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


Forgot your password?

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:Yes, but.... (Score 1) 112

by gnasher719 (#49350055) Attached to: Generate Memorizable Passphrases That Even the NSA Can't Guess
My bloody bank required 8-12 characters, and required uppercase, lowercase, digits and special characters.

Obviously the lovely scheme that is suggested here isn't going to work with that. On the other hand, when you are using an iPad, a 30 character all lowercase password is quicker and easier to type and more likely to get right than 8 uppercase/lowercase/digits/special characters. Now imagine if they allow space characters in the password and turn the spelling checker on as well.

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

by gnasher719 (#49349655) Attached to: MIT Debuts Integer Overflow Debugger

Not that checking it after every add instruction is really that practical. It would be better to have trapping and non-trapping versions of integer arithmetic, and to have languages with semantics which expose that choice to the programmer.

Swift does exactly that. Every instruction is checked for overflow. Not sure how clever the compiler is in proving that certain instructions cannot overflow.

Comment: Re:Not always true... (Score 1) 623

by gnasher719 (#49346111) Attached to: Germanwings Plane Crash Was No Accident

What about a stroke while still breathing, locking accidentally the door to "locked from inside", triggering accidentally the descent mechanism, accidentally not answering the door?

That is of course a possibility. But how often has it happened that someone had a stroke while still breathing, triggering the descent mechanism by accident and _not_ locking the door from the inside? It seems that it is hard to lock the door by accident, so not locking it is 100 times more likely than locking it. Do we have any reported case of that? Where the pilot went into the cockpit just in time to save the airplane? I don't think so.

Comment: Re:Risk Management (Score 1) 623

by gnasher719 (#49346041) Attached to: Germanwings Plane Crash Was No Accident

If you can't see the obvious tragic death of a child (with their future robbed from them) having a heavier weight than an 80 y/o great grandmother who's had a wonderful life then I can't help you.

It may have more effect on relatives. The effect on the person dying is the same. And there have been times not so far away when a huge percentage of children didn't ever make it to adulthood.

Comment: Re:it could have been an accident (Score 1) 623

by gnasher719 (#49345951) Attached to: Germanwings Plane Crash Was No Accident

The chances of that are about the same as those people who committed suicide by shooting themselves in the head - twice.

I read that it is possible to put two bullets in the gun - one the normal way, and one just pushed into the gun. So it is not possible to shoot yourself in the head twice, but it is possible to have two bullets in your head.

Comment: Re:Easy as 1-2-3 (Score 1) 255

by gnasher719 (#49339671) Attached to: Developers and the Fear of Apple

Samsung spends far more on marketing than Apple.

They have done that in the past, at times massively. Right now Samsung mobile revenues are down, and if they spent the same money on advertising they spent in the past, the would actually lose money. Profits are down as it is.

The semiconductor part that has actually grown in revenue and profit doesn't really need that much marketing.

Comment: Re:Check their work or check the summary? (Score 1) 469

by gnasher719 (#49337709) Attached to: No, It's Not Always Quicker To Do Things In Memory

I knew a guy with a Masters in CS who loudly proclaimed optimizing was a pointless exercise.

In many cases, it is true. Not being able to optimise however is quite bad. On the other hand, in my experience when I was given code that ran too slow, it almost never was because it wasn't optimised, but because it did something stupid (like some code that downloaded n files and took O (n^3) time; worked fine with n = 10 but when I tried with n = 200 it just broke down). Changing that to O (n) isn't what I would call "optimising".

Comment: Re:Check their work or check the summary? (Score 1) 469

by gnasher719 (#49337669) Attached to: No, It's Not Always Quicker To Do Things In Memory

That is pretty much what the article suggests. Concatenating string involves creating objects, blah blah blah...

I doubt you'd see the same "9000 times slower!" kind of results with standard C strings.

Of course you do. Assuming you allocated a big enough buffer at the start, strcat takes time proportionally to the length of the first string, because it has to search for the zero byte at the end of that string. If you want it fast, use C++ std::string, or Objective-C NSMutableString.

Comment: Re:Check their work or check the summary? (Score 1) 469

by gnasher719 (#49337609) Attached to: No, It's Not Always Quicker To Do Things In Memory

You don't even have to read the code. Reading what languages they used reveals the entire flaw. They used languages with expensive string operations when done in-memory which is the only reason why writing to a buffered cache and writing to disk is faster.

No, string operations in Java are not expensive. They are expensive if you do them stupidly.

Comment: Re:It depends (Score 1) 469

by gnasher719 (#49337563) Attached to: No, It's Not Always Quicker To Do Things In Memory

Indeed. Their results make no sense. They are doing something weird. For instance, their paper says that concatenating a million one byte strings into a single million byte string takes 274 seconds. That should take much less than one second. Their code is listed at the end of the paper, and they seem to be assuming that "flush" means the code is actually written to disk. It does not. It just means the bytes were passed to the operating system.

What are the bets that they didn't actually append a byte to a string, but created a new string consisting of an old string with one byte added?

In Objective-C, this would be using NSString instead of NSMutableString. In Java, which they were using, probably using a String instead of a StringBuilder or something similar. A file containing a string is basically a mutable string.

So the headline should be: Doing things on disk can be faster than doing incredibly stupid things in memory.

Comment: Re:And now, things get Ugly. (Score 3, Insightful) 120

by gnasher719 (#49334531) Attached to: Uber To Turn Into a Big Data Company By Selling Location Data

This is not what big data is, this is just selling customers' information. And Google, despite being listed in the summary, never does it BTW.

That lame argument that Google doesn't sell out customer's data comes up again and again. And it is nonsense, every time. They don't sell the data, but they sell the use of the data. They place adverts based on the data, using their deep knowledge about you (the product).

This is like arguing that an email spammer who doesn't sell his address list to other spammers, but sends spam emails as a service, is a good guy because he doesn't sell your address. Or arguing that a car thief doesn't do any harm as long as he drives around in my car himself, or rents it out, or uses it as a taxi, as long as he doesn't sell it.

Comment: Re:Bet the US can as well ... (Score 1) 132

by gnasher719 (#49331485) Attached to: Chinese CA Issues Certificates To Impersonate Google

Can't pretty much any high enough level certificate authority issue any damned certificate it wants?

Yes, they can. But that only works if Microsoft puts a root certificate for that certificate on all Windows PCs, and Apple puts it on all Macs and iOS devices, and Google puts it as a root certificiate on all Android devices and so on. If you get caught, the next Windows/Apple/Google security update removes the root certificate, and that certificate authority is dead.

The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft.