Forgot your password?

Comment: Re:So, go ahead, create a bio-weapon at home (Score 1) 63

by david_bonn (#47875477) Attached to: The Grassroots Future of Biohacking

I am getting very skeptical about the home-made bioweapon that ends the world.

It isn't unreasonable to think that some lone idiot could make a new version of smallpox or bubonic plague or bird flu that goes the distance. My question is how in heck would they test it? DNA is like the worst imaginable spaghetti code, so it isn't like you just flip this one sequence here and your ordinary flu bug is 99 percent fatal. And if you combine in other stuff you have no real idea what unintended side effects might make your world-killer fizzle out. And given the very large number of angry people with guns who would be looking for me, I would want to be DAMN sure that my world-killer would really kill the world.

If I wasn't suicidal, I'd also want a vaccine. How are you going to make that vaccine without testing? I mean like really infect people, vaccinate some uninfected people, put them together, and see who dies. And for your potential world-killer to go the distance, it would have to be easily transmittable -- so that implies that you would need wicked good biocontainment and someplace very private to do your evil deeds.

Now, there are still some awful things you could do without needing to worry about testing so much. Making a hypothetical virus that would be asymptomatic (or just very mild) for nearly everyone except some small group with specific DNA markers, or just one person, would be possible. It would sure suck to be president or even a university professor who gave the wrong little snowflake a shitty grade.

Comment: that gets the salmon upstream... (Score 3, Interesting) 147

by david_bonn (#47851197) Attached to: Restoring Salmon To Their Original Habitat -- With a Cannon

The problem is that you kill just as large a percentage on the downstream trip, largely due to dissolved gas bubbles in their flesh due to dramatic pressure changes. So even if you can get the adult salmon upstream to spawn, the baby salmon can't survive the downstream trip because they get the bends.

Even if they get past all of the dams, they have to go past the mildly radioactive section around Hanford and then the rather polluted Columbia River Estuary below Bonneville Dam.

Comment: Re: No one will ever buy a GM product again (Score 2) 307

by david_bonn (#47181371) Attached to: GM Names and Fires Engineers Involved In Faulty Ignition Switch

Anecdotal evidence.

I have never owned an American-made car. I have owned various Toyota or Lexus products for the last fifteen years.

My rigs always come with rubber floor mats. After Toyota redesigned the floor mat I had the very exciting experience of the accelerator sticking under the floor mat while boarding a ferry. Lots of luck and quick thinking prevented an accident. I pulled the floor mat right then and called the dealer and Toyota of America and told them they were murderous dumbfuck morons.

I found out later that the dealer started pulling rubber floor mats out of all of their customer's cars. This was about a year before all of the hype about sai's. The fact that my dealer took it that seriously did a lot to win back my confidence.

I do know that rubber floor mats could easily produce a sticking accelerator in some Toyota models. I never had any other experiences with sudden acceleration so have no opinion about whether or not firmware bugs could also cause such incidents.

Comment: just floating-point errors... (Score 1) 422

by david_bonn (#47111541) Attached to: Why You Shouldn't Use Spreadsheets For Important Work

A lot of spreadsheets have formulas that are dependent on calculated values from the preceding row or column. In fact, the replication functions most spreadsheets have encourage you to do this.

The problem, as any well-trained computer scientist knows, is that floating-point errors can rapidly accumulate using these kinds of calculations. Very. Rapidly. That means that your answers fifty or eighty rows along might well be gibberish.

I've been to three separate meetings at three separate companies whee different people's spreadsheets gave hilariously differing answers. Faces got red, voices got raised. The reality was that no one had numbers that were even close to right.

Comment: Different focus, I think (Score 3, Interesting) 309

by david_bonn (#46975223) Attached to: Ask Slashdot: Computer Science Freshman, Too Soon To Job Hunt?

I wouldn't worry about some list of technologies. I wouldn't worry about n years of experience in some field.

Technologies come and go rapidly.

It would be better to focus on what problems you have solved, and how you used technologies you knew and came up to speed rapidly on technologies you did not know to solve those problems. Come into an interview with working software you can demo and code you have written -- and expect to talk about what you are showing.

Also, bypass recruiters as much as possible. Work connections through friends, family, and school to get an interview. Expect to get turned down more than you get accepted, but eventually something will turn up.

Comment: Re:Helios flight disaster. (Score 1) 436

by david_bonn (#46493133) Attached to: Malaysian Flight Disappearance 'Deliberate'

I've been suspecting nearly the same thing.

Hypoxia can set in within minutes, and people can become extremely confused under its influence. If the pilots were so confused they thought the plane was malfunctioning for some other reason they might have started resetting things by shutting off circuit breakers and inadvertently shut off the transponder. Hypoxia could also explain the very extreme altitude changes that were reported.

I'm also thinking a fire in the cockpit could have caused nearly the same thing, and if the fire did enough damage that they could no longer control the plane but the autopilot still worked that also would explain most of what we know about the flight. But that seems a little bit or a lot unlikely.

If it is some terrorist or special operations chicanery then it is really an oddball scheme -- more like a Clive Cussler or Tom Clancy novel than something that would happen in the real world, I think.

Comment: visual what? (Score 1) 876

by david_bonn (#46193053) Attached to: Ask Slashdot: Why Are We Still Writing Text-Based Code?

My first observation is that even relatively simple programs can't be represented graphically and comprehensibly in two or even three dimensions. Since programs really aren't required to have a physical representation at all, there isn't any reason to expect that would be the case. Anyone who has played around with old-school flowcharts quickly discovers that flowcharts become unwieldy and incomprehensible for all but pretty basic algorithms.

My other observation is more of a question: what do you wish to visually represent? Execution flow? Data flow? Something else? Everything?

Comment: Re:do ave beacons eve n help? (Score 1) 100

by david_bonn (#45242347) Attached to: Ask Slashdot: Developer Responsibility When Apps Might Risk Lives?

Avalanche beacons definitely help. And the technology has dramatically improved in the last twenty or thirty years. They are definitely easier to use and much more reliable nowadays.

Having said that, there are some fairly serious limitations on how well they can work. From what I remember of avalanche school, about fifty percent of avalanche victims die of traumatic injuries during the event, so obviously beacons can't help in those situations (my own personal experience in an avalanche included the tail of my ski hitting me in the forehead while still attached to my boot). But for the remaining fifty percent of victims who are likely to suffocate within minutes unless found avalanche beacons are an invaluable tool.

There is, of course, much that can be done to improve them. But that is another story.

Comment: lots of reasons, standards probably first (Score 1) 497

by david_bonn (#45092421) Attached to: Cost of $634 Million — So Far

Having done a few contracts for the feds over the years, I have a pretty good idea why something like this happened.

Probably the biggest one was standards chosen before the project was even conceived and shoehorned into some product it wasn't intended for.

With the NSF, it was using Ada and ISO/OSI instead of C or C++ and TCP/IP. We solved that problem with creative prevarication. Since there was no imaginable way that the functionality was even implementable in ISO/OSI, we got away with it.

With DOI, it was using IIS and Windows rather than Linux and Apache. We told them that would increase development costs by a factor of ten and delivery would take twice as long. A waiver was quickly produced that let us do things our way.

It tells you how awful the federal contracting system is if you have to lie or bully them to let you deliver a working product.

"Oh dear, I think you'll find reality's on the blink again." -- Marvin The Paranoid Android