My biggest problem with them all is that I don't really have a problem with my apt.
I understand that this situation is problematic with vendors who want to distribute their apps. But to me it feels like that the packaging situation has always been an excuse for them to drop Linux support.
If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. And a lot of vendors are doing that nowadays.
Sandboxing would've been nice for sure. But again, I don't have a security problem with my Linux Desktop as of right now.
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal.
well, yes it is, because it only covers two families of distros over many. I develop a software with a fairly small niche and you wouldn't believe the weird distros on which people test it. With the AppImage, everyone is happy - and also the software can be installed without administrative permissions which is fairly useful when you want to use it in a class room without having to spend a week with the local system administrators to get the .deb deployed and just have the students download the AppImage and execute it.
It isn't really that hard to repackage it for any packaging format after extracting the deb file. I have used those distros(arch, void, now nixos) for a long time, i never had a problem with anyone providing just a deb file.
With my upstream developer hat and Ubuntu developer for about a decade hat on I really call BS on this. This is very hard in practice. It's hard even when you know things very well just because it is very complex and involves multiple pieces moving across multiple organisations and people.
Snaps, flatpak and appimage really make the aspect of distribution of free software less crazy. It is a hard problem to solve, we will get some things right and some things wrong. We will learn in the process. Eventually the platform may become useful for proprietary software but it will first and foremost improve for FOSS.
If you are on a niche distribution you are missing out 10s of thousands of applications because it is packaged for Debian or Fedora and not for your system. If you are on Debian stable you miss out that important update or that new feature that you won't have for the next months or more. If you are on the packaging side you know how it is like in the trenches.
I really cannot believe anyone who has done packaging or upstream development to not acknowledge those real world issues. Packaging is extremely hard because we all made it so.
Crazy novel idea; The FOSS developer could just give out the source code, maybe with some helper build scripts, and then users could just build the software on whatever platform they want. Maybe making changes to which features they need and which external dependencies they required.
Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro?
Nah, thats crazy talk. Lets repackage an entire OS so you can run an OS while your running your OS so you can listen to internet radio.
> and then users could just build the software on whatever platform they want.
most of my users are non-technical (yes, even on linux). Also, if you want to use a modern development environment this won't work: for instance, I use C++14 / 17 which restricts me to distros at least as recent as ubuntu 18.04 for building and cuts out an immense part of the user base. With AppImage it does not matter what OS my user is running - even if the OS isn't able to build my software, it will be able to run it.
> Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro?
won't happen. I have users on ubuntu 12.04 which still uses e.g. CMake 2.8 which is way too old and a frankly different language than CMake > 3.0. Even if it was another build system it would be the same problem : you would have to restrict yourself to the oldest released version still in used of the build system, which really really sucks because build systems hardly ever "get it right" in their 1.0 version.
It's not a crazy idea, just one that entirely limits the target audience to extremely technical people. Some people would like to make their software available to a wider audience.
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal.
There's also the issue of dependencies on other non-default packages. Do you ask the user to install another repository? Do you host your own repository and distribute the dependent packages in it along with yours? (Note this is much more complex than building and hosting a single .deb/.rpm)
Not to mention "desktop Linux" is not a thing. Supporting Fedora, Ubuntu and opensuse, for example, are all distinct efforts with only minimal overlap in terms of effort (think not just initial dev, but ongoing maintenance and testing).
Technically, they usually aren't "statically" linked as such.
They usually use dynamic linking, but then ship those dynamically linked libraries in the package.
This has the advantage that the user can still replace the libraries if they want (e.g. for games this is sometimes useful to replace the sdl build with one with more options enabled), and I've heard rumblings that the support for static linking on linux isn't all that great.
Your knowledge is incorrect. Snaps don't have to be statically linked. They use a mount namespace with a predictable set of libraries that are maintained and receive security updates. In addition the application can bring additional libraries but those are on the application developer to maintain (or delegate to a hosted service like build.snapcraft.io to rebuild on security updates).
Sure, you can do static linking, you just don't have to and this is not how snaps work.
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal.
Many developers don't have the resources to go through the whole process needed to get their app into the distro repo. In that case, I'd consider these package formats better than deb and rpm.
You can provide a repo hosting your software so that prospective users can add your repo. This is essentially trivial and can even be hosted for free.
After your user adds your repo updates will be handled automatically with the rest of the system and installs can be done in the same software management gui as anything else.
Schools almost exclusively use Microsoft Windows. Linux is almost exclusively used on servers, technical peoples workstations/laptops at work, and interested users personal computers.
Optimizing for users you wish you had doesn't seem optimal.
In the hypothetical school setting you probably want to actively prevent the user installing insecure crap in their home directory to the degree its possible to do so.
There's a lot of corner cases that break under static linking - anything that dlopen()s stuff using a private API is an obvious one, and that includes glibc.
> I don't have a security problem with my Linux Desktop as of right now.
Matthew Garrett (who does internal Linux desktop security at Google) gave a great talk at GUADEC about the current state of Linux desktops: https://www.youtube.com/watch?v=DUa-nnjjQcc
TLDR: It's not good. User-level processes have free, unrestricted access to all of your data, unless you use Wayland and desktop containerization.
I understand that this situation is problematic with vendors who want to distribute their apps. But to me it feels like that the packaging situation has always been an excuse for them to drop Linux support.
If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. And a lot of vendors are doing that nowadays.
Sandboxing would've been nice for sure. But again, I don't have a security problem with my Linux Desktop as of right now.