My favorite example of that was when WinRT app .exe files could not be launched from the command line. Only via some Windows Store voodoo dance with approvals, signatures and "security" that made WinRT for developers essentially a dead-on-arrival technology.
I would not be surprised if you still cannot launch a fricking .exe.
Nope, it wasn't solved in UWP days, neither it's solved today.
To satisfy my interest, I've tried creating WinUI app (aka UWP/WinRT) in Visual Studio 2026. And this is what I've got on the first app launch after compilation:
"This device needs to be set up correctly to develop this type of app for Windows. If you don't, then you can't install and test your app before you submit it to Windows Store"
I don't want to install/submit, I just want to be able to run my fricking .exe. Period.
So why are you calling this issue solved? To me, it's still right there in the plain sight - the same voodoo dances and delusional expectations of subordination to Windows Store.
The UI strategy of the future may very well be HTML. It's widespread, standardized, sufficiently performant, and pretty rich.
What's still missing is deeper integration with native OS concepts and programming languages other than JS. Frameworks like Electron are a step in that direction but they come with notable drawbacks. Applications often struggle with things that should feel natural like managing multiple OS-level windows.
Another PITA: Electron apps repeatedly bundle large portions of Chromium, leading to unnecessary overhead. Those duplicated modules lead to bloated RAM usage: every app has its own Chromium copy and OS must keep all that zoo in RAM without a possibility of reusing the otherwise shareable parts.
not exactly the same, but worth noting that in a spectacular display of being too early, microsoft shipped this 30 years ago (active desktop in 1997 merged the windows explorer with internet explorer, turning folders into web pages).
It was more despised for being a gaping security hole than anything else, as I recall - the things you could do with it were really neat demos, but even back then, I said "I am not loading a random website that can access local things every time I log in".
That was indeed a pain point, but not anymore after CSS flex layout became available some 10 years ago. It's not worse than WPF for sure. It's even better than WPF because you have access to tons of UI components and toolkits that work everywhere.
I think you're comparing hand-writing an HTML/CSS interface to the WYSIWYG form editor of Qt or Visual Studio? Because hand writing a GUI in Qt/QML/C++/.NET is not any easier than writing it in HTML. There are tons of boilerplate and special markup to learn. The magical editor just hides all the plumbing from you.
I'll grant you that the lack of good WYSIWYG designers for working on web/electron apps is appalling, it's like RAD peaked in 1998 with VB6 and it's been downhill ever since.
There's a competing webapp-wrapper framework that explicitly uses the platform's own browser, but developers don't like being at the mercy of whatever the OS ships...
Cursor works better for me than Claude Code. In my opinion, Claude intelligence is too narrow.
Good luck explaining all the details to Claude, it tends to ignore them anyway. Like a middle-level SWE, it's too stubborn to appreciate them, and prefers to blast energy (tokens) on shuffling the lines instead of seeing a bigger picture.
Cursor, in contrast, is a highly educated coder that gets you immediately.
I've got an impression that Claude Code is more oriented on unattended development of CRUD applications, while Cursor is more refined and closer to a senior-level SWE/PhD for productive work in pair.
Everybody says that bots put websites down, while marketing oriented folks start practicing AO (agent optimization) - to make their offerings even more available and penetrating.
JS runtimes are fatty, so embedding one instantly adds at least 30-50 Mb of RAM usage. Imagine that you do this for just for a specific function (JSON processing) and your total RAM budget for a whole pod is around 256 Mb.
No doubt, this approach would work reasonably well for machines with plenty of RAM, but I can see why it can be a bottleneck when scaled to N instances. RAM is expensive, and when you multiply those 50 extra megabytes by N, your total costs quickly climb up.
I presume that it's a difference between Windows OS editions. I turned it off too, but it wasn't as easy as one click, I had to use Group Policies to decrapify the adjacent aspects of the system. Group policies are not available in Windows Home edition, for example.
I just went into the settings for the widgets, turned off the "Start" or "News" experience or whatever it is and it's never come back. Just using the toggle it offers in settings. While I was at it I went into the taskbar settings and just turned off the widgets altogether, never came back. I wonder if sometimes we just assume the worst and resort first to "hack" ways to disable some of these things and when a new update comes along from your company or whoever, it gets re-enabled. Instead of just using the built-in functionality for turning things off.
No worries, this is just how manipulative relationships work: they always aim for unidirectional communication.
You're obliged to consume the most important news from the most important entity on the planet Earth (Microsoft/Facebook/X/...), eat piles of informational crap that get dumped onto you, waste you emotional energy on processing the whole thing, participate in drama and show your admiration. Why? Because you're very convenient when in this state, you're mendable and coercible for whatever action the entity wants you to do without saying it directly.
But when it's time to listen to you and your concerns - surprise-surprise, nobody's home. It's one way only, see you next time, maybe.
P.S. Forcefully installing an attention-pollutve app like News in the Start Menu is nothing less than a way to control you. And for an insatiable ego, the sense of control is everything. This is why it keeps coming back, again and again, as if it's a lucky reoccurring coincidence. A Windows Update repairs the system? Yes, plus it repairs the system of control. Security patches are very convenient vehicle for that - once you eat it, you'll be served special dishes you never asked for.
While we have `sandbox-exec` in macOS, we still don't have a proper Docker for macOS. Instead, the current Docker runs on macOS as a Linux VM which is useful but only as a Linux machine goes.
Having real macOS Docker would solve the problem this project solves, and 1001 other problems.
Why not? They're definitely not perfect security boundaries, but neither are VMs. I think containers provide a reasonable security/usability tradeoff for a lot of use cases including agents. The primary concern is kernel vulnerabilities, but if you're keeping your kernel up-to-date it's still imo a good security layer. I definitely wouldn't intentionally run malware in it, but it requires an exploit in software with a lot of eyes on it to break out of.
It's certainly better than nothing. Hence "probably doesn't matter too much in this context" - but of course it always matters what your threat model is. Your own agents under your control with aligned models and not interacting with attacker data? Should be fine.
But too many people just automatically equate docker with strong secure isolation and... well, it can be, sometimes, depending a hundred other variables. Thus the reminder; to foster conversations like this.
counter-intuitively, the fact that docker on the mac requires a linux-based VM makes it safer than it otherwise would be. But your point stands in general, of course.
> Having real macOS Docker would solve the problem
I'm very slowly working on a mock docker implementation for macOS that uses ephemeral VM to launch a true guest macOS and perform commands as per Dockerfile/copies files/etc. I use it internally for builds. No public repo yet though. Not sure if there is demand.
What would native containers bring over Linux ones? The performance of VZ emulation is good, existing tools have great UX, and using a virtualized kernel is a bit safer anyways. I regularly use a Lima VM as a VSCode remote workspace to run yolo agents in.
Sometimes you just have to run native software. In my case, that means macOS build agents using Xcode and Apple toolchains which are only available on macOS.
It's not a pleasure to run them in a mutable environment where everything has a floating state as I do now. Native Docker for macOS would totally solve that.
VZ has been exceptional for me. I have been running headless VMs with Lima and VZ for a while now with absolutely zero problems. I just mount a directory I want Claude Code to be able to see and nothing more.
> What would native containers bring over Linux ones?
What would a Phillips screwdriver bring over a flathead screwdriver? Sometimes you don't want/need the flathead screwdriver, simple as that. There are macOS-specific jobs you need to run in macOS, such as xcode toolchains etc. You can try cross compiling, but it's a pain and ridiculous given that 100% of every other OS supports containers natively (including windows). It's clear to me that Apple is trying to make the ratio jobs/#MacMinis as small as possible
I would not be surprised if you still cannot launch a fricking .exe.
reply