Re: Bits (Nybbles?) from the Vancouver release team meeting
On Fri, Mar 18, 2005 at 03:23:18AM -0800, Michael K. Edwards wrote:
> <small snip> 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. <small snip>
>
> 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?).
>
This is _exactly_ so: I've just had two colleagues get work to buy them
Xscale embedded processor boards - they'd just bought some slower boards
for themselves. The boards come with a cut down version of Debian stable
_BECAUSE OF THE TOOLCHAIN AND CROSS COMPILATION_ and because it all just
works :) One of them now want's testing .iso's.
>
> 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).
>
I don't have an Alpha to run as a desktop any more or a Sparc32 - they
were loan machines from my workplace - when I did, it was insanely easy
to install identical software across the three architectures and have
the same environment, features and ease of administration.
If you have to administer many machines, that familiarity saves man years.
> 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).
>
Red Hat and Novell are putting big money into releasing Enterprise
versions _less often_ and then supporting them for five years or seven
years in order to assure stability. That's the model that Debian has
(inadvertently) had for years. Their targetted release cycle is 18
months - 2 years. IMHO The quantity of software is minimal in these
enterprise distros, testing seems poor and the overall quality variable.
When you need something like a library you're used to in Debian,it's
normally not there and you have to dig round the net for <random RPM site>
and trust to luck. The RHEL point releases are not great - and may change
underlying stuff without telling you. [There is a prerelease of gcc 4 in
RHEL 4 - a snapshot version from 12122004 - I fully expect them to introduce
full gcc4 on one of their point releases _without bumping the version
number_ :( ]
> 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
> ...
Full ACK to the above. I can see where the Vancouver proposals are coming
from but the cut of what's a valid top tier isn't quite right yet.
I'm not sure that ia64, for example, is worth the candle at all - but we
are virtually the only distribution supporting it well. We _are_ the only
distribution supporting hppa - now if we could just get Debian running on
Superdome, I could suggest a replacement for hpux :) Ditto sole major
distribution for mips and sundry others.
I run testing _at work_ on several machines because I need the slightly
more up to date software and relative stability but that's only pending
Sarge release - they'll be stable-locked thereafter. But, in a community of
UNIX programmers, the primary reason I use Debian is because of the breadth
of apps and libraries and because I know I can readily use the whole thing
in a commercial environment (thanks to the DFSG and Social contract).
[All too often, I have to struggle like hell to build <random binary>
on Solaris thereafter because the programmers I support can't live without
it :) ]
Accept that we shoot for a Debian release every eighteen months
and hit every two years +/- - which is roughly the status quo - but that this
is _right_ for an awful lot of people. Don't lose heart - we're doing
well as we are.
Andy
Reply to: