Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/15/2013 09:43 AM, John Paul Adrian Glaubitz wrote:
On 07/15/2013 03:00 PM, The Wanderer wrote:
My personal objections to systemd come down to the fact that I
don't trust its developers / maintainers. Part of that is bleedover
from the fact that I've so far had only poor experiences with
pulseaudio
I haven't had any problems with PulseAudio for ages. PulseAudio is
installed by default by all major distributions and I have had heard
little to no complaints ever since it has matured.
Some older versions prior 1.0.x were broken or had exposed bugs in
ALSA drivers which needed to be fixed. These days, however,
PulseAudio is rock-stable.
It usually breaks only for people who tinker too much with it without
understanding the concept behind it.
My most recent experience with PulseAudio came when I noticed that WoW
(run through Wine) was producing crackling, stuttering sound again; this
was during the late months before the wheezy release.
I tried half-a-dozen things, without noticeable change (except for the
things which led to no sound at all); eventually I noticed that some
PulseAudio packages had been installed, apparently as recommendations or
dependencies of other things. I tried a few things to disable use of
PulseAudio without removing it, without affecting the problem; I then
removed all *pulse* packages I could, rebooted, and the problem was
gone.
I can't guarantee that that was a PulseAudio problem, but I haven't been
able to track it to anything else, and there does seem to be a
correlation. Other people have reported similar "crackling sound in some
programs when using PulseAudio" problems, though I don't recall offhand
how recent those were, and last time I searched there didn't seem to be
any indication of work being done to address that.
The fact that I wasn't able to find a way to disable use of PulseAudio
without uninstalling it is another negative; the fact that even
uninstalling it didn't work until after a *reboot* is an even bigger
one.
(and have heard several negative reviews of it not purely based on
user experience, mostly summing up to "why did they start a new
audio system from scratch instead of adding the missing
capabilities on to JACK?"),
Because JACK and PulseAudio target completely different audiences.
JACK is designed for professional audio and is usually an overkill
for most desktop users. No one, including the PA developers, ever
claimed that PulseAudio is a replacement for JACK.
The people I've heard discuss these things seem to think that PulseAudio
now essentially implements everything that JACK does plus some, and that
the approach JACK uses is fundamentally the right way to do Linux audio
in the first place. I admit that I haven't investigated this personally,
but I generally trust the understandings of at least one of those
people.
That's irrelevant to the current discussion anyway, however; I only
mentioned pulseaudio because leaving it out in explaining the reasons I
don't trust systemd's developers would have been dishonest.
but most of it hangs from the discussion I once read in which
Lennart expressed - and, when objections were raised to it,
reiterated - the desire to eventually drop support for using udev
without systemd.
While this is still not the case,
Could you clarify what you mean?
I recognize that support has not yet been dropped, but Lennart's
statements in that discussion (early August 2012 on systemd-devel,
apparently) seem quite clear, and if he's changed his mind I haven't
heard about it.
I don't really see why this shouldn't be done. udev is Linux-only and
so is systemd and neither of them will probably ever ported to
non-Linux kernels.
Not being able to use udev without systemd would mean you couldn't use
any non-systemd init system with udev.
If you don't see why that's a problem, both for other current init
systems and for people who might someday want to implement another new
init system (of perhaps a different design from either current older
ones or systemd), I'm not sure how well I could explain it.
That attitude as a whole, in fact, is the major offputting thing
about the entire systemd-et-al. project(s) from my perspective; it
reminds me of proprietarianism, and a little bit of "embrace,
extend, extinguish", and I very much want to avoid lock-in.
Which can be a good thing, sometimes, since it simplifies work for
other developers whose software builds on top of the kernel
plumberland when they know which software to expect on the target
system.
There are upsides to that paradigm, yes. There are also downsides.
That's a very large discussion of its own, and I'm not prepared to have
it at the moment, even if this were an appropriate place for it.
I actually *like* most of what I've read about systemd's
capabilities, performance, and behavior, as compared to at least
sysvinit; I'm even reasonably willing to accept that it's superior
to the other alternative init systems in those regards. I'm just
not at all sure that those improved capabilities, performance, and
behavior are enough of a benefit to be worth the trade-off of being
essentially at the mercy of developers whose philosophies and
attitudes I find so strongly objectionable.
systemd has many independent developers and contributors. I don't
think we're at the mercy of a small group of people when using it.
During the last cycle of this discussion here (in May), IIRC Steve
Langasek dug up statistics indicating that if you ignored udev, close to
78% of systemd code by line count was from Lennart.
And this doesn't matter anyway if the bulk of those independent
developers and contributors all share the same philosophies in this
respect - which, while not certain, is far from impossible, since those
who do not share those philosophies are less likely to contribute to
systemd in the first place.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
Reply to: