eddyb (u/eddyb) - Readit News

eddyb commented on KDE going all-in on a Wayland future blogs.kde.org/2025/11/26/... · Posted by u/dualogy

eviks · 4 months ago

> The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.:

Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)?

> really just 3rd party apps that haven't been updated

What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption?

> screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature.

So what was the screenshot feature of X11? Also classifying use as abuse isn't that honest, only the lack of security is

eddyb · 4 months ago

> So what was the screenshot feature of X11?

In case I wasn't clear enough, there was never a screenshot feature. Any X11 client could read any pixel written by any other X11 client.

> Have all the best or most popular apps been updated to ensure no disruption?

I am not familiar with DE-agnostic "screenshot apps" for Linux, they always seemed more common on other OSes, and I've always used the DE-specific apps (which were the first to support such mechanisms, some of them even using more direct DE-specific private protocols instead of XDG Portals).

But I spent a few seconds googling for general screenshot apps, found Flameshot (which makes sense as a cross-platform app), and it turns out that support for the XDG Portal approach was added to it almost 5 years ago:

https://github.com/flameshot-org/flameshot/pull/1272

And if you peek around the diff, you can tell that KDE/GNOME-specific support, on Wayland - using DBus but not the XDG Portals protocol - already existed, in early 2021, in fact...

https://github.com/flameshot-org/flameshot/commit/a5df852268...

That's the commit that added KDE/GNOME-specific Wayland screenshot support.

8 years ago, in a 3rd-party app!

> Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)?

I'd forgotten that this happened, but for screensharing from a X11 client, someone already went through the trouble of emulating it (on top of the XDG Portals + PipeWire infrastructure):

https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/

It's only a temporary hack, and it only matters for X11 clients running under XWayland - if an app can run as a native Wayland client, it should have XDG Portals-based implementations of relevant features.

> What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption?

Am I downplaying, or are you describing a vague category of "the best or more popular apps" without giving examples?

I feel like it's too easy for some of this stuff to end up in FUD-like arguments without considering the objective reality (of how far we've come in the past few years etc.).

Anyway, my subjective take is that X11 took a decade or two too long to die, and most (if not all) gripes users might have with Wayland can be traced back to X11 outliving its UNIX Workstation origins and having never been designed as a Personal Computing graphical environment.

eddyb commented on KDE going all-in on a Wayland future blogs.kde.org/2025/11/26/... · Posted by u/dualogy

eviks · 4 months ago

Oh the downplaying

> In certain cases, 3rd-party applications doing specialized tasks like taking screenshots

In what way is this copy&paste-like staple of general computing some "specialized" task?

Will the new opportunities include reaching "specialized" feature parity?

> In the longer term, this change opens up new opportunities for features, optimizations, and speed of development.

eddyb · 4 months ago

If you're not familiar, the way X11 works is comparable to "multiplayer notepad" for your pixels ("multiplayer MSPaint"?).

All your monitors are combined into a large canvas where every pixel can be written and read by any X11 client.

Screenshots (and screen sharing) could be silently performed with zero user feedback (or any good way to even detect when apps might be doing this maliciously, AFAIK).

This is one of the big "security implications" that motivated Wayland (and somewhat similarly, the Flatpak sandbox and the XDG Portal infrastructure that has by now outgrown it).

The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.:

- https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

Keep in mind that any action which doesn't require interactivity every time (e.g. restarting the screensharing of a previously-chosen window/display) could have "user gave permission" be remembered, but that seamless case still only applies to that combination (so that client can't peek at anything else than what it was offered).

Anyway, what the blog post is talking about is really just 3rd party apps that haven't been updated (and e.g. might already not function properly inside Flatpak).

> feature parity

If we are being honest, screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature.

eddyb commented on KDE going all-in on a Wayland future blogs.kde.org/2025/11/26/... · Posted by u/dualogy

hxorr · 4 months ago

What I am uncomfortable with is the inability to run Wayland on older video hardware. X11 will happily run with Vesa driver on older hardware which no longer has functional 3D accelerated drivers.

What is the way forward for the retro community to run a modern Wayland system on older hardware?

Hopefully someone more knowledgeable can chime in or correct me

eddyb · 4 months ago

If your Linux distribution is handling Mesa packages correctly, you will never lack OpenGL/Vulkan drivers.

The reason is that Mesa includes "software rendering" drivers for both OpenGL ("llvmpipe") and Vulkan ("lavapipe"). As the name(s) might suggest, they use LLVM to JIT shaders for your CPU (supporting SIMD up to AVX2, last I checked - although typical compositing shaders tend to get pattern-matched and replaced with plain `memcpy`s etc.).

So you should always be able to run a fully-featured Wayland desktop (albeit limited in performance by your CPU), on any unaccelerated framebuffer, nowadays (and I remember doing this even before Plasma 6 launched, it may be older than usable Wayland desktops tbh - the Mesa code sure is, but maybe distros hadn't always built those drivers?).

eddyb commented on Cursed Rust paper.wf/binarycat/cursed... · Posted by u/todsacerdoti

John23832 · a year ago

Interesting. Is there any documentation which explains this?

eddyb · a year ago

Not sure if there's a better section elsewhere, but at least this one touches on it: https://doc.rust-lang.org/reference/destructors.html#tempora...

eddyb commented on Stuff the identity function does in Rust (2015) bluss.github.io//rust/fun... · Posted by u/wilsonzlin

mastax · 3 years ago

Pretty deep in the nitpicky weeds here but I don't like putting mut bindings in parameters. They only affect the body of the function but they show up in the interface, including rustdoc, which can be confusing. It's easy to think that

    fn foo(x: u32) {}
    fn foo(mut x: u32) {}

has a semantic difference to the consumer similar to

    fn foo(x: &u32) {}
    fn foo(x: &mut u32) {}

but it does not. To avoid this confusion I'd rather do

    fn foo(x: u32) { let mut x = x; }

eddyb · 3 years ago

This is effectively a rustdoc bug, the pattern is very much part of the body of the function, not the signature (and this split is explicitly represented in the compiler IRs, which rustdoc effectively undoes).

While it's not really how it works, the closest valid Rust that comes to mind is:

    const foo: fn(u32) = |mut x| {};

What rustdoc should be doing is stripping binding modes (`ref` and/or `mut`), or even whole patterns - with more complex patterns, like `(a, mut b): (T, U)`, it can be beneficial to keep `(a, b)` as a way to label the two components, but the `mut` is superfluous for documentation.

eddyb commented on An X11 apologist tries Wayland artemis.sh/2022/09/18/way... · Posted by u/xena

tannhaeuser · 3 years ago

So what are you using or recommending? Recently switched to kubuntu from gnome-ubuntu, and while some pain points have gone away (lack of global menu can partially be kindof mitigated, didn't have to fiddle with touch acceleration like on 20.04), I'm not impressed: middle-click gets in the way a lot and can't be switched off, power mgmt tray is lagging badly behind power events, weird dock preview and not-so-great app switching, somewhat fiddly touch targeting at times, FF crashing, updates not smooth, insists on chromium as default browser, point-/tasteless Windows-y sounds and looks, ...

All the while there are ZERO GUI apps or other capabilities I'm using that I didn't already use 15 or 20 years ago.

Eying a return to Mac OS which at least doesn't feel like you're treated as guinea pig by dicks with attitudes. Linux notebooks seem barely good enough for uninspired enterprise work on bloated IDEs and Docker/other container crap only there because said dicks couldn't agree on a set of (really old) lib versions and gui toolkits.

eddyb · 3 years ago

> So what are you using or recommending?

I am using KDE (aka Plasma5) in Wayland mode, on NixOS unstable.

I would not recommend NixOS, just like I mentioned, and I didn't really want to get into the weeds of why, but while Nix is something that more people should try out if they're already familiar with unfortunate asymmetries (e.g. "git's data model is really nice" vs "git's CLI has sharp edges and some workflows the data model implies are entirely unserviced") and/or like to play around with experimental unpolished software, I would maybe avoid it until they actually come up with a "more declarative"/"less computational" flavor for 99% of usecases.

I've used openSUSE in the past, and while YaST2 might be less relevant now, it was shocking how much similar things were outright lacking back then (a lot of this was pre-NetworkManager to be quite fair).

A lot of people like Arch, and if Debian/Ubuntu package management doesn't get in the way I suppose KDE Neon might be nice? (I keep forgetting KDE's Discover exists, it might also help with not dealing with package management directly)

---

> FF crashing

Quite ironically, if it is https://bugzilla.mozilla.org/show_bug.cgi?id=1743144 that's technically a gtk limitation (not only does it lead to the FF main thread having to poll gtk often enough to keep the Wayland connection from breaking, but when it does break it calls `_exit` so Firefox can't even do crash reporting, and they refused a patch to address this), and it can also happen for Chrome (which also uses Wayland through gtk AIUI).

If you want to check if it is the case, you can look in the logs (e.g. through `journalctl -o with-unit -r`) for "error in client communication".

> middle-click gets in the way a lot and can't be switched off

Are you talking about the feature controlled by System Settings -> Input Devices -> Mouse -> "Press left and right buttons for middle-click"? (that is, if you intentionally press both buttons, does it trigger middle-click?)

AFAIK that's off by default, but I am on a different distro and running KDE/Plasma 5.25.4 and maybe it changed at some point, or maybe it's specific to touchpads? (which I sadly can't test because I only have an older Nvidia laptop, that can't use the Wayland-compatible drivers, or rather I would have to switch to nouveau first and deal with that etc.)

> insists on chromium as default browser

I've had issues with this in the past, some apps provide their own configuration instead of going through XDG mechanisms, or at least have suboptimal defaults.

I would check the settings of the apps which cause chromium to start, and maybe play around with Flatpak/forcing the use of XDG Portal, but that might be too much to ask.

eddyb commented on An X11 apologist tries Wayland artemis.sh/2022/09/18/way... · Posted by u/xena

slimsag · 3 years ago

With X11, I can change scroll speed using the `imwheel` tool.

Years ago with Ubuntu and ElementaryOS, I could change it in the system settings GUI.

Today, with Wayland now default, I can't change it at all when running Ubuntu or ElementaryOS.

You can say this is a GNOME problem, or a distro problem, or whatever. But at the end of the day, I installed two of the most popular Linux distro's out there and my scrolling is literally unusable - and I can't fix it without apparently installing an entirely different desktop environment or a patched version of libinput.

eddyb · 3 years ago

GNOME has kind of always been on the opposite end of the configurability spectrum from KDE, IME.

But also I'm not super clear on how libinput fits into the picture, I think there used to be some Synaptics-specific integration in certain places that I never went back to, to confirm the differences (switched to libinput several years before, and I've completely forgotten since what I was trying to solve back then).

