Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

On Systems and Strangeness

by samizdat (Vicar)
on Aug 25, 2005 at 13:28 UTC ( [id://486546]=perlmeditation: print w/replies, xml ) Need Help??

I've spent much of my career dealing with systems on many levels in the embedded world. UNIX m/f talking to PC's talking to strings of embedded controllers, etc.

Recently, I was downvoted (appending is not done) for saying that something as mundane as a munged (minged? ;)) #! line might make otherwise sane code do something stupid. I thought I'd explain my rationale and the experience that led me to it. I agree that my suggestion was unlikely, and I did so qualify it, but it's not impossible.

Today's computer systems consist of many layers of software sitting on top of many layers of firmware and hardware logic. Further, this software has often been subjected to upgrading processes, none of which are ever guaranteed to have been complete or completed without error. There are often multiple variants of libraries resident on systems, and they are often all required by something or another. The legendary Linux kernel and (g)libc snafus come to mind here, but the problem is far more widespread than that. At work here (Sandia Labs), we have production systems running old code that we can't afford to take offline, and some of them still have non-Solaris SunOS. Who's to say what Perls are installed there, and where they are? More importantly, who's going to know what bugs are still buried in their kernels from waaay back then?

I've seen enough strangeness happening (even without considering inimical code from evil empires like M$) not to discount any possibility. 90% of all electronics-related problems are caused by cables and connectors, but, of the rest, more are due to mistaken assumptions than bugs.

Replies are listed 'Best First'.
Re: On Systems and Strangeness
by derby (Abbot) on Aug 25, 2005 at 14:00 UTC

    I ++ that node. I think we can all agree with your explanation above but I can understand why it was --. You said the *only* thing you saw was the funky she-bang line when I think you might have meant the *only other* thing you saw was the funky she-bang. I wrote off the bad she-bang as a typo and thought the more important issue was the non-checking of the open call.

    -derby
      Well, to my mind, the OP's code was correct, even if not complete with all error checking. You're absolutely right that his|her error checking leaves him|her wide open for assuptions about the underlying system state to cause a failure. Making my point. :D
Re: On Systems and Strangeness
by hakkr (Chaplain) on Aug 25, 2005 at 14:02 UTC
    yes assumptions are the mother of all bugs, thats why you should have a test suite that asserts all your assumptions about the system.

    If an assertion fails then you don't have a sane environment for your code.

    'which perl, locate perl, some find commands and perl -V' should help you see what perls are installed where. As for perl kernal bugs the only thing to do is upgrade or carefully peruse every Perl patch.
      True as well, although I was referring to bugs buried in the UNIX kernel and filesystem code. The OP's problem was that his >> was acting like > and that's likely deeper than Perl.
      yes assumptions are the mother of all bugs, thats why you should have a test suite that asserts all your assumptions about the system.

      How could you possibly write such a system? How do you verify that first test in the suite is passed, something has changed in the system to make that test no longer pass? And if you can't, what good is your test? You can't avoid making assumptions; you can just add complexity by making meta-assumptions until you run out of time/money. Sometimes this is cost effective; but often it's not.

      If an assertion fails then you don't have a sane environment for your code.

      This is frequently true for production systems. It's often your job to deal with an imperfect world, and a dynamic and often flawed testing or production environment. Sometimes, this means accepting sub-optimal results as a consequence of a sub-optimal testing budget, on a probablistic basis designed to maximimize profits for the industry, given departmental budget contrainst.

      We don't always live or work in a perfect world. Quite the opposite, most of the time. We have to do what we can within the time and budget constraints we are offered; that's all we can legally do.

        yes maybe testing all assumptions about the system is a little broad.

        I think I meant in this case perl/module/binary version assumptions.

        Try putting the test suite in your development budget/schedule instead of testing, it should usually be part of development anyway

Re: On Systems and Strangeness
by Anonymous Monk on Aug 25, 2005 at 19:36 UTC
    90% of all electronics-related problems are caused by cables and connectors, but, of the rest, more are due to mistaken assumptions than bugs.

    Isn't this something of a false dichotomy? Bugs are always due to one or more mistaken assumptions. At a minimum, they're the result of mistakenly thinking "this code is correct". :-) --
    Ytrew

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://486546]
Approved by holli
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-29 10:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found