A Peek into the Future of Distros

https://venam.nixers.net/blog/programming/2021/01/26/future-of-distros.html

by todsacerdoti • 5 years ago

44 64 5 years ago

venam.nixers.net

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?

smitty1e2• 5 years ago

Sounds like a great business model for a RedHat or someone to sell subscriptions for curation and other tedious, yet needful, noise filtering.

dane-pgp• 5 years ago

"My own app store. Unauditable binary blobs being downloaded by lazy devops."

https://www.youtube.com/watch?v=_cdEFF-ttLw

nayaketo• 5 years ago

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.

linkdd• 5 years ago

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.

viraptor5• 5 years ago

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.

diffeomorphism2• 5 years ago

The AUR very deliberately does not offer packages but pkgbuilds.

vindarel• 5 years ago

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/)

ldng• 5 years ago

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.

esarbe4• 5 years ago

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.

alxlaz4• 5 years ago

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.

teekert7• 5 years ago

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.

warkdarrior• 5 years ago

Electron-based terminal is your starting point: https://hyper.is/

teekert7• 5 years ago

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.

est31• 5 years ago

This already exists in the form of Chrome OS.

teekert7• 5 years ago

I want my OS to have me as it's primary focus, not some company.

dingaling• 5 years ago

Why not just boot to Electron?

frankzander• 5 years ago

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.

teekert7• 5 years ago

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.

jclulow• 5 years ago

D-bus is fantastic in its own right and good at abstracting functionalities.

This feeling about D-bus is, I feel, not universally experienced.

venamresm__• 5 years ago

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...

esarbe4• 5 years ago

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.

viraptor5• 5 years ago

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.

alxlaz4• 5 years ago

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 :-).

throw89328942• 5 years ago

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...

Xunjin• 5 years ago

OpenSUSE Tumbleweed is a breeze, seriously kudos for all of them :)

esarbe4• 5 years ago

.... 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.

throw89328942• 5 years ago

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.

Fnoord2• 5 years ago

There is doas as replacement.

jabl2• 5 years ago

Some kind of sandboxing (mumble mumble containers) is necessary for the Linux desktop. In 2021 the security threat to a desktop user largely isn't other users on the same box poking around in your files, which is what the POSIX permissions protect against, but that every process you run has full access to all your files.

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.

enriquto3• 5 years ago

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.

jabl2• 5 years ago

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).

marcthe12• 5 years ago

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.

viraptor5• 5 years ago

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.

eeZah7Ux2• 5 years ago

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.

zxcvbn4038• 5 years ago

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.

curt152• 5 years ago

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).

viraptor5• 5 years ago

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.

ohazi• 5 years ago

Has anyone here played with systemd-homed? Any positive/negative thoughts? Been meaning to try it, but haven't had the time.

dvh• 5 years ago

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.

deaddodo2• 5 years ago

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.

gggtt• 5 years ago

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.

Fnoord2• 5 years ago

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.

A Peek into the Future of Distros

Related Stories