Forgot your password?

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.

Comment: Re:Errant twaddle (Score 1) 325

by david_bonn (#43200699) Attached to: How Beer Gave Us Civilization

In general, whether your grain of choice is wheat, rice, barley, maize, or quinoa, you'll need to cook it. And you won't necessarily need pottery to cook it either. Lots of native american cultures cooked in baskets, by transferring hot stones to the baskets which were full of liquid. This amazingly didn't burn the basket.

Chances are this was how our distant ancestors cooked their grains. While pottery surfaced in Japan about 9000 years ago, it took quite a while to disperse.

So a similar thing could obviously be done with beer, and the beer could easily be stored in watertight baskets, and wouldn't exactly leave a whole lot of evidence for the archaeologists.

And before you ask about watertight baskets, I have an Eyak basket made of seal gut which is quite watertight. Anyway, you could always seal the basket with animal fat.

Comment: given finite resources... (Score 1) 583

by david_bonn (#38885543) Attached to: When it comes to U.S. colonies on the moon ...

I have to ask, aren't there things (in space) that have a higher return on investment? A ballpark figure for a moon colony would be well north of $200 billion.

It seems that the science return from unmanned space probes has been enormously high, and it doesn't seem clear that the science return from manned space travel has been all that high. I'd also worry that the resources spent on a lunar colony would be taken from other space programs, like the unmanned exploration programs. So we'd be trading a high-return program for a somewhat lower one.

I'd also argue that if we want to build a long-term presence in space, focusing on technologies that will let us have sustainable, affordable space travel would be a wiser way to go -- I'd rather see a moon colony in 2050 or so that was permanent and affordable rather than one in 2020 that was abandoned in 2022.

Comment: Peopleware (Score 1) 1019

by david_bonn (#30414564) Attached to: Music While Programming?

The classic book Peopleware had some excellent disussions about this issue. Like most productivity-related things, there is good news and bad news.

There is an excellent discussion in that book about how productivity of coders is impacted by the number and frequency of distractions. That helps your case.

On the other side, there was another great discussion about listening to music while programming. They referred to a study (at MIT, I think) where two groups were given a series of puzzles to solve. One group while listening to music, the other while not listening to music. Here's the rub: all of the puzzles had a "brute force" solution and a much simpler "aha!" solution. None of the people listening to music found the "aha!" solutions, and about half of the people not listening to music did. Now depending on your situation and the kind of code you are writing, you might want or need those "aha!" solutions and probably ought to skip the music.

Gee, Toto, I don't think we're in Kansas anymore.