Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions.
At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't even be able to download and build Wine 9.21 staging, when yabridge worked.
Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends.
(I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.)
I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.
One of the dumbest auth workflows I experienced in recent times: My partner texts me, "Mom lost her phone somewhere in the zoo." I go to log into Google Find My Phone with her password. It sends a mandatory verification SMS... to the lost phone. (It was eventually found, no thanks to Alphabet.)
I would be much more comfortable with passkeys and 2FA if there was almost always the option to log in with just a password as long as an email gets sent to me (perhaps relevant that I have paid email, not Gmail) stating I logged in to site XYZ without 2FA. Not a "click button to confirm you want to log in" email, just a "hey this happened" email containing a Shaggy link, "It wasn't me." Bonus points if that site's account settings (e.g. 2FA) cannot be changed as long as I'm only logged in with a password[+].
The odds of me not having a device to receive the email at the same time someone guesses my password and causes rapid catastrophic damage[++]... I would need to be specifically targeted or unlucky beyond the normal expectations of unluckiness. (Much more likely: I'd occasionally discover which sites have bad security practices or that I need to be more resistant to social engineering or more careful in public spaces; guessing a long generated password in just a few attempts when the password is never shown on the screen would be impressive!)
I've lost count of the number of times I need to enter a password using a unknown machine, log into my Bitwarden server, copy/paste the necessary password, ... "okay now you'll see a popup on your Totally Breakable Losable Connectivity-Unreliable Android phone"
-----
[+]: account info can't be changed w/ only password... unless I provide some verification ranging from personally appearing at an office with ID for money-related accounts to verifying ownership from a backup email address for low-stakes accounts like bulletin boards.
[++]: short of guessing my Bitwarden master password, which is one of the carveouts for "always always 2FA" and "several alternative, secure backup login methods, at least one which does not require technology"
It's visually creative. At the same time, the reactive animations would bother me (to the point of deeming it unusable) in any production app or website. I'm glad it respects "reduced motion" preferences.
Except it's actually a massive pain in the ass for unrelated projects and users. One example:
Robbert van der Helm has a very popular (in the Linux music editing world) program, yabridge, which enables DAW plugins written for Windows/Mac (aka most of them) to run in Linux DAWs. It leverages Wine and a cascade of transparent window layers that position mouse clicks, menu positions, and graphics updates. It's crude, it's clever, it works. Musicians who love Linux rejoice!
Enter Wayland.
Mouse clicks no longer land where they're supposed to. Reparenting a window doesn't work like it did on X11. Edits to the yabridge source code are a moving target because WINE devs (who are largely paid professionals, which occasionally keeps out a handful of useful merge requests; these maintainers DO need to balance the needs of ALL Wine users with every edit) keep editing winex11.drv (which has all the display and input functionality touched by yabridge), and robbert-vdh shares in some issues that he doesn't have much time to make changes, especially when they might break again later.
For over a year, yabridge is broken.
Advice is given to pin wine-staging 9.21. (Wine 11.0, released 7 months ago, is the current stable version.) Yabridge users share tips on how to install/build Wine 9.21 long after their package manager has deprecated it. You can still run yabridge on newer Wine, mostly; one workaround is to always drag your plugins to the upper-left corner (if the window allows it; I couldn't do this with REAPER in Fedora KDE without disabling snapping, which I want; for months, I used the non-GUI plugin panel in REAPER). A few plugins just stopped working. Sometimes users will log what happens and upload this and it even eventually gets explained---for that specific case---but often not solved right away.
One maintainer of Wine made edits both in Wine and yabridge specifically to get yabridge working again. I don't know if he did it for a CodeWeavers user or just out of the kindness of his CodeWeavers-paid heart. This pull request covered 90% of users, but a few still complained it didn't work in X DAW with Y plugin on Z distro. Because it doesn't always work, it becomes a branch; technical users will be able to manually get their DAW/plugins (often paid, sometimes a subscription, so there's an incentive to use them) to hopefully work and hopefully for the long term.
A few DAWs even change their plugin code to support, say, keyboard passthrough, which should theoretically be handled by Wine or/and yabridge but still has issues. These DAWs could be getting new features or addressing USB interface latency/throughput/routing, but instead they're dealing with fractional scaling, plugin support, themes, and a bunch of other graphical details that worked previously.
It absolutely wastes developer time because now the rules of "who handles what" (in every major distro and DE) have changed for anyone with a GUI and because developers are often users who have no choice in the changes and don't have the background to just know---or the free time to learn---how Windows and Wine and VST and Linux graphics work, and even if they did, the MR/PR they write and submit might not get merged at all in the chain of programs needed to get FabFilter to run in Bitwig on Ubuntu 26.04, because it doesn't also let Auto-Tune run in Ardour on Fedora. (This is contrived, but you can read through the 100+ open yabridge issues yourself to find the actual problems being experienced.)
By the way, the "ya" in yabridge is an abbreviation, "yet another," because it worked where other VST bridges did not. It wasn't the first compatibility layer for VST and won't be the last. Either robbert-vdh will change his codebase to work with the new methods Wine uses to handle Wayland windows, or there will be a new bridge. If you're wondering why there are 20+ actively maintained and reasonably well-known terminal emulators (How many could I rattle off without looking it up? Alacritty, Ptyxis, Foot, Wexterm, Terminator, xterm, Konsole, Guake, Kitty, ghostty, xfce4-terminal, and does Putty count?) it's because of situations like this, where the new paradigm forces old devs to keep up and implement popular feature requests or get replaced.
All of this doesn't even consider whether a DAW is Flatpak or not. (Hint: the failure modes are different.)
-----
Users can't always get old hardware to support the old software that worked. Users can't always get every version of old software they knew to work six/eight/ten years ago. Users on old software have to figure out vulnerability patches and how to handle subscription and dongle-based plugins.
(Windows 11 is a bad experience, I don't even count this as a fallback.)
If the decision makers of Linux are going to make changes that break workflows, they absolutely should get [productive, kind] pushback. We shouldn't have to downgrade our OS UX and free cash reserves to a Mac Studio just to be able to do the things we already could do in 2018.
Flagging, to me, seems like pissing in the wind. If I notice serial posters submitting extremely low effort content (a pair of their own posts every waking hour from "6 months and 5 minutes ago", off-topic wikipedia nearly once a day, "I have 60000+ points but only upload from thealtantic/guardian/nytimes") then I go on an irate ten-minute flagging binge.
I've also been aghast at the nerve of those same serial posters applying the letter of the law against other users. I genuinely wouldn't care if Bartosz Ciechanowski only self-promotes every last one of his own posts. Some users are significantly more interesting than others, whether or not they violate the site guidelines marginally on a technicality.
I have suspected it's possible some users flags are worth more than others, and I wouldn't be surprised if my flagging ability was silently removed several years ago.
a.k.a. the most recent stable LTS, which will be succeeded by 26.04.1. Unless your hardware doesn't work on 24.04.4, I would not upgrade to 26.04 yet, unless you enjoy unexpected behavior in the console.
Gboard has been messing with the emoji search recently. It is worse.
Previously, if you type "fac" or "face" or "facep" or "facepa" or "palm" in the search box, you'd get the facepalm emoji among the results. Inexplicably, now the lying emoji, bacon, fondue are shown when you type "fac" but not the classic facepalm. It is only after you type "facepal" that the facepalm emoji appears in the results, which is a major... facepalm for the Gboard team.
As a parent, I need to _constantly_ send the facepalm emoji to my partner, so I noticed immediately when it recently changed. I think they're now trying to account for multiple languages, misspellings, a larger list of synonyms that allows partial matches, sentiment/meaning/synonyms, etc. In any case, I've always felt like emojis should be weighted by overall usage patterns (I have never used the fondue emoji and don't know anyone who does) and now they need a better search trie, where the facepalm emoji is in the top results of "fac".
Shopify (admin.shopify.com, help.shopify.com) was down for fifteen minutes today. shopifystatus.com showed it was "All systems operational" but for users "having trouble" click a link to contact support. That link? Hosted on help.shopify.com of course...
I find a much more enjoyable interface after disabling animations on every device I use---as well as shadows, glow, blur, translucency, hover effects, and rounded corners. Eye candy is an annoyance and wastes developer time, in practice, even when done "correctly".
Kinetic scrolling on touchscreens can stay, but only because my finger doesn't have a no-friction scroll wheel.
I wish I could fully agree. Canonical is a bit pushy: "Ubuntu Pro / ESM subscription will make your machine safer! and it is convenient mega free!! ((for non-business uses))"
Workplace very strictly requires Ubuntu LTS for toolchain & compatibility reasons, otherwise I'd run Debian or Fedora or Tumbleweed with Ubuntu containers/VMs where needed.
Nonetheless, Linux popups and promotions (even from enterprise distros) are not nearly as bad as the Windows 11 experience.
Fastmail had a UI change a year ago, where they went all "rounded corner" and created unique rows for every message that weren't so easily sorted with Stylus CSS. I emailed them about the changes, and a few weeks later the messages were listed in a way that I could easily apply my own stylesheet again. They also acknowledged on their subreddit the UI change was not incredibly popular (even the CEO was "not enjoying" it) and they took some feedback and provided a few better UX customizations in the options.
At one point, Fastmail had an error parsing Unicode in misconfigured iCal files (Google Calendar showed events correctly) but after a short back-and-forth, they fixed it within a week.
Now, Google Calendar has had a problem with my organization's iCal files for the past four weeks. Submitting a bug report via the help community is very opaque and unhelpful (a la "Have you tried turning if off and on again?"). Fastmail loads the iCal correctly. I have no clue if Google is aware or when they'll ever fix it.
One huge productivity advantage to FM over Gmail? Sort by sender name. (This makes it so easy to bulk apply changes)
Setting up own domain has been straightforward. (It's a bit of work ensuring DNS records have DMARC/DKIM/SPF, but it's all in the FM checklist/documentation.) Setting up Python scripts to auto email me using app passwords has been straightforward. Creating aliases and throwaways is straightforward.
I have not regretted paying for email; specifically, Fastmail.
I've never really needed that, or I don't understand the need for there to be a difference. I typically tile windows into each corner based on how large I need them. When I need more than 4, I'll manually place them.
What I do notice is the wasted space needed by the entire window border to accommodate rounded corners and how annoying it is to grab a window handle in e.g. Ubuntu w/ GNOME because you're clicking/touching where the corner would be (but isn't, because it's round).
I thought having a MacBook Pro after a few decades of Windows/Linux use would be utopic, but Apple hides a ton of keyboard/mouse shortcuts, so the majority of software is slow to learn and use. Simple stuff like split screen, file handling (particularly compressed files, mounts, and network), or USB device permissions leave a lot to be desired.
It gets worse when you need to add Parallels because a particular lab machine only has Windows support. Being Vim-dependent, I got unlucky receiving the butterfly keyboard model with no physical escape key.
excellent hardware specs, superb battery life, very opinionated aesthetic (I hate it.), not nearly as intuitive as one would assume
I keep purchasing ThinkPads (Z13, X1 Gen 11, X1 Gen 12, T16) where the USB-C port breaks within a year (respectively: "no dock or external monitor", "no charge and only non-Thunderbolt enumeration" on a single port, "charge only, no USB enumeration at all" on both ports, "fries other devices during reverse PD"), and I'd love to be able to swap out a broken port rather than ship the entire machine to Poland for two weeks and get lectured by the support contact that, "maybe ports only stop working under Linux but we'll still repair the mainboard this time."
I am waiting to jump ship to a different manufacturer, but nobody is challenging ThinkPad on keyboard quality/layout and Linux support, the two factors where I'm totally unwilling to compromise. (Tuxedo is close but still not the better alternative.)
Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions.
At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't even be able to download and build Wine 9.21 staging, when yabridge worked.
Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends.
(I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.)
I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.