Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:Ubuntu _is_ primarily a desktop OS... (Score 1) 115

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.

Comment Re: Oracle's monopoly? (Score 1) 457

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.

Comment Re:Antropologist (Score 1) 128

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

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

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

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

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

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.

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Working...