tinycore_v3.0rc1

[bmarkus]

As best as I can tell fldigi (the culprit behind the fltk recompile) does not require exceptions, just rtti and threads - the space savings is over 100kb ... unless other programs needed exceptions enabled in fltk.  (Note that exceptions still needed to be enabled in fldigi, but did not require them to be enabled in the fltk library)

Possibly it is right. For sure fldigi itself must be compiled with exceptions, rtti and threads. I tested compilation against fltk libs with same options. fltk.tcz now is 1.56M in size. I would live fltk libs as it is now to be on the safe side.

[tyler]

Version 3.0 is looking good! The last few alpha releases have been running without problems, but then I ran into a glitch with Xorg 7.5 during a hard drive installation of RC 1.

The machine is a Sony PCG-C1VPK, one of the old Picturebook line with a Crusoe processor upgraded to a mighty 238 MB of RAM. Because of the oddball 1024x480 display, which Xvesa sees as 640x480, I've resigned myself to loading Xorg. And indeed the previous test installation (3.0 alpha had run with Xorg 7.5 without any obvious problems.

For RC 1 I had updated the bzImage and tinycore.gz files and deleted my data and onboot.lst from /tce. After booting and updating the local extension copies, I figured it was time to load Xorg-7.5 and expand from the default 640x480 to 1024x480 again. Alas, after loading Xorg 7.5 via the  GUI Apps tool, I wasn't able to exit to the command prompt to run xsetup.sh or startx. Neither the logout menu nor the old Ctl+Alt+Bksp exit had any effect. (The lack of effect of the latter wasn't surprising, as this was apparently an "improvement" in the stock Xorg behavior.)

What <em>did<em> work was rebooting, exiting from Xvesa's GUI display via the logout menu, and then installing ala the command line: tce-load -i Xorg-7.5.tcz; xsetup.sh ; startx.

Why the logout/exit to prompt option didn't work I don't know. It might be an obscure permissions glitch, as I use boot codes for both user and host rather than the defaults. Now that Xorg-7.5 is in my onboot.lst, however, it's not a problem -- Xorg lets me exit to the prompt and back again without incident.

I'm not sure if something changed with the library upgrade, or I just didn't catch it earlier because I'd been keeping the onboot.lst around from alpha to alpha. But there you go...

Cheers,
Tyler

[bmarkus]

On my development system all extensions are mounted. Actually I have 262 loop devices which is definitely more than 256 and everything is working fine. So it looks like we can forget this 256 limit.

 

BTW, I do not recall an explicit statement that it is working now. Last as I remember that Kernel wise OK, but we need as new busybox to support it.

[helasz]

I find the combination of squashfs and unionfs extremely useful. Do not you plan patching TC 3.0 kernel for unionfs?

[curaga]

@tyler
I'm guessing the exit applet thought you were running Xorg, and thus didn't try to kill Xvesa.
Why ctrl-alt-backspace didn't work in Xvesa, that I don't know. A temporary glitch I think.

On this questionable improvement, I've reverted the change in 7.5; ctrl-alt-backspace works great there.

@bmarkus
Dynamic loops are working since the busybox update to 1.17.0-git (and 1.17.0 stable in -rc1).

@helasz
No, unionfs/aufs is not planned.

[attwo]

Running Micro Core 3.0 TC1 + Xvesa + aewm + various extensions on my Eee PC 900. It works perfectly and it's amazingly fast.
I noted that the wireless driver for the 2.6.33 kernel is a bit slower than 2.6.29; not a big issue anyway.

Amazing work, thanks.

[MakodFilu]

I have noticed OSS.tcz for 3.0 is different than the one used in 2.11.6. It has a dependency over 32 or 64 bits modules, depending on the kernel you are using, I suppose. This should be great, as it correctly download and install the right set of modules.

However, I found the sound of my Fujitsu-Siemens Liteline is no longer working. Have any module been stripped out in the new version? It works again when using 2.6.11.

I have separate /tce dirs for each version, which I rename during a base norestore boot, to avoid mixing repos. Then I reboot again into the chosen version.

[curaga]

@MakodFilu

It is a newer version, but all modules that built were included. Only two or three of the unmaintained drivers (in attic/) didn't build; can't recall right now which ones.

What's the sound card?

[meo]

Hi all!

I just have a suggestion. I would like a change of the color that comes up in app browser when an application is loaded. The current yellow is a bit hard to distinguish and I would therefore suggest a change to blue, for example the blue with following hex number:  00:00:00:a1. I suggest this because my medical condition, called muscle arthritis that causes pain and fatigue which forces me to rest a lot, and from my bed it's a little bit hard to see when an application is ready for use because of the color. Thanks for a great distro!

Have fun moving ahead with TC,
meo

[MakodFilu]

@curaga

According to osstest, it is a:

/dev/oss/oss_allegro0/pcm0 (audio engine 0): ESS Maestro3 (ESS1998)

[curaga]

@curaga

According to osstest, it is a:

/dev/oss/oss_allegro0/pcm0 (audio engine 0): ESS Maestro3 (ESS1998)

I'm afraid allegro was one of them, seeing as it's not included in the 4.2 module extensions. Since it's unmaintained and didn't even build, I guess you'll need alsa from now on.

[meo]

Hi all!

I have another suggestion for TC 3.0. It would be nice to have some kind of progress bar that shows how an installation or download is doing. The best would be to have it in the appbrowser in the field that shows what is downloading. If the progress bar is blue (like I suggested earlier) then the color could switch to red for example when everything is finished. I think that would be great and hopefully others agree.

Have fun making TC reach even higher in the IT world,
meo