Anyway, I ended up writing a mostly-personal-anecdote below, that would likely not help, so you can probably skip it (if you do want to try anything, KUbuntu and https://neon.kde.org are both on top of Ubuntu, and there's other distros, but I've not kept up with any distro I might recommend)

---

I tried Ubuntu (w/ the GNOME default) once (back in KDE 4 times IIRC) and the lack of almost any flexibility felt like I was stuck in a sandbox (a literal one, like from when we were kids, not that it's easy to remember that far back).

The only other time I felt like that was when a friend gave me their old iPhone (6 IIRC?) "to see what it's like" and I had to give up trying it out because both the OS, and the few apps I could find (for its max supported iOS version), had random chunks of features missing (tbh I should've jailbroken it, then it'd just be one more piece of hardware I have no immediate use for - but I digress)

KDE is far from perfect (switched to Wayland recently, and been tracking a few QoL leaps in the next couple releases), but I can at least try to tweak it - same goes for using NixOS or ZFS tbh (not going to even defend those, but I have done both Gentoo-like shenanigans, and randomly RAIDed a dual-SSD laptop, respectively, quite painlessly despite not preparing for it from the start, and the weirdness budget is personally paid for a thousandfold).

Meanwhile I run into e.g. GNOME apps using libadwaita nowadays needing environment variables (that appear deprecated?) to apply the KDE gtk integration theme so they don't stick out like a desaturated winamp skin.

I've never felt like "power user" applied well to myself, like I'm not doing the equivalent of weight-lifting for computers, never want to be doing sysadmin if I can avoid it, I just want to have enough control to make things seamlessly neat for myself.

Opinionated defaults are great in the same way you'd set up a house for a marketing reel, but if I actually buy it, why would I have to deal with a landlord telling me I can't paint the walls or move/replace some furniture to maximize my comfort?

The "personal" in "personal computing" is supposed to be the same as the one in "personal property", and so I'd have similar expectations of "can screw with it without asking for permision" for both (modulo real estate being seen as an investment, and building codes, etc. - should've picked a smaller example than a house, oh well).

To stretch the house analogy further, just like I have leased (some corporation's) private property as office spaces, I would be fine to doing the same (also for business reasons) with e.g. a cloud platform (most likely through GHA, whenever they announce the paid tiers) - tho be fair to everyone, this applies far more to walled gardens than opensource software like GNOME.

Also, to be clear about the "sandbox" thing: sandboxes (and/or ideally more objcap systems) are great, and I think that the XDG Portal work is incredible for what it allows: the apps are getting sandboxed, the user getting more power over them.

Even without Flatpak (which I keep meaning to try out), I was happy to see e.g. the KDE Wayland screenshare dialog outright has an option for "create virtual screen" (which can further be configured in the KDE settings, and e.g. partially overlapped with a physical monitor, etc.). If the app was in charge, they would barely enumerate some of the windows correctly, let alone provide new virtual screens.

eddyb commented on Zig, the Small Language zserge.com/posts/zig-the-... · Posted by u/nvais

TakeBlaster16 · 4 years ago

Oops I didn't explain clearly. Take this code:

  pub fn abc() -> usize {
      #[allow(deprecated)]
      "abc".len()
  }

I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)]

