A Peek into the Future of Distros(venam.nixers.net)
venam.nixers.net
A Peek into the Future of Distros
https://venam.nixers.net/blog/programming/2021/01/26/future-of-distros.html
64 comments
> Presumably we don't want coreutils to come packaged as a container, but I don't have a clear answer to where the line should be.
Nothing should come packaged as a container. The home OS should containerize all externally obtained binaries, assigning limited resources to them, as chosen by the user. The package distributors do not get to decide what level of access do they need; from their point of view, all resources are available; but the user must be able to add limits from the other side, unbeknownst to the (potentially hostile) package distributor.
Nothing should come packaged as a container. The home OS should containerize all externally obtained binaries, assigning limited resources to them, as chosen by the user. The package distributors do not get to decide what level of access do they need; from their point of view, all resources are available; but the user must be able to add limits from the other side, unbeknownst to the (potentially hostile) package distributor.
> The home OS should containerize all externally obtained binaries, assigning limited resources to them, as chosen by the user. The package distributors do not get to decide what level of access do they need; from they point of view, all resources are available; but the user must be able to add limits from the other side, unbeknownst to the (potentially hostile) package distributor.
The problem is that the user can't be expected to know which resources an app needs ("Hey, this thing wants to access /usr/lib/x86_64-linux-gnu/libc.so, sounds suspicious, let's deny it"), but OTOH you're fully correct that the user must have the choice to deny specific access, perhaps by giving the app fake or empty data. So I think both are needed, so honest app developers can specify a minimum set of permissions the app needs to work to reduce the havoc a programming error in the app can create, but also giving the user opportunity to limit what the app can see (the user presumably want a word processor to be able to read and write a document the user is working on at the moment, but not everything in the users home directory).
The problem is that the user can't be expected to know which resources an app needs ("Hey, this thing wants to access /usr/lib/x86_64-linux-gnu/libc.so, sounds suspicious, let's deny it"), but OTOH you're fully correct that the user must have the choice to deny specific access, perhaps by giving the app fake or empty data. So I think both are needed, so honest app developers can specify a minimum set of permissions the app needs to work to reduce the havoc a programming error in the app can create, but also giving the user opportunity to limit what the app can see (the user presumably want a word processor to be able to read and write a document the user is working on at the moment, but not everything in the users home directory).
Why not a virtual/shadow FS? The application would be given a virtual home dir, and would try to access the "~/Downloads" folder, for instance, and then this would take the form of a macOS "Firefox wants to access your downloads folder". Then, OS can easily set up a mount on the container for that folder, with restricted perms.
Same with drag and drop. Data could be put into a folder in /tmp, a mount could be set up whilst it uploads your photo or whatever to Facebook, and then the mount and the temporary dir could be deleted.
Having a "shadow fs" displayed to the container so it can function as if it is not in a container, but then when it wants to access the actual fs, it is done via either prebaked whitelist or user interaction/confirmation, would be great because apps would not have to be modified and security would be incredible.
You could even have it write to shadow FS and that could be synced later.
Same with drag and drop. Data could be put into a folder in /tmp, a mount could be set up whilst it uploads your photo or whatever to Facebook, and then the mount and the temporary dir could be deleted.
Having a "shadow fs" displayed to the container so it can function as if it is not in a container, but then when it wants to access the actual fs, it is done via either prebaked whitelist or user interaction/confirmation, would be great because apps would not have to be modified and security would be incredible.
You could even have it write to shadow FS and that could be synced later.
You've basically just described Linux mount namespaces. Flatpak and snap applications each see a virtual root directory which grants no visibility into the user's home directory by default. D-bus services called "portals" then grant access to individual files upon user consent.
Sure, many resources should probably be enabled by default (e.g., read-only access to /usr/lib), or globally selected by OS profiles, for example. Apps can also declare sets of permissions that the users will be able to override as they like, and that would be really helpful.
My point is that the security must not be enforced by the package distributors. This is what happens when they ship containers, as snap and the like, and it is a disgustingly wrong policy. Security must be enforced by the OS, under the total control of the user, and with reasonable defaults.
My point is that the security must not be enforced by the package distributors. This is what happens when they ship containers, as snap and the like, and it is a disgustingly wrong policy. Security must be enforced by the OS, under the total control of the user, and with reasonable defaults.
Well the technologies behind containers can used independent of containers. For example with mount namespace you can modify filesystem layout, mem cgroups for memory limits and so on. There are 3 issues of these:
1) Several operation are root only or need user namespaces which has its own problems.
2)almost all of these operations are inherented by processor in similar manner as user of the process effectively making a need for some kind of sudo or polkit style solution.
3) some protocols and storage systems are implemented in userspace and are hard to sandbox making a need for proxy. Examples are Xorg, dbus, DNS, dconf.
So proxy and policy management is kinda an issue.
> Presumably we don't want coreutils to come packaged as a container
For base system utilities we already have sandboxing solutions. Either apparmor or selinux can do it quite well. Apparmor doesn't come with quite the number of profiles yet, but I see that my system has specific selinux labels on chsh, dmesg, hostname, and other common binaries.
For base system utilities we already have sandboxing solutions. Either apparmor or selinux can do it quite well. Apparmor doesn't come with quite the number of profiles yet, but I see that my system has specific selinux labels on chsh, dmesg, hostname, and other common binaries.
sandboxing != containers
Please stop confusing the two things. Sandboxing is about security.
Containers are mainly modern chroots.
> And also it seems processes and workflows are stuck in the 1990'ies further preventing progress
Quite the opposite, especially in Debian. The distribution has been driving a lot of innovative projects including reproducible builds.
> So some kind of base system + app store
A curated archive of software, reviewed by trusted packagers and thoroughly tested by a large number of users? It's called APT and existed a decades before "app stores"
> where the app developers can push sandboxed stuff
No thanks, I'll never trust upstream developers to sandbox their own stuff. Too many times I run into upstream developers thinking that the end user system is their playground.
Please stop confusing the two things. Sandboxing is about security.
Containers are mainly modern chroots.
> And also it seems processes and workflows are stuck in the 1990'ies further preventing progress
Quite the opposite, especially in Debian. The distribution has been driving a lot of innovative projects including reproducible builds.
> So some kind of base system + app store
A curated archive of software, reviewed by trusted packagers and thoroughly tested by a large number of users? It's called APT and existed a decades before "app stores"
> where the app developers can push sandboxed stuff
No thanks, I'll never trust upstream developers to sandbox their own stuff. Too many times I run into upstream developers thinking that the end user system is their playground.
> What this leads to is a base system that is stable, a solid framework to build on.
After using Linux for about twenty years now, I'd be very surprised if a stable -- let alone solid -- framework were indeed what this leads to :-D.
Edit: FWIW, I, too, think this is where Linux is heading, more or less. I don't have secret insider info -- this is just where the money and, thus, where most active development and commercial support is. I don't think it's a bad thing in terms of overall idea or architecture, but the implementation fills me with dread and horror :-).
After using Linux for about twenty years now, I'd be very surprised if a stable -- let alone solid -- framework were indeed what this leads to :-D.
Edit: FWIW, I, too, think this is where Linux is heading, more or less. I don't have secret insider info -- this is just where the money and, thus, where most active development and commercial support is. I don't think it's a bad thing in terms of overall idea or architecture, but the implementation fills me with dread and horror :-).
That might be what RedHat wishes it to be and push for. Does not mean they're right and that it won't fail.
Big opportunity for badly packaged crap and security nightmare.
Why? All these components -- polkit, dbus, wayland, pipewire -- allow for sandboxing of applications. Flatpak already makes use of that to isolate applications from the system.
If anything it will reduce the security nightmare.
If anything it will reduce the security nightmare.
There's a huge, huge chasm between allowing for sandboxing of applications and actually getting applications sandboxed. Flatpak can make use of that to isolate applications from the system but many (and I'm using that to account for recent changes -- last time I looked into it, it was most) applications on Flathub are packaged with full access to $HOME and/or the root filesystem.
It's not just a matter of technical difficulty, but also a problem of getting users on board: lots of them look at Flathub and -- quite understandably -- wonder why you'd want to jump through fifty sandboxing hoops to sandbox applications like Gimp and VLC, whose developers they trust and for which they get sandboxed packages out of their distributions' repos. The obvious retort that this isn't aimed at applications like Gimp and VLC feels a bit unsubstantiated because... what applications is it actually aimed at, then? Closed-source, potentially malicious applications like... what, if Linux had a lot of those, "the year of Linux on the desktop" wouldn't be a joke. And why not just run those in a virtual machine, which is likely to be a lot harder to escape from and also means you get to keep a "normal" *nix system as a host.
It's hard to get people on-board with sandboxing when most of them shrug and say they don't need it, and when -- if you squint a little -- it kindda turns out they're not entirely wrong, either.
It's not just a matter of technical difficulty, but also a problem of getting users on board: lots of them look at Flathub and -- quite understandably -- wonder why you'd want to jump through fifty sandboxing hoops to sandbox applications like Gimp and VLC, whose developers they trust and for which they get sandboxed packages out of their distributions' repos. The obvious retort that this isn't aimed at applications like Gimp and VLC feels a bit unsubstantiated because... what applications is it actually aimed at, then? Closed-source, potentially malicious applications like... what, if Linux had a lot of those, "the year of Linux on the desktop" wouldn't be a joke. And why not just run those in a virtual machine, which is likely to be a lot harder to escape from and also means you get to keep a "normal" *nix system as a host.
It's hard to get people on-board with sandboxing when most of them shrug and say they don't need it, and when -- if you squint a little -- it kindda turns out they're not entirely wrong, either.
To expand on this - only running trustworthy programs is a far superior approach to this threat model than trying to somehow contain the damage from malicious code running on your machine. Siloing programs so you can run random crap feels like keeping the interior doors in your house locked to slow the progress of home invaders, while leaving the front door wide open - it's the wrong security boundary and it inconveniences you more than the attackers.
Meltdown should have been the nail in the coffin for this philosophy.
Meltdown should have been the nail in the coffin for this philosophy.
why you'd want to jump through fifty sandboxing hoops to sandbox applications like Gimp and VLC, whose developers they trust and for which they get signed packages out of their distributions' repos
To mitigate zero-day vulnerabilities in applications that parse external data (such as Gimp and VLC)? Trusting an application does not mean that it does not have vulnerabilities that can be exploited in the future.
To mitigate zero-day vulnerabilities in applications that parse external data (such as Gimp and VLC)? Trusting an application does not mean that it does not have vulnerabilities that can be exploited in the future.
(Editing period is done so:
> for which they get sandboxed packages out of their distributions' repos
s/sandboxed/signed)
> for which they get sandboxed packages out of their distributions' repos
s/sandboxed/signed)
There are a lot of closed source apps available for linux.
Don't I know it. On the other hand, see the part about "if there were enough of those" ;-).
> A universal package manager with a single reposotiry where anyone can push
So no curation, no security guarantees, no quality control. This will give you many more apps, but most of them will be garbage, just see the google play store as an example.
Is "size at any cost" actually a good goal?
So no curation, no security guarantees, no quality control. This will give you many more apps, but most of them will be garbage, just see the google play store as an example.
Is "size at any cost" actually a good goal?
Play store is great imho. Yes there's a lot of garbage, but there's also a lot of great apps if you know where to look. For not so well known apps, read reviews and ask around on sites like Reddit and you'll be (mostly) fine.
Those steps are totally useless if you have quality/security control. I just look at the store and install the app.
I don't want to spend more than 30s to decide if I want to install an app or not. I definitely don't want to have to go on reddit for that...
Making sure the apps on the store are secure is not my job.
I don't want to spend more than 30s to decide if I want to install an app or not. I definitely don't want to have to go on reddit for that...
Making sure the apps on the store are secure is not my job.
The store makes sure that the app is secure (via sandboxing), but you need to make sure that it is actually the app you want (quality)
It could work with Guix: it already works as a universal package manager on top of your distro (with reproducible builds, rollbacks, potentially sandboxed…) and it works with channels: the official one, and others for non-free software etc. I use it on top of Debian to get the recent version of Emacs and some dependencies (vterm).
(https://guix.gnu.org/)
(https://guix.gnu.org/)
Sounds like a great business model for a RedHat or someone to sell subscriptions for curation and other tedious, yet needful, noise filtering.
"My own app store. Unauditable binary blobs being downloaded by lazy devops."
https://www.youtube.com/watch?v=_cdEFF-ttLw
https://www.youtube.com/watch?v=_cdEFF-ttLw
The whole point is that some Real Cash Money would help the signal-to-noise ration.
Aside: how long until the GameStop "Downfall" parody?
Aside: how long until the GameStop "Downfall" parody?
We already have this - AUR can be used in Arch. It... could be worse. I guess it works pretty well because of the small scale.
The AUR very deliberately does not offer packages but pkgbuilds.
The visions of a Redhat fanboy I think. I’ve started using Alpine linux for just about everything the last couple years. Instead of layers upon layers of redirection and obfuscation, gnu politics, and systemd doing it’s own thing, Alpine just boots and gets out of your way. It’s proven itself to me on both bare metal and in containers. It would not be an amazing desktop when compared to a Mac, but very few things are.
>It would not be an amazing desktop when compared to a Mac
On a Mac:
* apps are shipped in self-contained bundles
* launchd inspired the design of systemd
* the base system is shipped as an immutable image in a APFS sealed volume, and there's a clear separation between the base system and the user's apps.
So Macs actually implement the vision outlined by this article. In the Linux land, Fedora Silverblue probably comes closest (although comparatively lacking in polish).
On a Mac:
* apps are shipped in self-contained bundles
* launchd inspired the design of systemd
* the base system is shipped as an immutable image in a APFS sealed volume, and there's a clear separation between the base system and the user's apps.
So Macs actually implement the vision outlined by this article. In the Linux land, Fedora Silverblue probably comes closest (although comparatively lacking in polish).
It's not really a redhat fanboy. All the elements are coming to pretty much any not-minimalistic distribution. Alpine describes itself as "Linux distribution designed for power users who appreciate security, simplicity and resource efficiency."
There's a significant number of non-power-users who appreciate more advanced things working out of the box, even if it means more resources when not using all the advenced things.
There's a significant number of non-power-users who appreciate more advanced things working out of the box, even if it means more resources when not using all the advenced things.
> D-bus is fantastic in its own right and good at abstracting functionalities.
This feeling about D-bus is, I feel, not universally experienced.
This feeling about D-bus is, I feel, not universally experienced.
I'm aware, it's a half-ironic quote. Take a look a this article: https://venam.nixers.net/blog/unix/2020/07/06/dbus-polkit.ht...
Let me quote:
> D-Bus has also been criticized as being bloated and over-engineered, though those claims are often unsubstantiated and only come from online rants. It remains that D-Bus is still heavily popular and that there’s no replacement that is a real contender.
> D-Bus has also been criticized as being bloated and over-engineered, though those claims are often unsubstantiated and only come from online rants. It remains that D-Bus is still heavily popular and that there’s no replacement that is a real contender.
There's some work happening on https://bus1.org/
However yes, dbus exists. It could be improved a lot but it does its job. There are some valid issues, but I also get the impression that a large number of people criticising it never actually tried to use it or understand what it does.
However yes, dbus exists. It could be improved a lot but it does its job. There are some valid issues, but I also get the impression that a large number of people criticising it never actually tried to use it or understand what it does.
I regularly kill all daemons in my computer whose name contains the substring "dbus". Never noticed any problem with that, and everything works OK. I don't hate dbus, but I never understood what purpose does it serve, and it just annoys me to see it around.
D-bus is a process discovery and communication protocol. It allows processes to universally interact with each other in a high-level manner versus requiring bespoke IPC mechanisms (low-level sockets, signals, shm, etc).
If you just kill it without disabling the service it may be restarted both as a dependency when it's needed or immediately after killing.
Things like network service discovery, possibly network configuration, screenshots, Bluetooth, IME, and many others use dbus these days.
Things like network service discovery, possibly network configuration, screenshots, Bluetooth, IME, and many others use dbus these days.
My personal dream stack is having the best of Guix and Flatpak.
Flatpak is sandboxed with clear APIs & portal which is absolutely necessary (even for FOSS app, for eg. if Firefox has a leak we'd be happy it can only access the download folder and not our photos, documents, home folder, etc.).
But Flatpak sucks so much for development. The runtimes idea are totally overkill and not granular. Using libraries, packages, IDEs and coding tools is horrible with Flatpak.
Just look at the wierdness of running VSCode(ium) in Flatpak. According to flatpak / red hat guys the dream setup is :
- Remove the sandbox of VSCode through flatpak-spawn escape permission (so there no point in using flatpak...)
- From there call & enter Toolbox/Podman and install your dependency there using yet another package manager (dnf)
So you loose sandboxing, use two separate container tool & use two separate packaging tools.
So overkill & overengineered.
Now take Guix. You have simple dependency system (just list the packages you need), you have true (recursive) reproducibility, and you could have only one container system for everything.
The issue is that Guix containers are not compatible with Flatpak portals (which is now pretty much a standard) and, from what I understood, are not really meant for security but more for the insuring basic reproducibility.
If some Guix guys would be interested in developing/improving a Guix container system to be compatible with Flatpak portals&APIs and that uses Guix packages instead of runtimes, I'd donate quite a bit for that. Maybe some other people would be interested in that too.
Flatpak is sandboxed with clear APIs & portal which is absolutely necessary (even for FOSS app, for eg. if Firefox has a leak we'd be happy it can only access the download folder and not our photos, documents, home folder, etc.).
But Flatpak sucks so much for development. The runtimes idea are totally overkill and not granular. Using libraries, packages, IDEs and coding tools is horrible with Flatpak.
Just look at the wierdness of running VSCode(ium) in Flatpak. According to flatpak / red hat guys the dream setup is :
- Remove the sandbox of VSCode through flatpak-spawn escape permission (so there no point in using flatpak...)
- From there call & enter Toolbox/Podman and install your dependency there using yet another package manager (dnf)
So you loose sandboxing, use two separate container tool & use two separate packaging tools.
So overkill & overengineered.
Now take Guix. You have simple dependency system (just list the packages you need), you have true (recursive) reproducibility, and you could have only one container system for everything.
The issue is that Guix containers are not compatible with Flatpak portals (which is now pretty much a standard) and, from what I understood, are not really meant for security but more for the insuring basic reproducibility.
If some Guix guys would be interested in developing/improving a Guix container system to be compatible with Flatpak portals&APIs and that uses Guix packages instead of runtimes, I'd donate quite a bit for that. Maybe some other people would be interested in that too.
> The key innovation of the picture I lay above is that every layer in the system is now isolated and communicate with one another through d-bus services. D-bus is fantastic in its own right and good at abstracting functionalities.
It still annoys me that Linux went down the route of hald for so long, before making the pivot to dbus (and udev). Especially since I was using FreeBSD in the 00's and early 10's, which had devd (an event-based system similar to udev, vs hald's polling system) and had to be hacked for all those years to emulate HAL's interface.
It would be far less annoying if there were some benefits to HAL's approuch, but event-based systems had long since been proven in nearly every OS except Linux.
It still annoys me that Linux went down the route of hald for so long, before making the pivot to dbus (and udev). Especially since I was using FreeBSD in the 00's and early 10's, which had devd (an event-based system similar to udev, vs hald's polling system) and had to be hacked for all those years to emulate HAL's interface.
It would be far less annoying if there were some benefits to HAL's approuch, but event-based systems had long since been proven in nearly every OS except Linux.
I think overall experience on desktop will continue to deteriorate. In 2008 on Ubuntu 8.04 it was the last time I didn't have any video tearing. I used every lts ever since. When I recently upgraded to 20.04 it replaced existing vertical tearing with brand new diagonal tearing which is even worse. The whole system is more complex every year and install requires more tweaking in every new generation.
OS' only job should be to let use ran apps and every year they find a way to make it more annoying.
OS' only job should be to let use ran apps and every year they find a way to make it more annoying.
What I'm missing is Electron-everything. Teams as an electron app has made my Linux Laptop (with everyone in lockdown) our prime machine, everybody has an account, all with their own Teams account set up. Soon we will have Office365 in Electron. Then Adobe tools. And then we can do all the things Windows can do (with a grain of salt) and more.
Sure, this will receive a lot of hate (Electron eat ram mmkay). In the mean time I'm having MS Office on Linux. Real and official. What a time to be alive.
Sure, this will receive a lot of hate (Electron eat ram mmkay). In the mean time I'm having MS Office on Linux. Real and official. What a time to be alive.
I don't get what you are glad about. Yes everything nowadays works somehow on Linux.
Why don't you just use Windows or Apple? You don't obviously want open software for your work ... you only need software.
What a time to be alive ... jail yourself and jubilate.
I work complete without paying any cent for any licenses - because of open software. That is a reason to jubilate.
I work complete without paying any cent for any licenses - because of open software. That is a reason to jubilate.
I don't like Windows, I don't like Apple. I like Linux and open source. But my employer likes MS, and so does my kids' school.
Why not just boot to Electron?
Electron-based terminal is your starting point:
https://hyper.is/
It's not that I want it... I'd rather see native (of course), but if it will get us app parity with Windows, so my kids can grow up in Linux and still do O365, I'm happy.
This already exists in the form of Chrome OS.
I want my OS to have me as it's primary focus, not some company.
you want 'electron everything' putting google in control of all your apps, but you don't think they're customer focused enough to do the OS ?
That sounds like its not gonna work well...
(You could problably use how well Chrome has gone as a rough indicator...)
That sounds like its not gonna work well...
(You could problably use how well Chrome has gone as a rough indicator...)
I don't want electron everything. I prefer native FOSS everything.
Electron is actually the property of Microsoft (via GitHub [0]). So at least for Office there are no extra parties. And again, no I don't want it, but I want app parity with Windows so my kids school can't force me to put Windows on my machines. And no O365 in the browser is not ok, it offers a very poor experience imo. Just using the tab key in Excel online is maddening, although I expect one could get used to, I don't wish it upon my kids.
[0] https://en.wikipedia.org/wiki/Electron_(software_framework)
Electron is actually the property of Microsoft (via GitHub [0]). So at least for Office there are no extra parties. And again, no I don't want it, but I want app parity with Windows so my kids school can't force me to put Windows on my machines. And no O365 in the browser is not ok, it offers a very poor experience imo. Just using the tab key in Excel online is maddening, although I expect one could get used to, I don't wish it upon my kids.
[0] https://en.wikipedia.org/wiki/Electron_(software_framework)
>>What I'm missing is Electron-everything.
You actually said you wanted electron everything? Also, since electron is based on chromium...I sorta thought it was close enough to make my point.
You actually said you wanted electron everything? Also, since electron is based on chromium...I sorta thought it was close enough to make my point.
What Is said was indeed "What I'm missing is Electron-everything." TFA lists the new directions of distros, I'm missing "Electron-everything." in that list (Electron gives us new major apps we never had before and will continue to do so). I'm certainly not missing it in my life. Native O365 on Linux is unrealistic, they are even electronifying it on Windows.
A bit of a miscommunication there.
A bit of a miscommunication there.
Then stay away from electron.
Are we going to talk about SUDO security and its implications?
For me future is less, but more controllable features. Things like dbus based security, snap or "universe" repo on Ubuntu are absolutely out of questions.
I really like OpenSuse and its direction. Conservative, yet fresh packages. Automated testing. Curated yet substantial package base. Package manager integrated with BTRFS snapshots...
For me future is less, but more controllable features. Things like dbus based security, snap or "universe" repo on Ubuntu are absolutely out of questions.
I really like OpenSuse and its direction. Conservative, yet fresh packages. Automated testing. Curated yet substantial package base. Package manager integrated with BTRFS snapshots...
.... and still you need something to run those apps and utils like Signal or Threema and those will never get into the base system. It wouldn't make sense. And you don't want to burden the developers of that software to have to package their software n+1 times for every imaginable distribution.
Thus Flatpaks isolation and sandboxing of apps using "dbus based" security, pipewire and polkit.
Two sides of the coin of a stable and extendable system.
Thus Flatpaks isolation and sandboxing of apps using "dbus based" security, pipewire and polkit.
Two sides of the coin of a stable and extendable system.
Unaditable apps like that should not be allowed in core system. Get tablet to run this stuff (way better ergonomics) or run it in virtual machine.
Both these applications are open source. And even if I teach my grandma to start a VM everytime she wants to send me a message - they still have to be packaged for each and every distribution.
That doesn't seem practical.
That doesn't seem practical.
OpenSUSE Tumbleweed is a breeze, seriously kudos for all of them :)
There is doas as replacement.
Has anyone here played with systemd-homed? Any positive/negative thoughts? Been meaning to try it, but haven't had the time.
The near future of the Linux desktop, I suppose.
Article fails to mention innovative OSes such as NixOS or Qubes. I would love to see a combination of these two as a desktop OS.
Article fails to mention innovative OSes such as NixOS or Qubes. I would love to see a combination of these two as a desktop OS.
Meanwhile, the distro packaging process isn't keeping up with packaging all interesting FOSS out there, e.g. it has more or less completely dropped the ball on integrating with the many language-specific package managers out there like cargo, npm, pypi. And also it seems processes and workflows are stuck in the 1990'ies further preventing progress (e.g. https://michael.stapelberg.ch/posts/2019-03-10-debian-windin... ). Ironically people run more up to date FOSS on windows or macOS than on Linux, where you're stuck with the schedule of your distro. There's also the irony that some FOSS apps fund themselves by providing builds for money on the commercial app stores, but they have no way to similarly monetize Linux users (e.g. Krita).
So some kind of base system + app store where the app developers can push sandboxed stuff with some automated or human curating like the mobile app stores around now looks like a reasonable model. I guess this is what flatpack and snaps are aiming for. Also, where should the line be drawn between the base and the app store apps? Presumably we don't want coreutils to come packaged as a container, but I don't have a clear answer to where the line should be.