For Linux the catch is usually that a recent-ish kernel can be compiled for i586 and some distros have i586 versions, but a lot of applications (browser for example) absolutely require SSE and can’t be compiled without. For a rétro system I’m generally looking for a « full experience ».

What options do you have to compile Linux with to get it to run on a Pentium MMX? I haven't seen anything about that. I know some distros claim to have i586, but I don't believe any work without CMOV and some others that aren't present on many 586es. I did, however, just find AOSC OS/Retro, though, and it seems very interesting!

Also worthy to note that some pages of FreeBSD's homepage still claims that it supports i386, the latest 15.0 version explicitly states in the release notes that support was removed.

Also nice looking laptop 😀

MagefromAntares wrote on 2026-04-30, 17:39:

Also worthy to note that some pages of FreeBSD's homepage still claims that it supports i386, the latest 15.0 version explicitly states in the release notes that support was removed.

True of a great deal of OSes, I've found. At least in FreeBSD's case, they are very clear about the dropping of support before you get too invested in the idea of installing it. A lot of GNU/Linuxes with a i386 branch are in truth i686 branches, and I appreciate the distros that are actually clear about that.

MagefromAntares wrote on 2026-04-30, 17:39:

Also nice looking laptop 😀

Thank you! I treasure it. It's got a genuine OPL3 chip, the display is actually pleasant to play games on, the keyboard is very passable for the form factor and the mouse concept is unmatched in its genius (in my opinion, of course).

shitbird wrote on 2026-04-30, 15:21:

Does X run on 32mb of RAM? I'm told it doesn't - that it needs at least 64mb. I haven't tested this. I'll probably install an Xserver just to see if I can launch some SDL games from the console. If it doesn't work, oh well. There's always W98SE for games! But if you do have >64mb of RAM, then I see no reason why it shouldn't work for you.

Looked at my notes of recent versions. You may be able to start X in 64MB. But to actually do something, like modern apps, you'll need to define what you want to accomplish here. It will be tight, and slow way down if you have to swap.

shitbird wrote:

What options do you have to compile Linux with to get it to run on a Pentium MMX? I haven't seen anything about that. I know some distros claim to have i586, but I don't believe any work without CMOV and some others that aren't present on many 586es.

In the past, CMOV would have been the issue. But most practice today is to treat 32-bit as basically a subset of x86_64, which SSE is preferred, and nobody actually tests real 32-bit only processors back before then. I don't think you'll hit packages using CMOV on a 32-bit, i586 support pretending, distro. It will be SSE, because these package providers broke their packages for this feature a long while back.

shitbird wrote on 2026-04-30, 15:21:

So my strong recommendation is NetBSD. If you find you need help getting it to run, I can help you in this thread, and eventually PMs (my account has too few posts for PMs, I believe). In fact, I would love to help you. Let me know if you have found any others to work recently! And how your NetBSD installs go, if you decide to do so, even if they go great!

Yes, back to what you had said about X11, you can't expect to do much, unless your OS of choice can be slimmed to the hardware properly. On Linux, there are some choices still around, if you are talking about a current release of a distro. But someone really needs to map out which and what they are actually doing about it. I have some information, but I am narrow in my focus, so I can't help point out which ones really work. For example, is the base OS clean for i586 (probably many choices still), but when it comes to all applications, many will simply fall because they don't actually care. So the two issues will be RAM requirements, and then the silly SSE requirement that just randomly shows up without warning.

If your thread is about all current and past options, well there are many fine options then.

I tried "ReactOS" years ago on an Athlon 800, unfortunately I couldn't solve some problems, although the installation was successful, there were several bugs, and in the end I gave up, but maybe it's possible that the version I used was one of the first, and therefore using the latest version, you can get a working installation (?).

How usable these alternative operating system are?

I did try netbsd on my Cyrix 586@120.
And it's was mainly useless. A lot of the package in there "i386" repo don't work because it require SSE2.
Then there package manager take like 30 minutes to install a 50kb package. Bloat everywhere

That Cyrix system have 64MB ram.

I don't consider "modern" operating system to be usable on theses systems.

Why using ReactOS when you can run win95 or 98 (and it run better)?
Why using netbsd when it take forever to install a mini package that does not work?
KolibriOS is the only option that is "usable" on P1 machines, there is not a lot of application of have fun making them yourself.

I personally don't bother, I just use very old OS, that where made when these machine where actual.

Good operating system choices for 586?
Dos, Windows 3.1, 95 and 98, that's it.
You can also find old linux release, for example like slackware 7 or 8, but you are going to be limited to what's come with the CD. Preservation is not a priority for Linux stuff.

As far as Linux goes....

Modern Linux kernels can definitely run on i586 CPUs just fine. Depending on what your needs are, you can get GUIs running on older systems using specialized X servers like the one Tiny Core Linux uses or in some cases you can simplify things further and have the application write directly to the framebuffer, bypassing the need for an X server entirely.

Tiny Core Linux would probably a good start, especially if you're not ready to build your own kernel and related userland. Otherwise if you don't mind getting your hands dirty a bit without having to manually compile everything and/or you want the most optimized setup possible (both size and speed-wise), I recommend using buildroot to create a Linux system. It uses a GUI/TUI to configure the system (same with the kernel itself). I've personally used buildroot to create an optimized, minimal image that I can stick on a Compact Flash card and use with my MMX-based board. While I haven't used that system in awhile, things like Dillo + FLTK and whatnot were working fine without any X server at all. Additionally, if there is software that buildroot does not have built-in support for, creating your own buildroot-compatible package is generally relatively easy.

the3dfxdude wrote on 2026-04-30, 18:41:

Looked at my notes of recent versions. You may be able to start X in 64MB. But to actually do something, like modern apps, you'll need to define what you want to accomplish here. It will be tight, and slow way down if you have to swap.

What is the most interesting thing you're willing to share from your notes? Is it socially appropriate to ask? I should be keeping notes about these kinds of things.

the3dfxdude wrote on 2026-04-30, 18:41:

In the past, CMOV would have been the issue. But most practice today is to treat 32-bit as basically a subset of x86_64, which SSE is preferred, and nobody actually tests real 32-bit only processors back before then. I don't think you'll hit packages using CMOV on a 32-bit, i586 support pretending, distro. It will be SSE, because these package providers broke their packages for this feature a long while back.

All true in my experience.

the3dfxdude wrote on 2026-04-30, 18:41:

Yes, back to what you had said about X11, you can't expect to do much, unless your OS of choice can be slimmed to the hardware properly. On Linux, there are some choices still around, if you are talking about a current release of a distro. But someone really needs to map out which and what they are actually doing about it. I have some information, but I am narrow in my focus, so I can't help point out which ones really work. For example, is the base OS clean for i586 (probably many choices still), but when it comes to all applications, many will simply fall because they don't actually care. So the two issues will be RAM requirements, and then the silly SSE requirement that just randomly shows up without warning.

It would be good to create a chart with this information. I'm interested in creating and publishing one when I have some time. If someone else made an online spreadsheet in the mean time, I would contribute to it.

the3dfxdude wrote on 2026-04-30, 18:41:

If your thread is about all current and past options, well there are many fine options then.

Past, yes, there are a great deal of excellent options. I'm trying to find an entrypoint to AOSC OS/Retro, currently. Have any tips on a relatively trustworthy download? Their site appears to indicate it will become available later, yet there's evidence of its existence on blogs and socials.

PC@LIVE wrote on 2026-04-30, 19:16:

I tried "ReactOS" years ago on an Athlon 800, unfortunately I couldn't solve some problems, although the installation was successful, there were several bugs, and in the end I gave up, but maybe it's possible that the version I used was one of the first, and therefore using the latest version, you can get a working installation (?).

