Re: Survey answers part 3: systemd is not portable and what this means for our ports
brian m. carlson wrote:
> On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote:
> > If you don't do development, and nobody sharing your views does either,
> > then there's a limit to the extent you can choose your direction just by
> > refusing to follow those that do develop things further. You can't stick
> > with Minix forever even if you think the direction of Linux is
> > undesirable.
>
> My point is that Debian developers create lots of great software, and
> certainly maintain lots of patches to software for which Debian is not
> upstream. But it's simply not feasible for Debian to be the upstream
> for all software.
That's true, but doesn't affect what I said above. If you can't develop
Minix to be competitive then you either have to switch to Linux at some
point or you'll become increasingly obsolete.
> I don't think it's controversial to say that Debian
> developers prefer upstreams that take concerns relevant to Debian and
> its users into account.
Of course. But my point was that when no other upstreams offer
competitive functionality, the friendliness of upstream isn't really
relevant when choosing which program to use. The friendliest possible
Minix maintainer can't make it a good choice over Linux, no matter how
much you despise Torvalds.
In the systemd case most of the "concerns" that upstream has been
accused of "not taking into account" have clearly more been
controversial views of some Debian developers than concerns of its
users. For example, if kFreeBSD died as a result of lacking systemd
support, that would probably be a net win for users.
> > Suppose that in the future systemd does go in a direction you don't
> > like. Now would it have done any good for Debian to not adopt it? Not
> > really, if nobody develops a competitive alternative to its
> > functionality. Not using it would only make Debian obsolete for most use
> > cases. And the most realistic way to create a competitive alternative
> > going in a different direction would be to fork systemd, so adopting
> > current systemd would not make moving to such alternatives harder.
>
> The vast majority of the work I do on a Linux box, desktop, laptop, or
> server, does not involve init in any way. It is therefore not accurate
> to claim that using an init system other than systemd would make Debian
> obsolete.
The init system matters for dynamic behavior like hardware discovery and
network connectivity. It will matter in a lot of typical workflows, and
choice of init system of course affects how easy it is to develop a
distribution overall.
Of course there are lots of tasks that you can still achieve on a
10-year-old machine with 10-year-old software. But even if such a
machine does not become completely unusable, it is clearly obsolete.
> For example, RHEL 6 and Ubuntu use upstart, and I think it's
> hardly accurate, based on their significant adoption, to call them
> obsolete.
And Debian still defaults to sysvinit, yet I wouldn't call it obsolete
yet. But it does already suffer from its init system.
> > > For example, if an upstream expresses disinterest in supporting non-PC
> > > architectures, that may be a bad piece of software for Debian to place
> > > in an important role, even if it currently works on all our
> > > architectures, since Debian is very portable among different
> > > architectures.
> >
> > Of course, this isn't relevant to systemd, as it has no hardware-
> > specific code and supports embedded platforms for which Debian is too
> > bloated.
>
> This was meant as an illustrative example of a common problem with
> upstreams, not as a problem particular to systemd. systemd upstream has
> made a lot of controversial decisions that Debian may or may not want to
> support: combined / and /usr, the journal, logging to the kernel ring
> buffer, lack of portability to non-Linux kernels, and merging udev and
> systemd are a few examples.
I'd say that mainly shows that systemd upstream has managed to develop
things forward. Creating and changing things involves decisions, and
there's no way to make everyone happy. And when old things are changed
there's bound to be a lot of controversy, even if the old stuff was
total crap and new is almost perfect.
I do not believe there would have been any chance to achieve a similar
amount of progress without controversy. The alternative to this kind of
controversy is stagnation, not any magical form of progress with total
consensus.
> If Debian decides that it is preferable for
> whatever reason not to adopt one or more of these decisions, the
> willingness of upstream to accept that decision and work with Debian
> instead of saying, "Too bad, so sad," is something that should be
> considered before making a major change. I'm not saying not to use
> systemd, I'm just suggesting making a well-reasoned decision.
I strongly disagree with the view that being a good upstream should
imply accepting such arbitrary demands from distributions. IMO what a
good upstream should answer to requests to change most of the things you
listed above[1] is "that's a very bad idea, and even if you insist on
it, no upstream resources should be wasted on supporting that". Ideally
upstream should have solutions to practical problems encountered on a
distro. But if you disagree on basic questions of how things should be
done, then you should either formulate a good enough argument to
convince upstream of your views or fork and show that your way works
better. That someone in a distro just "decides something is preferable"
should not directly steer development. Those are not things where Debian
would have any particular competence to make decisions that are better
for users than upstream ones.
[1] Systemd does for example support installing in /lib instead
of /usr/lib, so having them separate still works. That said, I haven't
seen any good argument why Debian should still keep /lib separate
from /usr/lib.
Reply to: