Re: A few observations about systemd
brian m. carlson <sandals <at> crustytoothpaste.net> writes:
> On Wed, Jul 20, 2011 at 04:36:35PM +0000, Uoti Urpala wrote:
>> I think you're committing exactly the fallacy I described in the part you
>> snipped. You think that "excluding" people who want a particular kernel is
>> significant when it's a "big thing" like a kernel. But _any_ case of not
>> supporting something can be described as "exclusion". Any time a package is
>> dropped, Debian is "excluding" the people who want to use that package. Every
>> time a decision is made not to package something people are being "excluded".
>> When Debian Linux fails to run on a specific submodel X of hardware Y, people
>> who use that hardware are "excluded". Any of those cases can affect a much
>> larger number of people than kFreeBSD support.
>
> I think the difference with excluding a package is that nobody is
> willing or able to do the work. Perhaps the package requires more time
> than the maintainer has, or it's a very difficult package to maintain
> and nobody that wants to is able to.
How's this relevant to what you're replying to? What I was saying was that
there's no rational basis to call dropping kFreeBSD support "exclusion" and
claim that makes it somehow categorically different and worse than dropping
support for any random package. Both should be evaluated on the same scale. Your
reply doesn't seem to address this at all.
> Since you're
> interested in changing the status quo (which init is the default),
> you're obligated to do most of the work to fix whatever breakage occurs.
> This is true for most FLOSS projects, including the Linux kernel, not
> just Debian.
I have personal experience with these kind of issues, and the approach you seem
to favor does not work in practice when the changes are big and resources are
limited. Changing the status quo must be allowed to involve deprecating
something or leaving its handling to the people who personally want to keep the
particular feature.
Compare introducing systemd to introducing libgtk2. libgtk2 was added to the
archive, applications migrated from gtk1 to gtk2, and eventually gtk1 support
was dropped and applications which required it were dropped with it. Suppose
someone brings systemd support to a level where it can be made the default on
Linux. Then daemons migrate to systemd files and eventually sysvinit support is
dropped and ports which still depend on sysvinit are dropped with it. Of course
we'd want to complete the transition faster than the time both gtk1 and gtk2
were available. But I think even dropping Hurd/kFreeBSD immediately would affect
fewer people than dropping gtk1 support did at the point it was done. Why should
users of kFreeBSD be considered more important than the people using gtk1-only
applications?
> But here, the kFreeBSD porters (just like the porters, for say, sparc)
> have done most of the work. Yes, maintainers need to accept patches in
> some cases. But the porters do most of the work because that's what
> interests them or perhaps because their employers need that
> functionality or just because it's fun.
If people who want to support kFreeBSD volunteer to handle everything related to
systemd compatibility then there's of course no problem and no reason to even
consider the issue when talking about whether to adopt systemd or not. If they
implement compatibility wrapper for systemd control files or a BSD port of
systemd itself (NOT patches to add BSD portability to Debian's main systemd
package; that would make it much harder to update to new upstream versions and
would likely cause regressions on Linux) then people can go on developing on
Linux and kFreeBSD will take care of itself. But it doesn't sound like people
are actually volunteering to do that.
> If a package simply cannot be used on kFreeBSD, then ok, that happens.
> Would it be nice if systemd were portable? Yes. But if we assume that
> it's not, then we have to accept that. The question here is whether
> we're effectively willing to make a non-portable package part of
> Essential. The question would be the same if systemd pervasively used
> unaligned accesses or inb/outb or some other non-portable construct.
> Would we jettison sparc and ia64 in favor of it?
I think calling systemd unqualified "nonportable" as opposed to everything else
being "portable" is somewhat misleading. It's not like every other package would
depend on strict standard POSIX functionality only. In this case the non-POSIX
functionality is just something that is not available on BSD.
"Unaligned accesses" sound like they'd indicate issues more likely to cause
problems on Linux too, and might also affect ability to run on any new processor
architecture (though of course then it might be reasonable to assume that
systemd would be fixed if an important new architecture appeared). But assuming
that would somehow not be the case and it would strictly be a question between
benefits of systemd vs benefits of keeping sparc and ia64 ports then that should
be evaluated objectively based on the benefits of either, rather than any
categorical "non-portability bad" answer. I don't want to start discussing here
how _that_ evaluation would go. In the kFreeBSD vs systemd case I consider the
answer to be clear - if there's a need to pick between them then kFreeBSD should
die.
Reply to: