Linux on a 486SX
ocawesome101.github.io
ocawesome101.github.io
Between the implosion of Fry's, and Radio Shack not quite lasting long enough to capitalize on the maker movement, it's pretty well online ordering or nothing.
I've often wondered why those places disappeared but then you remember nobody really builds PCs or other electronic stuff except as a hobby and most people are running laptops that can't be upgraded anyway.
Thing with Linux as much as I used it over the years, it's still no where near as compatible with weird hardware as windows. Windows just seems to be able to handle whatever hardware I've ever thrown at it.
Other than the very first few versions of Windows, the true reality is most probably the opposite: whatever hardware you've thrown at it is able to handle Windows. That is, both the hardware and its software (driver, firmware) have been designed for and tested with Windows.
I miss Dirt Cheap Drives.
In some ways that was some of the best times for Linux on the desktop in my experience. Windows and Mac were such an unreliable mess at that point that Linux seemed very competitive at the time. A lot of the advanced hardware integration in Win/Mac hadn’t happened yet and Linux was very lean and mean and reliable. Both KDE and Gnome appeared in 1997 IIRC and the desktop was decent even if some apps weren’t as good.
My machine was 75mhz, 12MB RAM, 250mb HDD, 800x600 color LCD that had poor refresh. It got me through most of my college CS programming projects, though I eventually built a Linux tower too. X was good on that laptop the first few years but was really slow by 1998.
Hard not to be nostalgic over that time but things are so much better now. One command with AWS CLI and I can spin up a Linux box in 3 seconds today.
I remember carefully selecting modems. Most of the PCI modems in popular retail shops were winmodems so getting one that used the ISA bus was the first step. But even that was not the safest bet. Online shopping was nothing like it is today, so getting a known good model was more difficult.
Google images on those external ones from USR took me back a bit though. I didn't have one of those but I saw them.
It was easier to do that back then than now... :)
Oh,and a grad student friend of mine warned me in 93... "That Web stuff is addictive"... so I avoided it for another 3-6 months and stuck to FTP sites and a bit of gopher/WAIS. :)
Prophetic declaration of the day. I'm envisioning a great hacker t-shirt: "That Web stuff is addictive... stick to FTP (a friend, 1993)"
The title of this post really had me do a double-take. "Of course Linux can run on a 486, it's fine on a 386". Just need the right version.
I just spent most of my free time in the last week trying to get the Rust compiler to run on a K6-2/500. Had a bunch of trouble because one of the newer x86 extensions (CET) chose opcodes which decode as NOPs, and therefore are considered safe to include in binaries for older processors. Unfortunately, they're only NOPs on i686 or newer, and the K6s are i586 processors. It was mind-numbing because even if you explicitly tell the compiler to output/optimize for a K6-2 or Pentium (-march=k6-2 or -march=pentium) it's still outputting the CET opcodes. You have to pass -fcf-protection=none for them to go away. Super annoying.
Benchmarking it was pretty funny, because compiling one of my personal Rust projects is about 500 times slower than my TR 1950X desktop. Compiles in 7.5 seconds on the Threadripper but takes 67 minutes on the K6-2/500. So much progress in 18 years (K6-2/500 in 1999 -> TR 1950X (4 GHz) in 2017).
I remember compiling Linux kernel on my Cyrix 486SX 25MHz (the one with a disabled-by-default L1 cache!) and it took an hour. Got it on a P60 and it was like 5 minutes.
Good times.
I also managed to get someone on utsource to sell me a tray of 386EX33s for like $2 a pop so eventually I can make some 386 systems. I managed to track down a few of the old IIT 3C87 FPUs that had the hardware matrix by vector multiply so I'm going to try to make some 3D renderer if I ever get around to putting it together.
I like retrocomputing too, but more virtually: https://jexer.sourceforge.io/evolution.html
I wanted to make a cycle-accurate 286 system once, just because it was such an interesting architecture. Protected mode, but 16 bit, and 16MB max RAM, but with segment:offset addressing. What's not to love about all of that?
Admittedly I didn't live through that time period, but reading about them, they are quite interesting. It seems that the main reason they were considered "brain-dead" was because you couldn't run 8086 native and 286 native software at the same time, and backwards compatibility and interoperability started becoming something people considered very important.
Interesting enough that I went and bought a static core 286 (the 25 MHz Harris one) to play with. Since it's a static core I can run it at whatever frequency I want, even if that is only a few hertz.
https://imgur.com/gallery/LKAh7fB https://gist.github.com/teknoman117/342b43db8b79652c1c91e78e...
Things to keep me sane during the pandemic isolation :)
I remember compiling Linux kernel on my AMD 386SX 25MHz. It took a whole day (only awake hours, so probably around 12 hours or so).
I still hang on to a PIII based Dell Latitude laptop from 2001 and Slackware -current runs surprisingly well on it (along with BeOS 5.1 from my original disc, QNX RTOS, OpenBSD, NetBSD, and a few other obscure OSes from its generation to today).
But then (U)EFI is an OS in itself, you can boot Linux directly from it, no bootloader needed:
Would it be accurate to describe (U)EFI as being like MS-DOS (i.e. single-tasking), but running in protected mode?
CFLAGS="-I/opt/libressl/include" LDFLAGS="-L/opt/libressl/lib" ./configure; make; sudo make install.
Try gopher://hngopher.com first and later, https://news.ycombinator.comHad running Linux as web proxy until about 2001. Interesting to see that what was quite normal at that time has become to a topic of interest again.
We managed to switch the users to an older server so they could continue to work. But it first seemed the HDD and files got corrupted and unrecoverable by disk tools from Netware. We thought of using a commercial recovery service, but this would cause delay and cost $$$$.
So I removed the disks from Netware, fired up a Linux PC, connected the HDD to the Adaptec SCSI (Luckily install prior for a CD drive). The file system was not mountable, but something like dd /dev/sdb1 |strings „JJJJMMDD“ discovered lots of salvage records.
This literally saved my ass and the company.
The print server has been replaced by an usb-2-centronics dongle recently to reduce energy consumption further.
An about 25 year old laser printer running almost flawlessly mechanically, with latest MacOS and Windows 10 OS, supporting PCL6 and PS is a thing. He is on the 3rd toner cartridge (at least 5 years old).
Only needed for rare cases of government mandated written docs like passenger locator forms.
Paper transport has been unreliable almost from day 1 based on dried up rolls and paper.
Downloading it was a nightmare though - there was no TCP/IP connection available to me, but I could use the X.25 based email package. Attachments weren't an option, but you could send email to a file hosting server (funet.fi perhaps?) and it would split the requested file into as many 64K UUEncoded emails as necessary in response. Reassembling them (given the clunky email software I was working with) was a distressingly manual process... but I eventually collated and copied the complete set of disk images to floppy and installed them on the lavish 100Mb drive of the 486.
I also recall the fun (?) of trying to get the right monitor sync info for the XConfig file, and the superstition of `sync; sync; sync` that must have been long out-dated by the time I actually got my hands on this machine (though I did play around a little with the boot/root disk combination before that).
I sometimes feel a pang of nostalgia for all that stuff, but you can take my 1Gb network connection, hidpi monitor, and multi-terrabyte SSDs out of my cold dead hands!
Edit: Afterthought to give a little extra perspective on when this was: Around the same time I signed up for a Beta program on some Microsoft projects and boxed copies (with manuals) of "Daytona" and "Chicago" turned up in the post!
I later learned that I could add "floppy=thinkpad" to the kernel command line to enable support for the floppy drive in my ThinkPad model. Then I got brave and resized my DOS partition, using one of the free DOS-based partitioning tools available at the time, so I could have a real Linux filesystem.
Loadlin.exe wasn't even a terrible solution for dual boot with win9x... I may have even scripted a boot menu in autoexec.bat at some point.
Booting from CDROM was still iffy and some BIOS might not like some drives and so on as i recall.
1. The aforementioned IDE/CF adapter. It helps that it's a dumb PCB since CF speaks IDE natively.
2. A Gotek Floppy Emulator (With the FlashFloppy firmware)
3. A SCSI2SD SCSI emulator.
A handy tool for booting from CD-ROM is Plop Boot Manager. It installs itself into the boot sector and can manage booting from the disk, CD drive, and even USB on systems that ordinarily wouldn't support it. Plus it can be configured to have a cool animated starfield background...
Some cards, usually marketed as "industrial", support a fixed disk mode. This one for example can be set to fixed disk by grounding pin 9 (output enable):
[PDF] https://resources.winsystems.com/datasheets/cflash-g-xxxm-i-...
The 36 pin connector on the sound card was probably a scsi cd-rom connector. They used to put them with the sound card :)
The InfoMagic discs:
Disc 1: Slackware 3.0 and Debian 0.93R6
Disc 2: Red Hat 3.0.3 for x86
Disc 3: Archive of sunsite.unc.edu
Disc 4: GNU source archive from prep.ai.mit.edu
Disc 5: Archive of tsx-11.mit.edu
Disc 6: Demos and Red Hat 2.1 for Alpha
Wonder how long it took to sequentially scan 4GB of RAM
One thing I would recommend that I didn't see mentioned is switching to the SLOB allocator in the kernel. It's more space efficient than SLUB or SLAB, but it is slower if you have a large amount of memory. (It's hidden unless you set CONFIG_EXPERT).
The main problem I bumped into for minifying a modern Linux kernel is that so much of the modern Linux ecosystem (systemd, OpenRC, runit, etc.) expects a lot of the networking stack to be enabled, along with cgroups, namespaces, etc. In order to get a minimal Gentoo i486 image to boot, I needed to turn a lot of things on in the tinyconfig kernel. Admittedly, it's hard to image a Linux/Unix system without some form of networking :)
Ran like a breeze on a 486DX-33 with 4 MB RAM, xeyes and all. Hard to be believe at the time - a UNIX in my own room! :-O
Of course it can, 486s were common in Linux's early heyday. During my senior year of high school and freshman year of college ('97-'99) I ran Debian Slink on an IBM 486SX. X ran a little slow on it so I used it in console only mode. I mostly used it to do compsci homework. Before I settled on Debian full-time (still using it to this day) I used Red Hat, I think v5 (the original numbering, before RHEL). And before that probably Slackware on floppies. I eventually got an AMD K6-2 which ran a lot faster...
Of course, this article is about running modern Linux, but Debian Slink is still there to download and install and I'm sure it works just peachy.
The section on configuring the kernel really gives me nostalgia as I used to build my own kernels back then, something I haven't done in years.
Here's an eBay item that is pretty much exactly what I had back then: https://www.ebay.com/itm/294597619526?mkevt=1&mkcid=1&mkrid=...
Yeach. Yeah I had two of those when they were being thrown out. MCA was a really horrible bus between ISA and PCI. I recall it not wanting to boot unless you installed drivers for all your cards into the BIOS, or something.
So not only did your OS need drivers, but your BIOS did too.
I may misremember.
Compiling the kernel was basically an overnight operation, IIRC.
But yeah they were built like tanks. Even the power switch felt like you were turning the power back on to the fences in Jurassic Park.
Yeah, I think you do.
> Compiling the kernel was basically an overnight operation, IIRC.
When, on what hardware?
Who was it who complained that compiling the Linux kernel took always ten minutes, regardless of hardware generation? (which of course, isn't entirely true: https://openbenchmarking.org/test/pts/build-linux-kernel)
For me, on my 386DX 24Mhz with 8MiB RAM, it took about 20minutes late 92 or early 93 (SLS 1.0 -- pre 1.0 kernel), but I had to leave X11, as otherwise the machine would swap to death.
That may have been later, thus with a bigger kernel, but on older hardware. It was probably 386 and 486s back in maybe 2.0/2.2 kernel era.
For the specific machines in question I set up some sort of RAID0 between two 60MB SCSI drives, to be able to do much.
The reason I say overnight may be because I had machines with specs like that a few years later than you. I did run Linux to some extent since 1994 (Slackware 2.0), but don't remember the kernel compiling aspects of back then at all.
But it's a good point. I was not comparing latest kernel to latest (or even necessarily median) kernel at the time.
I still maintain that after hardware ages a little, Linux (and perhaps other free operating systems and distros) are the only way to give a soul to the machine.
Unfortunately it didn't survive a household clear out 3 years later, and that fills me with regret. Maybe I could've been trying my own projects on it now. I always liked the relative simplicity of the OS and hardware.
http://www.dimlight.org/number9/dmesg_index.html
The TRI-m in that list was a 486, although not modern linux. http://www.dimlight.org/number9/dmesg/dmesg_machz.html
Many people ran Windows on 486. But it was Windows 3.x, or 95 at most. If you managed to get Windows 10 to boot on one, surely that would be a feat...
Six months later I finally got the disks for X11. My mind was blown. Real multitasking - not like DESQView or OS/2.
i ran a bbs on os2 and it was awesome. IBM sponsored my bbs as teamos2 and mustang software sent me wildcat! and i was the first bbs in houston to offer linux for download
I think I gave up after a day, tried Fedora, and settled on Ubuntu.
That same job taught me networking (Novell) and got me programming business apps in MS Access and the rest is history.
Unfortunately I didn't get into Linux until much later.
Teenage me had no idea what to do with it. I didn't know how to compile a Linux kernel from source, at that point I'd barely started moving beyond Atmel AVRs and Java on LEGO Mindstorms.
It's nice to see recent kernel versions can still work fairly well on this hardware. I don't recall my boot times being as long as 50s though. But who knows, it was a different time and expectations were different. I had 8MB RAM and a 200MB drive and while there was swapping, I was able to run X11, emacs, Mosaic (and then Netscape), and some terminals without serious problems.
I feel like it's almost required to page through the various dialogs in menuconfig periodically in order to stay current when it comes to modern hardware and how it can interact with the OS.
https://www.tindie.com/products/theoldnet/rs232-serial-wifi-...
In short, these let you connect to WiFi using AT commands, and then "dial" IP addresses and hostnames as if they were phone numbers.
With Linux, you can just keep your ancient programs and hardware running on modern systems.
I remember when X switched from monolithic server to modular one. I had to buy new GPU because S3 I had wasn't supported. I have bought ATI.
I didn't have much reason to bother with X11. Text utilities always got the job done, including for web browsing needs thanks to links.
Laughs in Tanenbaum
Since the days of 386 support, the kernel has only become much more modular and portable. It quite possibly supports more platforms and CPU architectures and families than any other OS ever written. Almost certainly true if you restrict it to a multitasking >= 32-bit OS with memory protection and virtual memory.
Many architectures and ports that have been removed or not merged were not due to being technically incapable of supporting the port but due to lack of interest.
If 486 support goes away, it won't be because suddenly the code has become unmaintainable after being fine for 25 years since the 486 was obsolete! It will because nobody has a machine to test or verify fixes on (although QEMU has improved this situation), or because the kernel or the x86 port decides to adopt a new feature which is more difficult to implement older CPUs (cmpxchg8b as another post mentioned).
So your post is totally misinformed and wrong. So with that out of the way here is the 386 removal changeset:
http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html
Net code change is fewer than 400 lines removed, much of it in boilerplate and config options changing.
"This tree removes ancient-386-CPUs support [which] plagued us with extra work whenever we wanted to change SMP primitives, for years."
There were no issues with spaghetti. They can and did maintain it just fine for many years. It was not removed to fix a bug, it was removed for lack of interest in doing the work to maintain it. And the extra work was not because of spaghetti it was because it required independent implementations of SMP primitives. As you see from the code change it was likely not the code itself that was the headache, but the testing of it.
> Technically Linux could once upon a time run on a 386
That's a really strange way to phrase it too. A 386 was the very first thing Linux was written to run on. There is no "technically" about it.