Embedded Gentoo?

An anonymous reader writes "Gentoo Linux may soon begin showing up in consumer gadgets, thanks to a new project creating an embedded version of Gentoo Linux. The year-old project has achieved preliminary releases on x86, MIPS, PPC, and ARM. The releases include native core system binaries, along with toolchains for native or cross-platform compiling. Native compiling, eh... considering it's Gentoo, how long would X take to compile on an iPAQ? :-)"

Coral link

[Anonymous Coward]

Coral link here [nyud.net]

disspelling gentoo myths

[Chuck Bucket]

Using Gentoo ebedded makes total sense, since you can customize it during install to be as big or small as you want.

as for the compiling joke, it's pretty old, and partially untrue if you use binaries during emerge (much like FreeBSD's pkg_add). Nonetheless, please read Dispelling the myths of Gentoo Linux, an honest review [lxer.com], and learn before you flame. After that, go on using whatever Linux distro you prefer.

CB

Re:This post

[$n1per]

Gentoo is actually fairly fast to install if you don't do the install from stage1(scratch) a stage3 install can be done in 5minutes.

Re:So why is Gentoo the right choice for this?

[PeterPumpkin]

Perhaps this reasoning doesn't apply to embedded applications, but Gentoo would be a good choice for other architectures in general. How many program projects that you know of offer linux-ppc or linux-mips or linux-arm binaries? Gentoo supports these.

Re:So why is Gentoo the right choice for this?

[qshapadooy]

Let's see, Debian - Ports [debian.org]

• i386
• m68k
• sparc
• alpha
• powerpc
• arm
• mips
• hppa
• ia64
• s390

Yes, I think that will do for now.

Re:So why is Gentoo the right choice for this?

[wolf31o2]

Why Gentoo?

Well, that is pretty easy. For one, we're not charging people for it, which puts us ahead of a ton of the competition right out of the gate. The second is that using portage to build your system, you are capable of building in exactly what you want.

If you're not familiar with the embedded arena, then you should probably know that pretty much every embedded project is done from source. There simply is not enough overlap between individual projects to allow for a "precompiled" solution to really be effective.

I really am not the best person to comment here, as the guys working on the embedded project are definitely the experts, but these are the few things that I have picked up just from reading around.

Flexibility (for the vendor)

[temojen]

It's very flexible for the vendor, and easy to up-date. I can't imagine wanting to include gcc, portage, etc on an embedded device, but it would give the vendor a good development environment, and an easy way to comply with GPL requirements (by having an rsync portage mirror available). It'd also give embedded device customizers a standardized development environment. A hardware vendor could sell hand-helds to customizers who add barcode scanners/rfid readers/whatever, and their own software, then sell them to businesses (whatever their niche is).

Re:So why is Gentoo the right choice for this?

[Mr.Ned]

Two thoughts in reponse to your post:

Debian provides more platforms than Gentoo.

NetBSD runs on many, many more platforms than any Linux does.

Re:This post

[Gherald]

> Many people want Gentoo for the portage system and not nessesarly for the
> advantages of running the most super optimized kernel possible.

Bleh, for the upteenth time:

1) Completing stage3 (whether by unpacking a stage3 tarball or bootstraping plus "emerge system" from previous stages) will net you the base system which is, well, basically complete with all the required system packages FOR WHICH THERE IS NOT CHOICE. Gentoo, is all about choice, so there's still a few things you need to add: your choce of a system logger, cron daemon, and your own customized kernel. There is a utility called "genkernel" which will set you up with a generic kernel, but in most cases this is Considered Harmful. So most users who start from stage3 should still end up with a fairly "super optimized kernel"

and in response to some of the grandparent posters:

2) Installing from a stage earlier than stage3 is ONLY advisable if:
a) No reasonably optimized stage3 tarball is available for your particular subarchitecture (unlikely)
--OR--
b) The default CFLAGS="-O2" optimization is insufficient for your taste.

