Jo22 wrote on 2026-09-08, 13:53:

Another problem with SSE2 is OS support, things like context-switching (XMM registers). Windows 98SE, for example, was released […]
Show full quote

zapbuzz wrote on 2026-09-08, 06:19:

Doesn't matter what processor, OS or web browser if it doesn't support SSE2 instructions there is no modern web support possible because nobody knows SSE they just copy each others SSE2 code. Think of all the old machines online if someone wrote SSE code. Then there’s older CPU's without SSE good luck with that!
IRC still works but with secure sockets on the rise soon there will be nothing there too.
Old browser compatible web sites are almost non existent because of the abuse.

Another problem with SSE2 is OS support, things like context-switching (XMM registers).
Windows 98SE, for example, was released when x87, MMX, 3DNow! and SSE were known.
SSE2 support is not natively available to such OSes.
Applications would need to take care of it themselves.
Hm, maybe an SSE2 emulation could be integrated at kernel level?
Unofficial Mac OS X distros had SSEx emulators for compatibility reasons.

CPU extensions never used to be relied on but that changed direction just about everything can be coded without these extensions its harder and boomers used to talk about the real CPU value without them. I would imagine there'd be a lot of attention for persons who do it.

nickles rust wrote on 2026-09-08, 13:48:

128MB is probably the minimum for an install, unless you're an expert and can manually tweak settings. I'd say 256MB is probably the minimum to load modern Firefox, and maybe 512MB to actually run a few web sites.

I was testing some new EDO memory modules, so I experimented with this some. At 64MB T2 would not boot. 96MB was the minimum needed to boot/install with the ISO. I'm sure linux experts could trim a bunch of extra stuff and build a smaller kernel, but that is beyond my skill. Also, setting zram above 100% doesn't seem to help. At some point there is no substitute for more RAM. Are there any PCI RAM expansion options? I wonder if the VRAM on a 256MB video card could be used as swap.

zapbuzz wrote on 2026-09-08, 17:32:

Jo22 wrote on 2026-09-08, 13:53:

Another problem with SSE2 is OS support, things like context-switching (XMM registers). Windows 98SE, for example, was released […]
Show full quote

zapbuzz wrote on 2026-09-08, 06:19:

Doesn't matter what processor, OS or web browser if it doesn't support SSE2 instructions there is no modern web support possible because nobody knows SSE they just copy each others SSE2 code. Think of all the old machines online if someone wrote SSE code. Then there’s older CPU's without SSE good luck with that!
IRC still works but with secure sockets on the rise soon there will be nothing there too.
Old browser compatible web sites are almost non existent because of the abuse.

Another problem with SSE2 is OS support, things like context-switching (XMM registers).
Windows 98SE, for example, was released when x87, MMX, 3DNow! and SSE were known.
SSE2 support is not natively available to such OSes.
Applications would need to take care of it themselves.
Hm, maybe an SSE2 emulation could be integrated at kernel level?
Unofficial Mac OS X distros had SSEx emulators for compatibility reasons.

CPU extensions never used to be relied on but that changed direction just about everything can be coded without these extensions its harder and boomers used to talk about the real CPU value without them. I would imagine there'd be a lot of attention for persons who do it.

Hi, sorry, I hope I understand correctly, I had to use Google Translator to understand this sentence.

The problem I see with leaving out SSE2 is the huge overhead that it may causes.

SIMDs like MMX or SSEx do apply relative simple computations to a bunch of data (a matrix).
GPUs with programable shaders do it a similar way. Not sure how to express it in simply words.
Let's think of a Mandelbrot fractal, maybe. Simple formula, big overhead.
Or let's take an bitmap. Change all red pixels into blue ones, etc.

So even if a program can be compiled without SSEx, it's questionable if it's worth it, performance wise.
Especially if there's no other SIMD or co-processor which might assist computating.
Such as MMX, 3DNow!, "SSE1" or x87 (the IIT chip 3C87 has 4x4 matrix calculation).

Let's think of booting Linux on a 4-Bit CPU that runs a simulation of a higher bit CPU.
It can be done, but the booting may take days and an user input on the shell may take 10min which renders the whole undertaking useless.

Edit: What I mean is that a mechanism like SSEx has its purpose in certain applications.
If the host system doesn't natively have the capability to provide said mechanism,
it might not be unwise to implement it by other means.

By using software/hardware emulation, for example.
Because the mechanism is helpful to solve a computational task.

Let's think of a "blitter", for example. Like how it existed on Atari ST on Amiga.
If no physical chip was available, then a "blitter" implemented as software routine will still be faster than if there was no blitter at all.

Jo22 wrote on 2026-09-08, 13:53:

Hi, sorry, I hope I understand correctly, I had to use Google Translator to understand this sentence. […]
Show full quote

Hi, sorry, I hope I understand correctly, I had to use Google Translator to understand this sentence.

The problem I see with leaving out SSE2 is the huge overhead that it may causes.

SIMDs like MMX or SSEx do apply relative simple computations to a bunch of data (a matrix).
GPUs with programable shaders do it a similar way. Not sure how to express it in simply words.
Let's think of a Mandelbrot fractal, maybe. Simple formula, big overhead.
Or let's take an bitmap. Change all red pixels into blue ones, etc.

So even if a program can be compiled without SSEx, it's questionable if it's worth it, performance wise.
Especially if there's no other SIMD or co-processor which might assist computating.
Such as MMX, 3DNow!, "SSE1" or x87 (the IIT chip 3C87 has 4x4 matrix calculation).

Yes, but processors with MMX, 3DNow SSE1 are hitting 30 years old now. I don't think anyone really wants to go back to before that for modern applications, which would be like trying to run Quake without an FPU. So that part I understand, basic SIMD is baked in.

