Slashdot Mirror

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

The vast majority of daily Linux users are using Android, the vast majority of them probably don't even know it's Linux let alone what Linux is, and Android doesn't use GNU utilities in their userland.

GNU is how we got where we are today, so all Linux users owe it a massive debt of gratitude for getting us here. Desktop Linux users, in the main part, still owe it thanks daily, but desktop Linux users are a tiny minority — both of Linux users, and of desktop users.

All the so-called "Linux" distributions are really distributions of GNU/Linux.

If you want to be pedantic, be fully pedantic. Not all of them are GNU/Linux distributions. For example, Alpine Linux. There is also a list of other Linux-based products which don't use the GNU userland on the Busybox site. There have even been a couple of attempts to wed a BSD userland to a Linux kernel, but none of them appear to still be around AFAICT. Seems like they should take the Solaris 2 approach of adding a BSD userland directory into their distribution for people who need it for scripts, or just want to use it to be perverse.

ArgoUML

ArgoUML is the leading open source UML modeling tool and includes support for all standard UML 1.4 diagrams. It runs on any Java platform and is available in ten languages. See the feature list for more details.

Bongo

The Bongo Project is creating fun and simple mail, calendaring and contacts software: on top of a standards-based server stack; we're innovating fresh and interesting web user interfaces for managing personal communications. Bongo is providing an entirely free software solution which is less concerned with the corporate mail scenario and much more focused on how people want to organize their lives.

Boost

Boost provides free peer-reviewed portable C++ source libraries.

Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use.

Boost aims to establish “existing practice” and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2.

Bro Network Security Monitor

Bro provides a comprehensive platform for network traffic analysis, with a particular focus on semantic security monitoring at scale. While often compared to classic intrusion detection/prevention systems, Bro takes a quite different approach by providing users with a flexible framework that facilitates customized, in-depth monitoring far beyond the capabilities of traditional systems. With initial versions in operational deployment during the mid '90s already, Bro finds itself grounded in more than 20 years of research.

Buildbot

Buildbot is a freely-licensed framework which enables software developers to automate software build, test, and release processes for their software projects. First released in 2003, Buildbot is used by leading software projects around the world to automate all aspects of their software development cycle.

BusyBox

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

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 some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

Clojars

Clojars is a community-maintained repository for free and open source libraries written in the Clojure programming language. Clojars emphasizes ease of use, publishing library packages that are simple to use with build automation tools.

coreboot

coreboot is an extended firmware platform that delivers light

is not "a pared-down version of the Linux operating system"

It is often USED as PART of a pared-down Linux install, but is not itself a version of Linux.

https://www.busybox.net/about....

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc.

For example I think the Linux (POSIX?) file system was written before they invented autocomplete, it's all TLAs like /var/usr/bin/lib/wtf.

In this case it's the file system hierarchy, not the file system. Personally, I think the argument for longer filenames is bogus. Using longer filenames isn't necessarily going to make their purpose any more clear, and for everything outside of the home folder, the novice user should probably not be touching that stuff, any more than they should be poking around in C:\Windows. Being user friendly is not a feature for things that are not intended for casual use. Autocomplete is an even worse argument: I'm not saving any keystrokes by typing /bi[TAB] versus /bin.

However, your example was somewhat poorly chosen in another sense, because while there is no call to make the names longer, at least one major distribution got rid of some of those top-level folders. Fedora likes to move fast and break things anyway, but in this case the historical justification for splitting up the binaries was, well, kind of ridiculous. Thompson and Ritchie created that particular issue a couple years before CP/M inflicted drive letters on us, but forty years later it's still a bug worth fixing. Most of today's code and systems will be pretty hoary in forty years, and I'm not sure I would consider it a virtue if it ran unmodified on my...hmm, well, whatever system exists at that time. One can always use emulation to provide old features, but most of the time I'd rather that not be happening at the OS level.

Given that Windows inherited both 8.3 filenames and drive letters from CP/M, it makes sense to talk about them in the same context. Drive letters are pretty harmless, but having "secret" 8.3 filenames and unremovable folders is probably something that needs to go. Linux definitely doesn't have those kind of problems.

