I'm beginning to think that those distributions which have chosen systemd are now beginning to think, what have we done to ourselves?
Well you are thinking wrong. The distributions that choose systemd have been able to easily layer Linuxes into more complex systems and as a result IaaS and PaaS type configurations involving literally millions of CPUs or workload running Linux as a base OS are becoming standard. At the same time microservice architectures are thriving making program management much easier.
What they are finding is that Linux finally scales easily to fill the niches their customers want.
Upstart: couldn't keep up. Systemd came out of solutions to some of the problems with upstrart. There was no good reason in theory upstart couldn't have won, it just didn't.
Launchd is tied to BSD initialization. But... there was an attempt to port its features over to Linux. That was called systemd.
What you might really like is OpenRC which is a "better init for Linux" and doesn't aim to be more than just init version 2. But it is mostly defunct now.
As an aside launchd is open source. The FreeBSD people were able easily to move it over.
Now onto your question:
OpenBSD, FreeBSD, and Slackware not have any problems with init scripts?
Those 3 don't support complex tiers of applications that need to work together. They aren't aiming to have say something like Oracle Financials running on them. They aren't used in large configurations involving hundreds (or many thousands or more) CPUs.
I did. All the system admins who were being forced off of VMS, MVS, Solaris, AIX... towards Linux that wanted complex process management wanted this. The system admins who had to work with large numbers of VMs in complex environments (i.e. admin of public, private and especially hybrid clouds) wanted this. The group of adminis who didn't want this were mainly the admins who run individual boxes running on bare metal which perform a limited number of tasks: i.e. the admins who like the "Linux way" were the admins who mainly use Linux like a Unix of the early 1990s.
The decades of Unix people who came before him mostly worked on big box Unixes and those did introduce process managers. Linux prior to systemd was fairly unique in at least the last 20 years of Unix history in not having enterprise features for running on large hardware configurations.
No. It got adopted by Debian because there were upstream dependencies on it. Debian is just a Linux distribution. If the developers who make underlying software (upstream) that goes into packages create dependencies on systemd then Debian has to follow.
There is two definitions of modular here and if you are going to defend your position you might want to use less emotive language:
a) Modular = a collection of binary modules each of which is replaceable but often the replacement needs to provide a specific binary API. Systemd is modular in that sense.
b) Modular = a loose collection of programs that work together via. the command line and communicate mostly via. ASCII streams. Systemd is not modular in that sense.
Systemd is modular in the 1st sense but not the 2nd. What you are complaining about is not that it isn't modular but rather that the modules are tightly integrated and at this point that no one is making alternatives so that system admins who don't want to program don't have options.
. Whoever gave him the right to make his shit the essential system component of the Red Hat OS without consulting anyone has a lot to answer for.
Paul J. Cormier former head of JBOSS then head of engineering at RedHat and now President of Products & Technologies. Cormier was appointed by the board.
Because there are other features of machinectl like machinectl status which give you information about VMs and containers machinectl enable which enables or disables containers....
Yes he dislikes shell scripts as being an important part of the system. That's been the entire argument regarding systemd on countless issues. Most of the criticisms of his stuff are factually incorrect. What is correct though is that his designs use binary interfaces but aren't very shell script friendly. So when people say "systemd doesn't do X" what they really mean is "systemd doesn't do X in a way that integrates well with scripting".
Systemd is not an init daemon. Systemd is a process manager, like you have on most sophisticated operating systems and most of the big box Unixes. Init is just a transitional state that the process manager needs to handle. When you start your analysis by calling systemd an init system you immediately tie yourself in with the anti-systemd lying propaganda.
A proper version of this might be: -- The process manager is taking over one of the means of privilege escalation for shell processes and thus is shifting auditing and monitoring responsibilities away from the legacy system onto itself.
Systemd out of the box is modular and optional. You can replace the modules with other modules of your choosing. The people complaining about systemd however don't want modules that communicate they want loosely integrated commands which use the command line. You could write a module that also had a solid command line interface but then that looks a lot like systemd.
Many companies have recruitment costs./. covers IT. There are plenty of IT companies paying either 20% of a year's salary for IT recruitment or paying something like 40% of the first 6 mo or more to sourcing firms. That's tens of thousands of dollars per candidate and after an expensive search.
There is no good reason to believe that were Uber holding to a static market it would be losing money: that is the Uber is losing money on providing the service. Every indication I've seen is that Uber's losses are growth related. Where would Uber be losing money on a static market?
But that's not the point of a reference implementation,
I agree that's not the point of a reference implementation. The MIT license is a good license for a reference implementation, as is the BSD license. The question was whether it is a good license to advance free software or not. That was the argument. The goals of a reference implementation are not the creation of a free software ecosystem.
You don't know that they would have even bothered with X at all,
I don't know. But it is likely. X was the GUI for Unix. Unix was a cheap operating system that allowed hardware vendors to create workstations and then servers without investing a ton in software. Much the same role as Android (another Unix flavor) plays today. If they didn't use X and went with another GUI they would have had to invent it and support it on an ongoing basis. I can see SGI and maybe Sun. But would DEC for example have wanted that for their GUI? IBM? HP?
Then Linux fails that metric in almost all cases too.
No it doesn't. Linux as used in almost all cases is open source freely available software. The big distributions are mostly free or at the very least have free versions. Linux as an operating system mainly sells support or hardware.
Show me that claim in the context of a "BSD license failure" then.
Just keep clicking parent from this very post. You'll get to this: http://slashdot.org/comments.p... The 3 examples to prove that the open version wouldn't be replaced where: OpenSSH, Apache and X11. X11 of course is the example that the GPL have used for 30 years since it was such a disaster. OpenSSH has had problems. Apache has been more of a mixed bag, it mainly has remained free with a broad community of support. But a lot of the advanced capacity is proprietary.
That would be good. I assume you meant FCC and not FTC. I'm not sure FTC has that power.
I agree there are government mandates and some serious work. There are also some exceptions being made that shouldn't exist. The government for example could move many of their commercial EDIs to IPv6 only and forcing companies (and thus their ISPs) to be at least partially on IPv6.
And that's how it is supposed to work, the better product wins out.
No that's not how it is supposed to work. How it is supposed to work is the free product stays free, and gets so far ahead there isn't a competition at all. Like what's happening in many domains with GPL.
If those competing UNIX vendors had to contribute back then they likely would have used their own fully proprietary implementations to differentiate eachother anyway.
You don't know that. The GPL has a track record of preventing such things.
You define failure as the existence of proprietary extensions, a definition devoted to your ideology rather than based on any objective metric.
The objective metric is whether the in use in the broader ecosystem is free or not. The claim of BSD advocates is that their software doesn't end up proprietary. Their claim is that it is a good free software license, where good is defined as advancing the interests of free software. Saying that advancing the interests of free software is an ideology is simply refusing to address the point.
Anyway I've given you clear failure. You are pretending that failures aren't failures by redefining the criteria so that everything is success. That's just dishonest.
True. The point is not that permissive licenses always fail to maintain free software but that they do often enough so as to have established a long track record of failure.
Eventually these died out and the permissively licensed project that remained became the defacto standard
You have the order wrong. The permissive product gave birth to the proprietary product. Then another permissive product started which copied ideas from the proprietary products, passing them over a decade later.
For all the humdrum about permissive licensing being bad there is *still* no decent restrictively licensed implementation.
When it mattered there were. In 2015 no. All through the 1990s that wasn't true.
Your fantasy is that had that reference implementation been restrictively licensed the proprietary UNIX vendors would have still supported X and they would have done so by building a collaborative free X implementation, but this is just fantasy.
How do you know? That's what's happened many times with GPL products. Again there is a track record.
Additionally given the defacto implementation is still permissively licensed, what are you (or anybody else for that matter) doing to prevent this "disaster" from happening again? Or with any other permissively licensed projects for that matter?
Encourage people not to use the license. Once they have, too late.
so how do I set up my internal DNS server so that everything works fine when my ISP gives me a new prefix every 24 hours, or every time the router is rebooted, or every time they feel like changing my prefix?
They don't do that either. They no longer use DHCP either so you have a fixed (and often more than one) IP as well. No more contention for you, no more contention for them. Remember even a midsized ISP now has more IP addresses in an allocation block than the entire internet is under IPv4.
I'm sure they might change your static address if they want to change their topology say once every 5 years or so. That's different than every boot.
Netflix I don't think uses AWS. In any case Netflix uses more bandwidth than most carriers they can get anything they custom they want from the people handling their data.
Slashdot Mirror
Well you are thinking wrong. The distributions that choose systemd have been able to easily layer Linuxes into more complex systems and as a result IaaS and PaaS type configurations involving literally millions of CPUs or workload running Linux as a base OS are becoming standard. At the same time microservice architectures are thriving making program management much easier.
What they are finding is that Linux finally scales easily to fill the niches their customers want.
systemd is not an init system. It is a process manager. Initialization is just one state it has to manage.
Upstart: couldn't keep up. Systemd came out of solutions to some of the problems with upstrart. There was no good reason in theory upstart couldn't have won, it just didn't.
Launchd is tied to BSD initialization. But... there was an attempt to port its features over to Linux. That was called systemd.
What you might really like is OpenRC which is a "better init for Linux" and doesn't aim to be more than just init version 2. But it is mostly defunct now.
As an aside launchd is open source. The FreeBSD people were able easily to move it over.
Now onto your question:
Those 3 don't support complex tiers of applications that need to work together. They aren't aiming to have say something like Oracle Financials running on them. They aren't used in large configurations involving hundreds (or many thousands or more) CPUs.
I did. All the system admins who were being forced off of VMS, MVS, Solaris, AIX... towards Linux that wanted complex process management wanted this. The system admins who had to work with large numbers of VMs in complex environments (i.e. admin of public, private and especially hybrid clouds) wanted this. The group of adminis who didn't want this were mainly the admins who run individual boxes running on bare metal which perform a limited number of tasks: i.e. the admins who like the "Linux way" were the admins who mainly use Linux like a Unix of the early 1990s.
The decades of Unix people who came before him mostly worked on big box Unixes and those did introduce process managers. Linux prior to systemd was fairly unique in at least the last 20 years of Unix history in not having enterprise features for running on large hardware configurations.
No. It got adopted by Debian because there were upstream dependencies on it. Debian is just a Linux distribution. If the developers who make underlying software (upstream) that goes into packages create dependencies on systemd then Debian has to follow.
There is two definitions of modular here and if you are going to defend your position you might want to use less emotive language:
a) Modular = a collection of binary modules each of which is replaceable but often the replacement needs to provide a specific binary API. Systemd is modular in that sense.
b) Modular = a loose collection of programs that work together via. the command line and communicate mostly via. ASCII streams. Systemd is not modular in that sense.
Systemd is modular in the 1st sense but not the 2nd. What you are complaining about is not that it isn't modular but rather that the modules are tightly integrated and at this point that no one is making alternatives so that system admins who don't want to program don't have options.
Paul J. Cormier former head of JBOSS then head of engineering at RedHat and now President of Products & Technologies. Cormier was appointed by the board.
Because there are other features of machinectl like ....
machinectl status which give you information about VMs and containers
machinectl enable which enables or disables containers
http://www.freedesktop.org/sof...
Yes he dislikes shell scripts as being an important part of the system. That's been the entire argument regarding systemd on countless issues. Most of the criticisms of his stuff are factually incorrect. What is correct though is that his designs use binary interfaces but aren't very shell script friendly. So when people say "systemd doesn't do X" what they really mean is "systemd doesn't do X in a way that integrates well with scripting".
Systemd is not an init daemon. Systemd is a process manager, like you have on most sophisticated operating systems and most of the big box Unixes. Init is just a transitional state that the process manager needs to handle. When you start your analysis by calling systemd an init system you immediately tie yourself in with the anti-systemd lying propaganda.
A proper version of this might be:
-- The process manager is taking over one of the means of privilege escalation for shell processes and thus is shifting auditing and monitoring responsibilities away from the legacy system onto itself.
Systemd owns PID1 and all of userspace. You either trust it or you don't run it.
Systemd out of the box is modular and optional. You can replace the modules with other modules of your choosing. The people complaining about systemd however don't want modules that communicate they want loosely integrated commands which use the command line. You could write a module that also had a solid command line interface but then that looks a lot like systemd.
Many companies have recruitment costs. /. covers IT. There are plenty of IT companies paying either 20% of a year's salary for IT recruitment or paying something like 40% of the first 6 mo or more to sourcing firms. That's tens of thousands of dollars per candidate and after an expensive search.
There is no good reason to believe that were Uber holding to a static market it would be losing money: that is the Uber is losing money on providing the service. Every indication I've seen is that Uber's losses are growth related. Where would Uber be losing money on a static market?
Given that drivers are rated by Uber and thus have a stronger incentive for service (especially UberX) why can't they maintain higher service?
I agree that's not the point of a reference implementation. The MIT license is a good license for a reference implementation, as is the BSD license. The question was whether it is a good license to advance free software or not. That was the argument. The goals of a reference implementation are not the creation of a free software ecosystem.
I don't know. But it is likely. X was the GUI for Unix. Unix was a cheap operating system that allowed hardware vendors to create workstations and then servers without investing a ton in software. Much the same role as Android (another Unix flavor) plays today. If they didn't use X and went with another GUI they would have had to invent it and support it on an ongoing basis. I can see SGI and maybe Sun. But would DEC for example have wanted that for their GUI? IBM? HP?
No it doesn't. Linux as used in almost all cases is open source freely available software. The big distributions are mostly free or at the very least have free versions. Linux as an operating system mainly sells support or hardware.
Just keep clicking parent from this very post. You'll get to this: http://slashdot.org/comments.p...
The 3 examples to prove that the open version wouldn't be replaced where:
OpenSSH, Apache and X11. X11 of course is the example that the GPL have used for 30 years since it was such a disaster. OpenSSH has had problems. Apache has been more of a mixed bag, it mainly has remained free with a broad community of support. But a lot of the advanced capacity is proprietary.
All the ISPs that are going to switch to IPv6 are going to offer IPv4 for sites that don't support v6.
That would be good. I assume you meant FCC and not FTC. I'm not sure FTC has that power.
I agree there are government mandates and some serious work. There are also some exceptions being made that shouldn't exist. The government for example could move many of their commercial EDIs to IPv6 only and forcing companies (and thus their ISPs) to be at least partially on IPv6.
No that's not how it is supposed to work. How it is supposed to work is the free product stays free, and gets so far ahead there isn't a competition at all. Like what's happening in many domains with GPL.
You don't know that. The GPL has a track record of preventing such things.
The objective metric is whether the in use in the broader ecosystem is free or not. The claim of BSD advocates is that their software doesn't end up proprietary. Their claim is that it is a good free software license, where good is defined as advancing the interests of free software. Saying that advancing the interests of free software is an ideology is simply refusing to address the point.
Anyway I've given you clear failure. You are pretending that failures aren't failures by redefining the criteria so that everything is success. That's just dishonest.
True. The point is not that permissive licenses always fail to maintain free software but that they do often enough so as to have established a long track record of failure.
You have the order wrong. The permissive product gave birth to the proprietary product. Then another permissive product started which copied ideas from the proprietary products, passing them over a decade later.
When it mattered there were. In 2015 no. All through the 1990s that wasn't true.
How do you know? That's what's happened many times with GPL products. Again there is a track record.
Encourage people not to use the license. Once they have, too late.
Good point.
They don't do that either. They no longer use DHCP either so you have a fixed (and often more than one) IP as well. No more contention for you, no more contention for them. Remember even a midsized ISP now has more IP addresses in an allocation block than the entire internet is under IPv4.
I'm sure they might change your static address if they want to change their topology say once every 5 years or so. That's different than every boot.
Netflix I don't think uses AWS. In any case Netflix uses more bandwidth than most carriers they can get anything they custom they want from the people handling their data.