This could be mostly due to the fact that China has been on the rise, economically. So people mostly see the system working, and mostly in their favor. We'll see the real oppression once that changes.
My family operated a business on exactly these razor thin margins. You always live on the razors edge. You're unable to invest into the future, unable to improve your processes, and god forbid there is even a minor disruption. I don't think it's sustainable. We've since faltered, as have our many of our competitors and suppliers.
I want to be able to buy ARM boards like I'm buying ITX PC boards. I don't want a special build of Linux from the SBC OEM, I don't want weird bootloaders, firmware and other embedded-like stuff. I just want an ARM-based PC board for my desktop and server closet (so Ampere stuff is out of the picture unfortunately).
I’m baffled by the current state of Linux for ARM where every board needs a special .dtb/.dts to describe its hardware and, often, peripherals, rather than there being some kind of self-describing plug-and-play-ish system like has been standard on other mainstream architectures since the ’90s.
That's what the Arm SystemReady certification is for. Blame manufacturers for ignoring it. Let's be honest, fixing device trees is usually lot easier than patching an ACPI table. Though, one manufacturer I know ships a DT with nearly 500k lines of if-def'd nodes.
I bought a Radxa Cubie A7A over the weekend because my homelab machine of 5 months threw an SSD and I wanted something to limp along with while I wait for a replacement. I was a bit nervous about the special builds, driver issues, etc but didn't really run into any significant issues (or if I did, Claude took them in stride). And it was a very good test of the Ansible Playbook I'd thrown together over time to rebuild the system from scratch. Was missing a number of small things, but it should be rock solid by the time (if) the other company gets a new drive to me.
It seems they've been stopping short of completion. Once the next gen chip is released, they are done and stop working on fixing issues.
Hopefully, with some time this gets better as it's not like they have to start from scratch with each generation. But it does leave a sour taste in my mouth that they quit so early before finishing.
As someone who mostly gets my retrocomputing kick from running modern software on old RISC hardware, I'll try to explain why that's my thing.
Typically, these venerable beasts come from a more "civilized" era of computing, at least that's how I feel. I wasn't around to actually experience it, coming up when real UNIX™ was already pushed to the fringes.
I'm completely aware that I'm romanticizing, but for me, there is something about these machines that a PC just still can't exactly match. Trying to move a mouse and typing with broken keyboard layouts through a buggy-as-hell IPMI interface that was somehow bolted to a machine that, from it's inception, never was meant to be operated remotely, just feels like a hack. It might get the job done, and it's cheap, but it most certainly isn't elegant. The PC as a whole just isn't elegant.
But these old SUN and IBM machines, they're something different. Tools from professionals, for professionals. With remote management built into the machine from the inception! No stupid GUI with whacky translations in sight!
Of course I'm also fascinated by Solaris, AIX and HP-UX and whatnot. But running modern software on these machines has it's own appeal to me.
My retrocomputing itch is to show off these machines, experience them. And what better way to do that than to actually use them to host modern software, impress people by showing how capable they still are, maybe as a glimpse into a future that never was.
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)
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.
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.
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.
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.
> 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.
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 ;)
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.
I agree with you that "enshittification" has a more specific meaning than just "make worse". Yet, the enshittification of Windows doesn't really follow the mold you described, even though I'd also call it enshittification.
I've only ever read about VMS in an historic context, like Wikipedia articles and blog posts. DEC and VMS are not well known. That's a shame, considering how much influence they had, especially on WinNT.
I don't know about VMS specifically (more people will just know it as the thing the VAX runs), but DEC is very well known to anyone in the computer space.
The PDP series brought us Unix and GNU, and the VAX was the only mainframe capable of competing with IBM. DEC was the largest terminal manufacturer (they made the vt100 and vt220. if you've ever run a terminal emulator, chances are it's emulating one of those or a machine that did). They created CP/M (and by extension DOS). DEC is very well known
Oh, I'm not in any way saying it didn't haha. Every other point still stands. Besides, even if it didn't directly influence DOS it did heavily influence another Microsoft operating system (NT)
Ha, that's very close to my story as well. I had a 166Mhz Pentium and it was all PCI cards and 100mbit by then. That was essentially the start of my career.
Reminds me of a Pentium Pro router put into a datacenter, two 2GB mirrored scsi drives, two nics, happily running a hardened pfSense, ran with zero issues for the better part of a decade.
It just wouldn't die.
The suspicion was because the electricity going to it cleaner than average, in a datacenter, the normal wear and tear on electronics may have been reduced.
Respect was paid at it's decommissioning to convert it into a vm, knowing it's luck, chances are it would still boot up and keep on running.
At work, we needed a PC for a Linux-based Webkiosk the other day. The computer proposed by the colleague who actually orders stuff comes with a Windows license. I said we don't need that. A fruitless, lame effort was made to locate a substitute w/o a Windows license. I renewed my protest, but the feeling that the problem is me was already floating in the air. I gave up. We purchased a Windows license to run Linux. For the umpteenth time.
It's like a Microsoft tax on PCs.
Those OEM licenses do seem quite cheap. I think it was Dell who gave an option for a while. To remove the Windows license and have Ubuntu instead only saved $10.
It was low enough where I think most buyers questioned if it would be worth it to have the license just incase.
reply