we used to 'joke' that you would have to set one of fire to get it to stop responding to a ping. even then, might take a while.

Been there done that? Circa 2001 I had a customer with a rack of 220R's and Clariion storage arrays. I was paged about an app outage and saw (IIRC) "environmental errors" in the logs about the temperature of the machines. One of the Clariion's, in the same rack, had caught fire which brought the database / app down but the 220R's kept chugging along. Unsurprisingly this was quickly followed a call from the NOC that the fire suppression kicking in and that I should down get there ASAP.

Oh wow.

I have plenty of fond memories about the stability of Spark Stations but none as fun as that.

Thanks for sharing.

I did once have a Bullfrog TSS that survived a literal explosion. They certainly don’t build hardware like they used to.

That was the joke my VMS colleagues said to us the younger unix hotshots.

My recollection is anyone doing massive concurrency per server (at the time over 10k connections) was moving to using a BSD because of kqueue.

We even went through a phase of email on OpenBSD before being bought by a company that insisted on Exchange.

Linux didn’t seem to pull decisively ahead of the BSDs until multicore x86 became mainstream. Up until then it always seemed flaky.

SunOS had /dev/poll, which the kqueue paper cited as prior art. https://web.archive.org/web/20000823103627/http://docs.sun.c... via citation 4 in https://people.freebsd.org/~jlemon/papers/kqueue.pdf

For a brief moment before epoll came along it looked like Linux would get /dev/poll.[1] In fact, IIRC, epoll started as a /dev/poll implementation. I don't think Sun's /dev/poll ever saw much uptake because, aside from the limitations mentioned the kqueue paper, the pace of software development was much more rapid and dynamic in the FOSS and web worlds, and the center of gravity had already shifted to BSD and Linux.

For better and worse, Linux developers seemed more inclined toward adopting extensions from SysV and SunOS/Solaris than from the contemporary BSDs.

[1] See, e.g., https://lwn.net/2001/0712/a/devpoll.php3

And then Solaris added EventPorts in reaction to kqueue. Arguably they should have just adopted kqueue. Would be much better if both Solaris and Linux had just adopted kqueue. Having that unified accross the 3 major server OSs would have been helpful.

> Sparc is not for performance, particularly for benchmarks

It certainly was from 2011 to 2019: https://en.wikipedia.org/wiki/K_computer

> obviously you need to write your own software

Kerberos ran fine for me on cast-off SPARCstation 10(?) which was well obsolete at the time.