Which does kind of suck. Yeah, it's not nearly as cool to say "I prompted a probabilistic pile of tensors and it did the hard work for me", and I think it majorly adjusts how "impressive" projects are. There's no point pretending like decompiling a game by hand and using GPT-6.7 to do it are remotely comparable.

The suck-y part is that if you do the decomp with GPT-6.7 and produce, say, a PC port of an early 2000s console game, a large number of people will refuse to touch it and treat it as if you have committed a cardinal sin. Maybe that's justified? I dunno. It definitely goes beyond people just saying it isn't as fun.

I like to make computers do the things I want. Since I was a kid, the satisfaction from programming or any sort of "computer engineering" (using the word engineering VERY loosely here) is in making something specific happen.

Sometimes, that means understanding the correct data structure to use, picking the right algorithm, and other computer science-y things.

Other times, and more often (for me), it means death by a thousand papercuts in managing third party dependencies, boilerplate, and other tedium and minutia.

I'm not someone who is "proud" of barely coding anymore, and I'm not entirely sure how I feel about the "structural soundness" of using LLMs this way (most of my coding is personal/hobbyist work), but I can confidently say that I don't really code just because I love coding, at least necessarily. I like making stuff.

A fun test would be to compare the logits for "gemini", "claude", etc for a continuation of "I am " on all these models. I'm sure that e.g. GLM, Qwen, DS are dominant, but I'd be curious to see the next highest contenders, and how they compare to each other.

- A MUD based on some derivative of the TinyMUD codebase, colloquially called "MUs"

- Literally any other "MUD"

These two categories of "games" are both legitimately called "MUDs" but also have almost nothing in common with each other. The union of "MU" players and "MUD" players is not that large, in my experience. MU servers tend to function somewhere between glorified Discord servers and sandbox programming environments.

Even more specifically, within the MU* space, the different forks of TinyMUD ended up adopting different subcultures, programming languages, and general vibes. Despite all being superficially similar, telling someone you play a:

- MUSH

- MUCK

- MOO

says a great deal about both you and server. MUCKs are furry subculture for the most part and use Forth for programming, while MUSHes are ... more Star Trek/Lord of the Rings coded. With other weird differences: MUSHes tend to have elaborate mail and Discord-like comm systems built in, MUCKs tend to eschew those in favor of "hanging out in the same virtual room".

IME there isn't this same feeling in "other MUDs". You don't "identify" DikuMUD or LPMUD players in the same way, so I don't think the question makes sense to anyone who isn't a MU* player.

The difference here is almost entirely cultural, since technologically, LPMUDs and MUSH/MOO/MUCKs aren't that dissimilar. But LPMUDs are almost never used the same way, at least I've never seen it.

I've got an RX 7900 XT (20GB of VRAM) and I can run glimmer with a full 128k context window with the draft model at 65-80 tok/s.

This model, on the other hand, I get about 30 tok/s with a 30k context. Raising the context or loading the draft layers for MTP drops performance to 9-15 tok/s.

So I wonder how big the "real world" delta between Glimmer and Qwen is here. I can already run 3-bit DSv4-flash at 9-15 tok/s with 100k~ context, and I suspect it would outperform 4-bit Qwen 3.8 27B here.

I'll have to experiment and see if I just made a stupid mistake somewhere, but it looks like Glimmer might make more sense for the comically specific niche of "20GB VRAM".

GLM ended up being far slower, and far more expensive, for approximately the same results. There was never a problem that GLM could solve that DS couldn't solve, faster, and significantly cheaper.

I strongly agree that you shouldn't pick a model based on benchmarks. But for me, I found GLM really underwhelming given its cost and speed.

DSv4 isn't as good as GPT or Claude or what have you, but it's fast, and pretty darned effective. I can run a 3-bit quant of DSv4 locally on my system with ~15 tokens per second, and for a local model it might be the most overall effective at coding. For what it is, it's extremely impressive.

Makes for a fine image if "looking good" is the objective (which it often is), but I wouldn't trust it to disambiguate anything uncertain.

But if the basic premise of "good enough LLM at insane throughput" holds, I think it could qualitatively change local uses of LLMs. At a certain speed point, you're able to move from request -> response to a cascade of tool calling and "subagents", which could allow a small model to be much more useful, if provided with a lot of local data and tool calls.