3) Realize that even if the stage3 tarballs aren't exactly what you're looking for, they are most likely still close enough that it makes sense to use them to avoid a lengthy install. Bootstraps can fail pretty easily -- even "emerge system" has it's quirks. And in the long run, once your system is up and running, future "emerge -uD world" updates will gradually replace those horribly unoptimized pre-built stage3 packages you've had to endure... (ha!)

Re:So why is Gentoo the right choice for this?

[ViolentGreen]

Well it's not just the compilation. It's the USE flags. I would assume that the standard version of XMMS (compiled with the Gnome and KDE support) will be a larger file size and use less memory than XMMS compiled without that support. That was my point. If there are precompiled packages specifically for your handheld, you may be better off going with those. If there aren't, I think compiling your own via gentoo would produce better results than just getting a standard version off of sourceforge.

Compiling X on an iPaq

[tgd]

Actually, I suppose it could be ballparked.

When I first started using Linux back in early '93, compiling was about all you could do. (Pre-slackware, Yggdrisil or something was the only distro, I think).

I remember compiling X on my computer, a 486/66DX2 with eight meg of RAM. It took a few days to build. Considering my busted down four year old iPaq is like 166mhz, and has 64 meg of RAM, it'd certainly be doable, probably take a day or so, maybe less.

Re:So why is Gentoo the right choice for this?

[pchan-]

as an embedded systems developer and a gentoo user, i'll tell you that my company certainly will not be putting a gentoo system into our devices. we might look at their kernel if it's good and light. our embedded linux is not much more than a kernel and busybox.

BUT... if you hack up some device and install linux on it, it has huge advantages. you don't have to use some guy's Linux-4-XYZdevice distribution, which might be a mess, never maintained, and poorly supported. you don't have to go hunting for applications that will run on your arch, mess with build scripts to make it build right, and get the patches that will make things run on this processor and with your devices. if you installed linux on your device from 2 years ago that everyone forgot about, you can still have up to date software for it right now. and finally, you have a working ifrastructure of bug reporting and fixing, and a good way to communicate with people doing similar things as you (even if the devices they use are different).

Re:So why is Gentoo the right choice for this?

[Lumpy]

why? because they are automating a HUGE amount of work in creating an embedded linux install.. MOST embedded linux systems have their os rolled by hand. you need to fight to get perl to compile with uclibc, good luck getting python cross compiling without rewriting the makefile system by hand, and many other items that embedded engineers fight with daily. Gentoo is making that task insanely simple.

I have a 9cm by 11cm board that uses a cirrus logic ep9301 processor at 200mhz and draws 9 watts with usb, ethernet, 2 serial 1 rs485, parallel and a CF slot I have 16 meg of flash on board with 64 meg of ram. this thing is a powerhouse in the embedded world and linux is a perfect fit for it. I am designing a home automation system around the device so python or perl will make programming it after the fact much easier.

I can not wait to dig into embedded gentoo.. espically cince it is based on uclibc... a mistake that all other embedded distros make is NOT basing on uclibc.

Re:why are they using Linux anyway?

[horeton]

The point is we already took our src and gave it back to the community. We submitted our patches to uClibc, and gentoo-embedded continues the original development done on i386 soekris boards to other architectures. Gentoo-embedded involves other embedded developers contributing to a build enviroment that you can build any opensrc software in from scratch as long as their is an ebuild in portage. Only factors really are space and device architecture. It also stores all your bins in ipkg format I might add...
Also for the foo's talking about compiling on the device. You could do that if you could nfsmount your chroot build enviroment and were an idiot, or you could just build your devices image in the build-root enviroment using you nice desktop then move the image to the device like a normal person.

The original Gentoo Embedded became Zynot.

[Anonymous Coward]

The current Gentoo Embedded project was started after an earlier effort was forked into Zynot [zynot.org].

Re:So why is Gentoo the right choice for this?

[ad0gg]

When you work with WinCE, you get the source code from microsoft to customize to your product. I don't know of any precompiled solutions in the embedded OS market.

Re:So why is Gentoo the right choice for this?

[zbyte64]

