Canonical's Snap system is intended to solve this. Snaps are packages that bundle their dependencies, so they are bigger, but they run successfully on most modern versions of Linux.

https://snapcraft.io/

AppImage solves the problem in a different way, although AppImage doesn't have a concept of automatic upgrades like Snap:

https://appimage.org/

I suppose one could put an appimage in a snap, leading to either the best or worst of both worlds.

One of the problems with these systems - maybe they've solved it by now? - is that they bundle up virtually everything for a running system, including the GUI - so any custom theme you have outside of the "package" doesn't translate over.

There are other downsides, too.

At the same time, the upsides of such systems are really nice; they are very much reminiscent of MacOS apps - and that I really like. If the whole theming and such can be fixed - it would be perfect.

Unfortunately they have to do that, because there the only thing you can count on being present in any given Linux system is the kernel.

They don't really need any new system for that, apt can perfectly handle that.

For example, they could have an optional "recent applications" repository that you add if you want up-to-date applications. This way Firefox, LibreOffice, etc would be up2date but the system would be stable.

If you install Chrome on an LTS by the way, it will come with the Google repository and be always up2date.

> although AppImage doesn't have a concept of automatic upgrades

It does: https://github.com/AppImage/AppImageUpdate

Thanks, I had no idea. I don't know how to update the AppImages I use except by downloading new AppImages manually.

I really really wish AppImages were embraced by more of the Linux Desktop community.

> although AppImage doesn't have a concept of automatic upgrades like Snap

And that's a good thing. If I wanted my system to force software updates on me, I'd use windows.

Users should always have the ability to control updates. Always.

I use snaps at work and they are damn slow at opening, insomnia takes a got 30 seconds to open and viscose takes 5-10.

I7 4/8 16gb and ssd. Laptop isn't a slouch

I think snaps magnify developer mistakes. These are probably really badly written nodejs apps.

I have tons of snaps and the only one that is really slow is Cura.

thanks so much for saying this. It has always baffled me. On a desktop I want to run up-to-date applications with a stable system, I don't want a feature freeze. Ideally the OS is a platform where software runs on, not in, with a standardised, backwards-compatible surface.

I'm only an occasional linux user as a developer, I never dove into the history or the design. Is there a particular reason why linux distributions couple the system so heavily with the application layer?

When I ran Gentoo Linux, a rolling release, I came to appreciate exactly what's going on in the Linux desktop ecosystem. I enjoyed the new features that came with new releases of libraries and apps, but it was shocking to see how often library releases had new ABIs. Sometimes I could get away with running apps on old ABIs, but more often than not I would see stability issues, and those stability issues disappeared when I recompiled the apps. I learned that there are simply a lot of improvements happening at every layer of the system, all the time, and there is no one in charge.

The proprietary solution to that instability is to appoint people who ensure ABIs don't change. Microsoft is a great example of that strategy. Many apps made for Windows 3.1 still run today on Windows 10, almost 30 years later.

The typical open source solution to ABI instability is to freeze library ABIs and build all the applications on those temporarily frozen libraries. Applications are built for a particular release. While it would be possible to keep updating the applications during the release cycle, it appears no one has yet figured out how to do that economically.

An interesting exception to the rule is web browsers. Firefox and Chromium get regular feature updates in major Linux distributions. That's probably because browsers have a very large attack surface, yet people use them all day long, so they deserve extra attention from software distributors.

I think this is a very reasonable complaint from a user. I get a lot of arguments against thing like this from an admin and os perspective.

In any case Things like ostree and flatpak seem to be heading in this direction.

There are snaps and PPAs for this.

At least the PPAs are actually a better solution than a platform like Windows (whose "system" is separated from "application"), where you download binaries for upgrades, since you have visibility of the source code and build process.

I have around two dozen PPAs for the software I need to keep up to date. In the past, I used to upgrade Ubuntu on every release; now, I barely do it on every LTS.

As a quasi-fanatic Linux user, I can say that the one thing I envy from Windows is installing things the Windows way.

Half of the time, PPAs don't work. Snaps and Flatpaks are a step forward, but they still require a central server for fetching dependencies.

AppImages are good.

> Half of the time, PPAs don't work

