Please elaborate.
Please elaborate.
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.
I did, yes. TBH it is very anti-Matrix right out of the gate, makes a mountain out of a molehill and it even admits that it contains FUD.
There’s a couple of things that are misleading in it (for example the section on bridges) and the critique basically boils down to “if you use the identity servers that are run by Matrix.org with your self-hosted homeserver they can see the info you send to them” and “Google Analytics in Element is bad”.
All in all I didn’t find it very convincing, and very lacking in nuance.
deleted by creator
Do you have a source for the claim that collecting userdata is ultimately what funds Matrix?
Does this support DRM protected streams, for example with Widevine? Whether one likes DRM or not, it is clear that support for it is a hard requirement for any streaming apps to support this.
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.
I generally call democratic countries “countries” and I occasionally call undemocratic countries “regimes”.
Yes, most (all?) Western countries are democracies. Yes, China is not a democracy. What is your point?
western regimes
Lol.
I guess that depends on which power your agenda aligns with. That power is generally a safe choice, compared to services from a power where your agenda is orthogonal.
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.
What makes you think that? The whole point of it is to create a
rustc
backend that useslibgccjit
instead of LLVM.