leah's tiny pc retirement home

a small cryptid caught in time's headlights.
'she/her' unless you know me

32 bits ought to be enough for anyone!

don't assume i know anything about anything

apparently this needs saying, so:
DO NOT BARGE INTO MY MENTIONS
TO PICK A FIGHT. i come here to chill
out, not argue. if arguing chills you out,
go somewhere else.

also, no DMs. ever.

#noai #nobot #nocops #acab

(btw, the millihertz on bluesky is _not_ me;
i have no bluesky presence at all.)

favourite instruction: ex (sp),hl
avatar from: cover of BYTE's Aug 80 issue
header from: Mars!

miaowier alt: leah & flutters & nose, oh my! (npub1dx9…0s5v)

Public Key

npub14fhm8fq6muz9cytfxkd8w3wl5p2m3hk8lx7hkmw9zc88acm3546sc0kjcu

NIP-05 Address

millihertz_at_oldbytes.space@momostr.pink

Profile Code

nprofile1qqs25man5sdd7pzuz95ntxnhgh06q4dcmmrln0tmdhz3vrn7udc62agpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds7a9atj

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub14fhm8fq6muz9cytfxkd8w3wl5p2m3hk8lx7hkmw9zc88acm3546sc0kjcu

Show more details

Published at

2026-08-17T17:00:49Z

Kind type

0 Metadata

Event JSON

{ "id": "ba6dbb2e8541ff24d47556a28e4aea930eb2415f20b989a1dba7a655bbc85c9a", "pubkey": "aa6fb3a41adf045c1169359a7745dfa055b8dec7f9bd7b6dc5160e7ee371a575", "created_at": 1786986049, "kind": 0, "tags": [ [ "t", "acab" ], [ "t", "nobot" ], [ "t", "nocops" ], [ "t", "noai" ], [ "proxy", "https://oldbytes.space/users/millihertz", "activitypub" ], [ "L", "pink.momostr" ], [ "l", "pink.momostr.activitypub:https://oldbytes.space/users/millihertz", "pink.momostr" ], [ "-" ] ], "content": "{\"name\":\"leah's tiny pc retirement home\",\"about\":\"a small cryptid caught in time's headlights.\\n'she/her' unless you know me\\n\\n32 bits ought to be enough for anyone!\\n\\ndon't assume i know anything about anything\\n\\napparently this needs saying, so:\\nDO NOT BARGE INTO MY MENTIONS\\nTO PICK A FIGHT. i come here to chill\\nout, not argue. if arguing chills you out,\\ngo somewhere else.\\n\\nalso, no DMs. ever.\\n\\n#noai #nobot #nocops #acab\\n\\n(btw, the millihertz on bluesky is _not_ me;\\ni have no bluesky presence at all.)\\n\\nfavourite instruction: ex (sp),hl\\navatar from: cover of BYTE's Aug 80 issue\\nheader from: Mars! https://immortal.org/wp-content/uploads/2015/10/mars-surface.jpg\\nmiaowier alt: nostr:npub1dx9hm5h8r8vnpcz8frll3zyj3lcmys74nzy7p383ew4hc38tlzgq4l0s5v\\n\",\"website\":\"https://oldbytes.space/@millihertz\",\"picture\":\"https://assets.oldbytes.space/assets.oldbytes.space/accounts/avatars/000/137/950/original/d3929e8c5aa1f765.jpg\",\"banner\":\"https://assets.oldbytes.space/assets.oldbytes.space/accounts/headers/000/137/950/original/5572d6cecffad118.jpg\",\"nip05\":\"millihertz_at_oldbytes.space@momostr.pink\"}", "sig": "4a7c749a538b6fc3f3ce23148113d7ad1197a42311a292f55690be91fcbd92a4a0b71ee2ebea1161faf804c6c459838810c75b0ddd2e1c265571a8e5d05522ac" }

Last Notes

2026-07-26 03:57:40 UTC

TIL EFI shell 1.1 included both a text editor and a hex editor. kind of surprised it doesn't include the equivalent of DEBUG too

2026-07-26 03:39:17 UTC

when even OSDev's approach to calling UEFI is "don't worry your pretty little heads about it, the C compiler and headers have you covered", you know something has gone fundamentally wrong with computers

2026-07-18 13:31:13 UTC

