Fixing the municipal waste system seems like the "add another system" school of engineering. As someone who works in poorly organized, poorly funded projects, I generally subscribe more to the "remove the problematic part of the existing system" school.
Getting rid of single-use wherever possible removes the broken part. I agree that we should also add more systems like proper waste disposal, but it's more complexity to count on.
> Dedicated graphics cards are faster but not to the point that it matters.
It definitely matters, if you're intending to run a Claude Code/OpenCode style agent workflow. Most of those harnesses start with 8-12k token contexts, which is a lot of prefill for a Mac but cheap for a CUDA GPU. The GPGPU compute on the fastest Macs is still trailing behind Nvidia's laptop GPUs; the highest-bandwidth Apple Silicon chip (now the M5 Ultra) has ~7x lower memory bandwidth than a single B100 card.
There's a good reason why Apple Silicon isn't to be found anywhere in the datacenter buildout. It's nonviable for training, and wastes electricity running real-world inference workloads.
I dunno why Apple fans do this thing where they pretend that their specific workflow is the standard for how things work, and because they can do it so well on their Macs, that means Macs are the best.
To be specific, 5 models at 57 gb means you are using crap quantized models, which suck for any real agentic work. I mean, sure they give you some inference, but compared to the full parameter models like Qwen3.8 and Gemma4 that can run full agentic loops, you may as well just use cloud inference for the price.
You of course could "run" those larger models, but we both know that the tok/sec is dogshit on Macs for those.
And 57 gb is split across 3 cards quite easily, which will all be cheaper than your comparable Mac and way faster.
You really need to educated yourself on how running local models works and what the models like Gemma 4 are capable of, so you don't continue to waste money on Macs.
You mean someone who uses a Mac? I find the term "Apple fan" is used as a way to attack the person.
> that can run full agentic loops, you may as well just use cloud inference for the price.
You can run full agentic loops fine with quantised models. In fact that is likely what you are doing with a 32GB PC Graphics card. Or what model are you using?
You use the right model for the right job. For example granite4.2 is optimised for agentic work and only needs 5GB of memory.
Gemma4 MLX runs fine with the larger model needing 19GB.
Prior to that I had OpenClaw (in Parallels VM) create an application with local models that worked the exact same way as created by Claude. It was more an experiment in how OpenClaw works, hence the VM.
> And 57 gb is split across 3 cards quite easily,
I assume you are talking about a good graphics card. A good 32GB will run you $2K a card, so that $6K to beat out a laptop of similar price, and where the difference doesn't matter.
[edit]
Anyway my main point is Macs work fine for local models. I have a 6 year old machine that proves that.
Running agentic loops doesnt mean just being able to execute them. When your llm is so slow that you are faster writing the code yourself with free gemini that comes with google account, local llm is no longer worth it. Tok/sec is everything.
And 3090 is $1500 used, and 24gb gb of ram. 3x is $4500 for 72gb of ram.
Mine cost $5K probably because I only have ever needed 2TB of SSD.
But this is an old argument that seems to be thrown at Macs. Normally everything is cherry picked to show it's better than the Mac while ignoring all the features.
Although I would hope if you pay $8K you can get something that outperforms the Mac in every way.
It's funny because I was the same as you. I hated Macs with a passion. I saw them as overpriced shiny things that weren't as good as a PC.
Back in early 2000's I was commissioned to build an application that should also run on the Mac.
I bought a second hand old Mac Mini. Within a couple of months I bought a brand new one, and since then I have been on Mac when it comes to non-gaming (even though it can do gaming).
The main reason was I could just get shit done. The operating system is transparent to what I needed to do. With Windows you were forever dealing with the operating system to solve things.
Windows eventually got better in this regards, and more recently worse again.
I own/use windows as well. But mainly for gaming or a VM on an internal server.
Often when people give a comparison of how much PC is better, they compare a PC desktop to a laptop. Windows laptops for the same features is same or more expensive, while feeling cheap/heavy/noisy.
So form factor is one part of it, and then how the whole ecosystem works together with my phone/iPad and other devices.
At the end of the day, if I am doing any serious inferencing then I use my companies server, or Claude.
...
What has amazed me over the years is the sheer hate I get from some people for even owning a Mac. I was probably the same, but I was younger then.
Its died down since ARM came in, but the irrational hate seems wasted. Someone prefers Linux, Android, Windows, etc. Good for them.
That selling point is probably more about using a claude code subscription than running your own models. Because of apple's lockin there are certain things you can only do on apple devices and a mac mini is useful for that
It was common knowledge, though not for most of those (with some exceptions like legacy gaming fans) coming into the PC world much after the early 2000s.
Terminate but Stay Resident was the original DOS function call to allow a utility program to exit but stay in memory waiting for interrupt signals (it will have hooked into those interrupts before calling TSR) to respond to. Utilities that operated in this manner (mouse drivers, and many other useful things) became collectively known as TSR programs and then just TSRs.
There were later other methods of leaving code resident, implemented by various memory managers for background tools that needed to use RAM outside the first 1MB (which in reality meant outside the first 640KB because of how the PC memory map was arranged), but the name TSR stuck to cover them generally.
DOS programs generally were like command line apps today (but simpler, obviously). They did a thing, then exited. Or they showed their "TUI" (as we'd call it today), and when you told it to exit, you got back to the DOS prompt to start the next program.
TSRs were a special kind of program, that instead of telling DOS "I'm done, here's my memory back", said "I'm done for now, but don't unload me", so their memory stayed allocated/used. And you got your command prompt back immediately to continue your work.
TSRs usually hooked into an interrupt like the keyboard interrupt, intercepting a hotkey to re-activate the program (so you could browse your address book while you were in your (text mode) word processor; "kind-of" multitasking), or they offered a service to other programs (like the mouse and CD-ROM drivers).
There were all kinds of things that ran as TSRs. Virus scanners (hooking into disk write/reads), modem tools (showing "RING" in the corner of the screen when the modem detected an incoming call), note-taking apps, address books, you name it.
To expand upon this - the TSR programs stayed in memory after being loaded. Typical use were drivers, for example mouse driver. It loaded, hooked itself in the interrupt table and then exited back to DOS prompt. And this gave you mouse support for other programs.
it'll all be centralized models justifying their capability against local inference in, maybe 3 years or less
once we have a bit more memory fab capacity and the insane bottomless investment in AI giants realizes there is a bottom, local hardware will catch up with model performance to the extent that centralized inference will be downgraded to special cases or for orgs that find it cheaper than buying expensive hardware
but really most power users are going to have 1 TB unified RAM and local models that will do well enough
for light office use you can still have a cheap laptop and a claude subscription
This is really astonishing. Are there no checks and balances in place for design decision in such a critical system component? What were the thoughts of all the major distros when they decided to go with systemd then?
systemd was funded and implemented by the biggest commercial distro, Red Hat, first. Other distros were influenced by its decision (RH has always had a lot of influence on distro direction generally) and followed suit.
I’m not sure Red Hat ever had a lot of database design expertise internally and that probably explains the design and outcome. As I said earlier, the design was not subject to public scrutiny before it was implemented.
Many applications hammer the disk even if the developers don't believe this is an issue, not only journald, unfortunately.
It's my third attempt to make my regular Linux desktop less disk-chatty. This is a huge issue for btrfs and for COW FS in general, because they have massive write amplification for small and frequent writes (38,7 TB written to my idle desktop SSD in 2 years).
If you're interested, here are my findings this time so far:
- workrave: 60 second stat sync https://github.com/rcaelers/workrave/pull/717
- kde klipper: saves to disk on every copy, even if permanent storage is disabled https://bugs.kde.org/show_bug.cgi?id=501030
- kde plasmashell: saves qt shader cache each time notification popup disappears https://bugs.kde.org/show_bug.cgi?id=523805
- bitwarden firefox extension: tries to connect to desktop application every 10 seconds, writes about every failure to browser's WebStorage 14+ KB https://github.com/bitwarden/clients/issues/22192
- firefox datareporting/glean: very chatty .mozilla/firefox/xxx/datareporting/glean/db/data.safe
- ipfs: writes every received DHT announce to disk, 20 GB in 3 hours https://discuss.ipfs.tech/t/constant-writes-to-datastore-log/20316
- mailcow: redis saves data every 5 minutes https://github.com/mailcow/mailcow-dockerized/pull/7405
Yeah docker does a ton of network stuff when you start/stop containers, depending on your configuration. It's extra fun because it can drop existing connections when that happens.
Had a process quietly in a crash loop for a solid month on my workstation until I figured out what was causing my random network outages.
> This is a huge issue for btrfs and for COW FS in general, because they have massive write amplification for small and frequent writes
Have you considered using a different fstype like XFS for this? btrfs is good for homedirs, but I wouldn't necessarily use it for other filesystems (/usr, /var, etc.)
You lose rollbacks, superior syncing, redundancy and data integrity assurance and add complexity for what deceased ssd wear which is hardly an actual problem.
systemd-journald has one of the most deranged log file formats I have ever dealt with, and one of the worse user interfaces, too.
I am not again binary logs, or logs in a database. It's just yet another time I deal with good ideas implemented horribly, horribly badly when it comes to systemd.
I wish Qubes Domain-0 was a customized Gentoo with OpenRC. Fedora with systemd was a poor choice to base off. Nobody should have let Poettering have the influence he was given over userland, systemd is an almost irrevocable mistake.
reply