So why not encrypt the whole disk at that point? Having a separate /usr is only a thing because Ken Thompson and Dennis Ritchie ran out of disk space.

Also, as the GP said, it's not systemd that has the issue.

I just checked https://busybox.net/license.ht...: it seems that BusyBox is still GPLv2.

Don't rewrite the history because you are ignorant. Busybox was from the start a project targeted for Linux, and more precisely for the Debian installer. BSD compatibility was added a decade later if I remember correctly. And Busyboy will probably dead if he remove this: http://git.busybox.net/busybox...

It does not help in discussions if you throw around inaccurate disparaging comments about things you criticize.

What exactly is "good engineering"? I bet finding a consensus on that one won't be easy. So, while you and me feel that systemd isn't well engineered, there will be people (its authors, for one) who honestly believe it is.

If you will talk to people about it, you need to carefully, with well-thought-out arguments, explain *why exactly* it is badly engineered.

Here's something interesting:
the person who commit that patch to remove systemd was also the first person to merge a systemd patch into BusyBox.

http://git.busybox.net/busybox... works for me. Tim S.

In retrospect these bugs look so simple and stupid to casual observers, but programmers know that simplistic hindsight shoulda-woulda-coulda analysis such as "oh, it only needed a simple bounds check!" and "you should have removed that goto line while you were working on that code!" only shows a gross lack of understanding of what real-world programming is like. It's easy to forget a simple bounds check; hell, it's a miracle a programmer gets anything done at all with all of the variables and structs and malloc() calls and pointers that have to be memorized. I recently wrote the code for adding undo support for BusyBox vi, and I can tell you firsthand that what seems like a simple thing (store changes, undo them) is a complicated and frustrating process once you start in on it. Even after I made simple undo actions work, the challenges compounded when I added the "intermediate queuing" enhancement to lower the otherwise insane malloc() overhead and improve the overall behavior of my "simplest thing that could possibly work" code.

The process of dissolving a big problem into low-level steps as is required by C programming is mentally brutal. You can't just go "I want to save the text that was deleted and restore it when they hit the undo key." You have to translate that into variables, pointers, structs, mallocs, and glue logic. You have to take into account every corner case; how do you undo multiple lines of pasted text instead of single characters? How do you store undo information a paste-over operation, where you must keep a record of what was deleted but also record that it overwrites a (possibly different length) chunk of the text buffer? How do you store the undo data for find-and-replace operations? Now that you've managed to figure out ways to store all these different types of text editing operations for undoing, how do you actually undo each one? Where does all this stuff need to hook into the existing program, and how will you hook it in without breaking existing functionality?

It's so easy to forget trivially simple things when you're trying to flow your mind through that complex glue logic that makes the magic happen, especially when you make a change, it appears to work, and you have no way to test for the bug you created by accidental error or omission.

The Chinese have been using Busybox for years. I still have two routers that use Busybox - the Swiss Army Knife of embedded Linux.

linky.

Linux can be configured to run in 2MB of RAM and 2MB of flash or less. It can run in 4MB RAM with a full network stack, busybox, and several hundred K remaining for apps.

There is no other full featured free unix like kernel which can do that. Certainly none of the free BSDs.

I'll take the bait. Care to show a reference to running a modern Linux kernel w/ 2 MB RAM, or 4 MB RAM with busybox, on i386 or ARM? Busybox can do wonders for storage requirements (e.g. for NAND FLASH), but it doesn't help with RAM at all! I found 8 MB to be difficult enough (!), last I tried ulibc and busybox on i386.

Just as a point of discussion, generic NetBSD is smaller than generic Linux (e.g. Debian) on the ARM platforms I've been using. A line from top shows the latest (NetBSD 5.1.2) kernel RAM footprint on ARM9: about 1.2 MB, with numerous filesystems, NFS, networking, USB support, etc. built in. This includes all kernel modules.

    PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
        0 root 125 0 0K 1240K schedule 0:00 0.00% 0.00% [system]

Running 1 instance of httpd, sshd, and two user processes, minus 1.5 MB of buffers/cache, it's using 5.5 MB of RAM right now. Tightened up, it might boot in 4 MB but I haven't tried. Do note that this is with the standard (Net)BSD libc, all completely generic, 'out-of-the-box'.

