The Linux Thread - The Autist's OS of Choice

Not sure this is the right place to ask but ive been looking into Linux mostly from seeing how well steam OS mirrors my favorite windows XP set up.

I've been told Ubuntu is a solid choice but does it have compatibility issues with Nvidia GPUs? I know my default choice of grabbing a branch modeled off steam os really require a AMD card.

Painfully new and planning to have a solid chunk of time to troubleshoot just looking for a good starting point to build from.

Its primarily for a gaming hobby computer.
Linux Mint is the just works solution for new Linux users. Similar feel to Windows desktop, but obviously Linux, and Steam Proton makes nearly every game work. Some games will need some messing around with settings.
 
Not sure this is the right place to ask but ive been looking into Linux mostly from seeing how well steam OS mirrors my favorite windows XP set up.

I've been told Ubuntu is a solid choice but does it have compatibility issues with Nvidia GPUs? I know my default choice of grabbing a branch modeled off steam os really require a AMD card.

Painfully new and planning to have a solid chunk of time to troubleshoot just looking for a good starting point to build from.

Its primarily for a gaming hobby computer.
Just get Linux Mint. NVIDIA sucks and they hate you and they are too busy making new shit for Palantir to stalk you so they haven't released any new consumer cards that wouldn't be supported if you just install the NVIDIA drivers through the GUI driver manager on that.

There are lots of design decisions made by various Linux distributions that will annoy different classes of user. The Linux Mint ones are ones that will mainly only annoy those who are more familiar with how Unix is supposed to work, and who want their system to be nice, rational and simple, like Mint using the Microslop employee and anti-Linux saboteur Lennart Poettring's shitstormd instead of the holy SysVinit, which is the wrong decision but will not inconvenience an unsophisticated end user about half the time if they use a completely base system without ever installing anything or enabling basic features like encrypted drives (you know, like how works 100% fine on Windows 11 by default).

The Ubuntu ones are more along the lines of deliberately ignoring everything that human beings have learnt about how graphical user interfaces should be in the last four decades, and are absolutely inexcusable and all of those cunts should hang.
 
Last edited:
which is the wrong decision but will not inconvenience an unsophisticated end user about half the time if they use a completely base system without ever installing anything or enabling basic features like encrypted drives (you know, like how works 100% fine on Windows 11 by default).
SystemDick shits itself on boot whenever it is unable to meet a defined target, so knowledge about target creation is a necessary skill.
 
Not sure this is the right place to ask but ive been looking into Linux mostly from seeing how well steam OS mirrors my favorite windows XP set up.

I've been told Ubuntu is a solid choice but does it have compatibility issues with Nvidia GPUs? I know my default choice of grabbing a branch modeled off steam os really require a AMD card.

Painfully new and planning to have a solid chunk of time to troubleshoot just looking for a good starting point to build from.

Its primarily for a gaming hobby computer.
Linux Mint is retard proof and, in my experience, found the latest Nvidia drivers right after fresh install. It's been a popular distro for a long time, any question I had I just googled it and the Linux Mint forum is almost always the first result
 
There are lots of design decisions made by various Linux distributions that will annoy different classes of user. The Linux Mint ones are ones that will mainly only annoy those who are more familiar with how Unix is supposed to work, and who want their system to be nice, rational and simple, like Mint using the Microslop employee and anti-Linux saboteur Lennart Poettring's shitstormd instead of the holy SysVinit, which is the wrong decision but will not inconvenience an unsophisticated end user about half the time if they use a completely base system without ever installing anything or enabling basic features like encrypted drives (you know, like how works 100% fine on Windows 11 by default).
to be fair to systemd, and linux mint. The only time I've ever set up an encrypted root partition, was using linux mint which obviously uses systemd. The whole thing just worked. I did it in the gui installer, didn't think about it at all. Just set it up, and that was that.

Every other time I've set up an encrypted drive it was manually on something other than a root partition, so I can't speak for it otherwise, but in that use case. It seemed to work perfectly.
 
I recognize it would be difficult, but would it be possible to make a version of Linux with a custom package management system that inherently uses compatibility layers? So instead of having discrete versions like Debian 12, Debain 13, etc you would have a core OS that does its own thing and something like a container that contains the bare minimum of code that's unique to each version. Then when you install an app it declares which version it uses (or if it's not prepackaged for the OS you declare it at the time of installation) and then the program uses the container that matches it's version. And if you have a really old application you want to use you can still run it inside the right container, and purge containers you're not using.

"Container" I'm not sure is exactly the right word, if imagine it would be closer to Steam's proton compatibility layers for Linux or something. But it would be a lot of work to set up, as you'd need to have a way to determine which containers to use and maintain modified versions of core libraries that support all versions.
 