That said, this is assuming you could stuff a "good enough" model into a phone with Taalas-like technology. The Taalas tech demo was an 8B parameter model and required hundreds of watts (IIRC) to run. The efficiency was good given the speed (as I understand), but it's not clear at all that the approach scales small enough to be a sensible coprocessor on an iPhone or whatever.

I say this not as a complaint, but to explain my perspective on using LLMs for personal projects. Granted, I'm publishing none of them, and not trying to make anyone care about them, so it's not really a response to the article or general discourse here per se, but I thought it bears mentioning anyway.

I'd like to buy into the idea that "doing it yourself" is more meaningful or personally edifying, but I don't get that feeling. I want to get that feeling, but I don't. I've found my private waste-of-time projects using LLMs have been more gratifying than my private waste-of-time projects that don't, and at the end of the day, neither really substantively matter anyway.

Again, this isn't really related to communities per se, but it is an answer why some folks use LLMs for projects/"hobbies".

I wasn't around at the time, so I don't know what availability and pricing actually looked like, but unlike the other RISC platforms, Alpha was actually available on PC-like systems, with PCI and ISA busses, and x86 emulation at the firmware layer, allowing regular PC peripherals like VGA cards to work. Windows and, significantly, Linux, had pretty superb support for Alpha.

It's not enough to suggest that it had a chance "in any reality", but it seems like a much more potent competitor than PowerPC or SPARC or MIPS, it only because of the platform and OS support. Both Windows and Linux had pretty capable x86 emulation software layers too, and not just at the very end!

[0] GCC still supports PDP-11, for example, but for a while modern GCC had some major codegen bugs. Last I checked, the maintainer had made heroic efforts to fixing the bugs, but that's just an example of where bitrot silently renders a target unusable.

Gemini (the web UI) used to show raw reasoning, or at least a more detailed summary of its reasoning, less than a year ago. Complete with markdown and weird spelling idiosyncracies, so I'd lead towards "real reasoning", but who knows. The reasoning block leaked the system prompt way more often than the response block did, and you could figure out why it would refuse a request through the reasoning, even if the response itself refused to elaborate. This is, presumably, why they stopped showing it. No loss for them, just prevents "pesky users" from low hanging fruit snooping.

(Gemma 4's reasoning and output remind me strongly of what I remember Gemini 2.5/3's reasoning to be, as an aside. I guess that's obvious, but Gemma 3 felt like a totally different model, while 4 feels very Gemini-ish.)

Probably more relevant on more "borderline" hosts. My SPARCstation 2 can just barely run NetBSD 10 at what I'd call "tolerable speeds" for some concept of "real work", and it's something like 50x the speed of the 780!

I hate to imagine what a 780 running NetBSD would be like, too.

I tried netbooting NetBSD on my MicroVAX 3400, which is about 2.5x the performance of the 780. It did, literally, take 6+ hours to slog through making RSA keys.

Ultimately though the real explanation, I think, is Google doesn't care since for their own purposes (in LiteRT-LM), they do bundle them. As far as I know, anyway.

While I have no idea who was, I do know that John Ousterhout's text editor and terminal emulators Mx and Tx used "natural scrolling", made pre-1989. Their scroll mechanism is shift + left/right click then drag, using "natural scrolling", e.g. push mouse up to scroll down. Left click scrolls normally, right click scrolls quickly.

There's no reason you couldn't build a solid, headless PC-compatible architecture based around EFI. It would just... cost money. Even in the retrocomputing stuff you see the same thing happen. Older VAXes had very rich boot PROMs, but by the time you get to models like the 4000 "Very Low Cost", most functionality was stripped out of the PROM to save space and cost.

This isn't to disparage them, either. GP admits they are romanticizing, I'm just offering my own perspective on it. When I call old stuff "hacked together piles of garbage", it was meant with the loving connotation of someone who's home office has a MicroVAX 3400, Sun 4/75, DEC PWS 433a, and a POWER9 workstation piled in the corner, all on a KVM switch. I love tinkering on these old machines, but I think it's healthy to remember they're not beacons of 80s/90s perfection, but products that were made and sold under time/cost constraints, as you said.

... Though, I will say, the MicroVAX was running from the late 80s until about 2018 in a university environment, and its HDDs still report no errors. That is pretty remarkable ;)