tinycore & microcore v2.0rc4.

[roberts]

Now ready for testing Tiny Core V2.0 Release Candidate 4
and introducing MicroCore a 7MB no X environment iso based on Tiny Core.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release/

Combined and updated change log:

* New kernel 2.6.29.1
* New glibc 2.9
* New libstdc++ and libgcc
* New ldconfig
* New base Xlibs
* New squashfs module to base for support of squash'ed extensions.
* New cryptohome to use AES.
* New mount and losetup
* New virtual drive support.
* Updated mousetool
* Updated appbrowser
--
* New tc-config & desktop.sh to support for window managers via WM interface programs.
* New cd-dvd-symlinks.sh to create generic cdrom and dvd devices.
* New updated udev rules 75-cd-dvd.rules to automatically create cdrom and dvd device names.
* Updated wbar.sh to retain HOME focus.
* Updated xsetup.sh mouse menu label change.
* Added /usr/local/sbin, /usr/local/bin to boot time PATH.
* Added tce-wget wrapper for CLI alternate to appbrowser.
* Updated flpicsee, new scaling, zomming, and popup informaton.
* Updated appbrowser Search now searches v2.x repositories.
* Updated cpanel to use generic HOME for tftpd.
* Updated extitc to be smaller via a single nix call.
---
* Updated imlib2 to 1.4.2
* Squashfs support for extensions has been enabled.
* Added Esetroot for background image support for window manager independence.
* Updated cpanel - Backgrounds button returns for support of window manager independence.
* Updated wallpaper GUI now supports multiple window managers via standardized calls to interface files. (See notes for RC3)
* New extension driven "desktop" boot option. Adding a WM extension no longer requires the corresponding desktop=xyz option.
* New restore=xyz-less restore. If your mydata.tgz is moved to your 'tce' directory then no need to specify restore=xyz.
----
* New microcore a 7MB separate iso based on the same core as tinycore but without the X environment.
* New support for ".core." elements, specialized squashfs system components that load early before any extensions,
* New support for /opt/tce used to optionally host ".core." elements within the initramfs.
* By popular demand JWM returns as default window manager for tinycore.
* Fixed fullscreen video bug in JWM.
* Depreciated .desktop via a new .xsession and extension driven "boot time" option settings.
  
Files likely in your backup that need update:
.profile
.xsession
/opt/.xfiletool.lst

Note: More to follow on microcore and .core. elements, but for now lets try to test tinycore and get it to final status.

Note: If you use the Xorg extension, use must grab the latest version. All Xserver extensions and Window Manager extensions must register at /etc/sysconfig/Xserver and /etc/sysconfig/desktop respectively. This is simply adding a one line to the extension and allows for extension driven "boot time " options.

[jpeters]

NICE!!   Working well on my dells with jwm.  THANKS

[bmarkus]

Both looks OK on ACER Aspire 5720Z laptop using for a while. The only issue with tinycore is that extension download (wget) stops randomly and Appbrowser is freezing, same with 2.0rc3 on two different machines. It varies in time; there are periods when it works nearly 100% and at other time useles.

[bigpcman]

Wow, you have done an incredible amount of work! I have been running the v2.0rc4 system on my dell development laptop without any problems.

I like the return of the jwm desktop although I was getting used to flwm.

I am wondering what kind of changes I will have to do to support a two display system when running a remote desktop. There were three system files that I had to change for flwm. I suppose there will be a similar set for jwm.

Anyway thanks for all the effort !

[meo]

Hi Robert!

Very good work. The new rc seems to work very nice. There is but one problem I have encountered so far. The background button on the control panel gives no response when clicked on. It might be something I have overlooked but since I have started from scratch with this release I think it would be worthwhile to look in to it. Anyway thank you for an excellent work.

Have fun,
meo

[roberts]

Thanks for feedback. Yes. That is an oops concerning wallpaper.
I forgot to update wallpaper again. With .desktop being depreciated breaks wallpaper.
I will be sure to have it fixed in 2.0 final. For temporary work around make a .desktop file in home directory with a single line of:
wm: jwm

Or other window manager that supports ..._setbackground interface.

[meo]

Hi again Robert!

Thanks a lot for your quick response. I kind of like to have a nice wallpaper when I'm working on the pc. So thanks again and keep up your most appreciated work!

