Goodbye RedHat.

Posted on by
My boxed copy from 1997

I’ve been using RedHat Linux in various forms for the last 26 years or so. I started back in 1997 with a boxed copy of RedHat Linux 4.1. It wasn’t the first Linux distro I tried, but it was the first one that I really liked. I kept buying boxed copies of it through version 6.1, around the time when the first release of RHEL dropped. (it’s hard to believe that was 23 years ago) You see, back in the olden days internet speeds the typical person could get were largely via modem and

far too slow to grab entire CD images in a reasonable time. Buying a boxed copy every time a new version was released both supported the company and allowed me to get a fresh set of installation media in my hands right away.

So why am I quitting RedHat you might ask? The recent news of RedHat Enterprise Linux essentially going closed source, (yes, I realize this is debatable) was the straw that finally broke the camel’s back. However, I’ve had this urge many times in the past due to similarly bad decisions by the company and I’m finally just done. So where did this start? For me, it started with the last release of RedHat Linux 9 being merged into the Fedora project. (as you’ll see, what’s old is new again) When RHEL was initially released to the public, it was based entirely on RHL with some add-ons that were exclusive to RHEL. As time went on, RedHat realized that some of their customers weren’t buying RHEL and were just sticking to RHL, often just grabbing the ISOs for free.

RedHat didn’t like this and felt the existence of RHL as an upstream distribution was potentially hurting their sales of RHEL and decided to kill it in favor of a faster-paced and shorter lived variant that would become Fedora. At the time, I thought this was great… newer packages, more frequent releases… what’s not to like? What I didn’t know was the pain that would come from sticking with the free version. Initially, the short support cycles weren’t all that bad. You could in-place upgrade from one Fedora version to the next and be back up and running in short order. This didn’t last though, and soon it was better to just wipe and reinstall from scratch. This difficulty wasn’t just some random experience, it was by design to drive IT pros into the RHEL fold.

For hobbyists or IT pros wanting to practice with a stable RHL/RHEL style OS there was no longer anything available until CentOS arrived on the scene in 2004. (there were others as well, but CentOS was so close to RHEL that you could use it as a drop-in replacement for RHEL for nearly any application.) This server ran on that distro for the last 15 years and all was good until RedHat, again frustrated by something they perceived as taking business away from RHEL drove them to change the game again. RedHat planned and executed a coup that would see ownership of CentOS transferred to RedHat which laid the ground work to kill off CentOS as it existed at the time. In December of 2020, RedHat announced that CentOS would be discontinued in 2021 in favor of a new offering called CentOS Stream. This new distribution wouldn’t be a replacement for CentOS, but would rather become a Fedora-like upstream for RHEL. (fast release cycle, but unstable) Basically, Fedora is the bleeding edge, new stuff is constantly migrated from Fedora to Stream after testing and a stable version/snapshot is occasionally cut from Stream and used to build the next point-release of RHEL.

Modification of graphic from ServeTheHome

The final nail in the coffin was a blog post on 6/21/2023 by Mike McGrath, VP of Core Platforms at RedHat announcing that “CentOS Stream will now be the sole repository for public RHEL-related source code releases.” What this means is that access to the actual source code for RHEL is now locked behind a RedHat subscription. This is a direct attempt to kill off successor distributions to CentOS such as Rocky Linux and AlmaLinux. Rocky Linux did make a statement on their blog that they, “[remain] confident in [their] ability to continue as a bug-for-bug compatible and freely available alternative to Red Hat Enterprise Linux (RHEL), despite changes in accessibility.” However, the writing is on the wall. RedHat intends to stamp out copycats of RHEL for good. In a follow-up blog post, Mike tries to explain that RedHat isn’t evil and then rails against what he sees as essentially freeloaders stating, “I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.” Nobody is profiting from the re-packaging, but I’m pretty sure this is a veiled reference to Oracle. (Oracle doesn’t charge for their RHEL derived distribution, but they do sell service and support)

What’s actually disingenuous is claiming that everyone who wants to use your source code without paying is a freeloader. Let’s not forget that RedHat wouldn’t exist today without the free contributions of thousands of open source coders over the last 3 decades. RedHat stands on the backs of these members of the open source community who receive little to no compensation yet feels aggrieved by those who want to use code they have the rights to under the GPL for free. The backporting and all the support effort Mike references in his post are self-inflicted and the very reason companies pay to get their product. Let’s be clear, those who use “rebuilder” distros like CentOS of old, Rocky, or Alma are not RedHat’s customers. If they had a need for RedHat’s support services and could afford it, they would be, but they’re not.

