No headless RDP solution is pretty unforgiveable in 2026 - right now I use Nomachine and indeed it requires X11. Why wouldn't Wayland have a solution for this? It is not a niche usecase. It is like, a headline, completely mainstream use-case.
Blind spot that comes from incompetence and arrogance. See https://lwn.net/Articles/553415/ for example and remember famous words of Daniel Stone that brought the need for remote work to - merely - launch xeyes.
Thus, that particular comment (https://lwn.net/Articles/555124/) was prophetic:
"With that sort of attitude, I have no confidence that remote Wayland will ever work properly. Clearly Daniel just has a laptop and does all his work on it, and damn everyone who uses more than one machine for anything."
Proton Mail not supporting filters for message bodies is brutal, I understand why they don't do it but that really lowers its usability for me. Bummer.
Honestly, for most open-source apps where you don't want to Deal with this, the answer is to just get it into Homebrew. They handle re-signing apps using the local computer's ad-hoc signature and for most apps this is by-far the easiest way to deal with Stupid Apple Bullshit.
I don't think this is true. A normal CS signing cert is sufficient for most commercial apps - you will get the SmartScreen warning for a few days but it will go away fairly quickly.
The important part is that SmartScreen reputation is URL-based, you need to make your initial download URL consistent. If you are constantly rewriting it (i.e. with a version #) it will break. It's ok if the original URL hits a 302 to the latest version.
This hasn't been my experience, ROCm is usually not only a bit slower for me (~32 t/s vs ~43 t/s on the main model I use), it is way less reliable; any upgrade in kernel version or AMD driver and suddenly everything is broken
It can be tricky to get/keep ROCm working, but around 7.2 it became reliable and as fast as or faster than ROCm 6.4.
And, I think the first response time of ROCm is pretty consistently faster than Vulkan, even if Vulkan has a slightly higher token rate. Though I don't see that big of a different on token rates, either. Honestly, though, I haven't done enough real testing to know for sure. The benchmarks Donato Capitella posts (https://kyuz0.github.io/amd-strix-halo-toolboxes/) have been my guide on what to run in what way, and the performance of most things that can run on the Strix Halo are Fast Enough(tm) such that I don't agonize about performance. When Vulkan was all that worked with llama.cpp, that's what I used. Now that ROCm is reliable, I'm using ROCm. ROCm feels faster, maybe just because it processes prompts faster and starts typing the answer fast (at a rate faster than I can read it, so when it starts answering is the more important metric even if faster token rate would lead to it finishing faster).
In short: If ever I'm doing something that will take many hours to complete, and I need to optimize it, I'll do some tests first to be sure I'm using the optimal path. Otherwise, as long as ROCm is working, I'll probably just keep using it.
Sure but on the flip side, skills not being in context means that for many harnesses, the model simply never finds them. Whether MCP or Skills are "better" depends extremely heavily on the context management functionality of your harness because if you use a relatively naive harness (i.e. one that implements MCP and Skills in a straightforward way), MCPs will generally be more effective, especially if your model is local-only (i.e. dumb), but at the cost of context.
That'll work great until your first customer from a CJK or RTL language writes in, "Hey, how come I can't type in your app?", or the blind user writes in "Hey how come your app is completely blank?" then you'll be right in the middle of the "Find Out" phase
These strategies are fine for toy apps but you cannot ship a production app to millions or even thousands of people without these basics.
reply