"Elegant"? I don't think this word means what you think it means. Look inside DHCP source - it's crap. And it's not like DHCP is some kind of an uber-complicated protocol, a simple implementation of it takes about a day to write.
This has nothing to do with really important things (for example, the Apache and MySQL config files), but only affects startup order and parameters to the daemons.
Here's an example for you: your MySQL database lives on a DRBD disk and it takes time to attach it. With SysV init you can't add dependency on a mount point. Well, you can create a service that mounts the data disk and add a dependency on it to the MySQL script.
Except that you have to directly _edit_ the LSB header in the MySQL script to add a new dependency. So if later a distribution update changes the MySQL script, you'd have to manually merge the changes.
Now the systemd way: simply add a "mysql-server.unit" file to/etc/init with this three lines:
[Unit]
After=yourmountpoint.service
Before=yourmountpoint.service
That's it. Systemd will merge the overrides with distro-provided unit file. And you can clearly see what's been overridden.
And in reality you actually don't even _need_ this if you use automount. Systemd will automatically mount the DRBD on MySQL startup.
I personally ran into tons of problems with SysV scripts. They are not theoretical. One of them forced me to go into our data center at night to power-cycle a machine: http://anonscm.debian.org/cgit... (can you find it?)
And yes, I really do hate the old "let's just hack a bash script approach" or "'sleep 10' solves this race" kinds of admins. And mostly because I have to make their shit run on large-scale clusters that experience all kinds of weird failure modes.
Yep. That's exactly what I'm saying. Not Linux per se, but the classic Unix model. All the large cloud users (Google, Facebook) developed something as a result.
One of nodes in your 500-node cluster is hanging because SysV scripts shat down its pants yet again because of a subtle race condition. Reproducing it locally yields nothing. Logging in SysV is nonexistent so debugging the issue is non-trivial. All while your cluster is frozen waiting for that critical DB node to start.
Now enter systemd. The traditional race conditions are solved right away. No more PID races, clean dependencies on mount points. In case of a service failure, its stdout/stderr are readily available. Boot graph with all the dependencies clearly shown is waiting for you to check it. The system status (including service watchdog timers) is easily streamed into an external monitoring system..
No. The traditional initscripts are full of crap because they are built on a crappy foundation. It's not possible to reliably track processes in the classic Unix, so that's why the whole pidfile mess is needed. But of course, pidfiles are fundamentally racy - and it CAN NOT be fixed.
Then there's a question of customization - blindly sourcing files in/etc/default into an init script is a the preferred method. Changing initscripts themselves is seductive but causes maintenance headaches. Dependencies between services are bolted on using LSB (a new invention itself), dependencies on anything other than direct services (like mountpoints) are nonexistent.
Starting several copies of a service is impossible - that's why even crustier inittab is used for gettys.
And so on. I can go on for quite a bit of time. All of these are real problems OF THE INFRASTRUCTURE and have to be worked around using reams of imperative code in bash (or even worse, POSIX sh). There is no deep inner meaning in initscripts - they SHOULD BE OBVIOUS AND SIMPLE.
Which daemons? Systemd 'replaces' NTP and DHCP daemons which never were particularly good. It even turns out that systemd's DHCP implementation was invulnerable for the recent 'shellshock' bug.
Oh, and notice the quote around 'replaces' - systemd can work just fine with the regular implementations.
No, it's not 'simplicity itself'. Inittab has no notion of dependencies, that's why the whole RC-level stuff had to be invented. Inittab has no notion of restart policies so if a service dies immediately after restart then it's certainly possible to get gigabytes of logs filled with output of a failing daemon. Inittab does not redirect output, so it's easy to miss crucial logs. Inittab rules don't care about service's prerequisites like mounted network shares.
It's actually hard to find something that inittab can actually do well.
Nope, I highly doubt it. As for other system, the only comparable solutions are launchd and Solaris SMF. Both are highly unusable and user-hostile, though nice in theory.
Systemd is the first actual usable solution.
My experience with systemd like initialisation systems is that they are not so easy for the new, fledgling administrators to understand and therefore are a source of application down time. I dont like them as a result. Is that OK with you?
If they are taught by crusty old sysadmins who can't see past their BASH manual? Maybe. Otherwise, please describe a way to write a portable initscript for a forking daemon with limited capability set. You know, the stuff that is done in 5 lines in a unit file.
Maybe you could learn a few things from people that have seen the same mistakes you make a hundred times before.
Yeah, sure. Those people continued to perpetuate a culture of broken unreliable systems (before cgroups it was not possible to _reliably_ kill a daemon!). I say give them their Social Security check and kick them out on a pension.
Which indicates that you are also clueless regarding configuration management. Hence, an idiot that should sit down and shut the fuck up while the grown ups talk.
So how do you merge local changes and distribution updates? I'm all ears. For the record, systemd does this cleanly by moving distro-provided unit into/usr while user overrides go into/etc.
What do you mean by "more layers"? Native systemd units are simple declarative descriptions of services, they don't (generally) use shell scripts riddled with infinite loops and hacks to detect dependencies.
See, my prediction is true - you've never used systemd and simply spout haters' talking points.
People that are older, smarter, and wiser than YOU realize that the basic concept of systemd is just fucked.
Yeah, sure. Here's your Social Security check grampa, go and watch Fox news.
While we (the new and stupid generation) actually start designing software that is built on a _reliable_ base instead of cobbled up shitmobile that are classic initscripts. Seriously, when shit scripts like this: http://anonscm.debian.org/cgit... are shipped in a major Linux distribution - you can't hope to build something that works on a large scale with them.
I'm not talking about shell. I'm talking about init.d files, tweaking them by hand, having to manually merge changes to configs during upgrades and so on.
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yep. That's exactly what I've witnessed. Most systemd haters haven't even used it.
The division is not between administrators and users but between luddites and users. Luddite administrators generally spent years learning all the arcana of Unix administration and simply can't accept that a large body of this knowledge is now inapplicable. THAT'S the source of "systemd divide".
Oh, and in our company we manage clusters of up to 30000 machines for our customers. And we simply _love_ systemd because it makes so much easier to make reliable clusters.
Oh, by the way, it turns out that the predominant strain of wheat and maize contains a genetic poison from a nasty bacteria (horizontal gene transfer for TEH WIN!). Entirely natural.
Now let's ban all maize and wheat production on an off chance that some poor bacteria can infect their genomes some time in the future.
Do you realize that this was the desired outcome? Other varieties of wheat still exist. We don't use them for most things on purpose.
Modern wheat has much lower protein content than it would be possible with a healthy genome. Also, modern wheat plants are little Frankenstein monsters with highly polyploid genomes riddled with mobile elements. Turns out that higher protein content can be achieved by fixing some of the problems caused by inbreeding during selection: http://www.researchgate.net/pu...
But no, that's eviiiiiil GMO and natural breeding can't be wrong.
But we cultivated the less-healthy kind on purpose. And if you made it healthier, it wouldn't taste as sweet.
Not modern "we". Maize was cultured by Native Americans and its loss of fat was a genetic accident. Corn with higher fat content would have been even more nutritional (fat is more energy-rich), healthier (less sugars!) and probably just as tasty.
See: http://www.plantphysiol.org/co...
Then there are soybeans. Do you know that soy can't be eaten without processing because it's enriched in anti-nutritional compounds? We can now eliminate them through GM by knocking out relevant genes. Is it also TEH EVILZ?
That'll trigger an instant vomiting reflex in a lot of people. Turns out that our brains think that conflicting visual and vestibular cues mean that we'd ingested something very psychoactive and it's time to try and get rid of it.
If we follow the logic in this book, then we should ban everything up to and including stone tools and fire. For example:
- Computers: might give rise to an artificial intelligence that will destroy everything. Ban them.
- Agriculture: might cause people to lose their natural aggressiveness so they'll be easily conquered by the alien invaders. Ban agriculture.
- Fire: might cause the global firestorm that will destroy all the life. Ban it.
- Stone tools: they might spark the fire that will destroy all the life. Ban it.
- Medicine: might cause humanity to lose natural immunity to diseases. Ban it.
Yes, the modern gene-splicing is much safer. Do you know that wheat lost most of its protein content due to selective breeding? Maize lost most of its fat content due to a genetic error (so its wild predecessors are much healthier).
If the same happened to a GM food then it'd be banned quicker than you can say "paracetomoxyfrusebendroneomycin".
Why should we create markets just to make some leeches richer? Trading spectrum doesn't generate more of it, it doesn't force more efficient usage and it gives monopoly power to several large players.
Slashdot Mirror
"Elegant"? I don't think this word means what you think it means. Look inside DHCP source - it's crap. And it's not like DHCP is some kind of an uber-complicated protocol, a simple implementation of it takes about a day to write.
This has nothing to do with really important things (for example, the Apache and MySQL config files), but only affects startup order and parameters to the daemons.
Here's an example for you: your MySQL database lives on a DRBD disk and it takes time to attach it. With SysV init you can't add dependency on a mount point. Well, you can create a service that mounts the data disk and add a dependency on it to the MySQL script.
/etc/init with this three lines:
Except that you have to directly _edit_ the LSB header in the MySQL script to add a new dependency. So if later a distribution update changes the MySQL script, you'd have to manually merge the changes.
Now the systemd way: simply add a "mysql-server.unit" file to
[Unit]
After=yourmountpoint.service
Before=yourmountpoint.service
That's it. Systemd will merge the overrides with distro-provided unit file. And you can clearly see what's been overridden.
And in reality you actually don't even _need_ this if you use automount. Systemd will automatically mount the DRBD on MySQL startup.
I personally ran into tons of problems with SysV scripts. They are not theoretical. One of them forced me to go into our data center at night to power-cycle a machine: http://anonscm.debian.org/cgit... (can you find it?)
And yes, I really do hate the old "let's just hack a bash script approach" or "'sleep 10' solves this race" kinds of admins. And mostly because I have to make their shit run on large-scale clusters that experience all kinds of weird failure modes.
Yep. That's exactly what I'm saying. Not Linux per se, but the classic Unix model. All the large cloud users (Google, Facebook) developed something as a result.
Good. We're in perfect agreement. Please go and fork Debian, Linux kernel, FreeBSD or whatever. But stop whining about systemd.
One of nodes in your 500-node cluster is hanging because SysV scripts shat down its pants yet again because of a subtle race condition. Reproducing it locally yields nothing. Logging in SysV is nonexistent so debugging the issue is non-trivial. All while your cluster is frozen waiting for that critical DB node to start.
Now enter systemd. The traditional race conditions are solved right away. No more PID races, clean dependencies on mount points. In case of a service failure, its stdout/stderr are readily available. Boot graph with all the dependencies clearly shown is waiting for you to check it. The system status (including service watchdog timers) is easily streamed into an external monitoring system..
Yeah, sure SysV scripts are better.
No. The traditional initscripts are full of crap because they are built on a crappy foundation. It's not possible to reliably track processes in the classic Unix, so that's why the whole pidfile mess is needed. But of course, pidfiles are fundamentally racy - and it CAN NOT be fixed.
/etc/default into an init script is a the preferred method. Changing initscripts themselves is seductive but causes maintenance headaches. Dependencies between services are bolted on using LSB (a new invention itself), dependencies on anything other than direct services (like mountpoints) are nonexistent.
Then there's a question of customization - blindly sourcing files in
Starting several copies of a service is impossible - that's why even crustier inittab is used for gettys.
And so on. I can go on for quite a bit of time. All of these are real problems OF THE INFRASTRUCTURE and have to be worked around using reams of imperative code in bash (or even worse, POSIX sh). There is no deep inner meaning in initscripts - they SHOULD BE OBVIOUS AND SIMPLE.
Which daemons? Systemd 'replaces' NTP and DHCP daemons which never were particularly good. It even turns out that systemd's DHCP implementation was invulnerable for the recent 'shellshock' bug.
Oh, and notice the quote around 'replaces' - systemd can work just fine with the regular implementations.
Please do it ASAP. We server people are fucking tired of constant systemd-whining by old coffin-dodgers who somehow happen to manage servers.
No, it's not 'simplicity itself'. Inittab has no notion of dependencies, that's why the whole RC-level stuff had to be invented. Inittab has no notion of restart policies so if a service dies immediately after restart then it's certainly possible to get gigabytes of logs filled with output of a failing daemon. Inittab does not redirect output, so it's easy to miss crucial logs. Inittab rules don't care about service's prerequisites like mounted network shares.
It's actually hard to find something that inittab can actually do well.
Systemd is the first actual usable solution.
My experience with systemd like initialisation systems is that they are not so easy for the new, fledgling administrators to understand and therefore are a source of application down time. I dont like them as a result. Is that OK with you?
If they are taught by crusty old sysadmins who can't see past their BASH manual? Maybe. Otherwise, please describe a way to write a portable initscript for a forking daemon with limited capability set. You know, the stuff that is done in 5 lines in a unit file.
Maybe you could learn a few things from people that have seen the same mistakes you make a hundred times before.
Yeah, sure. Those people continued to perpetuate a culture of broken unreliable systems (before cgroups it was not possible to _reliably_ kill a daemon!). I say give them their Social Security check and kick them out on a pension.
Which indicates that you are also clueless regarding configuration management. Hence, an idiot that should sit down and shut the fuck up while the grown ups talk.
So how do you merge local changes and distribution updates? I'm all ears. For the record, systemd does this cleanly by moving distro-provided unit into /usr while user overrides go into /etc.
What do you mean by "more layers"? Native systemd units are simple declarative descriptions of services, they don't (generally) use shell scripts riddled with infinite loops and hacks to detect dependencies.
See, my prediction is true - you've never used systemd and simply spout haters' talking points.
People that are older, smarter, and wiser than YOU realize that the basic concept of systemd is just fucked.
Yeah, sure. Here's your Social Security check grampa, go and watch Fox news.
While we (the new and stupid generation) actually start designing software that is built on a _reliable_ base instead of cobbled up shitmobile that are classic initscripts. Seriously, when shit scripts like this: http://anonscm.debian.org/cgit... are shipped in a major Linux distribution - you can't hope to build something that works on a large scale with them.
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yep. That's exactly what I've witnessed. Most systemd haters haven't even used it.
The division is not between administrators and users but between luddites and users. Luddite administrators generally spent years learning all the arcana of Unix administration and simply can't accept that a large body of this knowledge is now inapplicable. THAT'S the source of "systemd divide".
Oh, and in our company we manage clusters of up to 30000 machines for our customers. And we simply _love_ systemd because it makes so much easier to make reliable clusters.
So turn off this gene. Duh. Problem solved.
Oh, by the way, it turns out that the predominant strain of wheat and maize contains a genetic poison from a nasty bacteria (horizontal gene transfer for TEH WIN!). Entirely natural.
Now let's ban all maize and wheat production on an off chance that some poor bacteria can infect their genomes some time in the future.
You can't eat it exactly because of these compounds. You probably can eat carefully prepared fermented soy (tofu).
Do you realize that this was the desired outcome? Other varieties of wheat still exist. We don't use them for most things on purpose.
Modern wheat has much lower protein content than it would be possible with a healthy genome. Also, modern wheat plants are little Frankenstein monsters with highly polyploid genomes riddled with mobile elements. Turns out that higher protein content can be achieved by fixing some of the problems caused by inbreeding during selection: http://www.researchgate.net/pu...
But no, that's eviiiiiil GMO and natural breeding can't be wrong.
But we cultivated the less-healthy kind on purpose. And if you made it healthier, it wouldn't taste as sweet.
Not modern "we". Maize was cultured by Native Americans and its loss of fat was a genetic accident. Corn with higher fat content would have been even more nutritional (fat is more energy-rich), healthier (less sugars!) and probably just as tasty. See: http://www.plantphysiol.org/co...
Then there are soybeans. Do you know that soy can't be eaten without processing because it's enriched in anti-nutritional compounds? We can now eliminate them through GM by knocking out relevant genes. Is it also TEH EVILZ?
That'll trigger an instant vomiting reflex in a lot of people. Turns out that our brains think that conflicting visual and vestibular cues mean that we'd ingested something very psychoactive and it's time to try and get rid of it.
If we follow the logic in this book, then we should ban everything up to and including stone tools and fire. For example:
- Computers: might give rise to an artificial intelligence that will destroy everything. Ban them.
- Agriculture: might cause people to lose their natural aggressiveness so they'll be easily conquered by the alien invaders. Ban agriculture.
- Fire: might cause the global firestorm that will destroy all the life. Ban it.
- Stone tools: they might spark the fire that will destroy all the life. Ban it.
- Medicine: might cause humanity to lose natural immunity to diseases. Ban it.
And so on.
But you can breed together a tree and a beetle.
Or a beetle and a bacteria - http://blogs.discovermagazine....
Yes, the modern gene-splicing is much safer. Do you know that wheat lost most of its protein content due to selective breeding? Maize lost most of its fat content due to a genetic error (so its wild predecessors are much healthier).
If the same happened to a GM food then it'd be banned quicker than you can say "paracetomoxyfrusebendroneomycin".
Why should we create markets just to make some leeches richer? Trading spectrum doesn't generate more of it, it doesn't force more efficient usage and it gives monopoly power to several large players.
If insurgents get sufficient backing by a foreign power or by a faction in the military then the whole question of legally owned small arms is moot.