Ullebe1

What do you do on your machine that requires you to completely disable a fundamental security feature of your distro? I haven’t had SELinux cause any issues for years.

Allowing any app unrestricted access to the input and output of any other app (like in X11) is a terrible security practice. It allows for trivially easy keyloggers and makes horizontal movement to other apps after the first has been exploited super easy.

Many people’s answer to this is “then just don’t run untrusted apps, duh”, but that is a bad take since that isn’t realistic for 99% of users. People run things like Discord or Spotify or games or Nvidia drivers all the time, not to mention random JavaScript on various websites, so the security model should be robust in the presence of that kind of behaviour. Otherwise everyone is just a single sandbox escape in the browser away from being fully compromised by malware installed with root privileges. Luckily we know better now than when X11 was designed and that is the reason for things like Bubblewrap (used in Flatpak for sandboxing), portals and the security model of Wayland.

And in the end: the people who decided this are the people actually willing to do the work to build and maintain the Linux desktop stack. If anyone knows what the right approach is, it’s them.

What makes you think that? The whole point of it is to create a rustc backend that uses libgccjit instead of LLVM.

Please elaborate.

It uses FCM for the notifications.

Proton uses XWayland, this is for proper, native Wayland support. It will make its way to Proton eventually.

Yup, and I believe it even does it automatically if it fails to reach the desktop for a number of boots in a row.

Depends on which DE in which version it is using, but anything with recent Gnome (Fedora, Ubuntu) will. Not sure if KDE distros generally default to it, and for more niche DEs the answer is probably “no”, unless it was explicitly made for Wayland.

I doubt it’s ever going to be a part of the core protocols, but it doesn’t have to be, you can just use Waypipe.

Can’t Waypipe do this?

Won’t most of those pieces of software work on xwayland?

It is supported by systemd to use FIDO2 + pin to decrypt luks partitions with many security keys, including Yubikeys. I use it every day on my laptop.

Seems like a solid bunch of iterative improvements!

I live in a time where I don’t need to edit config files by hand to allow using multiple applications with the same audio output, since I use a sound server. If you’re willing to do it by hand, then by all means continue. Though it does seem that ALSA has had support for automatically setting up dmix since 2005, after PulseAudio was released.

I also don’t know if resampling and the like is automatically handled when using dmix, but perhaps you can tell me that, since it sounds like you have experience with it?

Reading the fucking manual suggests that […]

How about we keep a good fucking tone. Yes, that’s great. However my experience is that programs all want to set those properties without a way to disable it, so in practice it doesn’t really matter.

Yeah, as you mention hardware mixing used to be an option, but AFAIK hardware generally hasn’t supported that for a long time.

Another reason to use Pipewire is to enable sandboxed access to multimedia devices, for use with things like Flatpak or Snap.

For the multiplexing, as I mentioned.

A V4L2 camera can only be opened by a single application at a time, but if that application is Pipewire, then Pipewire can allow multiple applications to make use of it simultaneously. Same thing with ALSA, it’s the reason sound servers exist at all, though I suspect you’re already familiar with that.

I also hear that ALSA has some support for multiple applications per device nowadays, though I understand it is much less pleasant to use than a fully featured sound server.

Because it is convenient for programs to use Pipewire for screensharing, as those programs can then also use the same Pipewire support for all their audio and webcam needs. Also Pipewire is good at multiplexing the various media streams.

Because Pipewire only handles and understands media streams, so it can stream the output of a window or the whole desktop, but only because the Wayland compositor has already composed the windows and other data it gets from the application to a visual and hands the final result to Pipewire.

IIRC the debacle about theming was:

a. Only about programs using libadwaita b. About their opinion that just overriding the global style like in GTK3 was causing too many issues in apps defining their own widgets or CSS to be worth it.

IIRC they were willing to accept a contribution of a more advanced theming system (but building it themselves was not something they wanted to prioritise over other things), but lacking that they’d rather enforce using adwaita in libadwaita.