Jorge Castro: "The terminal experience is the…" - Hachyderm.io

I've got some awesome news for #linux folks today! @kenvandine dropped by my house on his way to Mackinac island and I got the full tour of #ubuntu core desktop. The TLDR is. It is not just good, it's looking _great_, and the better news is that it's the same model.

Which by the way, is available as a public image, people just haven't found it and realized you can splat it onto a disk. Everything I will talk about in this thread is all public, no secrets. Here's the lowdown:

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.

The base system will stick to LTSes but you'll be able to select your kernel channel from the usual suspects, so stock, HWE, etc.

And then certain components you can rev differently, so LTS base, with a newer kernel + mesa is how they'll do gaming support.

The terminal talks to the LXC api directly, there's no middle layer.

This is basically what I want project exo to be but they built it already with lxc and flutter.

The docker/podman experience is currently nonexistant. Your docker experience will be via the docker snap, which .. ok that's a choice, sure ...

Overall summary is, you really can't tell it's ubuntu core, which is what they're going for, sort of like how you can't tell I'm not using normal Fedora.

I pretty much agree with the model choices here, implementation details not so much, but ubuntu is moving faster than people think, the company is profitable and makes money _on the desktop product_, so it is funded.

So if you like #ubuntu it's pretty nice. No commitment on when other than what they've said already.

Was also happy to hear that they will be coming back to supporting ZFS better, which made me really happy. cc @jimsalter

"So I can get ZFS root on this laptop then?" wasn't answered, but you can tell they want to do it, it's plate juggling at this point.

Feel free to ask me anything about it!

@jorge Could you expand on "The terminal talks to the LXC api directly, there's no middle layer. This is basically what I want project exo". Is the terminal running in a distrobox-like environment by default? What is Project Exo?

@that_leaflet Yeah there's no "distrobox but it's for LXC". The flutter terminal app-to-lxc communication is all API driven.

Exo is the next thing @marco and I want to build, having the terminal just natively support containers without host interaction with direct communication to the container runtime: https://github.com/orgs/ublue-os/discussions/156

@that_leaflet @jorge This is the terminbal app he's talking about: https://github.com/canonical/workshops -- there's a few screenshots in the readme. It's available as a snap, so you can test it independently of Core Desktop.

@jamesh @that_leaflet Hah, all in the open the entire time too, well played.

@jorge Where can we find the image for it? Does anything special need to be done to launch it?

@that_leaflet No clue I only got to see the laptop, people should go look because the terminal was open this entire time and no one noticed it.

@Hashrack I didn't ask, this is for people who don't care about that and just want a finished end product.

@jorge I already looked for a bit but haven't found the image. Where can we find it?

@DiogoConstantino In the actions tab, go into one of the build jobs and the artifact is at the bottom.

I can think of a fine British gentleman who will find a way to make it real easy for everyone to play with it.

@jimsalter If you decide to do an article on this ping me, I'd love to get people up to speed on the state of this tech as it stands now as best I can!

@jimsalter Oh I'm sorry man, I always associated you with Ars and ZFS.

Well then, fresh 2.5 Admins content then!

@jimsalter And you'll dig this, we can do custom derivatives of CoreOS, so that means we can have atomic servers with ZFS with exactly what you want on it running out of a git repo, it's awesome.

https://github.com/ublue-os/ucore

@jimsalter Then you just do this with rocky/alma/whoever and you'd have an immutable, composable, openZFS-enabled server OS with it right on the image, no sync jank between kernel and openzfs, etc.

@felimwhiteley @jimsalter It's my last traditional Linux in the house because I don't fix what's busted.

For new installs moving forward on server? I have a plethora of healthy choices already, so I'm good to go there.

@felimwhiteley @jorge "dnf install" always cracks me up, because to me "dnf" reads Did Not Finish, like a 5k runner who gave up before crossing the line

@jorge I actually noticed that recently in a googling-myself-and-my-own-projects session, thanks to its inclusion of "sanoid" in the project page. looks super cool!

@jimsalter We have newer contributors just getting started, if you ever want to dive in ... your expertise would go a long way, even if it was advisory, just being in the conversation would be dope.

@jorge that sounds very interesting. Can you follow up in mid-July? I'm overwhelmed right now dealing with the fallout from Reddit's CEO being an entitled dipshit. :)

I'm scheduled to get a new Discourse instance up for our community on Jul 1 and I'm sure that'll be nuts for the first week or two, but I'd really like to get involved with your project once some of the dust settles.

@jimsalter I am on like year 4 of "This won't take long" so I can be patient lol.

Being on your radar is enough!

@jorge unrelatedly... When I'm reading your first name in my head, should I be hearing phonetic English "George" or phonetic Spanish/Portuguese "Jorge?"

I always assumed the latter, but my treacherous brain is trying to tell me I've heard you introduced as the former, so I figured I'd better ask.

@jimsalter I go by "George" but don't correct people. I grew up in the states so always went with the english version.

@jorge it's your name, up to you how it's pronounced. =) Thanks!

@jorge this sounds similar in goal to Suse’s ALP work. Big shifts from big players.

@keyboardg Yeah this is what I mean in my initial post with "the same model", I could have clarified that better.

I have this today with Silverblue other than the terminal, but hopefully now that people can see what Canonical is building we can get that cloud native terminal I want out the door.

@jorge I kinda build the same thing just using GNOME Terminal and the LXC CLI. I've been using it for a year or so full time.

https://github.com/ted-gould/lxd-terminal

It's all basically cribbing from Libertine on the phone.

@ted Do you remember ogra's `classic` snap that would do something like this? Using lxc too.

@jorge yup, that actually wasn't LXC, it was a chroot. Old school containers

@ted Oh dang ... the UX was nice at least.

@jorge yup. It was right for the time.

Image based is great for real systems day to day, but developers need more flexibility than that with their system. Provides some balance there.

@jorge I usually use snaps but the docker snap is one that I avoid.
Possibly you can run docker from the official docker repos, inside an lxc container, which is what I do on the desktop.

@DiogoConstantino It's at a minimum going to be 2024 before this hits GA but my initial reaction to the ability to run normal docker/oci containers was not a good one.

But I'm not sweating that because I think the userbase will make that clear.

@jorge I think snaps would work great as building blocks for a immutable system but I don't think they are good as Flatpaks for desktop apps. I would like to see Canonical giving up snaps as a front-end solution and specializing it for backend and services letting Flatpak for the desktop apps.

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

@jorge Yeah, I read recently that snaps adopted portals too some time ago. At least it is something very important to share between the projects.

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

@evasb @ramcq And part of the reason I'm rambling is that I tried this. Ok then, we formalize the the governance, do the thing, approach large organizations that are trusted to shepherd these kinds of things.

And .... that's a hard no because in order to compete we have to be important. And in order to be important we have to have a healthy ecosystem. And the only way to do that is allow developers to make money on the linux desktop.

@evasb @ramcq They don't return our calls. We don't even get invites, no cool parties for us.

So if we want the best realistic outcome, we need to prioritize getting app developers paid and Flathub is right here in front of us.

So the next time someone nitpicks about some dumb Flatpak issue, it better be more important than fucking paying open source developers.

@evasb @ramcq Otherwise another vendor gets that money, and sure, I like competition.

But we ain't out here trying to take some app store level cut, we need enough to keep the infra humming and sponsors like Fastly donate their infra to help make that experience better.

@evasb @ramcq So that's how I'm looking at this. So now that the diplomatic version is out of the way: