Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Ben Hutchings <ben@decadent.org.uk> [120820 20:21]:
> I don't think we should expect other developers to spend any large
> amount of time to help with our own pet projects, except in so far as
> they benefit 'our users and the free software community', which I take
> to mean collective interests (i.e. numbers matter). Right now, most
> package maintainers can provide more benefit to more users by working
> on bugs that affect x86, than by spending that same time investigating
> even the most serious problems on some other architecture. Of course
> they should not stand in the way of porters and should be ready to
> answer questions and apply reasonable patches.
While I agree with the first part (people doing their pet stuff should
not distract others), I see the roles afterwards differently, though:
Most software working only on x86 is simply some pet project, with code
so broken that any newer compiler version will likely break it[1]. And
it is porters that waste their time fixing bugs in toy software, most of
the time having to cope with code so broken it is a miracle it worked
even on any compiler version on x86[2].
There is some minor number of port specific issues (though they are
of course quite frustrating as one as maintainer of a package can
do little in this case), but in my experience the numbers are similar
as with alleged bugs of compiler misoptimising code: in over 95% of
cases it is a bug in the program instead.
More often than not a serious bug in another architecture is just
a case of a serious bug that does not yet show up on the more common
architectures or only very seldom, but lurking in the dark, waiting
till it can also hit your "more users" later if ignored now.
Bernhard R. Link
[1] As a C program can give very little information, almost all
optimisations involve some step of "the rules forbid this behavior
as it would not work on some obscure architecture, so I can assume
that behavior is not the intended, so I can optimize for the other
case".
[2] Well, it's not really a miracle, but observation bias: Only that
buggy code that 'luckily' did not cause breakage on previous compiler
versions on x86 (or on sparc if you look at 15 years old code)
has survived testing by the original authors, so you only meet those,
unlikely as they are.
Reply to: