[exe.dev co-founder here] It is planned! The reason we have not got to it yet is it needs to be very different than IPv4 support. We have spent a lot of time on machinery to allow `ssh yourmachine.exe.xyz` work without having to allocate you an IPv4 address. The mechanisms for IPv6 can and should be different, but they will also interact with how assigning public static IPv4 addresses will work in the future.
We do not want to end up in the state AWS is in, where any production work requires navigating the differences between how AWS manage v4 and v6. And that means rolling out v6 is going to be a lot of work for us. It will get done.
> Great if everything that one wants from their GNU/Linux experience is a command line and TUI.
Regular GUI apps work fine on ChromeOS. There's a flag to enable the GPU in the VM and with it, 3D accelerated GUI apps also mostly work. It's not optimized for gaming if that's what you are referring to though.
> This project currently has a bunch of C++ files, no docs, no tests
I think the more important thing is the protocol itself, rather than the specific implementation. As the author notes the current D-bus standards are substandard at best.
I think one of the point from your parent comment is that something that works for people is a powerful way of making things happen, much more powerful than rants or theory or protocols. I also noticed that with cryptography algorithms/protocol for example: design the most amazing algorithm - no one is going to use it ever if there is no great reference implementation people can use.
> any app on the bus can read all secrets in the store if the store is unlocked
Holy shit. I knew conceptually that this was the case but never really took the time to consider the implications.
Pretty much whenever you unlock your keyring all your secrets are accessible by any software that can connect to the bus... How is this acceptable? Are we just supposed to run everything as Flatpak?
Funnily enough, my work macOS keychain maimed itself in such a way that I need to recreate it every time I install an OS update. Every time I recreate it, the OS spends a few minutes in a state where every application that needs access to the secrets store requests access through the keychain's password. Incredibly secure!
Turns out, that's every application, every few minutes, many of them multiple times. Applications like having access to things like refresh tokens so they can download your email, or discover passwords for offering autofill for a website.
I'd welcome many improvements to the Linux status quo, but applications not needing to ask before accessing the bus is the only reason it's usable in the first place.
It's acceptable because flatpak dbus and all its ilk are too opaque for the average "experienced" user to fully grok. The problems are there, but the situation is so convoluted that it's hard to build a mental model unless you truly understand the overall system architecture
The reality is no one wants to be prompted everytime for a password. They want it to auto fill.
In complaining about this people are setting the boundary at the wrong place, and in proposing solutions assuming user behavior which doesn't exist (they will absolutely click "yes trust random application I'm busy move along now please").
I do not want to be prompted. I do perhaps want grades of secret access but even then thats asking a lot - do you want my SSH keys? Well yeah I probably want to give them to you some app which is automating things over SSH. It's 5 more versions before you get updates to ship them all to Russia or wherever after an author hand over.
reply