Do a search on the threads related to consolekit on OpenRC. That was the breaking point. OpenRC will continue to advance as a replacement for initd it just won't be a replacement for systemd.
The question is really the other way around - should systemd be doing all that it does and at the same time abandon POSIX compatibility.
I think we need process management. Once you accept a process manager I think it should be doing a lot more and really be designed to work with an IaaS / PaaS solution.
As for POSIX compatibility... POSIX was a solution to a world of lots of diverse big box Unixes to allow commercial software to support all of them. We have a mono culture on Unix now with Linux owning almost all of it, except for OSX (which has a cousin to systemd called launchd). So I'm not sure POSIX should exist and if does exist then I think Linux and OSX should be at the center of it with AIX, Solaris, other BSD... being peripheral. Things like support for Digital Unix and Xenix features can be dropped.
I meant that in a wider context than just Debian. It's abundantly clear that several of the developers at the heart of systemd simply do not play well with the other children, and reflexively treat dissent as opposition for its own sake
I don't think it is clear. They work for a corporation that has a few target strategic directions. People who disagree with RedHat's direction for Linux are kinda irrelevant they are not just dissenters. So for example if I disagree with congress immigration bill and march that's dissent. If I wanted to form a single state with the USA and Mexico that may be a valid opinion but it has so little support that it isn't even dissent in a political context. Dissent would be people who agree with RedHat's goals but not with systemd's approach. And those have been listened to.
The Debian anti-systemd crowd is IMHO: 1) Really ignorant about the direction of the industry and too involved in their own use cases 2) About 7 years to late to be having this debate. The time for this discussion was around 2007-8 when the "should Linux do something like launchd" discussion was happening. 3) No people who buy large number of commercial OS licenses or expensive support contracts.
Debian is the refuge of a certain kind of sysadmin/developer who is conservative in nature and curmudgeonly in attitude.
I agree. But the fact that they aren't getting what they want on someone else's dime is what is pissing them off. Linux has allowed them to avoid what most admins get where the OS company says, "our direction is X. Lead, follow or call our competitor and get out of the way".
I'll grant you that the upstream developers often have the upper hand, but distros do have a role to play in adjudicating the popularity contests that inevitably arise when you've got competing products.
Sure they do. If there are 2 competing standards the distributions can play an important role. Like they did the X.org fork away from XFree86 or earlier Emacs vs. X-Emacs. And like they tried to do when there 4 options for init: upstart, systemd, initd, OpenRC. But when there is only one viable path forward and upstream is unified they have not fought it successfully.
But I don't want to over-emphasise that. You're right that distros are sometimes circumscribed in terms of options. This is pretty much exactly why Debian moved when it did. If I understand correctly, they saw the writing on the wall—that GNOME was aligning and integrating with systemd—and decided to walk before they were forced to run
It wasn't just Gnome. Gnome alone Debian could have handled. Debian deves were looking at 500 packages directly or indirectly introducing dependencies during the life of Jessie. And while they could have held out for Jessie the next version the breakage would have been much more painful as you put it walk before they were forced to run.
You mean managed processes in an operating system, right, and not systems development process management?
Yes the operating system (or infrastructure management system) managing processes on individual boxes.
The departure that I spoke of was not from one particular init system to another. I was speaking of the move from heterogeneity to homogeneity. Poettering's goal is unification. Systemd is simply one means to that end. Read his blog for more about his grand design.
We agree. Poettering... want a more homogeneous environment. But, and this is important, so do most application programmers. They are sick of supporting heterogeneity's complexity.
I don't think there ever was a decision to kill off big box Unix. Nor do I think there has been (until quite recently) any particularly concerted, coordinated effort to replicate the kind of functionality typically seen in mainframes and minis.
I'd point you to things like aggressively recruiting the commercial DBMS to Linux in the mid 1990s. Why do that if not to go after big bog Unix turf? As far as replace functionality of mainframe and minis, I'd give clustering and virtualization as two examples from much earlier.
But systemd is, because it's of questionable quality and design
I don't see how the adhoc solutions that exist under initd are better quality and design. That's been beaten to death but the heterogeneity you are arguing for led to solutions where there wasn't proper attention paid. What existed wasn't good.
by people who treat dissent as enmity
I don't see that. Debian was never the target of the systemd crowd. They had few if any connections to Debian. The debate within Debian was not between systemd proponents for Debian not the actual systemd funders / developers. We know the funders and developers didn't care very much what Debian did.
Making an application stack that intelligently does that is no small feat, leaving a large chunk of the market not able to make the shift.
I guess we disagree there. I see a pretty easy migration for server solutions already. I'm not seeing many that are having that difficult a problem. What areas do you believe aren't migrating to IaaS solutions?
Besides, a great deal of companies that brag about how awesome their PaaS implementations do not provide a pleasant user experience and/or suck down a *lot* more resource than they need
True. No question. But often those resources are cheaper. So people for example replace expensive Teradata licenses with cheap (free) Hadoop licenses even if they are using 4x as much hardware the IaaS is way cheaper than what it is replacing. I haven't seen a place that hasn't worked.
As for unpleasant user experience, as contrasted to what? Who is having that problem?
I don't see any references either on Wikipedia or the official OpenRC web page that the people working on it threw in the towel over a year ago. Got any reference for this news?
Not off the top of my head. do a search on consolekit OpenRC and the problems they were having. They hit compatibility problems before upstart did.
As far as it being abandoned. You can go to Gentoo right now and see hard dependencies on systemd in unrelated packages.
Some embedded systems like the process management of systemd. For others it is too expensive. It is entirely possible, I'd say likely that a large subset of embedded Linux will break off to essentially become at the very least a majorly diverging forked OS. Embedded has always been a diverse ecosystem.
As for a desire for organization yes. That's absolutely true. The systemd folks want to be kernel 2.0 and have a much more larger range of standard services across distributions and instances. Obviously RedHat would like to be that committee. There are other players like IBM, HP... that wouldn't mind being able to focus on higher parts of the stack and are happy to yield those issues to RedHat. So let's assume that's true...
The why should it be is because systemd is a process manager not an init system. Initialization and shutdown are just two of the many states that systemd handles today and just two of the far greater number it will handle in the future. If you are going to offer OpenRC as a replacement for systemd then it has to do process management not just init management.
OpenRC is a great replacement for initd but that's not the issue anymore.
You are a tinfoil hatter. Debian is moving at the same pace it has for similar changes driven from upstream. There just haven't been that many times when upstream and large groups of users disagreed lately. Moreover RedHat was 2 years ahead of Debian so your when is intermixed.
Sure there is. If program X has 5 dependencies on systemd another init system is going to have to solve them. If Y has another 4 dependencies the replacement is going to have solve them. If X&Y together introduce cross dependencies then that solution for both them is going to need to handle cross dependencies. And that's the problem with replacing systemd.
Debian was moderately conservative it was never extreme. Debian was one of the last distributions to move to systemd and did so as gently as they felt they could. Debian was keeping with its pattern not breaking from it.
Now it wants to be the new shiny shiny
No it doesn't. Debian wants to be able to run mainstream Linux software even when upstream is starting to drop support for initd. That's conservative. If you want even more conservative Crux is good.
That's absolutely true. And that is one of the first valid criticisms of systemd I've seen. So let me start with a complement.
Now let me respond. One of the big shifts that systemd is embracing is towards IaaS/PaaS type services. Individual boxes if they go "off the reservation" are just blown away. Either they are able to fix themselves or they get dropped from the cluster. At an individual level they don't get fixed. The goal is to increase the percentage of self repairs as high as possible, even at the expense of making complex repairs much harder because those can be handled at by the PaaS.
Sure it does. Application A is dependent on B who is dependent on C. B has a problem and needs to be restarted. What should the OS do regarding C and A?
They did. That happened about 4 years ago. Debian was never the target for systemd people like Pottering had little to no contact with the Debian community. But then upstream packages more associated with RHEL, SUSE... started adopting it. And it was becoming increasingly complicated for Debian to offer both. So Debian had to switch either 2 years ago, now or 2 years from now. They weighed the plussed and minus and decided on now.
First off the FOSS distribution ecosystem was just simply a way of packing upstream. That's how it has always worked. What upstream FOSS software does determines what the distribution do. The distributions have a 30 year track record of trying to set standards and failing when upstream didn't support those standards. TexInfo as the universal way of handling documentation being a good example of distribution driven.
As for the move to process management being a change in philosophy. That's true. It is not a change for Unix, most of the commercial Unixes had it. When Linux decided to go after killing off the big box Unixes they also decided to absorb their functionality. That choice was made staring around 1994 when Linux stopped being purely hobbyist.
As for historical evidence. I don't know of any historical evidence that process management is a bad. IBM mainframes have been around longer Unixes.
Of course process management was needed. That's why virtually every commercial Unix, along with most other large system (i-Series OS, z-Series OS, VMS...) had it. That's why the most succesful desktop Unix OSX has it. Hundreds of applications of have had to work around the limitations of initd.
The funny thing is the people working on OpenRC threw in the towel over a year ago. They can't keep up. OpenRC was a good idea, it truly was init.d version 3.0. But in practice it is non-viable as a replacement for all systemd is doing today as the developers on it admit. Gentoo will be able to hold out a long time because of the nature of the distribution but I suspect that within 2-3 years Gentoo will be overwhelmingly systemd.
You are getting $400-500 phone subsidy at a cost of about $20 / mo. That's break even. Where you can save money is the prepay plans are about $10 / account / mo cheaper than the postpay accounts for similar quality for multiple accounts. It isn't as big a savings as people claim but it ain't $0 either. Mostly the crazy comparisons come from comparing worst possibly designed postpay to much worse prepay.
So: 1 account: go prepay 2-3 accounts: generally worth the less hassle to go postpay but you are spending more. 4+ accounts: postpay is often cheaper and less hassle.
That's fine. Changing products is also a one time porting of the scripts over to FreeBSD. The main thing is it is a one time transition cost not an ongoing issue.
Agreed. There are some good distributions for lean, traditional Unixes. The issue really is that Debian can't both be one of those and be mainstream. It is an either / or choice.
Slashdot Mirror
No it is about 2 years behind. Not 15. There are distributions which are much further behind.
Do a search on the threads related to consolekit on OpenRC. That was the breaking point. OpenRC will continue to advance as a replacement for initd it just won't be a replacement for systemd.
I think we need process management. Once you accept a process manager I think it should be doing a lot more and really be designed to work with an IaaS / PaaS solution.
As for POSIX compatibility... POSIX was a solution to a world of lots of diverse big box Unixes to allow commercial software to support all of them. We have a mono culture on Unix now with Linux owning almost all of it, except for OSX (which has a cousin to systemd called launchd). So I'm not sure POSIX should exist and if does exist then I think Linux and OSX should be at the center of it with AIX, Solaris, other BSD... being peripheral. Things like support for Digital Unix and Xenix features can be dropped.
I don't think it is clear. They work for a corporation that has a few target strategic directions. People who disagree with RedHat's direction for Linux are kinda irrelevant they are not just dissenters. So for example if I disagree with congress immigration bill and march that's dissent. If I wanted to form a single state with the USA and Mexico that may be a valid opinion but it has so little support that it isn't even dissent in a political context. Dissent would be people who agree with RedHat's goals but not with systemd's approach. And those have been listened to.
The Debian anti-systemd crowd is IMHO:
1) Really ignorant about the direction of the industry and too involved in their own use cases
2) About 7 years to late to be having this debate. The time for this discussion was around 2007-8 when the "should Linux do something like launchd" discussion was happening.
3) No people who buy large number of commercial OS licenses or expensive support contracts.
I agree. But the fact that they aren't getting what they want on someone else's dime is what is pissing them off. Linux has allowed them to avoid what most admins get where the OS company says, "our direction is X. Lead, follow or call our competitor and get out of the way".
The user is a machine. This is process management.
No it doesn't. systemd can handle complex dependencies in a specific indicated fashion easily.
Sure they do. If there are 2 competing standards the distributions can play an important role. Like they did the X.org fork away from XFree86 or earlier Emacs vs. X-Emacs. And like they tried to do when there 4 options for init: upstart, systemd, initd, OpenRC. But when there is only one viable path forward and upstream is unified they have not fought it successfully.
It wasn't just Gnome. Gnome alone Debian could have handled. Debian deves were looking at 500 packages directly or indirectly introducing dependencies during the life of Jessie. And while they could have held out for Jessie the next version the breakage would have been much more painful as you put it walk before they were forced to run.
Yes the operating system (or infrastructure management system) managing processes on individual boxes.
We agree. Poettering ... want a more homogeneous environment. But, and this is important, so do most application programmers. They are sick of supporting heterogeneity's complexity.
I'd point you to things like aggressively recruiting the commercial DBMS to Linux in the mid 1990s. Why do that if not to go after big bog Unix turf? As far as replace functionality of mainframe and minis, I'd give clustering and virtualization as two examples from much earlier.
I don't see how the adhoc solutions that exist under initd are better quality and design. That's been beaten to death but the heterogeneity you are arguing for led to solutions where there wasn't proper attention paid. What existed wasn't good.
I don't see that. Debian was never the target of the systemd crowd. They had few if any connections to Debian. The debate within Debian was not between systemd proponents for Debian not the actual systemd funders / developers. We know the funders and developers didn't care very much what Debian did.
FOSS predates Linux by decades. The GNU project itself is 7 years older than Linux and came into a world where FOSS software existed.
I guess we disagree there. I see a pretty easy migration for server solutions already. I'm not seeing many that are having that difficult a problem. What areas do you believe aren't migrating to IaaS solutions?
True. No question. But often those resources are cheaper. So people for example replace expensive Teradata licenses with cheap (free) Hadoop licenses even if they are using 4x as much hardware the IaaS is way cheaper than what it is replacing. I haven't seen a place that hasn't worked.
As for unpleasant user experience, as contrasted to what? Who is having that problem?
Not off the top of my head. do a search on consolekit OpenRC and the problems they were having. They hit compatibility problems before upstart did.
As far as it being abandoned. You can go to Gentoo right now and see hard dependencies on systemd in unrelated packages.
Some embedded systems like the process management of systemd. For others it is too expensive. It is entirely possible, I'd say likely that a large subset of embedded Linux will break off to essentially become at the very least a majorly diverging forked OS. Embedded has always been a diverse ecosystem.
As for a desire for organization yes. That's absolutely true. The systemd folks want to be kernel 2.0 and have a much more larger range of standard services across distributions and instances. Obviously RedHat would like to be that committee. There are other players like IBM, HP... that wouldn't mind being able to focus on higher parts of the stack and are happy to yield those issues to RedHat. So let's assume that's true...
The why should it be is because systemd is a process manager not an init system. Initialization and shutdown are just two of the many states that systemd handles today and just two of the far greater number it will handle in the future. If you are going to offer OpenRC as a replacement for systemd then it has to do process management not just init management.
OpenRC is a great replacement for initd but that's not the issue anymore.
You are a tinfoil hatter. Debian is moving at the same pace it has for similar changes driven from upstream. There just haven't been that many times when upstream and large groups of users disagreed lately. Moreover RedHat was 2 years ahead of Debian so your when is intermixed.
Sure there is. If program X has 5 dependencies on systemd another init system is going to have to solve them. If Y has another 4 dependencies the replacement is going to have solve them. If X&Y together introduce cross dependencies then that solution for both them is going to need to handle cross dependencies. And that's the problem with replacing systemd.
Debian was moderately conservative it was never extreme. Debian was one of the last distributions to move to systemd and did so as gently as they felt they could. Debian was keeping with its pattern not breaking from it.
No it doesn't. Debian wants to be able to run mainstream Linux software even when upstream is starting to drop support for initd. That's conservative. If you want even more conservative Crux is good.
That's absolutely true. And that is one of the first valid criticisms of systemd I've seen. So let me start with a complement.
Now let me respond. One of the big shifts that systemd is embracing is towards IaaS/PaaS type services. Individual boxes if they go "off the reservation" are just blown away. Either they are able to fix themselves or they get dropped from the cluster. At an individual level they don't get fixed. The goal is to increase the percentage of self repairs as high as possible, even at the expense of making complex repairs much harder because those can be handled at by the PaaS.
Sure it does. Application A is dependent on B who is dependent on C. B has a problem and needs to be restarted. What should the OS do regarding C and A?
systemd is a close cousin to launchd on OSX. Porting from Linux to OSX will be less not more difficult because of systemd.
They did. That happened about 4 years ago. Debian was never the target for systemd people like Pottering had little to no contact with the Debian community. But then upstream packages more associated with RHEL, SUSE... started adopting it. And it was becoming increasingly complicated for Debian to offer both. So Debian had to switch either 2 years ago, now or 2 years from now. They weighed the plussed and minus and decided on now.
First off the FOSS distribution ecosystem was just simply a way of packing upstream. That's how it has always worked. What upstream FOSS software does determines what the distribution do. The distributions have a 30 year track record of trying to set standards and failing when upstream didn't support those standards. TexInfo as the universal way of handling documentation being a good example of distribution driven.
As for the move to process management being a change in philosophy. That's true. It is not a change for Unix, most of the commercial Unixes had it. When Linux decided to go after killing off the big box Unixes they also decided to absorb their functionality. That choice was made staring around 1994 when Linux stopped being purely hobbyist.
As for historical evidence. I don't know of any historical evidence that process management is a bad. IBM mainframes have been around longer Unixes.
The debian developers are a pretty good random sample of the well informed That's as good as you are going to get to unbiased statistics.
Of course process management was needed. That's why virtually every commercial Unix, along with most other large system (i-Series OS, z-Series OS, VMS...) had it. That's why the most succesful desktop Unix OSX has it. Hundreds of applications of have had to work around the limitations of initd.
Your article read like a rant. Just use a distribution that's been conservative like Crux or Alpine. Problem solved.
The funny thing is the people working on OpenRC threw in the towel over a year ago. They can't keep up. OpenRC was a good idea, it truly was init.d version 3.0. But in practice it is non-viable as a replacement for all systemd is doing today as the developers on it admit. Gentoo will be able to hold out a long time because of the nature of the distribution but I suspect that within 2-3 years Gentoo will be overwhelmingly systemd.
You are getting $400-500 phone subsidy at a cost of about $20 / mo. That's break even. Where you can save money is the prepay plans are about $10 / account / mo cheaper than the postpay accounts for similar quality for multiple accounts. It isn't as big a savings as people claim but it ain't $0 either. Mostly the crazy comparisons come from comparing worst possibly designed postpay to much worse prepay.
So:
1 account: go prepay
2-3 accounts: generally worth the less hassle to go postpay but you are spending more.
4+ accounts: postpay is often cheaper and less hassle.
That's fine. Changing products is also a one time porting of the scripts over to FreeBSD. The main thing is it is a one time transition cost not an ongoing issue.
Agreed. There are some good distributions for lean, traditional Unixes. The issue really is that Debian can't both be one of those and be mainstream. It is an either / or choice.