On OS reliability

The modular kernel. It has its advantages, but the overhead to manage all those pieces can be a bitch. Context switching between kernel and user space is also expensive.

I guess you'd have to analyze each application to see if it was better to have some defective driver thrashing in the background, quietly crashing and reloading, or just to throw up a BSOD* and call attention to the problem.

I used it as an adjective, so it's...

freak adjective [before noun] very unusual or unexpected:

John

One of my temperature controllers has the capability to destroy a $40K probe inside a superconductive magnet. And that started happening one day. Great consternation around the world.

My fix was to add a hidden blackbox recorder that saves the last 1200 serial-input characters, from the system console, in battery-backed RAM. Sure enough, the C++ program in the console was occasionally telling me to go to 400C, which I dutifully did. You can indeed write spaghetti code in C++.

Some of the non-snappy membrane switches can bounce for 10's of milliseconds, so might see a double-hit if sampled too fast. Snap switches rarely bounce for more than a few milliseconds.

John

Haha... great story! :-)

I wrote this maybe 15 years ago for a programmer that I hired for a project:

(Note: I only write poetry when irate, bored, or frustrated).

If only they would pay my time, to write the docs in verse and rhyme.

Incidentally, the programmer in question spent what I now guess was 20 times as many billable hours debugging as writing code. He referred to it as testing, but it really was debugging. Code -> build -> load -> run -> crash -> debug -> repeat At the time, I never suspected there might be a better way. Thanks for the clues.

"Memory leaks" are the result of bad programming (eg: memory management).

It is likelely that the person who wrote the description was a tester, not a programmer. Also, immediately sit down and fix the problem

That depends on the function. Up-arrow should happen as close to instantly as possible. Function keys should take a deliberate action, so a delay might be appropriate. There is a button on the side of my cellphone that toggles speakerphone mode, and it takes somewhere in the range of 0.3 to 0.5 seconds to register. I like it that way; I really don't want to amplitude modulate the audio at a 5 Hz rate...

It is likelely that the person who wrote the description was a tester, not a programmer. Also, "immediately sit down and fix the problem" works well when you are first writig the code, but if the bug has been in the code base long enough that others have written code that references it, a more formal approach might be better.

That depends on the function. Up-arrow should happen as close to instantly as possible. Function keys should take a deliberate action, so a delay might be appropriate. There is a button on the side of my cellphone that toggles speakerphone mode, and it takes somewhere in the range of 0.3 to 0.5 seconds to register. I like it that way; I really don't want to amplitude modulate the audio at a 5 Hz rate...

These were up and down keys. The system did have the typical "long press" events as well (which I believe required a half-second press... that time delay struck me as a bit long but still within the bounds of "reasonable").

the system

Workers should be cognizant of the possible dangers (and causes) *FIRST*. Then, the safety interlocks be identified and described what they do AND DO *NOT* DO, with emphasis that they be used AND *ACTIVELY* MONITERED. There is a true story of a knowledgeable tech used all safety interlocks, pulled fuses, locked main power switches off, and then went on top to work on the radar dish...and got cooked (and died)- because some *** defeated all safeties, cut the locks, installed the fuses and fired up the radar. So, that is why i added that the safeties be *ACTIVELY* monitored (maybe an armed guard with sawed-off shotgun?).

The RADAR site I worked at used dead bolts to lock the gates, and to secure interlocks, so it would have taken a cutting torch to bypass. What you are describing wasn't an accident, it was murder.

Absolutely! The *** was given a DD and turned over to the authorities on that charge.

What was that old aphorism, "Anything worth doing is worth doing well." But only the very best like "putting themselves out of a job". I have some old code currently is daily use; it has been 20 years and has had not required any maintenance. Totally stable specifications. Not all that big, maybe 500 function points.

It's easy to distinguish between "real" programmers and everyone else. Ask someone to count to ten. If they start counting with one, they're normal. If they start at zero, they're a "real" programmer.

Really, I was told there are 10 kinds of poeple, those that know programming and those that don't!

The problem with that joke is that non-programmers won't understand it. If they can't do the math, real programmers can't spell "programmer", which should make a good substitute question.

Real programmers also don't eat quiche:

Sno-o-o-o-ort! Good list!

...Jim Thompson