Many people make jokes about gentoo and the whole compiling issue. But I myself have used gentoo on servers and there is a significant amount of performance to be gained.

One thing to consider, gentoo does have the capaibility to install from binary packages. I think this system here would simply compile once, and distribute the binary packages so others don't have to compile

Gentoo also only installs what you want (typically anyways), and on an embedded device with limited resources, that is important. I can't tell you how many times other distros automatically installed some package i didn't want, or favored kde over gnome, or vise versa.

I know im going to be called a ricer after this, but Im not. Me and my friends run a multiplayer web based game, and trust me, optimization flags do count. Granted i don't sit around for 5 hours testing every single flag. I typically set the march, -O3 or -O2, and the frame pointer one. I've seen the results first hand, Gentoo itself is not rice - but other people make it into rice.

Re:So why is Gentoo the right choice for this?

[lxt518052]

Gentoo may not support as many platforms as Debian, but did you know Gentoo was the first distro to fully support AMD64?

Debian claims to be the Universal Operating System. No wonder it supports so many platforms. And it has existed long before Gentoo came into being. Debian also has maturer community and larger user base. Some debian-based distros like Knoppix and Ubuntu are at least as successful as Gentoo. It is kinda like comparing the programming skill of a veteran programmer to a new kid that only programmed in Java, and blaming him for not mastering C++.

Having said that, I believe Gentoo has the potential to match Debian to say the least. Features aside, Gentoo updates faster than Debian. 4 releases in a year is really something. While Woody was released on 19th of July, 2002, next Debian stable Sarge won't be available until next September. It's 3 years in between Debian's two stable releases. It is just a bit too slow to me.

I know Debian's stable is _REALLY_ stable and no Gentoo release can match that. But stability isn't why one uses Gentoo. Others may have their own reasons, I use it because it's much easier to try out things on it.

Just my 2 pence. :)

Re:So why is Gentoo the right choice for this?

[Anonymous Coward]

only a complete and total moron would use apache in an embedded application. . using thttpd is a better choice all the way around.

there are gobs of things that are available for embedded that outperform the monster apps in use on full blown servers. thttpd can survivew a slashdotting on a P-1 233 while an apache machine that is a dual xeon 2.4 ghz will be a smoldering heap...

why? lack of features that bloat the app, speed and a simple thing called built in throttling.

I'm with lumpy on this one.. embedded gentoo is going to absolutely rock.

Oh and who compiles on the target platform?? absolutely everyone I know compiles on the workstation and then simply moves the binary to the target...

Re:So why is Gentoo the right choice for this?

[pchan-]

well, let's not underestimate the statement "it doesn't take much space". if you've ever had to remove print statements from your code to make it fit in the memory, you'll know that kilobyte of space weighs heavily upon the mind of the embedded programmer.

busybox is a terrible user experience, i agree. but it is generally not there to be used by the user. it's mostly to run scripts, do shell executes, and because unix programs are not happy if there is no /bin/sh. generally, you're going to want to statically link your binaries, and generally you'll be using uclibc for smaller code. the problem is, once you start having too many binaries, the advantages of static linking start to disappear now you have a dozen binaries (sh, ls, rm, ...), that all have duplicate code statically linked, eating up your file cache ram and non-volatile storage. if you only have 2MB of ram, you're going to be thinking twice about your memory consumption at this point. with busybox, you can run a dozen binaries, and they all share the same single executable image in the memory, and you don't waste ram on a dozen versions of printf() or the time to load each one from a potentially slow storage medium.

second, there are so many external dependencies, even with the most basic programs. "ls" depends on locale information in some libc helper library somewhere, terminal size, colors, .... i don't need support for fancy sorting order, i just need ls. busybox gives you very basic versions of all of these utilities (no tab completion in the shell, no color in ls, etc). this means speed and memory! besides, have you *seen* the code in some of these apps? good luck fixing bash2 if you find it broken on your system.

finally, it's a management issue. you don't have to worry about your binaries, they're all in the same place. if you need to re-make everything because you changed something, it's only one application to worry about.