Slashdot Mirror

I think Microsoft and SCO have very clear strategies about open source. So does Linksys and all others on the BusyBox Hall of Shame

I think Microsoft and SCO have very clear strategies about open source. So does Linksys and all others on the BusyBox Hall of Shame

I think Microsoft and SCO have very clear strategies about open source. So does Linksys and all others on the BusyBox Hall of Shame. A clear strategy to parasatise and cannibalize opensource is never good.

> In Asia and Latin America, we see that there are many national and regional projects to develop and to work on open source.

If Europe is lagging behind , it's very strange that an industrialized continent replete with welfare states fails to motivate it's youngsters to learn with OSS and maybe earn a bit as well. It's a comfort addict situation.

It has an 55MHz Arm Processor, runs Linux and has busybox aboard. Enough control for me.

That very true. Few companies dare to break the GPL over the Linux kernel directly, but they have little problem with breaking the license of lower profile projects like the incredibly useful Busybox.

That very true. Few companies dare to break the GPL over the Linux kernel directly, but they have little problem with breaking the license of lower profile projects like the incredibly useful Busybox.

Fortunately not. When a license says you can't copy stuff, or a storage medium is copy-protected, more people may pay up for an original. But at the same time, other people may get annoyed, and copy stuff precisely because it's forbidden. So you put something out, and it will be copied. Period.

Funny: the reverse is also true. You grant some rights that people otherwise wouldn't have (I'm talking GPL or Creative Commons here), on the condition that they obey some rules, and guess what: those rules get ignored too. For software, the BusyBox Hall of Shame is just one example.

The only thing licenses, copy-protections etc. do, is keep lawyers busy, and (somewhat) influence the economics involved. But no matter what rules copyright holders come up with, most people don't care, and these rules are ignored. Just check how few people actually read licenses.

Wrong! Linux is chosen for embedded systems simply because that's what it's best suited for. Plain, dumb I/O, resource manager are all these systems and routers and other "appliances" need. They don't need the power/applications of a server or workstation. Using Linux just keeps the engineers from having to spend $ developing software. These tasks used to be handled in microcode, but with the arrival of packages like BusyBox, it's easy to patch in a simple-minded OS.

...complete linux system (without kernel)... ...is that the sound of a long-haired, bearded, GNU guy clenching his teeth?

Very funny, smartass ;-)

No, it's the sound of a development engineer making embedded systems with linux, uclibc and busybox. Our system uses an Intel PXA250 CPU, with 32MB RAM and 8MB flash. BusyBox gives us plenty space left, to run our own application on the system. We have tried to build the system with glibc and the standard GNU tools, but that used almost all available RAM and flash so the system was basically useless.

No, I am not featured on the "Busybox hall of Shame".

Now that we have a lean userland in BusyBox and a lean C library in dietlibc, the next step is a lean kernel.

Suggestions?

...link to the Hall Of Shame: http://www.busybox.net/shame.html

It's a list of all the companies that use(d) BusyBox in some way without releasing the source code.

...are liars I tell you!

They robbed us of a real screenshot!

Not true at all. Check out uClibc and BusyBox. In fact, I may get one of this NSLU2 boxes *just* to hack on it.

It seems they let just about anybody post to Slashdot these days.

I am sorry if following the rules hurts sveasoft's business. Tough. Guess how much money I earn for every device sold based on my code? Zero. I see no reason why other's such as sveasoft should profit where the authors of the code earn nothing. Expecting to earn royalties off of what he received for free and has modified slightly is a poor business model.

I am sorry if following the rules hurts sveasoft's business. Tough. Guess how much money I earn for every device sold based on my code? Zero. I see no reason why other's such as sveasoft should profit where the authors of the code earn nothing. Expecting to earn royalties off of what he received for free and has modified slightly is a poor business model.

But this is good for colleges and other places where the concentration of "guys who can stop by and fix the router" is high. Also not to mention the tinfoil factor of a readonly-livecd router (but does it have remote logging).

The BusyBox Hall of Shame lists this device as one of several that is violating the GPL in using BusyBox, and presumably other packages too. Anyone know if Hauppauge is actually doing anything about it?

Obviously he's never heard of BusyBox, or seen the list of products which run it. Or the list of products which run it without giving it credit. While some companies certainly seem to enjoy using F/OSS and giving credit where credit is due, others seem to have no problem ripping off the work others have done, atleast when they don't think they'll get caught.

A good point was made on GrokLaw the other day: it's easy for commercial companies to make sure that none of their code has made it's way into F/OSS, but it's monumently harder for members of the open source community to make sure none of their code is being misused in commercial software and/or products.

Obviously he's never heard of BusyBox, or seen the list of products which run it. Or the list of products which run it without giving it credit. While some companies certainly seem to enjoy using F/OSS and giving credit where credit is due, others seem to have no problem ripping off the work others have done, atleast when they don't think they'll get caught.