I recognize it would be difficult, but would it be possible to make a version of Linux with a custom package management system that inherently uses compatibility layers? So instead of having discrete versions like Debian 12, Debain 13, etc you would have a core OS that does its own thing and something like a container that contains the bare minimum of code that's unique to each version. Then when you install an app it declares which version it uses (or if it's not prepackaged for the OS you declare it at the time of installation) and then the program uses the container that matches it's version. And if you have a really old application you want to use you can still run it inside the right container, and purge containers you're not using.

"Container" I'm not sure is exactly the right word, if imagine it would be closer to Steam's proton compatibility layers for Linux or something. But it would be a lot of work to set up, as you'd need to have a way to determine which containers to use and maintain modified versions of core libraries that support all versions.
This is called NixOS or Guix.
 
This is called NixOS or Guix.
Yeah but not gay. Though I'll research it more to see if it's close to what I was thinking. I was hoping for something where there's basically one container that represents every two to four years which most programs are compiled against, and if you really need fast moving software there's smaller containers for every year (or six months) that can be installed and used, but while the 2-4 year containers would be supported for 20+ years the 6-12 month containers are only supported 2-4 years or something.
 
Last edited:
I recognize it would be difficult, but would it be possible to make a version of Linux with a custom package management system that inherently uses compatibility layers? So instead of having discrete versions like Debian 12, Debain 13, etc you would have a core OS that does its own thing and something like a container that contains the bare minimum of code that's unique to each version. Then when you install an app it declares which version it uses (or if it's not prepackaged for the OS you declare it at the time of installation) and then the program uses the container that matches it's version. And if you have a really old application you want to use you can still run it inside the right container, and purge containers you're not using.

"Container" I'm not sure is exactly the right word, if imagine it would be closer to Steam's proton compatibility layers for Linux or something. But it would be a lot of work to set up, as you'd need to have a way to determine which containers to use and maintain modified versions of core libraries that support all versions.
FreeBSD has a system of compatibility layers through its compat packages that install older versions of libraries in a special directory. I’m not super familiar with how this works in practice, like how you’d tell the linker to get those packages instead of later ones, but there’s probably a way. The issue with doing this on Linux (or any POSIX system) is that when you load a binary, the first thing that gets loaded into its address space is libc, not the actual program. This is why sometimes even containerized formats will fail to run, bc they depend on the wrong version of libc and getting the system to use a different libc for a specific program is difficult. I’m not sure what the FreeBSD solution to this is, perhaps it’s to maintain an ultrastable libc ABI, or maybe they’ve figured out how to force their system to switch libcs without much hassle.
 
FreeBSD has a system of compatibility layers through its compat packages that install older versions of libraries in a special directory. I’m not super familiar with how this works in practice, like how you’d tell the linker to get those packages instead of later ones, but there’s probably a way. The issue with doing this on Linux (or any POSIX system) is that when you load a binary, the first thing that gets loaded into its address space is libc, not the actual program. This is why sometimes even containerized formats will fail to run, bc they depend on the wrong version of libc and getting the system to use a different libc for a specific program is difficult. I’m not sure what the FreeBSD solution to this is, perhaps it’s to maintain an ultrastable libc ABI, or maybe they’ve figured out how to force their system to switch libcs without much hassle.
Could a hypothetical system just replace glibc with something that basically maintains static ABIs that either don't change or have some sort of internal version control, so that binaries that target libc v1 will work in a backwards compatible mode in libc v5 that came out 10+years later, without having to be recompiled?
 
Could a hypothetical system just replace glibc with something that basically maintains static ABIs that either don't change or have some sort of internal version control, so that binaries that target libc v1 will work in a backwards compatible mode in libc v5 that came out 10+years later, without having to be recompiled?
ELF binaries support something called “symbol versioning”, which allow binaries to link against a specific version of a symbol and libraries to keep old versions around in a way that doesn’t mess up new versions. Glibc makes extensive use of symbol versioning to maintain backwards compatibility. Afaik, actual symbol breakages between glibc versions are pretty rare nowadays, the main issue people run into is trying to run software compiled against a *newer* version of glibc on an older version, which causes the system to throw an error before even running, or changes in how the library is packaged. Glibc used to be shipped as three .so files, but now apparently it’s shipped as a single .so, which is arguably a more sound choice architecturally but introduces breakages.

You could try replacing glibc with musl and see how that does it for you. I use musl-void, personally, and I have yet to encounter any compatibility issues. But never say never.
 
SystemDick shits itself on boot whenever it is unable to meet a defined target, so knowledge about target creation is a necessary skill.
Only if you willingly decide to welcome systemdicks into your ass.

