Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team 550
An anonymous reader writes Debian developer Tollef Fog Heen submitted his resignation to the Debian Systemd package maintainers team mailing list today (Sun. Nov. 16th, 2014). In his brief post, he praises the team, but claims that he cannot continue to contribute due to the "load of continued attacks...becoming just too much." Presumably, he is referring to the heated and, at times, even vitriolic criticism of Debian's adoption of Systemd as the default init system for its upcoming Jessie release from commenters inside and outside of the Debian community. Currently, it is not known if Tollef will cease contributing to Debian altogether. A message from his twitter feed indicates that he may blog about his departure in the near future.
Not resigning from Debian (Score:5, Informative)
I am not resigning from Debian, just from the systemd maintainer team.
Re:Not resigning from Debian (Score:4, Insightful)
Glad to hear. And for what it's worth, I think it's a shame some elements in the community behaved like they did. I chalk it off to them being immature twats, but mostly it's that people are people, and a good chunk of humanity are just idiots.
Re: Not resigning from Debian (Score:3, Insightful)
Yet both sides believe the other side is the idiots.
Re: Not resigning from Debian (Score:4, Insightful)
Exactly. Using ridiculous namecalling for folks challenging systemd such as "immature twats" is taking sides. It's not possible to have a reasonable collaboration so long as systemd has activist fans who do not take the time and care to understand the criticisms.
Systemd is killing the Debian project. (Score:3, Interesting)
And the criticism [boycottsystemd.org] from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.
Systemd is inherently contrary to many of the core philosophies that underlie the Debian project, and that underlie UNIX and UNIX-like systems in general. Many of the criticisms of it just cannot be refuted. Bad ideas will be bad ideas, and systemd is objectively full of t
Re:Systemd is killing the Debian project. (Score:4, Informative)
And the criticism [boycottsystemd.org] from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.
I'm not a total fan of every design feature of everything systemd has done but gave you actually read their supporting references? I'm most of the cases boycottsystemd has rephrased events to make the systemd folks look as bad as possible in ways that would make a Fox news reporter feel proud. A good example is their comment about requiring "bug for bug" compatibility with glibc was instead a use of a certain non posix flag needed for thread safety [freedesktop.org] and complaining that it is tightly tied to Linux is about as helpful as complaining that udev is tightly tied to Linux.
At any rate, I find it very telling that they don't actually mention any of their supporters.
Re: (Score:3)
Do you class every binary as monolithic because by your definition virtually every binary is if it has a dependency i.e. a library, and modular should not exist in any way in computing.
The only way a binary can be truly monolithic is not to have any dependencies outside its own
Re:Systemd is killing the Debian project. (Score:4, Informative)
Systemd is monolithic - not built into a single binary blob, but split into several tightly-dependant binary blobs.
Follow the Unix philosophy: Do one thing and do it well and work with other tools to implement complex tasks.
With your definition "ls -alF | grep "^drwxrwxrwx " is monolithic: The grep statement depends on ls formatting its output in a certain way. That makes them tightly-dependent binary blobs.
Re: (Score:3)
nope, grep can parse other statements too, and you do not need grep to understand the output of ls.
That's the difference, ls and grep are independent tools that can use other tools as you like. Systemd doesn't work so well if you choose to replace any of its subsystems as they tightly depend on each other.
The unix way is to develop a tool that does what you say it will, according to its own rules. It can be more trouble to integrate but the power means you have a lot of reuse potential.
The Windows way (if y
Re:Systemd is killing the Debian project. (Score:4, Insightful)
So is systemd-the-initsystem and systemd-networkd. Both are independent tools, where systemd-networkd uses an API provided by systemd-the-initsystem. Distributions routinely replace systemd-networkd. They replace other parts of systemd as well. So I fail to see the difference. There are about 60 different binaries, each doing one thing. They all communicate using a standard and even scriptable method that is widely used in unix desktop environments.
The BSDs tend to develop kernels and tools together, too, precisely to have a better integrated userland and I am pretty sure those count as unix:-) So that is not (only) the windows way. The systemd project is about providing similar plumbing for Linux. The developers clearly say so for a long time now. With the stated goal of being the plumbing layer the project tackles a lot of problems that were ignored. That is a good thing(TM). And that more and more developers of applications start to depend on the plumbing is proof to me that they are doing a good job. Actually that is where the value of systemd is, not in the init system.
Process management the core task of any init system, so I am not sure how that ended up in your list. Not sure what notifications does there either, since I am not aware of systemd actually doing that, but maybe I am missing something. The kernel devs have tried to clean up the console code repeatedly and have expressed interest in moving that code to userland. A brave soul stepped up and started to implement that. Putting it into systemd is the logical step for him to take: That is what all the major distributions are using. That there is finally some common ground makes projects like this possible in the first place! Or do you seriously think he would have written the code and then have bothered to integrate it into a dozen different distributions? Nope, no chance. Yes, there are packagers that help with the packaging, but he would still have a shitload of integration work to do to handle the different setups, init systems and whatnot.
Re: (Score:3)
Would you deny that a foundation built out of concrete is really not much more than a few tons of aggregate, some sand, and a binder? We call that kind of structure monolithic, even though the constituent parts are many, and concrete is only roughly analogous to stone. These are the same reasons OP calls systemd monolithic. Perhaps now we can move beyond being purposefully obtuse pedants.
By your silly definition, anything that isn't an elemental particle is a monolith.
If you think that something is the exact opposite of the dictionary definition, amnd the definition that almost every single person alive has - no wonder there is a knock-down, drag out, hissy fit, bitchfight going on between the modern day hatfields and McCoys.
Re: Not resigning from Debian (Score:5, Insightful)
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.)
Re: Not resigning from Debian (Score:5, Insightful)
Death wishes are never cool.
But what do you think people should do instead of escalate? I think at this point it's pretty clear that there are fundamental (some might say philosophical) disagreements at play here that haven't been resolved yet - and may be unresolvable (people are talking seriously about forking Debian over this). Escalation seems like exactly the appropriate step. When I'm at work, if I don't agree with a decision I talk about it with my boss - but if we can't reach an agreement and I feel strongly that it's the wrong decision, I take it to his boss, and so on if necessary. I would be remiss if I didn't!
Honestly, many systemd proponents seem annoyed that people aren't accepting their decision without question, when what they propose is a pretty serious departure from a pretty fundamental system design philosophy. I don't know what to make of that.
Re: (Score:3)
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?)
Re: Not resigning from Debian (Score:4, Insightful)
Death wishes are never cool.
But what do you think people should do instead of escalate?
Maybe accept that the larger group of people you're a part of has come to a decision you disagree with, and move on? People who can't let go of their personal hobby horse can be utterly poisonous to an organization, no matter how righteous they view their cause to be.
Re: Not resigning from Debian (Score:5, Interesting)
Maybe accept that the larger group of people you're a part of has come to a decision you disagree with, and move on?
That's not what happened, however. A very small group of people, divided in itself, reluctantly came to a decision that affects others — and these others do not clearly support that decision in the majority either.
People who can't let go of their personal hobby horse can be utterly poisonous to an organization, no matter how righteous they view their cause to be.
So you're saying that systemd is a mistake?
Re: (Score:3, Interesting)
people are talking seriously about forking Debian over this
No they are not,
Yes, yes they are.
and no they don't need to.
Yes, yes they will, because once systemd becomes the default init system, init scripts will suffer.
(And, even if they did, that's what Debian is for!)
The base Debian system should use the basic init system. If they want to offer the option to switch to another init, so be it, but making something new and not fully tested the default is daft and we all know it. Debian is the rock that many of us depend on whether we run Debian or a downstream distribution. It's been my go-to for ages specifically because of this stability. Debian stable is
Re: Not resigning from Debian (Score:4, Funny)
Look, no matter what you think of systemd, rewriting it in Visual Basic would not be an improvement.
Re: (Score:3)
The single biggest indictment of the anti-systemd crowd isn't that it will fail and waste everyone's time and eventually be replaced. It's that it will succeed and other software will come to depend on it. That's not a rational objection.
Re: (Score:3)
Comment removed (Score:5, Insightful)
Re: Not resigning from Debian (Score:4, Interesting)
Re: (Score:3)
Re: Not resigning from Debian (Score:4, Insightful)
Yet both sides believe the other side is the idiots.
And they are both 100 percent correct.
Who are you calling "immature twats" ?? (Score:2, Insightful)
If the Debian team never shove that unneeded thing down the throats to the users none of the heated exchange would have happened in the first place
And to call others "immature twats" you are showcasing yourself to the world how "mature" you really are!
Re:Who are you calling "immature twats" ?? (Score:5, Insightful)
If the Debian team never shove that unneeded thing down the throats to the users
Serious question here: how avoidable is systemd currently?
It seems the number of holdouts among the distributions is shrinking ever more quickly.
systemd seems to be incorporating ever more functionality in itself. That in itself should be a problem, but it seems that the equivalent functionality outside of systemd is being lost at the same time.
Not sure what the status is with the other stuff systemd is preparing to replace.
Add to that the increasing hard dependencies, like with window managers that expect systemd to offload session management and login onto and I'm not sure how feasable holding out on systemd is anymore.
Sure, if a sufficiently large group of developers were bothered enough with the presence of systemd they could set out to provide the functionality the traditonal way and form a whole bunch of projects, including some sort of desktop environment.
But it seems systemd managed to assimilate responsibilities more quickly than resistance could form and forking of projects to non-systemd dependent versions could occur.
Re:Who are you calling "immature twats" ?? (Score:5, Informative)
For what it's worth, I managed to purge everything systemd-related from my debian testing system the other day. I had to replace NetworkManager with WICD, which is a pretty good straightforward replacement (although you need to re-create your configuration). Also, I run KDE, so that made things easier.
As I understand it (if I correctly noted the packages which got removed), you can't run a gnome system without systemd; however, you can still run debian jessie with kde without systemd.
The only packages which are coming from the systemd source package on my system any more are udev and libsystemd0 - however, given that systemd-sysv and systemd-logind are no longer installed, I consider that basically a win.
libsystemd0 is only still there because cups-daemon and kde-runtime require it; but given that it only defines the interfaces, it seems benign.
udev [debian.org] and libudev1 [debian.org], despite being packaged as part of the systemd source, do not depend on it according to the package info...
Re: (Score:3)
" Let the forking commence." - i presume you've started the ball rolling with some code, how about pointing us to it?
Despite your attempt at superiority by expert-ism, perhaps non experts might have valuable input when the experts are behaving like children.
Under what circumstances do you think this is not going to be forked eventually?
Re:Not resigning from Debian (Score:5, Funny)
Re:Not resigning from Debian (Score:4, Interesting)
How systemd became Debian's default init system (Score:5, Informative)
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://bugs.debian.org/cgi-bi... [debian.org] (_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://wiki.debian.org/Debate, https://wiki.debian.org/Debate... [debian.org]) 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://lists.debian.org/debia... [debian.org] 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.
Re:How systemd became Debian's default init system (Score:5, Informative)
iwj's rebuttal to rra's write up:
https://lists.debian.org/debia... [debian.org]
Re:How systemd became Debian's default init system (Score:5, Informative)
And iwj's original comparison of systemd and upstart:
https://lists.debian.org/debia... [debian.org]
Re:How systemd became Debian's default init system (Score:4, Insightful)
Taking the requirements in turn:
So what? OpenRC has dependency built in and the added improvement of integration with kernel-level events would bring only a very minor improvement.
In my experience, this is solving a non-problem. I don't experience processes dying and needing an immediate re-start without any other action.
So what?
Not sure what advantage this brings.
Re:How systemd became Debian's default init system (Score:4, Insightful)
Just because you don't doesn't mean no-one does. There have been enough users as vocal supporters of this feature that it clearly is an issue to be considered, and not just a non-problem. I've once had sshd randomly crash. Very randomly. Nothing appeared to cause it and it has worked ever since. A headless server with no management console. I wonder to this day if I had another option than simply hitting the reset button on the front.
So what?
Not all of us are programmers who want to churn out lines of shell script to get simple software started. 200+ lines of scripting to start sshd on my system is a design flaw not a feature imo. By comparison the upstart file for sshd is 13 lines and achieves more i.e. process monitoring, event based startup and re-starting.
Re: (Score:3, Interesting)
I've once had sshd randomly crash. Very randomly. Nothing appeared to cause it and it has worked ever since. A headless server with no management console. I wonder to this day if I had another option than simply hitting the reset button on the front.
What if it was someone attacking your sshd and making it crash when it failed?
By automatically restarting it, you just allow the attacker to continue trying to exploit it.
By automatically restarting it, you don't solve the issue that makes it crashing.
By automatically restarting it, you, most of the time, don't even see it restarted, so really not giving you any way to solve the real problem.
It's not that I don't find process monitoring interesting, it's just tha
Re: (Score:3)
What if it was someone attacking your sshd and making it crash when it failed?
By automatically restarting it, you just allow the attacker to continue trying to exploit it.
By automatically restarting it, you don't solve the issue that makes it crashing.
By automatically restarting it, you, most of the time, don't even see it restarted, so really not giving you any way to solve the real problem.
It's not that I don't find process monitoring interesting, it's just that automatically restarting can bring more problems than it solves.
As with any service, the "correct" action upon a crash is probably dependent on what the machine is actually supposed to be doing. Take for example, a dedicated web server - having Apache do down when under attack and not attempt to recover would be bad since the attacker will have successfully caused a denial of service with very little effort. Compare to a private telephone exchange, for example, which is running a web server purely for management purposes - a crashed web server is not a disaster, the w
Re: (Score:3)
How about using /etc/inittab to monitor & restart your daemons like all good Unix admins are doing since last century ? ... you only know about RedHat's netutered inittab ? Too bad. Let's all switch to systemd because AC is too lazy to read a man page.
Oh
(Bitter because i just had to reinstall a Jessie machine from scratch after a filesystem corruption borked 2 system-d config files - the system would not come up even in rescue mode as systemd was spewing 2 pages of errors on the console then hanging)
Re: (Score:2, Interesting)
I'd just like to take the opportunity to thank you for your work. I have used Debian for many years now and feel I seldom get the opportunity to say how much I appreciate it. So, a big thank you to you and the many other hard-working individuals creating Debian! Don't let this argument stick to you. I hope you continue with other Debian stuff! You are truly doing a magnificent job!
Re: (Score:2)
What do you think is the greatest misconception people not liking systemd have about it?
Re:Not resigning from Debian (Score:5, Interesting)
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.
Re:Not resigning from Debian (Score:5, Insightful)
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 /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.
Re: (Score:3, Informative)
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 /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.
Well, systemd behaves according to classic "Unix Philosophy", see here under "Rule of repair":
http://en.wikipedia.org/wiki/U... [wikipedia.org]
A system shouldn't be allowed to boot if important disks are missing since this can lead to "silent" data corruption".
systemd does the right thing by stopping normal boot and just boot into a safe, minimal shell. A quick glace in the log file (journal) will instantly tell you (using red letters for emphasis) that fstab is broken in such and such a way. A quick edit with Vim can the
Re:Not resigning from Debian (Score:4, Insightful)
No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?
Re:Not resigning from Debian (Score:4, Interesting)
Re: (Score:3)
Pull your head out of the sand. The system did not come up far enough to do what you suggest even though it was clearly capable of it (since it did when sysvinit was in place).
Re:Not resigning from Debian (Score:5, Informative)
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 /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.
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. :-)
Re:Not resigning from Debian (Score:5, Interesting)
Re: (Score:3)
In the sysvinit scripts the philosophy is not so stark: the aim is to bring the system up to the greatest extent possible even in the presence of failures. If a single mount or service fails, we report the error and try to continue on. It's not perfect, but mitigation in the face of unexpected failure is never going to be.
If I make a typo when editing the fstab, I don't think bailing out is ever appropriate. The "nofail" flag is only useful for expected failures, and I think that the sysvinit script is c
Re: (Score:3, Informative)
In the sysvinit scripts the philosophy is not so stark: the aim is to bring the system up to the greatest extent possible even in the presence of failures. If a single mount or service fails, we report the error and try to continue on. It's not perfect, but mitigation in the face of unexpected failure is never going to be.
If I make a typo when editing the fstab, I don't think bailing out is ever appropriate. The "nofail" flag is only useful for expected failures, and I think that the sysvinit script is correct in not using it as a basis for unilaterally failing startup when in almost all cases we could bring the system up to a state where the admin can log in and rectify things. This is going to be incorrect from the worldview of a perfectionist, but it's certainly the pragmatic choice.
There are several problems with doing things that way; first of all, its is evident that it isn't uncommon for people to have stale or plain broken fstab entries. This strongly suggest that they are unaware of this, probably because if the system boots, people don't look in the log files. Finding such critical errors in legacy style syslog text logs aren't easy either; if you don't know the nature of the error, it is hard to grep for it.
So exactly because SysVinit cover up such fstab errors, they may remain
Re:Not resigning from Debian (Score:4, Insightful)
It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.
It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.
Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.
At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.
Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.
At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.
Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognise that advantage, and buy its products and support contracts.
I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.
It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.
Re: (Score:3)
Systemd to me seems overly complicated to the point where I can't work out how to fix things and more importantly (I might be thick), other people don't seem to be able to to offer assistance. I asked the questions properly, but the discussion ended with "dunno" as the result.
In the olden days, the sleep button on a laptop caused an acpi event. That was passed to a shell script in /etc/acpi which could then do stuff. Two sane options were to send the laptop top sleep or generate a fake keypress for XK_XF86S
A bit of background (Score:5, Informative)
Just posted on my blog with a bit more background: http://err.no/personal/blog/te... [err.no]
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2, Insightful)
First post was 8 full minutes after the article was published. This just demonstrates how far Slashdot has fallen in popularity.
Re: (Score:2)
Currently, it is not known if Tollef will cease contributing to Debian altogether.
Second to last line in the current summary.
Re:Not resigning from Debian (Score:5, Insightful)
It's been said that Ubuntu switched to systemd because they anticipated that Debian was going to do so, not because they really wanted to, but since Ubuntu re-forks Debian for a lot of its packages and development, as a derivative work it really doesn't have a lot of choice unless they want to make a clean break of it. With other distros also going systemd, inevitably like when Slackware was extremely late to the party with the whole libc5/glibc2 switch, a bunch of us will end up on Slack again, even without the advanced package tools that we've come to like with more modern distros.
Re: (Score:2)
Re: (Score:2)
It's sad that in the world of open/free software somebody can still be bullied out of their job by a bunch of people who, for whatever reason, don't like what they do.
So many people don't understand, the whole point of Open/Free software is that you can fork the source if somebody takes it in a direction you do not like, you don't pay for it and you do not get to dictate what the authors do with it but you are free to make it your own if you choose to. However some people have this entitlement complex whereby they think they can dictate the direction of somebody elses work, it's sad that these vitriolic people have not been put in their place. They do not contribute and they simply want something for nothing, that is not the way of free software.
It is great that you are staying on at Debian to continue your work there, it is terrible that you have been forced into that decision though and it does not bode well for the future of open source and free software.
Happens in the real world too. I have already been demoted at my job and am ready to be fired tomorrow and I am considering resigning. FYI I have positive work kudus from my fans at work and was a hero before moving to a new site.
I got blamed for things out of my control and my inferior who just got promoted over me got credit for me fixing them and the view was it was all my fault when 20% of stations didn't even have freaking Ethernet!
When it comes to a man's reputation bullies can certainly ruin your ima
Re: (Score:2)
So many people don't understand, the whole point of Open/Free software is that you can fork the source if somebody takes it in a direction you do not like, you don't pay for it and you do not get to dictate what the authors do with it but you are free to make it your own if you choose to.
In this case, you are suggesting they should have to fork all of Debian, because that's the only way to keep something other than systemd once Debian switches. Every package in the system has to be compatible with t
Re:Not resigning from Debian (Score:4, Insightful)
Never mind that with systemd, it goes beyond init. systemd as a project are sprouting tentacles everywhere, and projects closer to the user (Gnome for instance) is strongly encouraged to latch on.
This kind of tight coupling is unheard of in Linux history.
Re: (Score:3)
This kind of tight coupling is unheard of in Linux history.
Not true at all - stuff has been tightly coupled plenty of times in the past. Lots of stuff is very tightly coupled with udev these days, for example. And whilst I will agree that tight coupling is bad, its sometimes hard to see how it could be avoided.
Re: (Score:2)
Re: (Score:2, Insightful)
There is a difference between "attacks" and valid criticism. Calling everybody that criticizes systemd and its adoption into Debian a "troll" or an "attacker" is unfounded and represents an extreme form of trolling itself. One could get the rather strong impression that the systemd advocates do not want any dialog or have sufficient valid arguments to deal with the criticism voiced. Instead they revert to this form of primitive emotional manipulation.
Re:damn (Score:5, Insightful)
Ah yes, the "la la la la la I can't hear you" tactic. Fact is, people against systemd have voiced technical omplaints, including one on this very page, which the maintainer who just resigned admitted is a severe bug, equivalent to "shooting your foot off" (his own words).
It's the people pushing systemd that are busy pretending that there aren't problems and refuse to acknowledge the issues, because they're inconvenient for them.
Good riddance. At least OpenBSD doesn't have this BS where they pretend a bug is a feature.
Re: (Score:3, Insightful)
Fact is, people against systemd have voiced technical omplaints, including one on this very page, which the maintainer who just resigned admitted is a severe bug, equivalent to "shooting your foot off" (his own words).
You mean the bug in a not yet released version of the OS which will be fixed before release?
You guys are incredible. Last week I complained about everyone expecting software to be 100% perfect on it's first release, and now you are expecting 100% perfection in the betas?
Grow up!
Re: (Score:2)
Or why don't they put all of that time and energy into implementing an alternative to systemd.
For example, by implementing a systemd-independent logind.
Re: (Score:2)
In Jessie there's one mega 'systemd' package but 1 module that specifically invokes it is 'libpam-systemd', from which dependancies sprawl out.
Maybe separate out logind via the 'systemd-shim' mechanism?
Re: (Score:2, Insightful)
These 'attacks' do not prevent people from working on what they want to. Stop equating heated debates online with getting mugged in the street.
Re: (Score:2, Insightful)
Trolling is not disagreement.
Re: (Score:2, Troll)
Labeling people trolls does not invalidate their disagreement.
Re: (Score:2)
Go right ahead. There are plenty of distributions that use it.
Re: (Score:2)
Easily done. Given the lack of dependencies on sysvinit, it just drops right in. Feel free!
Abusing the bug tracker (Score:5, Interesting)
Debian have many good sides. It also suffers from fractions; the problem isn't so much that people disagree about some time petty technical things, but that they abuse the Debian bug tracker and governmental system in order to feud their petty wars on usually innocent package maintainers. By filling "political" bugs together with a lot of whining and twisted representation of facts, and then run and complain to higher ups in the hierarchy, they can force the package maintainer into endless, repeated explanations why things are like they. You can basically force the package maintainers to always be in defensive position. Not fun at all.
In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.
The "anti-systemd" faction probably just think they are fighting with their backs against the wall, trying to claw out a place in Debian with any means necessary before it is "too late".
But if they keep on attacking Debian developers like they do now, I think their strategy will backfire. Before the bitter systemd debacles started, most Debian developers where probably quite keen to support non-systemd inits too. But this rather poisonous war just never seems to end, so some Debian developers are starting to think, that the only way forward is an outright banishment of official SysVinit support after Jessie is released.
Re: (Score:3, Insightful)
In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.
Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?
Re: (Score:3)
Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?
There is firm backing behind systemd as default init system in Debian. There probably also is a lot of willingness to support more than one init system.
The problem with the eternal war by "committee weasels" and "paper warriors" is that it simply shows that continuing supporting SysVinit is the wrong thing to do for Debian, since it will be used as a permanent excuse to feud an eternal war and "retaliate" as you describe it.
At some point Debian will have to make a decision between kicking out SysVinit for
How would anti systemd zealots do terrorism? (Score:2, Funny)
Mail a bomb, presume the bombing will succeed without error, don't monitor if the bomb actually had gone off and don't send another bomb if the first bomb fails. Any other deviation from this terrorism process is not the proper UNIX way!
Re: (Score:3)
If the first bomb fails, you don't keep mailing bombs hoping one succeeds, you have to figure out why the bomb failed and fix that problem before you try a second time or some other method of achieving the same goal.
Re:Don't like Systemd... fork it. (Score:5, Insightful)
Not so easy since it is in the process of becoming a dependency for most of the base system. Currently, for much of it, it is an optional one, but that is slowly changing. This is redhat's embrace and extend.
Re: (Score:2, Interesting)
No one is forcing you to use it!
Yeah, it's not like other projects like Gnome 3 are deliberately making themselves dependent on systemd, is it?
Re: (Score:2)
To be fair, as of right now it's only the dependencies of gnome force you to use systemD.
Come the next couple of versions though gnome's entire desktop environment will be dependent on systemD, why?
They are going to link it to systemD's handling of c-groups to do per user and per process sandboxing.
Re: (Score:3, Interesting)
Well, no, it's not deliberate. They are dependent on systemd because ConsoleKit is dead and rotting, and no other system provides the features they need. They would be happy [gnome.org] to lose that dependency if there was an alternative.
But you're not helping, 0123456
0123456: What do you mean, I'm not helping?!
I mean: you're not helping! Why is that, 0123456?!
...
They're just questions, 0123456. In answer to your query, they're written down for me. It's a troll, designed to provoke an emotional response... Shall we con
Re: (Score:2, Insightful)
Re:Opposition is from a small elite (Score:4, Interesting)
I dont see an issue with systemd,
the issue isnt with systemd per se, the issue is systemd becoming a dependency of things that should not require it. for example, since systemd decided to eat udev, that means that every package that used udev now needs systemd. if you use any of the major desktops, it is a requirement. one the upside, it's fuelling the development of other desktops environments.
... let people who do not want systemd simply configure their system either so that systemd will start regular sys v init or bsd type scripts, or let them change /bin/init to point to the alternatifve init system of their choice.
there is a problem with that, it means systemd is running. there is an additional opposition to systemd itself, the most universally relevant reason being that systemd has a HUGE attack surface. the other reasons all feed into this one issue, it's a blaring and blindingly bright security issue.
btw, if you are GNOME2/MATE holdout trying to escape systemd like me, consider using LxQt [lxqt.org]. it's still a work in progress but it's usable as an everyday desktop environment.
LxQt repo (works with debian jessie):
Re:Opposition is from a small elite (Score:5, Insightful)
I honestly don't really care about this whole init debate, from a technical standpoint. I don't see a compelling reason to prefer systemd, and given the fact that it's changing a system that's worked fine (with a few tweaks) for more than 30 years, I'd just as soon stay with the old style.
But there's a few extremely troubling things I see from the systemd side:
- A complete disregard for precedent. Yes, it's good to be open to rethinking how we do things, but the fact is that Unix has worked for a very, very long time. There's many reasons for this, but the "Unix philosophy" is undoubtedly one of them. systemd is by no means "Unixy". Reading a directory of symlinks and executing shell scripts is simple, and minimizes the logic built into init - which a lot of people believe is a good guiding principle for pretty much the entire OS.
- An uncompelling value proposition. I don't much care about boot time (who reboots anymore, anyway?), and with Upstart my boot times were pretty quick anyway. If I'm running a server, I don't even care about boot time at all. What I do care about is simplicity of understanding and management. Systemd has failed to convince me that it does anything I want. Iin the absence of anything particularly valuable I'd just as soon stick with existing, robust, well-understood systems. I don't have my tonsils out for fun either - it's not change aversion to stick with things that worked fine in the absence of a compelling reason to change things.
- Poor architecture. The init system should be as simple as possible. Let it start things like dbus if the system needs it, don't build them in. Discrete components that are loosely-coupled, please - tight coupling is a black mark against virtually any multi-binary software package, but especially in the boot process. Building things into the startup process just reduces the number of things you're able to remove from a system that doesn't need them. DBus is a great example of this.
- Lack of concern for the server use case, and sysadmins in particular. People have raised concerns - many legitimate, some not - about systemd approaches, and the developers and (unusually rabid) community treat those concerns with indifference bordering on contempt. Here's a hint: when a group of competent professional acting in good faith doesn't understand why something is a good idea, it's your fault for having explained it poorly. Especially for an init system - the "average" user never did care about how his system booted! (Which, by the way, is something many systemd folk seem to disagree with - they say users are clamoring for it!) But the sysadmin does care, and has to manage it - best to treat him with respect, not contempt.
- Tying perfectly-good cross platform programs to Linux. systemd is, unabashedly, a virus. Why my window manager or graphics program has to depend on init, I don't know. But as long as it does and that package is systemd, it kills cross-platform compatibility. Compatibility is what got Linux off the ground, and with the exception of systemd it's not too hard to keep it going. Don't throw this away!
- Most importantly, the community is extremely toxic. What is Linux without community? Sure, there's bickering (since when is this bad, by the way?), but at the end of the day you have one of the most powerful and important pieces of software the world has ever seen. But the systemd mess feels like a Microsoft move, and the idea that there's a "Microsoft of Linux" able to move so unilaterally is extremely troubling. People voice concerns about systemd, and if they seem recycled it's because they haven't been well refuted! But the proponents are vicious, and vocal to an extent that makes one suspect astroturfing... which is even more troubling.
And the most troubling aspect of this toxic community are the attacks on opponents. The parent's comment is not the first, nor even the tenth, attack I've seen on a systemd opponent to claim that it's just someone afraid of losing their job and trying to set up some sort of
Re: (Score:3)
- A complete disregard for precedent.
There are precedents to changing init systems on unixy systems: Mac has launchd, Solaris has SMF. Sysvinit itself was called an aberation when it was introduced, too, doing away with the much simpler BSD-style init.
I would consider systemd very unixy: It has lots of small tools, each designed to do something well. These work in concert to accomplish complex tasks. This whole "unix philosophy" thing is basically in the eye of the beholder.
- An uncompelling value proposition. I don't much care about boot time
Boot time is a side-effect.
Better hardening options for services is a
Entropy always goes downhill (Score:3)
God. OK. While I agree with you in many things, there are a few things that you seem to have missed:
1. Debian (or general-purpose Linux generally) isn't simple anymore. These days are over and there's no way to get them back. Really. This is true for EVERYTHING in Debian/Linux and in every other OS. General-purpose systems tend to become more complex to be more easy on the outside. And there's no way around that.
2. The "community". I don't even know where to start. The "community" has turned into a mob that
Re:Opposition is from a small elite (Score:5, Insightful)
Lets say you have a laptop that is on one network and goes to sleep when you close it and arrives in a hotel room on another network? How would you do this with init without some serious hacks?
You don't, you open your laptop in the hotel room and select the new network. Was that so hard? why in the hell do you think the init system should be involved? You do show what's wrong with the systemd design philosophy, that's for sure. I'm glad one of the crappers of needless complexity has resigned. One down and a few more to go, and maybe Debian will be a good distro again....
Re: (Score:3)
I wouldn't hold out Apple as example of leader to follow for stable init or daemon system; my work macbook pro is still screwy booting after yosemite upgrade. We won't even talk about the plist files for daemons for mac osx server, or how they sometimes get ignored
Re:Opposition is from a small elite (Score:5, Insightful)
Re:Opposition is from a small elite (Score:4)
Having a 1000 different components doing 1000 different thing in 1000 different ways managed by 1000 different developers does not make an argument invalid and doesn't make the problem solved. For the most part people thank their lucky stars when a linux system works at all (unless of course it is a server sitting in the corner humming away on one task).
You're absolutely right though. The task is not part of the init system. It should be offloaded to a central system management daemon. Something that monitors hardware and system events and acts accordingly. It should have a fancy name like systemd. Heck while we're at it they can manage locales, login sessions, and the bootup process too.
Oh what you thought systemd was just an init system? Maybe you should read the project page sometime.
Re: (Score:3, Insightful)
I think you have it backwards.
SystemD is forced down our throats by a small elite at Red Hat. This is, very obviously, a move right out of Microsoft's playbook.
if you want Windows, use Windows. F250 vs Corvette (Score:5, Insightful)
> what they think is the right way. That ties into what the mentality of this elite crowd is. For years this elite crowd has fought at every turn any attempt to make Linux easier to use for common, everyday users as a Windows alternative.
For decades, not just years. The Unix way predates the Windows philosophy by a rather significant margin. Those who appreciate the Unix philosophy have been protecting it from turning into something else for decades.
Imagine you joined the Ford F-250 design team. Would you insist that the F-250 should be redesigned as a Corvette alternative? Would you be surprised when the veteran members of the team pointed out that the F-250 is a work truck, not a sports car?
The Windows way works well for grandma to look at pictures of her grandkids. Mac may be even better for that use case. That's not suprising, as those systems were designed specifically to be "easier to use ... for the common everyday user." The Unix / Linux approach is designed for a different role or two; client/server first and portability also. Linux is designed to work in your router, your phone, and your web server. It's no surprise that Linux makes a better server than Windows, a much better phone, and works well on a router where Windows can't run at all. It was designed to have that flexibility.
If you want something that is just like a Windows desktop, your best bet is to get a Windows desktop. Linux isn't Windows, and of it tries to be like Windows it'll stop being Linux and being good at what Linux is good at.
Re: (Score:3)
That is the part that is the most troubling. It is this very anti-FOSS "systems or nothing" that bothers me.
If the Debian team refuses to give me a choice, I'll be moving to FreeBSD after twenty years administering Linux. It is that simple.
Re: (Score:3)
I've been playing with it for about six months now. I'll probably begin the migration of our LAMP stacks and Samba file servers over to FreeBSD in the New Year. We're going to be building a new database server in the next few weeks, and initially it was going to be another Debian install, but at this point I'm thinking of altering the requirements to use FreeBSD. It's only mysql, so it's not like if it doesn't work all that well I can't push it quickly to a Linux server.
I simply do not like the direction De
Re: (Score:3)
You realise the whole reason he is leaving the Debian systemd team is precisely because of attitudes you've just displayed in your post. Deciding to heave a _volunteer_ position is his right, and it's rather impressive that you can get so angry about it.
Still, I had a good laugh. An Anonymous Coward heatedly taunting someone else as a Coward. Hypocrisy is humorous.
Re: (Score:3)
My problem with systemd is not the features. It's the way they are implemented.
I'm not sure that a slightly faster boot-up or easier package maintenance can ONLY come about by completing abandoning every vestige of a well-established init system. And I'm pretty sure that if we wanted to, someone could make the same features work with SysVInit too.
Feature-creep is the real problem. For the cost of slightly faster bootup, I lose an awful lot of old functionality that's been around forever, for no reasonabl
Re: (Score:3)
Maybe you have mis-identified the "bullies?"
SystemD is to Red Hat what OOXML is to Microsoft. They can claim it's "open" but really it is a vendor lock-in scam.
SystemD is a decision made by a few some execs at a for-profit corporation. It is absolutely not something the community was asking for.
I am sick of this Microsoft-like "the decision has already been made, why are you arguing? SystemD is inevitable, just accept it. Because we say so. So FU take it and shut up."
I am sick of the astroturfing bullshit c