A good point was made on GrokLaw the other day: it's easy for commercial companies to make sure that none of their code has made it's way into F/OSS, but it's monumently harder for members of the open source community to make sure none of their code is being misused in commercial software and/or products.

Obviously he's never heard of BusyBox, or seen the list of products which run it. Or the list of products which run it without giving it credit. While some companies certainly seem to enjoy using F/OSS and giving credit where credit is due, others seem to have no problem ripping off the work others have done, atleast when they don't think they'll get caught.

A good point was made on GrokLaw the other day: it's easy for commercial companies to make sure that none of their code has made it's way into F/OSS, but it's monumently harder for members of the open source community to make sure none of their code is being misused in commercial software and/or products.

That's a ridiculous statement. The firmware IS the router. Without the firmware, the router is a few of off-the-shelf ethernet chips and a processor. The only difference between many different products is the firmware.

You're being needlessly pedantic, and you're probably wrong by your own definition anyhow. There's no one solid definition of "operating system", but a distro is way more than an operating system: a distro is an operating system plus an application suite -- usually a very extensive one. Probably the minimum that you'd call "operating system" is the Linux kernel booting into Busybox or similar.

A good shell to have is "sash", or Stand-Alone Shell. Not only is it statically linked, but it also has internal versions of mv, cp, ls, dd, gzip, etc...

I've sent emails, asking for the reasons why snippets of our source end up mysteriously in their commercial applications. In one case, a company (in Germany) came back stating that they happen to have the 5 same exact function names in their application, and byte-for-byte identical perror() strings to our application, but they insist they're not using any of our code, but claim that they did use it "for documentation purposes" when writing their application. That one is still open and pending, and we'll be doing protocol sniffs to see if theirs match ours. We have certain "fingerprints" in our protocol, which can only be done by using the source directly.

Another company I just found several days after the one above, seems to be using our code in a commercial BeOS project. They responded to my email, claiming that our code was used "as is" in their project, and then goes on to say "the use was re-configured to allow for easier additions". I don't see how they can claim both, in the same project. Either the code was used as-is (impossible, our code doesn't build on BeOS), or they modified it (and they must give us back the changes to those sources).

Another company directly took our code, removed all of our names from the project, replaced them with their own, slapped their own (non-GPL) license on it, and sold it to "partners" for quite a hefty fee. When we confronted them asking for an explanation, they basically told us to piss off. When we escalated, the CEO came back with, and I quote "If we end up in court, I will bankrupt these guys".

We also contacted this company's "partners", and asked them for the source to the changes they were also distributing. Every time we would contact these companies, the original company would threaten to sue us if we contacted their partners.

The FSF is involved in all of the cases. The investigations are still open, and pending.

Companies seem to think that because they have money, and most Free Software developers do not, that they can just slap us around left and right. The other point companies seem to try to "leverage" when they are clearly violating the GPL, is that the common myth that the "GPL Has Never Been Tested In Court(tm)", and since it has no basis, they can take whatever they want, and not give back. They seem to forget that the U.S. Copyright system backs up all of this code.

So what do we do? There are dozens upon dozens of cases where the GPL is clearly being violated; the MPlayer violation from KISS Technologies, the BusyBox Hall of Shame, and many more.

Who have a history of GPL ignoring: busybox gpl hall of shame

Also of intrest: this lkml thread

Sorry didn't finish with my example:

Hauppauge incorporated proprietary source as subroutines in the BusyBox (GPL) binaries on the initial release of its MediaMVP. These are the fpage and mpgdec programs, which are clearly part of BusyBox in the ramdisk image.

Subsequent releases the programs were compiled separately, and the very scarce source code release does not include the source to compile the original release version of BusyBox . . .

Does GPL force release of what was previously proprietary source code in this case?

