water cooler :: Would it be time for DSL to shed its skin?



no one has any comments about my last question?
or might it be that this thread isn't shown in "new posts" anymore.. well now it is
I don't see much difference between the bloat from including dynamic libs in a package and the bloat from including libs statically in the executable.
Being a non-programmer, it sounds like voodoo to me - the thing about uClibc decreasing size of object files.

Let me explain myself more clearly:
We are not going to gain much in size reduction just from the smaller size of the uClibc main libraries as compared to Glibc.
The real size gains, as you have said, is from the smaller size of all code compiled using uClibc functions - hence the code size reduction is multiplied for each app.

The idea sounds very promising, but you are advocating a complete rework of DSL. Not just the base system; I mean, following what you said - all extensions have to be reworked.
But I don't like the idea. I mean, just think: All the memories from DSL, all gone. I know, all the extensions can be cleanly recompiled with uClibc and reposted. But they wouldn't be what they are, any longer. Besides, I don't think I have the right to take another person's extension and recompile it. It's more serious than this - If you do one, you have to do them all; it's like people can't even say no. I know, I could express this in a better way, but I do mean all this seriously.

I don't want to discourage, hamper, or hinder you in any way. In fact, I have fantasized giving DSL the full uClibc treatment myself, in the past. Perhaps we could do this as a shadow project, a side attraction alongside DSL. Something low-key but relevant to the people with this kind of interest (i.e. crypto-obsession) in small size.
I also propose an experiment just to honour the whole idea:
Try compiling a uClibc Firefox using buildroot - naturally, using the same buildconfig and the same version (1.0.6) as DSL's Firefox - and see how much the size is reduced.

Lastly, there is one last thing that hasn't been tried yet:
Try auditing all the code in DSL for code size.
I believe the binaries themselves are already compiled with '-Os', so there's no room for improvement with the binaries.
But some libraries I think were pulled straight out of Debian packages. Possibly we could get some marginal size gains there. Quite a small potential reduction - but it's there.
Basically, optimize the Glibc platform before moving on.
I know I am spending an unhealthy amount of time over something that is counter-productive to 'getting things done and changing the world', but.. Oh dear. Can't think of anything.. But! Curaga, assuming there's cooperation, we can get alot of libraries done quickly! That is all I want.

I don't mean to be pushy. I mean, if you don't like it at all, then just say, 'No, it's just too crazy!', or something like that.

Moderators, I apologize for inflaming this mania, this obsession, this abstruse, counter-productive, impractical concern with small size. I know that I've thrown away ettiquette and propriety for the sake of the last little bit of pseudo-elegance that does no one much of any good. My only fear is that DSL will be made into an imprint of my megalomania. I don't want that. Curaga, let's tune this baby up!
Nice one, stupid_idiot!

More in DSL has been drawn from Debian than you think. Maybe around 80% of the base. Plain -Os would gain something, but uClibC would give even more.

Let's. About your firefox idea: I haven't compiled firefox even once yet (I'm an Opera fan). And they mention that the one in DSL was modified to use only gtk1 and "took the pains of reducing it's space requirements as much as possible".. I don't know what they did, so an exact replica would be hard.

Quickie comparison of glibc-2.5 and uclibc-0.9.29 source tarballs: ~15mb and ~2mb.. So even replacing the main libs would have an effect. Also gcc-4 produces smaller code than gcc-3..

But you didn't say anything about the question of a static uclibc build environment for extensions needing a lot of libs not in core DSL, how about it?
Don't worry - Firefox builds out of the box with gtk1. I've tried this with 1.0.x, 1.5.0.x, and 2.0.0.x. As for what the DSL devs did in 'modifying' Firefox, I don't know exactly what they did - Perhaps these were only cosmetic changes?


Re: Building Firefox
1. Download source for 1.0.6 here (http://ftp.osuosl.org). 1.0.6 is not longer on ftp.mozilla.org - 1.5.0.x is the earliest.
2. Read this guide on how to write a '.mozconfig' file (used for configuring Firefox): 'Configuring Build Options'
You really should take note of the section 'Building with an Objdir' for the sake of convenience - If you want to discard a bad build, you can just delete the objdir and start over - Or, you can have multiple builds with differently-named objdirs.
3. In DSL's Firefox, go to 'about:buildconfig'.
Do you see the section "Configure arguments?" These should be pasted verbatim into '.mozconfig' using the proper syntax.
For each individual argument, start a new line, like this:
e.g.
Code Sample

ac_add_options --enable-application=browser
ac_add_options --enable-extensions=cookie,xml-rpc,xmlextras,pref,universalchardet
ac_add_options --disable-toolkit-qt
ac_add_options --disable-toolkit-xlib
ac_add_options --enable-toolkit-gtk
ac_add_options --disable-toolkit-gtk2
ac_add_options --enable-default-toolkit=gtk

The '.mozconfig' file should be placed in the Firefox source directory.
4. When you are done pasting all the arguments from 'about:buildconfig' into '.mozconfig':
Make sure you are in the Firefox source directory and that your '.mozconfig' file is placed in here as well.
Run `make`.

For building Firefox on uClibc, the procedure is the same.
The most straightforward way is probably to build from inside a uClibc environment. You can generate an entire uClibc system using buildroot (link to buildroot snapshots; direct SVN access also available - see here).

Building the uClibc environment using buildroot is similar to building the Linux kernel.
1. Extract and cd into source.
2. `make menuconfig` (Choose the packages that you want in your uClibc 'distro'/environment).
3. `make`.
At the end of it, a root filesystem image is produced (you can choose the filesystem type - ext2, iso9660, cramfs, etc - when doing `make menuconfig`).
Then you should set it up so you have an environment you can `chroot` into.
Possible choices:
1. `mount -o loop rootfs.ext2 mnt_dir` and copy the contents onto a spare hard disk partition.
or
2. Do the same as above, except just copy the contents into a directory somewhere.
or
3. 'rootfs.ext2' is fully used, but you can create free space:
`e2fsck -f rootfs.ext2` (`resize2fs` will insist that this be done first.)
`resize2fs rootfs.ext2 size_in_[kilo|mega|giga]bytes`
Then, just chroot into the image file itself. Hilarious!
`mount -o loop rootfs.ext2 mnt_dir` (Is it mounted read-write? Please do check!)
`chroot mnt_dir`
Next Page...
original here.