- Joined
- Jan 5, 2015
The Linux Thread - The Autist's OS of Choice
- Thread starter tehpope
- Start date
-
Want to keep track of this thread?
Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
Create account
- Joined
- Apr 1, 2024
It's an interesting project, but moving to that over xlibre is pretty retarded if you ask me.
Unless someone knows of an actual technical reason to ever pick that over an actual xorg server. I have a feeling it's not for technical reasons. But hey i could be wrong. And I'm not even someone overly hung up on the xorg being killed thing.
- Joined
- Mar 4, 2019
Your feeling is correct. The only reason this project exists is to try and fuck over xlibre. It was announced by "Ariadne" after he threw a bitchfit about xlibre, only to almost immediately abandon it to "the community".
- Joined
- Mar 4, 2019
I'm here to reveal my thoughts based on my limited experiences with Linux and I want you to correct the record if I am wrong.
In many ways, management of program installation is just superior on Windows.
Btw, it's mind boggling for me how such things as dependency hell has been allowed to exist at all. Why cant you allow two versions of same package to exist in the system.
Again, I may be completely wrong and misinformed, would be glad if you'll correct me.
In many ways, management of program installation is just superior on Windows.
- You want install program on another drive? No problem!
- You are in need to have two, or more different versions of same program installed on your system? No problem!
- You dont have internet? Here's hoarded installers you have on your thumb drive!
Btw, it's mind boggling for me how such things as dependency hell has been allowed to exist at all. Why cant you allow two versions of same package to exist in the system.
Again, I may be completely wrong and misinformed, would be glad if you'll correct me.
- Joined
- Apr 11, 2023
This is an artifact of (generally older) poorly architected distroes. Gentoo has an elaborate system for keeping multiple versions around. Nix/Guix have the most well-architected solution where countless versions exist simultaneously. Snaps and Flatpaks also make multiple versions straightforward.
- Joined
- Mar 4, 2019
Got it, how about installation on another drive? This rubbed me in really bad way when I learned that such simple task on windows is not a straightforward on Linux.
- Joined
- Feb 18, 2024
This is true. A global namespace for packaging has always been a mistake, content/input addressed "package paths" (or as it's called in Nix/Guix, derivations) fix the problem from the root. Gentoo's way of doing it is cope, and in a commom Gentoo fashion you have to rebuild everything.
The FHS can be emulated with this if you want, nothing prevents you from linking /nix/store/xxxx-... to /lib64/... in your system configuration. However having this be the default for better onboarding of people used to FHS distros would certainly help. (and a built-in option to do that, instead of annually linking it all).
Snaps/Flatpaks/AppImages are the worst, because they force you to make them self contained and also force you to download the whole thing. This increases storage use, which isn't ideal. Sure, there are a few hacks, such as using Nix to build your Flatpak & having the store paths within be deduplicated with other paks, but you still have to download it all as it's not a "native" concept for the wire format. NOTE: These are the most similar to the way you install stuff on Windows, though some offer isolation as a benefit (such as Flatpak)
I also wish Nix's implementation & nixpkgs weren't so terrible, which is why I'm working on a custom language that can build anything & is ruthlessly incremental, similar to how unison works.
Packaging in Linux sucks, but the least bad is Nix right now & even Nix is terrible.
In Linux, since it's all packaged by a single package manager and thus packages share dependencies, it's often harder to determine where to place what (do I only install the not-installed deps to the different package root? or do I just copy over all the deps?). And since stuff on Linux depends on absolute paths when referencing dependencies, you can't just say "just relocate this to $DRIVEFOO in dir /media/foo" where it's trivial to do so in an isolated package installation that's designed to be relocatable.
Of course this is cope, but the benefits of having a single package management system outweigh the negatives. (On windows, you can imagine every app having its own package manager)
Technically you can do "mount this path in my package manager to drive Foo", but that's tedious and not particularly useful.
Last edited:
- Joined
- Mar 20, 2024
Tools like "apt-offline" exist to download packages on one machine to a USB stick, to install onto another machine or to keep for later.
You can also tell your package manager to just download the required files (e.g., apt download <package>) and save the package sources elsewhere on your machine.
The more stable distros like Debian you could probably keep and use the downloaded files for a while, however on rolling distros like Gentoo and Arch it wouldn't be very useful for long, as they are always updating.
Windows doesn't even have a package manager the same way Linux does (winget is a glorified package downloader), which leads to different issues then the Linux approach. Such as people downloading viruses from websites like "freegooglechromenovirus .com"
Your options are pretty much bad or worse.
Linus Torvalds has screamed about how bad it is many times, best summed it up as "You make a package for Windows, it works on Windows. You make a package for Mac, it works on Mac. You don't make Linux programs, you make Debian and Fedora, etc packages". I love how Flatpaks and Snaps and AppImages were going to fix Linux packaging, but there's 3 different choices in true Linux fashion.
Linux's greatest benefits (freedom/choice) are also its greatest downsides.
- Joined
- Apr 11, 2023
The reality is that this philosophy is exaggerated by the GNU C library, which demands that all software be dynamically linked. Statically-linked software has substantially less bitrot.
- Joined
- Jan 29, 2024
Really the problem is that static linking isn't really accepted on Linux. On Windows, you will usually either link statically, or provide all necessary dlls with the program, and the installer is basically a glorified self-extracting archive. On Linux, every package is supposed to be self-contained and link against other self-contained packages that are expected to be in the system, with the package manager there to ensure that. And even if you want to statically link your binary, chances are you're dependent on glibc, which, as @analrapist mentioned, explicitly doesn't support that. Snaps and flatpaks are literally just static linking with extra steps, as they ship packages in containers with all dependencies.
- Joined
- Feb 18, 2024
Worse, if you think "better from a technical perspective, worse because we're not all using the same thing", sure I can agree with that.
Exactly, but this also makes Linux useful for much more, Windows and Mac are primarily desktop OSes. What I believe is that everything other than desktop programs/etc should be packaged by a "technically perfect" package manager, and the rest should be disteibuted as Flatpaks by publishers (or nixpaks, but not for the publisher of the software). That way you get the "just works" of MacOS while having a solid system, and people who don't want to use Flatpak can repackage it themselves. And you still have the freedom.
- Joined
- Mar 20, 2024
Pretty much. I've never used NixOS (and I don't intend to) so I can't say whether its truly better or not. But it does look interesting for embedded solutions where you need the same OS replicated perfectly thousands of times, looks overkill for desktop.
Good luck getting Linux autist troons to agree on what the technically perfect package manager is
I hate to say it but publishing all software as Flatpaks is probably the best workaround for now, considering how autistic glibc is about static linking.
- Joined
- Feb 18, 2024
I should've clarified, I mean technically perfect as in "every distro has what it deems perfect, and repackages stuff in it", the system PM doesn't need to be shared, just having a "desktop app installation mechanism" which is is sufficient.Good luck getting Linux autist troons to agree on what the technically perfect package manager is
I use it for having the same setup across 3 VPSes, a Macbook and a Linux computer. It's worth it, and after the initial learning curve (which is needlessly steep) and tinkering you don't even mess with your system that much. Your config becomes effectively "done" until you do your monthly (or even bi-yearly, I know people who do that) nixpkgs upgrade where you need to use undeprecated option names, etc.
However it does really shine the best for the setup you described. Anduril uses NixOS to build and deploy the exact same images to their drones used to bomb illegal immigrants.
- Joined
- Mar 4, 2019
If you want absolute portability without static linking, you want AppImage. You don't get sandboxing, but there's arguments for and against that (badly configured sandboxing can have unexpected outcomes when accessing your files, for instance). Order of preference for me, as a user, is distro package manager > AppImage > flatpak > tarballs >
- Joined
- Feb 3, 2013
The original sin of Linux, the sin that launched a billion package managers, is not having "the directory this binary is in" as part of the library search path.
- Joined
- Apr 11, 2023
You new to Linux? Add . to PATH and LD_LIBRARY_PATH and you can have this behavior you seem to want. (You don't.)
Retarded Weeb
kiwifarms.net
- Joined
- Dec 17, 2022
You could always just run a program through a bash script that tells it to look where you want for library files, can't you?
- Joined
- Mar 30, 2023
Can that be done recursively or are you assuming all the binaries and libraries will be in one big messy folder instead of individual folders for each binary like Windows and macOS?
- Joined
- Apr 1, 2024
I actually like using tarballs/zips out of those options.
you can just get an archive of a package if a developer offers it as an options, and untar/unzip it wherever you want. And generally it just works. It's pretty much equivalent to what people expect to be able to do with windows, or whatever other OS they like. Really I wish more maintainers just worried about making a tarball package for linux, then they release that, and let distros handle turning that into something their package manager uses. So they don't need to worry about deciding to make a package for a few different distros, and have them all working.
Though distros would probably need to still just build them from source against their own versions of libraries. Depending on how active the development the maintainer of the program is. Like debian, and it's forks will be 2 years behind where, arch, and void are. So the obvious solution to make installing packages easier across all of them, is having the distros build them from source against the versions of libraries they are offering so the end user doesn't have to worry about what versions they have installed, and so the package developers don't have to worry about paying attention to what however many different distros are doing.
Either way to what the origional person said.
You can generally tell a package manager to install a package whereever you want, (i'm only really familiar with 2 or 3 and vaguely with others, but that's the case for all of them I know well)
you can have multiple versions, but depending on your distro they way you do it will be different.
and you can download packages without unpacking them to save somewhere to install later.
- Joined
- Jan 29, 2024
I might be wrong, but I don't think Windows searches recursively, it's either in PATH/binary's directory or it's not.