Personal attacks are not OK, but he should keep his opinion on what _my_ machine should do for himself. For what it is worth, his systemd is a bug.
Personal attacks are not OK, but he should keep his opinion on what _my_ machine should do for himself. For what it is worth, his systemd is a bug.
Releasing free software and what you accuse him of are entirely different things. Frankly I'd like to understand how you even equate someone releasing software which you aren't even forced to use, to essentially ramming his opinions of how YOUR machine should run down your throat.
The anti-systemd people really aren't coming across at all well in this thread. At lot of what you guys are accusing him of literally makes no sense on the most basic level. This being a prime example.
Don't like systemd? Don't install systemd. Don't like that a distro is bundling systemd? Don't use the distro that is bundling systemd.
The creator of systemd cannot be held responsible for you voluntarily installing the software, leaving it on your system, and then becoming upset about how it works. If you installed systemd and hate it, remove it. It aint' rocket science.
The systemd developers have made many political decisions that ended up putting systemd in a position that makes it difficult to avoid. The prime move often cited is the engulfment of udev inside the systemd codebase and entangling it with systemd's shared files (formerly belonging to libsystemd-shared, not it's just a big libsystemd blob), and later rewriting the build system so that it was harder (though not impossible) to make udev-only builds. This and many other decisions prompted the creation of eudev. Of course, now they're converting the transport layer from Netlink to sd-bus, thus intending on making udev systemd-only, and taunting Gentoo users along the way.
Furthermore, various distribution maintainers (though particularly Debian and Arch) are placing various components that optionally use systemd libraries, or provide systemd units, as being dependent on systemd. You can see this with Arch and lighttpd.
Further, GNOME's adoption of systemd libraries was negotiated by Lennart as far back as 2011. Though it would have likely occurred anyway, he was an active instigator in the ordeal (https://mail.gnome.org/archives/desktop-devel-list/2011-May/...), and a couple of years later was arguing on his G+ feed that with systemd-logind being unportable and inseparable, that this should be a reason for Debian to adopt it. He chose to do this rather than continue ConsoleKit or make logind an independent daemon. Currently, more is being consolidated: Avahi is now becoming systemd-resolved, and kmscon is becoming systemd-consoled. Among other examples.
But it's not just the GNOME Shell, some core Desktop Linux applications now depend on systemd libraries, as well. upower and udisks2 come to mind. The former even caused quite a stir in Gentoo circles when a regular upower update was suddenly pulling in the entire systemd stack.
The whole point of systemd is to be the standard userspace middleware for a GNU/Linux system, and to be an absolute essential.
No, Lennart is not a rampaging monster, but to say that he's just some innocent bloke who's simply releasing free software, is bullshit.
It's been years since I used desktop Linux, but frankly so far my impression of systemd is that it sounds like someone in the Linux community is finally doing some damned architecture work for once instead of just trying to build a desktop on top of a pile of historical accidents. I remember when GNOME 2 was being developed (back then I was a user) and the massive, rampaging flamewars about how GNOME 2 was killing Linux, how it was fundamentally against the UNIX way etc. Back then it was Havoc Pennington who got shitted on by the "community" for daring to suggest that maybe you don't really need seven kinds of clock widget installed by default. And now what I see is people forking GNOME because they love GNOME 2 so much and they don't want to switch to GNOME 3.
Back when I used to work on Linux related stuff, one of my projects was a cross-distro packaging framework. The idea was you could create binaries that'd install and be upgradeable on any reasonable distribution. We did a lot of work into binary compatibility and other tools so you could make binaries that soft-linked against libraries, etc. The amount of crap we got was unreal. A lot of people in high places in the community, especially from distributions, hated the idea that maybe people could just download apps from a website and it'd work. I think at some level they understood that distros competed largely on the size of their package repositories and if that approach to software distribution became mainstream they'd lose their "lock in". And some of them had internalised the idea that "Linux is great. Linux doesn't distribute software in the same way as other platforms. Therefore that's what makes Linux great."
When I look at MacOS X what I see is a very successful OS that has an architecture rather similar to what systemd sounds like (the OS X equivalent is called Launch Services). So maybe that's why distros are getting behind it.
For what it is worth, his systemd is a bug.
There is no way in which you can look at systemd and say that "it's a bug". It may be a system not engineered the way you would prefer, but it absolutely isn't "a bug". It's a large, well engineered piece of software, that solves many pain points of traditional ways of managing services and sessions on Unix-like systems over the years.What way would you like to customize your system that you cannot using systemd? I'm genuinely curious if you've ever tried using it.
Now, there are many valid reasons why systemd may not be to your taste. No one is forcing you to use it. There are projects in which development is moving to depend on systemd, because it provides a lot of functionality that other systems don't, and the people writing that code don't want to have to reinvent the wheel. Lots of software has dependencies, some of which you may not like, but you shouldn't blame Person A for making a system that you don't want to use, that Person B who writes software you do want to use depends on; and really, blaming Person B isn't particularly helpful either, as they are just trying to get the job done efficiently and don't have the time to maintain many different backends for many different incompatible session management systems.