I love my oxy/acetylene torch. Somehow, I have never gotten one before. Now I am the death-god that can shoot 6000F flame and burn through all that stands before me!
A quarter placed in a graphite dish turns into a little puddle almost instantly.
For cost reasons I may switch to propane/oxygen – acetylene is pretty expensive and the measly 5500F temperature you get from propane/oxygen is probably sufficient. (There is an acetylene gas shortage for the forseeable future thanks to a 2011 explosion at the US’ only acetylene production plant in Kentucky [acn])
When I said I was getting one my neighbor Bob, of the wise advice, said “sometimes when people accidentally cut their hoses, they die while they’re trying to close the regulators. Just grab the hose and crimp it, then close the regulators.”
Oh lord, he’s got a torch. Keep him away from the pitchforks or there won’t be a vampire for miles around.
I’ve never seen Bob, never met Bob, but anyone who gives advice like that is 100% solid in my book.
Seriously, your and his asides about systems failure are a highlight of FtB for me – two different approaches, mutual respect for safety, it works.
Also, this reminds me of some of my own work in a laboratory – with equipment that piped gases into a chamber in fairly precise and fun ways. One day I asked about adding acetylene to the mix and got back a prompt ‘No chance!’ – there was a lot of pure copper around, you see, and acetylene and copper form some pretty explosive metal salts together.
Combine that with liquid oxygen, magnetically levitating pumps and regular 450 amp discharges and you would have gotten some, uh, impressively energetic failures.
Yeahhhh, I spent a long, long time just reading operations and safety manuals back when I worked with that.
Bob is of course correct, but doesn’t it make you wonder? He must have been right every time, because that’s an experiment you don’t get to repeat if you miss the first time.
Awesome!Torches are so cool. As far as Bob’s advice goes, how about this: don’t cut the hose. I mean, as long as you’re taking advice. :-D
“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.”
Oooooooh, serious fun! Don’t go killing yourself.
Dad taught me how to use an O\A torch as a teenager. My Lesson One was to always watch the hoses. Keep the gear and hoses behind myself at all times. That way the hoses never get under the flame in the first place. :)
kestrel@#3:
As far as Bob’s advice goes, how about this: don’t cut the hose. I mean, as long as you’re taking advice. :-D
That is “Plan A” – “Plan B” is crimping the hoses and “Plan C” is run like hell.
Reginald Selkirk@#2:
He must have been right every time, because that’s an experiment you don’t get to repeat if you miss the first time.
I asked him, once, what was the scariest thing that happened, and he said there was a time when the whole high wall of a coal mine collapsed onto his caterpillar – he thought something was funny and put it in reverse as fast as he could, and the rocks stopped right at the top of the dozer blade. I would say he had good instincts for safety.
jrkrideau@#1:
Keep him away from the pitchforks or there won’t be a vampire for miles around.
Ever since I became a master vampire, I haven’t had problems.
Bridget Wolfe@#6:
My Lesson One was to always watch the hoses.
Yup.
Problem with those torches is you can’t make a hose that can resist those torches.
aquietvoice@#2:
Seriously, your and his asides about systems failure are a highlight of FtB for me – two different approaches, mutual respect for safety, it works.
Thank you.
You’ll be thrilled, then, to know that later this week I am interviewing Tom Van Vleck for my column at TechTarget. Tom is an amazing character and I have been an admirer of his work since I was a wet behind the ears systems administrator at Gould in 1987. Read this and you’ll see what I mean: http://multicians.org/thvv/dark.html
The page the comic is from contains excellent, widely ignored advice.
cvoinescu@#13:
The page the comic is from contains excellent, widely ignored advice.
Van Vleck is a fountain of good advice.
When I was first starting out as a product programmer, I took a lot of his maxims seriously. Fortunately, I was also under the tutelage of an old school programmer who convinced me that I should write test harnesses for major functions, and full self-checking test-racks for modules. Consequently, I learned to think in terms of how to specify what a module looked like when it was correctly functioning, and to generate an alarm in the event that it was not.
I will note that, unfortunately, security-critical programming is a very different process from most production/application coding. Its got the same requirements for reliability overall but you cannot have the software “fail gently” because that usually means the software falls back to defaults if it gets bad inputs. For security critical stuff you need to, basically, never do that. A good example of this problem is the incessant litany of security flaws that involve cryptographic protocols which can be fooled into negotiating a null cipher/cleartext mode, or to drop back to a lower-quality encryption for backward compatibility reasons. Getting a programmer to re-think how systems operate and fail is a fascinating task.
Back when I managed teams of programmers, “read everything Tom Van Vleck wrote” was an assignment, as well as a job interview question.
Defaults, fall-backs and soft failures are bad in regular programming, not only in security-critical stuff. Some people are aware of this. Python, for example, has the right idea — “explicit is better than implicit” — but its library is not uniform in adherence to that principle (to put it mildly).
I am still contemplating the density of wisdom in those few rules. I can name examples of violations not only of whole rules, but of their smaller clauses too. “Without making that an end in itself” made me chuckle and sigh at the same time. I think everything that calls itself a “methodology” violates at least two of them (although not the same ones).
cvoinescu@#15:
I am still contemplating the density of wisdom in those few rules.
If you wish to be inspired, read his story “it can be done.”
I am inspired.
It sounds familiar, though — it’s my favorite approach to programming. Except for writing code by hand – last time I did that I was 16, because I did not have full-time access to a computer. State diagrams, tables, data structures, communication diagrams, pseudocode, actual code for the key bits: those are pencil and paper, yes. (And eraser. I can’t write code without a good eraser.) I’ve never been able to do it for larger subsystems, so I am suitably impressed by the story, of course, but I’ve had several smaller libraries work perfectly from the first try. Feels good.