Re: A few observations about systemd
Bernhard R. Link wrote:
> While there might be some problems originating from some architecture,
> but most problems you will see and people claim to be "problems specific
> to fringe architectures" are actual bugs in the program you just do not
> *yet* see on your usual pet architectures. And some more because the
> program is just doing some very narrowing assumptions.
Yes, such bugs do exist. However, I think the benefit of testing on
other architectures to uncover such bugs has been exaggerated. Many of
the problems that end up taking the most time are toolchain issues
specific to the architecture. Typical free software projects already
have multiple known issues that actually affect people even on popular
architectures; ability to find one more thing that's in principle broken
is not particularly valuable. It's mainly the relatively simple projects
or projects with exceptional developer resources (like parts of the
kernel) where ability to find more bugs results in quality improvements
with any kind of consistency. Debugging things on architectures you
don't normally use, often remotely on unfamiliar systems, is likely to
be slow and not have a particularly good results/effort ratio.
Note that I'm not opposing having Debian on multiple hardware
architectures. But that's mainly because I think it doesn't necessarily
require major extra effort, not because I'd consider such hardware
support to be essential.
> Imagine how long amd64 would have taken, if people had not had years
> to fix all those 64 bit bugs on alpha first (Which never really got
> a mainstream architecture and where it was used was quite server-only.
> Who would have guessed that fixing games to run there would have had
> benefits in a so soon future?)
I'm not sure exactly how long more AMD64 support would have taken
without Alpha, but I think it would have become supported reasonably
fast in any case, and likely with substantially less overall effort than
by fixing issues as they come up through Debian Alpha builds. "First
upstream developer of a game gets an AMD64 machine and makes the game
run on it" is just inherently a lot more efficient than "Debian
maintainer forwards reports about game not working on Alpha".
Considering the introduction of AMD64 overall, I think Debian did a
pretty bad job - avoiding the fuck-ups in the introduction of the
architecture in Debian would have helped a lot more than the 64-bit
preparation with Alpha.
If you want to help the development of upstream projects in general,
there's an obvious thing that could use more resources: make sure that
the latest upstream code is always available in Debian unstable (or if
it's likely to cause breakage, at least in experimental), and don't let
the introduction of new upstream versions in unstable stop around
releases. Getting more feedback about changes quickly is a lot more
important than testing on unusual architectures.
Reply to: