[Off-Topic] Rant: Most distro system requirements are ridiculous

[vincentkanin]

Many of you have probably heard about openSUSE and RHEL's switch to the x86-64-v2 requirement, but they still state that an "2,0 GHz Dual-core 64-bit CPU" is the requirement. That's false advertising!, they are all talking about bits but even though the damn laptop have 64 bits AND an Dual-core 2,4GHz CPU it STILL DOES NOT COUNT! It's like they are just making up excuses for being an asshole! what were they thinking?!?!?!?!
Debian has no plans for this right?

[arzgi]

Debian supports many architectures, I am not sure if it is the last distro supporting i386, but many distros have already abandoned that.

From that point, I can recommend Debian, also from many other points

[vincentkanin]

Okay. I'll stick to Debian. I'm already on Debian, that's great because i can stay.

[steve_v]

Debian supports many architectures, I am not sure if it is the last distro supporting i386, but many distros have already abandoned that.

This is also "false adversising", because "i386" WRT Debian actually means i686 with CMOV. Debian hasn't supported actual 386 CPUs for quite some time, and the last release to run on a 586 was Jessie.

[vincentkanin]

Debian supports many architectures, I am not sure if it is the last distro supporting i386, but many distros have already abandoned that.

This is also "false adversising", because "i386" WRT Debian actually means i686 with CMOV. Debian hasn't supported actual 386 CPUs for quite some time, and the last release to run on a 586 was Jessie.

That is so stupid! Why not just call it "i686" if it can't run on an actual 80386

[steve_v]

Why not just call it "i686" if it can't run on an actual 80386

Probably because changing the name of the architecture target is a PITA from an organisational/tooling POV.

Personally I find the recent change to -march=i686 rather annoying, as there are still machines around that would be quite capable of running current (CLI) Debian were it compiled for i486 or i586. The Geode and Vortex86 lines of industrial CPUs spring to mind (many of which are clocked at 600+MHz and mostly i686 compatible, but lack CMOV), as does the K6-2 on my desk right now.

[vincentkanin]

Why not just call it "i686" if it can't run on an actual 80386

Probably because changing the name of the architecture target is a PITA from an organisational/tooling POV.

Personally I find the recent change to -march=i686 rather annoying, as there are still machines around that would be quite capable of running current (CLI) Debian were it compiled for i486 or i586. The Geode and Vortex86 lines of industrial CPUs spring to mind (many of which are clocked at 600+MHz and mostly i686 compatible, but lack CMOV), as does the K6-2 on my desk right now.

What distro can be run on a system without the CMOV instruction like the one you're using?

[RedGreen925]

Why not just call it "i686" if it can't run on an actual 80386

Probably because changing the name of the architecture target is a PITA from an organisational/tooling POV.

Personally I find the recent change to -march=i686 rather annoying, as there are still machines around that would be quite capable of running current (CLI) Debian were it compiled for i486 or i586. The Geode and Vortex86 lines of industrial CPUs spring to mind (many of which are clocked at 600+MHz and mostly i686 compatible, but lack CMOV), as does the K6-2 on my desk right now.

What distro can be run on a system without the CMOV instruction like the one you're using?

Give this page a look. In the case of the k6-2 mentioned here that is twenty year old tech expecting a modern OS to cater to that niche for a normal use is a little much. For the embedded stuff mentioned they can pay someone for supporting the by now works for them but obsolete hardware for most others. That is the way those things have always worked, the vendors provide support for the hardware sold until declared end of life, then time for customer to upgrade.

https://www.vogons.org/viewtopic.php?t=79549

[steve_v]

What distro can be run on a system without the CMOV instruction like the one you're using?

Slackware, of course

expecting a modern OS to cater to that niche for a normal use is a little much.

Perhaps, but that's not the point here. The arch is called "i386", so one would expect it to run on an i386. Likewise when it's "x86_64" and the system requirements say "a 64-bit processor", one would expect it to run on an Athlon64.
One wouldn't have to hunt around in obscure threads on Vogons to find distros that will run, if the architecture names and published system requirements were accurate.

[RedGreen925]

What distro can be run on a system without the CMOV instruction like the one you're using?

Slackware, of course

expecting a modern OS to cater to that niche for a normal use is a little much.

Perhaps, but that's not the point here. The arch is called "i386", so one would expect it to run on an i386. Likewise when it's "x86_64" and the system requirements say "a 64-bit processor", one would expect it to run on an Athlon64.
One wouldn't have to hunt around in obscure threads on Vogons to find distros that will run, if the architecture names and published system requirements were accurate.

Whatever the arch is based on what the distributions decided to call it when it was set ages ago. The i386 was decided for 32bit intel based instruction set processors, the x86_64 for the AMD extensions to that previous 32bit instruction set that ran 64bit mode instructions. As opposed to the ia64 instruction set of Intel which got that name due to it being different arch to the i386, often referred to as the Itanic for its quick sinking so soon after launch. As with all things in the open source world, computers in general, people are just to god damn lazy to even bother to read the clearly listed instructions on all of the distribution's web sites telling you what they support. That might have them actually learn a thing or two about the computer they use and not be spoon fed the information. That website was found with the second or third hit in Google search "debian i586 processor support" again not for the too god damn lazy who would rather rant away with BS on how they are so hard done by due to fact no one is going to change a setting decided well over a decade ago, causing all that disruption, to make them happy in their foolishness.

[CwF]

Kernel names have been fairly accurate. I still use some i686. Actually there isn't a single change up to i686 and there isn't a single change since - that stays in the simplistic group of kernel compatibility. There are a continuous string of changes, mostly additions, that the base system may ignore, but will impact many programs. Many programs have multiple pathways for execution depending of what is specifically present. As time goes on this code duplication will eventually be simplified, leaving only the most modern techniques. So booting an old system is one thing, running a particular program may be an independent consideration.

Looking at the feature set of a modern processor there may be a dozen acronyms that all are new ways to do old things. These new ways are hardware based solutions to accelerate former software routines. The old routines will be purged from the code base eventually. So really, any 'minimum spec' is bogus without considering the ultimate use case will be. Such specs at most refer to a program, not a system.

[vincentkanin]

What distro can be run on a system without the CMOV instruction like the one you're using?

Slackware, of course

expecting a modern OS to cater to that niche for a normal use is a little much.

Perhaps, but that's not the point here. The arch is called "i386", so one would expect it to run on an i386. Likewise when it's "x86_64" and the system requirements say "a 64-bit processor", one would expect it to run on an Athlon64.
One wouldn't have to hunt around in obscure threads on Vogons to find distros that will run, if the architecture names and published system requirements were accurate.

Whatever the arch is based on what the distributions decided to call it when it was set ages ago. The i386 was decided for 32bit intel based instruction set processors, the x86_64 for the AMD extensions to that previous 32bit instruction set that ran 64bit mode instructions. As opposed to the ia64 instruction set of Intel which got that name due to it being different arch to the i386, often referred to as the Itanic for its quick sinking so soon after launch. As with all things in the open source world, computers in general, people are just to god damn lazy to even bother to read the clearly listed instructions on all of the distribution's web sites telling you what they support. That might have them actually learn a thing or two about the computer they use and not be spoon fed the information. That website was found with the second or third hit in Google search "debian i586 processor support" again not for the too god damn lazy who would rather rant away with BS on how they are so hard done by due to fact no one is going to change a setting decided well over a decade ago, causing all that disruption, to make them happy in their foolishness.

I'm still kinda okay with most distros not supporting i386 or i586 but the stupid x86_64-v2 crap is just planned obsolescence, the performance improvements over the original x86_64 binaries are next to nonexistent, sometimes the performance is even worse!

[Trihexagonal]

... but even though the damn laptop have 64 bits AND an Dual-core 2,4GHz CPU it STILL DOES NOT COUNT!?

Kali GNU/Linux 2024.2 Rolling

Here are the specs of the machine I'm using as I type:

Kali GNU/Linux 2024.2
Xfce DE
Thinkpad T61
Intel Core2 Duo T7700 @ 2.40 GHz
4 GB PC2-5300 RAM
Lenovo 100 GB HDD @ 7200 RPM
Intel HD Audio
Intel Mobile GM965/GL960 Integrated Graphics
14.1" 1440x900 (WXGA+) widescreen
Intel 3945 wifi
Bluetooth

I initially installed Kali 2021.3 and when its released in a few months wiil use apt and the rolling updates to upgrade to Kali 2024.3. That will make it 3 full years running the same build on the same machine with no downtime or problems. Because if there had been the first thing I would have done is upgrade that Lenovo 100GB HDD.

I have a couple i386 with FreeBSD installed on them but this is all I use. It doesn't have SystemD and should be easier on resources on that alone but I didn't shut anything down to take that screenshot a bit ago and only hope the fan doesn't give out.

I have over 20 years experience with Debian, close to that with Backtrack/Kali and it's easy as Administrating a Debian box and probably easier to maintain from the problems some have.

Am I trying to convince you or anyone to switch to Kali? Hell no,I'm just providing a little moral support. I'm kicked out of their forum and just drove by with a drive-by to say hi. Bye.

[Uptorn]

I'm still kinda okay with most distros not supporting i386 or i586 but the stupid x86_64-v2 crap is just planned obsolescence, the performance improvements over the original x86_64 binaries are next to nonexistent, sometimes the performance is even worse!

This new versioning is definitely a thinly veiled maneuver to artificially increase demand for new x86 chips. There is just so much hardware manufactured since around 2010 that is still perfectly performant for the vast majority of users.

[D2b2426R5d]

Here's a script to determine x86_64 level and tell which instructions are missing for next higher level. Compatible with Linux and Unix (tested on Debian and OpenBSD).

Code: Select all

#!/usr/bin/awk -f

BEGIN {
    # Collect CPU features from lscpu
    cmd = "lscpu | grep 'Flags:' | awk '{for (i=2; i<=NF; i++) print $i}'"
    while (cmd | getline) {
        features = features " " $0
    }
    close(cmd)

    # Define required features for each x86-64-v level
    levels[1] = "lm cmov cx8 fpu fxsr mmx syscall sse2"
    levels[2] = "cx16 lahf_lm popcnt sse4_1 sse4_2 ssse3"
    levels[3] = "avx avx2 bmi1 bmi2 f16c fma abm movbe xsave"
    levels[4] = "avx512f avx512bw avx512cd avx512dq avx512vl"

    level = 0
    current_level_met = 1
    missing = ""

    # Check features for each level
    for (i = 1; i <= 4; i++) {
        level_met = 1
        split(levels[i], flags, " ")
        missing = ""
        for (j in flags) {
            if (features !~ flags[j]) {
                missing = missing flags[j] " "
                level_met = 0
            }
        }
        if (level_met == 1) {
            level = i
        } else {
            current_level_met = 0
            print "Current level: x86-64-v" level
            print "Missing for x86-64-v" i ": " missing
            exit i
        }
    }

    # If all levels are met, report the highest supported level
    if (current_level_met == 1) {
        print "Current level: x86-64-v" level
    }
    exit level + 1
}

example result:

Code: Select all

$ ./x86_64_check.sh
Current level: x86-64-v1
Missing for x86-64-v2: popcnt sse4_2

Code: Select all

$ ./x86_64_check.sh 
Current level: x86-64-v3
Missing for x86-64-v4: avx512f avx512bw avx512cd avx512dq avx512vl