jmmv

Yeah, structs (records) is something I've been wanting to add and that became reasonably easy with the full rewrite of the compiler I did in 0.13. Probably in the next update!

What do you mean? FUNCTIONs are supported, and their arguments and return values are strongly typed.

Two years ago, I spent time studying the Windows NT kernel internals and ended up writing a comparison against Unix here: https://blogsystem5.substack.com/p/windows-nt-vs-unix-design . What I came out of that exercise with is that NT is actually well-made and was very ambitious and advanced at the time it was designed (although free systems have caught up by now).

But what I also came out thinking was: none of that shows. The kernel is great, sure, but all of the crap that has been built on top doesn't let it shine, and that's what people interact with. Take Windows 11 with is dog-slow file manager and the overall feeling that everything is bloated and designed to annoy you. I wish there was a simpler edition... but it ain't gonna happen.

Only the very first few models of Intel Macs had strictly 32-bit processors (the 2006 iMac and Mac minis with Core Solo/Core Duo processors), and none of them were realistically capable of playing Half-Life 2.

What? First, those chips were plenty powerful to run HL2 (the game predates them). And second, all x86_64 chips can run older x86 32-bit code unmodified.

The reason macOS stopped supporting 32-bit code has nothing to do with the processors but more about them wanting to remove support for 32-bit binaries from the kernel and from all user-space libraries. To run a 32-bit binary, you need itself and all libraries it depends on to be 32-bit too, including the syscall boundary, which is "fine" (both Windows and Linux do this just fine, so it's really on Apple to have removed this). And I suppose Apple removed those because it was building towards a 64-bit-only world to simplify the Apple Silicon transition.

It's a little bit sluggish, isn't it? And takes quite a bit of time to boot, right? It's certainly usable, though, not worse than your average website these days. I intend to use this setup for next Advent of Code. > But here's the kicker: This is Windows 2000 SP4 running on a Pentium 133 with 64 MB of RAM and a spinning harddisk

Heh, gotta reference https://jmmv.dev/2023/06/fast-machines-slow-machines.html (https://news.ycombinator.com/item?id=43972004) from a few years ago. There is a video in there of Windows 2000 running on a K7-600 from 1999 and it indeed flies.

Sure, and I'm not arguing that the answers are uninteresting, but I found it odd that this is being double-quoted several times as if it was taken out of the article.

I'm curious... why are people (this thread, but there are several independent others) replying to "Is anyone still using emacs?" ? I don't see that sentence anywhere in the article!

Thanks. I haven't documented it (yet?) but I did give a talk last year on the process that got me there and the internals behind this system: https://www.youtube.com/watch?v=WZFYTInWAqc

I went through a similar "thought process" to build this: https://www.endbasic.dev/endbox.html last year. I originally wanted to "just" launch my binary right after the kernel started... but in the end settled for a full NetBSD base system to get things like network and WiFi configuration to work with ease. (That said, I still hook very early in the boot sequence to launch my own program and take over the console so that the rest of the system is invisible and initializes in the background.)

They probably meant 2010s.

I remember this was the time when Google started pushing the Chromebook idea and highlighting how it could boot in "just a few seconds". One of the earliest models I got as a dogfooding device probably needed 20 seconds to boot or so. Nice, compared to the awful boot times of machines with HDDs... but not stellar.

But then, in 2011, my wife bought a MacBook Air with an SSD and I was blown away. That thing booted to a full desktop (and not the joke that ChromeOS was) in... 5, 6 seconds? It was ridiculous.

And we have lost all of those gains. I find it painful to witness how a recent Mac chews through I/O during boot or doing any sort of software update (iStat Menus is great to watch this sort of thing), and how these feel slower to that early experience of 15 years ago :-/

I’m starting to fall in love with CDs again.

I visited a long-time friend recently and was surprised that they were using modern LP player for music. But the surprise itself actually turned into curiosity. I got the urge to buy one too, if only to go back to the more-dedicated experience of choosing a disk from a catalog and playing it with explicit intention.

Maybe LPs are too much, but trying physical CDs again sounds like a cool idea. Especially because they can easily be rewritten and maybe I could get kids to create their own "mix tapes".

More Inevitabilism posting with the “not happy with” but is-what-it-is washing of your hands

OK so, _realistically_, what can you do that will make any meaningful difference?

Huh, that's an angle I hadn't thought about. It'd be cool indeed!

Shameless plug for my https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-i... article from a couple of years ago. You'll find a deep dive on unreal mode (I just learned it's also known as "vodoo mode") and some hands-on code to play with it ;-P

