Linux has standards where interoperability is important. The more things needs to talk to each other the more they need a common standard to talk over. Things like X11/Wayland don’t have many alternatives as so many things need to talk over them. The only reason there are two standards here is because X11 has massive limitations that cannot easily be worked around.
For package managers applications don’t care about them. Interoperability only matters within a single distro. So people are more free to create what ever standards they want for their own distros. And when people can choose people have opinions and these opinions evolve over time. Which results in multiple competing products that effectively do the same thing.
And here is my hipotesis if the GNU project came up with a good and easy to work package manager in the early days of Linux
Probably, but creating a good, easy to work, fast and reliable package manager that meets everyones needs when you are discovering how you want it to work for the first time is extremely hard. And even if you created a perfect one at the start, requirements can change. This happened with X11, and even with package managers seeing the rise of things like flatpack, snap and appimage that all work fundamentally different from the traditional ones.
OK maybe what I meant was a packaging format and not a package manager, above there was a user that mentioned that all distros have their quirks and kinks, if GNU created a package manager that worked perfectly at first time maybe it’s adoption would go across the distros but as u said to make it perfect the first time is something hard and even harder on early days where nothing was set on stone and there would be always the odd one that would make their package manager.
But if we all agreed early on, one one packaging format (which of course would have to go through many iterations to reach a stable state ) all package format wars would be over and in well implemented ecosystem of package managers of each distro, it would be also an somewhat interoperable one.
The package format is almost irrelevant TBH. Most packages are not interoperable between distros due to the versions and names of dependencies. That is not something that gets fixed by a standard package format. Packages don’t even work well between different versions of the same distro. largely due to libc - anything that depends on that is built against a specific version and when you upgrade it you need to rebuild and install everything that depends on it. Similar problems exist for all compiled dependencies on a distro.
And while some packages of the same format can be installed on multiple distros (mostly those based of the same foundation) most cannot. This is what the newer package formats (like flatpack) are trying to solve - by including all dependencies inside the package.
So a standard format does not really solve those issues, so there is little advantage for one. At least not one of the old school formats. And the wars are not really over the format, they are over the tooling required for that format. At the end of the day RPMs, DEBs, and arch packages are just tarballs of files and some meta data (and there is even a tool that can convert between them - though anything with dependencies quickly becomes a complete mess). It is the build and install tooling that makes all the difference.
Oh … thx for the insight, it was a daydream anyways looks like the only solution is cloud native if one wants uniformity, still a bit hesitant to have a system so stable I can’t change it’s core filesystem.
Yeah of course I get your argument although we have rpm (or deb in debain based distros) across redHat and OpenSUSE it does not mean that the same rpm package would work on both systems due to distro specific aspects (like different root structures, init systems etc . . .), but that’s something for the package manager to solve, the package format could be agreed upon, which would ease the workload of developers and maintainers since the moment you know the target distros of a package they could see the base differences of said distros and add symlinks, dependencies, environment variables, services … as needed for the package.
This seems like it could lead to a whole lotta of conflicts, but I think if the daddy distros were designed all with one package format in mind, such format could be somewhat interoperable.
@mintycactus@jack silverblue is not more user friendly than mint, not by any metric. A system with an immutable file system simply cannot be so. The immutability of the system often adds levels of complexity that an average person would have trouble understanding
@mintycactus to you and me that’s true, but to a person just starting with Linux, it could be complex. I think systems like Silverblue, Vanilla OS, and NixOS are great, but I would not suggest them to a new user of Linux.
@mintycactus NixOS can install to your hard drive. I have it on my laptop and it runs beautifully. I have issues with Gnome and their insistence on removing things like remembering window size and positions, and recently making it so hard to theme, but I am sure these will iron out with time.
My plasma desktop, however, is my favorite. Once I got it where I wanted it, it just worked so well and looked so good that I recommend it to everyone (BigLinux with KDE)
Open btop in the terminal, then (note the terminal window must not be in fullscreen) right click with the mouse on the top bar of the terminal window and select “Always on top”.
The rust one is called bottom (btm) see the other thread :). When you already have a rust environment it is just at a cargo install away which is convenient.
I can’t really give a super useful opinion given that I haven’t really touched fedora, but I’ve been using mint for school for almost a year, highly recommend
Even if Mint (Cinnamon) doesn’t look as good as GNOME, you can always install another desktop environment.
I’d recommend fedora silverblue. You’ll install all graphical packages via a Software store and you won’t brick your system. Even if, you may just recover an old state. I installed media codecs via the software store, not command line.
And bringing the cycle full circle, Microsoft is barreling headstrong into “embrace” to build up leverage and goodwill before fucking everyone over again
Mint has very nice tooling but its a weird Ubuntu derivate. One day a specific software doesnt install, or you have an XOrg problem that will never be fixed, or standard updates simply break something, and then…
Mint is nice and easy to get going, but its outdated a lot, and uses a Distro model that I dont like to install on random laptops that are never updated.
So you’re a power user? Case in point, you’d be better for Fedora.
Also my second distro was mint, after 3+ years of the old hdd’s non-use, I pulled it out last year when my install of some OS broke, updated it to zero issues (I was curious), used the software for a bit, all was good.
3 years without an update to zero issues.
Haven’t seen any issue with Mint updates yet like I’ve fought in Fedora
It’s crazy crazy sort order that I can’t stand. They deliberately go in and remove certain characters from the filename, specifically to make the sorting behave weirdly.
I installed Mint on someone’s old laptop at my Uni’s lab (it’s mostly for the field of environment and agriculture so nobody is an IT expert here), he didn’t have any complaints and is actually falling down the Linux rabbit-hole, while others are considering switching to Linux too after seeing how it resurrected 2 old basically-defunct laptops.
I’d go with that, it is a trusty and reliable distro for newbies. I even know some greybeards that use it.
Then again as others pointed out he can try both from live USB. The important part is that you explain a distro can have everything another distro has with the right know-how and some patience, as well as how things work on Linux (for example: imstall programs using the package manager whenever possible). But again he isn’t a tinkerer so stock Mint will work just fine with him.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.