https://arstechnica.com/security/2026/05/ubuntu-infrastructu...

Here's a quote from Bjarne,

> So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much harder problem. This is part of the standard proposal. Do we vote against the standard because there is a feature we think is bad? Because I think this one is bad. And that is a much harder problem. People vote yes because they think: "Oh we are getting a lot of good things out of this.", and they are right. We are also getting a lot of complexity and a lot of bad things. And this proposal, in my opinion is bloated committee design and also incomplete.

https://github.com/neovim/neovim/issues/20451

https://neovim.io/roadmap/

I personally will never forgive them for uploading the entirety of my users dir to OneDrive without asking for permission. They're --still-- doing this. Whatever decision making process they have in place that not only cooked this scheme up, but allowed it to continue for years must be broken beyond repair. It's contemptuous, backwards, and hostile to users. It cannot be condemned enough.

This blog post talks about taskbar positioning and vaguely gesturing at quality, which is whatever. I'm not mad about removing features or even a higher incidence of bugs. I'm mad about hostile dark patterns that they have consciously chosen to employ at an ever increasing rate. I don't think you can fix this without drastic company wide changes.

For as long as I live, if I have a choice, I will avoid Microsoft products. They cannot be trusted.

It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden.

Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support.

This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again.

Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux.

People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.

I was also under the impression that I could install DE's side by side on nixos and not have things like one DE conflicting with files from another DE, but this apparently isn't true either - I installed KDE, and then installed Sway and Sway overwrote the notification theming for KDE.

NixOS is very impressive but the marketing around it feels misleading. The reproducible claim needs a giant asterisk due to link rot.

I'm writing software for Linux myself and I know that you run into weird edge case windowing / graphical bugs based on environment. People are reasonably running either x11 or wayland (ecosystem is still in flux in transition) against environments like Gnome, KDE, Sway, Niri, xfce, Cinnamon, labwc, hyprland, mate, budgie, lxqt, cosmic... not to mention the different packaging ecosystem.

I don't blame companies, it seems more sane to begin with a limited scope of macOS.

I think we should question research which is overwhelmingly against our common experience of life. My memory is absolutely shot when I am consuming weed regularly. It's not particularly subtle, it is noticeably worse. I suppose there is room for a situation in which it is worse while I am heavily using, but if I were to cease maybe it will rebound and settle at a point which is better than it would have been had I not consumed any cannabis... but I don't see any reason to believe this.

There are people opposed to things like a allowing windows to specify their own bounds, and unless all the stakeholders agree to implement such protocols in their respective projects, the ecosystem will remain fragmented. Multiply this against every feature that people want.

* Debugging is rough. There's experimental DAP support, but it isn't ready to be used. I was able to set breakpoints and step through the code, but the UI for exploring variables / state while paused felt missing or was unintuitive enough that I couldn't figure it out. I use CLion for debugging.

* Goto definition works with clangd as long as your CMake setup outputs compile_commands.json, which you already do.

* Renaming symbols (variables / functions) via clangd works fine.

* Intellisense is decent, but I had to tweak clangd settings. By default, it would stop returning results after scanning a certain number of symbols, so some valid functions just didn't show up. I was using Helix for a few days before realizing this problem, it isn't obvious that you are getting an artificially constrained filtered view of your symbols via default clangd. Maybe this is a distro packaging issue though?

* The order of intellisense completions is not great. CLion is smart about surfacing relevant suggestions first. In Helix + clangd, I often get obscure symbols that obviously have nothing to do with my project or context. It's not the worst thing, but it is mildly annoying and noticeable.

* "go to error" doesn't surface errors in files that aren't open. In Helix, space D brings up workspace diagnostics, but it only shows errors for compilation units already open. This appears to be a clangd issue, as space D in other languages will show all project errors. CLion does not suffer from this problem.

* I think you can get LLM suggestions via an LSP, but I've not tried personally. Assuming it's true that you can get LLM suggestions, it's not clear to me that you can run two LSP's on the same file, so it might be a choice between clangd and an LLM LSP? Not sure.

* No integrated build support. You'll probably end up building from a terminal. I use Wezterm with a custom lua script that is invoked on a hotkey. I put a lot of thought into the build UX, and what I've done is both extremely hacky and still not good enough.

Helix is not flexible, it's uncompromising. I like it, but I think it's hard to beat CLion or vscode for C++ development.

I'd say right now, if you have a good setup already, stick with what you have.

Creators have stated that while their viewcount is down their ad revenue is not - but a lower viewcount still presumably hurts youtubers for in video sponsorships, and if some genres of video have a higher portion of users with blockers, that probably hurts that entire genre in the algorithm. It sounds like viewcounts are returning back to normal though.