And that's the problem. A typical init.d script is a pile of excrement with cryptic start-stop-daemon invocations and other such black magic. It's easy to overlook obvious bugs.
Let's check BIND9 init.d script from Debian: http://anonscm.debian.org/cgit... Notice the infinite loop at line 92 and a butt-fuck-ugly way to check that the network is up (by invoking ifconfig in a loop). Really beautiful and modern code. Not.
Now let's check the systemd unit file:
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop
[Install]
WantedBy=multi-user.target
That's it. It's so short that I can cut&paste it here and it _also_ correctly detects network going up, can be started in parallel, can't hang indefinitely during the shutdown and so on.
Systemd actually cut our startup time by about 1 minute down to about 15-20 seconds. Most of this because we can start PostgreSQL and its dependents (we use Jetty instead of Tomcat) in parallel with disks still being mounted. And this actually saves time.
Yes, I know that. But that's just a cargo cult security _now_. And it's not simply useless, it has actual negative impact because some daemons have to run as root all the time (like ejabberd) or at least during the config file parsing (Apache).
You CAN do whatever crazy perverted things you want with systemd, just write a bash script and go wild. Systemd can work fine with that. It's even possible to override the reboot timeout logic (but you have to ask for it explicitly).
And UNIX so called 'security model' is just another bullshytt. Restricting low ports adds NO security WHATSOEVER.
I'm running large clusters. One extra minute spent during the startup of 10000 nodes works out to 3 compute-hours. Sometimes we do multiple reboots every day.
Then there's a question of dynamic configuration: disks are attached and detached all the time, services can depend on disks being attached correctly, and so on. How do you make sure that your PostgreSQL server does not start until the disk with the data directories is mounted? Systemd does this out of box.
Yeah, because I'm admining sometimes 10000 machines at a time. A small race condition that happens in 0.1% cases means at least 10 machines failing to start. And I have to deal with it.
But I understand, old sysadmins are used to having One Big Machine where they are kings of the realm, lording their power over mere users. Sorry, granpa but these days are over.
I don't fucking care how it's been done before. This is a stupid limitation that serves NO useful purpose whatsoever - lots of legitimate services use ports greater than 1024. And ejabberd quite sanely does not do any stupid dances with dropping privileges, not in the least because it can dynamically add or remove services. Can you guess the first init system to deal with this issue?
Also, you should talk to your distribution's BIND maintainer about his shitty init scripts.
And that's the point. Any random Joe Shmuck can make a minor mistake in a 'blinkenlightsd' init script that can cause the whole system to collapse during the restart. Systemd deals with it, cleanly.
And these problems are? Currently init.d scripts are a pile of shit. For example, BIND9 init script in Debian waits indefinitely until BIND server goes down. So your shutdown/reboot sequence will hang indefinitely if for some reason BIND refuses to die. It happened to me personally and required a midnight trip into our datacenter.
Systemd does NOT replace anything. If daemons want to do some kind of perverted POSIXy BDSM sex, they are totally free to do this. Systemd can work with these kinds of daemons just fine, with only minor loss of parallel service start capabilities.
Sure. Systemd also has a watchdog infrastructure - your service can periodically touch a certain file, and if it hasn't been updated for a certain amount of time then systemd will restart your service. Or you can do something totally crazy and simply use systemd to stop/start your service.
The whole fucking Unix SysV init mess is a sticking pile of shit. It has never worked correctly. Not once. It's just _lucky_ to work most of the time.
Personally, I had tons of problems. How about visiting a datacenter at 4am because BIND9 shutdown scripts can hang indefinitely? Or maybe having a subtle race when a device appears 5-10 too late once in 10-20 reboots? Or maybe having to run ejabberd as root, because it simply wants to bind to a 1024 port?
Lots of apartments in NY are rent-controlled. I once lived in an apartment for $500 a month (it was a really crappy one, I could hear a neighbor 2 floors up). Somebody was also Airbnb-ing an apartment in this house for $80 a day.
Look at a typical service station on I-95 or I-5. They typically have a large parking lot, so people can leave their car and go eat something. So simply electrifying some of the parking lot spots would be quite enough to replace the pumps.
Except that Azure is crap and the only reason they are the second is that Google gives even less crap about Google Compute. Amazon is waaaaaaay better in almost any regard (price, availability, API design, documentation, the quality of products, the number of products, and so on).
We're not speaking about households. We're speaking about huge geographic areas that would have to redo their grids completely. You truly have no idea what you're even posting about.
No, it simply explains how the baseload generation works in Germany.
It works differently in other countries. The definition of baseload is: "Base load power sources are those plants which can generate dependable power to consistently meet demand". That's it. It might be variable or constant, it doesn't matter.
The answer is: "I want a pony". Current proposals for such grids include superconducting geographically-sized DC buses. And these are the most _realistic_ proposals.
It is NOT an easy problem. Energy storage might well be easier, and there's even a good prospective technology for that (vanadium flow batteries).
As I pointed out: baseload is adjusted every week or every few weeks, so the plants can be used at optimum. But baseload is not changing during the time of the day.
Dude, I pointed you at a specific example. Here's the dashboard for the generation in France: https://clients.rte-france.com... - notice the "Generation forecast" graph. It shows that the generation changes drastically throughout the day, even though France uses mostly nuclear power plants.
Is exporting now a bad thing?
Yes, it is. Because it implies that somebody else does the balancing.
The distance between TX and Maine is about 3000 km. That's way more than the average length for the power transmission (500 km). And such conditions do NOT require one huge weather system, just several smaller weather systems that happen at the same time. That happens about once or twice a year for the Eastern coast.
So no, current grid can not cope with the variability of renewable sources.
Yep. And other countries have adjustable baseload generation, like France or use hydroaccumulating stations (like Norway). BTW, Germany does NOT export energy into Ukraine, it's exactly the reverse.
Slashdot Mirror
Let's check BIND9 init.d script from Debian: http://anonscm.debian.org/cgit... Notice the infinite loop at line 92 and a butt-fuck-ugly way to check that the network is up (by invoking ifconfig in a loop). Really beautiful and modern code. Not.
Now let's check the systemd unit file:
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop
[Install]
WantedBy=multi-user.target
That's it. It's so short that I can cut&paste it here and it _also_ correctly detects network going up, can be started in parallel, can't hang indefinitely during the shutdown and so on.
Systemd actually cut our startup time by about 1 minute down to about 15-20 seconds. Most of this because we can start PostgreSQL and its dependents (we use Jetty instead of Tomcat) in parallel with disks still being mounted. And this actually saves time.
Systemd simply rocks.
Yes, I know that. But that's just a cargo cult security _now_. And it's not simply useless, it has actual negative impact because some daemons have to run as root all the time (like ejabberd) or at least during the config file parsing (Apache).
So? A reliable system should cope with such failures. Even Microsoft Windows does.
Bullshit. On both issues.
You CAN do whatever crazy perverted things you want with systemd, just write a bash script and go wild. Systemd can work fine with that. It's even possible to override the reboot timeout logic (but you have to ask for it explicitly).
And UNIX so called 'security model' is just another bullshytt. Restricting low ports adds NO security WHATSOEVER.
I'm running large clusters. One extra minute spent during the startup of 10000 nodes works out to 3 compute-hours. Sometimes we do multiple reboots every day.
Then there's a question of dynamic configuration: disks are attached and detached all the time, services can depend on disks being attached correctly, and so on. How do you make sure that your PostgreSQL server does not start until the disk with the data directories is mounted? Systemd does this out of box.
Yeah, because I'm admining sometimes 10000 machines at a time. A small race condition that happens in 0.1% cases means at least 10 machines failing to start. And I have to deal with it.
But I understand, old sysadmins are used to having One Big Machine where they are kings of the realm, lording their power over mere users. Sorry, granpa but these days are over.
Also, you should talk to your distribution's BIND maintainer about his shitty init scripts.
And that's the point. Any random Joe Shmuck can make a minor mistake in a 'blinkenlightsd' init script that can cause the whole system to collapse during the restart. Systemd deals with it, cleanly.
And these problems are? Currently init.d scripts are a pile of shit. For example, BIND9 init script in Debian waits indefinitely until BIND server goes down. So your shutdown/reboot sequence will hang indefinitely if for some reason BIND refuses to die. It happened to me personally and required a midnight trip into our datacenter.
Systemd does NOT replace anything. If daemons want to do some kind of perverted POSIXy BDSM sex, they are totally free to do this. Systemd can work with these kinds of daemons just fine, with only minor loss of parallel service start capabilities.
What problems do you have with journald? Do you know, that you can trivially redirect all logs into rsyslogd or directly into plain text files?
None of the replacements were really worth it (including Upstart). With systemd, however, it's different.
Sure. Systemd also has a watchdog infrastructure - your service can periodically touch a certain file, and if it hasn't been updated for a certain amount of time then systemd will restart your service. Or you can do something totally crazy and simply use systemd to stop/start your service.
What's broken? ARE YOU FUCKING JOKING????
The whole fucking Unix SysV init mess is a sticking pile of shit. It has never worked correctly. Not once. It's just _lucky_ to work most of the time.
Personally, I had tons of problems. How about visiting a datacenter at 4am because BIND9 shutdown scripts can hang indefinitely? Or maybe having a subtle race when a device appears 5-10 too late once in 10-20 reboots? Or maybe having to run ejabberd as root, because it simply wants to bind to a 1024 port?
Lots of apartments in NY are rent-controlled. I once lived in an apartment for $500 a month (it was a really crappy one, I could hear a neighbor 2 floors up). Somebody was also Airbnb-ing an apartment in this house for $80 a day.
Well, I've heard that they are hiring ISIS to make sure of that. I've also heard that they are terminating the service next year.
Look at a typical service station on I-95 or I-5. They typically have a large parking lot, so people can leave their car and go eat something. So simply electrifying some of the parking lot spots would be quite enough to replace the pumps.
Except that Azure is crap and the only reason they are the second is that Google gives even less crap about Google Compute. Amazon is waaaaaaay better in almost any regard (price, availability, API design, documentation, the quality of products, the number of products, and so on).
:facepalm:
We're not speaking about households. We're speaking about huge geographic areas that would have to redo their grids completely. You truly have no idea what you're even posting about.
I gave you a definition from a dictionary.
No, it simply explains how the baseload generation works in Germany.
It works differently in other countries. The definition of baseload is: "Base load power sources are those plants which can generate dependable power to consistently meet demand". That's it. It might be variable or constant, it doesn't matter.
The answer is: "I want a pony". Current proposals for such grids include superconducting geographically-sized DC buses. And these are the most _realistic_ proposals.
It is NOT an easy problem. Energy storage might well be easier, and there's even a good prospective technology for that (vanadium flow batteries).
As I pointed out: baseload is adjusted every week or every few weeks, so the plants can be used at optimum. But baseload is not changing during the time of the day.
Dude, I pointed you at a specific example. Here's the dashboard for the generation in France: https://clients.rte-france.com... - notice the "Generation forecast" graph. It shows that the generation changes drastically throughout the day, even though France uses mostly nuclear power plants.
Is exporting now a bad thing?
Yes, it is. Because it implies that somebody else does the balancing.
The distance between TX and Maine is about 3000 km. That's way more than the average length for the power transmission (500 km). And such conditions do NOT require one huge weather system, just several smaller weather systems that happen at the same time. That happens about once or twice a year for the Eastern coast.
So no, current grid can not cope with the variability of renewable sources.
Yep. And other countries have adjustable baseload generation, like France or use hydroaccumulating stations (like Norway). BTW, Germany does NOT export energy into Ukraine, it's exactly the reverse.