I tried it on something like an Athlon XP, in the vague mid aughts, and have a good impression of it from that time, however I don't recall anything specific that did or did not work. I am interested in knowing if the current release works, I guess. I'll get around to testing and report back in some days.

mscdex wrote on 2026-05-01, 00:27:

Modern Linux kernels can definitely run on i586 CPUs just fine. Depending on what your needs are, you can get GUIs running on older systems using specialized X servers like the one Tiny Core Linux uses or in some cases you can simplify things further and have the application write directly to the framebuffer, bypassing the need for an X server entirely.

I have used OpenBSD with applications that write directly the framebuffer this way on a C2D, so without necessity, but found it fun. I've been planning on using the Libretto this way with NetBSD and am looking forward to the challenge.

mscdex wrote on 2026-05-01, 00:27:

Tiny Core Linux would probably a good start, especially if you're not ready to build your own kernel and related userland. Otherwise if you don't mind getting your hands dirty a bit without having to manually compile everything and/or you want the most optimized setup possible (both size and speed-wise), I recommend using buildroot to create a Linux system. It uses a GUI/TUI to configure the system (same with the kernel itself). I've personally used buildroot to create an optimized, minimal image that I can stick on a Compact Flash card and use with my MMX-based board. While I haven't used that system in awhile, things like Dillo + FLTK and whatnot were working fine without any X server at all. Additionally, if there is software that buildroot does not have built-in support for, creating your own buildroot-compatible package is generally relatively easy.

It looks like the AOSC OS/Retro I've been looking at is built with buildroot, so maybe I will take your advice and use it myself. It seems like it will be an excellent learning experience.

Rav wrote on 2026-05-01, 00:04:

I did try netbsd on my Cyrix 586@120.
And it's was mainly useless. A lot of the package in there "i386" repo don't work because it require SSE2.
Then there package manager take like 30 minutes to install a 50kb package. Bloat everywhere

If you use old pkg_add instead of pkgin on such a system, and use ftp rather than http for the PKG_PATH, it's far more usable and won't take 30 minutes per package. I suspect it's because an http PKG_PATH downloads the entire list and does wildcard expansion locally (which needs more RAM than is on the machine), while ftp does it at the server side and works fine. Obviously, the applications for it are quite limited, aside from having up-to-date ssh, irc with modern TLS, links for very limited web browsing with modern TLS, etc.

shitbird wrote on 2026-05-01, 01:38:

I tried it on something like an Athlon XP, in the vague mid aughts, and have a good impression of it from that time, however I d […]
Show full quote

PC@LIVE wrote on 2026-04-30, 19:16:

I tried "ReactOS" years ago on an Athlon 800, unfortunately I couldn't solve some problems, although the installation was successful, there were several bugs, and in the end I gave up, but maybe it's possible that the version I used was one of the first, and therefore using the latest version, you can get a working installation (?).

I tried it on something like an Athlon XP, in the vague mid aughts, and have a good impression of it from that time, however I don't recall anything specific that did or did not work. I am interested in knowing if the current release works, I guess. I'll get around to testing and report back in some days.

mscdex wrote on 2026-05-01, 00:27:

Modern Linux kernels can definitely run on i586 CPUs just fine. Depending on what your needs are, you can get GUIs running on older systems using specialized X servers like the one Tiny Core Linux uses or in some cases you can simplify things further and have the application write directly to the framebuffer, bypassing the need for an X server entirely.

I have used OpenBSD with applications that write directly the framebuffer this way on a C2D, so without necessity, but found it fun. I've been planning on using the Libretto this way with NetBSD and am looking forward to the challenge.

mscdex wrote on 2026-05-01, 00:27:

