Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux.
Edit: Are snaps images? ...like containers?
Edit 2: answer:
> mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application
Sandboxing addresses AN issue but does not address any of the issues discussed in this article.
Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful.
Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do.
It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.
It seems to incorporate some novel ideas despite its obvious shortcomings.
I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update.
Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.
All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago.
Containers try to mitigate this problem but like a fever they often end up making things worse.
I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary.
If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits.
As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see.
Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.
As far as I can tell, snapcraft[0], the tool that allows the creation of snaps is open-source and on github. However the hosting server-side code is closed source.
> glibc (no matter what they say about having stable endpoints)
glibc does have a stable ABI. What they don't have is a frozen ABI so they will all new entry points. But old programs linked against glibc do and will continue to work fine.
> You can't run a program written today on the system repo libraries from 5 years ago.
You can absolutely write programs today targeting 5 year old ABIs. I agree that the FOSS toolchains could be more helpful there so you can just pass some compiler flag for the oldest glibc version you want to support but it is not impossible to achieve that on your own.
Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly.
The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
Yep. One of many reasons they're banned in our shop.
Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane.
Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade?
> an app quitting out from under me because it wants to update
This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted.
It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
Depending on the qualities your after, AppImage is also really great. Advantages over Flatpak are that they are completely portable (you can store them anywhere and run them from anywhere), and they don't require a special runtime or package management infrastructure of any kind.
AppImages are basically (kind of) statically linked binaries.
Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work.
I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
If you need this kind of packaging but want to retain freedom, just use an alternative solution like flatpak, which sandboxes from the get-go and lets you control what parts of your system the application can access
Saying "just use an alternative" seems overly dismissive of the complications that entails.
IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates.
IMHO this somewhat erodes Ubuntu's value proposition.
> Now I know it's not going to be Ubuntu or anything else derived from Canonical.
Why avoid Ubuntu derivates like Mint or Pop!_OS, though?
They're doing the heavy lifting of fighting Canonical on this issue. Maybe using one of those distros instead of vanilla Ubuntu actually strengthens the pressure that Canonical feels on this topic.
Why not EndeavourOS? It's based on Arch Linux, with minimal numbers of external packages; quite unlike Manjaro actually. You can just treat it as a standard Arch install, and even use the ISO to boot with wi-fi drivers and all and install Arch plainly, without the non-wifi and other regrets. EndeavourOS is pretty great; I personally use it as a live-ISO (XFCE environment) and just install Arch from within the live EndeavourOS booted iso. Just throwing it out there.
Hadn't heard the name but glad I did. I was going to look for a live CD distro with good NTFS read support for the old drive recovery. This sounds good.
Neat - "permissions that are defined by the maintainer of the Flatpak and can be controlled (added or removed) by users on their system" - https://en.wikipedia.org/wiki/Flatpak
I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.
Edit: Are snaps images? ...like containers?
Edit 2: answer:
> mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application