Luckily this will change next year with the new EU rules, as they explicitly call out allowing alternative browser engines.
Luckily this will change next year with the new EU rules, as they explicitly call out allowing alternative browser engines.
Proton uses XWayland, this is for proper, native Wayland support. It will make its way to Proton eventually.
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.
Can't Waypipe do this?
True. Luckily it seems Mozilla has been preparing for this in advance: https://www.macrumors.com/2023/02/07/mozilla-developing-non-webkit-version-of-firefox/
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.
Ordinary DNS requests are always plaintext and readable to anyone between you and the DNS server. So regardless of which DNS server you use, your ISP can see all your DNS lookups. For any amount of privacy for DNS, the minimum is something like DNS-over-TLS or DNS-over-HTTPS, the latter of which Firefox uses by default in some countries and supports everywhere.
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.
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.
That seems like a shortcoming in those tools, that I'd expect them to fix as Flatpaks are pretty commonplace.
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.
I mean most things are implemented as plugins, so you can just disable the ones with features you consider bloat.
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.
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.
Won't most of those pieces of software work on xwayland?
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.
Please elaborate.
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.
It uses FCM for the notifications.
What makes you think that? The whole point of it is to create a rustc backend that uses libgccjit instead of LLVM.
Yup, and I believe it even does it automatically if it fails to reach the desktop for a number of boots in a row.
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.
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.
Even people on Arch should use it. It ensures better isolation of processes and is the only supported installation method if you ever have issues.
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.
Global hotkeys in Wayland: org.freedesktop.impl.portal.GlobalShortcut
The X11 connection is generally an enormous hole in such containment, but yes. Such containment definitely helps. That is why I run as many applications as possible as Flatpaks, as they employ similar countermeasures, and why they're playing an increasingly big role in modern distros.
And it's great that you're risk averse and able to avoid untrusted scripts to that degree. It's just not feasible for the general user, which is why things need to be secure even if a malicious script is mistakenly allowed to execute.
I'm not saying that that specific annoyance is a security measure. I'm saying that the whole paradigm shift that Wayland is is partially motivated by improving security. Such paradigm shifts come with paper cuts, especially in the beginning. But the rough edges are being filed down one by one. That's not to say that Wayland is the answer for everyone yet, nor that it will ever be. There'll always be exceptions. But for the vast majority of users it is, and it helps keep their systems safer than they are without it.
Not at all, seems like you're reading things into it that aren't there.
By modern distros I mean that for the newer variants of multiple large distros (Like Fedora Silverblue and its cousins, openSUSE MicroOS, etc.), even ordinary Ubuntu, Fedora and their derivatives and cousins, across the major DEs like Gnome and KDE, for all of them apps packaged like Flatpaks and Snaps have an increasingly large role.
I'm specifically not saying it's the only way to be modern or that other approaches can't have merit, I'm saying there is a clear trend among some of the largest players in the game.
I think it's dangerous to put words in other peoples mouths and then argue against those imaginary statements, and I think it's sad that you seemingly feel it's the best way to argue for what you believe in. You can do better.
Not even close, you're even more off base than you were before. I mean what do you even base your ridiculous statements about my opinions and perceptions on?
So I guess your question wasn't in good faith then, but just bait so you'd have an excuse to rant about things unrelated to my answer?
The security issue that Wayland helps solve has nothing to with systemd or logind, so I'll just ignore your tirade against them. If you don't want to use them, then good on you.
The issue is an inherent issue with the X11 protocol. It can be worked around, but it can't be fixed without something changing in the protocol on a fundamental level. The core premise that any client can be trusted unquestionably is broken and was broken the second browsers began running JavaScript. Not to mention all the other times most modern computers run opaque code of uncertain origins.
Keeping it simple is definitely a great basis to build a secure system upon, it just can't stand alone because of reasons like the above.
What about ease of use, simplicity, faster to quickly setup, backwards compatibility,
The syntax of systemd timers is MUCH easier to read for newbies (and everyone else, really) as it uses words instead the placement of the characters on the line to convey meaning. If you can't remember or don't know the syntax well you can still understand a systemd timer, but that is much hard for the crontab. Granted, crontab uses fewer characters, but if you only set up either once in a blue moon you'll need the docs to write either for a long time. And is backwards compatibility really an issue with either one? All major desktop and server distros use systemd, and has for a while. Fedora doesn't even include a Cron by default anymore.
"crobtab is where everyone will look at when looking for a scheduled task"?
If it was a distro release from the last decade I'd definitely start by checking the systemd timers, rather than the crontab.
If systemd was implemented right, it would create the systemd files and autoconfigure default tasks by reading the crontab, for backwards compatibility.
You can to totally do this, using this systemd generator.
Nice appeal to authority. Are you referring to a formalised security model (of which I'd love to read more, if you have a link?), or the actual clipboard on your PC?
But not all interaction is equal. Access control and granularity of permissions is something X11 is sorely lacking in, which Wayland has built in. Which is why X11 is a bad fit for common treat models and Wayland is not.
Ohh, @LainTrain@lemmy.dbzer0.com said so, so it must be true! I'll let you keep believing that while I enjoy them and watch them grow in popularity and usage, just like Wayland.
I absolutely am. Calling Wayland "something that has been broken for more than a decade" rather than "something that has been in active development for more than a decade" is also an interesting take. By that measure X.Org is "something that has been broken for almost two decades", so let's just not go there. And I'm not saying that Wayland magically makes everything secure. I'm saying that Wayland (or something like it) is a necessary step if we want a desktop that is secure. I have seen people propose something like nested sandboxed X servers with a single application for each as an alternative, but I think it's probably better to actually fix the underlying problem.
That's an interesting use case. It isn't really anything I've had a need for, so I don't know what the best way to do something like that is. If your compositor doesn't allow it, could it perhaps be possible to run as a different user in a nested compositor, like Cage or gamescope? Also, how do you sandbox the applications X11 access? If they share the same server, then a sandboxed application can just wait for you to launch a terminal and use sudo, at which point it can inject a malicious command as root.
Seems like a solid bunch of iterative improvements!