Hacker News new | past | comments | ask | show | jobs | submit login

Sparc is not for performance, particularly for benchmarks. BTW, even Linux lose benchmarks to windows often times.

We used a Sparc Ultra 10 for a Authentication server in 2000, it supports concurrent 100K users without any issue, obviously you need to write your own software, but the server is super stable. And yes, we use cheap x86 + Linux for all sorts of thing from 1996 and it was quite faster but you can not trust it the same way as a Sparc.




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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: