The old model works for established software, but breaks down a little now that it becomes easier to write software applications.
Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications.
What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.
AppImages are not comparable with statically linked binaries.
Meanwhile, Snap and Flatpak are package managers - what's more, they're invasive heavyweights with permanent costs that are even worse than distro package managers. Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck! They are both trying to impose some dubious vision of sandboxed apps that require bureaucracy to communicate with each other, instead of just tackling the core issue of software distribution.
Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.
Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox.
Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.
If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.
I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior".
I have absolutely zero trust in the former, and lots of trust in the latter.
> The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more.
This still forces the user to learn the internals if the AppImage doesn't work. E.g. if MATLAB would use Appimage, I'd have to extract squashfs contents, fix the broken libraries inside and the repackage it. Or I would have to write a script to start the executable outside. It's a simpler from a pure technical standpoint when it's a tarball + wrapper script.
> Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck!
Snap has many issues Canonical just refuses to solve (e.g. users without home under /home), so I just ignore that. What flatpak does is arguably exactly what Appimage does, a wrapper script. Maybe more complex, but with additional features and the it's the same script for all packages. If you have 100 AppImages installed, you have the same thing as "flatpak run" in up to 100 slightly different versions. I can't see how that reduces complexity.
To begin with Flatpak makes .desktop files so no one should be needing to use that command manually.
Secondly, Flatpak has an option folder you can add to your path that lets you run applications by running their FQDN. e.g. org.gnome.Gimp myFile.png rather than gimp myFile.png
Flatpak and Snap have SDKs for this purpose, but with AppImage an ISV is forced to guess which libraries need to be bundled and which may be dynamic link dependencies from the OS.
Not to mention the requirement for fuse2, which is being replaced with fuse3.
That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that.
If an app can't use a standard .deb or .rpm then the distro is doing something wrong. If dependency version management is too hard, someone is doing something wrong - not sure who, could be a library maintainer or an app maintainter. Let's not ship half an OS with every app to avoid this stuff.
You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. 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.
If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.
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...
> 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".
Oh, not all libraries support that. They need to...
You will very likely bump into conflicts. Or you you need to upgrade a lot of fundational libraries (like libc), at which point why stay on Debian 10?
Backports exist for a reason.
Backports do indeed exist for a reason, I just felt like challenging “can’t”
If you're using a "Debian based" distribution, the "standard" .deb is the one shipping with Debian. If it doesn't work on the derivative distro, they are doing something wrong. Or like I said, maybe the dependencies are doing something wrong.
This is the problem that Flapak, Snap etc try and solve. I won't put AppImage onto that list because it actually doesn't solve the problem it just makes it worse.
I was under the impression that Debian already solved that problem by allowing you to deploy an older Debian version in a chroot with debootstrap? As long as the Linux kernel is binary compatible, that should work fine. Although I have to admit I don't use stale software that often, so I have little experience in that area.
The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.
There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.
https://refspecs.linuxfoundation.org/lsb.shtml
These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.
What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.
If a distro wants to include their application they have every right in the world to do so. So its up to them to do what ever is necessary to enhance their product with the freely available product of the unpaid developer who created it.
You build one flatpak and it will work for all distributions.
Packaging is not required for testing individual applications. That happens at build time and the developer writes the tests. These ate not distribution specific.
The separation of concerns is very clear. If a distribution doesn’t package the code then the user is left to build the application themselves. It’s impractical that a developer would build and maintain their own packages for every flavor of every distribution.
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.
Flatpak and friends are a pain in the ass to use and offer a shitty UX. Having a single point of contact and well understood mechanism for software management is a feature for users.
I don’t expect my distribution to have every software package ever. I do expect it to fulfill my needs. As long as there are applications in the repository that do what I need I am happy.
They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo.
> false dichotomy to say snap or flatpak are the only alternative
we are slowly moving into the world of immutable base systems, like fedora silverlight for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.
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.
> we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.
The "last thing I want" is a package manager that's invasive to use, doesn't have the latest software and is slow. Immutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!
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 disappear. You know, being robust.
If the year of linux desktop has to happen, not borking the system during updates is a requirement. You don't have a problem with daily updates? Congratulation, but your grandma probably has.
> mmutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!
Immutable system does not prevent writable /usr/local/bin. Your one-off tool has no business messing with /usr/bin or /usr/lib.
Immutable systems are also minimal; they don't care about your additional software, as it is separated from the base system. You can update your software at any pace you want; nightlies if you want. It just cannot touch anything in /usr (with /usr/local being exception).
> Immutable system does not prevent writable /usr/local/bin.
I can't speak to the others, but Nix most definitely does not make /usr/local/bin writable. You have to package up your tools to use them.
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.
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).
And I said that apt/dnf solve problems that pacman didn't start thinking about yet. So we are in agreement here.
Flatpak seems to be working out pretty fine.
> Pretty much universally reviled by developers (people who actually use Linux on the desktop).
Two things:
1) Reviled by some very conservative types, often not willing to consider things from different perspective than what they are used to. If they would build the desktop, it would end up like Homer's dream car.
2) Don't you think that it is a problem when only developers use the desktop as it is? (Not really true, but let's consider that for the sake of argument).
I would consider my self non-conservative to the extreme, which is exactly why I don't like Snap since it's built out of fear of problems that I simply don't have. I want the latest versions of any given piece of software and I want my package manager to be performant. I don't think those are conservative values.
> 2) Don't you think that it is a problem when only developers use the desktop as it is? (Not really true, but let's consider that for the sake of argument).
I don't think developers having a great computing environment is a problem at all, quite the opposite. I think it's very desirable and I think efforts that hamper that for the mythical "grandma" are indicative of the core UX problems that plauge the "desktop linux" community.
For the base system and libraries, yes. But why should the distro maintainers be burdened with additional work for every possible enduser application out there? If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository.
Maybe a far-fetched analogy, but imagine if browser maintainers have to perform additional work every time a new website launches before it is available to its users.
Also, in this system, the application developer has a lot of extra work for making the application run and build against older versions of its dependencies. If I want to make my app available for Ubuntu 22.04 LTS which has libadwaita 1.1, I cannot use any of the new widgets in libadwaita 1.2 (released 6 months ago) or 1.3 (released earlier this month). I can use those widgets but I'll have to write ifdefs and provide fallback behavior/widgets when building/running against these older versions. I will also have to manually track the various distro versions to detect when I can remove the fallbacks from my codebase.
This is what Flatpak is for. Using Flatpak I can target a specific GNOME SDK version and make use of all the new code immediately, without having to write fallbacks. The downside is that when a user downloads my application through Flathub or another Flatpak repository, it might have to download the additional libraries as well, but they will be the correct versions and they won't be downloaded if that SDK is already available due to other Flatpak applications already installed.
Essentially, something like Flatpak is a middle-ground solution that trades of some disk space for the benefit of less work for distro maintainers (so they can focus on core packages) and less work for application developers (that can use more recent dependency versions and don't have to worry about the versions in other distro's)
Yes, and that's a good thing for a whole bunch of reasons.
If you don't want to leave it up to the distro maintainers, nothing's stopping you from standing up your own repo to distribute your software to a particular distro. It's a one-liner for users to add your repo to their list so they can use their package manager to install and update your software as usual.
> Essentially, something like Flatpak is a middle-ground solution
Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way.
I'll give flatpack this much credit, though -- it's not a nightmare like snaps are.
My browser, mail client, rss reader, music player, video player, image viewer, steam, ... all have been working incredibly well as Flatpaks. I also get free sandboxing for all of them, so for example Steam and its games, don't have access to my ssh and gpg keys or documents.
The only applications which don't work that well with Flatpak are things like my IDE or file manager.
Yeah but that the worst part of what they ARE and if they didn't have to spend so much time doing that maybe they could do more innovative things.
You know, that was never a problem when we had to package the other 500000 packages available in debian, just when users want seemingly popular packages updated more than once per decade. Firefox for starters.
That's ... kind of the job of a distro maintainer.
But isn't that the primary job of a distro?
For software that they can't do this with, or that isn't worth their time, they just omit it from the package manager.
Nonsense. Developers can do their thing, and distro maintainers can do theirs. The two have very different priorities and goals.
I'm perfectly happy downloading the latest version of hip package X directly from the developer's website while relying on distro packages for all the boring, stable stuff.
The whole "it's either all hip or all boring" is a false dichotomy.
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 to some third party app store thingy.
...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.
Not being facetious, genuinely curious.
https://askubuntu.com/questions/1259840/why-an-old-nodejs-ve...
Nodejs v4.x was "new" when Ubuntu 16.04 LTS came out. It was added to its apt repos, LTS releases are supported for 5+ years, and LTS policy is not to update major versions of software within a release.
So while nodejs was pumping out new major versions every 6-months, people running Ubuntu 16.04 and installing "apt-get install nodejs" were stuck on the same ancient version.
Actually, I think the LTS mentality is one of the bigger problems in security right now. The hardest problems I've had to deal with in tech all stem for LTS:
* Getting an not-substantial budget to update an essential but forgotten server with custom software and an unpatched heartbleed problem.
* Convincing developers to even look at old web services that have massive SQL injection and were built with libraries with known (six years ago) exploits, all running on some 13 year old version of RedHat.
* Inevitable meetings where you try your best to avoid saying "I told you so" when a disclosure, cryptolocker or malware infestation happens because of the above. These are no fun because they quickly devolve into career-end bingo.
From a security point of view, yes, you have a point.
But I blame the problem on the industry shift to lumping security and feature updates together. I hate, and prevent, automatic software updates because I don't want feature changes to happen except if/when I'm ready for them. Feature updates are very disruptive, and sometimes break things horribly.
If I could just get security updates, I'd allow those to automatically happen without thinking twice. LTS releases were a (poor) compromise to accomodate those of us who can't, or won't, take on random feature updating.
Sadly, the LTS time periods are getting so short that they're often not effective for this purpose anymore -- so in those cases, I resort to blocking updates entirely until I'm ready for them.
That's also a bad security place to be. I just don't see any other way to handle it aside from separating security and feature updating, like we used to do. But that's not going happen. So all I'm left with is LTS releases and blocking updates.
These should be absolute exceptions, not the rule, anyway.
Quite a few maintaining teams are the exact same people in Debian and Ubuntu.
While I wouldn't call Flatpak "popular" with users per se, it's probably one of the least-worst alternatives that have come out. The horse Ubuntu has backed (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt), but that's not going to make the debate go away: it just strengthen's the argument to return to distro packaging.
Care to expand on this? I'm not in Ubuntu-land but can't imagine how a service with an open protocol and multiple clients forces you onto Snap.
This wouldn't be the worst situation (devs needing to more time preparing myriad distribution formats is a valid problem) if the specific 1 channel being used wasn't a broadly resented channel.
Sure, packaging software is a bit of a thankless task, but with enough automation, packaging thousands of bits of software on every git commit should be doable by just a few volunteers.
1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc...
2) a standard format for declaratively describing how to build a package.
Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templates, Gentoo ebuilds - they all do more or less the same thing in the same way, they all work really well, and they're all incompatible for sheerly incidental reasons. I'd like to see these incompatibilities papered over in such a way that I can write one template and generate all the others.
Configuration options will need to be specified manually if you want any but I don't see a way around that as they are both package-specific and also something where distros want to differ.
For dependencies there are usually language-specific registries and pkg-config for C/C++-land. Some distros (e.g. RPM-based-ones) already support specifying dependencies by the pkg-config names or library SONAMEs. There is no distro-agnostic way to specfy your dependencies except for a README as far as I know - this would be something worth specifying.
It's not as if package formats can't be declarative - just that some issue always turns up in package X or Y that the declarative format didn't anticipate.
I think there may indeed be tools to convert these formats but in the end the devils are always in some distro-specific set of details that make life miserable. e.g. your library has some option enabled or doesn't and some other package in that distro needs it and so on and on.
I much prefer the f-droid model, of having curated repositories to keep crap outside.
Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the authors.
Bugs should be fixed upstream, not kept in distro specific silos. There's no reason why only a packager can fix some upstream issues or become a contributor. On the contrary shipping your app as a universal tech like flatpak means Redhat, Debian, Arch or any other user can use it, develop for it, and send fixes upstream.
This is mostly a Debian issue fwiw. Debian is literally notable because they're obsessed with making sure that any package in their repositories is kept with the same "API"[0], no matter how old the software is. The result is that Debian packages can end up hugely derivative compared to the equivalent of upstream and other distros, but it's usually also because the software in question is half a decade old.
With other distros, packaging changes to upstream usually just reflect the preference to match a certain style of configuration (to pull another example from Debian: nginx ships with sites-{enabled,available} folders and is configured to load from sites-enabled by default. This is to match the same configuration style that's used for apache2 and that it's associated tools assume you configure apache2 with, even though nginx just uses a conf.d folder and has no extra tools to facilitate anything fancy with sites-{enabled,available}).
The extreme end is nix, which actively requires you to have the upstream written with nix in mind because nix will basically demand you configure the source code in ways to accommodate for it.
[0]: This includes actual software-intended interfaces and the ones hacked together by users by ie. reading out logfiles.
I'm pretty sure this isn't true.
What does upstream emacs have to do for Nix to provide https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/appli...
I will agree though that applications which have their own update mechanism or do other things that make reproducibility harder are much more difficult to create a Nix expression for.
No other desktop OS has done it like Linux and for good reason. People have been citing this as a reason they don't want to use Linux as a desktop for decades to mostly deaf ears, who then turn around and wonder loudly why no one wants to use their OS. Hell, even Linus Torvalds himself complained about it.
If you want the dystopian hellhole you seemingly long for, just use Android and enjoy the ad-infested crapware? No reason to moan about things you seemingly don't understand.
For decades, Linux package managers have been the killer app for Linux. They made installing and updating every single one of your applications trivial. You didn't google for sketchy download sites and unsigned exe's. You didn't have to fight the system to cleanly uninstall things. Even release upgrades were the smoothest thing ever. In 25 years, I've never had a Debian release upgrade go wrong.
Anyone bitching about package managers as user hostile is a flat out idiot.
If a package is not in the repo? Sorry, you have to compile from source. Want a newer version? Compile from source and hope that the build environment dependencies are in the repo. Want an older version for some reason? Break out docker or KVM so you don't break your system.
None of this is fundamental to the model, that much is true, but in practice it is how all Linux distributions using a package manager/repo model without things like Snap, AppImage, and Flatpak work.
Here's the best part though: Even with Flatpaks and AppImage you can still use a repo! In fact Fedora Silverblue, which uses an immutable base system and installs everything through Flatpak and Toolbox, uses a Fedora controlled Flatpak repo by default.
[0] http://saimei.ftp.acc.umu.se/pub/debian-meetings/2014/debcon...
I personally do mind very much. Just the differences in startup times between apt and snap applications are huge and I would absolutely despise working with such a sluggish system. I would rather build everything myself from source if forced to.
First of all, there is no such thing as an average user. Also, it is not relevant to the discussion. I care about what I want in a system, not what some imaginary users want.
Now, we could stop there but I will play: Electron solves a real problem for developers. Writing cross-platform GUI apps is a real pain. Yes, there are native solution but ensuring the user has the exact same experience on every platform tends to be orders of magnitude more costly compare to web based solutions. (That or they are exotic options like Lazarus with Free Pascal that have a much lower Developer pool.) Many apps wouldn't even have Linux ports if they were not written on Electron.
Now, why do users accept them? Why are they not out-competed by native solution? Oh, honey. Why do I have Microsoft Teams installed? Because I like it? Hell, no! Because I need it for work. Why do I have the Discord Client? Because it is great? Nah, I long for good old IRC but Discord it there the people currently are. Did I think the Epic Games launcher is such an great app? Nah, they bought me with offering free games.
Users tolerate shitty software for many reasons, mostly because they have to. It does not follow from that, that they don't mind software being shitty.
In which case I hope you are prepared for software to get many times worse, because the software industry doesn't give a tuppeny fuck what you want in a system, they care what sells to the lowest common denominator. And that means slow, bloated electron web sites shoehorned into the desktop because the pool of mediocre JavaScript developers that can extrude a minimum viable product is huge compared to the pool of native developers of any language.
And it will continue this way for as long as it's accepted. So, forever basically, because the average user you claim doesn't exist will put up with anything placed in front of them without significant enough complaint to impact profits.
You keep trying to hand wave this relatively straightforward point: users are already used to, and accepting of, slow and bloated applications. Therefore, the downsides that app containerization introduces are irrelevant to most people that will use them.
With maintainers in the loop, there is at least one more person that can notice something is fishy. Not to mention there is usually so time before packages are updated, so there is more time to notice an attack.
Also one more person who can inject malware or break something. How did that Debian keygen issue happen again? Oh right.
The people on the openssl mailing list said it was fine. That's how it happened.
You have apparently no idea how much it costs to recompile everything, every single time that openssl fixes a bug.
upstream didn't build with all the dependencies at the same version as the latest in the arch repo. Nor are most upstream developers bumping all their dependency versions constantly
if you're a big player like ubuntu/debian you can go to the authors/upstream and ask them to fix the program to work with their dependency versions (in say.. an LTS release). most would be glad to bc it's just something upstream needs to do once every couple years and doesn't need maintenance. If even thats too much and yyou want esomething even more handsoff/timeless then you make an Appimage. It'll work for ever
With Arch youd need to constantly monitor the thing doesn't break？Are they just #yolo'ing dependency versions most of the time ？ (itd prolly work 99% of the time..)
Right now e.g. there's openssl (still at version 3.0.x, because nobody supports 3.1.x yet) and openssl-1.1 (1.1.x-y) to handle the rather slow migration of upstreams to the new major release.
You're expected to run most apps as flatpaks.
It's probably one of the most solid Linux distros at the moment and their website makes it seem.. boring.. No screenshots, features, mentions of whats available (like apps), that Fedora uses newer graphics/drivers kernels, that you can run Steam, that apps are sandboxed etc.
Stark contrast to something like https://vanillaos.org/
The caveat is, there's no common baseline for libraries. Graphics libraries, the libc itself, GUI widget libraries etc. will appear in different version combinations in different distributions, since they have different release schedules.
So if you want to go the Windows/MacOS route and ship a readily compiled program for Linux, you have to vendor in a loooot more libraries, and they have a higher risk of breaking due to incompatibilities (kernel interface for your graphics driver changed, configuration file syntax for your font renderer changed, etc.)
Flatpaks/snaps try to solve this (poorly) by vendoring the entire kitchen sink and then some, which just creates more bloat and a worse DLL hell than Windows could ever have dreamed of. So using it for everything isn't really feasible still.
Simply don't vendor glibc and graphics drivers and you will be fine. Vendoring drivers doesn't make sense anyway as your application will be obsolete by the next HW cycle.
And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly.
And that sort of software doesn't really obsolete. Steam and GoG allow games to have a 10+ years long tail of slow but steady sales that don't really justify constant maintenance releases but still both let people enjoy good games (those don't really obsolete), and serve as advertisement for the developers' newer games.
Neither of this is true.
> And there is a lot of more obscure examples: fontconfig e.g. at some point changed their config file format in a not backwards compatible way, and now some Steam games crash on startup because the developers earlier vendored it to get around its ABI breaking repeatedly.
Bundling fontconfig but not it's internal config is retarded, yes. Really, games have no business looking at system fonts at all.
Honestly, if you just want the naked OS, you don't need a distro at all.
Or just don't use the package manager.
And to a degree, the line is blurry with Windows as well, what with how deep MSVC/win32 is integrated into the system. .NET took decades to dis-entangle itself from Windows and become a proper standalone platform, and Microsoft's attempts at getting people to use UWP instead of win32 is ongoing and not very successful so far.
Interesting. It never occurred to me that there's a blurry line between the two. It seems to me that there's a very hard line between the two. I'm not sure I understand what you're saying here.
> For example, installing a C# or Go compiler on Linux is great with a package manager. But doing the same with a C or Python is different?
I'm confused by this question, so forgive me if this answer isn't really addressing it. A package manager is a convenience, nothing more. Using one means makes your life easier in a number of ways. But not using one isn't really that much more difficult. Package managers are 100% optional.
(I'm not the guy who wrote that comment but I would very much like this)
https://conveyor.hydraulic.dev/7.2/outputs/#linux
It works by downloading the Ubuntu package index and using it to look up ELF dependencies, devs can also extend the inferred list with other package names if they like. The deb installs an apt sources file and public key so users can stay entirely in the GUI. The control scripts are auto-generated but can have extra code appended to them via the config file if the developer so wishes.
It works pretty well. Conveyor is used primarily for cross-platform apps that use {Electron, JVM, Flutter, C++/Rust} and those don't normally have very complex Linux specific dependencies. Also, in practice Ubuntu and Debian and its various forks are close enough that package metadata is compatible in basically all cases.
People do ask us for Flatpak sometimes. Probably RPM is a higher priority though. Those two get most Linux users, they're stable, there are portable libraries that can make them and they can package anything without code changes. Flatpak requires mastering a new file format and the mandatory sandboxing is guaranteed to cause problems that will end up in the support queue of the deployment tool.
Two specific examples:
(1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not using the versioning scheme or naming convention. We're not doing it now but we may switch to statically linking this.
(2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages.
So imagine (1) and (2) ad infinitum times a hundred little distributions and Debian forks and... it's completely untenable. Static linking solves many of the problems but that defeats some of the purpose of package management.
We do it for all the major Debian and Ubuntu distributions by using a qemu-chroot based build farm that builds on each distribution+architecture combo with actual qemu binary emulation. It's over 200 gigabytes of chroots and takes two hours on a 64-core Threadripper to build all the artifacts. We tried cross compilation and had too many problems: it builds fine, seems to run fine, then users complain that some mysterious glibc symbol was missing on their system. We switched to building on actual chroots and most of those problems went away. Most of them.
Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs."
The only thing worse is Windows MSI installers and Windows drivers, though with those at least there's less platform variation so once you battle those horrors the result mostly works on most systems. Mostly. But whoo boy is the Windows installer system horrific. I shall quote Pinhead: "I have such sights to show you..."
Apple is the easiest because they have less legacy baggage than Windows and only one "distribution." They do have some horrors around signing and notarization and we don't distribute in the Mac App Store (yet?).
A major reason SaaS delivered through browsers is eating the world is the immense and totally unnecessary pain of distributing apps for major OSes. Even Apple is quite a bit harder than making a web site that you visit in a browser. All this pain is 100% the fault of OSes not caring about developer experience and in the case of Linux the multiplication of endless "vanity distributions" to no benefit to the community.
If you want packages instead of tarballs of OSes, Linux distributions could (1) consolidate and (2) invest some time in the very boring totally un-sexy work of massive amounts of clean-up and standardizing things as much as possible. But it's more fun to make another vanity distribution I guess. You'll get it right this time and everyone will switch to your distribution.
..wait a minute
> (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had security bugs that they would not upgrade because it would break other packages.
Wouldn't this solve the same problem without adding snap/etc?
We've invested a lot of time in this. For most developers I totally understand "fuck it."
You can still pacakge that distro-agnostic build up into distro-specific package formats to make updates easier for users without needing zillion of different build roots just for Linux.
I have some experience with packaging, and if we talk about standalone applications, dependencies aren't a big deal; production deb packages for different targets it's not difficult. The last (only) breaking change I can remember was old graphic libraries (I think it was gtk2-based WxWidgets).
This is one of the points they are missing with snaps and flatpaks.
These formats might be OK for desktops, but are absolutely awful for servers, containers, etc., which, incidentally, are where Linux dominates.
Do I want to spend my time worrying about setting up a package cache, because a handful of updates are costing me a small fortune in transfers? Why would I need to think about what snap is doing in my small instance with a 16GB volume, when I use it to run a certainly small application?
Snaps are an absolute nightmare in these scenarios.
Containers have already won the war on the Linux server, there's no point Flatpak etc trying to compete here. Additionally, desktop software is a complete design paradigm to server software. I wouldn't even say they make sense to be in the same package manager.
Although they do share tech, ostree, namespacing etc.
There are things that you just cannot run inside a container.
Also, in cloud environments, default provisioning is not done with containers, which makes sense, but directly causes the issues I mentioned, e.g. Amazon provisioning SSM on Ubuntu Server instances.
While probably still less efficient than a properly maintained and integrated distro, where all software uses a single set of shared core libraries, its actually (in the Flatpak case) quite optimized & has additional benefits, such as installing a set of apps that don't share a common set of required library versions, which would normally be impossible.
That's exactly what I want. Developers and Linux distribution maintainers should be working more closely with one another instead of reinventing static linking with "snaps" or whatever just to avoid working with the community.