Is that a reasonable argument against using X11? Sure, for some use cases. Is it a good argument for wayland/windows/OSX/whatever to do your tiling WM experimentation? Not really, those environments kinda suck for playing around with.
[1] Or "local-ish", your system or a trusted remote has to have been compromised already. Untrusted X11 protocol still exists but is deliberately disabled (and often blocked) everywhere. Even ssh won't forward it anymore unless you dig out the option and turn it on manually.
for example. run ./clipscreen 1 2 3 4
It's not like it's not a valid argument, just that it's sort of a nitpick. Security is hard, and defense in depth is a thing, but this particular attack surface is way, way back in the "depth" stack for a modern app deployment.
We've had to give up so much flexibility. Wayland certainly focuses on plugging this hole, but it means we've lost all these cool utilities like this one. There was just so much you could do with devilspie, xdotool, and others to make sure my operating system and window environment worked for me.
I still really miss X11's Zaphod mode, where you had two independent X sessions (:0.0 and :0.1) on two different monitors, with different window managers and different windowing rules.
I miss the days of being able to trust my computer and trust my software.
Wayland breaks a lot of these tools because it is so much simpler than X.
Again, this isn't the fault of "Wayland", which is just a compositor framework. The complaint is that the ecosystem of "desktop" software which evolved around Wayland is an ad hoc monstrosity that lacks the unified structure that its ancestor had way back in the X11R5 days.
This flat-out can't be done in Wayland. Though all is not lost, you might not need this at all in Wayland. The standard way to capture the screen from an unprivileged process in Wayland is through desktop portals, and at least KDE supports a wide variety of different capture options including capturing a rectangle of the screen. I haven't tried, but I suspect this is even true when running X.org applications, thanks to XWaylandVideoBridge.
I am not really thrilled about D-Bus stuff everywhere, but it is nice that you can pretty much override any screen capture behavior you want by changing the org.freedesktop.impl.portal.ScreenCast implementation: I think that's actually a step in a better direction versus having every application implement its own functionality for selecting capture targets.
Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.
You can say many things about Wayland, but it's "simple" from a point of view I for one really do not care about. Wayland may be "simple" in some respects, but it makes most of the things I care about doing unnecessarily complex.
You can trivially verify it by running the following, I have personally been using "sleep for 1ms in a loop to prevent CPU burn" for years and never noticed it having any impact, it's not until I go into microseconds when I can start noticing my CPU doing more busy work.
// g++ -std=c++20 -osleep sleep.cpp
#include <thread>
#include <chrono>
int main(int, char **)
{
while (true) {
std::this_thread::sleep_for(std::chrono::milliseconds {1});
}
return 0;
}
> Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.On what system? AFAIK, if your sleep time is low enough, it will round up to whatever is the OS clock resolution multiple, not skip the sleep call completely. On Linux, it will use nanosleep(2) and I cannot see any mention of the sleep not suspending the thread at all with low values.
That's only true if you decide to trust it.
You can deal perfectly well with software you distrust, and not have it harm your system.
At any rate, back to the code at hand, there are many ways to block on SIGINT without polling. But it's also hugely odd that this code does not read events from the X11 socket while it does so. This is code smell, and a poorly behaved X client.
Example of this would be where "runas /user:smith application.exe" is simple but does not work when a Windows Service is required to run an application as the user signed in. One must use Window's API to pull in the account's token and use more API to execute "application.exe". UltraVNC is a great source to see all the extras needed.
Besides the duplication of efforts in implementing the same stuff over and over, now someone developing somewhat non-trivial programs needs to be aware of the differences in supported features and non-standard extensions in all desktops, for example [1].
[1]: https://wayland.app/protocols/cursor-shape-v1#compositor-sup...
That said, I understand what they were going for. They really wanted to make the compositor as small and simple as possible, so for example you would just use libwayland-cursor instead of bothering with cursors yourself. However there are a lot of ways libwayland-cursor worked out poorly... Not everyone agreed on how scaling should work, GTK4 ditched it for performance reasons, and overall it's just inconvenient for a lot of cases (languages other than C, sandboxing, etc.) And to make matters even worse, in practice every compositor needed to load and handle XCursor themes anyways...
That said, I think that it's okay if Wayland doesn't own the majority of the Linux desktop stack the way X11 did. It's fine for compositors and their helpers to implement protocols from other projects, too. That way Wayland can be more applicable to graphical machines other than desktops without bringing unnecessary baggage. It'll always have trade-offs, of course, but I think it's far from the end of the world.
Of course, it still needs to be possible under Wayland, because there are plenty of legitimate use-cases (screenshots, screen sharing, video capture, etc.), but it was a non-goal to make it as simple as X.
Wayland merged the image-capture-source and image-copy-capture protocol extensions earlier this year: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture
Browser sandboxes pretty heavily though of course one does want to be a bit careful there too.
Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
I'd even say that it's a good example for others, because the equivalent code with the event loop would be slightly more complicated (maybe 5 more lines?). Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
Coincidentally, it's also the best experience, for whatever reason it's the only on that supports virtual backgrounds on Linux for me? Neither Chrome nor Desktop seem to work for this.
https://lxr.linux.no/#linux+v6.7.1/kernel/time/hrtimer.c#L20...
https://www.man7.org/linux/man-pages/man2/PR_SET_TIMERSLACK....
I'd love to see numbers with a Kill-A-watt between the PC and the wall
I'd argue it's completely opposite of this. You're streaming video, already putting some significant stress on the system. No reason to waste time (even if it's a minuscule amount) to make things worse.
> Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
And that's how we ended with e.g. modern IoT that kinda sorta works but accumulation of minor bad decisions (and some less minor bad decisions for sure) ends up making the whole thing a hot mess.
Thankfully, for a lot of software, there is no reason to ever give them network access in the first place.
All the programs that I use (ls, rm, vim, ...) can "spy" to each other, and have unrestricted read/write access to all the bytes in my home directory. That's the whole point: I run these programs to control said bytes. What's so special about the pixels of my screen that the programs that manipulate them need to be protected from each other? If anything, the pixels in my screen seem less critical to security that the bytes in my disk. But Wayland insists in making that difficult, for incomprehensible reasons. Those are my pixels and I want to do what I decide, not what Wayland lets me to. I control my programs, not the other way round. If I decide that this program reads one pixel on my whole screen, or the global mouse position, or whatever, I see no point in forbidding me to do it.
Of course, if I want to run some rogue program whose author I don't trust, I will do so inside a limited container. But this has nothing to do with graphical applications. I wouldn't like the rogue program to read my homedir either.
As for the rest, they may have "analytics" (spyware) but are there any documented cases of any of them acting as an X11 keyloggers or covertly screenshotting the users desktop? Those are the threats Wayland asks us to fear. And Wayland won't protect us from the rest. If Firefox or Audacity phone home with reports about what I'm doing with those applications, Wayland won't stand in the way.
This was changed sometimes in the last 20 years, probably with battery powered devices becoming more prevalent and CPUs implementing more advanced sleep states.
1. https://people.kernel.org/joelfernandes/on-workings-of-hrtim...
It's nice that wayland makes such containerization much lighter, at least concerning the GUI (you still need to hide your filesystem, network, etc if you want to run rogue programs under wayland). But I don't see the point in enforcing it for each and every one of your programs. It's extremely unergonomic.
Because after 10 years of heavy development none of the waylands have managed support simple things like screen readers. X11 supports screen readers and innumberable other vital accessibility features that wayland never will be able to. Some waylands might eventually develop extensions for their particular desktop but there won't ever be a way for wayland protocol because it can't. Security theater is more important than accessibility/usability for wayland that leaves many use cases and entire demographics of people out in the cold.
So yes, X11, which is still the least worst option. Better to have the ability to do all things than have to wait decades+ for developers to write complex extensions to do things (and just for their DE, causing fragmentation).
import time
while True:
time.sleep(0.001)
also the script itself it bounces between 0% and 1% cpu usage