> All of the AI projects we have observed as a team are failing. Every single one – we have seen 0% success in a year and a half, not only amongst projects we have been asked to participate in2, but even within projects that we have observed in passing while doing totally unrelated work.
> -- > [> https://> ludic.mataroa.blog/blog/ai-man> ia-is-eviscerating-global-decision-making/](https://ludic.mataroa.blog/blog/ai-mania-is-eviscerating-global-decision-making/ )
sometimes the plural of anecdote *is* data

2026-07-14 15:28:06 UTC

> I don’t understand this complaint. The maintainer didn’t write this software for you
i never cease to be amazed at how many ways software developers can find to reject any and every notion of responsibility to their community.
if the author really didn't write it for anyone but themselves, why did they publish? if the author is also the maintainer - the only instance in which your statement might even be testable! - then why do they fix bugs they have not encountered?
if you maintain software for a community, you are implicitly accepting the responsibility to do so properly. if you don't want to do that, vacate the position for someone who will. better that software be thrown over the wall than maintained badly.

2026-07-11 15:20:36 UTC

- reply

also, it turned out to be yet another dialect of Lisp

2026-07-10 15:05:04 UTC

remember when Firefox *didn't* randomly fall over after a few hours for no apparent reason whatsoever?

2026-07-07 00:46:23 UTC

surprised to discover that Voidlinux still packages XForms!
so i immediately tried to compile LyX 1.4.5.1 with it, that being (afaik) the last version that supported XForms; but unfortunately, it failed because strcmp and strncmp are no longer members of std
the wonderful thing about open source: if you want to compile one thing from 2007, you damn well better have *everything* come from 2007
the past is another operating system; they do things incompatibly there

2026-07-07 00:17:03 UTC

- reply

i remember you posting the results on here

2026-07-07 00:15:08 UTC

- reply

on the other hand, if the Athena widgets had been released with a default .Xdefauls that made them actually attractive, we maybe wouldn't have poured *quite* so much time into trying to come up with alternatives

2026-07-06 23:47:15 UTC

of course, the single reason Motif didn't take off in the open source community is that it wasn't. it is *now*, far too late to make a difference; but back when, if you wanted to write open source graphical apps, you basically had to use XView or one of a bunch of variations on Athena.
XForms had the same problem. although it went LGPL a decade earlier than Motif. so did Qt at first, until it realised it could pioneer the dual-licensing model - but by then GTK already existed, and the X11 world had been sent to hell forever :-( had XForms been open from the start, we'd probably never have ended up with the whole KDE vs GNOME mess - we'd all be using XFCE instead

2026-07-06 23:33:52 UTC

> Even the vanilla X11R4 “xclock” utility consumes 656K to run. And X’s memory usage is increasing
> -- UNIX-HATERS' Handbook, p.123
oh... you sweet summer children...

2026-07-05 16:40:14 UTC

> Some say the learning curve is steep, but you only have to climb it once.
said someone who never had to use tar or find

2026-07-05 04:54:16 UTC

- reply

i've successfully compiled stuff that used autotools from decades ago. and yet, CMake won't work with something released in August 2024.
i can only conclude that CMake isn't intended for use in the same way that autotools is; it's only intended for short-term use within closed development projects.
that's fine, but they need to say so, and explicitly counsel against source releases that rely on CMake.

2026-07-05 04:47:29 UTC

this is for software released *less than two years ago*:<code>$ cmake . CMake Error at CMakeLists.txt:11 (cmake_minimum_required): Compatibility with CMake < 3.5 has been removed from CMake. Update the VERSION argument <min> value. Or, use the <min>...<max> syntax to tell CMake that the project requires at least <min> but has been updated to work with policies introduced by <max> or earlier. Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway. -- Configuring incomplete, errors occurred! </code>
fuck you ***so very much***, CMake, and fuck everyone who still uses you

2026-07-05 04:41:06 UTC

<code>unknown font: verdana </code>oh ffs. ok...<code>$ find /mnt/omni -iname verdana.ttf ./fontback/msttcore/verdana.ttf $ sudo cp -R /mnt/omni/fontback /usr/share/fonts $ fc-list verdana /usr/share/fonts/fontback/msttcore/verdana.ttf: Verdana:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta […] $ ./Self -s kitchensink.snap […] unknown font: verdana $ linux go home, you're drunk _ </code>

2026-07-03 01:08:24 UTC

i do so love the fact that it's perfectly normal to compile a program with Xft enabled, then start it by specifying program -fn FONT, then have it immediately fail with a "can't set font" message.
it is 2026 and this is **bullshit**.

2026-06-29 22:06:54 UTC

- reply

now that brings back some memories...
https://www.youtube.com/watch?v=557Npb85Emo

2026-06-28 16:11:02 UTC

re LB: so basically any commercial VPN you might choose has an even chance of being a Trojan horse for domestic or foreign intelligence... and if it isn't - or even if it is - then it's either already a washing powder brand, or soon will be one when they realise they can't make money at it and sell up.

2026-06-28 00:21:58 UTC

thinking about it, the worst aspect of this is that that CEO must have started Mullvad *with the specific intention* of using the profits he made from it to fund something expressly counter to its stated goals. Mullvad has basically been one big Trojan horse for *its entire existence*.
that takes cynicism to another level.

2026-06-17 18:17:23 UTC

well... that's that for RISC OS Pi then.
the ancient copy of RISC OS i've been using with my Pi 1 is creaky, and for some reason stuck with a 16-bit GPU framebuffer, but it works perfectly with my Barco E-3620 and the custom monitor definition i made for it. (from some of the strangeness, i assume there was some display scaling going on.)
but i just tried the latest RISC OS, v5,30 - and i dropped the same MDF onto the display manager... but - nothing. i can only select 640x480. RISC OS seems to have completely lost the ability to do custom modes. i mean, i do at least actually get 256 greys in greyscale modes, rather than just 32 - but... if i can't have them at 1536x2048, it rather defeats the purpose.
anyone who knows RISC OS and can suggest a solution, please let me know!

2026-06-01 18:39:12 UTC

quick question: do TVs that recognise PAL and NTSC automatically also recognise hybrids like PAL-M and PAL-60?

2026-05-27 12:06:04 UTC

yes, by all means, if you want to underline the point i was making about OpenBSD contributors being a *special* kind of asshat, just send me a link to the FAQ with no comment, and when i ask why, reply only "RTFAQ". you will *definitely* encourage me to switch to your favourite operating system with that attitude.
🤦‍♀️
**plonk** ( ( ( ☎️ ) ) )
is it possible that i've uncovered the only OS fandom objectively worse than the hordes of reply guys and 'splainers that constitute Linux's...?

2026-05-25 01:06:43 UTC

- reply

sidenote: whoever decided to call it Wayland instead of Y needs to re-evaluate their life choices... but then i'm still firmly of the opinion that the successor to C should have been called P

2026-05-25 01:05:48 UTC

all this talk of Tripos is reminding me of another OS that relied on a microkernel and superoptimised message passing and really needs to be updated for modern systems.
no, not QNX, if you wnt there. its grandfather, Thoth... whose offspring included the system on which the predecessor of the X windowing system was developed.

2026-05-12 18:34:03 UTC

oh for FUCK'S SAKE
https://codeberg.org/small-hack/open-slopware
https://assets.oldbytes.space/assets.oldbytes.space/media_attachments/files/116/563/032/636/683/818/original/cb69c96bbde83ceb.png

2026-05-04 16:01:08 UTC

the eZ80 is much less wtf-y than the 65816 in many ways (so few transistors, so many bad decisions!), but whoever decided that it was OK to have the only practical way to access the high byte of a 24-bit address be storing it into memory and loading from n+2 should have to subtitle their CV "i have no design taste"...
i mean, at least<code> ld (temp),hl ld a,(temp+2) or push hl ld hl,2 add hl,sp ld a,(hl) or ld (ix-1),hl ld a,(ix+1) </code>
only take 12, 11 or 10 cycles respectively; but still...

2026-05-02 02:12:24 UTC

in general, "someone else will do that icky stuff for you" is not a sustainable programming practice.

2026-05-02 02:05:03 UTC

- reply

Raymond Chen was writing about Windows, not generally. it's not hard to imagine a system which expects memory to persist between processes - or one in which that expectation is made use of.

2026-05-02 01:26:50 UTC

what a bunch of arseholes
https://serverfault.com/questions/110219/which-os-distributions-have-64-bit-kernel-and-32-bit-userspace
it's a perfectly reasonable question, yet look at *literally every single one of them* refusing to answer it.
that's linux "helpfulness", in a nutshell

2026-05-02 00:39:55 UTC

- reply

hang on... so you're seriously telling me that the option on which everyone seems to have settled is that malloc() always *pretends* to work, but that the *entire system* might grind to a halt at some future point as the operating system struggles so hard to release free pages to satisfy that promise that it eventually thrashes all code executed anywhere in the system through a single page...?
are you kidding?
are they high?!

2026-05-02 00:36:27 UTC

- reply

no doubt such folk would prefer a system in which malloc() blocks on failure (because obviously a shortage of memory is a temporary problem) rather than returning null... wait. what do you mean, they don't like that option either?!

2026-05-02 00:33:06 UTC

- reply

certainly, being forced to code for such systems would put the all-the-world's-a-POSIX folk who insist that you don't have to check malloc()'s result because what can you do if it failed? in something of a tight spot...

2026-05-02 00:30:13 UTC

i wonder how much modern software ultimately relies on the fact that modern operating systems will reclaim all their resources?
because i read recently about a comparatively widely used system (was is Tripos?) where that wasn't true - programs were expected to return all their resources to the OS before quitting, because the OS wouldn't do it for them

2026-04-27 13:29:15 UTC

one thing i still want to see is a tiny rust compiler, akin to tcc. something that can do all the checking and compile all the code, but inthe most direct way possible, rather than going all in on optimisation.
perhaps we could call it trust?

2026-04-24 19:18:59 UTC

every so often i wonder what happened to machine-oriented high level languages - things like PL/360, PL/516, or Action!
and then i remember. C happened. an entire class of languages, killed at a stroke! (though oddly enough, BCPL didn't have nearly the same apocalyptic effect on MOHLLs for word-addressed machines that C did for those on byte-addressed machines)

2026-04-18 23:04:07 UTC

more and more, i want to hear about software that FOSS evangelists sneer at because its licence contains clauses like "no fascism" or "no warmongering"

2026-04-18 10:18:46 UTC

**sigh** i mean, i *get* why every new kernel released by anyone is POSIX compliant and can compile all their favourite programs. recreating the corpus of software everyone relies on these days, especially for internet connectivity, is a literally terrifying prospect. and of course computers are useless without internet connectivity, aren't they? ;-)
but it's killed the field of OS research - especially hobby OS research - stone dead. nobody's doing anything that departs from the "kernel in C implementing POSIX" model, even though *literally every other seam* is all but untapped.
froggey's Mezzano is an honourable exception, and one i really need to install on a respectable machine - it's just, i also need to learn Common Lisp and emacs, and that's a *lot*, all at once! but if it can work well on one of the (um, ten) Wyse 3040s i ended up with, then i might well have a permanent little ersatz Lisp machine in the corner

2026-04-18 10:07:54 UTC

so has anyone made a linux distro built on mlibc yet? if so: which one? comments, opinions, etc?

2026-04-16 23:01:59 UTC

never mind "free, open source first, community-owned" - point me at a git hosting service that bans AI contributions to any of its repos outright

2026-04-15 16:10:44 UTC

the *exp(x)-ln(y)* finding is a fun result, but it doesn't appear to be of the same order of practicality as "you can build everything out of NAND gates". partly because exp and ln are complicated functions to calculate in themselves, especially when y is negative! so they don't really simplify anything in the way being able to fab an entire chip of gates the same way does - which is itself sort of accidental; as i understand it in NMOS fabrications an inverter can be expanded into an n-input NAND gate (and in PMOS a NOR gate) by just adding n-1 extra bases to the input transistor - essentially making a compound serial sequence of transistors. (the other kind of gate is made by parallelising the input transistors)
fun fact (also TIL): in CMOS a NAND gate is made by stacking the input transistors of a PMOS NAND gate on top of those of an NMOS NAND gate! same for NOR gates. the effect of which is that you don't need the output amplifier that NMOS and PMOS gates do, which means the whole arrangement only consumes power while transistors are switching; the design benefit is that you can choose whichever gate is most advantageous, rather than preferring NAND or NOR in NMOS and PMOS respectively, because they take the same surface area

2026-04-14 11:34:17 UTC

i knew NetBSD had declared LLM-regurgitated code verboten. i didn't know that edict was passed nearly two years ago - does this mean that NetBSD has dodged the worst of it?

2026-04-01 03:15:15 UTC

- reply

according to https://en.wikipedia.org/wiki/List_of_POSIX_commands they all originate with AT&T - sort from v1, join from v7, paste from 32V and cut from System III
(but if you go to the cut and paste WP entries, it turns out they were originally BSD additions)

2026-04-01 00:59:03 UTC

and *why*, exactly, do cut and sort have different options for selecting fields...?

2026-03-30 18:53:04 UTC

tell me how whimsical claude can be, get muted

2026-03-27 07:28:50 UTC

- reply

how bad do you have to be at business to fail to make money selling porn?!

2026-03-24 19:21:05 UTC

re LB: like i said a few days ago, "i don't do cults" has become the single most apposite answer to anyone asking why you didn't wrote your project in Rust
the assumption embedded in this bit, in particular, annoys this piss out of me:
> it has gotten to a point where people have told me that i should… stop because “you are making the world worse by writing insecure code”
C code is *not* automatically insecure! in fact, anyone assuming that Rust is automagically preventing them from writing insecure code should frankly step away from their keyboard, turn off their computer, and go and find a hobby they can cut themselves on. then they might learn a thing or two about the complex interrelationship between tools and personal responsibility.
i can see why that accusation *would* wreck an autistic person. it's one of those "you aren't even making it to the level of being wrong" category errors. it's impossible to sensibly argue against, because it's nonsense! but how on earth does one effectively counter nonsense...?

2026-03-12 08:21:16 UTC

i'm beginning to think that Smalltalk is literally the only language family that does booleans properly
https://lwn.net/Articles/1059177/
...ok, maybe Scheme and the Pascal family too, but none of them quite *run with it* like Smalltalk

2026-03-11 19:26:54 UTC

- reply

like, i just tried to install tooi, which has failed 3 times. the first time, because it needed cffi. the second time, because it needed aiohttp. an dd the third time, because it somehow objected to the system aiohttp i just installed and attempted (and failed) to roll its own.
i don't know how to resolve that error, so my attempt to build tooi is at an end, because *life is too damn short* to deal with the *absolute bullshit* of the people who think a fucking *scripting language* is a suitable medium for app distribution.

2026-03-11 19:23:59 UTC

if python is so "batteries included", why does building literally *anything* that uses it always involve dragging in 37 different packages, at least one of which is guaranteed not to exist / compile?

2026-03-10 22:49:19 UTC

"this meeting could have been an IRC session"

2026-03-09 16:23:43 UTC

remember back in the days of DOS, when it was just accepted that some folk would still be using DOS 3.30 because they didn't have any compelling need to upgrade? or back when the general consensus was that if you were using Win95 OSR2 or Win98SE, Windows ME was, at best, not worth the bother?

2026-03-07 22:36:38 UTC

- reply

could something like LZ4 or ZX0 compression strike a happier medium?
https://github.com/einar-saukas/ZX0
https://github.com/pararaum/lz4-6502

2026-03-07 20:42:28 UTC

"but i'm bad at coding". yes. so is everyone else. getting good at coding is the humbling process of realising how bad you are at it and figuring ways to get better. not by going "oh well a computer must be better than me at programming, i'll let it do it for me"

2026-03-07 20:40:11 UTC

damn. i hate it when someone is asking about a situation i have almost exactly faced, and which i am *almost* sure i remember how to deal with, but....not quite sure
like, i so want to be helpful but i even more don't want to be accidentally unhelpful... **bites tongue**

2026-03-06 08:46:09 UTC

the chardet situation demonstrates that LLMs are *literally* plagiarism machines. worse - they are plagiarism *launderers*. in no other reality would replacing all the code in chardet with a clean-room implementation and then claiming that this represents a "new version" be possible, let alone permissible - at the very least, it'd have to be called 'new-chardet' or something distinct. and then it'd have to fight for its place in the ecosystem as a better implementation of the old chardet.
instead, someone appears go have gone "gee, i wish i didn't have to obey the LGPL for this library" and gone looking for ways around it, whilst also stealing the valour of the existing code.
frankly the only acceptable response to this is for the Python maintainers to explicitly disallow any chardet greater than v6, *and* any future contributions from this maintainer. *pour encourager les autres.*

2026-03-05 16:11:05 UTC

funny thing. in contrast to the veritable *gush* of people who have suddenly adopted vibecoding and even though you'd think they'd know better they're basically all saying the same things about how great it is...
i can't help but think back to Chuck Moore's recent - and by his own description, miserable - experience of trying to get Microsoft's own LLM to figure out how to use the Microsoft API that stopped working the way colorForth expected it to.
one small, simple problem - and he couldn't cajole the LLM from the company that made it to help him solve it.
so i guess the lesson to derive is that LLMs are great if all you care about is spewing out code that passes the test suite. but actually *debugging* that code? not gonna happen. the LLMs can't do that.
*because stochastic parrots aren't capable of analysis*.

2026-03-04 02:39:10 UTC

"Oh my god, was I Claude’s nanny?!" Erin Cikanek's key realisation about having AI code for you...
https://erincikanek.com/the-rumors-of-my-demise-have-been-greatly-exaggerated/

2026-03-03 23:56:36 UTC

i'm just going to say this: i remember when Linux could cheerfully run a GUI and a web browser in 64MB RAM. for all people like to say "oh, but web browsers did less then", they had CSS, JavaScript and multimedia capabilities by the turn of the century (the timescale i'm talking about). they also had XSLT, Flash and Java, and they could read email and news, and connect to FTP servers (and i think gopher servers too). so much for "they do so much more now". no, they really don't - they just make a hell of a mountain out of a rather smaller molehill.

2026-03-01 14:03:48 UTC

> One of my main software goals was to be able to run the program “cool-retro-term” or CRT, which uses 3D shaders to simulate the look of a cathode ray tube with an LCD panel
um. not to yuck anyone's yum, and i do appreciate that CRTs are increasingly hard to find, and more importantly, that even running a Pi 5's VideoCore flat out and overclocked will come *nowhere near* the power consumption of a CRT...
but honestly, i don't get the appeal of emulating the worst visual aspects of CRTs - badly (remember, back then we all used to use inch-wide margins on our CRTs precisely *because* of the curvature at the edges!) - when LCDs are just *better*. in almost every respect - and the respects in which they aren't won't be solved by emulating a CRT with them

2026-02-25 11:32:54 UTC

on the subject of "operating systems created by only one person", anyone else remember AtheOS?
https://atheos.metaproject.frl/

2026-02-23 03:36:36 UTC

- reply

if nVIDIA charged money to up your frame rate, it'd be well into the three figures
i mean, i'm sure the technical capacity exists - i'm sure some of their lower speed stuff is artificially slowed down higher speed stuff, and it'd only take a line of firmware to unlock it - but chip manufacturers have learned that never *ever* releasing that line of firmware, under *any* circumstances, is what keeps the business of selling of speed grades alive

2026-02-21 20:33:34 UTC

- reply

they're in the GSoC '26

2026-02-21 20:31:53 UTC

um, congratulations to Haiku OS for winning the devil's deal contest, i guess

2026-02-11 05:33:27 UTC

what has really gone wrong with softwre, why bloat is running away with itself?
*nobody programs real hardware any more*.

2026-02-10 13:51:07 UTC

seriously, what is it about the words "but with *computers*!" that makes people stop recognising ancient scams?

2026-01-24 21:12:22 UTC

what if... home computers had come with something like the Canon Cat OS installed? where basically the interface to the machine is a text editor, but if you select a chunk of text and press the RUN key, it drops into its implementation language (probably Forth, maybe BASIC) and runs it? and games can be loaded by compiling source code into memory on the fly, or by loading the text file, compiling the source code and then immediately overwriting it with object code and game data?
the SwyftCard was this, and was apparently written in Forth, although the language it exposed was Applesoft BASIC (presumably because that meant it didn't need Forth headers). hmm...

2026-01-24 00:35:10 UTC

i think the falling out between me and Void Linux is *imminent*
i can't update google-fonts because i don't have 2GB free on my 8GB root directory, even though /usr/share/fonts is cross-mounted on a disk with 270GB free
there is theoretically a voidlinux installation on there already, so i decided to try using xbps-install to update that
but no. it demands i update xbps first. so i try to do that, but there is a script that fails because of an exec format error. because that is an x86_64 system, and i am trying to update it from an i686 system, and apparently Nobody Has Ever Done That™.
of course, it would be a whole lot easier if google-fonts were split into its component packages, like qemu has been. but no. i don't know whether licensing prohibits or what, but if i want all the latest google fonts on your system (don't judge me), i have to somehow free up 25% of my root drive.

2026-01-23 14:50:44 UTC

- reply

as with everything, what "the Left" (whatever tf that is) *does* hate is narrow-minded prescriptivism

2026-01-13 21:08:58 UTC

oh no, has OSNews stomped tech.lgbt off the web?

2026-01-11 01:08:25 UTC

i think the biggest problem i have with GNOME is its tendency to insist that the new shiny thing is The Only Possible Way To Do Things Now, with the singular focus of a toddler on a sugar high chasing a shiny ballloon

2026-01-10 15:11:37 UTC

kind of puzzled as to why more people don't use the RISC OS outline font format, given that it's a format designed to be used on integer-only processors with single-digit MIPS speeds and memory measured in kilobytes, for which the specifications have been available for decades...
at the very least, a portable reimplementation could have been interesting

2025-12-27 01:05:35 UTC

- reply

domestic electricity costs about 3 times as much as that in the UK

2025-12-25 03:13:15 UTC

i must confess, i find the stance that the Linux kernel is all about sharing the code back to upstream, and not remotely about ensuring that people can hack on the devices that they *own, having paid good money for*, somewhere between self-absorbed (it helps the Linux kernel to be adopted more widely, but does nothing at all to help people take meaningful ownership of their devices) and just plain pointless (the only thing you can actually *do* with the source code as supplied by a company that locks down its device's kernel is look for backdoors - you can't fix anything, which was the whole reason the GPL was created in the first place)

2025-12-22 23:35:58 UTC

what if we started with the premise that sharing memory between cores was the root of all of our security issues, and simply... stopped doing that?

2025-12-22 22:02:56 UTC

one thing i really miss: the days when someone said "oh, i've got a $TYPE_OF_COMPUTER" and everyone knew exactly what the specification of that machine was and exactly what software it could or couldn't run
now? we're not *quite* in the realm of "no two computers have exactly the same specification", but we're a hell of a lot closer than we were. and yet every computer, no matter how dissimilar to anything else, is expected to run all the [same] software.

2025-12-20 16:27:33 UTC

- reply

exactly. tbh i mind emulators that run on microcontrollers - even ones as powerful as the RP2350 or ESP32 - a whole lot less than i object to someone who just chucked a Cortex A series SoC running VICE on Ubuntu into a funky box and went "eh, job done"

2025-12-20 16:24:19 UTC

programming a PIC24 is enough like retrocomputing anyway that anyone using one for anything interesting automatically gets a free pass

2025-12-18 01:49:57 UTC

- reply

you've conflated "genuinely useful" and "useful to people other than the creator"

2025-12-04 18:51:06 UTC

https://hackaday.com/2025/12/04/uefi-on-arm-more-likely-than-you-think/
oh dear gods no

2025-12-03 21:24:11 UTC

the thought of going all the way back to DOS is alarmingly attractive right now tbh

2025-12-03 21:03:07 UTC

- reply

the TMS9900 also used a 4-non-overlapping-phase clock, so you're in decent company

2025-11-24 07:25:36 UTC

- reply

re LB:
Plan 9: no, really, *everything* is a file
Oberon System: everything is an object
Bare-metal Smalltalk: no, really, *everything* is an object
polyForth: everything is a disk. "file"?
colorForth: everything is a memory location. "disk"?

2025-11-13 16:51:51 UTC

pro tip: do not put your multimeter back on the shelf without turning it off - unless you have plenty of spare PP3 batteries

2025-11-04 18:17:13 UTC

i confess, i still think that in terms of form factor, computers peaked with the TRS-80 model 4
https://en.wikipedia.org/wiki/TRS-80_Model_4

2025-11-01 01:15:38 UTC

- reply

the worst bit of this? if you're coding for an 8086, you will already be aware of the bug that means that if a es: rep movsb is interrupted, the 8086 forgets about the es: override because it can only remember one prefix at a time across an interrupt. so you carefully code this:<code> push ds push es pop ds rep movsb pop ds </code>
and then wonder why you're now copying from ds *unless* the rep movsb gets interrupted, at which point it starts from es again
i think it's at this point that the enlightened IBM PC coder would have gone "fuck this, i'm going back to CP/M"

2025-10-31 16:42:55 UTC

i just switched back from my red-switch mechanical keyboard to a membrane keyboard with round keycaps. and my gods, it's like typing into blancmange! how did i ever manage with this before?!

2025-10-31 15:00:09 UTC

oh cool, in all the stuff the ACM have made free to download are all the SIGFORTH articles.
including one from Charles Curley which details a nasty little bug in the x86. say you need to copy something that's currently sitting in the ES segment into a segment inside a variable pointer. mindful of the fact that all your registers are in use, you write<code> push es mov es, [segment] pop ds rep movsb </code>
(assuming CX, SI and DI are already populated).
and... then you notice that instead of the data you expect, a random chunk of data has been copied from DS:SI to ES:DI, rather from ES:SI to userseg:DI
this is because (a) every segment register update inhibits interrupts until after the following instruction; and (b) the segment registers, at least on the 80186 on which Curley tried it, are not reloaded until interrupts are re-enabled. thus, when the REP is executed (which also inhibits interrupts) and applied to the following MOVSB, ES and DS still have their original values... disastrously!
(even more fun, of course, is the fact that REP MOVSB can be interrupted... but ES and DS are not updated until either an interrupt or the end of MOVSB, which suggests they're copied into buffers - which means that on return from any interrupt, REP MOVSB will recommence *with the correct ES and DS values*. just to *really* fuck everything up)
a single NOP, after the DS, fixes it; or if any useful instruction can be found to fill the gap, that also works. but... yeah. that must have been not very much fun to debug!

2025-10-26 23:32:08 UTC

definitely onboard with a middle ground between Linus Akesson's "don't use syntax highlighting at all" and the prevailing "a kitten puked into your text editor" approach

2025-10-26 20:54:36 UTC

the eZ80's decision to make the upper byte of its address registers inaccessible except by saving them to a temporary and reloading them from there is just incomprehensible
at the very least, LD A,xxU and LD xxU,A could have been provided. they only needed 10 opcodes for that, and there's more than enough space left on the ED page. if they were feeling really generous, they could have provided xxU as well - that's only another 11 (including TST xxU). then at least it would actually look like someone gave enough of a shit about the design to do it properly...

2025-10-19 02:38:50 UTC

when you actually look into the Atom core (thanks to Agner Fog for doing that and providing excellent write-ups), it has some really nifty features, and if you were to write code targeted specifically for it, there's good reason to think it'd be surprisingly fast
there are some problematic aspects - only 8 bytes of instruction decoded per clock cycle, in-order execution so you have to watch pairing (but at the same time, it's also deterministic), x87 instructions *have* to be interleaved with non-x87 instructions to run at full speed, 64-bit SSE instructions using the high registers end up copping a 4-cycle penalty for using more than 3 prefixes because it counts escape bytes as prefixes(!) - but if you're writing assembly code specifically targeted at the Atom, which you might as well because it's an in-order processor and that makes *everything* simpler, you can work around that

2025-10-19 02:16:01 UTC

for normal code, is there any good reason to not run an FPU with flush-to-zero and denormals-are-zero set by default? if so, what are the exceptions?

2025-10-17 17:37:54 UTC

- reply

how is that not just preying on people's ignorance, though? if you're in a preferential voting system, "X can't win here" is ALL THE MORE reason to cast a first-preference vote for X...

2025-10-17 17:22:33 UTC

- reply

i'd argue that first past the post voting systems are a much bigger blight on democracy than tactical voting. if i could specify a list of preferences, i wouldn't need to care about tacitcal voting at all.

2025-10-12 01:44:48 UTC

- reply

alternatively, and for quite a lot less money, you could just keep the Casio as is, buy a headphone splitter cable (3.5mm stereo to 2x6.3mm mono) and two multi-effects pedals, at least one of which has an aux input; connect the output from the keyboard to both pedals, the output from one to the aux input of the other, and ta-da!
little known fact: since the whole point of effects is to get a huge range of sounds out of an instrument that really only has a couple of them, using it on just about any home keyboard - even the most tablehooty¹ - works a kind of magic.
¹ http://www.weltenschule.de/TableHooters/instruments.html

2025-10-12 01:37:40 UTC

turn a $5 toy into a serious-looking instrument with integrated effects! all you need is a decent thrift store, $200 of guitar effects, and a garage-sized workshop kitted out with >$13,000 worth of fab equipment...
https://hackaday.com/2025/10/11/a-casio-toy-synth-is-ready-to-rock/

2025-10-09 15:04:59 UTC

- reply

the problem is all of those addressing modes. a pipeline would have to split up their calculation into separate stages, most of which would be unused for most instructions. these days there's no problem with wasting silicon like that, i guess, but back in the day every spe- uh, gate was sacred

2025-10-09 14:59:53 UTC

the era of single-cycle instruction sets has spoiled me; i can't help but view 8-bit and early 16-bit processors as *intolerably* slow

2025-10-08 17:48:57 UTC

maybe we should just all agree that from now on ChatGPT's name should be Little Kitty Brainworm

2025-10-08 17:48:01 UTC

> > As a hobbyist, the five volt TTL standard always seemed a little capricious, but I strongly suspected there had to be a solid reason behind it. To get some insights into the engineering rationale, I did what anyone living in the future would do: I asked ChatGPT.
really? fucking ***really***?!
> And while overall the answers were plausible, like every other time I use the chatbot, they left me wanting more.
weird. it's like some force in the universe is telling you to stop fucking doing that and go and learn how to actually use a search engine. one no-AI ducking got me closer to an answer than ChatGPT appears to have got Dan Maloney.

2025-09-11 21:02:37 UTC

- reply

² the modern Forth community seems to have a real problem with reinventing the wheel, rather than reusing perfectly good wheels. rather than generalise CREATE into a word which is given a string and creates a word with that name, or DOES> into a word which takes two execution tokens and sets the runtime action of one to be the other, they went back to the drawing board and tried to work out how to impose closures on a language which doesn't traditionally even *have* local variables to close over!
my brethren in Chuck, i say this with love: if you want to write Lisp code, use Lisp. if you want to write Lisp code in Forth, use Factor - that's what it's there for. do not try to retrofit the entirety of Lisp into Forth - and *especially* don't try to do that with the bits of Lisp that rely inherently on garbage collection, lexical scope and spaghetti stacks...