Re: Bits (Nybbles?) from the Vancouver release team meeting
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
Reply to: