You are not logged in.
Pages: 1
Busybox 1.00 released!!!
How about switching from coreutils (and other stuff) to busybox?
http://pdfinglis.tripod.com/widget.html
"In order to make an apple pie from scratch, you must first create the universe."
-- Carl Sagan, Cosmos
Offline
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
All of your mips are belong to us!!
Offline
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
The impossible missions are the only ones which succeed.
Offline
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.
http://pdfinglis.tripod.com/widget.html
"In order to make an apple pie from scratch, you must first create the universe."
-- Carl Sagan, Cosmos
Offline
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.
Markku
Offline
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.
All of your mips are belong to us!!
Offline
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?
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
Maybe I'm just stupid, but what's the difference between the 2?
DaDeXTeR (Martin Lefebvre)
My screenshots on PicasaWeb
[img]http://imagegen.last.fm/dadexter/recenttracks/dadexter.gif[/img]
Offline
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.
Offline
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?
http://pdfinglis.tripod.com/widget.html
"In order to make an apple pie from scratch, you must first create the universe."
-- Carl Sagan, Cosmos
Offline
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
Offline
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.
Offline
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.
Offline
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.?
http://pdfinglis.tripod.com/widget.html
"In order to make an apple pie from scratch, you must first create the universe."
-- Carl Sagan, Cosmos
Offline
Pages: 1