[TUHS] Unix stories
lm at mcvoy.com
Sun Jan 1 15:00:11 AEST 2017
> Stephen Bourne after some time wrote a cron job that checked whether an
> update in a binary also resulted in an updated man page and otherwise
> removed the binary. This is why these programs have man pages.
I want to tell a story about working at Sun. I feel like I've sent this
but I can't find it in my outbox. If it's a repeat chalk it up to old
I wanted to work there, they were the Bell Labs of the day, or as close
as you could get.
I got hired as a contractor through Lachman (anyone remember them?) to do
POSIX conformance in SunOS (the 4.x stuff, not that Solaris crap that I
As such, I was frequently the last guy to touch any file in the kernel,
my fingerprints were everywhere. So when there was a panic, it was
frequently laid at my doorstep.
So here is how I got a pager and learned about source management.
Sun had two guys, who will remain nameless, but they were known as
"the SCSI twins". These guys decided, based on feedback that "people
can interrupt sun install", to go into the SCSI tape driver and disable
SIGINT, in the driver. The kernel model doesn't allow for drivers messing
with your signal mask so on exit, sometimes, we would get a "panic: psig".
Somehow, I sure was because of the POSIX stuff, I ended up debugging this
panic. It had nothing to with me, I'm not a driver person (I've written
a few but I pretty much suck at them), but it landed in my lap.
Once I figured it out (which was not easy, you had to hit ^C to trigger it
so unless you did that, and who does that during an install) I tracked down
the code to SCSI twins.
No problem, everyone makes mistakes. Oh, wait. Over the next few months
I'm tracking down more problems, that were blamed on me since I'm all over
the kernel, but came from the twins.
Suns integration machines were argon, radon, and krypton. I wrote
scripts, awk I think, that watched every update to the tree on all
of those machines and if anything came from the SCSI twins the script
That way I could go build and test that kernel and get ahead of the bugs.
If I could fix up their bugs before the rest of the team saw it then I
wouldn't get blamed for them.
I wish I could have figured out something like Steve did that would have
made them not screw up so much but this was the next best thing. I actually
got bad reviews because of their crap. My boss at the time, Eli Lamb, just
said "you are in kadb too much".
More information about the TUHS