Tiny Core v4.0 Alpha 3

[roberts]

Tiny Core 4.0 Alpha3 is available for public testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/alpha/

Change log:

alpha1:
* Updated kernel to 3.0.3
* Updated udev to 173
* Updated glibc to eglibc-2.13
* Updated e2fsprogs base libs to 1.41.14
* Updated gcc base libs to 4.6.1
* Updated util-linux base libs to 2.19.1
* Updated all the custom core utilities to use the new repository area:
   http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/

alpha2:
* New loadcpufreq to handle module loading.
* Updated eglibc for 486/586 support.
* Updated busybox 1.19 with latest patches and fix for chpasswd segfault.
* Updated ondemand for console based extensions via Freedesktop Exec=cliorx prgname
* Adjusted .xsession to handle X startup failure.
* Adjusted .setbackground colors for wallpaper handling.

alpha3:
* Replaced ldd and ldconf with original versions not dependent on bash.
* Restored ssb module to base.
* Updated AppBrowser Search and Keyword as described below.
* Updated ab Search and Keyword.
* Updated search.sh internal script support for new search method shared by AppBrowser & ab
* New keyword.sh internal script support for new keyword method shared by AppBrowser & ab

Notes:
The Search method for both AppBrowser and ab is now a local info.lst seach.
To use enter the starting few characters of the desired extension, e.g., abi for abiword, or oper for opera

Both AppBrowser and ab now offer Keyword searching.
Examples: enter browser to display browsers, enter game to list games.

Attn: microcore users will need new Xprogs.tcz from 4.x repository.

[vinnie]

Notes:
Both AppBrowser and ab now offer Keyword searching.
Examples: enter browser to display browsers, enter game to list games.

finally! but these keywords are stored where?

[roberts]

On our servers. words.db is generated from the extension's Description: field.

[vinnie]

Ok, I think a package maker should be able to watch all the keywords listed in words.db to get an idea of the keyword when he use for a package.
A clickable list of words appbrowers may be valid?

[roberts]

words,db is not a set of predefined words rather the actual words from the extension's Description field. While it is true that garbage in results in garbage out. It should not be difficult for extension makers to use the new keyword search infrastructure that I have provided. Let's not make a mountain.

[vinnie]

It was only the prospect of a similar situation:
text_editor
editor_text
doc_edit
code_editor
...
all for the same tipology of software

[Lee]

Its mainly when I'm fooling around with alphas and betas and testing out a new release or when I'm trying to debug an installation that has gone astray (most of which are the case right now), that I wish for this.  If we already laid this question to rest, please remind me,  but since we're heading into 4.x I though I'd bring it up.

I've got lines in my menu.lst including the following boot codes:

For tc 3.8.3:

Code: [Select]

... tce=LABEL=pnyfob0 ...

For tc 3.8.4:

Code: [Select]

... tce=sdb1/tce3.8.4

For tc 4.0A3:

Code: [Select]

... tce=sdb1/tce40A3 ...

I can't use the LABEL clause for tc 3.8.4 or tc 4.0A3 because I want to specify a directory other than just plain "tce".  However "pnyfob0", a USB flash drive, gets different device IDs on different hosts so I'm forever having to adjust the "sdb1" part to reflect the actual device.

Any chance we could revisit the tce boot code so something like the following would work?

Code: [Select]

... tce=LABEL=pnyfob0:/tce4.0A3 ...

[maro]

Lee, I'm pretty sure that I've tested this a while ago (albeit with UUID instead of LABEL) and IIRC it was working just fine.

One thing I noticed is that you where using 'tce=sdb1/tce40A3' for the working boot code and 'tce=LABEL=pnyfob0:/tce4.0A3' (which includes a colon and a dot which I would have not expected to see) for your "target" one.

Is that a simple typo in your posting or actually copied from the config file (which would make the latter then probably wrong)?

[Lee]

It was a typo.  I was just putting that out as "for instance" because I didn't remember the issue having been resolved.  It has been a long time since I tried anything like this.  I'll try

Code: [Select]

tce=LABEL=pnyfob0/tce40A3
(no dot and no colon) next time I reboot.

Edit  2011-09-07 05:35:
Wow!  Do I ever feel sheepish!  I can't believe I either knew about that and forgot it, or I missed it entirely, but there it is - works exactly as I had hoped.

Thank you, maro, for pointing it out to me and Thank -you-, roberts, for implementing it.  Have I mentioned lately, "Thank you to the whole Tiny Core team and the community for making TC what it is"?  TC just keeps getting better and better.   

[curaga]

There was a small mixup with the 64-bit modules. Look forward to the next release.

[bmarkus]

Any idea how to avoid the 10-15% size increase of 4.0 built extensions compared to 3.x build? In most cases no need for GCC 4.61. Adding GCC from 3.x to 4.0 repo would help. BTW, 4.0 repo contains GCC 3.3.6 also.

[curaga]

Why not ask the gcc folks on what changed with -Os from 4.4 to 4.6? If there's a reproducible test case, some small package etc, they should listen.

[bmarkus]

Why not ask the gcc folks on what changed with -Os from 4.4 to 4.6? If there's a reproducible test case, some small package etc, they should listen.

For sure there are test cases (all extensions maintained by me ) Will make a try

[Jason W]

Here is link noticing a change in the behavior of gcc 4.6, perhaps building gcc with "--enable-frame-pointer" can restore the smaller size binaries generated by the previous gcc.  May be worth a try, if I am reading that page right.  (EDIT:I don't see -fomit-frame-pointer along with -Os causing a larger binary size with the TC 3.x I have available to test with remotely, so may not be the cause.)

http://www.mail-archive.com/coreboot@coreboot.org/msg30467.html

[robc]

Here is link noticing a change in the behavior of gcc 4.6, perhaps building gcc with "--enable-frame-pointer" can restore the smaller size binaries generated by the previous gcc.  May be worth a try, if I am reading that page right.  (EDIT:I don't see -fomit-frame-pointer along with -Os causing a larger binary size with the TC 3.x I have available to test with remotely, so may not be the cause.)

http://www.mail-archive.com/coreboot@coreboot.org/msg30467.html

I ran some quick builds of ccache to look at the different optimizations.  The build tests failed without the -fno-omit-frame-pointer switch.  The builds finished and produced the binary but the binary failed at runtime with the testsuites.  I would recommend adding the --enable-frame-pointer into gcc to prevent any runtime problems.

Here is a table of optimizations ran:

optimization	binary size
-Os	74.9k
-O1	75.6k
-O2	72.2k
-O3	89.0k
-Ofast	85.9k

I find it interesting that the -O2 gives the smallest binary size, though it is over 33% larger then in 3.x.

Also, compiletc depends on linux-3.0.1_api-headers, is this correct? I thought the kernel was 3.0.3.