This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. Really, I think all of the reasons why systemd attracts hate can be boiled down to this. Nobody wants a standard init system that's overtly hostile to bug reports and reasonable changes.
Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with.
This. It doesn't help this guy's case that he's basically calling anyone who doesn't want systemd a "troll". That's not the way to win people to your side of a disagreement.
"The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future."
A major bug is reported, and their response is "it's too hard so we won't fix it" in a project that is soon to be at the core of every major GNU/Linux distro? No thanks.
I'd say telling a bug reporter that their report is useless because "we're too lazy and dumb to fix it" is being hard to get along with. Besides, that's far from the only example. A quick Google search brings up dozens of cases where systemd developers and evangelists deride even those who ask basic questions about it. It's a perfect example of "it's our playground, find your own" that is so juvenile and antisocial that it bothers the hell out of me. And that's not even the reason I don't want to use systemd; I simply prefer traditional init systems like sysvinit and Slackware's BSD-style init system.
Yes, in Arch Linux. And as I've said elsewhere, it's a good idea, but terrible execution and a load of unnecessary controversy. I think GNU/Linux should have one major init system, with the option to use any other system one wants to. But in my own informed opinion, systemd is not the init system we need. I'll take 30 year old working technology over unproven, barely tested new technology with hostile developers, any day. If the day comes that systemd is stable and mature, drops the insane binary log system, stops being a dependency for entire DEs, stops being hostile to any other init system (if your distro of choice uses systemd as a default you risk breaking your system if you want something else), along with developers who aren't lazy and working in a bubble of their own creation, then I'll welcome it with open arms.
I guess not, but maybe it's even more damning that this core system component is so much more complex than the previous system, that it sometimes corrupts its data. I'm willing to believe that's not catastrophic, but can someone tell me why it's a good thing for an init system to have corruptible persistent state to begin with?
There are a couple of incidents mentioned on the LKML that go directly to their bug tracker - the ones I refer to is where Linus gives Kay Sievers an earful for hijacking the kernel flags (and subsequently writing off the perfectly reasonable complaint). I'd link you to them directly but I'm mobile now.
That's moving the goalposts in a significant way. Debian has always been of the philosophy that binaries that have runtime-optional support for something link libsomething and have a dependency on it, but there cannot generally be a dependency from libsomething to the actual something package.
For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed.
Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.
This libsystemd points to a dangerous habit of the certain group of developers who prefer strong interdependency and monolithic architecture. In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. And gconf libraries which ship daemon executables and also launch daemons from library. Libsystemd is apparently not doing such right now, but given its windows.dll like nature, it's a reasonable concern to have.
> In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library.
That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here.
As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency.
> it's a reasonable concern to have.
The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything.
For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
Yep. You noticed that too. I found this out by trying to remove all traces of systemd from my Jessie/Sid installation, found out that I couldn't get rid of libsystemd0 because bsdutils depends on it. That's the same bsdutils that you can't really do without.
It's almost as if systemd was being forced upon you no matter what.
You don't have to. Someone apparently implemented the logind interface(!) so that GNOME could function on non-systemd systems. Just use that.
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. [...]
Are you kidding? I've been following along the mailing list for at least two years and I've never seen any of the unreasonableness you claim. (I'm not in any way connected or invested in the systemd project, just as a little disclaimer.)
If you're going to pull this stunt please at least give us concrete references.
> Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
Ah, I see. You're just another troll recycling talking points. Oh, well.
Oh, and btw: Complain all you want -- in F/OSS the people doing the work get to decide. Deal.
No-one has yet come forward publicly with a working second implementation of logind for Linux. The only person known to be working on a second implementation of logind is targetting OpenBSD. To use logind-API-client desktop environments with the well-known systemd-shim actually involves using the logind that is part of the systemd package, running on top of a daemon that implements only part of an internal systemd API. See http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
As well as upower (though it still works with ConsoleKit as fallback, I think), udisks2, the Weston compositor and some other programs. Binary distros also have some pretty skewed dependency chains on systemd for packages where it's inessential.
Only up to a point. Systemd is getting too bloated, and software engineering tells us that the effort to maintain this will grow exponentially.
So we have two options: if systemd improves and decides to follow UNIX principles, good. Otherwise it'll be replaced like consolekit et al. It's great that we have so many init systems to choose from. The only problem now is software that hard depends on systemd when a single line of code could avoid that.
In the future? Yeah, probably.
This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. Really, I think all of the reasons why systemd attracts hate can be boiled down to this. Nobody wants a standard init system that's overtly hostile to bug reports and reasonable changes.
Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...