[spijdar]

I felt this way in my late teens and early 20, when I spent a lot of time e.g. finding a pipeline for playing YouTube videos on sun4m machines running NetBSD.

I'm now in my late 20s, and my impression is these machines were largely always hacked together piles of garbage, they had just cost a lot more ;)

There were highs of elegance, yeah. The OpenBoot PROMs introduced with the SPARCstation were marvelously functional and beautifully elegant, especially compared to the previous pre-boot environment. But when you look under the cover, you find a million patches of duck tape, like Sun having to force their compilers to avoid using the o7 register due to speculative instruction prefetching sometimes triggering DMA activity on a peripheral card and causing an unintended side effect. This was due to one buggy CPU (the 80 MHz Weitek upgrade CPU for the SS2), but the bug required changes for all sun4c kernels (at an minimum).

Or how the ILOM on newer SPARC servers are just embedded PowerPC chips running RedHat Linux. At least in the late 2000s :)

At the end of the day, NetBSD on my SPARCstation 2 is cool, super cool even -- there's even EXA acceleration support for the CG6 framebuffers in X!

But ultimate NetBSD/sparc is basically identical to NetBSD on my raspberry pi. I can even run the big endian port if I want a BE system!

On the other hand, running a contemporary OS like SunOS 4, or something exotic like Sprite, gives a very different experience. And honestly, these 80s OSes themselves feel more "elegant" in a hacker sort of way.

(I'd agree that most mid/late 90s+ Unix systems mostly just feel like worse versions of modern Linux/Unix, though)

[avhception]

While individual implementations may or may not have had horrible bugs or consisted entirely of hacks, I think just carrying forward the expectation of having a proper, all-powerful text prompt into the firmware that can easily be made accessible remotely would have been a real boon to the foundations of server hardware. With time, the bugs could have been fixed and the hacks replaced with proper implementations.

[spijdar]

I think this boils down to a cost problem more than an engineering or cultural one. If you look at the original Itanium machines of the early 2000s, they had BMCs like the Sun ones, and they ran EFI as the base firmware, often with no graphical head. Pure serial!

There's no reason you couldn't build a solid, headless PC-compatible architecture based around EFI. It would just... cost money. Even in the retrocomputing stuff you see the same thing happen. Older VAXes had very rich boot PROMs, but by the time you get to models like the 4000 "Very Low Cost", most functionality was stripped out of the PROM to save space and cost.

[segmondy]

same here, I feel all sorts of sadness since this sort of thing use to bring so much joy but now bring a bunch of yawn. i had sun 3s, earlier sparcs, IPX, IPC, decstation, HPs, SGI and you are right, it took getting older to feel the same. but then again, even modern systems software/hardware are surprisingly hacked together piles of garbage too. it all depends on how you define garbage.

[hparadiz]

I got paid by my university to decommission and throw out a bunch of Sun SPARC rack mounts. Like anything else these machines had to be maintained except due to licensing issues they were always susceptible to exploits, were woefully out of date, and were missing major utilities that existed on Linux by this point due to again licensing issues. And because no one bothered to compile for SPARC pretty much installing anything modern required very slowly compiling everything and hoping you didn't get a weird SPARC only machine error in the compiler which actually happened quite a bit. Even worse I remember at the time my gaming laptop that I used for university coding work was already much faster. The one benefit from the experience was that it really drove home just how hard it is to maintain a cpu arch that isn't popular.

[stinkbeetle]

> There were highs of elegance, yeah. The OpenBoot PROMs introduced with the SPARCstation were marvelously functional and beautifully elegant, especially compared to the previous pre-boot environment. But when you look under the cover, you find a million patches of duck tape, like Sun having to force their compilers to avoid using the o7 register due to speculative instruction prefetching sometimes triggering DMA activity on a peripheral card and causing an unintended side effect. This was due to one buggy CPU (the 80 MHz Weitek upgrade CPU for the SS2), but the bug required changes for all sun4c kernels (at an minimum).

Do not look at ACPI, boot firmware, or the CPU microcode, instruction match "patch" modes, chicken bits, or any of the other horrible hacks required for modern CPUs to run :)

CPUs have more or less always operated under the same constraint as any other engineering project, which is to optimize the cost/value of the thing. That means at some point you bake the silicon that is guaranteed to have known and unknown bugs in it. CPUs sit in a different place in this spectrum than software does, thanks to the relative ease of software patching, but underneath it's bugs and hacks. So they do certainly get far stronger testing and verification treatment before shipping. But there is enormous infrastructure baked into the silicon purely for finding and fixing bugs that inevitably escape that QA. Everything from leaving a sprinkling of spare gates and latches around the chip so you can use them for post-synthesis or metal-layer fixes, fallbacks and and fixups everywhere. There are watchdogs or hang timers or state condition checks in the core and SMP fabric so if some known or unknown condition causes deadlocks or livelocks, you can hit it with a hammer and go to some slow mode (e.g., single-issue, non-speculative, in-order) for a while to clear it up.

CPUs in embedded or certain vertically integrated shops did have the issue that fixing bugs in the compiler or their applications was viable so you would get a bunch of craziness leaking out (there are or were patches in binutils to pad code so it doesn't put branch instructions at the end of a page, things like that, for more than one CPU). ARM and x86 CPUs today would absolutely ship with bugs like this if backward compatibility were not extremely important and if the hardware vendors had more control over the software stack.

There were a bunch of serious user-visible speculative execution bugs in ~all modern high performance CPUs within the last decade (yes, AMD, ARM Ltd, and I believe Apple all had speculative execution security side channels too). Occasional issues with user and supervisor level can be seen in errata documents too, often they can be fixed with "firmware" (which means microcode, chicken bits, etc), but they still exist.

[spijdar]

True! That was my point exactly, that (for the most part) the old workstations weren't special or magical relative to PC hardware, when you pull old DEC and Sun hardware manuals on Bitsavers or whatever they're chalk full of ink from manual corrections and errata. Old Ethernet NICs are especially bad... :D

This isn't to disparage them, either. GP admits they are romanticizing, I'm just offering my own perspective on it. When I call old stuff "hacked together piles of garbage", it was meant with the loving connotation of someone who's home office has a MicroVAX 3400, Sun 4/75, DEC PWS 433a, and a POWER9 workstation piled in the corner, all on a KVM switch. I love tinkering on these old machines, but I think it's healthy to remember they're not beacons of 80s/90s perfection, but products that were made and sold under time/cost constraints, as you said.

... Though, I will say, the MicroVAX was running from the late 80s until about 2018 in a university environment, and its HDDs still report no errors. That is pretty remarkable ;)

[avhception]

To add a bit of context: I'm not even romanticizing the actual implementations, which may or may not have had horrible bugs and errata. Rather, it's the abstract concept, the ability to have a reasonable expectation that, for example, the firmware would be completely operable, scriptable and so on and so forth from a serial line. Stuff like this.