But do we really need to require AVX, SSE3, or even SSE2? That I'm not sure. Sure it'd be slower without a P4 or SSE2 if we don't even meet that level of CPU. But is it really a requirement? Why do we need GPU-like programmable shaders for all our home applications...what's the application really doing to need that level of computation?

It's totally understandable to have heavy computation in the business world. But we far exceeded what people could need at home. That said, I'm not saying forgo the computational power if it's available. It's the question, why bother breaking backwards compatibility anymore? Handling computation can all be the same, transparent to the user, only faster.

I think it's great for people to go back and restore support for old hardware. But I think there will be an age of hardware that it really isn't worth the effort. I'm not sure where, but it might be around the latter half of the nineties or up to the x86_64 era. But I think x86_64 is a bit late, and that late era 32-bit is still fine and should still be supported.

Jo22 wrote on 2026-09-08, 13:53:

Another problem with SSE2 is OS support, things like context-switching (XMM registers).
Windows 98SE, for example, was released when x87, MMX, 3DNow! and SSE were known.
SSE2 support is not natively available to such OSes.

SSE2 did not introduce new architectural registers. If an OS supports SSE(1) then it automatically also supports SSE2 ( and SSE3,4). This is also true for Win98 SE.
The legacy 87 FPU supports both single precision 32-bit and double precision 64-bit floats (and also 80-bit extended precision but it is not relevant here) In javascript all numbers (even integers) are stored as 64-bit doubles.
That's why SSE2 is needed in modern browsers and SSE(1) is not enough. SSE(1) only supports 32-bit single precision floats. 64-bit double precision support was introduced with SSE2. 64-bit double precision floats required by Javascript are supported natively only by x87, SSE2 and AVX, but not by SSE(1) or 3Dnow!.
Emulating 64-bit double support with SSE(1) is even slower than using the x87 FPU natively.

BTW the backward compatibility of binary things in Linux is its worst defect.

Try to install things like VMware 10 or kodi 14 on a current Linux or, viceversa, try to use VMware 26h2 or kodi 21 on ubuntu 10.o4

In theory, given the open source status, everything can be fixed and rebuilt, in practice the chain of requirements make the operation next to impossible, at least for a normal user, but even a skilled coder must invest a lot of time. Even running something in chroot may be complicate, if the target is too old or too new.

In windows, you can run most old SW just installing it, often even in cases where a kernel driver is involved, like the VMware example, and kernel extender and patched dll makes possible to run new SW on old Windows, like recent Vivaldi/Opera/Chromium/FF on Win7/8/8.1, sometimes even XP or Vista

The Solutor wrote on Yesterday, 01:14:

BTW the backward compatibility of binary things in Linux is its worst defect.

I second that. I knew someone who was an avid user of Borland's Kylix.
Kylix was a Linux port of the Delphi development system.

It allowed porting/writing Delphi programs on Linux and compiling them to "EXE" files (binaries) that would run on Linux.
To do this, it contained a part of the Windows environment, even.

Unfortunately, the limited binary compatibility of Linux did put an end to this before it really started. For for Kylix itself and its compilated binaries.
The IDE nolonger runs on modern Linux and the binaries do rely on an older version of QT that is nolonger available/executable in modern distros.

If Kylix was more successful, then more native Linux programs would been available as shrink-wrapped software.
Linux games and business applications could have been installed years after purchase, still.

Long story short, Delphi was the Object Pascal language's equivalent to Visual Basic 5/6 at the time.

More information here: https://en.wikipedia.org/wiki/Borland_Kylix

Jo22 wrote on Today, 00:16:

I second that. I knew someone who was an avid user of Borland's Kylix. Kylix was a Linux port of the Delphi development system. […]
Show full quote

The Solutor wrote on Yesterday, 01:14:

BTW the backward compatibility of binary things in Linux is its worst defect.

I second that. I knew someone who was an avid user of Borland's Kylix.
Kylix was a Linux port of the Delphi development system.

It allowed porting/writing Delphi programs on Linux and compiling them to "EXE" files (binaries) that would run on Linux.
To do this, it contained a part of the Windows environment, even.

Unfortunately, the limited binary compatibility of Linux did put an end to this before it really started. For for Kylix itself and its compilated binaries.
The IDE nolonger runs on modern Linux and the binaries do rely on an older version of QT that is nolonger available/executable in modern distros.

If Kylix was more successful, then more native Linux programs would been available as shrink-wrapped software.
Linux games and business applications could have been installed years after purchase, still.

Long story short, Delphi was the Object Pascal language's equivalent to Visual Basic 5/6 at the time.

More information here: https://en.wikipedia.org/wiki/Borland_Kylix

No explanation needed. The coder I cooperated often is a longtime a exclusive Delphi coder, and used to be a close friend, I helped him many times in the past decades, when he had to migrate his work on a newer Linux, or (like recently happened) when he had to keep an "untouchable", 15 years old installation alive (untouchable because third party mainframe interfaces, because licenses and so on) and he needed to compile things there.

Sadly my friend isn't my friend anymore, he was caught, slowly but steadily, in to the no vax propaganda, which "evolved" in populism and fascism. We had a very unpleasant discussion about that, and a 40+ Y/O friendship (and cooperation) ended in the toiled.

So my Delphi days are likely ended for good 🙁

P.S. Speaking of old QTs I think that Q4OS is one of the few distro worth using today as a main driver The TDE flavour I mean, which is light, modern looking w/o looking like a giant iphone, avaiable in i386 version, and usable as Linux used to be when it was at its best (2005~2009 circa).