The article is completely wrong. The current version of Hypercard (RunRev's LiveCode) is cross platform: iOS, Android, BlackBerry, Windows Phone, Windows Desktop, Linux Desktop, Mac.
TCP/IP DID end up replacing DECnet, but not through political tricks. It was simply preferred.
There are no political tricks in systemd. It was simply preferred.
The DECnat fans were in no way prevented from running DECnet.
Init fans aren't prevented from from init. What they are worried about though is that more and more stuff will have hard dependencies on systemd. In exactly the same way more and more stuff had hard dependencies on TCP/IP.
If by willingly, you mean bent over a barrel, a tie vote in one committee, a pending general resolution to ban dependencies on systemd and a threat to fork the distro, then I suppose so.
Nothing like that happened. It was introduced in the form of launchd a decade ago by Apple. Some people from the Linux community started to port it over. RedHat supported it. Ubuntu disagreed and Gentoo disagreed both creating alternatives. Their alternatives ran into problems and systemd pulled ahead quickly. It got adopted by a standard and then distributions started picking it up. Debian being one of the last.
Now if I have binary logs, I need tools to read them. Which means likely the same system as the one just crashed.
Why? Lots of people have implemented readers for systemd's journal format. Nothing about your process is going to change. Just like you don't read current log files with a hex editor by track and sector you won't read these binary files with a text editor.
As far as a worm, you don't execute any code on the crashed system.
E restarts due to the loop. The dependents either re-connect if well written or if not then they crash and get restarted. In such a case you'd want to insert a test for availability of dependencies in the loop.
They may not automatically restart or reconnect. They don't get notified E has restarted.
In the most extreme case, you could even do something like make runlevel 2 the default and have/etc/rc2.d/S99gothree run telinit 3. Should one of the production services fail, the server tramnsitions to runlevel 2, shutting down all of the production services, then transitions back to runlevel 3 to bring them all back up in order.
That won't work either. Remember F and D are communicating in this scenario. I think if we go enough rounds you will come up with a working solution. But what you would be doing is building the requirement for process management in the init system. Once you accept that process management needs to be in the init then init is out.
More broadly, there are any number of solutions to the problem that are far less intrusive on the rest of the system.
In theory, of course, in practice there aren't. Had OpenRC or Upstart worked we would have the Linux normal situation of a bunch of options with people choosing their favorite. Part of what is making systemd controversial is that the other two realistic options failed as projects so there is really only one choice.
Well actually the dependency could be loading the particular filesystem or it can run a check. But assuming not... then the loading daemon which depends on autofs could fail if the NFS load isn't there.
You can't simultaneously have all of: a) A compute environment dependent on storage X b) High reliability c) Storage X being unreliable
Pick any 2.:) For high reliability I'd make the storage redundant. In your kind of environment use a SAN not a simple NFS against raw storage.
I still have RedHat's printed "Linux Man : The Essential Man Pages for Linux" manpages on my bookshelf. Way way out of date, but it is nice to browse. I miss printed manuals but I have to admit pdf and the web are better.
xinetd does that for internet ports. It doesn't do it for generic sockets. Something like an xinitd+ could do it for sockets. The idea is clearly there, a key hard part done. There might be some work to getting it to work smoothly for partial loading but I'm not sure how useful that is in practice.
$DEITY forbid that you want to remount your NFS shares because you're cutting over to a snapmirror of your Netapp to perform maintenance (or have the vendor perform it). Pardon my language, but systemd absolutely shits the bed when that happens.
I would think AutoFS would take care of that and systemd would be out of the picture. Or if you want to do it manually it would be just like what you would do with init except instead of directly unmounting you disable the service associated with the NFS mount. I don't think I'm following the objection here.
to be fair, but they're edge cases that affect many common enterprise-grade setup
Well absolutely being able to handle filesystem failures is mandatory. I'm still not quite understanding what you are saying doesn't work here.
reliable logging, minimizing attack surface, and avoiding SPOFs
systemd's logging is more reliable not less. As far as SPOFs the move to PaaS makes systems far more redundant not less. Each node is unimportant. As for minimizing attack surface containerization and virtualization are how that's accomplished. Fundamentally that idea is being rejected in favor of dedicated security systems.
That's why I'm so anxiously waiting for the result of Ian's GR
It doesn't really matter. Ian doesn't have a solution for the problem.
Application programmer B creates a systemd dependency in application C. Debian package maintainer D considers this a bug in the package. B tells D to go pound sand.
Now what? Obviously if there is interest in init.d package maintainers can create scripts and add them to the package if it is no big deal, that is if the developer isn't using systemd features. Maintainers can't force upstream to do stuff they don't want to do. The example that changed people's mind was brasero. Once brasero decided to use a chain of dependencies to detect when someone inserted a CD (i.e. no user interaction) what is Debian going to do about it?
If large numbers of people from upstream are committed to systemd (and increasingly they are) Debian can't do anything about it. The opposition from systemd (in so far as it actually exists) is coming from old school admins not developers. Distributions are about wrapping software as it exists or making minor changes.
Of course Linux came out of the hobbyist / Minix community. But that was before any of the distributions you mentioned more during the days of LSI. Most certainly people by 94 were using it for real work, that's when the entire cheap webserver movement was started. 1994 people were running NCSA HTTPd (what would become Apache) on Linux in production. 1994 people who used Linux most certainly did use it for productive work. Heck I was using it as a cheap replacement for a pizza box starting in '95.
As for Linux being disruptive to Unix, it most certainly was. The big Unixes are dead. But that's not what I said. What I said was Unixes, especially Linux and Windows server disrupted the early mini computing platforms.
There was a Unix culture in the 1980s from which Linux came. As for the PC world that was similarly disruptive but Linux as a replacement for Windows was an ideology that came a few years after Linux as a cheap alternative to workstations.
I'm not sure in a 5 9s environment you would care about boot issues. Every machine is already redundant so the only time a new machine would be coming up is
a) When it is entering as another node b) When it is introducing a new / replacement service
An individual system should never be running in a degraded state.
Certainly systemd itself will create a situation like the kernel where if it were to have a critical bug that prevented it from running the system might not in any useful / meaningful sense boot but it isn't going to get through even early testing in that situation. I just don't see how there is any impact on production from possible systemd bugs that are that catastrophic.
So, why not leave systemd in "user centric" distros like standard ubuntu ; but keep init as default in server-distros
Because process management is really important for servers as well. The idea that it is only useful for desktop is a myth. The direction of the Linux server ecosystem is towards PaaS and containerization. The idea is to divorce hardware from specific workloads entirely where individual boxes just becomes a node with compute and storage resources as part of a larger superserver. Essentially a shift back towards a mainframe like paradigm. Init doesn't work well there either.
There are some obvious niche cases where init is superior but they are niche and few. This isn't about ease of use. It is about the fact that Linux in the server space is now becoming something other than a cheap Unix for use in niche cases for stuff that isn't running on industrial Unixes or mainframes. Instead Linux is finally really genuinely replacing those systems and now needs to offer the functional depth they provided.
I think systemd is excellent for servers, I think the wide adoption by PaaS vendors proves this. I also happen to think process management is good for most embedded systems. Because they often have less support, both human and other infrastructure being able to do internal process management is a plus. So I disagree strongly that systemd is about desktop, that's a myth.
That being said though I agree that systemd is a bad choice for low memory embedded systems. But frankly I think Debian is mostly a bad choice for low memory embedded systems. Those really do need specialized distributions and those specialized distributions exist. Certainly Debian can feed those as a parent distribution and there is no reason that for those packages which are appropriate for embedded I'd expect people to supply patches to make the package work with cheaper (in terms of memory / CPU) init systems.
Your history is a bit off here. Linux's earliest intent was as a workstation OS. An operating system that Unix users could administrate and on their x86 box. A $2k alternative to buying a $7k Solaris workstation. RedHat itself came from this desktop mold, before the LAMP stack made the real action cheap server alternatives. Mandrake, Caldera Desktop, Corel Desktop were all doing easy desktop before Ubuntu. What was unique about Ubuntu was: it was free and gave away the CDs. Everyone else was trying to make money selling the operating system.
What you are right about is that Ubuntu created a generation of Linux users with no experience with other Unixes or often other Linuxes. In so far as Linux was ever successful on the desktop Ubuntu was the form of that success. Your paranoia about "disruption" and "the establishment"... is simply that. Exactly what do you think in the 1980-90s you were doing to the mini computer culture of the generation before you when you made client server cheap and ubiquitous?
For example, RedHat in 1994-6 was selling a commercial X-Server as an option because XFree86 was too hard and too crappy. That wouldn't have been the case if no one cared about ease of use or just doing bug reports. ____
As for the "no plan" that was part of Linux culture from the beginning. It was one of the things that distinguished the GNU community from the 386BSD guys (and the children that spun off to be the today's BSDs).
systemd is able to have server sockets and listen to them creating the underlying process on an as needed basis. One of the reasons the Unix shell was so successful was because there were all these little utility programs around that could be easily patched together via. scripting. This made simple applications really really easy in Unix. What systemd does is allows the creation of something like this for application services. You could have hundreds of thousands of socket services being offered by a collection of applications always available but not consuming resources until needed. Which allows applications to mainly consist of just pasting together services from other applications in unique ways.
To do this though the system has to be doing more than just simple initiating services during boot it needs to talk on other roles. This is one of the reasons that systemd is designed for process initiation all the time.
Slashdot Mirror
LiveCode. http://livecode.com/
I'm glad someone posted that. LiveCard is basically HyperCard.
The article is completely wrong. The current version of Hypercard (RunRev's LiveCode) is cross platform: iOS, Android, BlackBerry, Windows Phone, Windows Desktop, Linux Desktop, Mac.
It has been revived and it has a free / open source version: http://livecode.com/
Far better than the original.
respawn handles a process going down intentionally. It doesn't handle process crashing, locking up....
You have a good point about memory management being an alternative for holding huge numbers of sockets open.
There are no political tricks in systemd. It was simply preferred.
Init fans aren't prevented from from init. What they are worried about though is that more and more stuff will have hard dependencies on systemd. In exactly the same way more and more stuff had hard dependencies on TCP/IP.
Nothing like that happened. It was introduced in the form of launchd a decade ago by Apple. Some people from the Linux community started to port it over. RedHat supported it. Ubuntu disagreed and Gentoo disagreed both creating alternatives. Their alternatives ran into problems and systemd pulled ahead quickly. It got adopted by a standard and then distributions started picking it up. Debian being one of the last.
Why? Lots of people have implemented readers for systemd's journal format. Nothing about your process is going to change. Just like you don't read current log files with a hex editor by track and sector you won't read these binary files with a text editor.
As far as a worm, you don't execute any code on the crashed system.
They may not automatically restart or reconnect. They don't get notified E has restarted.
That won't work either. Remember F and D are communicating in this scenario. I think if we go enough rounds you will come up with a working solution. But what you would be doing is building the requirement for process management in the init system. Once you accept that process management needs to be in the init then init is out.
In theory, of course, in practice there aren't. Had OpenRC or Upstart worked we would have the Linux normal situation of a bunch of options with people choosing their favorite. Part of what is making systemd controversial is that the other two realistic options failed as projects so there is really only one choice.
Well actually the dependency could be loading the particular filesystem or it can run a check. But assuming not... then the loading daemon which depends on autofs could fail if the NFS load isn't there.
You can't simultaneously have all of:
a) A compute environment dependent on storage X
b) High reliability
c) Storage X being unreliable
Pick any 2. :) For high reliability I'd make the storage redundant. In your kind of environment use a SAN not a simple NFS against raw storage.
You mean like replacing DECNet with Unix style TCP/IP networking for example nothing like that happened? :) Or replacing VWS/UIS with X-Windows?
That's what they did. Distributions are willing adopting it. People are switching over to their side.
I still have RedHat's printed "Linux Man : The Essential Man Pages for Linux" manpages on my bookshelf. Way way out of date, but it is nice to browse. I miss printed manuals but I have to admit pdf and the web are better.
What if the process has dependencies?
So assume
A and B depend on C, D and E.
D depends on E.
D and F are currently communicating but no dependency.
E crashes.
xinetd does that for internet ports. It doesn't do it for generic sockets. Something like an xinitd+ could do it for sockets. The idea is clearly there, a key hard part done. There might be some work to getting it to work smoothly for partial loading but I'm not sure how useful that is in practice.
iOS uses launchctl which is systemd's father.
I would think AutoFS would take care of that and systemd would be out of the picture. Or if you want to do it manually it would be just like what you would do with init except instead of directly unmounting you disable the service associated with the NFS mount. I don't think I'm following the objection here.
Well absolutely being able to handle filesystem failures is mandatory. I'm still not quite understanding what you are saying doesn't work here.
systemd's logging is more reliable not less.
As far as SPOFs the move to PaaS makes systems far more redundant not less. Each node is unimportant.
As for minimizing attack surface containerization and virtualization are how that's accomplished. Fundamentally that idea is being rejected in favor of dedicated security systems.
It doesn't really matter. Ian doesn't have a solution for the problem.
Application programmer B creates a systemd dependency in application C.
Debian package maintainer D considers this a bug in the package.
B tells D to go pound sand.
Now what? Obviously if there is interest in init.d package maintainers can create scripts and add them to the package if it is no big deal, that is if the developer isn't using systemd features. Maintainers can't force upstream to do stuff they don't want to do. The example that changed people's mind was brasero. Once brasero decided to use a chain of dependencies to detect when someone inserted a CD (i.e. no user interaction) what is Debian going to do about it?
If large numbers of people from upstream are committed to systemd (and increasingly they are) Debian can't do anything about it. The opposition from systemd (in so far as it actually exists) is coming from old school admins not developers. Distributions are about wrapping software as it exists or making minor changes.
Of course Linux came out of the hobbyist / Minix community. But that was before any of the distributions you mentioned more during the days of LSI. Most certainly people by 94 were using it for real work, that's when the entire cheap webserver movement was started. 1994 people were running NCSA HTTPd (what would become Apache) on Linux in production. 1994 people who used Linux most certainly did use it for productive work. Heck I was using it as a cheap replacement for a pizza box starting in '95.
As for Linux being disruptive to Unix, it most certainly was. The big Unixes are dead. But that's not what I said. What I said was Unixes, especially Linux and Windows server disrupted the early mini computing platforms.
There was a Unix culture in the 1980s from which Linux came. As for the PC world that was similarly disruptive but Linux as a replacement for Windows was an ideology that came a few years after Linux as a cheap alternative to workstations.
I'm not sure in a 5 9s environment you would care about boot issues. Every machine is already redundant so the only time a new machine would be coming up is
a) When it is entering as another node
b) When it is introducing a new / replacement service
An individual system should never be running in a degraded state.
Certainly systemd itself will create a situation like the kernel where if it were to have a critical bug that prevented it from running the system might not in any useful / meaningful sense boot but it isn't going to get through even early testing in that situation. I just don't see how there is any impact on production from possible systemd bugs that are that catastrophic.
Nope: https://uglyman.kremlin.cc/git...
Because process management is really important for servers as well. The idea that it is only useful for desktop is a myth. The direction of the Linux server ecosystem is towards PaaS and containerization. The idea is to divorce hardware from specific workloads entirely where individual boxes just becomes a node with compute and storage resources as part of a larger superserver. Essentially a shift back towards a mainframe like paradigm. Init doesn't work well there either.
There are some obvious niche cases where init is superior but they are niche and few. This isn't about ease of use. It is about the fact that Linux in the server space is now becoming something other than a cheap Unix for use in niche cases for stuff that isn't running on industrial Unixes or mainframes. Instead Linux is finally really genuinely replacing those systems and now needs to offer the functional depth they provided.
I think systemd is excellent for servers, I think the wide adoption by PaaS vendors proves this. I also happen to think process management is good for most embedded systems. Because they often have less support, both human and other infrastructure being able to do internal process management is a plus. So I disagree strongly that systemd is about desktop, that's a myth.
That being said though I agree that systemd is a bad choice for low memory embedded systems. But frankly I think Debian is mostly a bad choice for low memory embedded systems. Those really do need specialized distributions and those specialized distributions exist. Certainly Debian can feed those as a parent distribution and there is no reason that for those packages which are appropriate for embedded I'd expect people to supply patches to make the package work with cheaper (in terms of memory / CPU) init systems.
Your history is a bit off here. Linux's earliest intent was as a workstation OS. An operating system that Unix users could administrate and on their x86 box. A $2k alternative to buying a $7k Solaris workstation. RedHat itself came from this desktop mold, before the LAMP stack made the real action cheap server alternatives. Mandrake, Caldera Desktop, Corel Desktop were all doing easy desktop before Ubuntu. What was unique about Ubuntu was: it was free and gave away the CDs. Everyone else was trying to make money selling the operating system.
What you are right about is that Ubuntu created a generation of Linux users with no experience with other Unixes or often other Linuxes. In so far as Linux was ever successful on the desktop Ubuntu was the form of that success. Your paranoia about "disruption" and "the establishment"... is simply that. Exactly what do you think in the 1980-90s you were doing to the mini computer culture of the generation before you when you made client server cheap and ubiquitous?
For example, RedHat in 1994-6 was selling a commercial X-Server as an option because XFree86 was too hard and too crappy. That wouldn't have been the case if no one cared about ease of use or just doing bug reports.
____
As for the "no plan" that was part of Linux culture from the beginning. It was one of the things that distinguished the GNU community from the 386BSD guys (and the children that spun off to be the today's BSDs).
systemd is able to have server sockets and listen to them creating the underlying process on an as needed basis. One of the reasons the Unix shell was so successful was because there were all these little utility programs around that could be easily patched together via. scripting. This made simple applications really really easy in Unix. What systemd does is allows the creation of something like this for application services. You could have hundreds of thousands of socket services being offered by a collection of applications always available but not consuming resources until needed. Which allows applications to mainly consist of just pasting together services from other applications in unique ways.
To do this though the system has to be doing more than just simple initiating services during boot it needs to talk on other roles. This is one of the reasons that systemd is designed for process initiation all the time.