Prompt – A terminal for a container-oriented desktop | Hacker News Reader

Prompt – A terminal for a container-oriented desktop

blogs.gnome.org

127 pointsjcastro27 comments

This looks interesting but I'm clearly missing something. Could someone explain what does this terminal do for containers and flatpaks? Even reading the linked blog post didn't help me, probably because I only use containers a little and no flatpaks at all so I have no experience with what would make using them more confortable (if that is indeed the point?).

Thanks!

EDIT: Ah, looking at the screenshots on the project's page I see that it has a menu listing running containers which allows to directly open a terminal tab with a shell running inside the selected container. Is that it or is there more to it?

What about flatpaks? Do flatpaks actually work like containers?

> What about flatpaks? Do flatpaks actually work like containers?

From what I found[0] Flatpak can run OCI images.

[0]: https://docs.flatpak.org/en/latest/under-the-hood.html

> What about flatpaks? Do flatpaks actually work like containers?

No, the flatpak connection is that Prompt is designed from the beginning to run inside a flatpak.

Where this gets most interesting is if you're running atomic distributions like Fedora Silverblue. The idea is that the OS itself is immutable, i.e. when you get an update, the OS files are replaced wholesale, and you can't modify them yourself. Applications are installed in a layer on top of that via Flatpaks, and if you need more advanced tooling that's hard to run in a Flatpak (e.g. software development tools), you run those in a container - typically a container per project, or at least per stack.

The reason Prompt is interesting is that 1. I can install it as a Flatpak which, as mentioned, is pretty much a requirement for me to install anything (on top of providing sandboxing), and 2. it makes it easier to jump into one of my development containers, and to see which container I'm currently working in.

jcastro has a demo here: https://youtu.be/qeUH1_fFSUs

It just occurred to me that a container-based desktop is an over engineered statically linked userspace :)

Author here \o

People that know me know I'm not fond of the design of containers on Linux. But that's just because I've been stuck having to make things actually work on them. Transparent IDE support, making profilers, resolving ELFs from radically different mount namespaces, PTY API giving completely undocumented results, ...

But that said, we're stuck with them so might as well make it as pleasant as possible.

It seems to me we’re seeing something of a native GNOME application renaissance, both core and third-party, buoyed by GTK 4 and Flatpak (as well as the trend towards immutable base images). Rust seems to be part of this too—Loupe, Fractal, and Emmanuele Bassi’s recent GUADEC talk on oxidizing GTK¹ are examples. There are now three newer VTE-based terminal emulators targeting a native GNOME UX: Console (C), Black Box (Vala), and Prompt (C). Is there something about VTE or terminal emulators that makes Rust less appealing, or is this just a coincidence? I’m curious.

Prompt will probably be my next terminal emulator. That inspector looks interesting. Have you seen Ghostty’s recent demo²?

1: https://www.youtube.com/watch?v=WVWrllJQJ_s&t=6155s

2: https://mitchellh.com/writing/ghostty-devlog-005#terminal-in...

I might be biased, because I'm the author, but I think GNOME Builder making it dead simple to install an IDE from Flatpak, create a GTK 4 application template in numerous languages, and click run/debug/profile/valgrind and you're off to the races had a lot to do with it. It even installs the SDKs and extensions for you so your new-developer setup is install, clone this url, click run.

We built Flatpak and Builder in concert from the beginning to foster this exact outcome.

But as for language? I already hack on GTK/GDK/GSK internals in C, a mix of C++ and C to contribute to VTE, and Builder is 250k of C with another 200k in associated libraries. I'm just better at it and language bindings are never an issue.

Makes sense. I should give Builder a try sometime. Thanks for your work!

So far prompt looks amazing, though it's crashing occasionally for no apparent reason. I'll try to track that down.

Are you aware that there is already a terminal for iOS with the same name? https://panic.com/prompt/

Kind of, when containers appeared on mainframes and early commercial UNIX systems (HP-UX, Solaris,...), the goal was security, and constrain applications.

It was Linux folks that decided it was also a means to ship developer machines into production, and now we're stuck with the revised meaning what containers are supposed to be used for.

Very cool, direct install link: flatpak install --user --from https://nightly.gnome.org/repo/appstream/org.gnome.Prompt.De...

I just started researching Project Bluefin a few weeks ago. Will probably make the jump to it as my primary development machine very shortly. Thanks for sharing this great project.

Come join the discord if you have any questions. It's very active and friendly. Reminds me of the old IRC days when I was first learning Linux :)

https://discord.com/invite/bluefinapp

Is this the server about Bluefin the Linux distribution? In the discussion chat the last 100 messages seem to be about Bluefin the cryptocurrency or something.

Hi @sureglymop , here's the main website for the Bluefin linux distro: https://projectbluefin.io

I'd love to hop in if there's a way to join in Matrix (via a bridge?).

yes! I've been using the nightly for a few weeks now and this is as close to the perfect terminal as I've found. I love the integration with containers, I do next to nothing on the host itself, instead using Distrobox and Incus. Prompt makes that delightful.

> To give Prompt the best chance at tracking containers and foreground processes a prompt-agent runs from the host system.

Interesting so is that a package that needs to be installed on the host or does flatpak allow running executables outside the namespace?

It discovers the location of `prompt-agent` from inside the Flatpak and executes it similarly to how it would execute a shell on your host. The socketpair() is passed in to do FD passing.

This of course only works because of careful selection of which GLibc API/ABI is allowed to be used. So far I've tested as far back as CentOS 7.

I don't quite follow how the prompt-agent is assisting here. But more importantly, is said agent tied to prompt or could the "container detection extras" be usable with other Linux terminals?

The application runs inside of the Flatpak sandbox and therefore has a different mount namespace, PTY namespace, PID namespace, etc. That makes tracking foreground processes for simple things like "is the user running something when they close the tab other than the shell" extremely difficult. You'll just get 0 back a the PID from the TTY API.

Additionally, being able to monitor container APIs in the long run will require more than file monitoring a podman json file in the user $HOME. It could connect to a socket for monitoring (like machinectl, etc).

All these sort of things really benefit from running on the host rather than the UI sandbox.

> is said agent tied to prompt or could the "container detection extras" be usable with other Linux terminals

In that it's bundled with prompt, but it's just a D-Bus API albeit on a private socketpair(). The agent is not much code though to copy.

I really like the "tab overview" interface and animations. Very slick and functional.

That's a standard part of Gnome! Gnome's Console and Web browser also use it, plus some third-party apps like Wike.

The big difference here from Console is that Prompt will do custom snapshotting for the TabOverview to make it fast. Otherwise it thrashes the glyph cache.

Of course, I also wrote the glyph cache for GTK, but it's just not something I can fix there.

I love that Ctrl+Scroll to zoom is built in! Always missed that in Gnome terminal and had to use Wezterm.

Reply on news.ycombinator.com