I don't believe this, and I suspect you're doing something unorthodox with your apt sources (it wouldn't be the first time I hear a story like this).

PPAs build from source on a vanilla platform for the given configuration, so they're guaranteed to have standard output (binaries etc.) and dependencies. When there is a problem with a certain configuration, such build won't be available to the user.

Can you list the PPAs that don't work?

I hate PPAs, and the entire repo model, because it's just so much overly complicated bullshit for a simple task. And they don't cover everything.

Example: recently I had need of the of the DOSBox debugger, which you need to enable at compilation. On Windows this was as simple as finding some zip file from someone who'd done it and extracting the executable. On my Lubuntu system though, it wasn't in the repo for my version, nor was there a PPA. It was, however, in the very newest repo for Ubuntu and required up to date dependencies and I didn't want to upgrade my perfectly working base system.

Ultimately I had to manually download the package and its dependencies, extract their contents, and use LD_LIBRARY_PATH and the like to get it to run out of a self-contained directory.

That's what's fascinating to me. All the technology is there to distribute portable self-contained applications on Linux, but basically no one does it, or they pull a flatpak and still tie it into the horrifically silly repo model (and still aren't portable!). Only AppImage makes any sense, but hardly anyone embraces it.

There's an interesting project from Fedora recently. I haven't used it yet, but I'm really curious to try one day: https://silverblue.fedoraproject.org/

It seems essentially to be what you want - separation of "system" and "apps". An immutable containers host with custom things running on top.

I don't think I've seen any software for many years that would target the latest non-LTS release. If anything, it's more typical that proprietary apps fall out of date and require obsolete packages from an LTS that's no longer current.

> The way Linux distros have no conception of separating "system" from "application" ..

That's a novel concept if you don't mind me saying so ;]

This is working well with nixOS: have a stable channel for the system and the unstable channel for the user.

Wake me when I don't have to learn a new language to use it or compile anything from source.

If you want immutability with a normal distro, like Ubuntu, use Darch.

https://godarch.com

With a very brief look, it seems like I still have to manually putz with a text configuration format (learning a new language) the same way I would with Nix.

The configuration is a shell script with regular "apt install" commands.

There is a config.json for defining inheritance only.

edit: Here are my recipes: https://github.com/pauldotknopf/darch-recipes/tree/master/re...

The secret to making this more bearable is to install your OS on a partition separate from /home - put home on it's own partition (ideally, different drives).

I did this - and it saved my bacon recently.

I had a 14.04 LTS install, from around the time that that Crunchbang "went away" (just before Bunsen and CB++). At the time, it was my upgrade (completely new system). I decided to make it look as close to CB as I could; in a large part, I was very successful and happy with the result. But when I installed the OS, I decided to put in on an SSD (with certain partitions done as ramfs, so as not to kill the SSD). My /home went on another drive.

All was good and happy, but over time, things became more and more difficult to get newer software, etc. Over the years I really buggered my system; the nearly final blow was doing a "hand-upgrade" to the latest gcc so I could get certain features needed to compile some stuff for a Udacity course I was taking (also got CUDA installed and working for that course as well). Doing this upgrade, though, ended up breaking a portion of the standard "upgrade" process to the point where it would fail if I tried to move to say, 15.04 LTS or similar. Even simple installs of software from the repos would sometimes throw errors in the logs. It was really messed up.

Then one day last year, I decided to try to upgrade my NVidia drivers, and in the process fubar'd the whole system; all I could do was land to a console. Ultimately, I ended up switching over to the FB drivers just to get X back so I could do some research easier with a browser, and to see what I could recover to. I decided that since my /home was still ok - that I would attempt to just upgrade the OS and see what happened pointing /home at the old drive.

So - I bought a new SSD and pulled the old one (so I'd have something to fall back on), and then tried out a variety of distros to see what things had gotten up to in the years I'd been away. I had considered just moving to Bunsen, but as I started to think about things, and research stuff, I decided that I wanted something less compact.

Ultimately, via a series of steps which I won't delve into, I settled on Ubuntu Budgie 18.04 LTS.

The install went perfectly, and it had no problem picking up my old /home partition and such; I ended creating a new user instead of going through the rigamarole of trying to get the old user and such all configured with the login system (I've been there and done that, and it's a damn pain); besides, that also allowed me a "backup" of my old user directory in /home - a good thing, I could move over what I wanted as I needed it or such, and keep the old one around for a while.

It turned out to be a fairly easy and painless upgrade. Since then, I've decided and stuck with the idea of not using any software that isn't from a repo, or .deb file or such. No more compiling from source and wondering where/what I have on my system. Instead, I either do without, or install it on a VM, or build a .deb package myself, or try a snap or appimage, etc. Basically, I'm trying to keep my system clean and "uncontaminated" so I don't fall into this issue of a broken upgrade system again.

Now I need to see if Ubuntu Budgie 19.04 LTS is available yet - when it comes out, it's supposed to have all the newer features of the latest Budgie desktop; I had played with that and the distro (I forget the name), but I didn't like the package manager that distro used; it felt too limiting since most things out there are distributed as .deb or .rpm packages, etc.