That's a reasonable comment. And the answer is.... most likely no. Older configurations probably won't work. Systemd one the server side is tied to IaaS and PaaS deployment. Most likely those old fashioned systems will migrate to some traditionalist child of Debian that doesn't use systemd. They are legacy systems and should be handled like legacy systems.
Yeah it is a remarkable change in attitude on/. over the past 15 years. People used to be thrilled about change. Now they hate it. If it were the old fogies like me I can understand, get off my lawn... But it is the young guys who seem the most fearful of change and stuck in their ways. I really realized this during the IPv6 debates when the idea of changing a network system was unthinkable. Dammit where would you all be if my generation had ripped DECNet et al out?
I'd doubt that Linux is alienating power users. What it is alienating is traditionalist system admins. Going back traditionalist system admins had traditionally been drawn to BSDs and the big box Unixes. Most likely those guys learned to admin on Linux when they weren't traditionalists and became traditionalist with time. The product no longer fits.
This General Resolution was about making certain that the distribution still worked even if someone chose to use a different init system. I am not sure why that is contentious.
If you are honestly asking, because it isn't really something a distribution can successfully do. This is like asking a distribution to still work if you use a different libC. Fundamentally systemd does so much and changes the way so many packages are going to work that that yes/no on systemd is going to be different distributions. You are going to have different OSes based on the Linux kernel. The analogy is something like Android (or GooglePlay) not something like emacs.
Except it isn't the Debian developers and package maintainers who are objecting to systemd. It is a small group of Debian users (i.e. traditionalist system admins). That's the issue.
a) Was the systemd approach unthinkable 5+ years ago. b) Is systemd the right approach.
GP was arguing about (a). You are arguing about (b).
It's because of the toolbox approach where you can always upgrade one component without touching others that Linux won.
I think Linux won because it was designed to run on cheap x86 hardware primarily. The Microsoft/Western Digitial / Intel standard won. Intel beat MIPS, Spark Motorola (sort of in the Intel camp so debatable), RISC / IBM, Alpha, Itanium.... and Linux went along for the ride. I guarantee you that if I could have gotten a Solaris workstation for $2k while the Linux workstation was $7k no one would have cared about upgrading components on Linux more easily. How quickly Linux workstation lost to OSX workstation (essentially NeXT) when they were in direct competition I think shows this.
Now that being said, the more interesting case is Linux's victory over Windows server. But again I think it was primarily cost. LAMP didn't beat IIS and Netscape Server because it was better, in the beginning it beat IIS & Netscape Server because it was so much cheaper.
So I just don't see much evidence for your claim as to why Linux won based on diversity. Where there hasn't been much price difference: desktop and embedded Linux has been able to play but it hasn't been nearly as dominant as in server.
There is a good chance I've been using Unix longer than you. People who had to argue for "the Unix way" when it was an argument knew there complex tradeoffs vs. other systems that had more complex systems. They argued for it in specific use cases fully aware that there were other use cases where it was a terrible fit.
The fact that Linux killed off those other systems means that now Linux has to handle use cases for which TUW is a bad fit.
what is the problem to have both systemd and sysvinit scripts in the package
Absolutely nothing. There is a problem with additional functionality though. Applications X has complex dependencies. In 2013 it had custom code that handled those. In 2014 it stopped maintaining that code and lets systemd take care of runtime dependencies . Initd doesn't know how to resolve runtime dependencies. Writing an initd script doesn't solve the problem.
I suspect the primary users of Debian are other Debian based distributions: Ubuntu, Knoppix, Kantonix...
I get that users want a say. Ultimately this has always been a problem with Linux. In commercial software users ultimately have most of the power. In Open Source there are 3 options:
a) Paid child distributions b) Contribute code c) Contribute money
to have a say. Users of free distributions don't really get much of a say. I think that's part of what makes this whole systemd thing such a problem. That main proponents of systemd are upstream from the distributions while the main opponents are downstream. The distributions are caught in the middle.
All the while poor little upstart or openrc just wait in the shadows getting more and more stable.
Well Upstart had a huge head start on systemd. As for OpenRC is anyone actually doing much work on it?
In the short term debian's forks might end up breaking free from debian if they dont get a solution to the systemd situation that facilitate forks(none of the systemd success stories have been in distro's known for facilitating forks the way debian does).
RedHat starting have forks (like Mandrake) before Debian did if memory serves. But I think Debian will likely fork and have a non-systemd child distribution. And hopefully that will reduce the heat.
Applications have been ignoring API features for decades systemd is just another piece of crap for application vendors to work around
Except the application vendors want the functionality.
And people still need external process management for serious server instalations ect
Here I think systemd is going to have hooks directly into OpenStack/OpenShift, CloudFoundary... So yes it will offload it by being a node and giving intelligent information as a node. That's what I expect to happen.
Journald will not replace rsyslogd for any system where log consistency matter
The Linux community has lots of distributions. That isn't exactly drastic. Anyway both Crux and Alpine have already committed to long term no systemd. So you should be fine.
, or at least a troll war, by asking "Which is better: emacs or vi?
Funny enough... after 2 decades of hearing that argument.. I don't hear anyone care anymore. They both have found niches and GUI oriented IDEs have mostly replaced both as developer's day to day choices. This one was finally settled by going from 2 main options to 50 options.
Stripping away functionality is going to be hard to do. For example if standard hostnamed is not going to able to support all the features of the systemd version. Which means either:
a) System admins are going to be directly exposed to complex use case reverse engineering when they can or cannot use the less powerful daemon b) The daemons are going to need to keep up with systemd's feature set and interfaces which means for all practical purposes being part of systemd.
If systemd was really that good, I wouldn't need it foisted upon me forcibly, I'd be voluntarily choosing it rather than the default init on every distro I boot.
There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.
Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers. One massive program running at PID 0 doing 100 different jobs from startup scripts to DNS resolution complete with binary log files and a completely different (but the same) set of tools o manage them (grep less awk tail). You would be laughed at and run out of town. Nobody would ever take you seriously again.
BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.
They only want you to believe you have privacy. But whether you do or you don't won't make any difference in their market
True but you can't have at the same time:
1) A widespread belief there is privacy 2) The government violating that privacy through monitoring and frequently acting on the information
I'm a little disappointed to see the EFF involved. Now I have to pay a bit more attention to their intentions, for instance, where are they going to compromise our interests when dealing with the big names?
Or maybe the EFF was brought in so that a trustworthy system would be seen as trustworthy. They actually do intend to do the right thing.
ith thinking like that, you might as well start using Windows because Microsoft will fix it too
Microsoft is pretty good at fixing security exploits for the last decade.
it's a needless complexity that increases the risk of critical/exploitable bugs
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.
It isn't the encryption they would care about its you being comfortable consuming video privately. In particular people want privacy about their porn choices.
Akamai wants you consuming lots and lots of video. Cisco wants you chewing up bandwidth like crazy. They benefit. But yes if push comes to shove between you and Homeland Security, you lose.
In NYC I can get far better than DSL anywhere for well below $1000 / mo. If those business are willing to send me a list of locations and don't want to play games I'd be happy to fix that.
There are low cost phone shops all over New York city. They have a nice mixture of 1st world culture with premium prepaid shops and 3rd world culture with cheap phones being sold out of dedicated stores. For $40 you can get a phone.
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.
Slashdot Mirror
That's a reasonable comment. And the answer is.... most likely no. Older configurations probably won't work. Systemd one the server side is tied to IaaS and PaaS deployment. Most likely those old fashioned systems will migrate to some traditionalist child of Debian that doesn't use systemd. They are legacy systems and should be handled like legacy systems.
Yeah it is a remarkable change in attitude on /. over the past 15 years. People used to be thrilled about change. Now they hate it. If it were the old fogies like me I can understand, get off my lawn... But it is the young guys who seem the most fearful of change and stuck in their ways. I really realized this during the IPv6 debates when the idea of changing a network system was unthinkable. Dammit where would you all be if my generation had ripped DECNet et al out?
It isn't just Gnome. This has expanded to dozens of other packages already. By the next Debian stable hundreds.
You seem to be on both sides of this.
But basically Systemd is complex enough that there should be systemd and non-systemd distributions.
I'd doubt that Linux is alienating power users. What it is alienating is traditionalist system admins. Going back traditionalist system admins had traditionally been drawn to BSDs and the big box Unixes. Most likely those guys learned to admin on Linux when they weren't traditionalists and became traditionalist with time. The product no longer fits.
If you are honestly asking, because it isn't really something a distribution can successfully do. This is like asking a distribution to still work if you use a different libC. Fundamentally systemd does so much and changes the way so many packages are going to work that that yes/no on systemd is going to be different distributions. You are going to have different OSes based on the Linux kernel. The analogy is something like Android (or GooglePlay) not something like emacs.
Except it isn't the Debian developers and package maintainers who are objecting to systemd. It is a small group of Debian users (i.e. traditionalist system admins). That's the issue.
There are two questions:
a) Was the systemd approach unthinkable 5+ years ago.
b) Is systemd the right approach.
GP was arguing about (a). You are arguing about (b).
I think Linux won because it was designed to run on cheap x86 hardware primarily. The Microsoft/Western Digitial / Intel standard won. Intel beat MIPS, Spark Motorola (sort of in the Intel camp so debatable), RISC / IBM, Alpha, Itanium.... and Linux went along for the ride. I guarantee you that if I could have gotten a Solaris workstation for $2k while the Linux workstation was $7k no one would have cared about upgrading components on Linux more easily. How quickly Linux workstation lost to OSX workstation (essentially NeXT) when they were in direct competition I think shows this.
Now that being said, the more interesting case is Linux's victory over Windows server. But again I think it was primarily cost. LAMP didn't beat IIS and Netscape Server because it was better, in the beginning it beat IIS & Netscape Server because it was so much cheaper.
So I just don't see much evidence for your claim as to why Linux won based on diversity. Where there hasn't been much price difference: desktop and embedded Linux has been able to play but it hasn't been nearly as dominant as in server.
There is a good chance I've been using Unix longer than you. People who had to argue for "the Unix way" when it was an argument knew there complex tradeoffs vs. other systems that had more complex systems. They argued for it in specific use cases fully aware that there were other use cases where it was a terrible fit.
The fact that Linux killed off those other systems means that now Linux has to handle use cases for which TUW is a bad fit.
Absolutely nothing. There is a problem with additional functionality though. Applications X has complex dependencies. In 2013 it had custom code that handled those. In 2014 it stopped maintaining that code and lets systemd take care of runtime dependencies . Initd doesn't know how to resolve runtime dependencies. Writing an initd script doesn't solve the problem.
I suspect the primary users of Debian are other Debian based distributions: Ubuntu, Knoppix, Kantonix...
I get that users want a say. Ultimately this has always been a problem with Linux. In commercial software users ultimately have most of the power. In Open Source there are 3 options:
a) Paid child distributions
b) Contribute code
c) Contribute money
to have a say. Users of free distributions don't really get much of a say. I think that's part of what makes this whole systemd thing such a problem. That main proponents of systemd are upstream from the distributions while the main opponents are downstream. The distributions are caught in the middle.
Well Upstart had a huge head start on systemd. As for OpenRC is anyone actually doing much work on it?
RedHat starting have forks (like Mandrake) before Debian did if memory serves. But I think Debian will likely fork and have a non-systemd child distribution. And hopefully that will reduce the heat.
Except the application vendors want the functionality.
Here I think systemd is going to have hooks directly into OpenStack/OpenShift, CloudFoundary... So yes it will offload it by being a node and giving intelligent information as a node. That's what I expect to happen.
Not following this one.
The Linux community has lots of distributions. That isn't exactly drastic. Anyway both Crux and Alpine have already committed to long term no systemd. So you should be fine.
Funny enough... after 2 decades of hearing that argument.. I don't hear anyone care anymore. They both have found niches and GUI oriented IDEs have mostly replaced both as developer's day to day choices. This one was finally settled by going from 2 main options to 50 options.
Stripping away functionality is going to be hard to do. For example if standard hostnamed is not going to able to support all the features of the systemd version. Which means either:
a) System admins are going to be directly exposed to complex use case reverse engineering when they can or cannot use the less powerful daemon
b) The daemons are going to need to keep up with systemd's feature set and interfaces which means for all practical purposes being part of systemd.
There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.
BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.
True but you can't have at the same time:
1) A widespread belief there is privacy
2) The government violating that privacy through monitoring and frequently acting on the information
Or maybe the EFF was brought in so that a trustworthy system would be seen as trustworthy. They actually do intend to do the right thing.
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.
It isn't the encryption they would care about its you being comfortable consuming video privately. In particular people want privacy about their porn choices.
Akamai wants you consuming lots and lots of video. Cisco wants you chewing up bandwidth like crazy. They benefit. But yes if push comes to shove between you and Homeland Security, you lose.
EFF and Mozilla are included. I think that's a stretch.
In NYC I can get far better than DSL anywhere for well below $1000 / mo. If those business are willing to send me a list of locations and don't want to play games I'd be happy to fix that.
There are low cost phone shops all over New York city. They have a nice mixture of 1st world culture with premium prepaid shops and 3rd world culture with cheap phones being sold out of dedicated stores. For $40 you can get a phone.
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.