By escalate, I mean escalating the conflict rather than appealing to some judicial body. (A trivial example would be for you to say "Implement feature X or I'll resign", or if it's an unarmed robbery, pulling out a gun.)
Asking for help resolving the conflict (which is another use of the word escalate) is of course ok. (English has many words, but does that help, when half of them have multiple meanings?)
Just posted on my blog with a bit more background: http://err.no/personal/blog/te...
An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.
And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in
Yes, this is a bug (sorry, I don't have the bug # handy) and there's work in progress on preventing you from shooting your foot off (by requiring you to fix your fstab before the installation completes). It's still possible to boot up using sysvinit by booting with init=/lib/sysvinit/init as long as you've not uninstalled the sysvinit package. I'm sorry about people hitting this, but on the other hand, there's a reason why Jessie isn't released yet, we have some bugs to fix first.
Yet both sides believe the other side is the idiots.
If you make that "some people on both sides", I agree with you.
There are certainly good people on the anti-systemd side (and I'm sure there are poisonous people on the pro-systemd side too). People being skeptical and saying that we should be careful adopting everything it provides. I don't agree with them (at least not fully), but my resignation from the maintainer team is not about people being skeptical, it's about personal attacks, it's about death wishes from project members and it's about people escalating conflicts instead of trying to resolve them.
(I do agree with them in that we should think about what technologies we adopt by default and which we don't. As an example, systemd-resolved is not enabled by default. As the recent CVE shows, that wasn't a bad decision. We might change it in the future, but we should absolutely think about the maturity of the components we enable, in particular those enabled by default.)
What do you think is the greatest misconception people not liking systemd have about it?
It's a new system, so some things work differently. Many people seem to fail to see the line between bugs and intentional behaviour. If something doesn't work as before, it might not be because we're evil bastards who are out to steal your logs. It might just be that there's a bug in some package which means your logs aren't correctly forwarded from the journal.
Sometimes it might be that systemd makes other assumptions about what something means and we're just failing to catch that in an upgrade check that should warn you about this. An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.
Assumptions, as so often before, are the mother of all fuckups. Asking (preferably in a civilized manner) will get you a long way: "Hey, I'm not seeing my logs appear in syslog, is this supposed to be that way, and if not, can you help debug?"
This might not be the greatest misconception, but I think it's the most common one. The greatest is possibly the conspiracy theory that this is all a takeover attempt from RH to kill other Linux distributions and that people pushing systemd are either shills or just unwittingly working against the distro they're pushing systemd into. I'm not sure how adopting a free software component (which sure, happens to be largely maintained by RH engineers, like many other free software components we use to build a distro) will turn us all into corporate-loving robots giving up freedom to be near the source of systemd.
I was pointed to this by a friend on IRC. As you can see from my comment history, I'm not exactly a heavy slashdot user so I was quite surprised when this showed up.
It's a pretty long story. If you want to read all of it, you probably need to read the entire debian-devel and debian-ctte archives from approximately a year and a half ago until February/March this year.
A shorter summary is something like (from my memory, coloured by my views, etc, but I believe it's largely correct). User names are generally @debian.org, finger $user@db.debian.org for full names and such. It's a bit rambling and written in one go, but it's what you get this time:
- I upload systemd to Debian about a month after its initial release, get it into a ok-ish shape for wheezy, but not anywhere near suitable for being the default.
- Other distros start switching to systemd as default, various people in Debian start discussing if we should switch to systemd. Some people say yes, some no, some want to switch to upstart. Bickering and discussions in equal measure spread out across all media (IRC, blogs/planet, mailing lists, in-person discussions). Most of it reasonably civil.
- At some point, paultag files https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bi... (_massive_ bug report, you don't want to read it all) , asking the Debian technical committee to default on what the default should be.
- Lots of discussions happen, we use a bit of liw's and rra's Essay Debate System (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwiki.debian.org%2FDebate, https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwiki.debian.org%2FDebate...) to structure the debate. It's Debian, it has to be A System.
- vorlon (Steve Langasek) sets up VMs using the various init systems for the Technical Committee members to play with. They do so and write up their findings and arguments. rra's writeup is at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Flists.debian.org%2Fdebia... and is possibly the best comparison I've ever read of init systems. Lots more discussions happen. I contribute a fair bit with my systemd maintainer hat on (though we're at this point a team maintaining systemd in Debian) and is very happy this happens while I'm holidaying in Spain so I don't have to deal with a day job at the same time.
- A lot of arguing internally to the CTTE whether to couple the question of what the default init system should be with whether it's ok for packages to require a given init system. bdale resolves the knot by calling for votes on a proposal very quickly after proposing a ballot. iwj sees this as backstabbing and is still very, very angry about this to this day.
The vote ends with systemd being the winner, after bdale's casting vote as the CTTE chair.
After this, there is an attempted General Resolution in March, which fails to get enough seconds, this is restarted by iwj on late October this year. The goal of this GR appears to be to forbid packages to depend on a specific init system.
I am not resigning from Debian, just from the systemd maintainer team.
Sounds like we should set up a reverse botnet with a rating system, then.
Talk to some other companies you know, create a system that takes a list of failed logs, anonymizes it somewhat and publish it. They do the same, you all have a system that pulls down the list from the others and puts that into a list of "hosts we probably don't want to talk to, because they have tried as root@othercompany.com".
If the lists are properly anonymized and we have a rating system so getting bad data into the system is harder, I think we'll have more or less countered them for now.
I'm sure the next reply will tell us all about somebody who already has this designed and set up.
In practice, failures in system development, like unemployment in Russia, happens a lot despite official propaganda to the contrary. -- Paul Licker
