![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
…I probably should have checked the byline before posting. It does still come from the same material, just a little more directly.
…I probably should have checked the byline before posting. It does still come from the same material, just a little more directly.
There’s some weirdness on that because she did some important but not-very-public work at IBM in the 60s with their ACS/“Project Y” effort that did what we later call superscalar/multi-issue processors like …20 years before those terms existed. As part of that she wrote a paper about “Dynamic Instruction Scheduling” in 1966 under her pre-transition identity that is a like retroactive first cause for a bunch of computer architecture ideas.
There was almost nothing about that work in public until Mark Smotherman was doing some history of computing work in the late 90s, put out a call for information about it, and she produced a huge trove of insider information after deciding it was worth exposing the provenance. There’s a neat long-form LATimes piece about the situation which is probably the primary source for the history in OP’s link.
They don’t have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it’s why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.
Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you’ve fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We’re not going to have compositing and non-compositing, we’re going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren’t even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.
Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that’s not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That’s whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.
One place we’re about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted… so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it’s also layering violations with privileged processes.
I will preface that Xorg is obviously an unmaintainable mess of legacy decisions and legacy code, and I have both a machine that runs Hyprland and a machine that usually starts Plasma in Wayland mode so the Wayland situation getting to be more-or-less adequate with persistent irritations here and there… but Wayland is trauma-driven-development. It’s former xorg developers minimizing their level of responsibility for actual platform code, but controlling the protocol spec, and in the position to give up on X in time with their preferred successor.
Essentially all of the platform is being outsourced to other libraries and toolkits, who are all doing their own incompatible things (Which is why we have like 8 xdg-desktop-portal back-ends with different sets of deficiencies, because portals were probably designed at the wrong level of abstraction), and all have to figure out how to work around the limitations in the protocols. Or they can spend years bikeshedding about extensions over theoretical security concerns in features that every other remotely modern platform supports.
Some of that outsourcing has been extremely successful, like Pipewire.
Some attempts have been less successful, like the ongoing lack of a reasonable way to handle input plumbing in a Wayland environment (think auto-type and network kvm functionality) because they seem to have imagined their libinput prototype spun out of Weston would serve as complete generic input plumbing, and it’s barely adequate for common hardware devices - hopefully it’s not too late to get something adequate widely standardized upon, but I’m increasingly afraid we missed the window of opportunity.
Some things that had to be standardized to actually work - like session management - have been intentionally abdicated, and now KDE and Gnome have each become married to their own mutually-incompatible half solution, so we’re probably boned on that ever working properly until the next “start over to escape our old bad decisions” cycle… which, if history holds, isn’t that far away.
We’re 15 years in to Wayland, and only in the last few years has it made it from “barely a tech demo” through “Linux in the early 2000s” broken, and in the last year to “problems with specific features” broken … and it is only 4 years younger than the xf86->xorg fork.
As expected from the docs, that’s why I was surprised to see you mention Nix on a Chromebook, it seemed like order of magnitude wrong. 128GB is an unusual amount of local storage for a Chromebook.
I have a little Arch/Hyprland install that fits a comfortable environment in like 8 of the 16GB in my Dell 3189 right now - It was kind of a fun project fitting it and chasing down all the little annoyances, I think it all works now other than the lack of pluming to make use of the fold sensors, and an occasional ASoC bug for which patches have landed upstream in Linux or Pipewire since the last releases.
How is NixOS on a Chromebook? The Chromebook I’ve been hacking on exists as a beater for trying environments without disrupting the (principally Arch+KDE on X) boxes I do my real work on, and I was thinking about trying Nix on it, but it seemed like the combination of 16GB eMMC and Nix’s propensity for large disc usage would make that difficult.
I just tried keyd a day or two ago and I’m super taken with it.
I just wanted to make Meta+Arrows generate PgUp/PgDn/Home/End because I’ve really grown to like laptops that do that with Fn (And I was playing with a hacked Chromebook whose keyboard does those soft with Ctrl+Shift+Arrow in software on ChromeOS so you’ve got to do something).
I’m quite impressed. The configuration format is sane, the daemon’s runtime footprint is tiny, and it works across VTs, X, and Wayland because it’s a virtual keyboard emitting events. The historical options have like…0-1 of those properties. Also the virtual keyboard takes bus ID 0fac:0ade, and who doesn’t like a god hex pun.
Played any Beyond All Reason? (or it’s predecessor Balanced Annihilation on Spring)
I played a lot of TA in the 90s and early 2000s, and I think its a better successor in many regards than Supcom or Planetary Annihilation.
Alternate perspective: I use the heck out of session restore, and it has driven me nuts that it hasn’t worked properly under Wayland.
I tend to use different virtual desktops for different projects, so being able to reboot (because of a kernel update and needing to load a module or something) without losing and having to rebuild that state is is super valuable.