If the main to run Apple computers is their hardware, why not to run it with Linux. Aside from better filesystems (Theo tests were shocking to me, how bad FS you guys have), you would get better compartmenalization and I believe better security. What's missing?
> There is one aspect in which the Mac is the perfect agent host: Apple has, for decades, invested in a combination of scriptability, automation, and accessibility APIs (these are very often the same thing) that makes it remarkably well-suited to computer use.
It's the software that matters here, not the hardware.
> I use screen-sharing constantly — including from my phone — and almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously;
It's insane what people will put up with to avoid just doing it properly on a real OS.
Better design in terms of resource isolation and control, too.
I use krunai. It is not quite as flexible as some people probably want (strongly linked to a specific non-systemd version of Debian 13), but there are many other options as well, such as Lume, Virtualization.framework, etc.
Much better than wrangling server code via Apple nonsense, and there are no real downsides after you've done the integration/deployment work once, assuming you are not building on some closed source thing that only runs on macOS.
No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.
It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.
Fossil is very opinionated about some things, in particular, the inability to rewrite history, which makes it a non-option for some. So there's still a niche for Git-based distributed bug tracking.
I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
There is an alternative to auto-resolution or fixing low-level git merge conflicts. In my git forge Haxy, I am detecting conflicts in local-first metadata and allowing you to fix them in the UI. This is possible because I am not doing a line-based merge; the issues are stored as a data structure, so I can see what specific parts are in conflict. This allows a much nicer form of conflict resolution than conflict markers in a text file. I demoed this here: https://www.youtube.com/watch?v=kkGUARj5Wdw and here's the project: https://github.com/xit-vcs/haxy
I think the problem with his ask in that initial picture is mentioning Pi, which doesn't do headless CLI, but does do the OAuth that the TOS specifically mentions.
And if I am not mistaken, Theo’s T3Code (which was explicitly told was bad), doesn’t even use anything else than AI producer provider command line tools and use them with `-p`.
