Re: A few observations about systemd
* Uoti Urpala <uoti.urpala@pp1.inet.fi> [110721 19:19]:
> First, as I already explained in earlier mails, it's wrong to think of only very
> visible features like a separate kernel as counting for excluding/including the
> people affected. There are _hundreds_ of other possible features/fixes with
> corresponding groups of people as large as potential kFreeBSD users. It's
> impossible to support them all.
There are hundreds of groups as that. But if you exclude any of them,
noone is left.
> Second, you're ignoring the negative effects of the decision to support
> something. Saying "the project must support this" does not magically add
Again there is a difference between saying "the project must support
this" and saying "we are not forced to support this, so I do not care
about it".
> features that help someone without hurting anyone. To make a rational decision
> about kFreeBSD support I can consider the likelihood of needing kFreeBSD in the
> future vs the likelihood of encountering some problem on Linux that would have
> been fixed had resources not been diverted to kFreeBSD support, or would never
> have appeared in the first place if not for compromises needed for the sake of
> kFreeBSD support. The latter probability is much higher.
That is your prime mistake here. Over-doing compatibility can have
negative effects, but not looking far enough always causes
short-sightedness leading towards fragile code that is only useable by
the people that wrote it.
> To put it in software development terms: you are advocating feature creep.
Not replacing things with other things supporting much less is feature
creep now?
What you are suggesting in software development terms is a new build
system that only works on the developer's box. While it might look a
little better in the short term, you lose a lot of help from other
people and also in the long run are stuck with something finally
sub-par.
Bernhard R. Link
Reply to: