It's when I want to use a non-systemd, no-DE environment that xdg-stuff becomes very annoying, but that's usually because applications assume a certain setup rather than any fault of xdg. eg. Wayland is very stupid about requiring a certain xdg setup to run at all.
On the other hand, it should be very obvious for anyone that has experience with concurrency, that changing a field on an object like the author showed can never be safe in a concurrency setting. In any language.
This is not true in the general case. E.g. setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution.
It depends on the platform though (e.g. in Java it is guaranteed that there is no tearing [1]).
[1] In OpenJDK. The JVM spec itself only guarantees it for 32-bit primitives and references, but given that 64-bit CPUs can cheaply/freely write a 64-bit value atomically, that's how it's implemented.
> setting a field to true from potentially multiple threads can be a completely meaningful operation e.g. if you only care about if ANY of the threads have finished execution.
this only works when the language defines a memory model where bools are guaranteed to have atomic reads and writes
so you can't make a claim like "setting a field to true from ... multiple threads ... can be a meaningful operation e.g. if you only care about if ANY of the threads have finished execution"
as that claim only holds when the memory model allows it
which is not true in general, and definitely not true in go
GP didn’t say “setting a ‘bool’ value to true”, it referred to setting a “field”. Interpreted charitably, this would be done in Go via a type that does support atomic updates, which is totally possible.
I saw that bit about concurrent use of http.Client and immediately panicked about all our code in production hammering away concurrently on a couple of client instances... and then saw the example and thought... why would you think you can do that concurrently??
If you want that feature, then the display server doesn't need to be the one to support it when the display server lets applications obtain and control window positions.
Wayland doesn't let you do that, and it's a deliberate choice.
We know it's a deliberate choice. It's just wrong.
>This decision affords Wayland compositors a greater deal of flexibility — windows could be shown in several places at once, arranged in the 3D space of a VR scene, or presented in any other novel way. Wayland is designed to be generic and widely applicable to many devices and form factors.
Do ANY of these other features work? Furthermore, all our applications are built basically as 2D grids of pixels. What click position do you get if you render the same window in some "novel" way like in two places at once? I don't especially care if any of their space-age bullshit works. It NEEDS to work for the apps we have, which are just pixel arrays. Many users have been ranting about this issue for years and all we get in response from Wayland wackos is basically "live with it!" Nobody has realized any actual benefits in functionality from switching to Wayland. Maybe some graphics nerds with weird monitor setups are geeking out about fractional pixel coordinates and multiple refresh rates. The rest of us are just dealing with issues for no benefit.
> Maybe some graphics nerds with weird monitor setups are geeking out about fractional pixel coordinates and multiple refresh rates.
They're complaining too because Wayland upscales everything (quadrupling the number of pixels and trashing performance) in order to downscale it for fractional scaling.
> They're complaining too because Wayland upscales everything (quadrupling the number of pixels and trashing performance) in order to downscale it for fractional scaling.
Only once ? They could do this 3 times. For smoothness. /s
I don't resent it. x11 is laggy and poorly supported on modern desktops, even if all the bugs were fixed it would be a pretty sore daily driver experience. Without Wayland I'd still be dual-booting into Windows, the same likely goes for every Steam Deck owner.
x11 desktops can and will continue to exist, and users will choose whichever one they prefer.
Be aware that Debian's xwayland depends on x11-common, so your number here will be the combined total of Xorg and Wayland.
You could try comparing xserver-xorg-core instead, but even then that'll only show you the number of submitters who have it installed, not the number that actually use it. The usual way to get a graphical desktop in Debian (task-desktop) pulls in both Wayland and Xorg, but uses the former by default.
The best estimate would be something like the number of xserver-xorg-core installs less the number of xwayland installs.
Using that method, it looks like there are roughly twice as many GNOME users as pure Xorg users.
I believe they refer to KeePassXC's autofill feature, which autotypes credentials into other applications. I've never used this in X and won't use it on Wayland, as I prefer to keep all applications isolated.
I Ctrl-C to copy and then manually paste the password. Wayland is better for this method because I know the clipboard is cleared once I close KeePassXC.
That's nice, if you don't have to always copy both the username and password or if you don't have custom autotype set up.
Also I disagree, if I do not trust my password manager, I should not be using it at all.
