As a few have already mentioned, a Debian based distro is a good choice, and you Mentioned vanilla Ubuntu isn’t ideal do to prioritizing snaps, I would then suggest Pop!_OS or Mint. I like what System76 (Pop) is doing with their scheduler and the upcoming Cosmic DE (written in Rust and should see an alpha early next year).
It would be excellent if he could get fully funded through Patreon. I chipped in a bit, and I don’t even use it–looks like a cool approach, though. There have to be enough enthusiasts out there to pitch in enough cups of coffee to cover his dev time.
I’m not sure how much of a cut Patreon takes, but it seems like there would be better options out there for non-profit foss projects, no? Liberapay maybe?
Even though librapay doesn’t take a cut, the providers they use do. Someone is taking a cut; I just try to make it smallest with the least-shitty company. :) But it’s tough, as a buyer, to find ways to pay people. I really wish creators would have obvious tip jars, and there was a standard way to tag them in HTML so search engines could find them.
I love Fedora but definitely Mint for a normie. Even then I question if you should install Linux at all since reliably being able to do what you need to do is priority one, especially for a student, and if he may be blocked in his work as a result I don’t think it’s a great idea.
I made the swich a year or two ago. It is much better I find. I leave it running in a tmux session on my server . with btop on one pane and switch to another with a split view to do work. It allows me to take a quick glance at any time while not taking the focus from what I was working on.
I saw him with “-1” so actually 2 people not just one person have misclicked according to your theory. Hmmm i don’t know, but i hope it’s true, better then the alternative
Just found this too, through the rust post some days ago…but its quite obvious that from a usability context that btop is easier to use. With bottom you have to memorize all hotkeys wheres btop is showing them right in the interface.
Yea. I was using bottom until I saw this and did a quick side-by-side comparison (nix-shell -p btop, I use NixOS BTW). btop’s UI is just so much better.
Linux mostly follows POSIX standards, even though it’s never been certified as compliant, so much code targeting POSIX systems runs on Linux too. In other words, it didn’t establish any standards so much as adopt one that already existed.
There is no POSIX standard for package managers, however.
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.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.