Slashdot Mirror
Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team
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.
I am not resigning from Debian, just from the systemd maintainer team.
the trolls win, and by that everyone else loses :P
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!
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... (_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...) 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... 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.
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.
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?
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.
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.
An elite crowd trying to force on everyone else what they think is the right way? Thats one of the many reasons people are against systemd! One thing I don't understand is how in the hell it is considered ok to have this in Debian STABLE? Maybe, in Fedora or OpenSuse but Debian stable???!
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.
> I dont see an issue with systemd, since it allows for sys V style init to be used.
You're forced to install it due to dependency hell and lots of major packages are relying on it. Depending on a particular init system is a bit crazy.
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!
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 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 continue?
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. it's still a work in progress but it's usable as an everyday desktop environment.
LxQt repo (works with debian jessie):
Anons need not reply. Questions end with a question mark.
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Just posted on my blog with a bit more background: http://err.no/personal/blog/te...
Lose the hostility, coward. What do you care whether moves on? As a FreeBSD user, I can assure you he won't be sorry learning and using it, so nobody is a loser.
Railroading by a small elite.
FTFY.
Whatever they wanna say, they are more than welcome to share with the world. It's a free country, and with free software, you get Double Free! They can choose another distro, or they can uninstall systemd (see instructions here: http://forums.debian.net/viewtopic.php?f=5&t=112364 ).
But using verbal violence against a developer is unacceptable, and immature. So I stand behind my prognosis.
All those moments will be lost in time, like tears in rain... time... to... die...
Like I said, they can voice their opinions, switch distros, or make contributions to non-systemd projects. Nothing is an excuse to use verbal violence against a developer who has contributed thousands of hours to the Debian community.
All those moments will be lost in time, like tears in rain... time... to... die...
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.
One down, four to go!
Remaining team:0
Michael Bieble
Marco d'Itri
Michael Stapelberg
Sjoerd Simons
Tollef's smart to get out before Jessie is released. The looming spectre of broken systems that are going to haunt sysadmins everywhere when they update their Debian systems to Jessie is going to phenomenal. Who's gonna wanna stick around for that grief?
Sure, they'll all cry about "muh feels!" as the reason for leaving, but when you abandon a project (systemd packaging) this late in the schedule, everyone knows it going to be because you're trying to distance yourself from the inevitable shitstorm that going to happen.
I think you fail to understand that an init system is very much about managing run-time dependencies, the way package management tools deal with install dependencies. Just like you can't just mix and match between deb, rpm and tar.gz and expect them to play nicely together all services need to describe their dependencies in the same way, systemd doesn't have sysv's concept of run levels so they don't mix. The compatibility basically means you can create a simple wrapper to call sysv init scripts as the implementation of a systemd service, the actual dependency management will have moved to systemd.
Now if every project provides sysv init scripts, getting rid of systemd would be easy but you wouldn't actually get any benefit either so that won't happen. Some projects will stop maintaining those, stop defining their run level and just describe their systemd dependencies or for new projects they might not exist at all. If you want to run without systemd you have to map all those dependencies back into run levels for sysv init to run. I'm not really sure what you're asking for because it simply isn't reasonable to pick your own init system, any more than you pick a package management system.
The worry is that when the momentum is big enough to create a change that you pick a bad choice you'll be stuck with. That said, I think sysv-style scripts need replacing. Dependency management through run levels reminds me of programming with line numbers in BASIC, it's so 1980s and bad practice to boot. Services should describe what they need to run, which sysv totally fails at. Do you need systemd which seems to want to rewrite everything including the kitchen sink? I don't know. But any replacement that provides named dependencies so services depend on other services the way packages depend on other packages would be a step forward.
Live today, because you never know what tomorrow brings
> 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.
It is monolithic. It has many components, but no alternatives to any of them.
It encrypts (writes binary) logs and offers only itself as a way to read them.
It encourages non-kernel systems to rely on it.
NSA?
How long can (Open)BSD and Slackware hold out against this perversity?
Are you paranoid if they really are out to get you?
--
It was a dark and drunken night. Four shots called out -- drink me.
And the criticism 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 them.
In hindsight, it's obvious now that systemd should never have been integrated into Debian the way it has been. Debian should have indeed been forked, but with systemd going into this fork, rather than traditional Debian. Only after it had been proven as a suitable replacement should it have ever been considered for integration into mainline Debian.
Personally, I don't think the Debian project will survive. It may survive in name, but it will become weakened and irrelevant, like the XFree86 and GNOME projects have become. This truly is one of the most disturbing events to have hit such a major open source project. The worst part is that it's all so unnecessary. Debian didn't have to die as a project, and it especially did not have to die thanks to systemd of all things.
I've read all of the comments in this thread (at -1), and I think you're the only one to have truly nailed what's going on here.
Systemd has been a total disaster for many Debian users already. The animosity toward it doesn't come out of nowhere. It comes out of a situation like this, described as a "horrible experience". People are having their Debian systems utterly trashed thanks to systemd being forced upon them during routine updates.
I, too, fear that these early disastrous results will just be amplified many times over once Jessie starts to become more widely used. There will likely be problems, and they won't be pretty. I wouldn't be at all surprised if Debian's reputation is completely ruined. That's a real shame, given how many decades of effort have gone into making it such a respected and trusted distro.
This is also where FreeBSD could make a triumphant comeback. If the FreeBSD project play their cards right, and end up on the right side of this (which is obviously taking a strong stand against systemd, and standing in favor of stability and reliability), they could win over many refugees who are fleeing Debian.
It would be a shame. A lot of people worked hard for POSIX, and I think POSIX does have a purpose.
Seems like it would solve a lot of problems.
It would give Debian users years of use while the systemd thing got sorted out.
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....
Downstream dependencies should NOT be an issue. The problem is when the downstream software depends on a function that systemd provides which you can't achieve without the rest of systemd. I personally am a fan of what systemd is trying to do but I fully agree with all the dependency complaints. It's not healthy when large projects depend on the functionality systemd provides, it should be optional.
All this makes me wonder why someone can't build some other piece of software which would perform the required session management in this particular case? It's not dependency for nefarious means, it's dependency which provides a specific feature that a programmer would like to use. Why can't that be coded separately from systemd by someone other than the systemd maintainers?
I cannot find the option any more to filter out AC posts. It is very clear that there is a concerted attempt to deliberate inflame on here and all the inflame posts are done by ACs. How to ignore?
Which, by the way, is something many systemd folk seem to disagree with - they say users are clamoring for it!
You are right of course. No one cares how their system boots.
Systemd however is much more than that and provides central management of the boot process, running services, hardware, logging, user login session, etc.
Their biggest problem I think is that systemd has been miss-marketed. Anyone who calls it an init system is missing about 90% of the point. Likewise anyone who thinks that systemd's value proposition is boot times, it's not. Replacing init is a side-effect of what it is doing, not it's primary purpose.
Was that so hard? why in the hell do you think the init system should be involved?
Yes that was hard. You expect me to remember every time I'm in a range of a different wifi point or network outlet to change some system setting? What is it 1995? Your only saving grace here is that you're not asking me to reboot.
The init system isn't involved. System management is. When a network interface changes state without bouncing then all associated network services should reset to handle the new case.
Your world doesn't seem to reflect that, but your world also doesn't reflect all use cases for PCs. Systemd is attempting to suit everyone and are getting grilled by the "I don't see why that's an issue, so no one else should either" crowd.
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
If I'm running a server, I don't even care about boot time at all.
You've apparently never had to manage a server that took 10, 20, or 30 minutes to boot up, excessively long boot up times are a common occurrence in enterprise environments. After a system update/reboot I want to be able to ssh back into the box as soon as possible, if I can't ssh back into the box within five minutes I'll typically have to lunch a recovery console or submit tickets to have hands & eyes go look at the box for me... it's a major pain in the ass. If a watchdog timer bounces a box I want it to come back up as soon as possible so I and the other service delivery teams can start troubleshooting why it failed. Fast boot on servers is very important to administrators, we have SLAs, maintenance windows, managers, customers, and service delivery teams to deal with.
I see you're horribly misrepresenting problems and their solutions in other threads too. Apple switched to launchd because they had a real use case for it. They didn't have to grow (k)dbus, because they already had the many IPC mechanisms built on top of mach ports. They don't have to worry about the server because the server isn't their market, so they can go full steam ahead with desktop features. Of course, you're still trumpeting that network example, and of course, you're still wrong. The init daemon has nothing to do with the network in your example, the network management daemon does. On Linux that's NetworkManager and on Mac OS X that's networkd (IIRC). Stop using that example. It's terrible.
Also stop talking about event driven daemons as if you know what you're talking about. With NGINX, being event driven is referring to how it's implemented. It has an event loop that receives requests and queues them up to be fulfilled. You can only very, very loosely even begin to compare them to init systems in function, but you're sure as hell trying. Also please don't mention Windows services. Some of us have had to actually administrate that heap of undebuggable shit.
It's immature twats all the way down...
But the system management would need to probe. Now imagine every app in the Linux distro doing the same thing. See a problem?
According to the wikipedia entry Init does more than just act as autoexec.bat and monitors processes and exhorts to runlevels for things like X mode or stay in a console.
In my world it makes sense that the OS knows what is going on in real time. It is debatable if the init processor should be the one to manage this but seems most logical. Read the part on the bottom and the replacements?
No need to get mad or personally at me. I am just stating init is not perfect. I have seen ugly init scripts that try to mimic a lot. The idea is quite powerful and kind of like the idea of servers that react differently to conditions such as a high load, hack attack, or one of the nics going down etc. If you program the events the init replacement can take care of a lot of stuff where you do not have to have scripts and other daemons which are designed to work with 1 app try to interact with several to do what you want.
System management is init as it launches the processes so it seems logical and it doesn't have to be ugly or complex. You simple state the event and what you want to happen next ala NGIX has over apache httpd files. SystemD in its current form does have issues from what I read even if it is not a good implementation but I am no expert.
http://saveie6.com/
..You've apparently never had to manage a server that took 10, 20, or 30 minutes to boot up, excessively long boot up times are a common occurrence in enterprise environments. After a system update/reboot I want to be able to ssh back into the box as soon as possible,
Some of us have, and know *exactly* why various servers take time to boot, and know that systemd would not help appreciably speed up the process one significant iota.
Here's a clue for one machine, data sanity checks...and they occur after most of the init scripts have done their respective things, I'd rather that they be thorough than speedy before the server goes fully live as far as the end user is concerned, funnily enough, so does the end user of said data, that's why the sanity checking is there as that's the service they're paying for. The actual OS/Bios part of the boot process accounts for approx less than 6% of the overall boot time.
Another box, the init scripts part of the boot process takes about two minutes, the setting up of the firewall, IDS rules, etc. takes approx 15 minutes (the rules are complex, there's a massive blacklist and other fun things), on a box with an average uptime of 236 days this is a pretty damn insignificant fraction of a percentage 'idle boot time' (and, incidentally downtime for the section of the network that the box protects - compared to the upstream ISPs downtimes/outages[another story entirely], it's nearly non-existent)
Another server, fairly lightweight, boot time 3 minutes, uptime averages about 130 days, so maybe systemd could slash the boot time to less than 1 minute, wow, that's a whole 2 minutes 'saved' over 130 days..not even time to brew a decent cup of tea..
And I could go on, and on, and on...
Fast boot on servers is very important to administrators, we have SLAs, maintenance windows, managers, customers, and service delivery teams to deal with.
No, reliable boot is very important, fast is just icing on the cake if it can be achieved without sacrificing stability.
As to SLA's etc, that's why we cluster, virtualise etc. etc.
Maybe they figure they got us by the balls (note I didn't say they're right). The desktop market in linux is virtually nonexistent. Maybe it's a case of an honest desire to improve things while figuring a bit of lock-in couldn't hurt them. Of course this doesn't mean poettering, kay and friends aren't issues for the community. ..or maybe systemd configuration is more easily squeezed into a certification test they can charge for.. Who knows..
Actually using SYSVINIT already handled this quite well. Mainly because it was NETWORK MANAGER's job. Not Init's job, to handle network connectivity. I close my laptop, it sleeps, I open it, network manager fires up my wifi and connects. This argument is already invalid because it's already been solved by network-manager.
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?
init doesn't control the network, and it never has. it only starts the network. you use a network managing daemon to handle rejoining previously-seen access points and the like.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Dependency management through run levels reminds me of programming with line numbers in BASIC, it's so 1980s and bad practice to boot.
There's nothing wrong with run levels. Dependencies aren't handled through run levels alone, they're also handled through start order. But the proper answer is to add something to /etc/default/package or directly to the init script to handle dependency checking, it's actually really simple.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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?
init doesn't control the network, and it never has. it only starts the network. you use a network managing daemon to handle rejoining previously-seen access points and the like.
The problem is you have each thing doing checks all the time every 30 seconds and ugly scripts to do this. Especially if you want to do more than 1 thing from an event.
Init does processes, states aka runlevels, and other things. Not just loads the OS in a unix autoexec.bat. So wouldn't the logical way to do this would be to use something like Solaris version of system control manager (I think it is the name) to load this from an XML file? You just state what do for each thing and the system runs on its own with minimal configuration or complexity and maximum performance. SystemD may or may not be good. A lot of people fear change and I do not mean this as an insult. I think people do not see a benefit they do not want to learn something new which is why people obsess over the ancient XP and refuse to change. Unbelievable with that ..
Anyway yes init controls processes and threads and states so it makes sense it would do this correct? Unless you want each daemon and component to do its own checking and not integrate with each other?? This is the mess Linux does now.
Apple, Ubuntu, and Sun ditched init for that reason and why we have tons of inet alternatives. Something needs to change.
http://saveie6.com/
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 and libudev1, despite being packaged as part of the systemd source, do not depend on it according to the package info...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Then why did Apple get rid of init years ago?
Apple is an example of good UI, not system design.
"First they came for the slanderers and i said nothing."
All this makes me wonder why someone can't build some other piece of software which would perform the required session management in this particular case? It's not dependency for nefarious means, it's dependency which provides a specific feature that a programmer would like to use. Why can't that be coded separately from systemd by someone other than the systemd maintainers?
Systemd is also somewhat know for having no stable interfaces between its parts; combined with the increasing large number of parts it has, one would need to implement quite a lot to handle the required functionality. Systemd does have a chart of its API stability promises, but it looks to be last updated a year ago.
FWIW, I ran Debian Jessie with sysv for a while - and for about a month it was impossible to login via gdm (workaround was to switch to kdm or lightdm), so there's already been (testing-)user visible impact.
This is all very frustrating, especially since I really like the init/process-management parts of systemd, but not the glomp-up-all-the-projects and explicitly not working with others parts...
" Let the forking commence." - i presume you've started the ball rolling with some code, how about pointing us to it?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
I think it takes a much braver person, mid-flow, knowing they are going to attract vitriol, to stand up and say "Sorry, I don't think I can do this". Only cowards are subject to peer pressure like yours.
How many large projects would be saved (maybe we couldn't say they weren't delayed or hindered, but still saved) by someone stopping in the middle saying "It's too much, I can't do it". Rather than the management-ese of "Let's push on through anyway", I'd much rather someone said.
It's also an indication of the state of the project. Say you have poured your heart into a project. And then realised that it's not going to work, it's not what you thought it was, it's too much work for such an outcome. Are you saying that you shouldn't say "stop"? Or at the very least "Sorry, I'm out". If things aren't heading where you thought they would be, and you can't steer the ship back to the right course, it's better to abandon it than help it crash into the rocks.
Sure, it sucks to be the guy that takes over, but that's not his concern because he WAS the guy that was doing all that stuff already - and they are all volunteers, anyway. I believe it says in the various Debian stuff about how nobody should feel obliged to continue in their post if they don't want to.
A coward would keep their heads down, run the ship into the rocks, then quietly slip away. Or even just say nothing and not do any more work. It takes a person of character to announce "I'm abandoning" and jumping into the ocean first, alone. At least then, everyone knows where they stand.
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 reasonable reason. There's no reason logs have to be binary, etc. in order to make that work.
And as has been discussed here before, most of systemd's nice features come about because of things like cgroups and other new functionality, not systemd itself. Make SysVInit cgroup-aware and things could be an awful lot nicer.
Standardising on a format for init files isn't worth completely abandoning all the previous init system and every Unix principle for. But the only people who care about that are the programmers and geeks, not the "so long as it just works" desktop users (of which Linux apparently has a surprising amount nowadays).
I agree that resorting to threats is a little over the top. That being said, any product/service/whatever--yes even free ones--are ultimately supported by their users/consumers.
I've been a Debian user for over 15 years now and I didn't get a vote or a say in the matter. It was a small split-vote that had to be over-ruled.
If this was to be voted on by Debian users globally, any idiot that knows anything about Debian would know that it would overwhelmingly be voted against systemd and to keep things the way they are, even if only for stability reasons.
So, that said, I don't feel a ton of sympathy for the backlash. The end-users may be marginalized the majority of the time but when they feel undermined they will have their say. This is what is happening now.
The sad part is that I know a lot of old school linux users that have had long careers and are affected by this and are quietly switching over to the BSDs or just trying to deal with systemd as best they can despite the hack jobs necessary to get things working. Their insightful opinions aren't being heard or voiced.
I think a Debian version with systemd should be forked but regular Debian kept as it is. Let the users feedback help decide in the months ahead. Not shove a split-vote decision down everyone's throats.
Well, this is developers voting with their feet, isn't it?
xkcd is not in the sudoers file. This incident will be reported.
So have a go at Gnome 3 developers and get them to produce a system thats not dependent on systemd.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
"No, reliable boot is very important," - yes, so is speed if you have a branch office full of customers in a queue waiting to be served. 15-20 minute boot time is painful
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Well that's kind of my point. Systemd does the system management and acts as an API to allow other apps to figure out what's going on. The "every app probing" problem is exactly one of the things it tries to solve by being fundamentally an event driven system.
Some info on the init system:
You're right, it is more than autoexec.bat. Unfortunately what it acts like is 7 different autoexec.bat files more than anything. Everything it does other than it's single core number 1 thing is a kludge. The init system sits and catches orphaned processes. That's the only process it can keep track of, one without an owner. When you start sshd it starts and then it forks, often more than once. The old sysv init system had no way of tracking the PIDs of the forks so it writes to a file what the PID was and hopes to god that it doesn't change. This leads to scenarios where a process may crash and you type for instance "start sshd" and it says it's already started. So you say "stop sshd" and the system says unable to stop the PID doesn't exist.
The wikipedia entry says the biggest problem with sysvinit is that it is a serial starting process. I think that couldn't be further from the truth, few people care about how long it takes for a system to start up. Tracking of processes, and tracking of events is what my main gripe is. Such as the typical sysv init method of booting up a system, eth0 didn't come up because it doesn't have a network cable plugged in, oh well start httpd anyway, nope that fails because eth0 isn't present, and on and on.
The other issue you touched on is that it tries to do a lot with very little. Init scripts are powerful, but the process is endlessly duplicated. When every init script on the system does the same thing before starting a service (like writing PID files) its time to consider handing that process over to a supervisory system.
Honestly I actually like Upstart the most. On one of my ubuntu systems the upstart script for sshd is 11 lines, the init script is over 200. Both get the job done equally well, except that sysv init will blindly start it even if network has failed and upstart will only try to start it if the network is present.
Also runlevels were a workaround for lack of an event driven process. You could jump from runlevel 2 to runlevel 3 for instance to bring up networking and all associated software, runlevel 5 to bring up a GUI, runlevel 6 to commence a system shutdown etc. This is effectively superseded for any async event based system. They weren't a bad solution in their time, but the ideology is dated imo.
Ultimately I think EVERY init system has issues. The biggest problem with systemd is political not technical (1. ramming it down users throats, 2. having downstream applications depend on it).
It's no surprise that Linux makes a better server than Windows
debatable
, a much better phone,
debatable
and works well on a router where Windows can't run at all.
debatable and factually wrong.
You see your problem is you say one thing is super flexible but shouldn't include one thing you don't like. Well that's just it, Linux IS super flexible, and despite the bizarre rhetoric of the "get your crappy desktop init system off my server" crowd, it actually IS still flexible. So far every argument against systemd I've heard from the server based crowd are from people who should just spend 5 minutes to RTFM and just setup systemd the way they want. In each case it already had the features people were asking for (not auto restarting processes, dumping logs to rsyslogd, ignoring system events.
syslogd can be very small and run on your router, or it can be massive and manage your entire desktop. The choice is yours, but first everyone should actually read the manual.
"This is redhat's embrace and extend."
This is pretty much exactly what this is about. Redhat wants to control the direction of linux, and they don't seem to be too fussy about how they achieve this.
This is the third init system in RHEL is as many releases (RHEL5 = sysv, RHEL6 = upstart, RHEL7 = systemd).
Given that the majority of RHEL installs are servers, it puzzles me why they've been increasingly hostile to sysadmins.
RedHat is loosing the cloud/cluster market to ubuntu and debian, and since redhat's stock price have been inflated based on the expectation that redhat would dominate that market, they quite desperately need to start dominating.
systemd's init componet is not a bad idea and it's not a new idea, but it's being pushed out way to fast as a part of a strategy to retool the entire linux stack to a specific vision that redhat thinks will put them back on top and is growing feature's faster then the team behind can fix bugs. And this creates a potential mess, i gues most sysadmins are growing concerned about Debian 8's stability for that reason.
In most existing cloud/cluster designs monitoring and re-spawning is a part of the cluster support infrastructure and not a feature of the node operating system. this means all you need is for init to kick up the cluster-agent and let the cluster-agent decide on services to run on the node based on instructions from the cluster-manager. In that setup we dont really care about init features. Neither do most desktop enviroments(gmome3 being the exeption)
Redhat needs systemd to be a cluster-agent and not just an init system because they dont have a cluster-agent anyone wants to use, which is where we get almost all of the pushback. Had systemd stuck to the feature set of sun SMF i doubt we would have seen the kind of civil war we see now unfold in the debian camp.
For the stand alone system systemd sort of dont break anything important but if you already have a cluster-agent running it will need to be rewritten to s or work through systemd's addon services which is something you dont want to do in a routine platform upgrade from debian 7 to debian 8 which is why they really dont want to see systemd dependencies on everything.
Except that NetworkManager commits illegal felonies on baby goats. It has *never* handled pair bonding or VLAN tagging, which are absolutely critical for virtualization servers, and it remains a nightmarish wayward wishlist of features that *do not work under stress* and which require so much hand management to stabilize, one may as wall handscript it all in /etc/rc.
and you think merging the network manager code into systemd(which is redhat is more or less doing in rhel7) is going to solve the issue of NetworkManager being NetworkManager? Thats the fallacy of the systemd argument, in practice you are better off having a separate deamon(and systemd kind of implements networkd as a seperate forked process) because it's easier to fork and a replace a smallish single purpose deamon then init.
I blacklisted/pinned systemd to -1, and solved the problem. but I am also planning on moving to FreeBSD, but I want to take my time. However it is as you say, when I am upgrading a system with another init system, and without any visible dependencies nor gnome, why in hell should the upgrade to systemd should be forced upon us? I also have a couple of problems, until noticing in my test server that systemd was there without my permission or asking.
I do care more about it being forced, and upgrading a system installs it no matter what init system I am using, that the way it is implemented. Linux whas and should still be about choice.
The problem is you have each thing doing checks all the time every 30 seconds and ugly scripts to do this.
That's not a problem. Who cares if a check happens every 30 seconds? Who cares if it's done by a script? The system is designed to do stuff like let a script step every 30 seconds. The system is also designed with cheap process creation in mind; the time to fork a process is comparable to the time necessary to create a thread.
Anyway yes init controls processes and threads and states so it makes sense it would do this correct?
Well, in theory to me anyway, it would make sense to use a runlevel for sleep. This isn't what is normally done, but there's really no reason why you couldn't do that with init, and I think that might well make more sense. Any services which needed to stop themselves could do so, the network could be reconfigured on resume, et cetera. All without any ugly hacks. We would still run a bunch of scripts, but shell scripting and cheap process creation are central features of the Unix environment. Shell scripting is not a hack. Unix was invented for single-digit-MHz computers, and we can afford to toss off a few shells.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
those times are almost never caused by the os - usually it's this disk controller, that out of bounds controller, this firmware, that timeout.
even when it is the os, it's not the init system as such, it's a database, which is needed for some app and so on.
where have you seen up to 30 minute bootup time where init system would contribute in a whatsoever notable way to that time ?
Rich
.. and for people that don't like the desing of systemd and don't want to use the LARGEST security risk installed by default in many years on Debian???
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?
this seemed to be handled w/o systemd just fine for years. was it networkmanager ? probably. don't care. but it was never tied to the init system, login or anything else. having it all in a single, hairy ball of code is quite scary.
Rich
Mod parent up.
Exactly right - systemd isn't about desktop boot times at all, it is about servers and process management and supporting containerization (and managing using cgroups). See RedHat Atomic / OpenShift / Geard etc.
I agree that monitoring and re-spawning doesn't _need_ to be at OS level, but the cgroups type of stuff (resource limits, accounting, namespace isolation) really does.
Systemd is definitely about servers, lots and lots of servers delivering PAAS clouds, so no, traditional discrete server admins won't like it, but then they won't like PAAS either (if it really takes off) as it outsources / automates a large part of their job.
systemd is not the kernel, and is not required to run the system. If a Debian user can't do an apt-get purge systemd, then Debian is fundamentally broken. Debian used to be about choice, but has morphed into a step-child of Red Hat. It is sad to see a once-great distribution go down the tubes.
LxQt looks good, thanks for the tip!
if they don;t like it, fine, use something else. Can you back up your claim of "LARGEST security risk" and identify and detail all the security risks presently in systemd (we'll need specifics to confirm them)
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
That udev is placed in the same source tree as systemd does not make systemd eat it and also doesn't mean that packages needing udev also suddenly needs systemd.
If they ever do report it as a bug.
Watch this Heartland Institute video
This is completely ridiculous. Those attacks need to stop. This bullying needs to stop. This isn't like those anti-#GamerGate people who bully people into silence and do other nasty stuff like spread lies in mainstream media about #GamerGate in order to avoid talking their corruption. I agree that Systemd is on a road to become a feature creep and I don't like that but it's still a very good init system. I personally like Systemd for several reasons. It makes use of cgroups for example. I was very happy to see Debian do, what I considered to be the right action, and switched to Systemd. I understand that there are people who would like to turn clocks back to 70s and do "The UNIX way" but that so called "UNIX way" is broken philosophy that shouldn't be blindly followed. It's a good and noble princible but it stops working when solution needs to be scaled up. It's not delivering "correct and complete" software. Instead it often results in complex and incomplete mess. If you don't like Systemd then fork it and make a better solution or contribute to the project by taking part of it. Or make your own distributions without it. Just don't attack the devs for what they believe is worth doing. Jesus. Rant over.
An elite crowd trying to force on everyone else what they think is the right way? Thats one of the many reasons people are against systemd!
The maintainers (you call them "an elite crowd") of some distros have made the decision to use systemd because they think that's the right thing to do - someone has to make the decision, and if not the maintainers, who? Or would you prefer that the maintainers decide to do something that they think isn't right?
No one is forcing anyone to use systemd - the source is there for anyone to use as they see fit; Some distros have decided that systemd is the right way to go, some have decided to use other inits, you can either choose the distro (from a wide selection) that suits your purposes the most, or you can even make your own, no one is forcing you to use one particular distro.
Note: I don't really have any opinions about systemd, I currently use Fedora and it seems to work ok, but if I have problems then I can switch distros.
One thing I don't understand is how in the hell it is considered ok to have this in Debian STABLE? Maybe, in Fedora or OpenSuse but Debian stable???!
Why not Debian Stable? Red Hat Enterprise Linux uses systemd, so it must be good enough for enterprise use, so why it it not good enough for Debian Stable?
http://blog.nexusuk.org
To me a faster boot-up time are just a nice side-effect of running systemd. I also do not see where well-established init system vestiges are abandoned. PID1 is pretty small -- yes, it is bigger as sysv-init, but then it does quite a few new and useful tricks.
Logs can be binary or you can forward them to whatever syslog implementation you care for (some of them then storing them in their own binary format;-). Why is that considered an issue at all? SuSE and RedHat apparently do that in their default configuration (I have not tried those though).
And no, adding more stuff to sysv-init is definitely not the right approach. It had out-grown its usefulness about a decade ago: That is when all the "real" unixes moved away from it, using service managers similar to what systemd tries to do now on Linux.
Abandoning sysv init is not happening to standardize on a new file format. It is happening because shell scripts are a horrible way to configure a system. A 10 line systemd file does a better job at starting a service than a 200 line sysv-init file. Systemd does apply a bunch of hardening features (e.g. make /home unavailable to a daemon, make /usr and /etc read-only to a daemon, restrict capabilities a daemon can get access to, even make it unable to ever apply more privileges than those it was started with), many of which I have never seen implemented in sysv-init scripts. Not that it is impossible to do in sysv-init, it is just so hard that nobody ever bothered!
About "Unix principle": I personally do not see why systemd is supposed to violate those. It is a lot of small binaries -- each doing some specific task -- working in concert.
Regards, Tobias
It is actually pretty simple: The systemd init system provides cgroups, which do solve a lot of problems that tools close to the kernel have. So those tools start to use systemd-the-init-system. These tools then in turn provide solutions to problems that application developers face. They do so in a better way than other tools addressing the same problem -- because they can leverage systemd-the-initsystem. So application software starts to depend on the tools lower down in the stack.
There is no one piece of software that depends on systemd-the-init-system directly: They all depend on things one level lower in the stack, all the way down to systemd-the-initsystem. That is actually considered to be good software design.
You are free to replace any level with another implementation (providing the same interface). Those interfaces are not all stable at this time, which is a bit of a stumbling block. But systemd actually promises stability for some interfaces while listing others as still under active development. That is more than many other projects do!
Regards, Tobias
" 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?
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
It's immature twats all the way down...
Somehow I don't think this is what getting women involved in STEM careers was looking for.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
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
[...]
"Shoving down" implies some external force. But last I checked, everyone is completely free to choose between Linux distributions. I think, the license even allows it, to start your own distribution, without having to pay anyone anything. Possibly, you can even start your own distribution without asking anyone for allowance. So talking about "shoving down" seems to be a little bit exaggerated.
The people doing the hard work behind Debian are completely free to change the project any way they like. Under no circumstance they should get any harassment for how they decide to change their project (because I think it only belongs to the people putting effort into it). If they decided to remove the init system at all and let the user manage all services by hand, it would be their (should I say: "god given"?) right. They are free people and they can change their project as they choose. If they decided to switch to the NT kernel and toss Linux completely, it would be their choice and everyone else would have to accept it.
Sorry to see you going. Online harassment has always been a big problem but it seems to be getting epic lately. I think it is time to start applying stalking laws and other such measures to these campaigns. There is a difference between disagreeing and virtual violence.
apt-get install sysvinit systemd-shim
Might not work with some packages (gnome), which, if it bothers you, should be reported as a bug in those packages, or as a bug in sysviinit for not providing the interfaces those packages want.
Watch this Heartland Institute video
What? No choice?
The choices are any package that implements the virtual package "init".
Currently that's systemd, sysvinit and maybe upstart.
Pre-Jessie the "choice" was sysvinit.
(Note: Some packages may depend on systemd directly -- I'd suggesit aiming any complaints at the authors (upstream, not Debian) of those packages).
Watch this Heartland Institute video
for example, since systemd decided to eat udev, that means that every package that used udev now needs systemd.
Not true.
Watch this Heartland Institute video
By default systemd logs to syslog on Debian, no google-fu is required.
Watch this Heartland Institute video
It seems to me you don't actually like traditional Linux and might have been more at home with something like Haiku.
Shame Haiku only has a small dev community. Would have been a nice system to offload all-in-one-seekers onto.
and works well on a router where Windows can't run at all.
debatable and factually wrong.
Windows runs on routers, like the 54G, just as Linux distributions like OpenWRT, dd-wrt, etc?
I'm guessing what you mean is that a Windows desktop could kinda do some routing. It could. That's Windows running a desktop, doing some routing (poorly). That's not running on a router.
On the other hand, Windows runs really well on a desktop in the third grade classroom. That's not surprising since that's what Windows is for. It turns out, screwdrivers do a good job of turning screws. Hammers do a better job of hammering nails. Yeah, you CAN sort of pound a nail with a screwdriver and it might kind of work some of the time, but it's very definitely the wrong tool for the job. If you want to pound nails, use a hammer. Don't add an 18-ounce head to my screwdriver so you can pound nails with it.
- 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 value systemd brings to the table. Process management is another big one. Better logging, too. A more robust boot free of races is hard to argue with too (provided you have been bitten by such a race condition before:-). Finally socket activation greatly simplifies dependency management.
- Poor architecture.
Systemd uses DBus, an established, well understood and well tested protocol to communicate in favor of rolling its own. That can be considered a huge plus: Or have you never seen custom protocol parsers explode before, especially those written in C?
- Lack of concern for the server use case, and sysadmins in particular.
I wonder where you got that from. Systemd is particularly well suited for server systems: It makes for a more reliably boot process, it provides easy ways to harden services run, it can monitor running services, it collects way more log entries and enriches them with a lot of information directly from the kernel.
- Tying perfectly-good cross platform programs to Linux. Why my window manager or graphics program has to depend on init, I don't know.
Systemd is designed to make all the features of Linux available to admins. Those features are not available elsewhere, so of course systemd is neither. Blame that on the kernel developers, not on systemd.
Why does it your desktop environment depend on systemd? Because the developers of your desktop environment have decide that the services provided by systemd are valuable to them. Note that the desktop environment technically does not depend on systemd running as PID1, just on some of the daemons that are developed in the systemd repository. Those do in turn depend on systemd being PID1, but that is a different story:-)
If you do not know something, then maybe you should spend your time trying to understand the issue at hand before commenting in a public forum?
- Most importantly, the community is extremely toxic.
My experience with the systemd community was positive all the way. Any questions I had were answered in a friendly and helpful way. My patches were reviewed in a direct but friendly fashion and applied after all parties were happy with them. That is more that I can claim about many other projects I had contact with.
And I have seen several comments that have been well refuted but are brought up again and again. Well, I am happy with the answers to those comments, obviously the people making those comments are not.
And the most troubling aspect of this toxic community are the attacks on opponents.
There are rather a lot of opponents attacking proponents as well. That is no excuse for anybody to misbehave, but at this point *both* sides need to step back and take a deep of breath.
[...] No, there was outcry all those other times (in the PulseAudio case, quite rightly), but this is by far the most severe I've seen. And do any of these proponents think to ask - why? No, they decide it must just be change aversion and claim they're all just trying to set up a guild to keep their practices secret.
The outcry when the complex monster known as sysv init was introduced to replace the beautiful and simple B
Regards, Tobias
This: http://ewontfix.com/14/
Do you order cryptsetup before LVM or after? Put it before LVM and you can encrypt the physical volumes used by LVM, put it after and you can have encrypted logical volumes. Both approaches are valid and if you change the order and you can stop your system from booting. You want some encrypted logical volumes and some encrypted physical volumes? Fix the cryptsetup script as no distribution apparently bothers to test for that:-)
Stop me if this is a bad idea, but can't you just load it before and after?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Is there a pattern developing of people resigning from their roles as Debian maintainers? Recently Joey Hess submitted his resignation from the entire project: https://lists.debian.org/debia...
So develop an alternative to udev support and be happy in your contribution to linux. Oh wait, you expect other people to do this for you.
I think this whole "systemd" fiasco is nothing more than a black operation intended to hurt Debian. There are a lot of reasons why Debian would become a target for such an operation. Debian is a strong, powerful project to support true freedom and its not hard to think of why certain players would want to harm it in these sick times we live in.
If people don't think that black operations are real and that they happen they have not been paying attention for the past decades.
There are players in the world with vast resources at their disposal to use to engage in these sorts of activities. Sometimes they get caught red-handed but not always.
Surely the fact that all these posts filled with invective are coming from AC's should be a serious red flag.
I hate to say this, but the Debian team need to realize that they are targets for some potentially very dark actions because that increasingly is the type of world we live in. They can no longer afford to be naive of such things.
And who is one of Red Hat's most lucrative customers?
The National Security Administration
It's no surprise that Linux makes a better server than Windows
debatable
, a much better phone,
debatable
and works well on a router where Windows can't run at all.
Debatable? See how many supercomputers in Top500 run Linux and how many of them run Windows. I will answer that for you - only 1 supercomputer in Top500 list run on Windows... There is a reason why almost any performance-centric system prefers Linux-based distros.
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 clearly know nothing about linux and have never been a system administrator if that's how you think.
"If you love someone, set them free. If they come home, set them on fire." - George Carlin
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 knows everything and gets nothing done. I'm sick of that. Strong opinions about things with no alternative implementations are worth exactly nothing.
3. Sit down and develop something better and defend it.
4. There is no step 4.
Meanwhile I really fear that several community-based projects will happily fail just because there are legions of people who know perfectly what they hate and have no precise idea what they want to have or even would sit down and DO IT. Do I like SystemD? No, it sucks, just like every other comparable system. Do you know what I hate even more? Not having ANYTHING to work with and to rely on it staying around.
Debian (and Wikipedia by the way too) is becoming a bit like a failed state: Factions that love fighting more than building something and kill each other while there's hardly anything left than smoking ruins around them. If there's someone doing something that you don't like and won't listen to you than either just sit down and do something better or shut the fuck up.
Debian is becoming a lesson in applied entropy.
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 Debian is going, and indeed many of the Linux distros. Systemd violates some of what I consider to be core Unix principles.
The world's burning. Moped Jesus spotted on I50. Details at 11.
I think you are paranoid in suspecting SysVinit supporters being a front end for Putin/NSA etc. Sure their relentless hate attacks against Linux developers and Linux porjects may look like a concerted effort to split the Linux community, but at least some of them are sincere Linux users, perhaps lacking modern technical insight, but well-meaning never the less.
So Network Manager had to come in because init lacked the ability
You say that like it's a bad thing. Have you replaced your car because it doesn't chop carrots, yet? The init system didn't NEED to deal with the network settings, because it's a fucking init system, not a network manager.
Where the hell did this whole kitchen sinking mess come from?
From where I sit, the opposition is from people who don't like, approve or trust how systemd is incorporating more and more into itself. It smacks some people of bad design, bloated design and insecure design. Plus, it's the kind of behavior most often seen and witnessed by the historical enemies of Linux; it's the method of feature creep that reminds people of Microsoft and others, designed to make it difficult, if not impossible, to use anything else... ("lock-in" by another name). I'm sure that much of the "small elite" in opposition are opposed because Linux was supposed to be the revolution that got us *away* from that sort of monolithic control that they see systemd as.
As for me? meh.
"The best analogy in the Windows world for systemd is the Win95 registry..."
The Windows registry was designed to make it very, very difficult for people to make copies of software to use on another computer. The Windows registry was intentional obfuscation, and very much against the needs of users, because of the huge amounts of time it takes to understand and fix problems with the registry.
A comment below says, "SystemD is RedHat's version of embrace and extend." That seems a better explanation. The way it is being done is certainly deliberate. Starting a big hassle that damages the reputation of Linux is certainly against the needs of the users.
It seems that the entire U.S. culture is becoming more adversarial. For example, there are health care insurance policies that are written in such a way that the insured will not understand that they aren't being fully covered.
Companies are deliberately over-billing. Many people cannot afford the time to find all the ways they are being treated badly.
Bizarre reply. There is cowardice, and then there is foolishness. Listing your email address on a public forum would be the latter.
Are you trying to imply that the original AC was _not_ a coward for heatedly attacking a volunteer behind the veil of anonymity?
I would be happy if that were the case but your reservation "at least some people" deeply concerns me.
I can't understand why any rational person would go on a tirade against the best OS on the planet because of something like an init system. Either they are concealing deliberately malevolent intentions or else are really, really stupid.
Fortunately I think that Debian is more than strong enough to easily withstand any black ops directed against it. But I have no doubt that there are entities in our world who would like to destroy the Debian project because it threatens many things and confounds their plans to enslave everyone.
Actually resistence did form a few years back with both OpenRC and Upstart. The problem is those two projects failed to keep up. So the Linux community is confronted with the weird situation where they don't have choice. Normally there is chaos for years with competing standards this time there is 1 option. Sort of like if either Gnome or KDE had failed in the late 1990s.
What do you mean? Systemd does process management. That's what's introducing the dependencies it is a process manager. Why would you fork process management away from the process manager?
Of course it is going to be forked. There will most likely be child distributions of Debian that don't use systemd. There certainly will be embedded distributions that don't use systemd and those can be built up with current software.
We each have our breaking point. Anyone will break when subject to a verbal tirade of appropriate intensity. Yes, even you, Mr/Miss AC. It's just as valid a reason as family, health, or job issues.
You are not in a position to call out his character, unless you've experienced what he did. Unless you've volunteered yourself, given up your precious time and effort, for no recompense, and then been insulted, threatened, cursed, and have had every hateful expression thrown at you for your work. You cannot judge, because you just don't _know_.
The fact that there is such a toxic environment is the cause of my worry. That environment is not just in Debian developer circles. Every Slashdot poster, AC or otherwise, that has cheered this decision is a contributor to that poison. Every hater that has posted in any forum is a contributor to that poison. If you have done so, think long and hard about where you want open source software to go. Because if it continues down this path, there will be little future for it, and that's quite sad to me.
The positive thing to do, rather than rant and rave, is to go out and create a better alternative! Create, rather than destroy. I believe that forking is a positive thing to do. At least you're creating something new, which may even have a future, instead of cursing those who are actually trying to do something.
Would be a good theory except: Suse, CoreOS, Ubuntu, Oracle.... are also going systemd. If that were RedHat's plan you don't think they would have an interest in stopping it. And for that matter let's not forget things like IBM and Linux on Azure.
OK I'll assume this is a genuine question. Most certainly over the life of the next Debian stable there is going to be a situation where hundreds of packages make use of systemd process management or depend on lower level systems that do. They are going to be mostly untested and unmaintained against other init systems. Their own application specific process management features will be buggy or non existent. More importantly when their are security problems they may not be patched because nobody in upstream cares. That is a completely unacceptable situation.
So Debian must by their next version be converted over. They may have that problem over the next 2 years. So at best they could do one more version, Jessie on initd and even for that it is likely to be a hassle. So given:
a) The switch has to happen.
b) RHEL will guarantee that systemd is going to be well maintained
why not switch now?
Do you really believe that IBM, Oracle, RedHat, HP, CenturyLink, ... are not going to be addressing security problems if and when they emerge?
LXDE is a great choice of a lightweight desktop. And will be a great choice for distributions that don't make use of systemd as well.
OK I'll address those:
Z-OS has worked for an even longer time and that has always had complex process management.
boot time is just one of many advantages. Process management does matter for server.
The direction is server administration is the exact opposite. Extremely complex systems which offer a rich set of services to developers and and administrators. Your view of what is valuable is the minority view because of its proven costs especially in the area of pushing the complexity into deployment complexity.
You do understand there is a difference between someone disagreeing with you and someone being ignorant. For example you run the Linux kernel which is monolithic and tightly coupled rather than a kernel like QNX's which meets your criteria. Why?
The major server vendors and distributions are all in favor of it. OpenShift, Cloud Foundry, Heroku, Helion... are not exactly ignorant about the server use case.
OK and how does that not apply to the anti-systemd people who have failed to explained why initd's lack of process management is a good idea?
Because it isn't an init system. It is a process management system. initialization is just one of the states it manages.
Of course they have been refuted. It is being used in production in some of the largest most complex systems out there.
Bullshit. They are attacking fantasy by quoting propaganda. The Linux community generally called that FUD when it was applied on other issues.
No they aren't. Their intended users on the server side are the admins who control hundreds to tens of thousands of servers. The opposition is coming from system admins who generally administer a 1/2 dozen boxes. And I will tell you as someone who strongly supports systemd's direction, for server, I get attacked personally all the time by anti-systemd people.
Excellent comment. If I hadn't already commented I'd mod you up and if I hadn't already friended you I would. Very well put.
It is reasonable for a distribution. Systemd will be a bad choice for many types of embedded distributions and Linux is big on embedded. So there will be non-systemd distributions. It won't be hard to fork those to create a "traditionalist Linux". So yes I think it will exist. It wouldn't shock me if some are child distributions of Debian.
That being said, initd shouldn't be the default for mainstream distributions like Debian. So what's happening is the right thing.
Forgot about bootup times. Address the real issue. Full featured process management. That's a major shift. A complete replacement of the userspace plumbing with something much more feature rich, and thus much more complex. This isn't feature creep it is the natural evolution of a central system management daemon.
That's OpenRC which the anti-systemd people didn't work to support either.
The programmers, developers love the systemd features. That's where the dependencies are coming from. They are thrilled to be able to be able to depend on complex runtime dependencies the way the Linux package management system let's them depend on complex chains of library dependencies. The opposition is a small group of administrators who like traditionalist administration.
Do you really believe that IBM, Oracle, RedHat, HP, CenturyLink, ... are not going to be addressing security problems if and when they emerge?
with thinking like that, you might as well start using Windows because Microsoft will fix it too. the point is that it's a needless complexity that increases the risk of critical/exploitable bugs occurring.
Anons need not reply. Questions end with a question mark.
What I don't like is people assuming everything must be black and white. Linux has very many upsides. A complete fragmentation of the system due to every tiny little thing being coded by a different person has both benefits but also downsides.
100 monkeys typing on typewriters won't ever compose Shakespeare, but may accidentally spit out some garbled English.
There is a balance.
You clearly know nothing about linux and have never been a system administrator if that's how you think.
Wrong and wrong. I'd argue with you about this but a single update to a single app has caused a discrepancy issue which is going to take all night to resolve and I simply don't have the time.
I have actually seen someone who has used Linux for 10+ years try and install Zoneminder on a system and after 2 days of agony nuke the entire virtual machine and start with another distribution thanks to dependency hell which could make a dll blush.
I applaud Linux administrators for their work. They are worth far more than admins of any other system for the sheer crap they need to put up with.
I guess you never heard of Windows CE which ran everything from embedded PBX systems to my satnav in the car. It has full network support and runs in a remarkably tiny space. It most definitely CAN run on a tiny embedded chip in a router. Just because there's no OpenWRT equivalent doesn't make your statement any less wrong.
Or you could look at the licencing agreements for Windows Datacentre edition on a per processor basis and you'll see the reason is no one can AFFORD to run Windows on a super computer.
Man I must be turning into a Slashdot junkie because I swore I wouldn't say this but .... correlation != causation.
Don't know. I don't run xfce, so I don't know what it depends on. Here's how I did it, if you're comfortable with aptitude's interactive resolver:
then review the list of conflicts and suggestions in simulate mode. (I started without explicitly marking libsystemd0 for install, but after I realised its list of reverse-dependencies, I relented.)
I proceeded by looking at the 800ish packages it suggested removing, picking two or three packages I use and marking them as rejected (in my case, initially kmail, kdm, xserver-xorg-video-all), cycling to the next suggested resolution. then repeat. Whenever it suggested installing a systemd package, I rejected that suggestion too.
Eventually I settled on removing about 20 packages I didn't need (networkmanager, gnome-shell, some evolution packages, etc). Then I re-ran it without the simulate option.
Afterwards, I realised that I really wanted something to manage the network for me, so I had to manually bring the wifi network up, and
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
You do realize that CE is a completely separate operating system from Windows, right? A completely different kernel, different APIs, the whole thing.
Microsoft sold OS/2 as well, that doesn't make it Windows.
You wouldn't. Gnome's dependency is not on systemd and as far as I know none of the so called dependencies of down stream apps are on a process manager (GIMP depends on gudev, which depends on udev and on many systems this involves systemd). From what I can tell Gnome depends on logind to do login and session management, and logind depends on systemd for reasons that didn't exist until a little while ago (Gnome's dependency on logind actually goes back a while).
My understanding is that cgroups is moving (for various reasons) to require a single userspace process manager a la systemd. No, it doesn't have to be systemd but it sounds like it will have to be something _like_ systemd if you don't use systemd. Also, if your one process manager needs to manage stuff spawned from init, maybe it is right that it should _be_ init - I am not actually sure, but that seems to be the argument.
I am not sure if RedHat is chasing a phantom use case as you say or a genuine and valuable innovation - probably only time will tell - I just think it is clear they are chasing something in the PAAS / cloud / server space, and that that is where systemd is coming from.
I have actually seen someone who has used Linux for 10+ years try and install Zoneminder on a system and after 2 days of agony nuke the entire virtual machine and start with another distribution thanks to dependency hell which could make a dll blush.
Then that "someone" either sucks or is having to admin boxes that were poorly built / maintained. That sort of thing just doesn't happen on a well managed system. Ever,
"If you love someone, set them free. If they come home, set them on fire." - George Carlin
There are things like pam, policy management as well for Gnome. Logind btw needs process management because of power of/on and sleep conditions (wakup) requiring relogin.
Maybe I'm misinformed, but I'm quite wary of systemd myself.
I use Gnome3, Mate or XFCE alternatively, but never tried KDE.
From what you say, it seems to be a good alternative when Jessie will become stable.
What to look for when transitioning from Gnome to KDE?
Is purging systemd like you did tricky for a newbie like me?
Microsoft is pretty good at fixing security exploits for the last decade.
That's debatable. It is entirely unclear if having lots of systems overlapping doing parts of process management is really more risky then having one doing it all well that's being heavily checked.
Sorry, your words have little weight because you're posting them as an Anonymous Coward. More hypocrisy at show, as far as I'm concerned.
SJW? Hmmm, never heard of that term before. After looking it up, I don't think you've used it correctly.