Re: On OS reliability

On Tue, 26 Aug 2008 11:07:24 -0700, "Joel Koltner"
<zapwireDASHgroups@xxxxxxxxx> wrote:

"John Larkin" <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1rd8b45n595k5ommqpkimanads8cvl3tkg@xxxxxxxxxx
Possibly, but such "bugs" aren't bugs if nobody triggers them.

That's grammatical sleight-of-hand, but I take your point; we definitely agree
on the major problem.

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++.



I know two superb programmers who do everything fast and right.
Neither has ever studied programming.

Programming is a field where I suspect there's far less correlation between
formal training and quality/productivity than most other fields. I took a
handful of CS classes in college, and they were useful -- I hadn't previously
encountered stuff like sparse matrices, fancy hashing/sorting algorithm,
balanced trees, etc... not to meniton some good consideration of numerical
algorithms for solving differential equations, integrating, etc., although in
practice few people implement those when robust library routines are available
to do so. But I was already a better programmer coming out of high school
than some people I know with 4 year CS degrees today, which is a sad
commentary on CS degrees (since I'm certainly not any sort of genius).

20 Hz pushbutton service (state machine run rate) seems about right,
with no explicit debouncing required. That would keep up with your 5
Hz push rate. Only lunatics interrupt on pushbutton hits.

Agreed 100% -- simpler and more reliable to just sample than to try to get
fancy with edge interrupts.

20Hz does seem fine. I normally sample push buttons at 60Hz, but it's because
I often already need a 60Hz interrupt around anyway to do something else.

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

.

Relevant Pages

  • Re: Why cant/wont Stern make their game code open source?
    ... interrupt handlers, etc, as was done for the assembly libraries, C ... and in the compiler tools and runtime. ... programming in assembly. ... Main game logic, making sound and light sequences, ...
    (rec.games.pinball)
  • Re: Relevance of languages WAS: Re: Date Validation in COBOL
    ... computer programming to the masses was a very bad move and there ... resistance to the new thing (Cobol) most of the older programmers I ... to aid in attitude control & speed control. ... experience gained teaching interrupt driven programming ...
    (comp.lang.cobol)
  • Re: kmalloc without GFP_xxx?
    ... > No, it's just bad programming. ... tries to grab it and starts to spin. ... > GFP_ATOMIC will also be unable to allocate the memory it needs. ... called by both an interrupt and non interrupt code. ...
    (Linux-Kernel)
  • Re: Is Perl open source?
    ... >> Also sprach brian d foy: ... >>> in Perl. ... is programming in an environment with exact and rigorous timing ... milliseconds after event B is detected, ...
    (comp.lang.perl.misc)
  • Re: How to reboot a computer immediately by programming?
    ... How to reboot a computer immediately by programming? ... I figure there is no way to do this in user mode. ... privilege 3, you can't reset ... See Ralph Brown's Interrupt list for more ...
    (comp.lang.asm.x86)