Busybox 1.00

rehcra · 2004-10-14 08:19:01

Busybox 1.00 released!!!

How about switching from coreutils (and other stuff) to busybox?

bogomipz · 2004-10-14 09:31:28

The way I see it, it would be better to have busybox as an optional package that would replace coreutils if you choose to install it. If this package proves to be more popular than the packages it replaces, we could discuss making it default and the other packages optional.

I've got one question about busybox (and similar toolbox binaries). The main purpose of this program is to take up less disk space than the total space of the tools it replaces. This is good and all, but how is execution time affected? I mean, the binary you need to load to execute for instance the command 'yes' is way bigger than the original. There is, on the other hand, a good chance that the binary is already loaded because of its frequent use. So, will the execution of a simple command like 'yes' be delayed to a noticable degree when part of busybox?

-bogo

dp · 2004-10-14 09:57:08

dumping something must have a heavy reason to do so ... i would better like both as a choice, if this is easy to handle

on the other hand ... busybox seems really promising ... however i didn't really tried it in arch and am now in some time-trouble

references for the non-informed:
http://www.busybox.net/
http://www.busybox.net/FAQ.html
http://www.busybox.net/lists/busybox/20 … hread.html
http://www.busybox.net/lists/busybox/20 … 12795.html

rehcra · 2004-10-14 10:33:05

bogomipz wrote:

The way I see it, it would be better to have busybox as an optional package that would replace coreutils if you choose to install it.

I agree.

(...) the other packages optional.

This way Arch will not be GNU/Linux but Busybox/Linux/GNU.

So, will the execution of a simple command like 'yes' be delayed to a noticable degree when part of busybox?

I guess no, not at all. The kernel will have more to do (mapping ~1 MB means 256 pages), but this has marginal effect. Kernel doesn't have to touch all pages of executable.

On the other hand, some coreutils programs are heavily optimized for speed (this is one of the reasons they are large), but I think this won't have much impact too.

Certainly, busybox modules like bunzip2 are much slower than orignal (about 2 times, I guess). But it's better to have orignal bzip2, because it supports compression.

rasat · 2004-10-14 12:08:30

I am using busybox in al-amlug live CD to save space in miniroot, but would not use it in a HD distro centralizing several important system executes in one place what Window does. If busybox or in general a center controlling execute fails, the whole machine stops. Linux is a decentralized system where each and every component is on its own.... easy to maintain and update.

bogomipz · 2004-10-14 12:49:37

rasat wrote:

If busybox or in general a center controlling execute fails, the whole machine stops. Linux is a decentralized system where each and every component is on its own.... easy to maintain and update.

You got a point in that if busybox gets corrupted, a large number of commands stop working. There are however, other components that will break your system just as efficiently. Also, on a desktop computer you would normally boot from a CD, a floppy or a different partition to fix such a problem, not focus all your energy on finding a way to rescue the system from within.

On the easy to maintain and update part; if busybox replaced everything in the coreutils package and nothing else, you would neither get more nor less flexibility in the way things are updated because pacman already sees this as one component. Busybox has the potential to replace stuff from many different packages, though. This will mean you get less of that flexibility. I have not checked whether it offers all the programs from coreutils.

sweiss · 2004-10-14 16:12:56

From a quick reading of the BusyBox About page I came across the following sentence: "The utilities in BusyBox generally have fewer options than their full-featured GNU cousins".

So please make it an optional replacement to coreutils.

Anyway, how much physical space is gained from the use of it?

dadexter · 2004-10-14 16:23:59

Maybe I'm just stupid, but what's the difference between the 2?

kpiche · 2004-10-14 20:14:40

If you replace coreutils with busybox you'll find that your utilities have very few command options and the lack of functionality gets annoying after a while. Plus you'll have to modify a large number of shell scripts to work around missing options. It isn't hard, just annoying.

rehcra · 2004-10-15 05:26:58

Ok, I think I'm convinced that we shouldn't get rid of coreutils.

But choice would be nice. This means all Arch scripts need to be modified to work well with busybox.

By the way, does anyone know if autoconf-generated scripts are compatible with busybox?

iphitus · 2004-10-15 08:47:25

Busybox is designed for the small or embedded systems. I don't see much point at all using it on the desktop. It's slower, lacks features. The only advantage is size, however, 1,2,5,10mb however much more coreutils is, is next to nothing nowadays. I ran multiple distros on a 6gb hdd, and as much as I was scraped for hard drive space, busybox would have done next to nothing to help me.

iphitus

dreas · 2004-10-15 09:12:07

iphitus wrote:

Busybox is designed for the small or embedded systems. I don't see much point at all using it on the desktop. It's slower, lacks features. The only advantage is size, however, 1,2,5,10mb however much more coreutils is, is next to nothing nowadays. I ran multiple distros on a 6gb hdd, and as much as I was scraped for hard drive space, busybox would have done next to nothing to help me.
iphitus

/agree

I don't see much point in using BusyBox too, especially if it's much of a hassle to implement it properly or assure compatibility.

kpiche · 2004-10-18 05:25:50

rehcra wrote:

By the way, does anyone know if autoconf-generated scripts are compatible with busybox?

No. You'd have to modify the configure scripts every time. I have a busybox/uclibc dev environment and after about 5 minutes of poking around with this I compiled bash instead.

rehcra · 2004-10-18 05:31:45

kpiche wrote:

rehcra wrote:
By the way, does anyone know if autoconf-generated scripts are compatible with busybox?
No. You'd have to modify the configure scripts every time. I have a busybox/uclibc dev environment and after about 5 minutes of poking around with this I compiled bash instead.

Ok, this means using busybox on my system doesn't make sense. However, I'm amazed how they put together so many utilities in one executable.
Perhaps one day busybox will become more compatible.
By the way, what part of busybox caused the problem? Was it one of coreutils replacement or their version of sed, sh, etc.?

Arch Linux

#1 2004-10-14 08:19:01

Busybox 1.00

#2 2004-10-14 09:31:28

Re: Busybox 1.00

#3 2004-10-14 09:57:08

Re: Busybox 1.00

#4 2004-10-14 10:33:05

Re: Busybox 1.00

#5 2004-10-14 12:08:30

Re: Busybox 1.00

#6 2004-10-14 12:49:37

Re: Busybox 1.00

#7 2004-10-14 16:12:56

Re: Busybox 1.00

#8 2004-10-14 16:23:59

Re: Busybox 1.00

#9 2004-10-14 20:14:40

Re: Busybox 1.00

#10 2004-10-15 05:26:58

Re: Busybox 1.00

#11 2004-10-15 08:47:25

Re: Busybox 1.00

#12 2004-10-15 09:12:07

Re: Busybox 1.00

#13 2004-10-18 05:25:50

Re: Busybox 1.00

#14 2004-10-18 05:31:45

Re: Busybox 1.00

Board footer