Embedded = Busybox or less. I don't even use full init implementations on embedded gear cause it's just too dang big. Python would, of course, be "right out". I do have to admit, another GOOD choice for 'init' is a plausable idea (gods know I'd love to see chkconfig go bye-bye), but whatever the solution, it needs to be fast, clean, and efficient.

A new shell (no bash, no ash, no sh at all!) A new shell scripting language A new (universal) packaging scheme (would retrofit other OSes) A true application management system A new core process management system (No 'init' here...)

• BusyBox has an excellent sh implementation that supports tab completion.
• BusyBox's same sh implementation is great for shell scripting. Lots of the same poeple who want a Linux router know how to write shell scripts, why would they want to learn a new language?
• Dependency tracking package managers do not fit well into embedded distributions. Not only are they storage hungry, but they're definite overkill on an embedded distro where you probably aren't going to have very many packages anyway. I use Slackware's pkgtools since they work great and take up almost no space because they are shell scripts.
• Application management.... what applications? Deamons are started, restarted, or stopped with init scripts. Daemons are configured in /etc/. Applications are run on the command line.
• BusyBox also has an init. I think it does the job quite nicely. What else should a core process manager do except run some other processes?

LRP didn't just die. It evolved, or reincarnated. Linux Embedded Appliance Firewall (or LEAF) is the next step. Kernel 2.4 support, several ready distributions for different needs, packaging system, etc..

"LRP is dead" news is more like a bitter cry of an abandoned developer.. If he touts his "next version would've had all these magical abilities", why doesn't he release it? Even a partial implementation would probably attract attention and it could be integrated into other embedded projects.

Linux-on-a-floppy idea is generally just an issue of picking the right components and wrapping it up. I taught a linux-trainee to make an iptables-floppy in one night, just by cut-pasteing parts of a running debian system and compiling a custom kernel.

I'd say that the linux-floppy-culture owns most credit to uClibc and Busybox developers, for making embedded-sized libc and utilities.

I've found slackware tends to be nice to slower hardware. Slack 3.0, for example, is running quite briskly on my 386 now that I upgraded from 3 to 7 Megs of RAM. Plus, I could fit lots of development tools and a minimalist X in 80 megs of HD and 17 megs of swap.

Of course, thanks to glibc, such things are now very tough. But, don't forget, slack used to use BSD libc (which is small and fast!), and guess what still uses it? that's right, *BSD. So if you'll consider more than just linux, don't be afraid to look at NetBSD (which is a little smaller and lighter than FreeBSD.... not sure how OpenBSD compares).

You might also want to test-run Knoppix, since it doesn't even need to be installed (so it can't hurt!).

For window managers, OpenLook VWM, FVWM, Blackbox (probably the best), or mwm. Please don't force them to use twm... they'll never want to look at a computer again!

If you want a small memory footprint, try the embeddable shell alternative: BusyBox.

"BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add /dev, /etc, and a kernel."

Actually, in the embedded computing space, there may well be no GNU code on the box. Both of my most recent PDAs have used Busybox utilities in place of the huge (and therefore featureful, but not ideal for a machine with small amounts of permanent storage) GNU utilities.

A previous version of the Linux distro for the iPAQ used the full GNU utilities, but they switched to Busybox a while back for space reasons.

And you know what? A Linux distribution based on Busybox that follows the Linux filesystem standards feels a lot like any other Linux distribution (GNU-based or not). And it doesn't feel very much like a Solaris distribution when /usr/local/gnu is at the front of my PATH. And I've never played with GNU/Hurd, but I bet it doesn't feel much like GNU/Hurd, unless GNU/Hurd has deliberately adopted standards from the Linux community. All of that is part of why I call Linux distros Linux distros. It feels more accurate and more descriptive to me.

People routinely refer to Slackware Linux as Slackware, and to Debian [GNU/]Linux as Debian. If Richard and the FSF want to increase the public mindshare of the term GNU, one good way to do it would be either to encourage Debian to rename their project "GNU Linux" ("GNU" being the name of the distribution), or to start their own Linux-based distribution which they refer to from the start as "GNU Linux". And people would routinely refer to it as GNU, and maybe make the connection that the same people who put it together produced the GNU utilities that show up in other Linux-based distros. That would be a lot more effective than arguing with people about terminology. After all, it's been something like thirty years that people have been encouraging gender-neutral language, a change in terminology that benefits half the population of the planet rather than a small fraction of geeks, and changes in that area are still far from complete. If the FSF wants widespread mindshare for the phrase "GNU", and widespread understanding of what it represents, and if they want it while POSIX-like operating systems and semiconductor-based computing are still relevant, they need marketing methods that work faster than that.

> What is the weakest specced machine that anyone here is getting productive/useful work with Linux done on?
> Do people use Linux on 468s at 12mhz? P75s? Just curious.

Newer distros assume you have at least some hundred megabytes of disk space, a decent amount of memory and a relatively fast CPU.
To use old hardware efficiently you should look at projects like uClibc or Busybox that are intended for embedded/small devices.

the story author really should have put in a url to busybox.. here it is.

