Hugh Pickens writes:
Systemd has turned into the Godzilla of Linux controversies. "Everywhere you look it's stomping through blogs, rampaging through online discussion threads, and causing white-hot flames that resemble Godzilla's own breath of death," writes Jim Lynch. Now Sam Varghese reports at iTWire that although Linus Torvalds is well-known for his strong opinions, when it comes to systemd, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," says Torvalds. "I don't personally mind systemd, and in fact my main desktop and laptop both run it."
Oh, there's been bitter fights before. Just think about the emacs vs vi wars. Or, closer to systemd, the whole "SysV init" vs "BSD init" differences certainly ended up being things that people had "heated discussions" about. Or think about the desktop comparisons.
I'm not really sure how different the systemd brawls are from those. It's technical, but admittedly the systemd developers have also been really good at alienating people on a purely personal level too. Not that that is anything particularly new under the sun _either_: the (very) bitter wars between the GPL and the BSD license camps during late-80s and early-90s were almost certainly more about the persons involved and how they pissed off people than necessarily deeply about other differences (which existed, obviously, but still).
Torvalds was asked if systemd didn't create a single point of failure which makes a system unbootable if it fails. "I think people are digging for excuses. I mean, if that is a reason to not use a piece of software, then you shouldn't use the kernel either."
I don't want to showcase my naivete any more than I have to, but I can't agree with a lot of the things he said from a technical perspective, especially the dismissal of introducing complexity to a single point of failure. At first he compared systemd to the kernel, then walked that back and compared it to glibc instead. But there are other libcs, and glibc doesn't require applications to call glibc-specific functions to work properly [ewontfix.com].
I suspect most people remember the udev fiasco a while back, but it's worth noting that the eudev team kicked off their fork by citing Linus' complaints ( http://article.gmane.org/gmane.linux.gentoo.project/2262 [gmane.org] ). So Linus is certainly capable of complaining, and his complaints get things done. Perhaps he's also remembering that, because he was careful to avoid saying anything that could be taken as hard advocacy for anything.
To go with your point that Linus isn't afraid of complaining, he went off on Kay Sievers [theregister.co.uk] back in April. He's probably going to stay out of the fight unless one of the systemd devs does something else that causes him pain.
I don't want to showcase my naivete any more than I have to, but I can't agree with a lot of the things he said from a technical perspective, especially the dismissal of introducing complexity to a single point of failure.
Absolutely, especially if you're talking about servers. Even kernel devs have commented on the 1 MiB size of the systemd executable as being troubling and being a potentially big attack surface. Combine that with the fact that almost nothing in there is desirable on a server in the first place, which means you're just asking for more bugs and vulnerabilities with no upside whatsoever.
I think Linus knows his opinion would carry far too much weight for him to get involved, and he's arguably correct.
For me, I just can't imagine how anyone isn't sent screaming into the night by the very idea of that binary logging alone.
That's me. I think binary logging is fine. Hell, I even prefer it. I am NOT a stranger to either binary formats or to fixing systems that use them and which have become unusable. I use Enlightenment as my daily desktop and it uses a binary format for all of it's config files. Turns out that editing configuration with a purpose-built program is, in practice, much handier than using something generic like vim (setting up Enlightenment is more comfortable than, say, PekWM or Fluxbox would be if they had the same levels of functionality, which they only have a small fraction of), sticking to simple plaintext formats is impractical because it comes with A LOT of subtle failure modes (see: KDE with it's magically disappearing and easily corruptible configuration), and making a "plaintext" format complex enough to support less-error-prone development results in formats that are a PITA to view/edit in their plaintext form (see: Openbox with it's xml config file -- or anything with xml configs, really) and are still error-prone, with the errors just having been shifted elsewhere (ask anyone who has worked with xml).
Just because a format is binary doesn't mean you can't use your standard tools on it. The one time I locked myself out of Enlightenment because I enabled an option that made my graphics driver go nuts? Extract the plaintext with the included tool, edit with vim, and encode it again. No big deal.
While that was for config files, and not log files, the way I see it the binary format brings similar benefits to logging. I'm all for that.
Wow...I don't even know where to start. Nothing in anything you wrote makes a single solid argument for binary formats, especially ones that can get corrupt like the systemd logs, which apparently is NOTABUG:
You've described nothing that can't be done, and shouldn't be done with text formats. Windows has proved that failure of the approach for decades. It's just as easy to write user friendly frontends for text formats as binary. Insane. There's a reason the 'nix has avoided this for 40 years.
1. Yeah, because corruption can't happen on plaintext files.. the thing is you'd probably not even notice
2. Yes, I just described things that can't be realistically done with plaintext formats. It's been tried, it always results in headaches. Many of those headaches have been on my head. Yes, you're right, HYPOTHETICALLY it can (and there are very compelling arguments why it should) be done with plaintext. HYPOTHETICALLY the same is true of microkernels vs. monolithic kernels, you tell me how that one worked out. Things that work hypothetically don't always work out in practice.
3. No, Windows hasn't proved the failure of the approach. To say that is like to say that Windows has proved that terminals suck because Windows's terminal sucks, or that microprocessors are unreliable because Windows can crash. (And I am as much of a Microsoft hater as _gweg, I go out of my way to avoid anything MS and, where possible, try to make my stuff explicitly incompatible with it)
It's just as easy to write user friendly frontends for text formats as binary.
I wish. What this tells me about you is that you've never actually done such a thing, at least not to the extent of a proper industry-grade product. There are complex problems with it that you're unaware of as an armchair developer. I've seen them first hand, they're one of the things that made me fed up with KDE (which I otherwise mostly loved) and made me flee to other options.
Obviously I'm not saying there isn't a place for binary formats, with things like databases being the obvious example. Remember however this all started with my comment about binary log files. There's no possible way you're convincing me, or most anyone, that that's a good idea. There's no excuse for critical log files to be dependent on anything aside from a readable file system.
...and how about not assuming you know anything about me. I've been an "armchair" developer for a living since 1985.
at least not to the extent of a proper industry-grade product....<snip>...There are complex problems with it that you're unaware of as an armchair developer.
Just to clarify my previous post, for many years I've been the lead developer for a server based data center product currently running all over the world, which also has been in heavy use for years by data center assessment teams for IBM and HP, among others. It's that very sort of experience with the server side of things that makes me find systemd and everything about it totally revolting. It also makes it a little hard to accept condescending crap from some arrogant AC frankly.
At first he compared systemd to the kernel, then walked that back and compared it to glibc instead.
I forgot to mention in my reply above: I'm sure he backed off on that because he realized the bad analogy. When it comes to the kernel, there a countless modules you'll never load, for example, on your companies web server obviously. You use whatever you need. Systemd is decidedly not modular in that way, and it seems as though that's by design.