As for myself, I’ve been hanging onto this RHEL compatible distro and it’s ecosystem mostly out of nostalgia, experience and let’s be honest… laziness. When the initial shutdown of CentOS was announced, I created a replacement VM based on Debian/Ubuntu and planned to migrate, but never did. Instead I stayed on CentOS until the updates dried up and then migrated to Rocky. (big thanks to the Rocky Linux team for making that a mostly painless process) However, with this latest chapter unfolding I don’t see the point in staying in the RHEL/RedHat ecosystem. (at least not for anything I care about) RedHat’s senior leadership has made it clear that they are going to make it as hard as possible for anyone to duplicate RHEL going forward. I feel bad for Rocky and Alma, but I’m done being a victim of the chaos caused by RedHat’s periodic jealousy. Today, I built a fresh Debian 12 VM and migrated this blog to it. I already feel better, my packages are more up to date, but equally stable and it didn’t even take that long. Farewell RedHat, I hope this path works out for you, (I honestly do) but if it doesn’t you’ll know exactly why that is.

(mostly) 4th Gen x86 Shootout!

Posted on by

Having recently restored my old 486SLC board, I was curious how it stacked up against other 486s of the era. I actually have a fairly decent collection of chips from this time period and a few motherboards that accept them.

For the majority of this test, I used a PerComp branded board made by PC Chips, (model M912) that has a fairly broad range of support for these CPUs and is based on the PC Chips “Chip 16″/”Chip 18” chipset. The board is configured with 256KB of L2 cache, 16MB of 32-pin SIMM memory and supports 7x 16-bit ISA expansion slots, 3 of which support 32-bit VLB cards.

stock photo of an unlabeled M912 board

One funny thing about this board is the branding on the chipset. At the time PC Chips didn’t have a great reputation for performance. In an attempt to boost their sales, they often placed stickers on their chips with the model numbers of other more popular chipsets.

fake chipset branding
actual chipset branding

Alright, enough of the history… let’s get into the testing! The chips I selected for the test were several Intel CPUs, a couple of Cyrix CPUs and a single AMD CPU. These were as follows: i486SX-25 (overclocked to 33Mhz), i486DX-33, i486DX2-66, Cx486DX2-66, Am486DX4-100, Cx5x86-100 (overclocked to 120Mhz)

stock photo of the chip I have. Mine has a fan bolted onto the heatsink as I’ve overclocked it to 120Mhz

The five 486 CPUs shown above all contain 8k of L1 cache on-die. They were all tested on the same motherboard mentioned above, which was configured with 256k of L2 cache.

I’ve also included the 486SLC numbers from a previous test. The SLC and the 5×86 aren’t a good direct comparison since the motherboard and configurations are quite different. Unfortunately, I managed to kill the Cyrix 486DX2-66 when I tested it the second time and wasn’t able to get cache and system performance numbers, but an image with the last screen it produced is included below.

What was most interesting to me were the results for the Intel SX and DX chips clocked at 33Mhz. All of the results from these 2 chips were identical except for the performance index. (which is lower on the SX as it lacks an FPU) What this tells me is that unlike the 3rd generation, Intel’s 4th generation SX chips were fully 32-bit externally. The i386SX was 16-bit externally and was dramatically slower as a result. Likewise the Cyrix 486SLC also suffered in this test due to its 16-bit external bus. I suspect Intel’s 4th generation SX chips were simply lower binned parts from the DX production line that had defects in the FPU section of the die. Simply disabling the FPU by cutting/burning the traces between it and the CPU section of the die would allow these otherwise defective chips to be sold, albeit as a lower-end model.

TX486SLC-e w/IIT FPU
i486SX25 @33Mhz
i486DX-33
i486DX2-66
Cx486DX2-66
Am486DX4-100
Cx5x86-100 @120Mhz

It’s a shame the Cyrix DX2-66 gave up the ghost during the test. However, it’s not a chip I was likely to put back into use in any of these systems. What data I did get from it confirmed my recollection of the CPU. It was slightly faster than the Intel DX2-66 in integer ops, but was a bit slower in floating point due to a weaker FPU design.

