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


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:In before... (Score 1) 148

And I can't remember all those hex digits LOL

And THIS is the best thing about IPv6: it might finally stop enterprise IT teams and programmers from using IP addresses to access everything, rather than using their names. Because IPv4 numbers are easy to remember, it's tempting to use them in config files, command lines, and code. But this is a dangerous practice, considering that many IP addresses change assignments regularly, even if they are "fixed" addresses. I've seen entire VM clusters inadvertently wiped out by IT staff because they mis-typed an IP address.

Comment What defines "hair on fire"? (Score 1) 85

Every software team has to prioritize bug fixes, including security vulnerabilities. When deciding which ones to fix first, every team considers factors such as:
- severity - how costly is the damage that occurs from the problem?
- frequency - how often does it happen, or how often is it likely to happen?
- cost - how much does it cost to fix?

If a bug is really severe (bricks your device) but it happens only once for each 100 million installations, it might not be worth the effort to fix it.

I think the author is considering only severity when he refers to these issues being "hair on fire." But how often are these vulnerabilities exploited in real life? How does this frequency compare to, say, ordinary car theft? In the US, about 2,000 cars are stolen every day, mostly through low-tech methods. I doubt these security "flaws" are exploited anywhere close to that often.

I don't think anybody's hair is actually on fire yet.

Comment We already use automated coding every day (Score 1) 140

IDEs like Visual Studio generate code using a GUI. Report builders like SSRS generate code using a GUI. There are lots of examples, and they all have one thing in common: they work within very limited boundaries. Visual Studio generates code to produce data entry forms; SSRS generates code to produce reports. This project might generate some specific class of applications. That's nothing new, but it will certainly never replace general purpose languages.

Comment Somebody sold India a LOT of hardware (Score 1) 93

India is going to find out that iris scanning suffers from all of the same issues as any other biometric scanning device. ALL of them have to turn the scan into a digital representation, which is then used to authenticate or verify identity. The weak point int he process is between the device and the computer. Since that digital representation can be copied and replicated, it is no more secure than any other identification system. It's actually less secure, because it's considered the user name AND password. Any biometric system really needs a second factor, a password, to go with it.

Comment DNA reading techniques require massive redundancy (Score 1) 42

Today's DNA reading techniques begin with PCR, a process that multiplies small amounts of DNA so that millions of copies are made. These copies are needed to be accurately read by the equipment, in order to distinguish between "good" copies and noise. Getting the results amounts to statistical analysis of the number of A, T, C, or G results read at a certain location; a "call" can be made only if a high enough percentage of the results agree.

The bit density claims are massively overstated, and reading the data would not be trivial!

Comment DNA degrades after just a few years (Score 2) 42

I work for a DNA lab. After about 10 years, DNA samples that have been sent to us are basically unusable because they degrade over time. Sure, it might be possible to still read some strands of the remaining DNA, but significant percentages are lost. DNA archaeologists don't mind, because they are looking for whatever fragments they can still read. But if they required most of the DNA to be readable after long periods of time, they would be out of luck.

Comment Re:Why "smart" IDs are a bad idea (Score 1) 135

Oh how well I know! I'm old enough to have used punch cards. In a sense, it's like the Y2K problem. It's a legacy technique that had a purpose in the beginning, and was never corrected when it became obvious that there was a real cost. The biggest difference is that the "smart key" problem is still in wide use in NEW applications today, while the Y2K problem has largely been obliterated.

Comment Re:Why "smart" IDs are a bad idea (Score 1) 135

The greater sin here was that they were using a live system for testing

I don't know about that. There are many situations where it is impossible, or infeasible, to reproduce an entire production environment with test equipment. For example, if you are writing software to use a credit card processor, you have no choice but to connect with the "real" credit card processor to do your testing, since you don't have access to the processor's system. Sure the processor might have a test environment for you to use, but there are bugs that don't show up in a test environment, only in production.

Still, you're right about not needing "testing" IDs, a separate field that indicates a test transaction is always better.

Comment Why "smart" IDs are a bad idea (Score 4, Insightful) 135

This is a perfect illustration of why "smart" IDs are a bad idea. Any time you encode attributes (like "this is a test transaction") into an ID (like a range of bank branch IDs) you are asking for trouble. Everybody does it, but it's usually just plain lazy and careless. DON'T! Add an attribute that marks the transaction as a test transaction! Then anybody who sees it will instantly know the difference.

Slashdot Top Deals

"A complex system that works is invariably found to have evolved from a simple system that worked." -- John Gall, _Systemantics_