511–520 of 624 posts
Earlier quoted context omitted.
Manjaro was a very smooth transition from an ubuntu-based system (neon, in fact) for me.
I ran Manjaro on my gaming desktop for a couple of years but I hated KDE, it felt so clunky, always misbehaving compared to Gnome where I've had relatively few issues.
Earlier quoted context omitted.
This model doesn't necessarily work for software that developers don't want others shipping for them .
Setting aside that those developers are not good team players / open source citizens, they always have the option to ship a regular tarball with everything inside, a la Blender / Firefox / VSCode / Arduino etc... I resent having to install and maintain another package manager, and another set of base runtime libraries. I won't do it. Give me standalone binaries, give me source that compiles, but don't give me a link…
...yeah, no.
Open sourcing your code doesn't mean you necessarily want people packaging it up for distribution elsewhere, because when they inevitably fall behind the release schedule and people get on old versions, you are often the one who gets the support triaging work. It is entirely reasonable to not want other people doing this.
Earlier quoted context omitted.
> You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.
That's the point though: this sort of thing is not ridiculous on most OSs. I should be able to use old versions of software (or new ones for that matter) without having to worry about causing my system to catch fire and explode.
Oh, not all libraries support that. They need to...
Earlier quoted context omitted.
> So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager. So, they decided that the update path is always defined, from any state to the latest, without having to update the packages in specific order, where some steps needed may…
I actually don't want a package manager tuned for "my grandma" (the white whale of the linux community). I'm a professional dev, Arch perfectly suits my needs where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them (something I go out of my way to avoid at this point). > Immutable system does not prevent writable /usr/local/bin. I can't speak to the others, but Nix most definitely…
So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it.
> Arch perfectly suits my needs
Good for you. You just need to realize that you are minority. Do you notice that Arch is not the dominant distro? There's a reason for that.
> where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them
You are holding it wrong ;)
> but Nix
Nix is not exactly a typical immutable system; it has strong opinions about many things, that other systems don't. You can't evaluate other systems through assuming they are like nix.
Nowadays, even MacOS is immutable and people live with it just fine.
Earlier quoted context omitted.
I actually don't want a package manager tuned for "my grandma" (the white whale of the linux community). I'm a professional dev, Arch perfectly suits my needs where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them (something I go out of my way to avoid at this point). > Immutable system does not prevent writable /usr/local/bin. I can't speak to the others, but Nix most definitely…
> I'm a professional dev So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it. > Arch perfectly suits my needs Good for you. You just need to realize that you are minority. Do you notice that Arch is not the dominant distro? There's a reason for that. > where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them You are h…
I didn't say that you should use Arch on the server, but it's great for the desktop.
You can refer to this entire thread to see how well Flatpak/Snap... are working out. Pretty much universally reviled by developers (people who actually use Linux on the desktop).
Earlier quoted context omitted.
> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. But isn't that the primary job of a distro?
For base packages like desktop environments, tools, libraries, popular applications, etc, yes. But I don't think they should be responsible for every end-user third party application. It's a massive waste of time for everyone involved.
For software that they can't do this with, or that isn't worth their time, they just omit it from the package manager.
Earlier quoted context omitted.
Or another recommendation. If you want all the drivers and you want to run Debian, use the non-free image which I believe they just decided to make it easier to find?
Didn't know that was an option! Thank you! If I only had a time machine to 3 weeks ago. Oh well. Thanks anyways. I'll try that again in a couple of years.
Earlier quoted context omitted.
No, users don't do it. The application developers do it in their CI pipelines. Application developers should be the ones building and testing the app, not distro maintainers responsible for a dozen other applications.
It’s called a distribution . Literally distributing the software. The distro deals with integrating all the packages into a single compatible system. This includes setting options to maintain system compatibility. Packaging is not required for testing individual applications. That happens at build time and the developer writes the tests. These are not distribution specific. The separation of concerns is very clear. I…
Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy.
But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications.
However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately.
This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.
Earlier quoted context omitted.
> shouldn't be work in the first place. It seems very much intentional. You could just keep multiple different, vulnerable versions around and keep everything working. Instead distros say "Nope. We support exactly one version. Update or die." That is also why you have runtimes, grafting, support sunset,... . I agree that a different trade off makes much more sense for desktops. For servers though...
Most updates aren't security updates. Not all vulnerabilities in a library affect all consumers of that library. Distros don't have every library packaged. Distros often are not often willing shipping patched versions of dependencies. Distros often offer out of date versions of libraries.
> distros don't have every library packaged.
Exactly. And for those that are packaged they say "these are the versions we support. If you want to us to do the support work, use these". Again for stuff like windows ltsc that means I install version X now and want this to be supported for the next 5 years. If I instead install a consumer version of windows it means X will be out if support by then and I am expected to have upgraded to X+1, X+2, X+3 during these 5 years.
Case in point, Firefox has multiple current versions: 102 ESR and 111. Both get regular updates and neither is "out of date".