I'm going out now. I may be some time.

[Rob Landley]

On Sunday 01 October 2006 11:45 am, Denis Vlasenko wrote:
> Fortunately, I am not going to pay attention to such silly distractions
> at all. All new code which I will commit to svn will be GPLv2 only.
> It's that simple.

Good for you.  Feel free to loot applets from toybox then (which is also GPLv2 
only, or at least will be when I get the new server finished to put the 
mercurial repository online with, anyway).  Although the design's noticeably 
different and I probably won't have anything worth using for a month or more, 
but hey.  Gotta start somewhere. :)

> > I think this is long and rambling enough.  Denis wanted to make sure I'd 
stay 
> > subscribed to the list, so I will, but I'm not planning on posting much.
> 
> Okay, I need to explain what I intend to do now.
> 
> I believe that busybox now is mature enough to be almost usable
> on ordinary desktop machines. So I actually did that - replaced
> most of applicable /bin/* with links to busybox.

Which is cool.  I was going for a self-hosting development environment first.  
The goal of my old Firmware Linux project was to build a system under itself 
with BusyBox and uClibc replacing every gnu package except the toolchain.  
The closest I got was seven packages (linux-libc-headers, uClibc, gcc, 
binutils, make, BusyBox, bash).  Eight if you count the linux kernel.  The 
last thing required to hit my original goal was bbsh (to replace bash).

My _new_ goal was to get it down to four:  linux, BusyBox, uCLibc, and tcc.  
That would involve upgrading tcc until it can build the Linux kernel, the 
kernel headers becoming usable (make headers_install in 2.6.18 is close, but 
alas not quite there yet for a couple different reasons), and me upgrading at 
least three things in BusyBox (bbsh, a write mode for "ar", and adding 
a "make" applet). 

My _new_ new goal is to get it down to linux, toybox, uClibc, and tcc.  (Heck, 
maybe I'll see if klibc can actually do anything useful.  If that gets merged 
into Linux, that would get me down to _three_ packages.  Still, that would 
just be an option: uClibc is more generally useful.)

> I expect some fallout. I will try to fix it.

Did uClibc ever fix the bug that made busybox "tar xvjfC blah.tbz dirname" try 
to extract a file called "C" when BusyBox was linked against uClibc 0.9.28?

I just updated "http://busybox.net/~landley/todo.txt" (so it's now "stale but 
less so") if you want to take a look at that.  I also sent you my "pending" 
folder (and have since dug up a second one, older and much smaller, dunno if 
any of that's still relevant...)

> Busybox should not lose its position of embedded device tool.

Oh, I dunno.  Toybox may make a play for the niche, someday. :)

I'm thinking of it as a sort of "BusyBox lite".  Someday, when computers go 
beyond cheap to disposable and you have a full motion video display on the 
front of each box of captain crunch, it'll still need software to run the 
thing.  And if it has to be cheap enough to throw away and also run on a 
cheap battery for months, 4 megabytes of ram could easily be the _high_ end 
of things, and the really tiny systems tend to be nommu to save the memory 
used by the page tables, so that may still be interesting too...

The bits of BusyBox development that have really held my interest weren't 
adding features, but taking our big bloated apps (ash, fdisk, e2fsprogs, 
shadow support) ripping them out and writing tiny versions.  (I may have 
started with "sed" to make binutils' ./configure happy, but my second big 
project was rewriting bunzip2 because the old one was just too big and 
complicated.)

*shrug*

> I think it makes sense to introduce CONFIG_DESKTOP and put
> all such things under it.

They should probably be individually configurable for now.

What I learned with CONFIG_NITPICK is that our current menuconfig sucks rocks.  
Visibility and selection state are mixed up horribly.  If you hide something, 
you set it to "n".  There's no way to make it take its default value when 
it's hidden, because the design assumption is that hidden means off.  
(Actually, hidden menus don't even get written out in the unmodified 
menuconfig; I had to change that to make the ENABLE_ stuff work.)

I'm all for tagging things into groups so you can switch the entire group at 
once to be "all on", "all off", or "individually editable" with a central 
switch somewhere.  But our current .config infrastructure doesn't do that, 
and I wasn't going to upgrade the old stuff if you had a kernel/klibc-based 
replacement in the wings... :)

> I will add such thing with gunzip -v fix. 
> Non-DESKTOP bbox will silently ignore -v,
> DESKTOP one will print statistics.

We can have various default configurations.  Not quite sure on the syntax 
("make desktopconfig"?) but I don't see it as a bad thing.  This is something 
miniconfig was going to allow.  (Then again, I've been called a 
perfectionist, rewriting entire subsystems to get the behavior I want.  I 
wouldn't ask anyone else to do that.  Among other things they're probably 
sane.  And you may notice that being maintainer seriously cuts into your 
actual coding time.  Reading and merging other people's code happens at the 
expense of writing your own.  Only so many hours in the day.)

It's your call, I'm just saying how I'd do it.  Since I'm _not_ doing it (not 
here, anyway), this carries no weight and is eminently ignorable.

> I know that increased attention to destop needs will inevibably
> lead to _some_ increases in size even for non DESKTOP case.

I didn't accept increases in size for the non-development environment case.  
It's not inevitable, it's just a boatload of work repeatedly re-auditing 
stuff.  (And bloat-o-meter is a beautiful thing.)

But again, it's a question of finding somebody to do the work.

> Please think also about positive side: with such move there is
> a chance that bbox will get much wider userbase and therefore
> will bring some sanity into desktop world.

I kept hoping knoppix would pick it up, but they never did.  I cornered some 
of the One Laptop Per Child guys at OLS, but they hadn't even looked at it 
and they're being sponsored by Red Hat.

Good luck with this.

> Of course contributions and corrections (and even rants about
> bloat) from embedded people are still accepted
> and encouraged.
> 
> P.S. below sig: the list of applets I added to /bin on my box.
> Need to check whether it will at least boot correctly now ;)
> --
> vda

I'm about 2/3 of the way through the patch backport for 1.2.2.  (You may 
notice that http://busybox.net/downloads/busybox-1.2.1.fixes.patch has gotten 
noticeably larger.  Since this is the last "or later" licensed release I'm 
merging all the relevant fixes up through svn 16112, so there's a ways to go 
yet.)  I might get that done today.  Dunno.  (I might finish book 3 in the 
Temeraire series, "Black Powder War", instead.  Might manage both!)

I'll update the news.html page for 1.2.2, and I'll mention the change of 
maintainership when I do.  After that I'll be out of your way.  Meanwhile, 
off to the coffee shop, with paperback and laptop.  (Wasn't that a book by 
Hemingway or somebody?)

Rob
-- 
Never bet against the cheap plastic solution.