Are there any distributions left that don't suck?
Despite being an example of someone having an issue I can still recommend Artix with openrc + xfce. The thing with Jami @GNU Abyss is quoting is the only time I've had something like that happen after using it for several years at this point.

Fair point. I got used to Debian at one point, moved my webservers to Devuan because I'm that buck broken in the LAMP setup 20 years later. I liked Alpine for a bit, but their politics annoy me. Considering moving back to OpenBSD for everything except for my personal laptop. I don't have 20 years to wait for the latest GMA3000 compatible drivers to make it there with twm.
The Artix team is also essentially non-political (meaning they are far-right-nazi-chuds because they don't believe in troons).
1717891469462466.png1715496113000193.png
Edit: I don't know why these won't thumbnail. I deleted and re-added them as a thumbnail and there's no change.

They're downstream of arch but which distro isn't downstream of massive faggotry now-a-days. Arch? trannies. Debian? chomos. RHEL? corpos. Pick your poison.
 
They're downstream of arch but which distro isn't downstream of massive faggotry now-a-days. Arch? trannies. Debian? chomos. RHEL? corpos. Pick your poison.
Cheers.

I really liked Void, but then they kicked Juan out and it went pretty stagnant. I'll have to give Artix another shot. I'm running Mint right now because nothing else liked my new (lol 2024) hardware at the time. I want to get rid of systemd. Again.
 


For people that don't want to watch. He brings up that the age verification stuff is happening on the OS level. But we also have this being pushed at the package manager level as well.

verify.png

comp-dev.png

In the current form, it needs to have over 5 million users. Although I think something like apt might hit that mark. Other package managers will likely be well under it.

five-mil.png

Either way the slippery slope is continuing to steepen. Honestly I think we hit the point of no return either last year or the year before, People didn't care at the time, people even supported it. And faggots are even supporting this as we speak. If people think this is no big deal, I promise you will regret that in a few years time, after more laws get passed. Unless enough people decide this is a bad direction, and realize the state, and federal government doesn't actually have your well-being at heart, or your child's.

I recognize it would be difficult, but would it be possible to make a version of Linux with a custom package management system that inherently uses compatibility layers? So instead of having discrete versions like Debian 12, Debain 13, etc you would have a core OS that does its own thing and something like a container that contains the bare minimum of code that's unique to each version. Then when you install an app it declares which version it uses (or if it's not prepackaged for the OS you declare it at the time of installation) and then the program uses the container that matches it's version. And if you have a really old application you want to use you can still run it inside the right container, and purge containers you're not using.

"Container" I'm not sure is exactly the right word, if imagine it would be closer to Steam's proton compatibility layers for Linux or something. But it would be a lot of work to set up, as you'd need to have a way to determine which containers to use and maintain modified versions of core libraries that support all versions.
really, that's any immutable or atomic distro. nix and guix like was mention. Also the silverblue like distros. There are plenty of distros like these, you can look into which might do what you like. I'm personally not a fan of this way of doing things. It ends up making things more complicated rather than less complicated.

There are also distros like bedrock that takes different distros and pieces them together, I would say just look into it rather than having me describe it. I would probably get something wrong in the details about it.
 
Last edited:
In the current form, it needs to have over 5 million users. Although I think something like apt might hit that mark. Other package managers will likely be well under it.
A lot of package manager commands these days are done automatically what r they gonna do age verify ur agent
 
A lot of package manager commands these days are done automatically what r they gonna do age verify ur agent
What do you mean? Are you refering to when people are using a gui?

Anyway. If this passes I assume they obviously wouldn't make you stop in the middle of installing a package to verify your age. It would have to be while setting up things with the package manager, and that would then have to follow whatever full details of the spec would be.

They're likely going to have to change how some of these are designed, or at least add in something if they are going to comply with this law.
 
Despite being an example of someone having an issue I can still recommend Artix with openrc + xfce. The thing with Jami @GNU Abyss is quoting is the only time I've had something like that happen after using it for several years at this point.
I have been running Arch on my desktop for a while now, but I decided to try Artix as described on the TV machine a few years ago. Granted, there's much less stuff I've installed on that one, since all it needs to do is access YouTube and play video files, but it boots faster and I have had very few problems, and nothing significant. I'll need a laptop this year and I intend to run Artix, it seems like it works quite well indeed.
 
I like the default wallpapers of the Raspberry Pi distro back when I used that. They can be seen here.
When I searched for them, the top result was people complaining that the CachyOS default wallpapers were "unprofessional" as they often feature anime girls? Along with complaints about AI art.

It got me wondering if there's any specific favourites you have (or any you think are horrible).
 
Back
Top Bottom