Reprocess the 'spent' fuel and the stoarge is down to 200-500 years.
Of course, for most of that 200,000 years the waste is no more radioactive than it was in the ground before it was mined and concentrated into U235 fuel.
The insanely long storage figure was invented to scare people.
That used to be expected in the U.S. as well. Take it back to the store, show that it doesn't work and a receipt to show when you bought it. Leave with a new one.
Really, it makes sense. The store is the one that has a business relationship with the manufacturer. You bought the item from the store.
If the brick and mortar stores in the U.S. hadn't stopped doing that, they might stand a chance against online retailers.
R&D isn't that expensive when the cost is spread over the huge number of sales. Unlike many other operations, Apple can pretty much count on even a clunker selling enough to pay back the R&D costs at $1 per unit.
It's almost as if the antis just wanted to force others to bow to their will and now they're ticked off that there is a solution that invalidates their best "objective" arguments. Thus they must stomp it out so they can go back to demanding that others bow to their will.
If they were actually objectively concerned about people's health or even the costs to society, they'd be dancing in the streets and arranging to get ecig starter kits to all smokers.
Actually, the degraded option does NOT work for BTRFS or at least hasn't when I've tried it. I still ended up in the shell. I checked the changelog for systemd from present back to the date of that report and there is no mention of it at all. Once in the shell, mount -odegraded / will work just fine. If systemd' wasn't too mind-bogglingly stupid to just try the mount command nobody would have to get out of bed at 3AM just to type that. But if I just rip systemd out and use the supposedly old and broken down sysV init, it works every time. If systemd had a sane configuration, I'd just poke that mount commend in as an explicit action and it would just work, but in all of that tangled spaghetti just below the surface, there appears to be no way to do that.
For md devices, they get around the problem by having a regular old script in the initrd go ahead and assemble the RAID before systemd gets a chance to get the vapors and refuse.
Mainframes certainly DO cost 100x more than (for example), a supermicro server.
Sure, networks do go down, but in those cases, you're either dual homed or no amount of non-stop can help you. Again, take the 90% solution or be prepared to start paying a lot more. I did say it should be in a good datecenter with backup power. If that fails, again, no amount of non-stop can help you.
I would say it's a 90% solution if you have RAID and dual power supplies on separate circuits (this is common in x86 servers these days). Add in dual network connections and you're certainly on the threshold of diminishing returns.
It at the very least reduces the chances of a 3A.M. server down emergency to a very small figure if it's in a decent datacenter with proper electrical backup. I have seen a fair number of power supply failures and a LOT of HD failures, but few machines go down for other failures.
Sure, for only 100x more money you could get a non-stop like solution but few applications justify that outlay.
I know you desperately want to minimize one of systemd's most embarrassing failures, but it just doesn't ring true. I have servers with dual power supplies and RAID (I'm testing brtfs w/ raid1) and I want them to boot in degraded mode if that's what it takes. Systemd is absolutely contraindicated for that application.
First, Linux isn't restricted to x86 hardware (you knew that right?). Second, HA isn't all or nothing. Very few (very expensive) machines go all in on HA. By far, the most common case is RAID (which is implemented on x86 hardware all the time).
Honestly, the RAID thing is a brown paper bug for systemd that should never have made it into a distro and should have resulted in a crash program to fix that in days. It should not have resulted in claims of "not a bug".
And let's not forget that systemd destroys high availability by refusing to mount btrfs degraded if one of the drives fails even if it's set up as RAID1. It refuses to even try the mount commend and drops to the shell (eventually). If you issue the mount manually from there, it mounts right up. They apparently don't know what high availability is all about.
If systemd didn't use butt-ugly APIs, it would be a lot easier to mix and match. For exampl, you want to suspend? Call/sbin/suspend which might be an suid binary, or might use a private interface to a daemon running as root (depending on need). That constitutes a nice standard interface. Want to manage a daemon? Run a manager and pass it the path to the daemon it should manage. Again, a standard interface that can be used by any init system to provide more advanced functionality.
It seems that everywhere there is a choice between a goofball tangled mess and a simple and easy to use interface, systemd is all over the former.
It's much faster and easier to cover everything in shit than it is to scrub it all away again.
The projects are out there, it just takes a little while to bootstrap. Meanwhile, I am working with Jessie and fvwm using sysv to avoid systemd to the extent possible. That is, where I haven't just stayed at wheezy for now.
No. If he was a WASP, the treatment would still be crazy and the principal would still be a braying ass. The police treatment would still have been outrageous.
I just wish they would at least confine it to Friday. By letting it seep into thursday, they're causing quite a few dismal Thanksgiving dinners for the family of people who have to work.
Tell that to the families that can't have a decent holiday because of employers anxious to show us how unthankful they are by trampling one of the few national holidays that are observed at all as anything but an excuse to sell mattresses.
Slashdot Mirror
Yes, two centuries to be exact.
Reprocess the 'spent' fuel and the stoarge is down to 200-500 years.
Of course, for most of that 200,000 years the waste is no more radioactive than it was in the ground before it was mined and concentrated into U235 fuel.
The insanely long storage figure was invented to scare people.
Then they need to document the dependency that approach created, not deny it.
That used to be expected in the U.S. as well. Take it back to the store, show that it doesn't work and a receipt to show when you bought it. Leave with a new one.
Really, it makes sense. The store is the one that has a business relationship with the manufacturer. You bought the item from the store.
If the brick and mortar stores in the U.S. hadn't stopped doing that, they might stand a chance against online retailers.
Not to mention the handwaving costs.
R&D isn't that expensive when the cost is spread over the huge number of sales. Unlike many other operations, Apple can pretty much count on even a clunker selling enough to pay back the R&D costs at $1 per unit.
It's almost as if the antis just wanted to force others to bow to their will and now they're ticked off that there is a solution that invalidates their best "objective" arguments. Thus they must stomp it out so they can go back to demanding that others bow to their will.
If they were actually objectively concerned about people's health or even the costs to society, they'd be dancing in the streets and arranging to get ecig starter kits to all smokers.
No, they want the KDE developers to do LESS work by not ripping out still working functionality.
Alternatively, they had an undocumented dependency that they refused to document. That's doubling down on a bug.
You didn't RTFA, did you?
Alternatively, that's MICRO doses of LSD, not MEGA.
Actually, the degraded option does NOT work for BTRFS or at least hasn't when I've tried it. I still ended up in the shell. I checked the changelog for systemd from present back to the date of that report and there is no mention of it at all. Once in the shell, mount -odegraded / will work just fine. If systemd' wasn't too mind-bogglingly stupid to just try the mount command nobody would have to get out of bed at 3AM just to type that. But if I just rip systemd out and use the supposedly old and broken down sysV init, it works every time. If systemd had a sane configuration, I'd just poke that mount commend in as an explicit action and it would just work, but in all of that tangled spaghetti just below the surface, there appears to be no way to do that.
For md devices, they get around the problem by having a regular old script in the initrd go ahead and assemble the RAID before systemd gets a chance to get the vapors and refuse.
Mainframes certainly DO cost 100x more than (for example), a supermicro server.
Sure, networks do go down, but in those cases, you're either dual homed or no amount of non-stop can help you. Again, take the 90% solution or be prepared to start paying a lot more. I did say it should be in a good datecenter with backup power. If that fails, again, no amount of non-stop can help you.
Then look at all the school children taking related stimulants.
Too bad he was deprived of his right to an attorney.
Funny thing, strip the nicotine from the terrible delivery system (and the MAOIs it contains) and nicotine becomes much more benign.
But in general, most of the actual harm from drugs comes from the prohibition itself.
Sorry for the double reply, but what option is needed to convince systemd to mount a btrfs filesystem with a missing disk?
I would say it's a 90% solution if you have RAID and dual power supplies on separate circuits (this is common in x86 servers these days). Add in dual network connections and you're certainly on the threshold of diminishing returns.
It at the very least reduces the chances of a 3A.M. server down emergency to a very small figure if it's in a decent datacenter with proper electrical backup. I have seen a fair number of power supply failures and a LOT of HD failures, but few machines go down for other failures.
Sure, for only 100x more money you could get a non-stop like solution but few applications justify that outlay.
I know you desperately want to minimize one of systemd's most embarrassing failures, but it just doesn't ring true. I have servers with dual power supplies and RAID (I'm testing brtfs w/ raid1) and I want them to boot in degraded mode if that's what it takes. Systemd is absolutely contraindicated for that application.
First, Linux isn't restricted to x86 hardware (you knew that right?). Second, HA isn't all or nothing. Very few (very expensive) machines go all in on HA. By far, the most common case is RAID (which is implemented on x86 hardware all the time).
Honestly, the RAID thing is a brown paper bug for systemd that should never have made it into a distro and should have resulted in a crash program to fix that in days. It should not have resulted in claims of "not a bug".
And let's not forget that systemd destroys high availability by refusing to mount btrfs degraded if one of the drives fails even if it's set up as RAID1. It refuses to even try the mount commend and drops to the shell (eventually). If you issue the mount manually from there, it mounts right up. They apparently don't know what high availability is all about.
As a developer, I find systemd much harder to interact with than the previous "hacks". So I guess it failed there.
I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
If systemd didn't use butt-ugly APIs, it would be a lot easier to mix and match. For exampl, you want to suspend? Call /sbin/suspend which might be an suid binary, or might use a private interface to a daemon running as root (depending on need). That constitutes a nice standard interface. Want to manage a daemon? Run a manager and pass it the path to the daemon it should manage. Again, a standard interface that can be used by any init system to provide more advanced functionality.
It seems that everywhere there is a choice between a goofball tangled mess and a simple and easy to use interface, systemd is all over the former.
It's much faster and easier to cover everything in shit than it is to scrub it all away again.
The projects are out there, it just takes a little while to bootstrap. Meanwhile, I am working with Jessie and fvwm using sysv to avoid systemd to the extent possible. That is, where I haven't just stayed at wheezy for now.
For example, have a look at Devuan.org.
No. If he was a WASP, the treatment would still be crazy and the principal would still be a braying ass. The police treatment would still have been outrageous.
FINALLY, the cow troll is on topic!
I just wish they would at least confine it to Friday. By letting it seep into thursday, they're causing quite a few dismal Thanksgiving dinners for the family of people who have to work.
Tell that to the families that can't have a decent holiday because of employers anxious to show us how unthankful they are by trampling one of the few national holidays that are observed at all as anything but an excuse to sell mattresses.
Quite a few, I'm sure. The optimal level of regulation will be somewhere between none and what the FDA is doing.