This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.
There are two processes that need to be running that somewhat work.
xdg-desktop-portal & xdg-desktop-portal-wlr
Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used.
Might be better under Firefox, but chrome is spotty for me.
(as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly)
EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far.
At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release.
The sooner people report those crashes, the better for everyone involved.
DOSBox exists because DOS legacy applications still exist, and will continue to exist for a very long time. The same is true of X legacy applications.
Soon it will get to the point where the UI toolkits that matter will have ported entirely to Wayland and remove their X11 compatibility code. When that happens, all modern apps will be Wayland-native only. That leaves legacy apps and toolkits that haven't gotten with the program. For those, a VM running an old OS with Xorg will suffice. That is the "DOSBox equivalent" here.
[0] https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
If I can't run suckless terminal then what's the point of having a computer on my desktop? At that point I might as well kill the GUI altogether!
I haven't disabled Xwayland, but I have configured the apps that by default do not do it (in my case, Emacs and Chrome) to avoid Xwayland and instead to talk directly to Wayland.
(Gnome's interface design decisions are not very good IMO, but that's clearly not Wayland's fault).
At least some of comments on supposed defects in the architecture of Wayland seem to me to be written by long-time X users who simply do not like change. (I used MacOS for 11 years before I switched to Fedora and barely remember X.)
The problem for those that want to continue to use X -- well, Xserver to be specific -- is that nobody wants to maintain it.
I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it.
(I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems.
Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
There wasn't any good reason to change this.
>hur dur why depend on evil systemd
Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though.
And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."
If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them.
I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
>I recommend
No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows.
>That's on them
No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."
Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for handling it in an interactive program is because you want that program to persist when the tty goes away and almost the only things that do this are tools like nohup and tmux, not the processes that run inside them) then your crashed program is going to be killed by the hup signal when the user closes their terminal.
Yes you can contrive pathological examples, yes signals are hacky in general. You're never going to be able to come up with a real problem with this other than "misusing tmux and nohup to manage deamons instead of initd causes problems." There isn't a legitimate problem with handling the hup signal for interactive tools when the user is expecting it.
>RE: Discerning between states
Yeah if you want the OS to manage a process for you write a service. I'm not going to write a service for everything I do interactively that needs to not die if there's a network problem.
Again, because you seem to be missing it, handling the hup signal in an interactive program is just a way to tell the OS that the user is managing the program themselves. If the user does this and then decides not to manage it, "that's on them."
And finally, the real problem here is that systemd breaks stuff like this all the time and makes the platform unpredictable unless you spend time reading the release notes.
Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right?
This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly.
Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.
Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed.
> Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes.
> I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks
It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone.
I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes?
> But these are trivially portable
OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working.
> some manageable breaking changes instead.
This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case.
They didn't think and things broke. You don't get to paint that as innovation.
I'm really not a fan of software being this presumptuous. The root of most of my gripes with things like Windows and macOS (not to mention most of the things gnome/freedesktop puts out) are entirely because of this mindset. I am not interested in infecting Linux with this baby-proofing as well.
Security maximalists, especially when removing or refusing to implement useful functionality as a result of that stance, should be reminded that the first pillar of security is availability.
More to the point, you can always add the ability to do stuff like that, when you have the time to do it in a way that lets the user decide what should and should not have any given kind of access. On the other hand, if you start out by just letting everything run amok and then try to add controls later, assumptions will get changed underneath existing programs. That pretty much always makes things break in ugly ways... if it's even possible to do it at all, which is not guaranteed if you didn't think hard before you designed the function to begin with.
It's now something your 70 year grandmother who doesn't understand computers does.
Do you really think that Linux users are asking "why do you want that?" about screen sharing applications? Of course not. You can't implement screen sharing the same way you did in X, and software will need to change if it wants to support Wayland.
Which shouldn’t surprise anyone changing their display server.
> I don't want one process to be able to […] see what's displayed on another processes windows
But that is much easier to do than not getting soaked in the rain when all you have is a door in the middle of nowhere.
The traditional, greybeard way to deal with a misbehaving application is to stop using it. This “security” approach breaks all other applications instead.