The reason for logind is technical - GNOME needs a session manager. Logind can't run without functionality that was originally provided by systemd only.
Glyphosate has been used for ages, even before the glyphosate-reistant GM plants. Before the glyphosate even much worse pesticides were used. So I think your 'farmers' are talking shit or pining for the good old days when the grass was greener.
You don't need to do anything with systemd. Debian now uses insserv, so I assumed that you would do tree recalculation. And still, after modifying the script you'd have to always check the updates to the initscript and merge them manually.
Yes, because systemd is a very logical consequence of trying to reason from the first principles about a good init system. If you try to think (try it, it's fun!) about it then you'd arrive to pretty much the same conclusion.
The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1.
Yes, it's written ONCE, thoroughly audited and tested on variety of systems.
Which is better is not clear just from looking at the files.
I see some studies that show animals are not doing so great on this new corn, so I have some concerns.
That's actually not true. All the independent studies point out that GM foods are safe. All the studies showing harm from GM foods are poorly controlled and/or outright fakes.
Systemd core (the thing that you want to replace) is a pretty simple piece of code. You don't even need to replace all of it to get most of its functionality. And GNOME does not depend on systemd, it depends on logind DBUS interface that can be implemented without systemd at all (see: "systemd-shim" package in Debian/Ubuntu).
You can replace the complex binary and they'll still work. You can even use an offline generator to translate unit-files into shell scripts, nosh ( http://homepage.ntlworld.com/j... ) does just that.
OK, you made a good case for cgroups, but you failed to advocate systemd.
Then start thinking about an init system that uses cgroups for process tracking. Suddenly you can dispense with the cryptic start-stop-daemon invocations, you can reliably track the service state (to check if it's completely dead) and so on. Then you realize that you're actually halfway to systemd!
Individual initscripts might support instanced services, but that really depends on the script writer. For example, Apache or nginx initscripts do not support multiple instances. And the most classic instanced service (gettys) have to be written using inittab.
Yes, it's hard if you're not physically doing it or you need to do it on 10-20 machines. And what if the script contains important fixes inside and blindly selecting "Keep local changes" leaves your system vulnerable?
'Interpreter'? Systemd doesn't interpret the unit files, they are simple declarative definitions. Do you think that INI-style parser is too complicated to write?
In contrast, shell interpreters are vastly better tested for much longer.
Yes, that's because better-tasting tomatoes are too difficult to handle. They are too easily damaged so it's not cost-effective to sell them in supermarkets. The GM tomatoes in question actually turned off the biochemical pathway that made ripe tomatoes so easy to break (please not, they haven't even inserted new genes or anything!).
The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file.
There's an infinite loop near line 92 if for some reason BIND becomes unresponsive to signals. That actually happened to me, so that's why I can pinpoint it. And to add insult to injury, this loop happens during service shutdown and can leave the machine inaccessible remotely.
Yes, a boot script with an infinite loop is horrid. And the init system is horrid because it allows this and provides no diagnostics about it. Moreover, the crappy SysV init requires all the init scripts to reinvent everything and it's no wonder that sometimes scripts get it wrong.
Wrong. The first commercially-available GM plant (tomatoes) was marketed as a healthier and tastier alternative to non-GM plants. And it actually was much tastier, because it allowed tomatoes to ripe while still on the vine, not on the way to the market.
That. You have no idea about Unix, do you? The only primitive in Unix that allows to track processes is wait(2) and it's inherently racy.
There's also SIGCHLD but it's delivered only to the parent, and the typical double-forking pattern reparents processes to PID 1. So when a classic PID 1 receives a SIGCHLD from a daemonized process it can't do anything with it, because it has no idea to which service the deceased process belonged.
Sure it can. It's called double locking.
Nope. A PID file simply store a numeric PID. It's possible for the process with this PID to die and another process can get this PID. You can double-check that the process you're killing is actually your target process, but this simply _reduces_ the race window.
Slashdot Mirror
The reason for logind is technical - GNOME needs a session manager. Logind can't run without functionality that was originally provided by systemd only.
Glyphosate has been used for ages, even before the glyphosate-reistant GM plants. Before the glyphosate even much worse pesticides were used. So I think your 'farmers' are talking shit or pining for the good old days when the grass was greener.
You don't need to do anything with systemd. Debian now uses insserv, so I assumed that you would do tree recalculation. And still, after modifying the script you'd have to always check the updates to the initscript and merge them manually.
Can the "not doing well" be quantified? What does it fucking even mean?
And yes, I've actually worked in molecular biology (not on GM foods) and I know a little bit about it.
Yes, because systemd is a very logical consequence of trying to reason from the first principles about a good init system. If you try to think (try it, it's fun!) about it then you'd arrive to pretty much the same conclusion.
Yep. That means: "no solution".
The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1.
Yes, it's written ONCE, thoroughly audited and tested on variety of systems.
Which is better is not clear just from looking at the files.
Look at http://anonscm.debian.org/cgit... - can you spot a fatal flaw in this file?
It will not tolerate not being PID1 and it demands all of it's dependencies be met.
Systemd actually works just fine as a non-PID1 and its replacement can do it just as well. It can be even be used for non-root users.
So you can start by making a simple daemon that oversees only the processes it manages and slowly expand it to replace systemd.
Dude, get a fucking grip and read the fucking manual. You can learn new stuff, even in advanced age.
So? GNOME developers want to have a reliable session manager. Logind was the only solution, systemd-shim came later.
I see some studies that show animals are not doing so great on this new corn, so I have some concerns.
That's actually not true. All the independent studies point out that GM foods are safe. All the studies showing harm from GM foods are poorly controlled and/or outright fakes.
So you're admitting that classic init scripts offer poor configurability and no real solution for configuration changes. Noted.
Systemd core (the thing that you want to replace) is a pretty simple piece of code. You don't even need to replace all of it to get most of its functionality. And GNOME does not depend on systemd, it depends on logind DBUS interface that can be implemented without systemd at all (see: "systemd-shim" package in Debian/Ubuntu).
Yeah, I've eaten shit sandwiches - they're also called SysV scripts.
You can replace the complex binary and they'll still work. You can even use an offline generator to translate unit-files into shell scripts, nosh ( http://homepage.ntlworld.com/j... ) does just that.
OK, you made a good case for cgroups, but you failed to advocate systemd.
Then start thinking about an init system that uses cgroups for process tracking. Suddenly you can dispense with the cryptic start-stop-daemon invocations, you can reliably track the service state (to check if it's completely dead) and so on. Then you realize that you're actually halfway to systemd!
Individual initscripts might support instanced services, but that really depends on the script writer. For example, Apache or nginx initscripts do not support multiple instances. And the most classic instanced service (gettys) have to be written using inittab.
Yes, it's hard if you're not physically doing it or you need to do it on 10-20 machines. And what if the script contains important fixes inside and blindly selecting "Keep local changes" leaves your system vulnerable?
In contrast, shell interpreters are vastly better tested for much longer.
LOL ROTFL. You've been sleeping the last two months, haven't you? I'll just leave it here: http://en.wikipedia.org/wiki/S...
Ah, you must be one of the luddites. Thank you for confirming my point. Don't worry grampa, the world will go on without you.
Yes, that's because better-tasting tomatoes are too difficult to handle. They are too easily damaged so it's not cost-effective to sell them in supermarkets. The GM tomatoes in question actually turned off the biochemical pathway that made ripe tomatoes so easy to break (please not, they haven't even inserted new genes or anything!).
Why does it make it difficult to replace systemd?
The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file.
There's an infinite loop near line 92 if for some reason BIND becomes unresponsive to signals. That actually happened to me, so that's why I can pinpoint it. And to add insult to injury, this loop happens during service shutdown and can leave the machine inaccessible remotely.
Now let's check the systemd's version of this file: http://pkgs.fedoraproject.org/... Please tell me which one is better.
You want people to test code on weird clusters
Not really. I simply want people to stop assuming that race conditions are rare and write reliable software.
Yes, a boot script with an infinite loop is horrid. And the init system is horrid because it allows this and provides no diagnostics about it. Moreover, the crappy SysV init requires all the init scripts to reinvent everything and it's no wonder that sometimes scripts get it wrong.
Wrong. The first commercially-available GM plant (tomatoes) was marketed as a healthier and tastier alternative to non-GM plants. And it actually was much tastier, because it allowed tomatoes to ripe while still on the vine, not on the way to the market.
Wait, what?
That. You have no idea about Unix, do you? The only primitive in Unix that allows to track processes is wait(2) and it's inherently racy.
There's also SIGCHLD but it's delivered only to the parent, and the typical double-forking pattern reparents processes to PID 1. So when a classic PID 1 receives a SIGCHLD from a daemonized process it can't do anything with it, because it has no idea to which service the deceased process belonged.
Sure it can. It's called double locking.
Nope. A PID file simply store a numeric PID. It's possible for the process with this PID to die and another process can get this PID. You can double-check that the process you're killing is actually your target process, but this simply _reduces_ the race window.
Uhm, what? Systemd can work just fine as non-PID-1 although it'll be less reliable because there's no protection against SIGKILL.