http://panko.shidler.hawaii.ed... there's academic work going back years "indicting" spreadsheets. Not that anyone pays attention... inside academic circles or outside.

"... No one owns a car for 10 or 20 years anymore..."

Each of my Hondas have done at least 10 years. My 1996 Acura is still quite healthy. My 1987 Shadow as well.

I suspect that no one who reads /. Is in the target demographic. It will be interesting to see how this plays out.

"... No one owns a car for 10 or 20 years anymore..."

Each of my Hondas have done at least 10 years. My 1996 Acura is still quit healthy. My 1987 Shadow as well.

I suspect that no one who reads /. Is in the target demographic. It will be interesting to see how this plays out.

Indeed. In one of my first college courses we were permitted to take notes in the (very small) margin of the text itself. This led to focus on the instructor and very small amounts of note taking.

In High School I took more notes and learned less.

The best situation was where I took little or not notes, but paid one of the transcribers for the hearing impaired for their professional notes (in those dark days before professors provided pointers to their web page ;>). I focused on the lecture, and a professional took notes. I wound up not using the professional notes all that much (usually it repeated things in the text book ... but for the one time in a hundred that material wasn't in the textbook AND was on the test ... it was invaluable ;>).

The other "trick" was to write notes immediately *after* class. While precise dates and fiddly facts weren't recorded, the overall structure of the lecture and the immediate impressions I formed were there for the recording. This has proved useful in the many years since ... recording the gist of discussions (if I can't remember it 10 minutes after the meeting, it probably wasn't terribly important) ... and sending them out as minutes (soliciting corrections from attendees) is usually far more effective than recording and ignoring the mp3 when trying to figure out at what meeting we went down the wrong algorithmic path ;>

Perhaps the language from "across the pond" is hard for some US readers to parse. "Exploitation" meaning "use effectively" ... without knowing more about what this bloke's department(s) are tasked to do, it is hard to call him to task for his choice.

I would not be surprised if Macintoshes were even a better match for his user base.

I cannot seem to find it, but I recently ran across a bizarre claim that the average office worker's time is dominated by outlook (duh) but that Microsoft Word was number two at a paltry few minutes per day, and Powerpoint even less than that. Quite possibly true, and while that does tee up the question for why they need Microsoft products at all (since casual users needs can be met by a wide variety of FOSS projects) it would explain why retraining is *so* difficult. For people who live and breathe computing, learning a new platform isn't hard and is even "fun". For people who really only need to tinker with a few characters in documents that pass through their hands for a few minutes per day ... virtually ANY change is highly disruptive.

SAAB dealt with this issue mechanically decades ago. Mechanical key in the center, where the handbrake is located. No stress on the mechanical switch due to heavy key rings.

Worked very well, unless they had (have) a patent on it, seems like an easier more reliable fix.

The published text of the PM's speech makes it clear its based on the analysis (what you are calling "statistical probability") not debris or black box.

I don't know why anyone would find that disturbing.

Even if he had debris, for any given family there would still be some "statistical probability" that their loved one survived (infinitely close to zero) involving some sort of miracle, a hidden parachute or a missed connection, etc. Just as we'd discard such false hope, pretending that there is some other place folks ought to be looking or that there is any realistic chance that their family members are safe as hostages in some terrorist base.

It is exceedingly unfortunate that the data analysis was relatively slow (and the data itself was never open sourced); the delay resulted in much lost time and resources by many naval and air groups, and lots of needless gnashing of international teeth.

If there's any lesson here, the satellite data feed(s) should become a bit more formalized, and their release in the event of an accident be as standardized as the black box information. As for the $10/flight for the data, even if the airline doesn't pay for it up front, the data collectors should collect it, and save it until after the flight has landed. If it doesn't land, the airline can pay some much larger fee to get the data ahead of it going public ;>

Yesterday the discussion seemed to center on how bloody expensive it would be to track the planes and how special equipment and etc. would be required. Now everyone seems to understand that messages can come from the planes ... indeed, it would have been trivial (although it would have involved a fee) to record the rest of the plane sensor data.

Instead of reinventing the wheel, and making some magical device to transmit just before an accident ... the folks who maintain the current system record the last 5 positions ... but not release them except when they are paid OR there is an accident. The amount of data storage would be small, and the infrastructure apparently already exists.

Obviously, old enough airframes might not *yet* have the equipment, but rolling them in as engines and/or other major renovations occur should be feasible.

"Are the dealers afraid that the majors are going to copy Tesla's model and cut them out of the business?"

Yes, precisely. Just as Amazon reduced the number of bookstores by a pretty wide margin. Dealerships suck up a lot of the profit, GM could sell direct for a lot less than current prices *and* make more $$.

The "term of art" for this is disintermediation. And the dealers are well advised to fear it. But its unclear to me why in the world government should protect them from it. Customers outnumber dealers by a wide margin at the voting booth.

jokes aside, the most obvious thing is for you to:

a) Do enough consulting/hands on work to get a firm grounding (do that in the summers even if you keep your teaching slot)
b) Move up to community college, vocational school, private tutoring, etc If you are a great teacher, focus on that. But expand your turf so you can teach more

I suppose if you are tired of the actual teaching, then this isn't very sound advice ;>

'but should these governmental restrictions apply to an open-source software project?' there would appear to be two different questions here. (1) does the current law apply and (2) should the law apply.

w.r.t. (1) Sounds like some cognizant group has determined that the law does (or at least may) apply, so the Fedora team is taking the steps they can.

As for (2), that is a matter for Congress. Lobby them if you think the law should carve out an exception for Open Source projects (all or some specific licenses).

Essay writing isn't a key skill useful for college or thereafter?

Penalizing students for guessing is somehow no longer a good idea?

I appreciate their thinking about the issues, but the conclusions seem odd to me.

Such a degree, if it were to exist, should focus NOT on the basics of CS, but on good design.

1) Do cover human factor engineering principles and techniques. Include lab work to do usability testing.
2) Do cover the basics of good design (perhaps a joint Art department effort).
3) Do cover the foundations of programming, but using several web focused languages. C/C++/Algol and friends are wonderful, but you have limited hours.
4) Do provide an introduction to computer security. Chances are it is folks in the backend that need to focus on it, but security holes can occur anywhere.

Good luck.

The question seems so ill-posed that one has to wonder if there's a product or service advert lurking... but assuming this is real.

Software doesn't automatically translate directly to hardware. As others have noted, break out the algorithmic core from the setup and finish. Presumably there is some part of the code which is the most critical in steady state. Describe that to their hardware engineers in whatever depth is required. Depending on the algorithm, the ASIC library elements available (or FPGA units, etc.) you may want to make some substantial adjustments to the "code" to make it fit within the design parameters of the available device. This should be an iterative process, not a single estimate based on a pure software perspective.

If there isn't a clearly identifiable set of "hot blocks" the chances of there being a good hw implementation fit is poor. If there is, it may still be necessary to change the algorithm details to fit but it should be "doable". Whether it is worthwhile depends on the volumes and the performance gains.

Bugs are never RANDOM. Bugs are, by definition, an error (human blunder ... incorrect design, improper code, etc.)