The first post called Linux software bloated (oh come on, glibc is VERY bloated - try using at uclibc or dietlibc - they don't have 100% of glibc's functionality, but for embedded systems it's amazing how much space they save) and it's a troll?? Then he makes a statement that starts with "probably" and turns out to be wrong - Debian and RedHat 'ls' definitely link with several libs. I won't say "probably", but who wants to bet on how many of the other major distros do as well?

Ok, to put something less whiny in my post - if you're worried about having a functional set of utils for emergency use, install busybox. For ~800k statically linked you get a ton of utils in a multicall binary, along with a shell. Available from the RedHat install CDs, in fact.

Putting pico in front of a unit is simply easier than writing 0.000 000 000 00x (or twelve figures before the decimal point) before your number and putting micro in front of a unit is a short way of writing 0.000 00 (or 6 figures before the decimal point) before your number. So one micro has 1 000 000 or one million pico units in it. [ source]

So as you can see, MicroBSD, referenced in this article, takes 1,000,000 times more space than PicoBSD. Using compiled-assembly /bin utils, combined into one executable which checks $0, such as busybox--one is able to strip down the OS to fit on a 1.44Mbps floppy disc. I would suppose MicroBSD is aimed to fit on a 700MB CD-RW, with the ~600MB left over for user files thanks to the rewritability of RW media. As you can see, there is a large gap between Micro and PicoBSD, each fills their own niche.

Cool. This device uses Busybox and uClibc. These are very very cool projects for developing embedded systems. Of course I'm biased (busybox and uClibc maintainer hat on), but I had no idea these folks were building an AP with them. Looks pretty nice. I hope they send me a free one. ;-)

• Client side devices (miniPCI/PC cards, particularly GPRS/802.11 combo cards)
  
• Mesh networking technology
  
• Technology for enabling seamless roaming, by means of cellular and WLAN networks
  
• Additional security features
  
• Integration with innovative antenna technologies
  
• Expansion of the platform beyond the WLAN market

• Processor: Motorola MPC8241 running at 200MHz
  
• RAM: 32MB (default), 64MB, or 128MB of SDRAM
  
• Flash: 8MB (default) or 16MB
  
• 1 x Davicom DM9102AF (tulip-clone) 10/100 Ethernet on RJ45
  
• 1 x miniPCI socket (comes filled with a 802.11b NIC and "AP" software)
  
• miniPCI socket has the pins for V.90 modem and 10/100 Ethernet brought out to a second RJ45
  
• 1 x Smart Card (SIM form-factor)
  
• I2C header
  
• 3.5 x 3.6 in. (smaller than PC/104 form-factor)

• Processor: Motorola MPC8245 running 333MHz
  
• RAM: 1 x SODIMM socket, usable with up to 512MB (off-the-shelf modules)
  
• Flash: up to 32MB
  
• 2 x Davicom DM9102AF (tulip-clone) 10/100 Ethernet on RJ45s
  
• 2 x miniPCI socket
  • first slot comes filled with a 802.11b NIC and "AP" software);
    
  • first miniPCI socket has the pins for V.90 modem and 10/100 Ethernet brought out to a second RJ45
• 1 x full PCI slot (more Ethernet, T1, T3, additional 802.11a/b/g NIC, etc.)
  
• 1 x Smart Card (SIM form-factor)
  
• I2C header
  
• Size: 6.0 x 7.0 in.

• PPCBoot
  
• PowerPC Linux kernel
  
• Busybox
  
• hostap
  
• uClibc (A glibc2 environment is also available)
  
• M.U.S.C.L.E (Movement for the Use of Smart Cards in a Linux Environment)
  
• open1x.org

Another issue, is the poor way that Lineo participated in the open source community. Taking, but not giving back. MontaVista is a better example of an embeded linux company that understands the importance of open source community membership and fiscal responsibility.

I think this is unfair. Lineo were behind Busybox and uClibc, both under GPL. Erik Andersen is the maintainer of these and he was employed by Lineo until being laid off a few months ago.

john

Exactly. Just like busybox. :)

Just FYI, BusyBox is a pared down set of basic comman line unix utils, integrated into a single binary. It's function is determined by symlink's or command line params. Pretty cool, especially when ls and stuff stops working 'cause you nuked your libc. ;) hehehehe (c'mon, who hasn't done that at least once?!? :) )

Step one, configure and install the Linux kernel. Step two, configure and install uClibc, step three configure and install BusyBox. Step four, setup the bootloader (depends on architecture). Step five, reboot into a working system...

What I would do is compile a stripped down kernel, use busybox for most system apps, and have your init scripts call the tinyX server and then instead of using a window manager have the startx script start galeon in full screen mode using tabs instead of separate windows for popups. The only difficult part may be getting mozilla or galeon compiled because of the gtk requirements) You could try the Xlib mozilla port perhaps.

For a little bit of info on how I have done a similar project take a look at my linux on a floppy page.

I was going to ask the same questions.

Particularly, is there anything in these ancient sources that the GNU tools have overlooked? Or have they succeeded in their earlier goal of superseding the original UNIX utilities?

Second, if the focus was on 16 bit computers, then is there anything in these sources that could be helpful on smaller processors of the current age, namely embedded applications where power requirements take us back a few generations.

Busybox is popular among the embedded crowd - does this old code have anything in it for BusyBox to learn from?