I refactor code all the time and find these stray "allow"s that aren't doing anything anymore

eddyb · 4 years ago

> Maybe it would be called #[expect(deprecated)]

Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek.

Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-...

eddyb commented on The end of Optane is bad news theregister.com/2022/08/0... · Posted by u/RachelF

mwcampbell · 4 years ago

Has the Rust compiler team considered using a busybox-style approach (single binary, multiple entry points) for rustc and friends? Even Windows supports hard linking, so AFAIK this should be feasible.

eddyb · 4 years ago

We explicitly support building against librustc_driver-*.so for both "custom drivers" (what we call those binaries I mentioned) and generally "rustc as a library" usecases. We should maybe rename it to librustc and remove as much potentially-confusing "driver" terminology as possible.

Pinning a nightly and installing the "rustc-dev" rustup component are both necessary, the former because internal APIs of rustc aren't stable, but it's a supported usecase.

Both clippy and miri are developed out-of-tree like that, and sync'd using `git subtree` (or `git submodule` but we want to move everything to subtree).

eddyb commented on The end of Optane is bad news theregister.com/2022/08/0... · Posted by u/RachelF

cesarb · 4 years ago

> All this while Rust, go, and all the new kids on the block use only static linking.

This is trivially disproven:

  $ ldd /usr/bin/rustc
   linux-vdso.so.1 (0x00007ffd3de9b000)
   librustc_driver-e4385bf403336f76.so => /lib64/librustc_driver-e4385bf403336f76.so (0x00007ff832a00000)
   libstd-d371b708c754b3bb.so => /lib64/libstd-d371b708c754b3bb.so (0x00007ff832886000)
   libc.so.6 => /lib64/libc.so.6 (0x00007ff832600000)
   libLLVM-14.so => /lib64/libLLVM-14.so (0x00007ff82be00000)
  [...]

Not only does rustc dynamically link against rust's "std" library, but also parts of rustc are implemented in a dynamic library ("librustc_driver").

The only reason projects written in Rust (other than rustc itself) don't use dynamic linking to other Rust code yet, is that there still isn't a stable ABI for Rust code (for good reason: that allowed them to introduce not only reordering of struct fields and niche optimizations, but also passing and returning slices as a pair of registers instead of a pointer to a two-word structure in the stack). I fully expect that, as the language matures, a stable (possibly opt-in) ABI will be introduced, together with freezing some of its standard library (for instance, the contents of the Vec structure, and how its inline functions work), allowing for dynamic linking against Rust's "std" (and as a consequence, passing Rust types between separate dynamically linked modules compiled with different releases of Rust).

(As an aside: back when C was the "new kid on the block", it also used only static linking, dynamic linking of C code came later.)

eddyb · 4 years ago

> but also parts of rustc are implemented in a dynamic library ("librustc_driver")

Nit: 100% of rustc is found within librustc_driver-*.so (I mention it in https://news.ycombinator.com/item?id=32329062 - which also touches on stable ABI).

`rustc` just calls into the .so without any custom configuration: https://github.com/rust-lang/rust/blob/e141246cbbce2a6001f31...

(but rustdoc/clippy/miri all have additional configuration, passes, etc. specific to them)

Also, if you look at the `rustc` executable's size:

    $ du -bh ~/.rustup/toolchains/nightly-*/bin/rustc
    17K     /home/eddy/.rustup/toolchains/nightly-2018-01-01-x86_64-unknown-linux-gnu/bin/rustc
    2.9M    /home/eddy/.rustup/toolchains/nightly-2021-12-02-x86_64-unknown-linux-gnu/bin/rustc
    2.9M    /home/eddy/.rustup/toolchains/nightly-2022-01-13-x86_64-unknown-linux-gnu/bin/rustc
    2.7M    /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc

17K is what it should be, I'm not sure where the extra 2.7M are coming from - my current suspicion is that it's entirely statically linked jemalloc, which I guess we didn't want to impose on all users of rustc_driver, but it might be worth doing it anyway.