Don't be stupid. I didn't say big cities are bad (I live in one myself), all I said is that it's bullshit to compare one country with its most violent places taken out with another country with all of its most violent places taken in. Get over it.
So Amazon is jeopardising their own reputation as the one-stop online shop where you can buy any popular goods and items in existence -- just because they want to sell more of their own video streaming gadget? They must be terrified of their competitors.
Well, if you were one of the sailors on the first circumnavigation of the world (Magellan, 1519-22), the probability that you wouldn't come home alive was about 92%, breathable air or not. That's certainly higher than any conceivable Mars trip today would incur (unless you count in the proposed one-way mission profiles). In fact, I'm pretty sure if you make a serious and educated estimate of how likely it would be to die on such a trip and put that in a historical context, you wouldn't have had that good a chance of surviving an intercontinental sea voyage until the mid or late 18th century or so. By that time however, thousands upon thousands of people routinely made such trips, and contrary to space travellers today, not all of them did it voluntarily, and most of the others were low-paid sailors who were forced by serious economic pressure and would've had no income if they refused to participate.
I got no idea where all that came from, except possibly as an Australian Government misinformation campaign because they were having to reject too many American applicants and the Americans were getting nasty about it but http://www.bobinoz.com/migrati.... I mean seriously grizzly bear versus koala bear which would you rather meet out in a forest or mountain line versus Tasmanian devil, sure the devil sounds worse, much worse but not really a problem.
Yeah, but then whenever I'd discover one of these in my room I'd have to burn the house down and be homeless afterwards, which is not so convenient in a place with so many free-running monsters.
Technological progress trumps all redistribution schemes when it comes to standard of living, because the former is exponential growth, while the latter is a constant.
Who's to say you won't have technological progress once you have basic income? The question would rather be, who gets to participate and reap the benefits of that progress when there are no jobs for more and more people. And this is a real possibility, contrary to what many free-market enthusiasts think. There's almost no job that absolutely couldn't be automated. Even the job of doing the automation, and even creative jobs, might be automated some day. And you can always reduce the argument to the extreme: What happens if/when we achieve technological singularity? By then at the very latest, the concept of having to work in order to live seems absurd.
And technological progress isn't exponential, btw. The changes in the technology world from 1960 to today have been less pronounced than those between 1905 and 1960. The biggest "recent" change was probably the internet, but all in all our world isn't so much different from the one in the 1960s, whereas at the beginning of the 20th century there were no airplanes (let alone air travel for everyone), no TVs, no washers, no penicillin, no computers, almost no telephones, and not even any electricity in households.
Brian Booker writes at Digital Journal that carbon dating suggests the Koran, or at least portions of it, may actually be older than the prophet Muhammad himself, a finding that if confirmed could rewrite early Islamic history and shed doubt on the "heavenly" origins of the holy text.
Umm, I actually have doubts about the "heavenly" origins of anything. Did someone actually write the above in a scientific paper? What test result would have confirmed the "heavenly" origins of that book? Those researchers seem to assume that the C-14 dating period should have started the moment that Koran was "handed" to Mohammed. That would imply that this heaven/god thing makes books out of carbon fetched from living things or the upper atmosphere, at the moment it hands them down to us. That would be kind of pedestrian, wouldn't it? Shouldn't He have instant access to all the carbon resources of the universe? Like, if He made the Koran out of carbon fetched from the Martian atmosphere or from some stellar core, there would be no C-14 in that, so C-14 dating would give "infinite"/undefined results.
If you DON'T want to do all this yourself, there are companies who will do it for you and provide commercial support. Ubuntu is one of those companies.
Um, actually the company is named Canonical, but whatever...
Debian does releases. They also provide a rolling release, but that isn't the only option.
testing and unstable are rolling releases. stable is a fixed release, but it's too old for most people to use. So if you want to have a halfway recent Debian with fixed packet versions, you have to roll your own or use one of the ones that other people (like Ubuntu) already provide.
They also provide security updates for their releases, so normally "patching in" security updates is done using apt-get.
I know, but if you're running your own fixed-release Debian, you'd have to build those packages yourself.
It's almost as bloated with junk as the desktop version. I've been telling our developers to use debian over ubuntu. A base minimal container with Debian is under a 100 megs. With Ubuntu it's close to 700 megs.
Debian is a rolling release distribution, with no direct commercial support. You can't use it to achieve repeatable rollouts and provisioning unless you set up and support your own Debian mirror with all package versions freezed at some known-good, conflict-free state, and patch in security updates as necessary, while still ensuring and testing that the whole system still works. If you DON'T want to do all this yourself, there are companies who will do it for you and provide commercial support. Ubuntu is one of those companies.
Any API reimplementation is built for the purpose of interoperability.
No. To take the present example, Google's Java API is clearly not interoperable with the original Java code.
Yes it is. You can compile and run source code that uses the common subset of Google's and Sun's APIs for both Google's and Sun's VM. That's not accidental, it's intentional, because the thing was built for the purpose of interoperability.
The article really has nothing to do with nuclear power plants, despite the opening references.
He is talking about the poor security at the Oak Ridge facility.
If private security guards are so bad, maybe they should call in the experts from Homeland Security.
The opening references talk about "nuclear accidents", not specifically power plants.
And if, after reading the article, you conclude that private security guards may be bad, then I don't understand why you'd still criticise or deride the article or its author -- after all, it seems you've learned something new from it.
I would've "bothered", but the talk isn't available online, apparently. So by your logic, nobody should comment anything here. Or/. shouldn't link to articles that are essentially just teasers.
I know nothing about IKEA's Linux setup and didn't see the talk, but "one-line Linux command" sounds like the wrong approach to something like this, at least if that command directly manipulates something on each server. Shell commands that an administrator issues interactively on a terminal can't be reproduced, tracked, or documented automatically. The right thing to do would probably be to change some "bash_version" parameter in the puppet hiera/chef/whatever configuration management system they use, from where the change will automatically be applied on all nodes, or use an internal rpm/yum server that all nodes install from automatically (governed, again, by the configuration management system) and upload the patched bash rpm to that.
As it seems even tech giant google gets it wrong with its own certs. Lets hope that Let's Encrypt will make these problems of yesterday one day.
Well, the web mailer wasn't affected because the site uses different certificates, and neither were Google's other gmail clients, e.g. the Gmail app on Android, because those all use the Gmail API (again, with different certificates) rather than SMTP. So if you're paranoid enough, you may suspect malice rather than sloppiness.:-P
The certificate was used to issue Gmail's certificate for SMTP, and the expiration at 11:55am EDT caused many e-mail clients to stop receiving Gmail messages
If the certificate was "for SMTP", the problem would have affected not just end users, but also peers, i.e. other e-mail providers who wanted to deliver mail to @gmail.com addresses. Or at least they may have automatically fallen back to unencrypted SMTP delivery (which was pretty much the default before Snowden, but anyway).
Oh come on. The hex revision numbers are there because the programmer was too stupid or too lazy to figure out something people could actually use. Typical programmer attitude---code for other nerds, not normal people.
No. git is a distributed version control system, which means that, among other things, operations like "commit" and "merge" that create new commits must operate purely locally, without synchronizing with any remote copy of the repository, and then, much later, when the user decides to push those commits to a remote copy, and other users push their new commits to the same remote copy, the remote copy must be able to tell which of the incoming commits it already had locally, which ones are actually new to it, and whether or not multiple incoming commits from different source repositories represent the same commit (for example because those two source repositories pushed to each other before) and thus must be collapsed into one new local commit, and which ones are different commits and this must be imported as separate local commits. The fundamental problem that the DVCS has to solve here is merging/synchronizing multiple directed acyclic graphs coming from different remote sources, all of which can independently add new nodes to their local version of the graph at any time without communicating with any of the other copies or any other sort of "central repository".
This means that you have to have some sort of globally unique identifier for the nodes of the graph, and those identifiers must be creatable locally, using only information that's available in the local copy of the graph, and then still be unique across all copies of the graph that might exist elsewhere. That's what the SHA1 checksums achieve. They also have the nice feature that they're not random numbers, but actual checksums over the entire contents of the graph up to and including that node. But the fundamental issue is that you can't have human-readable commit identifiers like "1.2" or "1.4.1" because there is no central authority that could generate those names and guarantee that they're unique across all copies. Mercurial uses the same solution (they have a linearly increasing "commit number" on top of that, but those numbers are only valid locally, i.e. they might be different in each copy of the graph).
I can believe this. But what if, instead of falling against the switch, the copilot, recognizing that he was about to pass out (e.g. recognizing symptoms of an impending stroke), intentionally attempted to move the switch to the "unlocked" postion (to make it easier for the captain to get into the cockpit quickly)? Due to a combination of confusion, physical incapacitation, and infamiliarity with a probably rarely-used control, he could conceivably have turned the switch to the wrong position even while he was attempting to do what he thought would be the best possible action.
The switch is designed such that the middle ("norm") position is the only one that's stable and will be retained without the user pushing the switch. I.e. the switch will always move back to "normal" when not actively pushed to either "lock" or "unlock". And with the switch in stable position, the door can always be unlocked from the outside -- with a short delay that gives the person inside the cockpit time to actively suppress the unlock using the switch. If the person in the cockpit does nothing, the door unlocks. So without deliberate and repeated activity from the person inside the cockpit, there is no scenario that would indefinitely prevent people outside the cockpit from entering.
Slashdot Mirror
Don't be stupid. I didn't say big cities are bad (I live in one myself), all I said is that it's bullshit to compare one country with its most violent places taken out with another country with all of its most violent places taken in. Get over it.
So Amazon is jeopardising their own reputation as the one-stop online shop where you can buy any popular goods and items in existence -- just because they want to sell more of their own video streaming gadget? They must be terrified of their competitors.
Right, in the world. Amongst developed nations, it's certainly number 1 in that sense, by miles and miles.
Only if you count Detroit, Baltimore, Chicago, and New York as part of any "developed nation".
Take the gun violence from those locations out of US statistics, and where would the US be?
Probably in the same position as before if you take the two or three biggest/most violent cities of those other countries out as well.
Well, if you were one of the sailors on the first circumnavigation of the world (Magellan, 1519-22), the probability that you wouldn't come home alive was about 92%, breathable air or not. That's certainly higher than any conceivable Mars trip today would incur (unless you count in the proposed one-way mission profiles). In fact, I'm pretty sure if you make a serious and educated estimate of how likely it would be to die on such a trip and put that in a historical context, you wouldn't have had that good a chance of surviving an intercontinental sea voyage until the mid or late 18th century or so. By that time however, thousands upon thousands of people routinely made such trips, and contrary to space travellers today, not all of them did it voluntarily, and most of the others were low-paid sailors who were forced by serious economic pressure and would've had no income if they refused to participate.
I got no idea where all that came from, except possibly as an Australian Government misinformation campaign because they were having to reject too many American applicants and the Americans were getting nasty about it but http://www.bobinoz.com/migrati.... I mean seriously grizzly bear versus koala bear which would you rather meet out in a forest or mountain line versus Tasmanian devil, sure the devil sounds worse, much worse but not really a problem.
Yeah, but then whenever I'd discover one of these in my room I'd have to burn the house down and be homeless afterwards, which is not so convenient in a place with so many free-running monsters.
Technological progress trumps all redistribution schemes when it comes to standard of living, because the former is exponential growth, while the latter is a constant.
Who's to say you won't have technological progress once you have basic income? The question would rather be, who gets to participate and reap the benefits of that progress when there are no jobs for more and more people. And this is a real possibility, contrary to what many free-market enthusiasts think. There's almost no job that absolutely couldn't be automated. Even the job of doing the automation, and even creative jobs, might be automated some day. And you can always reduce the argument to the extreme: What happens if/when we achieve technological singularity? By then at the very latest, the concept of having to work in order to live seems absurd.
And technological progress isn't exponential, btw. The changes in the technology world from 1960 to today have been less pronounced than those between 1905 and 1960. The biggest "recent" change was probably the internet, but all in all our world isn't so much different from the one in the 1960s, whereas at the beginning of the 20th century there were no airplanes (let alone air travel for everyone), no TVs, no washers, no penicillin, no computers, almost no telephones, and not even any electricity in households.
I could work at Burger King or some other McJob that has a LOT less stress than designing ASICs
So when given the choice (and equal pay), you'd rather work at Burger King than design ASICs?
Brian Booker writes at Digital Journal that carbon dating suggests the Koran, or at least portions of it, may actually be older than the prophet Muhammad himself, a finding that if confirmed could rewrite early Islamic history and shed doubt on the "heavenly" origins of the holy text.
Umm, I actually have doubts about the "heavenly" origins of anything. Did someone actually write the above in a scientific paper? What test result would have confirmed the "heavenly" origins of that book? Those researchers seem to assume that the C-14 dating period should have started the moment that Koran was "handed" to Mohammed. That would imply that this heaven/god thing makes books out of carbon fetched from living things or the upper atmosphere, at the moment it hands them down to us. That would be kind of pedestrian, wouldn't it? Shouldn't He have instant access to all the carbon resources of the universe? Like, if He made the Koran out of carbon fetched from the Martian atmosphere or from some stellar core, there would be no C-14 in that, so C-14 dating would give "infinite"/undefined results.
If you DON'T want to do all this yourself, there are companies who will do it for you and provide commercial support. Ubuntu is one of those companies.
Um, actually the company is named Canonical, but whatever...
Debian does releases. They also provide a rolling release, but that isn't the only option.
testing and unstable are rolling releases. stable is a fixed release, but it's too old for most people to use. So if you want to have a halfway recent Debian with fixed packet versions, you have to roll your own or use one of the ones that other people (like Ubuntu) already provide.
They also provide security updates for their releases, so normally "patching in" security updates is done using apt-get.
I know, but if you're running your own fixed-release Debian, you'd have to build those packages yourself.
It's almost as bloated with junk as the desktop version. I've been telling our developers to use debian over ubuntu. A base minimal container with Debian is under a 100 megs. With Ubuntu it's close to 700 megs.
Debian is a rolling release distribution, with no direct commercial support. You can't use it to achieve repeatable rollouts and provisioning unless you set up and support your own Debian mirror with all package versions freezed at some known-good, conflict-free state, and patch in security updates as necessary, while still ensuring and testing that the whole system still works. If you DON'T want to do all this yourself, there are companies who will do it for you and provide commercial support. Ubuntu is one of those companies.
Any API reimplementation is built for the purpose of interoperability.
No. To take the present example, Google's Java API is clearly not interoperable with the original Java code.
Yes it is. You can compile and run source code that uses the common subset of Google's and Sun's APIs for both Google's and Sun's VM. That's not accidental, it's intentional, because the thing was built for the purpose of interoperability.
WINE has a clear fair use defense, because it is built for the purpose of interoperability. Interoperability is well established as fair use.
Any API reimplementation is built for the purpose of interoperability. So by your logic, they should all have a fair use defense anyway.
"The research shows the way lies are really uncovered is by comparing what someone is saying to the evidence,"
Looks like those mad scientists make new groundbreaking discoveries every day now.
A better title would be "Volkswagen Factory Worker Killed By Industrial Machinery."
The "industrial machinery" in this case was a robot. And they're really called robots. So why not be specific?
The article really has nothing to do with nuclear power plants, despite the opening references. He is talking about the poor security at the Oak Ridge facility. If private security guards are so bad, maybe they should call in the experts from Homeland Security.
The opening references talk about "nuclear accidents", not specifically power plants.
And if, after reading the article, you conclude that private security guards may be bad, then I don't understand why you'd still criticise or deride the article or its author -- after all, it seems you've learned something new from it.
I would've "bothered", but the talk isn't available online, apparently. So by your logic, nobody should comment anything here. Or /. shouldn't link to articles that are essentially just teasers.
I know nothing about IKEA's Linux setup and didn't see the talk, but "one-line Linux command" sounds like the wrong approach to something like this, at least if that command directly manipulates something on each server. Shell commands that an administrator issues interactively on a terminal can't be reproduced, tracked, or documented automatically. The right thing to do would probably be to change some "bash_version" parameter in the puppet hiera/chef/whatever configuration management system they use, from where the change will automatically be applied on all nodes, or use an internal rpm/yum server that all nodes install from automatically (governed, again, by the configuration management system) and upload the patched bash rpm to that.
Didn't George Washington personally own 300 slaves or something? Maybe the US should rename their capital city first :-D
Whether it's the predominance of Visual Studio in many computer science programs
I must have missed that.
PS: http://www.jwz.org/doc/backups...
As it seems even tech giant google gets it wrong with its own certs. Lets hope that Let's Encrypt will make these problems of yesterday one day.
Well, the web mailer wasn't affected because the site uses different certificates, and neither were Google's other gmail clients, e.g. the Gmail app on Android, because those all use the Gmail API (again, with different certificates) rather than SMTP. So if you're paranoid enough, you may suspect malice rather than sloppiness. :-P
The certificate was used to issue Gmail's certificate for SMTP, and the expiration at 11:55am EDT caused many e-mail clients to stop receiving Gmail messages
If the certificate was "for SMTP", the problem would have affected not just end users, but also peers, i.e. other e-mail providers who wanted to deliver mail to @gmail.com addresses. Or at least they may have automatically fallen back to unencrypted SMTP delivery (which was pretty much the default before Snowden, but anyway).
Oh come on. The hex revision numbers are there because the programmer was too stupid or too lazy to figure out something people could actually use. Typical programmer attitude---code for other nerds, not normal people.
No. git is a distributed version control system, which means that, among other things, operations like "commit" and "merge" that create new commits must operate purely locally, without synchronizing with any remote copy of the repository, and then, much later, when the user decides to push those commits to a remote copy, and other users push their new commits to the same remote copy, the remote copy must be able to tell which of the incoming commits it already had locally, which ones are actually new to it, and whether or not multiple incoming commits from different source repositories represent the same commit (for example because those two source repositories pushed to each other before) and thus must be collapsed into one new local commit, and which ones are different commits and this must be imported as separate local commits. The fundamental problem that the DVCS has to solve here is merging/synchronizing multiple directed acyclic graphs coming from different remote sources, all of which can independently add new nodes to their local version of the graph at any time without communicating with any of the other copies or any other sort of "central repository".
This means that you have to have some sort of globally unique identifier for the nodes of the graph, and those identifiers must be creatable locally, using only information that's available in the local copy of the graph, and then still be unique across all copies of the graph that might exist elsewhere. That's what the SHA1 checksums achieve. They also have the nice feature that they're not random numbers, but actual checksums over the entire contents of the graph up to and including that node. But the fundamental issue is that you can't have human-readable commit identifiers like "1.2" or "1.4.1" because there is no central authority that could generate those names and guarantee that they're unique across all copies. Mercurial uses the same solution (they have a linearly increasing "commit number" on top of that, but those numbers are only valid locally, i.e. they might be different in each copy of the graph).
I can believe this. But what if, instead of falling against the switch, the copilot, recognizing that he was about to pass out (e.g. recognizing symptoms of an impending stroke), intentionally attempted to move the switch to the "unlocked" postion (to make it easier for the captain to get into the cockpit quickly)? Due to a combination of confusion, physical incapacitation, and infamiliarity with a probably rarely-used control, he could conceivably have turned the switch to the wrong position even while he was attempting to do what he thought would be the best possible action.
The switch is designed such that the middle ("norm") position is the only one that's stable and will be retained without the user pushing the switch. I.e. the switch will always move back to "normal" when not actively pushed to either "lock" or "unlock". And with the switch in stable position, the door can always be unlocked from the outside -- with a short delay that gives the person inside the cockpit time to actively suppress the unlock using the switch. If the person in the cockpit does nothing, the door unlocks. So without deliberate and repeated activity from the person inside the cockpit, there is no scenario that would indefinitely prevent people outside the cockpit from entering.