Tiny Core Linux would probably a good start, especially if you're not ready to build your own kernel and related userland. Otherwise if you don't mind getting your hands dirty a bit without having to manually compile everything and/or you want the most optimized setup possible (both size and speed-wise), I recommend using buildroot to create a Linux system. It uses a GUI/TUI to configure the system (same with the kernel itself). I've personally used buildroot to create an optimized, minimal image that I can stick on a Compact Flash card and use with my MMX-based board. While I haven't used that system in awhile, things like Dillo + FLTK and whatnot were working fine without any X server at all. Additionally, if there is software that buildroot does not have built-in support for, creating your own buildroot-compatible package is generally relatively easy.

It looks like the AOSC OS/Retro I've been looking at is built with buildroot, so maybe I will take your advice and use it myself. It seems like it will be an excellent learning experience.

Well I'm interested, if you can get a working installation, I would like to know what type of PC you use (configuration), and especially if you can tell me which version to use, if it was possible where I can find it, I don't know if the one I tried was a beta version, so not definitive, I remember that I was suggested to install it, to check if there was any working problems, and in fact there were at least some.

PC@LIVE wrote on 2026-05-01, 13:34:

Well I'm interested, if you can get a working installation, I would like to know what type of PC you use (configuration), and especially if you can tell me which version to use, if it was possible where I can find it, I don't know if the one I tried was a beta version, so not definitive, I remember that I was suggested to install it, to check if there was any working problems, and in fact there were at least some.

I've been trying for the past day to get it to install on a Libretto FF1100V without any success. Mostly the problem seems to be that the installer cannot see PCMCIA or USB attached disks, and even though I have to channels on my CF to IDE adapter, when you try to use the second, it causes... issues. I have tried various methods to get it to install from the same disk it is on, but it freezes up usually when checking the partition the installation files are on. That's as far as I've got on it for now.

shitbird wrote on 2026-04-30, 15:21:

Linux? I believe no current GNU/Linux works. Maybe on some later 586s, but not on any I own. Even the ones that claim to do not. You will find if you look hard enough that they all require instructions that were added late in i586's run.

Install Gentoo. Start with the i486 stage 3 tarballs in a QEMU VM, use the correct -march and -mtune options for the CPU you're targeting, compile a kernel with sys-kernel/gentoo-sources that's both targeting your CPU and also tailored to the motherboard(s) regarding PATA drivers as you ideally want to have a kernel that using ~8MB of RAM (the sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin ebuilds targets i686 and also has way too much stuff enabled, so you can only use Cyrix MII CPUs). Current mainline Mesa works fine, but unless you're using an Aladdin V or a MVP3 (most likely with a 686B southbridge, I'm not sure about what PCI standard is supported by 586B) mobo you're limited to only using a FX 5200.

DEAT wrote on 2026-05-03, 00:07:

Install Gentoo. Start with the i486 stage 3 tarballs in a QEMU VM, use the correct -march and -mtune options for the CPU you're targeting, compile a kernel with sys-kernel/gentoo-sources that's both targeting your CPU and also tailored to the motherboard(s) regarding PATA drivers as you ideally want to have a kernel that using ~8MB of RAM (the sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin ebuilds targets i686 and also has way too much stuff enabled, so you can only use Cyrix MII CPUs). Current mainline Mesa works fine, but unless you're using an Aladdin V or a MVP3 (most likely with a 686B southbridge, I'm not sure about what PCI standard is supported by 586B) mobo you're limited to only using a FX 5200.

Thank you for the suggestion. I'd written Gentoo off some time ago due to some frustration with the difficulty of keeping Systemd out of my system when attempting to use only OpenRC. I otherwise liked the concept. I do find some of the setup required odd, like having to install a utility for merging config files generated by package management, when it seems like that should be something managed by package management and not myself, manually. But I'll give it another shot and see if it better suits my needs here. Thank you for the pointers, as well, I'm sure I'll find them useful.

shitbird wrote on 2026-05-01, 01:22:

the3dfxdude wrote on 2026-04-30, 18:41:

