Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Ummmm ... duh? (Score 1) 297

by Rei (#49358149) Attached to: Modern Cockpits: Harder To Invade But Easier To Lock Up

Sure there is: add this to the CPDLC standard and make all of the hardware modifications needed to support it:

----
Message type: Revert flight plan and lock
Message arguments: TIME: the time of the flight plan to use
Message description: Revert to the flight plan that was active at TIME that had been approved by both ground control and the pilot; engage autopilot; and disable all pilot / copilot access to all systems. If there is no approved flight plan then the flight plan is to return to the nearest suitable airport in the most direct route possible.
----

Additional modifications: Make sure that the pilot can never disable datalink communications with ground by any means that ground wouldn't have time to respond to.

Result: Nobody is ever "remote controlling" the plane from the ground. A murderous / terrorist ground controller can't crash the plane, only make it autopilot itself on a previously approved or otherwise reasonable flight plan. A pilot behaving suspiciously can't crash the plane, as ground control will just engage the autopilot and lock them out. To abuse the system both ground and the pilot would have to agree on a suicidal flight plan.

Comment: Re:When it works. (Score 1) 186

by Jaime2 (#49356683) Attached to: Ask Slashdot: What Makes Some Code Particularly Good?

Whether it works is orthogonal to quality. Good code can be fixed easily, so good code is always a short distance from "it works". Bad code can quickly go from "it works" to "it doesn't work and I don't know why" with just a simple change in requirements.

One of my rules is that the customer is the judge of whether is works or not, but the team is the judge of whether it is good or not. If the only person to evaluate the product is the customer, then you are pretty much guaranteed to have bad code. Code quality management comes before testing in the form of design reviews, code reviews, standards, pair programming, etc...

Comment: Re:Not concerned (Score 2) 171

by gmhowell (#49353367) Attached to: German Auto Firms Face Roadblock In Testing Driverless Car Software

I should actually correct myself slightly: Wal-Mart (and others) have some in house drivers and some outsourced.

BTW, in discussions of the transport industry, don't get distracted/lied to by the companies. Some drivers think they are owner operators, when in practice, they aren't. They will lease/buy a truck from (as an example, all of the bigs do this) Schneider. As part of the lease terms, they can only accept loads from Schneider. It should be obvious that the 'owner' is an employee who has assumed much of the risk that the company would usually take on.

ShanghaiBill has a decent reply, but he misses a point: if the automated truck is cheaper, the big companies will drive that change in a heartbeat. The trick is that someone has to be convinced that they will be cheaper. They are unlikely to automatically accept that an automated truck is safer, faster, etc. One area where they are likely to be impressed is the possibility of 24 hour operations, rather than the 10 hour per day (rough) limits of human operated trucks. In addition to (possibly) being cheaper, this will allow faster shipments for more mundane goods (there are already plenty of ways to have fast shipping, but it is cost prohibitive to do for everything) which would offer them a competitive advantage. I suspect this last point will be the thin edge of the wedge.

Comment: Re:Heisenberg compensator ... (Score 1) 83

I think of all the times anyone has tried to explain it to me, this is the one that clicked. If I'm understanding correctly, they're (electrons, photons, et al) not really either a "particle", as I think of it (like you say, teeny tiny baseballs with well defined boundaries and positions), or a "wave", but entirely different animals that happen to have some, not even all, of the features of both.

Thanks (assuming I didn't misunderstand!)

Comment: Re:Memorizing site-unique passwords isn't possible (Score 2) 246

by Rei (#49350175) Attached to: Generate Memorizable Passphrases That Even the NSA Can't Guess

Yeah, the suggested method for generating passwords generates needlessly long passwords. The total entropy is good, but the entropy per character is pretty poor. You get much better entropy per character with abbreviation passwords, where you have a sentence or group of random words and you use the first letter from each, or second, or last, or alternating, or whatever suits you. It's still not as much entropy per character as a random pattern, but it's much better than writing out full words - and pops into your head just as fast (because it is, in essence, the same).

Comment: Re:Not really needed (Score 1) 34

by Waffle Iron (#49349923) Attached to: MIT Debuts Integer Overflow Debugger

If his garbage causes you take take a different flow of execution, however, that provides him a way to reach bugs in the little-used parts of your code.

The different flow of execution triggered by an overflow trap should almost always be a simple call to "abort()". At this point, your program has already failed and should be stopped.

I disagree with your premise. Garbage input values should be checked and rejected in software before the overflow ever occurs. The hardware overflow check should be a last resort to enforce this at every instruction step, and in the worst case it converts privilege exploits into less serious DOS attacks.

Allowing "garbage output" as you propose just creates more opportunities for attacks when that output gets consumed somewhere.

Comment: Perhaps the problem is with the concept. (Score 1) 157

by hey! (#49349767) Attached to: Many Password Strength Meters Are Downright Weak, Researchers Say

What does "password strength" really mean?

If people used a textual representation of number obtained from a reliable hardware random number generator then the meaning would be unambiguous. It's the number of digits in that number. But most people don't do that (perhaps more should).

So what does it mean to say that a password has so many bits of entropy? Well, I guess it means how many truly random bits it would take to index their password from the universe of passwords the user considered. This is more an exercise in psychology than it is in mathematics. You have to figure out how users generate passwords or discount passwords. For example requiring a mix of upper and lower case letters doesn't add as much entropy as you'd think, because most users are mediocre typists who'll avoid using the shift key too often. Requiring digits means that many people will just "0" for "o" and "1" for "L".

So it's really easy to concoct passwords which you know are bad, because you know the methods used to select which passwords you'd consider; if the developers of the strength meter don't take your particular generation algorithm into account the meter will show the password to be stronger than you know it to be.

"Be *excellent* to each other." -- Bill, or Ted, in Bill and Ted's Excellent Adventure

Working...