Have fun all you TC-fans out there,
meo

[roberts]

I will post a bug I found this morning.

This only can happen if you are using the new shortcut method of storing your backup, mydata.tgz, inside your tce directory.

When doing so, the 'norestore' option is ignored. So, if you occasionally, use norestore and you have moved your backup to be located inside your tce directory. Be advised.

I have this fixed for 2.0 final.

[mcewanw]

Using tc2rc2.4 with no mydata.tgz (i.e. clean)

I think this is a bug, but I thought I'd seek clarification before posting it as such:

There seems to be an extra "sh" process left behind after starting up any application (if exec was being used the application should overwrite the originating sh call surely?)

Here is my ps output after starting up a number of aterm's, firefox and emelfm2

Note all the sh -c processes still running for firefox and emelfm2 (and a separate sh process along with each aterm):

Code: [Select]

  6748 tc       /usr/bin/aterm
 6749 tc       sh
 6760 tc       /usr/bin/aterm
 6761 tc       sh
 6778 tc       sh -c /usr/local/firefox-official/firefox
 6779 tc       /bin/sh /usr/local/firefox-official/firefox
 6782 tc       /bin/sh /usr/local/firefox-official/run-mozilla.sh /usr/local/fi
 6787 tc       /usr/local/firefox-official/firefox-bin
 6798 tc       /usr/lib/gconf2/gconfd-2 13
 6820 tc       sh -c /usr/local/bin/emelfm2
 6821 tc       /usr/local/bin/emelfm2
 6824 tc       /usr/bin/aterm
 6825 tc       sh
 6836 tc       ps


[roberts]

There is some history as far as the aterm call from .jwmrc goes:
Currently aterm is called with the -e /bin/sh option (extra shell).
Originally TC, which uses busybox ash shell, had no .ashrc.
Users wanted to re-source .profile for any changes made after login, so -e /bin/sh was added.

Now after several updates to busybox and the addition of .ashrc (TC v1.1) calling solely aterm should source .ashrc so new items in .ashrc are available.

Subtle point, but perhaps now again another change in aterm's call in the JWM menu is needed.
Since RCs are about field testing, may I sugest that since .jwmrc is under your control, i.e., in your backup by default, remove in the three calls to aterm the -e /bin/sh and verify that .ashrc will be re-read for an updated environment in the new aterm, and finally post your results.

[mcewanw]

may I sugest that since .jwmrc is under your control, i.e., in your backup by default, remove in the three calls to aterm the -e /bin/sh and verify that .ashrc will be re-read for an updated environment in the new aterm, and finally post your results.

Using tc2rc2.4 with jwm.

Assuming what you meant, I modified part of .jwmrc to:

<Menu label="XShells">
  <Program label="Dark"> exec aterm +tr -T "sh"</Program>
  <Program label="Light"> exec aterm +tr -bg white -fg black -cr blue -T "sh" -e /bin/sh</Program>
 and rebooted.
  
[I purposively left the -e /bin/sh on the "Light" terminal for comparison purposes]

I then started up a few aterms and emelfm2 apps using the following different methods to see the result in terms of the number of sh processes that are left running:

1. Dark aterm started from jwm menu
2. Dark aterm started from jwm menu
3. aterm started using: aterm & (from commandline)
4. aterm started using: aterm & (from commandline)
5. emelfm2 started from jwm menu
6. emelfm2 started from jwm menu
7. emelfm2 started using: emelfm2 & (from commandline)
8. emelfm2 started using: emelfm2 & (from commandline)
9. Light aterm started from jwm menu
10. Light aterm started from jwm menu

The following is the result from running command "ps".
Note how running emelfm2, for example, from commandline (items 5 and 6 above => pids 6595 and 6598 below) don't result in an extra sh process running. In other words, starting apps from jwm seems to result, as I said in a lot of overhead in terms of extra sh processes.

In the aterms which weren't started with -e /bin/sh, I entered du and the result was actually a du -h, which shows that .ashrc was being read since the alias du equals du -h was from there.

Code: [Select]

