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

 



Forgot your password?
typodupeerror

Comment: Re:I agree. (Score 4, Insightful) 624

by NeutronCowboy (#49585621) Attached to: Disney Replaces Longtime IT Staff With H-1B Workers

The real problem here is that IT is regarded as something like a janitorial service, rather than an integral business function. That's a recipe for a slow burn into the ground. There is plenty of cog work to be done, sure. But if you don't use IT to actually change how you do business, you're not doing IT.

I'm not surprised then that Disney is only making money by buying IP, and riding old IP. They're organizationally prohibited of producing something new.

Comment: Re:flashy, but risky too. (Score 1) 81

by NeutronCowboy (#49578599) Attached to: Uber Testing Massive Merchant Delivery Service

Insurance means very little to companies who have a certain service standard to uphold. No one will give a shit if they get their money back if their order of 10k worth of shoes disappears. These people want their service, and they will blame whoever they bought their stuff from if anything goes wrong.

There is a reason why certain trucking operations pay their truckers a shit-ton of money, have armed guards, locked trucks, tracking devices, etc. It's so that shit doesn't get "lost", not that they can pay their customer for shit that got "lost".

Comment: Re:160 characters to die for (Score 1) 247

by hankwang (#49566481) Attached to: The Engineer's Lament -- Prioritizing Car Safety Issues

"Folks walk out into traffic staring at the samsung. Go 10 blocks in Manhattan, you will get at least a dozen of these folks. No spatial awareness at all."

If you're on foot, you can usually have pretty good spatial awareness of cars from your ears. Doesn't work well for bicycles and e-cars at low speed, though.

When I'm cycling abroad (I'm from Netherlands) on the countryside, it's weird how some car drivers seem to think that it's necessary to announce themselves by honking the horn even though I could already identify them as truck, passenger car, or agricultural vehicle before they were aware of me.

Comment: Re:Good! (Score 3, Interesting) 25

by hankwang (#49415191) Attached to: Google In Talks To Create International Roaming Network

Telecom is hugely profitable, mobile telecom even more so.

Could you provide some data to support that statement? Not that I think the roaming charges are reasonable (since they are completely disconnected from actual costs for the operators), but that would just mean that domestic charges should go up and international/roaming rates should go down.

Look for example at the Vodafone annual report (big PDF), income statement on page 96. On 38 bn UK pounds annual revenue, the made 5 bn loss (before taxes, not including the profitable sale of their stake in Verizon).

Or the T-mobile US numbers on 2014 (full year). Page 6: US$ 14 bn revenue; net income US$ 0.25 bn. That does not look like a hugely profitable business to me. Or the balance sheet on page 5: US$ 57 bn assets, and only US$ 16 bn of stockholder's equity; a ratio of 3.6:1, which I'd consider pretty large for a company that is not making a large profit and that has to deal with rapidly depreciating infrastructure.

Here's Verizon 2014 full year: US$ 127 bn revenue, US$ 12 bn net income. That looks more healthy. But look at the balance sheet: US$ 232 bn assets, and just US$ 14bn in equity (16:1 ratio). I would be very hesitant to invest in a company with such a balance sheet. To my surprise, the stock market thinks differently with a P/E of 21.

I'm not a finance expert, so if I misinterpret the numbers, please correct me.

Comment: Re:The big advantage of XOR (Score 2) 277

example is the AES-NI instructions, which exist on essentially all modern desktop and laptop CPUs, and many of the newest mobile CPUs as well.

What's the difference between "mobile CPU" and "laptop CPU"? In any case, most 4th generation i3 mobile/laptop CPUs don't support AES-NI, nor do the current Intel Celeron CPUs. Many of those have been released as recently as 2014, so I would count them as "modern".

Comment: Re:What are you protecting? (Score 1) 277

You can build a sophisticated cypher that does not require polynomials, massive primes or any of the stuff that RSA uses

That stuff is for secure key exchange over an untrusted channel. The actual ciphers that are used to process the bulk of the data is not much more complicated than what you describe. You can look up the algorithms for RC4, AES, and blowfish.

Create a two dimensional array each dimension being 64K in size of 64 bit integers (...) If you exhaust the length of the key simply wrap it around.

Several big problems with that: 1. You'll need to calculate 2^32 (4 billion) 64-bit entries, i.e. 32 GiB, which is a lot of CPU time and memory if you just wanted to encrypt 10 kB of plaintext. (I'm not completely sure how you want to implement it; maybe you "only" need to calculate 64 k random values for each word of plaintext). 2. You need a really good (cryptographic-grade) random generator. If you have one, you could just as well use it directly - it's called "stream cipher". 3. If you wrap around your 32 GiB "two-time" pad over a low-entropy plaintext source, it is broken, since you can xor the plaintext at offset 0 with itself at offset 32 GiB to cancel out the pad. If you know that the message is plain English language, that may be enough reconstruct the two plaintext messages. [English has about 1 bit of entropy per character; xoring two texts with itself wlil result in about 2 bits of entropy per byte (8 bits) of message.] 4. If you encrypt two plaintext messages with the same key, your encryption is broken, for the same reason as under #3.

Comment: Re:xor unbreakable with long (stretched) key (Score 1) 277

RC4 is simple, it's fast, (...) and it is *broken*.

It's only provably broken if you don't use the straightforward workaround for its weakness, i.e., discarding the first few hundred bytes (2 KiB to be on the safe side) of cipher stream. This was a problem in WEP encryption and may be a problem in the SSL implementation (not sure about today's status) and it kind of negates the speed advantage if RC4 is used for transmitting short messages. But run ssh with RC4 (it will drop the first 2 kB of the key stream) for large file transfers and you're safe and fast.

Comment: Re:Don't make it impossible, just make it hard (Score 1) 385

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

"Why would the cabin crew have the code? The code is for the pilots."

Here is airbus's own explanation: http://m.youtube.com/watch?v=R...

TL;DW: if the pilots are incapacitated, the cabin crew can punch a code to save the day; the door will unlock after 30 seconds unless the pilot pushes the button to deny access. (the pilots are alerted by a beeping signal.) Actually, a pretty sensible way to do it.

Comment: Re:Check their work or check the summary? (Score 2) 486

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

And this is why we should not teach CS101 in Java or Python. If they'd been forced to use C this whole experiment would have turned out differently.

Not at all. If you wrote your C in memory string handling as stupidly as they wrote the Python and Java you will still get worse performance in C (e.g. each iteration malloc a new string and then strcpy and strcat into it, and free the old string; compared to buffered file writes you'll lose). It's about failing to understand how to write efficient code, not about which language you chose.

Comment: Re:Maybe you should have read more than one senten (Score 1) 264

And this is why the "channel" Internet is a horrible, horrible idea, which needs to be nuked from orbit, just to be safe. It'll be the return of corporate-interest TV, with all the propaganda that comes with it - but with the veneer of "it's on the Internet, so people checked it!".

All programmers are playwrights and all computers are lousy actors.

Working...