But no worse than systemd, which is near universally despised by system administrators.

Does slashdot have Leonart Poettering on the design team, by any chance? It would sure explain a lot.

Who would have thought there would be consequences to spamming every article with whining and bitching?

Justice is served. Keep up the bans and let's get rid of the deadwood.

I fully support the rights of a bar to throw out the belligerently drunk - that's not censorship, it's called caring for your customers. None of us are here to read moronic posts about website style changes. We are here to read insightful commentary on technical stories and if you can't handle that, you do not and should not belong.

I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible (ambition to replace at, cron, change from running static number of getty on VC specified by inittab to on demand spawning of getty as auto detected). It's clear they regard users valuing plain text data with some disdain. There is plenty of opportunity to achieve the gains whilst concurrently providing a plain text stream to peruse natively, but they have *zero* interest in trying to pursue such paths.

This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.

In general, distributions embracing this become increasingly opaque to admins. Distribution behavior flows through an increasingly complex labyrinth of crap that it approaches Microsoft level BS. I'm somewhat disheartened at the possibilities here.

The biggest thing that pushed adoption was when it absorbed udev. You can still run udev without it, but it's plastered with systemd branding and building udev without also building systemd (and then having to manually strip udev out, if you want to run it standalone) is difficult. Beyond that, Gnome 3.8 made it (almost) a hard requirement. Strictly speaking you can run Gnome without, but, as I understand, it loses almost all of the power/disk/device management.

People like it because it's obsessed with boot times (which is apparently a really important thing to people who don't actually run a real-world system, where boot times of 10 seconds vs. 5 seconds are meaningless), has a few useful features (often, subjectively, questionably implemented), and has really good PR. The problems with it include an obsession with APIs (Unix, everything is a file -> systemd, everything is an API), an everything-and-the-kitchen-sink approach (NIH: write their own binary-formatted logging daemon, their own cron daemon, their own implementation of dbus, ...), and a horrid misunderstanding of what an initsystem really needs to do for servers (LP: "Control groups of course are at the center of what a modern server needs to do." -- which, really, what it needs to do is serve things, not shuffle processes around various metaphorical boxes). The project is, as a result of including the kitchen sink, also extremely monolithic -- everything is stuffed in a single git repo, a single tarball, and is heavily interconnected.

Two of the primary developers (Lennart Poettering and Kay Sievers) are also notoriously hard to deal with if you ever suggest they've done something incorrectly. You can find a lot of examples of this, largely to do with LP's attitude towards anything that isn't systemd, and Sievers' regular breaking of udev over the past few years.

The problem is the drunk one is the barkeep. The patrons told him to stop before he wrecks to whole place, but there is no stopping him. Every day he gets drunk and wreaks half the bar. Soon he'll be drinking alone. And it all started with that damn game of Dice.

Ubuntu used to be good before they destroyed themselves around 2011.
Mint is an Ubuntu fork after all...

Incidentally, this also means they align more closely with Microsoft thinking than traditional Unix thinking. At some point I wish these people would just accept they want Windows and go with Windows and leave Linux alone.

I too, lament the apparent impending demise of sysvinit shell script startup and plain text logging/process handling. Functional transparency in Linux booting was a good thing, and it will be missed. It seems more to me like these people arguing so hard over whether to replace sysvinit with upstart or systemd as though just leaving it alone was not an obvious option are more interested in changing the Linux init system to something inherently less secure and more obfuscated so that they can leverage it as a tool in some sort of entirely separate logistical/technical/political maneuvering and pissing match. I don't know any actually experienced sysadmins who are not involved directly with upstart or systemd development (and thereby have a vested career interest in promoting one or the other) who think eliminating sysvinit after all these years has any sanity or operational value whatsoever. The actual complaints about sysvinit are things that in practical use are only minor annoyances to the uneducated, quickly overcome by a modest amount of experience. The obvious maintenance nightmares that will be created by what these guys want to replace it with (either systemd or upstart, but for differing reasons) would dwarf any problems anyone ever had with sysvinit even if they were persistent, actual technical limitations, not just basically "user error."

I can only assume that all people who support this argument run GNU Hurd, as it's a microkernel, instead of that 16,000,000+ line of code "monolithic megamonster" known as the Linux kernel.

"systemd versus sysv init most visibly leads to faster boot".

That was the original marketing. systemd of course is much much more than boot.
Systemd touches every part of the OS.

https://en.wikipedia.org/wiki/... [wikipedia.org]

Upstart was bad. Systemd is worse. Both were born as boot/init systems and are unconstrained in scope.

Any program unconstrained in scope will grow into a monolithic mess.

The problem for Gnome and KDE is, that systemd is vastly superior to anything out there, and that it will help them dump loads of hard to maintain code, and give them easy access to make powerful distro-agnostic programs.

systemd provides a a common, uniform Linux plumbing system that makes life easier for all user program developers. So of course Gnome and KDE will start to take advantage of systemd, why shouldn't they?

The main problem with those who for some reason or another doesn't like systemd, is that they are incredible lazy. Instead of actually getting together to make an alternative development stack to systemd, they rant against Poettering and spew empty platitudes about "UNIX philosophy".

The most pathetic example of this anti-systemd laziness, is of course "ConsoleKit". It has now been unmaintained for +1½ years, but it is a crucial piece of infra-structure for any Desktop. But instead of either maintain it or make an alternative, anti-systemd people just rant against Gnome for no longer making it a priority to support this piece of abandonware. All rant and no work.

I think Pulseaudio was a great step forward for sound on Linux. Yes, it did uncover many sound card driver bugs, and bugs in Alsa back in 2004, but that also meant that those bugs got fixed. My internal sound chip was somewhat flakey before pulseaudio, and PA simply broke it completely, but that also meant, that when the bugs was fixed, the sound chip driver and Alsa layer worked perfectly ever since. I just used a popular and well supported SB compatible sound card instead while the bugs where fixed.

At the time, every other sound daemon was neither system wide, nor working properly. PA solved all problems in a rather elegant way, so for nearly a decade Linux have had an excellent and powerful sound deamon. Sound just work, and the "per application" sound volume is worth everything.

That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it. If PA ever was so bad as some people like to claim, why didn't alternatives spring up instead?

Sure, PA doesn't do low latency stuff like Jack, but it was never meant to. Instead PA works in perfect unison with Jack, in that it can suspend itself when certain programs need low latency sound operations, just like PA works on top of Alsa, not replacing it.

Actually, I would complain if the currently active log file were gzipped. It's a needless impediment to read the files. Besides, once a developer has said 'gzip' the files, then they decide 'well, I can bzip them', then later 'oh, well, .lzma is good', then 'oh, use xz'.. This is the sort of situation that systemd sets up: a treadmill where diagnostic environments must match runtime environments or else.

This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world, and now systemd systems will break from that strategy.

Just because you *can* do something doesn't mean it should be done. Just because this is one way at getting to more sophisticated log analysis infrastructure doesn't mean there is not a better way which would have made everyone happy.

This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world,

No, we haven't. We do exactly the same thing as Windows. We use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows. We like to call this "plaintext", but it's really a misnomer for a very particular binary encoding standard. (Go back in time and find some sysadmin for an EDBDIC system and ask them what their definition of "plaintext file" is.) So you can't easily view and work with these files on a Windows system (just try opening one of these files in Notepad). Do we care about this? I don't know about you, but I don't; any Linux or Unix system can view Unix-standard text files just fine, and that's all that matters.

The same goes for cases where the file is gzipped; there isn't a Linux system from the last 20 years that doesn't have gzip installed. And on modern systems, xz is commonplace as well.

The only thing that matters is if your data, in whatever format it's in, is easily accessible and manipulatable. For those of us using Unix or Linux, there's various kinds of files which are: "plaintext" (ASCII/Unix EOL), gzipped, bzip2ed, even pkzipped, because these all have easily and universally-available tools to access this data: you can expect any modern Linux system to have these tools installed by default. As long as the tools to view and manipulate systemd logfiles are similarly prevalent (which they will be on any systemd distro, as long as they don't go changing the binary standard for these files), it'll be no different. No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).

Dealing with \r\n versus \n is *totally* different scale than this. Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r'). EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.

My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.

I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation. I still would be in a fix despite having all the filesystem and block device wrangling required to get at the files.

Maybe he was downvoted by all the people who actually want to use the site instead of having to dig through 1000 'boycott Slashdot' and 'BETA SUX0RZZ!!' messages, and this is an example of the moderation system working.

We get it. Everyone hates beta. I hate beta. However, I hate digging through the 'FUCK BETA!' messages nearly as much as I hate beta. By all means, boycott the hell out of site, but I'll just send feedback and if they don't listen I'll find some other site to read. Then I'll come back and have a peep every couple of months to see if they got the message.

Personally, I prefer the traditional init system from UnixV...but then I also prefer grub over grub2. I like to be able to edit my scripts easily, and not dig through several files and try to puzzle out the documentation. (In the case of grub2 my puzzling out the documentation hasn't been that successful...I frequently need several attempts to get a change that would have been simplicity itself in grub. OTOH, I've only got one machine that I can use, so any change is difficult. If I make a mistake, I may need to reinstall the whole system. I can't just look up an answer on the internet...because that requires the machine to be working.)

I am not putting a convoluted, megalomaniac-spawned and KISS-violating atrocity like systemd on my systems. The binary log-format alone is a faux pas to severe as to invalidate the whole thing. Are there any good server-distros left that stay away from systemd or that are at least commited to maintaining a different init system longterm, preferably the classic SysV init?

Of course systemd will fail eventually (once enough people realize it is a bad clone of what Windows does and makes things worse, not better), but I am unwilling to wait that long or tolerate all the disadvantages this thing brings in the meantime.