I'm sorry but the landing page at fuzix.org (the top page nonetheless) is terrible as it does not even try to explain what FUZIX even IS. I went to the GitHub project page, which contains some more details, but it still doesn't answer the question and only talks about how FUZIX differs from UZI.

To be honest, I still have no idea what I'm looking at.

the generated code just annoys me and the agents are too chatty

I’ve eyerolled way less with Codex CLI and the GPT models than with Claude.

It sounds like you haven't tried.

LLMs definitely can do this. The output tends to be overly positive though, claiming that any sort of rough draft you give them is "great, almost ready for publishing!". But the feedback you can get on clarity, narrative flow, weak spots... _is_ usually pretty good.

Now, following that feedback to the letter is going to end up with a diluted message and boring voice, so it's up to you to do with the feedback whatever you think best.

I was reading this and couldn't stop thinking https://en.wikipedia.org/wiki/Literate_programming

No, I _never_ referred to the GUI versions.

I started playing with NixOS recently in a VM and... while I don't have much experience with it yet, it feels _great_ for the many reasons described in the article. I really like configuring a file and knowing that the rest of the system aligns to whatever that file says: no more, no less.

The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.

Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P

I’m not sure why any of this matters? I was looking at top, and the only two non-idle processes were claude and codex.

and (partly as a result) it's fairly resource inefficient (often uses 1GB of RAM or more. For a TUI).

That's (one of the reasons) why I'm favoring Codex over Claude Code.

Claude Code is an... Electron app (for a TUI? WTH?) and Codex is Rust. The difference is tangible: the former feels sluggish and does some odd redrawing when the terminal size changes, while the latter definitely feels more snappy to me (leaving aside that GPT's responses also seem more concise). At some point, I had both chewing concurrently on the same machine and same project, and Claude Code was using multiple GBs of RAM and 100% CPU whereas Codex was happy with 80 MB and 6%.

Performance _is_ a feature and I'm afraid the amounts of code AI produces without supervision lead to an amount of bloat we haven't seen before...

Somebody blamed this comment on LLMs, and maybe/probably it is, but I think the first sentence is spot-on so I thought it was worth replying to.

Dealing with the corner cases ends up teaching you a lot about a language and for an ancient language like the shell, dealing with the corner cases also takes you through the thinking process of the original authors and the constraints they were subject to. I found myself in this situation while writing EndBASIC and wrote an article with the surprises I encountered, because I found the journey fascinating: https://www.endbasic.dev/2023/01/endbasic-parsing-difficulti...

To be honest I've never tried boot environments. I know they are a thing, and I have my whole setup on ZFS, so maybe that's the perfect use case.

I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.

I haven't done that yet because I think I'd want to switch to pkgbase but that makes me nervous. Did you go with that option or continued to use the sets?

“Modern TUIs may support mouse events” hah! They already did in the 80s…

Huh, in a point release?

But excited to try it out ASAP! I haven’t made the leap to 15 on my server yet (in part because I can’t decide whether to go with pkgbase or not…), but sharing data more easily with VMs will surely be nice.

What’s the performance like?

I don't disregard what you are saying and believe that being more productive with sufficient quality is _possible_.

But how do you measure it? All the metrics I see being chased (metrics that were never accepted as productivity measurements before) can be gamed with slop, and so slop is what we'll get.

If we have been complaining about bloat before, the amount of bloat we are going to witness in the future is unfathomable. How can anyone be proud of a claim like "It's 3M+ lines of code across thousands of files." _especially_ when a lot of this code is relying on external dependencies? Less code is almost always better, not more!

I'm also getting really tired of claims like "we are X% more productive with AI now!" (that I'm hearing day in and out at work and LinkedIn of course). Didn't we, as an industry, agree that we _didn't_ know how to measure productivity? Why is everyone believing all of these sudden metrics that try to claim otherwise?

Look, I'm not against AI. I'm finding it quite valuable for certain scenarios -- but in a constrained environment and with very clear guidance. Letting it loose with coding is not one of them, and the hype is dangerous by how much it's being believed.

This is something that always bothered me while I was working at Google too: we had an amazing compute and storage infrastructure that kept getting crazier and crazier over the years (in terms of performance, scalability and redundancy) but everything in operations felt slow because of the massive size of binaries. Running a command line binary? Slow. Building a binary for deployment? Slow. Deploying a binary? Slow.

The answer to an ever-increasing size of binaries was always "let's make the infrastructure scale up!" instead of "let's... not do this crazy thing maybe?". By the time I left, there were some new initiatives towards the latter and the feeling that "maybe we should have put limits much earlier" but retrofitting limits into the existing bloat was going to be exceedingly difficult.