The main downside to a rolling release distro, with that much drift there’s a good chance something will install that conflicts with something else, and nobody can really help because the only real way to replicate your install is to go back in time and do the same thing
YMMV based on distro. IIRC OpenSUSE has upgrade “pathing” to reduce conflicts during long delays between updates. Geckolinux has an iso released 6 months ago and it will update to the latest OpenSUSE packages.
I honestly think Arch could handle 3 months as well as long as you update the keyring and read the update news from Arch.
NixOS rolling wouldn’t give a damn but that’s not really fair since it basically rebuilds the whole system :P
The biggest issue is not getting security updates for 3 months.
KDE: Welcome to Linux. Do you like the UI of Windows? Well we have an excellent offering for you if that’s your choice. There’s also other DEs that you may select from if that’s your choice.
I wish Microsoft kept Windows as a paid product, instead of making it effectively free (with things like free upgrades from older versions) and sticking ads all over the place.
Disregarding the DE-shaming (which, lol who cares? let people use what they like) how do you even figure OP uses Gnome? I can’t make out anything on their screen from the picture apart from the neofetch.
Uh, no need to apologize? I’m not offended at “Gnome being garbage”. I don’t feel any offense at all, to be honest.
I am slightly annoyed at the “too-bad-it’s-Gnome” comment, which is why I pointed it out. It’s fine to not like Gnome, heck, I don’t like Gnome. I don’t see why that should translate into having a shitty attitude towards people who do like it. I’m just glad people are using FOSS, whether it be some nerd dev on an obscure tiling WM perfectly customized to suit their needs, or some tech-illiterate noobie using Linux Mint and a GUI software manager.
I guess I was wrong. But I just can’t stand gnome. Their devs are insufferable and it’s so incredibly unconfigurable. I have to use it at work (at least I can use linux) and it’s just so frustrating. I can’t stand people voluntarily using gnome
In the unix world, truly great programs tend to stay around for ever. less has been around since 1983. grep was there ten years earlier. Linux users love vim. What does the “v” stand for, you ask? “Visual”, of course, because it was one of the first text editors to offer support for computer monitors. And before that, when we had teletypes, people used ed, which still comes pre-installed with Ubuntu. Not to mention that the modern linux terminal is basically emulating (that’s why we called them terminal emulators) an electronic typewriter with some extra extensions for color and cursor support. They’re backwards compatible to this day. That’s why it says tty (teletype) when you press ctrl-alt-F2.
The caveat is that these examples are all low-level programs that have few dependencies. And they are extremely useful, therefore well-maintained. When it comes to more complex programs with a lot of dependencies, unless there is someone to keep it updated with the latest versions of those dependencies, it will eventually get broken.
The reason this happens less often in Wndows is because wndows historically hasn’t had a package manager, forcing devs to bundle all their dependencies into the executables. Another part of the reason is that mcrosft would lose a lot of business customers if they broke some obscure custom app with a new update, so they did their best to keep everything backwards compatible. Down to the point of forbidding you from creating a file named in order to keep support for programs written for qdos, an OS from before filesystems were invented.
The reason this happens less often in Wndows is because wndows historically hasn’t had a package manager, forcing devs to bundle all their dependencies into the executables
Thanks that’s pretty informative
Why isn’t there a way for Linux users to automatically install every missing dependency for a program? Not sure if this will net me a ban here but the W*ndows way kind of looks superior here. Having old programs break with updates is a massive pain.
isn’t there a way for Linux users to automatically install every missing dependency for a program?
Great question! There is. What you’re describing is a package manager. Overall, they are a great idea. It means devs can create smaller “dynamically linked” executables that rely on libraries installed by the package manager. The w*ndows equivalent of this is using DLL’s. Another advantage is that urgent security updates can be propagated much faster, since you don’t have to wait for each app that uses a vulnerable library to update it on their own. Also, dynamically linked executables can help save on ram usage. With statically linked executables, everyone brings their own versions of some library, all off them off by a few minor revisions (which all have to be loaded into ram separately), whereas a bunch of dynamically linked executables can all pointed to the same version (only needs to be loaded once), which is what package maintainers often do. Finally, package managers eradicate the need for apps to include their own auto-updaters, which benefits both developers and users.
This model goes wrong when software depends on an outdated library. Even if the package maintainers still provide support for that outdated version, often it’s difficult to install two wildly different versions of a library at the same time. And apart from libraries, there are other things that a program can depend on, such as executables and daemons (aka background processes aka services), old versions of which are often even more difficult to get running along with their modern counterparts.
So when you say that the “W*ndows way kind of looks superior here”, you are right about the specific edge case of running legacy apps. It just happens that the Linux crowd has historically decided that the other benefits of package managers outweigh this disadvantage.
There are tools for developers to bundle dependencies. Statically linked binaries, “portable” apps, AppImage, and so on… It’s just that package managers are so widespread (because of the aforementioned benefits), few developers bother with these. The general attitude is “if you want a statically linked executable, go compile it yourself”. And by the time it’s time to make an “archiveable” version of an app because it’s abandoned… nobody bothers, because it’s, well, abandoned.
However, as disk capacity and ram size steadily increase, people are starting to question whether the benefits of traditional package managers really outweigh the added maintenance cost. This, combined with the recent development of a linux kernel feature called “namespaces”, has spawned various new containerization tools. The ones I am familiar with are Docker (more suited for developer tools and web services), and Flatpak (more suitable for end-user desktop apps). I personally use both (flatpak as a user, and docker as both a user and a developer), and it makes my life a whole lot easier.
As for what makes it easier for users to get old apps working (which is what you’re asking), well… that’s sort of what we are discussing in this thread. Again, these tools aren’t very widespread, because there is rarely a practical reason for running legacy programs, other than archivism or nostalgia. More often than not, modern and maintained alternatives are available. And when their is a practical reason, it is often in the context of development tools, where the user is probably skilled enough to just Dockerize the legacy program themselves (I did this a couple times at a job I used to have).
I’m just getting started with nix, if I’m understanding it correctly I think that is kind of what nix package manager does? It keeps packages and their versions separate and doesn’t delete them, so that you can update some programs and their dependencies without breaking other programs that depend on other versions of those same dependencies. linux.com/…/nix-fixes-dependency-hell-all-linux-d…
Yep, that’s the gist. Nix build is reasonably good at spitting out what’s missing ( if your packaging a random git ) and nix-init gives you a great starting point, but generally will need some tweaking to get the package running / installing.
Why isn’t there a way for Linux users to automatically install every missing dependency for a program?
There is; actually there are several. Every^* distribution has a package manager, that’s what it does. But you have to make a package for the program, similar to what the tegaki folks have done for Mac and Windows.
Another option is to statically link everything.
One issue is the fragmentation; because there are so many Linux distributions, it’s hard to support packages for all of them. This is one thing that flatpack aims to solve.
I would expect this to be an issue for old closed-source software, but not for old free software. Usually there’s someone to maintain packages for it.
Some cursory searching shows no tegaki package on flathub or in nix (either of these can be used on any distro; the nix one is surprising to me; it hosts soooo many packages).
There’s pros and cons. On one hand, packing your dependencies into your executable leads to never having to worry about broken dependencies, but also leads you into other problems. What happens when a dependency has a security update? Now you need an updated executable for every executable that has that bundled dependency. What if the developer has stopped maintaining it and the code is closed source? Well, you are out of luck. You either have the vulnerability or you stop using the program. Additionally bundling dependencies can drastically increase executable size. This is partially why C programs are so small, because they can rely on glibc when not all languages have such a core ubiquitous library.
As an aside, if you do prefer the bundled dependency approach, it is actually available on Linux. For example, you can use appimages, which are very similar to a portable exe file on windows. Of course, you may run afoul of the previously mentioned issues, but it may be an option depending on what was released.
Do you happen to know what (if any?) technical advantages appimage has over “portable” applications (i.e. when the app is distributed as a zipped directory containing the executable, libraries, and all other resources)"? As far as I understand, appimage creates an overlay filesystem that replaces/adds your system libraries with the libraries that the packaged app needs? But why would that be necessary if you can just put them in a folder along with the executable and override LD_LIBRARY_PATH?
Not at all! Since it’s half of 9, it can therefore work with half of the software RHEL 9 is compatible with, but since the 4 is also divisible by 2, it can handle all of that software as well.
It’s really quite simple, I don’t see how this could be confusing at all…
And for new users choosing a distro with big user base (thus having a better support system) should be a top priority. Instead newbies are often advised to use an obscure distro that in theory might be a good fit, but isn’t. Probably those who do the recommendations are Linux testers (using VZ) rather than Linux users and mostly evaluate a distro based on install process and out of the box usage.
Configuring a big distro to your needs is much better than choosing a nishe distro.
Just hopped back over to linux mint again after years of making due with Windows
Went with cinnamon cuz pretty.
switched to CobiWindowList so I could see all windows on either of my monitor menu bars.
switched to CinnVIIStarkMenu for a more familiar menu system.
Not much change, I can lean on the habits I’ve gotten from windows, and now my switch is pretty much unnoticeable to me.
Funny enough, Lutris has made it alot easier for me to access games I usually would just have downloaded, like my itch.io library. Proton has tackled all my other games fine. Hell, I even got Tarkov running smoothly, even though you can only do offline raids on Linux ATM.
linuxmemes
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.