"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.
This. Backed by nothing, calling the systemd team "notoriously hard to get along with". I'd be interested in seeing proof of "this".