Amazing work has been done to cram Linux into small places, but I think it's somewhat disingenuous to say that no BSD is close. I'd say NetBSD provides a rather interesting starting point.

Powershell is a powerful CLI, but I can write useful pipelines with busybox faster.

http://busybox.net/downloads/BusyBox.html#commands

Try running bash without grep and awk some time. bash is smaller because it calls other programs.

What are the odds those packages will be missing? They're small enough (236K for sed, 264K for grep, 924K for gawk, and 3504K for coreutils, which contains things like head, tail, sort, and uniq) that the only reason you'd leave them out is if you're really crunched for space and intend to use something like BusyBox instead...oh, wait, looks like even BusyBox includes cut-down versions of grep, sed, awk, etc. BusyBox doesn't include a cut-down version of Perl, though.

That doesn't seam to be true.

http://stackoverflow.com/questions/1580923/how-can-i-use-linuxs-splice-function-to-copy-a-file-to-another-file

This is something I was wondering. As I understand it splice/sendpage just marks a page belonging to a block of one filesystem as a page of a block of another filesystem. Thus no memory copying, the same RAM the data was read from one disc is used to write that data to another disc. So I think markhahn has a point, the problem is userspace, not the kernel. The cp code could be faster if it used splice/sendpage zero copy stuff (when dealing with filesystems that it is possible to do so (i.e non-FUSE)).

BusyBox certainly doesn't http://git.busybox.net/busybox/tree/libbb/copyfd.c

Why would you have to pay any fees for distributing GPL licensed software? All you have to do is provide the source code of your derivation. If you haven't modified the software, even an acknowledging link to http://www.busybox.net/ is more than enough.