6639 tc       /usr/bin/aterm
 6640 tc       sh
 6651 tc       /usr/bin/aterm
 6652 tc       sh
 6663 tc       aterm
 6664 tc       sh
 6675 tc       aterm
 6676 tc       sh
 6687 tc       sh -c /usr/local/bin/emelfm2
 6688 tc       /usr/local/bin/emelfm2
 6691 tc       sh -c /usr/local/bin/emelfm2
 6692 tc       /usr/local/bin/emelfm2
 6695 tc       emelfm2
 6698 tc       emelfm2
 6703 tc       aterm +tr -bg white -fg black -cr blue -T sh -e /bin/sh
 6704 tc       /bin/sh
 6716 tc       aterm +tr -bg white -fg black -cr blue -T sh -e /bin/sh
 6717 tc       /bin/sh
 6728 tc       ps
 
Unfortunately I'm preparing for a job interview next week so can't investigate this much more just now sorry.  

Great distribution this, by the way. Fantastic to work with in terms of its ease of adaptability. Can't be bothered using any other Linux distribution now...

[mcewanw]

I repeated some of "the experiment" on a different Linux distribution (which also uses jwm but didn't by default have aterm or emelfm2, so using rxvt and leafpad).
Half of the following rxvt shells were started with jwm menu; the other half with rxvt &
The same goes for leafpad.

As you can see there are no extra bash (shell) process overhead associated with the started leafpad whether started from jwm menu or from the commandline with leafpad &.

7628 root       2772 S   rxvt
 7629 root       2800 S   bash
 7705 root       2772 S   rxvt
 7706 root       2796 S   bash
 7819 root       2772 S   rxvt
 7820 root       2796 S   bash
 8299 root       2788 S   rxvt
 8300 root       2796 S   bash
 8375 root       2788 S   rxvt
 8376 root       2796 S   bash
 8471 root       2788 S   rxvt
 8472 root       2796 S   bash
 8608 root      13244 S   leafpad
 8633 root      13344 S   leafpad
 8655 root      13344 S   leafpad
 8693 root      13344 S   leafpad
 8794 root      13320 S   leafpad
 8818 root      13320 S   leafpad
 8858 root       1600 S   sleep 2
 8859 root       2312 R   busybox ps

[jpeters]

adding alias cl=clients to .ashrc  with .jwmrc:  <Program label="Dark"> exec aterm +tr -T "sh"</Program>

tc@box:~$ cl
 8073 tc       /bin/ash /home/tc/.local/bin/clients
 8074 tc       wish8.5 /mnt/hda3/MyFiles/clients

[mcewanw]

There is some history as far as the aterm call from .jwmrc goes:
Currently aterm is called with the -e /bin/sh option (extra shell).

The problem I am referring to is with /usr/local/tce.wbar and pretty much 'all' the entries in /usr/local/tce.menu
Since the issue concerns so many extensions, fixing the problem appears to me to involve quite an undertaking, unless TCbase can be modified to address the issue, because the tce.menu entries are inbuilt into every tce and tcz.

For emelfm2, for example, the relevant c: entry line in tce.wbar currently needs to be changed

from: /usr/local/bin/emelfm2
to: exec /usr/local/bin/emelfm2


/usr/local/tce.menu/emelfm2 (as provided by the tce and tcz extension creator) needs to be changed

from: <Program label="emelfm2">/usr/local/bin/emelfm2</Program>
to: <Program label="emelfm2">exec /usr/local/bin/emelfm2</Program>

Unless, that is, all the unnecessary sh processes which are currently left running (because of the missing "exec" instruction) are considered acceptable, but that would hardly fit in with the minimalist philosophy and is a major bug and unacceptable system overhead IMO.

If TC core itself can't be modified to remedy the problem, then it seems that pretty much all extensions need to be fixed to include "exec" at the front of the application run path in the associated tce.menu entry. There appears to me to be no simple fix for the user.

Also, the Wiki page about creating iconmenus should also be altered to reflect the need to include the "exec" instruction within the Program label run application stanza.

I note that the aterm, cpanel, and appbrowser references in /usr/share/wbar/dot.wbar DO include the exec in front of the application run path, so TC core appears to be "correct" in that sense. The same applies for these particular apps as far as .jwmrc is concerned.

[jpeters]

Kindof like the difference between running  "$RED" and "echo $RED". Both work, but the former
involves sh in a different way.