I’d agree.

I think it does _too much_ and the performance is _bad_ but it’s rock-solid for video and audio calls - more than even FaceTime or analog calls.

I mean, doesn't basically everyone with a 401k?

surely the telegraph was the biggest value creator ever?

Or the steam engine, or writing, or... Shareholder value is such an obtuse way to look at the world.

The Roof was an invention the allowed us to delay the rotting of all our harvests. Pretty good.

That's a good one, I haven't thought about needing to invent a "roof".

Also keep you dry when it’s raining, pretty cool.

My “history of technology 101” course was pretty clear that this title lies with the invention of the bowl. Be that pottery or wood. Something to store excess food in for tomorrow.

I would generally say I have a healthy 40hr work week at my current role but multiple MANGA friends have agents doing the bulk of their work.

Have you not found that checking, editing and altering agent work is a ton of work in itself?

I have.

Based on their LoL play time they have not.

idk man, I'm having Claude automate things people were doing manually (usually entering data in a years old spreadsheet).

I can get a good PowerShell script worked out in a few hours and it's on to the next ticket.

Nobody seems upset they're not spending hours a month in a spreadsheet, I still text my wife and our mortgage is paid.

I've had a .name for almost a decade now and was not aware of it's history.

Shame I didn't register on my lastname .name , I had thought it was a much newer gTLD.

there's a number of Marketplace listings for 8th/9th gen mini PCs ~$60 nearby me.

My friend has gotten full Linux on a number of weird RISC-V boards. https://github.com/queenkjuul/milkv-duo-ubuntu

Milk-V Duo has been a pretty popular RISC-V board, one of the more mainstream affordable RISC-V boards. We did a reading group on RISC-V machine code where we used this as the initial board. It even has it's own fcked up vector instructions that are based an RVV draft with some extensions. gcc has its own arch specifier for it (xtheadvector*, e.g. -march=rv64gc_xtheadvector).

The Jupiter 2 has standard RVV, but also another set of cores that are designed for AI with non standard matrix instructions...

I've never _actually_ implemented a filesystem, but when researching OS dev it seemed like FAT32 was pretty close to what you'd write as a minimum viable filesystem while being a very well known quantity.

Yes, I think that's a fair assessment, although the fractal of stupid runs deep in FAT32: a separate 5-bit field for seconds within a minute? Separate fixed-width fields for filename and extension? A 4 GiB file size limit?

But, although FAT32 does indeed have the virtue of relative simplicity, that's no excuse for VFAT.

I might be unfamiliar with the terms - is there a distinction between FAT32 and VFAT?

VFAT is the way that some operating systems implement long filenames in FAT - PROGRA~1 and whatnot. It's pretty messy.

Windows 95 introduced long filenames to FAT, and implements the file system in the VFAT.VXD driver. “VFAT” is thus sometimes thus shorthand for FAT with “Windows style long filenames”. It can be applied to all variants of FAT, such as FAT16 and FAT32.

FAT32 is a variant of FAT introduced in the mid 90s with Windows 95 OSR2 that better supports large hard drives (beyond size limits, cluster sizes were getting too large on FAT16 drives etc.).

Not really, no. Linux regards various ways of looking at the same on-disc filesystem format as distinct filesystem types: msdos, umsdos, vfat. Old Microsoft doco from the 1990s that is still lying around explains things in the way that they historically progressed rather than structurally, describing VFAT as an extension of FAT32.

The reality, certainly in respect of the headlined subject, is that the bitness of the FAT and the style of the root directory (fixed location or variable length) are the only meaningful variants. In 2026, no-one aims not to support long filenames on FAT, and EFI understands them natively. EFI copes with all three bitnesses. And it does the conventional thing of variable length root directory on 32-bit and fixed-length root directory on 16-bit and 12-bit.

FAT is a very poor filesystem format, and no, it's not a minimum filesystem format if one is writing one's own operating system. It's a lazy filesystem format, inasmuch as the cross-development tooling for it exists. But if one were writing a minimum filesystem for one's own operating system, one could start from much better places. FAT is not minimal by any reasonable definition even if one is not writing one's own operating system, and requires an awful lot of hoops to be jumped through that are only there because one is being compatible with the cross-development tooling, several decades of historical changes, and whatnot.

One could use the original UFS, for example. LEAN exists. Over 20 years ago, I invented HPFS2.

* https://jdebp.uk/Proposals/hpfs2.html

HPFS2 looks appealing. Did you implement it? And what were the design blunders in LEAN you decided not to go into in the footnote?

Given that normally UEFI only needs to read the filesystem, not write it, I think a more appropriate filesystem might be something like ZIP.

wouldn't it come with your install?