Resurrecting the past

Posted on by

Lately I’ve been digging into more of my retro collection to repair and preserve some of these systems and components. One of the systems I’ve put a fair amount of time into was the first motherboard I bought. It was a humble system, even by the standards of the day, barely exceeding the performance of the previous generation, but it was really the beginning… the first system I assembled from (mostly) new parts. My first 2 computers were an 8088 (XT) I cobbled together from spare parts and an 80286 that I got from a friend and some additional used parts from the 8088 and elsewhere. The system board I chose to create this new computer from was an Eteq 486SLC at 33Mhz. It was powered by a Texas Instruments TX486SLC/E-33MAB CPU, a licensed copy of the Cyrix 486SLC. This was a low power variant of the Cyrix 486 CPU intended for use in mobile or embedded applications. (like Intel’s SX compared with the DX 486 CPUs, or DLC in the case of Cyrix) In a desktop the 486SLC was competent, but was not fast by any means, only performing slightly faster than a i386DX CPU at 40Mhz. (mostly due to the fact that the Cyrix/TI design had a small amount of onboard cache memory, but also close because the SLC/SX CPUs only have a 16-bit external bus which slows down I/O)

Eteq 486SLC board with corrosion, before cleaning
corrosion visible on the board before cleaning

Like many systems of the era, this board was equipped with a Varta NiMH rechargeable battery soldered permanently to the board. Also like many of these systems, over time the battery leaked and began corroding the conductive metals near the area. I had previously removed the battery and scrubbed some of these parts

with IPA and a toothbrush, but it hadn’t gotten a lot of the corrosion off. I decided to see if a bath in white vinegar would stop the corrosion and sure enough, it neutralized and broke it up. I repeated this several times until there were few if any remains of the corrosion visible. I had also removed the power and keyboard connectors from the board and given them a vinegar bath as well. (I had also removed all of the socketed chips and checked them for corrosion ahead of time) With the corrosion eliminated, I washed the board with tap water in the sink and set it up to dry for several days. (I also helped it along by turning it upside down and spraying it with compressed air)

Once I was sure the board was completely dry, I placed all of the chips back in their sockets and soldered the keyboard and power connectors back onto the board. While I had to fiddle with the hardware, I was able to get the system to POST after a few tries. The next problem I ran into was

corrosion removed from the board

the BIOS and it’s lack of support for large drives. I had purchased some IDE to CF adapters to allow me to boot from a Compact Flash card, but the 8GB cards I selected were too large. I’d recently seen a video about another retro enthusiast who had been able to use a network card with a custom boot ROM that might be able to solve this issue. While restoring my old 286, I built a complete 8-bit ISA controller using this same software (XTIDE) and thought I’d give this a try. I also happened to have the original EPROM for the Eteq 486SLC (which I’d replaced because it got corrupted… that’s a story for another time) and was able to successfully erase and re-write the chip with the XTIDE firmware. This got me further, but the system still seems to have some translation issues with the Winbond multi-io card I’m using. Eventually, I imaged the card with one I’d taken of an identical card from another system and that got it booting.

Eteq 486SLC with ALU and RAM populated

So, time to run some benchmarks and see what the system can do! As I suspected though, the system was pretty modest. As I mentioned earlier, the system only performed a little better than a i386-DX40. This isn’t so bad considering the design. You have to remember, at the time small jumps in processor frequency provided measurable performance increases. While the Cyrix-designed chip was a little slower and had an I/O bus half the size of 386, it had a more efficient design and onboard cache that helped it perform much better.

Also helping this system is a math co-processor made by IIT, the XC87SLC-33. This chip was effectively a recycled 80387 compatible design IIT had been pumping out since the 386 days. It’s performance is modest, but it was cheap and that made it attractive as a poor college

speedsys results

student. The Norton SpeedSys benchmark shown above demonstrates just how modest this system was. Looking at some similar reports for i486-DX266 CPUs, this is a little less than half the speed in just about every area. Because I’m curious, I’ll probably drop my Cyrix 486DX2-66 into a compatible motherboard and see how they compare. This system isn’t fast and it’s not all that exciting, but I’m glad I saved it from rotting away for good. Perhaps one of these days I’ll find a baby AT case and build it up into a complete system again.