AJ's categorization has some traction, but I think it's a somewhat short-term perspective. Just because a full Debian doesn't usually fit today's embedded footprint doesn't mean it won't fit tomorrow's, and in the meantime Debian's toolchain, kernel, and initrd-tools are probably the best embedded Linux development and packaging environment going. Doubly so if you respect the spirit of open source development and feel obliged to enable end users to reproduce firmware after a source-level change.
I think Sarge on ARM has the potential to greatly reduce the learning curve for some kinds of embedded development, especially if Iyonix succeeds in its niche (long live the Acorn!). In particular I look forward to being able to woo certain mobile computing colleagues, currently doomed to PocketPC, with a proper native development environment. The same goes for some apparent "doorstop" arches: mipsel in networking and storage (e. g., SoC from Broadcom in set-tops, wireless gateways, and micro-NAS) and m68k in device control (68332 peripheral support, anyone?). On the other hand, enterprise sparc boxes with niceties like hot-swap PCI make lovely debian targets, and sparc64 may prove as practical on the high end as p(ower)?pc64 or even amd64. And these big girls haven't lost touch with their little sisters. In the etch time frame, sparc32 looks to me mostly like an embedded architecture (sparc-based CompactPCI boards remain in use in industrial automation) and powerpc (ppc32) isn't far behind. On present trends, i386 (amd32 :) ) will be a doorstop/embedded arch for etch+1 at the latest. That leaves mips (big-endian), hppa, alpha, and s390. Not so much doorstops as space heaters; some people might put ia64 in this category too. To my mind, they remain interesting because they cover more parameter space in terms of instruction set design, cache architecture, and relative speeds and sizes of CPU/memory/interconnect. When something close to a common kernel source base works adequately on all of them, it starts to look production-ready. Likewise, minority-architecture autobuilders are one reason why Debian is really the only organization I trust to QA a toolchain any more. For instance, compiling KDE for all of them expands the C++ stress test in a really useful way. Even better if at least a couple of people actually run big globs of GUI on their kotatsu and catch run-time problems like #292673 (grave glibc bug, spotted with evolution on ia64). Although sarge's long cycle has been frustrating for many people, if you ask me it's just as well that Debian never put the label "stable" on kernel 2.6.<7 (i. e., pre-objrmap), gcc 3.<2.3+ (not just C++, but nagging C and optimizer problems, often exposed by non-i386 kernels, in all previous 3.x), or glibc 2.3.(before next week or so, given #292673). By comparison, the next year's core changes are likely to be much more incremental in nature, with a few exceptions we can already see coming (UTF-8 everywhere, the rest of FLOSS Java in main, Perl 6 :-) ) and one big asterisk (biarch, aka dpkg 2 (c: ). None of that says that the world has a right to put the burden of sysadmining the broadest single software QA effort in history on the Debian release team's shoulders. But if specific technical problems can be identified and addressed to where the infrastructure equipment and teams can stand it, keeping Debian Universal for at least one more cycle would be Herculean but not impossible. I think this is one of those cases where the last 20% of the effort invested (coaxing along minority architectures) provides 80% of the value (stable actually means something). Or look at it this way: supporting minority architectures has revealed all sorts of scalability problems in Debian. Some of those problems will be really nasty if we wait until the major architectures are in crisis to face them. The doorstops are the canaries in the coal mine that start to suffocate before the big guys notice air quality problems. Don't like performing CPR on canaries? Don't put 'em down in coal mines! Wait, there's something wrong with that logic ... Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]