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?
