Wonder how they arrived at a 0.893381 (impressive number of digits btw) probability of a 119 year old male dying within one year, considering that not a single man in history is confirmed to have reached that age.
Gowdy's comments just cater to IT novices who might think that there must be a bad cheap way and a good expensive way to wipe bits from a hard drive, when in fact there's just one way, and it's not particularly clever or complicated. People have written free programs to do it, so everybody uses them. It's just like thinking that anybody who uses a Teraflop/s machine must be using it to design nuclear bombs, until you realise that TFLOPs machines cost 100 bucks these days, so everybody uses them for everything, including writing birthday emails to grandma.
He doesn't "sit trapped in the Ecuadorean embassy" any more than a prissy teenage girl who is mad at her parents and doesn't wanna come down for dinner sits trapped in her room. He can just walk out of there whenever he pleases. The only risk he'd face would be major embarrassment after NOT being deported to the US.
I'm fine with Wayland...
As long as it still runs all my wonderful diverse choices of Unix desktop environments.
Which are used to run a browser and 26 terminals. So no problem there. As long as we have a good browser, lack of Xorg compatibility will become less and less of a issue.
On linux, piping commands in bash are extremely limited. mostly because the command you pipe from cannot customize what data it is going to output to the command you pipe to.
Why exactly should it be able to customize output based on the pipe target? It sounds like something that makes commands work only with some specific other commands, seriously limiting reusability.
Yeah, almost everything that's genuinely useful limits reusability somewhat. By your logic, OOP "limits reusability" compared to raw assembly language, which allows you to do more things, including implementing your own OOP language in it. In reality, OOP tries to hit a sweet spot by constraining reusability somewhat and gaining functionality and ease of reusability for it. I've never used PS, but I understand that using object streams instead of text line streams will provide advantages. If the processes on both ends of the pipe declare what kind of objects the support, the shell can provide enhanced functionality if the processes support it, and fall back to text or to a generic meta object protocol otherwise.
Have you ever tried to grep from an mbox file all mails sent last month by a specific sender? That's gonna be next to impossible because grep doesn't know anything about mails, and because grep is line-oriented, but an mbox file doesn't contain one mail per line. OTOH if you can turn the mbox file into a stream of "Mail" objects, which it really is, the job is probably trivial even with any kind of "object grep" that just works via reflection and doesn't know anything about Mail objects specifically.
Perl isn't very unixish though. It throws everything into one process. Arguably, PS is more unixish except that it has objects where Bash uses (lines of) text.
Just remember that even clean energy ends up as waste heat that must be radiated out into space. Any excess and independent of AGW, the earth starts to heat.
If energy per person continues to grow at the same rate it has since the 1600s, in less than 500 years the earth is over 212 degrees. Energy per person is another limit to growth. And the more people we have, the lower that limit. If we have 20 billion instead of 5 billion, the ultimate cap on energy per person is going to be 1/4th as much.
Yeah, we're a few orders of magnitude away from that. It's T~P^(1/4), T=300K, and the solar power input is currently about 10,000 times the entire human energy production. So a tenfold increase of our power production would lead to about 0.06 Kelvins of temperature rise from direct energy to heat conversion. Or to put it another way, the current AGW temperature increase (~1K) corresponds to the heat equivalent of about 140 times our current energy production. So yes, we won't be able to achieve the same relative growth in energy production over the coming 500 years as we did in the past 500 years, at least as long as we stay on this planet and don't venture into outer space. But that's not really all that relevant for solving the energy and resource consumption problems at hand.
Recycling is well under 100% efficient. It's a good thing but we lose a significant amount of usable material each pass thru the recycling part of the system.
The book "Limits to Growth" includes recycling in it's models.
Conservation and less consumption per person are our best bet but it really only changes to day we hit the limits not the fact that we will hit the limits. We can't sustain our current population level much less the potential for 12 billion by 2100 now projected by the UN.
We now use more of many nonrenewable resources each year than we did during all of last century.
Well, it largely depends (ultimately) on the energy you put into the recycling process. Energy is the only true "nonrenewable resource", due to the 2nd law of thermodynamics. But there's enough of it. What we really have to do is develop technologies and policies to produce large amounts of clean energy. If we don't do that, then even half the current global population number will be unsustainable in the long term, especially if more countries strive to attain western standards of living. If we do do it, then 12 billion or even 20 billion people can be managed. Since forbidding people to consume and prosper didn't even work under communism, it certainly won't in liberal democracies, so our options are quite clear AFAICS.
How about almost every climatology study done in the last forty years?
I tell you what. If you don't think AGW is real, why don't you explain where all the energy being absorbed by CO2 in the atmosphere is going. Are you advocating the "magic heat sink back into space" theory?
I think AGW is real, but I fail to see how you get from that to August 8 as a single date of an "overshoot day". Does this imply that, since on August 8 we're about 60% through the year, we'd have to reduce our CO2 output by 40% to completely stop the increase of atmospheric CO2 levels? That doesn't make any sense at all, given that the worldwide CO2 emissions were 40% lower than today roughly 30 years ago, but by that time the CO2 levels had been increasing for more than a century already. So that doesn't make sense at all unless you postulate that the natural CO2 sinks work at a much higher pace at today's CO2 levels compared to those in 1986.
So what does August 8 represent? Are they computing one overshoot day per type of resource (Hydrocarbons, aluminium, copper,...) and take the average? Or the minimum? And what's a "copper overshoot day" anyways, given that we don't "use up" metals the way we do oil or gas when we burn it. If you count metal as "used up" if it's not recycled but replaced with new raw materials, then the corresponding "overshoot day" would be January 1st because the Earth's crust contains a fixed amount of extractable ores.
Well, he was one of three muslim science nobel prize winners in history (the other two being Abdus Salam and Aziz Sancar). And there are 1.5 billion muslims. By contrast, jewish scientists have won over 100 nobel prizes, and there are only 15 million jews. I guess this means that a muslim is about 5,000 times less likely to become a renowned scientist than a jew is. So while muslim scientists aren't oxymorons, they're an exceedingly rare occurrence.
It seems like a really weird bomb - if we assume middle eastern terrorists. They would be in Paris with a bomb, but choose to go through all the airport security and the risks associated with it just to blow up a plane filled with mostly Egyptians in Egyptian airspace?
Yeah, why not? First, bringing down an airliner means a lot more publicity than just exploding a bomb in a restaurant somewhere. Second, a bomb that kills at most one or two people in a restaurant kills 100+ people when exploded in an airplane because most or all victims won't die from the blast but from, you know, flying in an airplane that's crashing.
Yeah but if you're going to blow up a plane wouldn't you want to do it over land, preferably over a city or something (like the one it just left) where lots of people are likely to see, rather than over some bit of ocean miles and miles away from anything.
Yeah, if you have any control over where exactly the bomb goes off. You seem to be assuming that the terrorist was onboard the plane, on a suicide mission. Which seems pretty unlikely to me.
It seems like a really weird bomb - if we assume middle eastern terrorists. They would be in Paris with a bomb, but choose to go through all the airport security and the risks associated with it just to blow up a plane filled with mostly Egyptians in Egyptian airspace?
Yeah, why not? First, bringing down an airliner means a lot more publicity than just exploding a bomb in a restaurant somewhere. Second, a bomb that kills at most one or two people in a restaurant kills 100+ people when exploded in an airplane because most or all victims won't die from the blast but from, you know, flying in an airplane that's crashing.
So they're not upgrading but replacing Hangouts with not one but two new apps. I'm sure there's a brilliant strategic move hidden in there somewhere that I just fail to see.
And since it's not the 1990's anymore anything worth calling it encrypted is storing keys in specialized hardware, so it's not just a question of getting a debugger out and pawing through memory.
Well, in block device / disk encryption on PCs, they keys are stored on the regular device, but they're stored encrypted with another key, namely the passphrase, which is only stored in the user's brain (hopefully). So unless the device is already running and somebody has already entered the correct passphrase, you can paw through anything you want (except the user's brain) and it won't help.
Still, there are obstacles. SpaceX still needs to demonstrate the ability to consistently produce and launch rockets many times a year after the June accident caused an unexpected, six-month setback, something it will do with several flights planned for the weeks ahead.
Just because it's relatively cheap to use Space X, if I have a 50-50 ( better or worse) chance that my $100 million satellite that took several years to design and build is going to get blown up, I'll pass.
So I'm guessing (and I'm more or less an interested layman here) it would depend o the cost of the payload. Even if reusable rockets turn out to be less reliable, they'd still open up new possibilities IF they're substantially cheaper. If cheaper launches become available, that opens the market up for new, less expensive types of payloads that nobody would've thought of before. If your payload costs two million dollars to build (and to build again if you lose one), you'd probably launch it with the one-million-dollars-per-launch vehicle that's three times more likely to explode. If your payload costs one BILLION dollars, you probably[*] launch with the 60 million per launch vehicle that's three times less likely to explode, because the launch costs are just 6% of your payload anyway. But the thing is, that 2 million dollar payload would not be launched AT ALL if the cheap launcher wasn't available (at least not if the payload is heavy enough so it can't be launched with 10 others on the same flight).
[*]
Even that's not an automatic no-brainer decision if you're thinking of buying one hundred one-billion dollar payload launches and want to have as many dollars in orbit per million dollars expended as possible -- in that case you might launch even the expensive payloads with the cheaper launcher.
Why measure weight? All that's needed to know whether the plane will lift off is the current amount of thrust, the current speed and its acceleration.
The plane lifts off when its lift exceeds its weight. Its *weight*, see? The airspeed (and flaps setting) determines the lift; to determine the weight, you have to, well, weigh the thing.
And that is the whole fun point of it all: AICCU (or anything else) cannot fix network problems
It's not supposed to fix them, it's supposed to retry until they've been fixed externally. And no, you don't expect a user to "read log messages" and restart the thing manually every time the network is unavailable. A network outage is fixed where it happens, it's not supposed to break thousands of daemons downstream permanently until somebody has read their logfiles and manually restarted them like an idiot. There may not even be a user, if you think of unattended server boxes or, say, home routers running in your mom's basement. Your mom won't read log files. And she certainly doesn't want to power-cycle her internet box every time the network comes up again (or wasn't up when she switched the box on). This thing wants to be a Unix-style daemon that's supposed to support robust automation, not requiring a c00l h4xx0r type holding its hand and reading log files and typing fancy restart commands all the time to do stuff that's blatantly obvious anyway.
You should really step back for a minute and think this over and change your perspective. You were thrown into that Redhat bugzilla because you were angry because someone had made a wrong fix that DDoSed your service, without contacting you first, and apparently that anger has clouded your judgment, or so it seems.
I may be miss-understanding something, but if a service crashes, SystemD is responsible to restart the service. In this case the service may just crash again, but that's besides the point. Why wasn't SystemD bringing a crashed service back online?
It did, after the submitter wrote Restart=always/RestartSec=10 into the service definition file. But that led to the (understandable) concern on the part of the aiccu author that when this patch was rolled out to all Fedora installations, you might have thousands of Fedora boxes out there with e.g. a wrong tunnel password in the aiccu configuration, and all those machines would then be continuously hammering the SixXs tunnel broker with rejected connection attempts. Stuff like that is one of the reasons why auto-restarting services are frowned upon. AFAIK systemd allows you to specify that a service be restarted only if it exited with one out of a specific set of exit codes and/or signals, but again, aiccu doesn't define specific exit code for specific error conditions, afaik (and I don't know whether systemd itself can perform exponential backoff for certain exit codes).
Another question is why wasn't the service registered with the event for when the network came back up? Then it could crash and stay down until the network was functioning again, instead of attempting to restart every 10 seconds.
Not all network outages are local. An upstream router or the SixXs service itself may be go down randomly. So you still have to have some strategy in the service daemon and/or the service definition to deal with the tunnel broker being unreachable.
There was a problem involving systemd, networking, and aiccu.
The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu
No they didn't demonstrate that. The relevant thread is this one, and the short version is that the aiccu author failed to understand that the network being unavailable temporarily is quite a different failure mode than, say, the configuration file having a syntax error. In the latter case, it's OK to terminate and require user intervention, whereas in the former case, if you're a long-running daemon that's supposed to keep a tunnel open, you keep running, backing off exponentially and waiting until the network becomes available again. Or at the very least, you exit with a specific exit code so that somebody can write a wrapper script that handles this particular error correctly and implements the backing-off thing in the wrapper script, and still terminates permanently for any other error condition (at which point it's fair to ask again why you wouldn't implement the exponential backoff in the daemon itself).
This whole thing is quite independent of the init system; sysvinit will expose just the same set of issues. What's broken is the daemon, not the init system.
Slashdot Mirror
Here's a link for you.
Wonder how they arrived at a 0.893381 (impressive number of digits btw) probability of a 119 year old male dying within one year, considering that not a single man in history is confirmed to have reached that age.
Gowdy's comments just cater to IT novices who might think that there must be a bad cheap way and a good expensive way to wipe bits from a hard drive, when in fact there's just one way, and it's not particularly clever or complicated. People have written free programs to do it, so everybody uses them. It's just like thinking that anybody who uses a Teraflop/s machine must be using it to design nuclear bombs, until you realise that TFLOPs machines cost 100 bucks these days, so everybody uses them for everything, including writing birthday emails to grandma.
He doesn't "sit trapped in the Ecuadorean embassy" any more than a prissy teenage girl who is mad at her parents and doesn't wanna come down for dinner sits trapped in her room. He can just walk out of there whenever he pleases. The only risk he'd face would be major embarrassment after NOT being deported to the US.
I'm fine with Wayland... As long as it still runs all my wonderful diverse choices of Unix desktop environments.
Which are used to run a browser and 26 terminals. So no problem there. As long as we have a good browser, lack of Xorg compatibility will become less and less of a issue.
On linux, piping commands in bash are extremely limited. mostly because the command you pipe from cannot customize what data it is going to output to the command you pipe to.
Why exactly should it be able to customize output based on the pipe target? It sounds like something that makes commands work only with some specific other commands, seriously limiting reusability.
Yeah, almost everything that's genuinely useful limits reusability somewhat. By your logic, OOP "limits reusability" compared to raw assembly language, which allows you to do more things, including implementing your own OOP language in it. In reality, OOP tries to hit a sweet spot by constraining reusability somewhat and gaining functionality and ease of reusability for it. I've never used PS, but I understand that using object streams instead of text line streams will provide advantages. If the processes on both ends of the pipe declare what kind of objects the support, the shell can provide enhanced functionality if the processes support it, and fall back to text or to a generic meta object protocol otherwise.
Have you ever tried to grep from an mbox file all mails sent last month by a specific sender? That's gonna be next to impossible because grep doesn't know anything about mails, and because grep is line-oriented, but an mbox file doesn't contain one mail per line. OTOH if you can turn the mbox file into a stream of "Mail" objects, which it really is, the job is probably trivial even with any kind of "object grep" that just works via reflection and doesn't know anything about Mail objects specifically.
So throw in some perl.
Perl isn't very unixish though. It throws everything into one process. Arguably, PS is more unixish except that it has objects where Bash uses (lines of) text.
Just remember that even clean energy ends up as waste heat that must be radiated out into space. Any excess and independent of AGW, the earth starts to heat.
If energy per person continues to grow at the same rate it has since the 1600s, in less than 500 years the earth is over 212 degrees. Energy per person is another limit to growth. And the more people we have, the lower that limit. If we have 20 billion instead of 5 billion, the ultimate cap on energy per person is going to be 1/4th as much.
Yeah, we're a few orders of magnitude away from that. It's T~P^(1/4), T=300K, and the solar power input is currently about 10,000 times the entire human energy production. So a tenfold increase of our power production would lead to about 0.06 Kelvins of temperature rise from direct energy to heat conversion. Or to put it another way, the current AGW temperature increase (~1K) corresponds to the heat equivalent of about 140 times our current energy production. So yes, we won't be able to achieve the same relative growth in energy production over the coming 500 years as we did in the past 500 years, at least as long as we stay on this planet and don't venture into outer space. But that's not really all that relevant for solving the energy and resource consumption problems at hand.
Recycling is well under 100% efficient. It's a good thing but we lose a significant amount of usable material each pass thru the recycling part of the system.
The book "Limits to Growth" includes recycling in it's models.
Conservation and less consumption per person are our best bet but it really only changes to day we hit the limits not the fact that we will hit the limits. We can't sustain our current population level much less the potential for 12 billion by 2100 now projected by the UN.
We now use more of many nonrenewable resources each year than we did during all of last century.
Well, it largely depends (ultimately) on the energy you put into the recycling process. Energy is the only true "nonrenewable resource", due to the 2nd law of thermodynamics. But there's enough of it. What we really have to do is develop technologies and policies to produce large amounts of clean energy. If we don't do that, then even half the current global population number will be unsustainable in the long term, especially if more countries strive to attain western standards of living. If we do do it, then 12 billion or even 20 billion people can be managed. Since forbidding people to consume and prosper didn't even work under communism, it certainly won't in liberal democracies, so our options are quite clear AFAICS.
How about almost every climatology study done in the last forty years?
I tell you what. If you don't think AGW is real, why don't you explain where all the energy being absorbed by CO2 in the atmosphere is going. Are you advocating the "magic heat sink back into space" theory?
I think AGW is real, but I fail to see how you get from that to August 8 as a single date of an "overshoot day". Does this imply that, since on August 8 we're about 60% through the year, we'd have to reduce our CO2 output by 40% to completely stop the increase of atmospheric CO2 levels? That doesn't make any sense at all, given that the worldwide CO2 emissions were 40% lower than today roughly 30 years ago, but by that time the CO2 levels had been increasing for more than a century already. So that doesn't make sense at all unless you postulate that the natural CO2 sinks work at a much higher pace at today's CO2 levels compared to those in 1986.
So what does August 8 represent? Are they computing one overshoot day per type of resource (Hydrocarbons, aluminium, copper, ...) and take the average? Or the minimum? And what's a "copper overshoot day" anyways, given that we don't "use up" metals the way we do oil or gas when we burn it. If you count metal as "used up" if it's not recycled but replaced with new raw materials, then the corresponding "overshoot day" would be January 1st because the Earth's crust contains a fixed amount of extractable ores.
Well, he was one of three muslim science nobel prize winners in history (the other two being Abdus Salam and Aziz Sancar). And there are 1.5 billion muslims. By contrast, jewish scientists have won over 100 nobel prizes, and there are only 15 million jews. I guess this means that a muslim is about 5,000 times less likely to become a renowned scientist than a jew is. So while muslim scientists aren't oxymorons, they're an exceedingly rare occurrence.
> The Group’s gross profit increased 20% to € 2.304 billion (2014: € 1.918 billion) in the third quarter.
http://www.adidas-group.com/en...
I would love to know why Adidas can't afford to pay decent wages?
Maybe they're using more robots precisely because they want to pay their (remaining) human employees decent wages. :D
It seems like a really weird bomb - if we assume middle eastern terrorists. They would be in Paris with a bomb, but choose to go through all the airport security and the risks associated with it just to blow up a plane filled with mostly Egyptians in Egyptian airspace?
Yeah, why not? First, bringing down an airliner means a lot more publicity than just exploding a bomb in a restaurant somewhere. Second, a bomb that kills at most one or two people in a restaurant kills 100+ people when exploded in an airplane because most or all victims won't die from the blast but from, you know, flying in an airplane that's crashing.
Yeah but if you're going to blow up a plane wouldn't you want to do it over land, preferably over a city or something (like the one it just left) where lots of people are likely to see, rather than over some bit of ocean miles and miles away from anything.
Yeah, if you have any control over where exactly the bomb goes off. You seem to be assuming that the terrorist was onboard the plane, on a suicide mission. Which seems pretty unlikely to me.
It seems like a really weird bomb - if we assume middle eastern terrorists. They would be in Paris with a bomb, but choose to go through all the airport security and the risks associated with it just to blow up a plane filled with mostly Egyptians in Egyptian airspace?
Yeah, why not? First, bringing down an airliner means a lot more publicity than just exploding a bomb in a restaurant somewhere. Second, a bomb that kills at most one or two people in a restaurant kills 100+ people when exploded in an airplane because most or all victims won't die from the blast but from, you know, flying in an airplane that's crashing.
So they're not upgrading but replacing Hangouts with not one but two new apps. I'm sure there's a brilliant strategic move hidden in there somewhere that I just fail to see.
The right to privacy doesn't end at death.
Then why does Apple grant you access to a deceased relative's iCloud account when shown the death certificate?
It also doesn't matter who legally owns the phone, since Apple is UNABLE to unlock it.
Well, no. Since the kid probably didn't use a 20-digit PIN, Apple could write special software to brute force it.
They should train other robots to do all the kicking and pushing and abusing. So they get mad at each other and don't turn against us.
And since it's not the 1990's anymore anything worth calling it encrypted is storing keys in specialized hardware, so it's not just a question of getting a debugger out and pawing through memory.
Well, in block device / disk encryption on PCs, they keys are stored on the regular device, but they're stored encrypted with another key, namely the passphrase, which is only stored in the user's brain (hopefully). So unless the device is already running and somebody has already entered the correct passphrase, you can paw through anything you want (except the user's brain) and it won't help.
Still, there are obstacles. SpaceX still needs to demonstrate the ability to consistently produce and launch rockets many times a year after the June accident caused an unexpected, six-month setback, something it will do with several flights planned for the weeks ahead.
Just because it's relatively cheap to use Space X, if I have a 50-50 ( better or worse) chance that my $100 million satellite that took several years to design and build is going to get blown up, I'll pass.
So I'm guessing (and I'm more or less an interested layman here) it would depend o the cost of the payload. Even if reusable rockets turn out to be less reliable, they'd still open up new possibilities IF they're substantially cheaper. If cheaper launches become available, that opens the market up for new, less expensive types of payloads that nobody would've thought of before. If your payload costs two million dollars to build (and to build again if you lose one), you'd probably launch it with the one-million-dollars-per-launch vehicle that's three times more likely to explode. If your payload costs one BILLION dollars, you probably[*] launch with the 60 million per launch vehicle that's three times less likely to explode, because the launch costs are just 6% of your payload anyway. But the thing is, that 2 million dollar payload would not be launched AT ALL if the cheap launcher wasn't available (at least not if the payload is heavy enough so it can't be launched with 10 others on the same flight).
[*] Even that's not an automatic no-brainer decision if you're thinking of buying one hundred one-billion dollar payload launches and want to have as many dollars in orbit per million dollars expended as possible -- in that case you might launch even the expensive payloads with the cheaper launcher.
Why measure weight? All that's needed to know whether the plane will lift off is the current amount of thrust, the current speed and its acceleration.
The plane lifts off when its lift exceeds its weight. Its *weight*, see? The airspeed (and flaps setting) determines the lift; to determine the weight, you have to, well, weigh the thing.
And that is the whole fun point of it all: AICCU (or anything else) cannot fix network problems
It's not supposed to fix them, it's supposed to retry until they've been fixed externally. And no, you don't expect a user to "read log messages" and restart the thing manually every time the network is unavailable. A network outage is fixed where it happens, it's not supposed to break thousands of daemons downstream permanently until somebody has read their logfiles and manually restarted them like an idiot. There may not even be a user, if you think of unattended server boxes or, say, home routers running in your mom's basement. Your mom won't read log files. And she certainly doesn't want to power-cycle her internet box every time the network comes up again (or wasn't up when she switched the box on). This thing wants to be a Unix-style daemon that's supposed to support robust automation, not requiring a c00l h4xx0r type holding its hand and reading log files and typing fancy restart commands all the time to do stuff that's blatantly obvious anyway.
You should really step back for a minute and think this over and change your perspective. You were thrown into that Redhat bugzilla because you were angry because someone had made a wrong fix that DDoSed your service, without contacting you first, and apparently that anger has clouded your judgment, or so it seems.
How is it that sysvinit (and other init systems that operate via rote scripting) is able to handle aiccu flawlessly
It is not. As explained, the flaw is in aiccu itself. The init system cannot (and, consequently, does not) fix it.
aiccu then crashes and it never starts again.
I may be miss-understanding something, but if a service crashes, SystemD is responsible to restart the service. In this case the service may just crash again, but that's besides the point. Why wasn't SystemD bringing a crashed service back online?
It did, after the submitter wrote Restart=always/RestartSec=10 into the service definition file. But that led to the (understandable) concern on the part of the aiccu author that when this patch was rolled out to all Fedora installations, you might have thousands of Fedora boxes out there with e.g. a wrong tunnel password in the aiccu configuration, and all those machines would then be continuously hammering the SixXs tunnel broker with rejected connection attempts. Stuff like that is one of the reasons why auto-restarting services are frowned upon. AFAIK systemd allows you to specify that a service be restarted only if it exited with one out of a specific set of exit codes and/or signals, but again, aiccu doesn't define specific exit code for specific error conditions, afaik (and I don't know whether systemd itself can perform exponential backoff for certain exit codes).
Another question is why wasn't the service registered with the event for when the network came back up? Then it could crash and stay down until the network was functioning again, instead of attempting to restart every 10 seconds.
Not all network outages are local. An upstream router or the SixXs service itself may be go down randomly. So you still have to have some strategy in the service daemon and/or the service definition to deal with the tunnel broker being unreachable.
There was a problem involving systemd, networking, and aiccu.
The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu
No they didn't demonstrate that. The relevant thread is this one, and the short version is that the aiccu author failed to understand that the network being unavailable temporarily is quite a different failure mode than, say, the configuration file having a syntax error. In the latter case, it's OK to terminate and require user intervention, whereas in the former case, if you're a long-running daemon that's supposed to keep a tunnel open, you keep running, backing off exponentially and waiting until the network becomes available again. Or at the very least, you exit with a specific exit code so that somebody can write a wrapper script that handles this particular error correctly and implements the backing-off thing in the wrapper script, and still terminates permanently for any other error condition (at which point it's fair to ask again why you wouldn't implement the exponential backoff in the daemon itself).
This whole thing is quite independent of the init system; sysvinit will expose just the same set of issues. What's broken is the daemon, not the init system.
The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes
So some day it'll be dark at noon, but our buggy software will still function.