Why exclusive to SWEs? They tend to be more time-restricted than financial-restricted (assuming the "SWE" comes from a job description). I'd be more interested in making sure that those with less well-paying jobs are able to access such benefits rather than stacking it onto those already (probably) making 6-figures.

Of course, the problems arise in the details. Define "volunteer": if $DAYJOB also uses it (in a way related to my role), is it actually, instead, wage theft? Also, quantifying the benefit is a sticky question. Is maintaining 10k emoji packages on NPM equivalent to volunteer work on libcurl? Could it ever be? Is it volunteer work if it ends up with a bug bounty payday? Google's fuzzing grant incentives?

Dad has seen AMC I-6s go 400k before the transmission died and ended its run.

I still see it around town from time to time, must have 360 on it now. Original engine and as far as I know, transmission as well.

I ran it out of oil once without damaging it.

Since then, I bought two inline-6 Ford F150s from the mid-90s. I plan on running them forever. I bought two so I can learn to work on them, and have a backup to drive. Both manual, as well.

Jeep XJs from the 90s are still great cars to buy, so are the fords from that era (all the engines are reliable, but the I6 is starting to have a cult following online). I was working on that Jeep before I had any mechanical experience at all. It never failed to start.

I used to keep a password card in my wallet and had a pattern I would use.

We also need custom runners anyways because macOS and Windows are important and getting those with graphical session access and/or CUDA hardware in the cloud is either $$$$ or severely limited. Even with our setup, we split the build and test phases so that CUDA hardware slots aren't wasted on running compilers. It also lets us test a single build under different environments easily.

So, yeah, I can see fighting with the feature spectrum, but you need to restrict yourself in most other cases with that kind of stuff too. But at least what we do is possible with GitLab-CI.

- clean integration branch histories (series of merge commits) - merge commits can contain metadata (topic-level descriptions, trailers for who reviewed, merge request links, test results, etc.) - you can be (pretty) sure that `git bisect --first-parent` will not run into any compilation problems (logical conflicts occur, but are fairly rare; use merge queues to be sure) - none of the "you merged main into your topic" "backwards merges" to deal with too

Merging and rebasing each have their pros and cons, so why not use the pros of each and mitigate a lot of the cons at the same time.

In this app, I ended up hunting for the first note and by the time I found it, I couldn't remember "how far" up/down the next note was (and by even 3 notes I often lost the direction from 2 to go). I /could/ figure out the key positions and go from the staff, but that goes through the FACE/EGBDF path of what notes the lines on the staff mean and is 100% non-aural for me. It's also extremely slow.

I also have a horrible time finding melodies and rhythms in music (kind of like Steve Martin in The Jerk, just more…physically coordinated at least). I end up "tapping" out every note and lyric syllable instead of being able to tease anything apart (separate instruments help, but then I lose "the rest"). Rarely was I able to effectively utilize those "song tapper" apps in the 00's to find anything I wanted.

I do remember playing the recorder in class in elementary school and at least "Horse With No Name" on a guitar in…some higher grade (7th? 8th?), but I believe those were very physical-oriented finger memory rather than anything to do with my ear helping out. New songs were basically from-scratch practices rather than being able to build on prior experience.

So while my ear might not be "tin", so to speak, my mind is not well-wired for ir.

I ran XMonad for 15 years, but recently switched to river and am loving it.

fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly.

Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.

Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur.

[0] https://news.ycombinator.com/item?id=32021261

[1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.

These days Xinerama is the only mainstream tool for dual head, but there used to be others. Nvidia Twinview was one. I bought my first dual head box in 1996 with two Matrox Millennium cards (although it mainly ran NT4) and those cards later went into my dual Athlon XP machine. That ran SUSE until Ubuntu came out.

Xinerama isn't a sine qua non. It's just easy so it became ubiquitous. Maybe it's time to replace it.

Well if three independent programs have to coordinate to make it work, then I would state that it do not support it at all.

I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here.

[0] https://wayland.app/protocols/fractional-scale-v1#wp_fractio...

The annoying thing about the other things you mention is that they honestly are not that difficult to fix.

The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.

Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!

And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.

There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.

So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.

[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.

I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.

When it finally got added, the PR was like a 2-300 lines.

My understanding from the outside is that this didn't happen, that Wayland is a spec without a reference implementation - that they didn't actually build anything and are leaving the difficult part up to everyone else.

What features is Wayland the protocol missing to allow supporting Xfce?

They convinced their employers Wayland would be better?

> Xscreensaver/lock screens on Qubes are still broken.

Most people aren't nation-state-level targets and don't worry about security to that degree. But they do like global hotkeys.

For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.

Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.

However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.

It is when you are essentially putting bars in front of your windows while leaving the front door unlocked, i.e. you are making things worse in the name of security while not actually providing any additional security.

> Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do

Who is we? I don't want or need any of that on my free software system.

I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else. Yes, X provided functionality that now WMs get to implement themselves - since the developers of Xorg worked closer to Gnome and Qt people, and Gnome and Qt people were OK with this, this didn’t feel like a horrible trade off. And given the diversity of Wayland window managers today, I don’t think it mattered all too much.

> I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else.

"I think the owners of the Internet infrastructure would be the best people to choose what websites I'm allowed to visit"

No, the users have spoken and continue to speak up that Wayland doesn't serve their use cases.

It is the same, yet some uppercase characters are not supported when entered via a yubikey. This has been marked as a WONTFIX. This is rather sad, because I can enter the same password in a TTY with no issues.

Also, this level of security is wanted even on a "I don't want my sister to look at my stuff" level, no need to go nation-state level.

The most active implementation (particularly in the early days) is probably wlroots, started by Drew deVault (again in his free time), who is often quite vocal against corporate control.

In fact the large desktop environments, which are much more under "corporate control", were comparitavely slow to adapt wayland IIRC.

So instead of repeating this accusation, maybe actually give some evidence?

Then you'd be wrong. Freedesktop is essentially RedHat and friends.

I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?

Sorry for my combatitive before. I definitely interpreted your previous post differently and I think your clarification is a fairer assessment of the situation. I would still argue that the majority of people implementing the wayland protocol are not paid by their employers to do so (this might now have changed a bit with smithay, which is sponsored by system76 I believe).

It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).

This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.

Wayland doesn't solve any problems I have, and would create new ones, such as having to adapt to new tools or write my own compositor.

Battery life just isn't a relevant consideration for me.