Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Antropologist (Score 1) 69 69

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.

Comment: wrong approach? (Score 0, Troll) 150 150

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.

Comment: Re:Lets encrypt (Score 2) 104 104

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

Comment: Just clients? (Score 4, Informative) 104 104

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).

Comment: Re:And yet, no one understands Git. (Score 2) 203 203

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).

Comment: Re:it could have been an accident (Score 4, Informative) 737 737

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.

Comment: Re:Let me guess (Score 1) 166 166

Chrome already has it's own method for doing remote desktop.

It won't be supported because it will be competing directly with something Google already does.

Yeah, it's called HTTP. It even supports client-induced code upload and execution on the display server just like display postscript did (and JavaScript is a nicer programming language than PostScript), oh and it calls its display server the "client" and its client the server. You get used to it.

Comment: Re:Maintainable... (Score 1) 247 247

The study sounds like nonsense (at least as presented in this post).

Refactoring doesn't make code easier to analyze or change.... But it may make code more maintainable.

What is code maintenance, if not analyzing and changing the code??!?!

Refactoring means code gets written anew, so it becomes more maintainable because it was written by the same people who have to do the maintaining. Before the refactoring, you have to maintain crappy code written by some dude that quit last year. After the refactoring, you have to maintain crappy code written by yourself. Definitely easier.

Comment: Not much. maybe (Score 1) 203 203

We might see not much at all because Betelgeuse happens to be located almost exactly in the ecliptic plane (10 degrees or so below it), so at certain times of the year you can't see it because it's just 10 degrees away from the sun. It would really suck if the supernova occurred during those months. I think even Hubble can't observe that close to the sun, so you'd need a telescope in deep space, which we don't really have atm.

Comment: trial and error (Score 1) 248 248

It seems SpaceX is relying on a trial-and-error strategy during the development of the soft landing capability of their booster much more than they (or others in the industry) do for other components or capabilities of space launch or other aeronautical systems. I don't see (unmanned) rockets or drones being developed in this fashion. Even large rockets that can achieve orbit will normally be modeled, simulated and tested component-wise to the point that they will usually work at the first or second attempt when the entire system is integrated and tested for the first time. So why is this so different here? Is it just cheaper? Or is it actually that much harder to make the rocket land softly on its own exhaust jet than to make it go into orbit?

[We] use bad software and bad machines for the wrong things. -- R.W. Hamming

Working...