So distributions chose to bundle Pulseaudio before it was sufficiently stable, and this is all Lennart's fault and he must forever burn in hell with no way to ever, ever fix or improve things?

The Lennart hate is ridiculous. This time, even Linux kernel hackers think systemd is a good idea. What are your credentials?

Well, when Lennart says that *BSD is irrelevant as if he was the judge of that... I don't see why he shouldn't be able take a little heat. After all - he is the god that wrote, you know, PulseAudio and Systemd.

There are other hackers around that are not "Linux hackers" who might have a different view about the quality of Linux space. I tend to agree with them.

What does this suddenly have to do with BSD? kashchei claims that Lennart is incapable of ever producing good code and that all his creations must therefore die. Nothing about BSD.

It may seem unrelated but it is not. Lennart lacks the humility necessary for his contributions to be considered genuine advancements. He dismissed BSD in the context of discussing systemd. The way he put it, anyone who doesn't see the light coming from his code is irrelevant.

When I put this next to the half-success that PulseAudio is (which was similarly promoted and blindly embraced by all major distributions out there), I find questionable the idea of systemd being the next best thing since hot water.

I do not know if Poettering creates good code. He surely creates successful code, though: Gnome, PulseAudio, Avahi, systemd.

I find hard to read such comments and think that they are valuable contributions anymore.

First of all, Pulseaudio was not the biggest success, true, but can't someone learn from their mistakes? Both are also living, moving software products that continue to improve, as you said, "development marred with huge number of bugs that ruined audio on Linux until recently" - key words: "until recently".

Secondly, about the technical aspects:

http://0pointer.de/blog/projects/the-biggest-myths.html

http://www.freedesktop.org/wiki/Software/systemd/ -> "The systemd for Administrators Blog Series"

Lennard Poettering said it better than I ever will.

Also: just saying that something is a myth does not make it any less true. The whole point is that systemd (and Pulseaudio) is anti-Unix because its author does not understand Unix design, how would his opinion be of any value in this matter?

I find his arguments quite compelling and honestly, at this stage saying "the author does not understand Unix" just sounds silly.

Judging by his work and his writings, Lennart probably sleeps with a copy of "The Unix Programming Environment" or other such classic under his pillow. He probably knows Unix 10x better than you or me (feel free to point me to your resume/bio if my assumption is wrong :) ).

Just say that you don't agree with his design.

That's fine and it's acceptable. It also turns this debate into something kind of like Linux versus Minix. Working code (his) wins for now ;)

The design is still beyond horrible, and on par with Windows. If everything that can be shoehorned into a system and "works" despite being a complicated mess, was accepted, we would have adopted Windows registry and SNMP as primary configuration mechanisms, too -- after all, they both work more reliably than Pulseaudio does.

PA was force-pushed too early, systemd got it's own momentum. AFAIK PA suffered from external unsolvable forces, like hardware/driver giving inconsistent if not false data to PA, causing failures; I believe systemd is shielded from this. The benefits (sound dependency based state) already outbid the other issue one might have with it (less freeform scriptability as in SV).

I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?

In my opinion, there is no replacement for true modularity, simple, future-proof interfaces, and clear, human-readable and human-writable formats.

> I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?

I've been running systemd as my init system for at least a year. It's also used in Fedora. It is working pretty well by now.

> In my opinion, there is no replacement for true modularity

Systemd is an ecosystem. It contains a number of different binaries. They may be part of the same codebase, but so what?

>, simple, future-proof interfaces, and clear, human-readable and human-writable formats.

You mean, like systemd's unit file format, which is both more readable, and more specified, than the sysvinit boilerplate? If you mean journald, if you have rsyslog as well, you get your usual /var/log/syslog. Best of both worlds.

> Systemd is an ecosystem.

"Ecosystem" == vendor-managed closed system.

True interoperability does not produce "an ecosystem", it produces standards with (at least potentially) multiple implementations.

> It contains a number of different binaries. They may be part of the same codebase, but so what?

So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.

> "Ecosystem" == vendor-managed closed system.

I'm sorry, but you're not making any sense. If a closed system is a project you can fork on github, with ~ 260 contributors and libraries like python-systemd, I don't know how you define "closed".

> So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.

Right. So, the systemd Debian package on my machine has 21 separate binaries. Who in their right mind would want to have 21 separate repositories to keep in sync?

As for "cleanly defined interfaces", I don't know how having several different systems in the same codebase prevents that. Which parts of systemd do you feel are not well-documented and prevents you from writing code to interact with it, or replace part of it?

systemd is already used and from what I've seen there's far less complaints than PA[1], even talks of admins suggesting to look into it. That's for the 'not ready' part. For the rest, I'd agree with you, but I think the gain in abstraction and correctness is quite worth it, even with it lacks some simplicity.

[1] never encountered a single issue with systemd since archlinux pushed it as default, even on hybrid sysvinit scripts and naked systemd installs, compared to PA which may crash far too regularly, but that's just me.

And yet, it seems to be very popular and is the default audio system in many many Linux distros. It seems odd to me that such a poorly written and obtuse program would be readily embraced by the desktops and distros (and every other program that it needs to interface with).

If the downsides are so severe, it must have some really good upsides, otherwise no one would use it.

My personal anecdote is that Debian installed it for me on my long running system and that I've never touched a config file or otherwise looked at it at all and that my audio always works...