The terminal experience is the same model as say distrobox, but it's built on lxc as you'd expect. The terminal is brand new, built using Flutter, and it looks native, I thought it was gtk.

There's a gui with the logos of each distro when you click it, with the ubuntu logo being the larger default, and then after setup the terminal just takes you there, similar to distrobox.

Here's boot on an xps 13:

The entire gnome session is sandboxed, and apps talk to the things in your CLI via the snap plugs (or whatever they call it, sorry my terminology might be wrong).

This session has no "classic" mode, but the classic vscode runs fine and can connect to the lxc container for dev work.

The desktop sessions can run on top of the base system, which will be based on core LTSes, so 22, 24, 26, and then the desktop can run on a channel so you can run different versions of GNOME let's say.

And then sessions like KDE, etc and be on the same system and they also run in a sandboxed environment, so the entire desktop itself is like this.

Most of the old apps you hate won't be coming with, they'll be replaced with flutter versions, so no more old update manager.

No gnome software, they are rolling with the community made snap store thing.

Resource usage is better than with classic ubuntu by a measurable amount, and you can tell on observation almost immediately, it's not as jank as usual.

@evasb They're not going to give up on that.

And the whole "but it's fine for servers and services" won't work as it's not suitable for that (despite what they tell you).

@jorge I don't like snaps at all. I like to argue that they are "fine" for backend just to be diplomatic.

It is kinda sad having this pretend half-closed universal packaging being pushed by the arguably most important distro on the desktop while Flatpak is a much better solution.

@evasb We're going to get the fruits of their portal contributions, and the hard part is getting apps to care about zero trust models.

For example, visual studio code will still not work right when it's sandboxed (that's why it's a classic snap), and the flatpak has the same challenges. Fixing the IDEs would make them work on both, and they have to integrate with portals anyway.

Sure, it's not my personal choice either but shrug, it's OSS.

@evasb I ramble on about "the cloud native linux desktop model" and people roll their eyes. Here's an exact example:

In Kubernetes each part of the stack has an interface. Two of them are: A container network interface (CNI), a container storage interface (CSI).

Those interfaces are part of kubernetes and maintained upstream, in order to play you have to follow those guidelines as they are codified in open source governance and an understood standard.

@evasb There are tons of CNI plugins you can use, some open, some not. Same with CSI.

Different consumption models, everything from your the worst nightmare to your ideal thing can use these interfaces.

So while I prefer all open stuff, it ends up, if you have a plug for vendors to connect to stuff that is maintained as an open standard, they can make money using kubernetes. And in order to be successful you have to care about the health of kubernetes.

@evasb Repeat this for just about every component in the stack.

Canonical has chosen a model where they feel they can add value, and while people might not like it (I don't), they have to talk to portals ... this is what @ramcq and I were talking about 2 years ago at LAS when we mean that Portals are the missing desktop API.

@evasb @ramcq The way to keep Canonical honest, is to hold them to that portal standard. So far they have been doing that.

And we have to accept that they want to choose this road, it's their money to spend.

So the way we do this (IMO) is to push for the portal standards and whatnot to be run in a similar fashion as it works in cloud. aka portals should have the same level of rigour governance-wise as you would expect in a cloud native project.