Looked at my notes of recent versions. You may be able to start X in 64MB. But to actually do something, like modern apps, you'll need to define what you want to accomplish here. It will be tight, and slow way down if you have to swap.

What is the most interesting thing you're willing to share from your notes? Is it socially appropriate to ask? I should be keeping notes about these kinds of things.

What I've done is try to study where we came from, specifically tracking Slackware Linux, since it has about the longest documented continuous use as a 32-bit OS out of anyone since it's 1.0 release, even edging out Windows NT's first public release, and arguably the BSD forks a little bit as well. I was collecting the information to study what made Slackware a success, and found interesting potentially breaking transitions. Some things I can more clearly describe, but perhaps not everything. I don't have time to test a whole lot, so I'll just leave out the stuff that I don't have an answer on, even if it is somewhat relevant.

So when it comes to things like being able to run X11, there were two sort-of seismic changes that I note that appear pretty clear. It appears that the major revision of XFree86 4.x bloated up memory usage from XFree86 3.x. The next thing seems to be that the transition from Linux Kernel 2.4 to 2.6 also was another event that could increase memory usage. Perhaps some of it could be artifacts of how the maintainer decided to deploy things, but I suspect there were alot of changes (much more code) in those builds.

Why could that be important? Well given that these releases come much later after the days that the pentium 1 was mainstream, it is unlikely what followed those releases provide much benefit to running on a pentium 1. PCI video cards probably did not get much attention. Kernel development probably didn't benefit any other of the old PCs drivers as well by that point. So why would you want to run a post-2000 distro on i586, given that when they began to bloat up, 64MB could be quite limiting after that point?

Now there are distros out there that for today claim to be built to support i586. I'm not sure that they are really doing that... I for one would want to really compare that on the specific pieces of software and drivers that if they changed and are being built better or worse. The nice thing about Slackware is that it really actually does not change very often, and if it does, it is because upstream did it -- it hardly will customize things from what upstream does with the software. So I guess it does kind of make it a good control case if you want to find when things really start to break.

This topic is one I am interested in too.

(Aside: Not trying to be offensive, but is the bird endian little? 😁)

The 2.4->2.6 transition was a major one yes, that tended to weigh down on pentiums.

You might find this read interesting: http://vega.pgw.jp/~kabe/linux/c7-i586/pentium.html - running CentOS 7 on a i586. Bottom line is emulating the SSE* family of instructions in the kernel (so that userland binaries that use them can function) is possible on a plain 586 without MMX. If the cpu has MMX some of the SSE opcodes don't trap and cannot be emulated.

This is also an interesting page about X driver breakage over time: https://flaterco.com/kb/video/X-regressions.html

st31276a wrote on Today, 10:19:

You might find this read interesting: http://vega.pgw.jp/~kabe/linux/c7-i586/pentium.html - running CentOS 7 on a i586. Bottom line is emulating the SSE* family of instructions in the kernel (so that userland binaries that use them can function) is possible on a plain 586 without MMX. If the cpu has MMX some of the SSE opcodes don't trap and cannot be emulated.

So yes, that is technically interesting. It could be helpful, but I think only the really recent AMD x86_64 that don't have sse2/sse3, being fast enough, could benefit from something like this.

But at the same time, as the page indicates, just recompiling solves the issue and in the case mentioned for the packages, like glibc, recompiling that could provide a substantial speed improvement for i586. Which again, just goes to show, that it is very unlikely that any distro out there is building specifically for i586.

st31276a wrote on Today, 10:19:

This is also an interesting page about X driver breakage over time: https://flaterco.com/kb/video/X-regressions.html

Yes, I've followed that guy on that for many many years, and it's a tragedy what's happened. There are some guys working on a fork for the drivers, to bring some of them back.

So it's entirely possible to start fixing all the issues and bring back good support. But if you wanted to do this for recent stuff, it's alot of work to base it on any mainstream distro, so you might as well start from scratch and make something work well on i586, or a known good variant, but which? There may be some hope with T2.