I was interested in the bit about busybox (namely, wondering why they wouldn't include such useful and dead-simple flags like -f), and the first page I discovered (http://www.busybox.net/downloads/BusyBox.html) listed the following for cp:

cp

cp [OPTIONS] SOURCE DEST

Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY

Options:
-a Same as -dpR
-d,-P Preserve links
-H,-L Dereference all symlinks (default)
-p Preserve file attributes if possible
-f Force overwrite
-i Prompt before overwrite
-R,-r Recurse
-l,-s Create (sym)links

Which leads to another interesting point. Put all your standard linux system binaries in the same exe and they can share all that boilerplate startup and runtime library code.

Maybe you are right... though it seemed he did a pretty thorough analysis during the GPLv2 vs v3 flamefest ...
http://busybox.net/~landley/forensics.txt

Except that http://busybox.net/downloads contains every busybox release in the last 10 years...

A tarball is a tarball, and if the tar is identical and the link is valid, then why isn't that sufficient? If the site goes down or the tar is removed, then I suppose they'd have an issue, but it shouldn't be any different from their own server going down and having to find a solution.

From the GPL FAQ:

Can I put the binaries on my Internet server and put the source on a different Internet site?
Yes. Section 6(d) allows this. However, you must provide clear instructions people can follow to obtain the source, and you must take care to make sure that the source remains available for as long as you distribute the object code.

Sounds like as long as the source is available on "a different Internet site", it's ok. If it goes down, they need an alternate arrangement...

Unless linking people to http://busybox.net/ can be proven to meet the requirements of "making available" I'd avoid using busybox for anything I plan to distribute. Hopefully they're not just suing for mirrors, asking would be less effort ;)

It appears Erik Andersen is responsible for a large amount of rewritten core apps in BusyBox:

http://git.busybox.net/busybox/tree/AUTHORS

Sounds to me what you really want is something like a busybox based system.

I saw this article on OSnews this morning, and it inspired me to write a tiny open-source (public domain) *NIX shell, which can be seen at http://www.samiam.org/software/yash.html. I know the busybox guys are looking to rewrite their *NIX shell to be more modular; this code would be a good starting point.

- Sam

There seem to be a few BSD tools with the aim of building smaller collections of binaries in a similar fashion to BusyBox.

You've mentioned crunchgen but there is also embutils (which can be smaller than busy box but requires dietlibc) and there also seems to be something called beastiebox (which allows different amounts of linking). Finally there is Cauldron which seems to be a collection of tools for creating embedded BSD environments.

A couple of things that have changed, from the top of my head:

  - Those old machines had an OS dedicated to support exactly the hardware that was shipped. OTOH, Linux distros are usually generic, and detect hardware on boot.

  - There's a huge difference between a BASIC interpreter and a full-fledged multi-user OS with networking, GUI, etc.

  - PC hardware spends a lot of time during boot before actually handing control to the software. Server hardware is often a lot worse.

  - The code involved in booting those old machines was probably written by Real Programmers, who knew the ins and outs of the hardware they were programming for. It's probably horrible to maintain, but ridiculously fast. By contrast, most of the code involved in booting your Linux distro is written in a variety of languages, by a whole lot of people, few of whom are Real Programmers, and it's probably optimized for genericity and maintainability, rather than efficiency.

Having said all that, you _can_ boot Linux ridiculously fast. I used to have a 486 where the boot process basically consisted of (1) POST (2) Load GRUB (3) Load kernel (4) Run init (5) Run login. Pretty much a normal boot process. What was special about it is that the kernel had all required modules compiled in, and nothing else. init (IIRC) only spawned a single tty and ran login. And both init and login were BusyBox statically linked against dietlibc. From GRUB to login prompt took less than 5 seconds, IIRC. You could further improve on this by foregoing the BIOS in favor of something like coreboot.

You could go with a straight BusyBox, or add a slightly more robust text editor to the enviornment.
Then compile that into your initramfs, and just don't bother to do a switch_root to a real file system. As long as you've got the hardware and filesystem drivers compiled into the kernel, life is good.
See http://www.linuxfromscratch.org/ for more details.
This use-case is one where I would not recommend emacs.

Since the article does mention Busy Box, I'll explain a little of what I know about it.

Busy Box is a collection of many common Unix shell utilities (sed, ln, ls, etc.). Each package has been scaled down in size and combined into one binary, BusyBox. BusyBox is often used on embedded Linux devices and distros, such as the Sharp Zaurus and the Linux Distro pdaXrom.

See the BusyBox About Page and the BusyBox FAQ for more information.

Since the article does mention Busy Box, I'll explain a little of what I know about it.

Busy Box is a collection of many common Unix shell utilities (sed, ln, ls, etc.). Each package has been scaled down in size and combined into one binary, BusyBox. BusyBox is often used on embedded Linux devices and distros, such as the Sharp Zaurus and the Linux Distro pdaXrom.

See the BusyBox About Page and the BusyBox FAQ for more information.

However, for future clarity, I might ask you to review the rules for use of their (possessive implicit pronoun, i.e., "It is their software,") there (indicating location, "The authors put it there,") and they're (conjunction of "they are," "They're going to enforce Copyleft over the work.") Yes, I am the Grammar Police and get paid very well as a result.

As the parent says, only the copyright holder can actually take any legal action.

For busybox, you can see on http://busybox.net/license.html that:

"BusyBox's copyrights are enforced by the Software Freedom Law Center (you can contact them at gpl@busybox.net)"

This an effective process, but a slow one (expect it to take 6 months+ for any response on past experience).

For the linux kernel, lkml is perhaps an appropriate place.

FSF can't help, since they don't own any of the software.

You perhaps want to consider how you're wording your requests. If a polite (or impolite) request for source code has been refused, you might want to try a different track, pointing out that the hardware contains software that they have no valid license to distribute and is hence illegal, and would they like to discuss this further before you contact the copyright owner.

Under copyright law, there is absolutely no requirement for them to provide the source code. One possible legal conclusion is that they pay court decided damages to the copyright owners for illegal distribution to date, and cease further distribution. If they wish to continue distribution, it's likely that they're only available option is to open the source code, especially since their are often multiple copyright holders, especially in the linux kernel.

(Disclaimer, I'm not a lawyer, and some points will vary between jurisdictions.)

You could notify the authors (and copyright holders) of BusyBox.

Unlike Linus, they are pretty strict on companies infringing on the GPL, and have sued (and won) several times.

Take a look at gpl-violations.org or google "busybox gpl violation" for more information.

Let's have multiple forks of glibc then!

You mean like uClibc, klibc, dietlibc, etc?

And the kernel!

You mean like all those various kernel patches people use? Or maybe the BSDs vs Darwin vs Linux vs Solaris?

and coreutils!

You mean like BusyBox?

A foolish consistency is the hobgoblin of little minds.

For the EPIA-MII VIA supply a "fastboot" BIOS, there are seperate BIOS images depending on what device you want to boot off. Using their BIOS along with a compact flash->IDE adapter and a little kernel optimisation you can have a command prompt in around 4 seconds from power on. My aim was to have the system in a gui (using DirectFB) in under 10 seconds but at present I'm looking at around 6-7.

The system was using grub, a custom built kernel and Busybox.

http://www.busybox.net/

He made the kernel, at the very least you generally need the GNU tool chain to have something usable, plus a couple of other little things.

The term "GNU toolchain" usually refers to their compiler stack (gcc, as, make, autoconf, etc.) rather than their regular userland tools, aka coreutils (ls, cp, du, stty, su, etc.), or other stuff that are more than just "little things", like init and sh. I usually wouldn't nitpick, but you seem way too sure of what you're talking about.

And yes, I believe the original discussion centered on Linus's credentials as kernel author and made no claim that he wrote coreutils or anything else. Writing a functional coreutils isn't that amazing of an achievement, actually - take a look at BusyBox, a single binary that does all the useful coreutils plus (working imitations of) init, sh, insmod, ifconfig, dpkg, wget, etc., so that, "To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel." Notably, you need nothing from the GNU project, just the two binaries (Linux and busybox).

I recommend Gumstix for beginners.
It uses U-Boot and the whole uClibc BusyBox Buildroot stack for development.
It is rather slick to work with. They even added support for the rt patch not too long ago which was a big bonus for me.
I've been working with it for about a year now and I have to say it's really the best solution for embedded Linux beginners.

On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager.

You don't *technically* need anything else, but for development it can be IMMENSELY useful to have a shell and a base set of utils. Busybox will get you everything you need in a multicall binary under 1MB (dynamically linked to glibc).

Things can be even smaller using uclibc instead of glibc, but unless you are building an EXTREMELY low end embedded device and can't spare an extra 1-2MB or so (or 1/2 that with a compressed filesystem like cramfs) it may not be worth the extra hassle trying to build a uclibc toolchain (and potentially deal with uclibc issues with other utils/libs you may use).

Anyway, the nice thing about Busybox is that you port a single package and get huge range of utils. Overall I agree 100% with a previous poster who said the key to rolling your own OS is getting the toolchain working - once you have that, porting is relatively easy (I'm assuming we're talking about non-x86 embedded systems here... with x86 it becomes easier still, as the vast majority of open source development is done on that architecture).

Maybe there are other free PXE "Pre-OS"es?

Well, you can use PXELinux (part of the whole SysLinux thing) to boot a kernel with a RAM disk (initrd), and run whatever you want from there. You will need a basic live distribution to go in the RAM disk, which contains init, libc.so, sh and whatever other bits you need. You can keep the size down by using busybox. Creating a working initrd can be a little hairy, as your compile-time paths are normally different than the runtime ones, which can break some programs without a little hacking. The initrd itself is a gzip'd cpio archive. You then have to set up a TFTP server for serving PXELinux; if you want to automate things, you can have your DHCP server tell PXE-capable clients to boot PXELinux from your TFTP server.

If you are in the market for a commercial solution, with centralised management and all the trimmings, you should get NetInstall v6 from enteo software with OSD (OS deployment); this includes TrueImage. It costs money, but it works very well. It's a primarily PC/Windows solution, however, so imaging to/from a Mac may well not work.

-- Steve

I reluctantly got into vi back in the early 1990s, after being spoilt by the wonderful text editors available on VAX/VMS. Then I promptly forgot all about it -- never even had a fling with ELVIS on MS-DOS -- until discovering Linux sometime in 1999 or 2000. My favourite console editor used to be AEE; then I discovered pine, and hence pico. Now I can't live without nano. There's even a vi command built into BusyBox.

Much of the operating system (meaning the kernel plus system utilities) is GNU software, many of which existed as mature software well before the Linux kernel came about

The kernel is GPL software, but there is no GNU software in it as far as I know. And there are Linux systems where the implementation of the UNIX userland system tools do not come from GNU either, for example the case of embedded systems using BusyBox.

Since a big problem in the GPLv3 debate covers the actual practices of companies that develop embedded systems, this is really relevant: In embedded systems, size is an important parameter, and the GNU userspace tools are not optimized in that direction. This means that those systems may be Linux systems, but not GNU/Linux systems.

What Stallman calls GNU/Linux is what *some* Linux distributions distribute.

On the embedded side, there are more and more distro which are using replacements for the GNU tookchain and glibc like busybox and uClibc, thus avoiding many of the GNU tools you typically see in a Linux distro.

Stallman's generalization is mostly true, but not always true...

How about busybox, all that and more (http://www.busybox.net/

I bet M$ ignores use cases like this, they assume you have to spend money, or you're out of luck. Well, I value my time too highly to let M$ tell me how to spend my money.

We are happy to use Linux and generate some revenue from it (try to, anyway). We use a monotone install with our added crap on top. We keep a clean separation of what's opensource and need to provide source for... if asked:

• GPL: The linux kernel, Linux drivers we write (the odd USB driver built using the USB skeleton driver), everything in the linux distro.
• Special provision for busybox which are happy to abide by their license. Don't and you'll end-up in their Hall of Shame. Not worth the aggro.
• LGPL: Everything LGPL we need to compile against, is compiled as shared objects. No static linking!
• Closed source... a couple of our daemons which do all the work. This is our code. Maybe we'll open it some day, maybe not.
• Giving back. Revenue so far is not worth talking about, but we contributed bug fixes and enhancements back to the community. Some bits and bobs people could find some use for, we put on sourceforge.

The simple rules of opensource: Abide by the licenses and try to contribute back if you can. Do that and it'll translate into real karma in the next life... and maybe into some profit, one hopes!

We are happy to use Linux and generate some revenue from it (try to, anyway). We use a monotone install with our added crap on top. We keep a clean separation of what's opensource and need to provide source for... if asked:

• GPL: The linux kernel, Linux drivers we write (the odd USB driver built using the USB skeleton driver), everything in the linux distro.
• Special provision for busybox which are happy to abide by their license. Don't and you'll end-up in their Hall of Shame. Not worth the aggro.
• LGPL: Everything LGPL we need to compile against, is compiled as shared objects. No static linking!
• Closed source... a couple of our daemons which do all the work. This is our code. Maybe we'll open it some day, maybe not.
• Giving back. Revenue so far is not worth talking about, but we contributed bug fixes and enhancements back to the community. Some bits and bobs people could find some use for, we put on sourceforge.

The simple rules of opensource: Abide by the licenses and try to contribute back if you can. Do that and it'll translate into real karma in the next life... and maybe into some profit, one hopes!

We are happy to use Linux and generate some revenue from it (try to, anyway). We use a monotone install with our added crap on top. We keep a clean separation of what's opensource and need to provide source for... if asked:

• GPL: The linux kernel, Linux drivers we write (the odd USB driver built using the USB skeleton driver), everything in the linux distro.
• Special provision for busybox which are happy to abide by their license. Don't and you'll end-up in their Hall of Shame. Not worth the aggro.
• LGPL: Everything LGPL we need to compile against, is compiled as shared objects. No static linking!
• Closed source... a couple of our daemons which do all the work. This is our code. Maybe we'll open it some day, maybe not.
• Giving back. Revenue so far is not worth talking about, but we contributed bug fixes and enhancements back to the community. Some bits and bobs people could find some use for, we put on sourceforge.

The simple rules of opensource: Abide by the licenses and try to contribute back if you can. Do that and it'll translate into real karma in the next life... and maybe into some profit, one hopes!

I know this was a joke, but just to pretend I don't get the joke: Actually, on an embedded platform (at least one without a lot of storage), a Linux system is probably going to have very little GNU code. An embedded Linux system is likely to use BusyBox for basic Unix-compatible commands like ls and rm, and something like uClibc or dietlibc for its C library, and won't have things like Emacs or a compiler actually on the system. So it's unlikely to have much actual GNU-project code on it, if any.