↳
In-reply-to
»
@movq How about "Quongsi"? I generated the first five letters with
⤋ Read More
pwgen --no-capitalize --no-numerals 5 and since that already showed up in DDG search results, I simply appended the last two, which yielded nothing on DDG and Google).
Dang it, there’s a Swede by the username of Quongsi: https://www.flashback.org/u1404408 :-D
↳
In-reply-to
»
Whoo! I fixed one of the hardest bugs in mu (µ) I think I've had to figure out. Took me several days in fact to figure it out. The basic problem was,
⤋ Read More
println(1, 2) was bring printed as 1 2 in the bytecode VM and 1 nil when natively compiled to machine code on macOS. In the end it turned out the machine code being generated / emitted meant that the list pointers for the rest... of the variadic arguments was being slot into a register that was being clobbered by the mu_retain and mu_release calls and effectively getting freed up on first use by the RC (reference counting) garbage collector 🤦♂️
@prologic@twtxt.net Tada, congratulations! I find that rather interesting, thanks for telling us. :-)
↳
In-reply-to
»
Trying to come up with a name for a new project and every name is already taken. 🤣 The internet is full!
⤋ Read More
@movq@www.uninformativ.de How about “Quongsi”? I generated the first five letters with pwgen --no-capitalize --no-numerals 5 and since that already showed up in DDG search results, I simply appended the last two, which yielded nothing on DDG and Google).
What kind of project is it? Maybe we can help you find a name or nudge you in the right direction.
↳
In-reply-to
»
@zvava The problem you now then is you lose integrity of the message content if you compute the hashes at runtime rather than on the way in. So if your message content or database becomes corrupt in any way, so do your hashes.
⤋ Read More
@lyse@lyse.isobeef.org True !
↳
In-reply-to
»
@zvava The problem you now then is you lose integrity of the message content if you compute the hashes at runtime rather than on the way in. So if your message content or database becomes corrupt in any way, so do your hashes.
⤋ Read More
@prologic@twtxt.net In my opinion, the integrity isn’t lost. The same input data always result in the same output hash, no matter when you calculate the hashes. It’s true that a corrupt database contents yields to corrupt hashes, but then you have a whole bigger problem than just receiving different hashes. :-D
↳
In-reply-to
»
@lyse while caching those is a good idea the problem is baking data that can be calculated into the database instead of some cache, because post hashes are not fixed and change for every post edit. you can always easily look up other twts by hash with a cached lookup table, but now you're not locked into them so supporting hashv2 or other hash variants or any other solution becomes far easier
⤋ Read More
@zvava@twtxt.net By hashing definition, if you edit your message, it simply becomes a new message. It’s just not the same message anymore. At least from a technical point of view. As a human, personally I disagree, but that’s what I’m stuck with. There’s no reliable way to detect and “correct” for that.
Storing the hash in your database doesn’t prevent you from switching to another hashing implementation later on. As of now, message creation timestamps earlier than some magical point in time use twt hash v1, messages on or after that magical timestamp use twt hash v2. So, a message either has a v1 or a v2 hash, but not both. At least one of them is never meaningful.
Once you “upgrade” your database schema, you can check for stored messages from the future which should have been hashed using v2, but were actually v1-hashed and simply fix them.
If there will ever be another addressing scheme, you could reuse the existing hash column if it supersedes the v1/v2 hashes. Otherwise, a new column might be useful, or perhaps no column at all (looking at location-based addressing or how it was called). The old v1/v2 hashes are still needed for all past conversation trees.
In my opinion, always recalculating the hashes is a big waste of time and energy. But if it serves you well, then go for it.
↳
In-reply-to
»
very good blog post that reminded me why it's taking so long to ship bbycll — previously i had computed the hashes of every post before storing them in the database, after realizing it's a much better idea to compute the hashes during runtime and only store the post content & timestamp i'm now having to rewrite every function that reads & writes data. i hope the reason as to why i lost motivation is obvious — thankfully i caught it early enough so that once i'm done rewriting just those functions i should™ be able to finalize 1.0-rc with little hassle
⤋ Read More
@zvava@twtxt.net The problem you now then is you lose integrity of the message content if you compute the hashes at runtime rather than on the way in. So if your message content or database becomes corrupt in any way, so do your hashes.
↳
In-reply-to
»
very good blog post that reminded me why it's taking so long to ship bbycll — previously i had computed the hashes of every post before storing them in the database, after realizing it's a much better idea to compute the hashes during runtime and only store the post content & timestamp i'm now having to rewrite every function that reads & writes data. i hope the reason as to why i lost motivation is obvious — thankfully i caught it early enough so that once i'm done rewriting just those functions i should™ be able to finalize 1.0-rc with little hassle
⤋ Read More
@lyse@lyse.isobeef.org while caching those is a good idea the problem is baking data that can be calculated into the database instead of some cache, because post hashes are not fixed and change for every post edit. you can always easily look up other twts by hash with a cached lookup table, but now you’re not locked into them so supporting hashv2 or other hash variants or any other solution becomes far easier
@shinyoukai@neko.laidback.moe The CSS 404ing highlights the improvability of the content to noise ratio. :-)
↳
In-reply-to
»
@lyse … I was about to write “it really is worse where you live”, then I heard the first bang out on the street. 🤣
⤋ Read More
@movq@www.uninformativ.de The asshats are everywhere. Luckily, it has been rather quiet so far. But of course, I now jinxed it.
@shinyoukai@neko.laidback.moe Very cool! 😎
@shinyoukai@neko.laidback.moe Nice! 👍
↳
In-reply-to
»
Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It's insane really, it's a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔
⤋ Read More
@movq@www.uninformativ.de Thanks! 🙏
↳
In-reply-to
»
Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It's insane really, it's a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔
⤋ Read More
@prologic@twtxt.net This is a really cool project, that’s for sure. 👌
↳
In-reply-to
»
It's this time of the year again, where people burn money on the streets.
⤋ Read More
@lyse@lyse.isobeef.org … I was about to write “it really is worse where you live”, then I heard the first bang out on the street. 🤣
↳
In-reply-to
»
Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It's insane really, it's a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔
⤋ Read More
@shinyoukai@neko.laidback.moe Nah it’s more like there’s a lot of repeated code, because when you go from source language to intermediate representation to machine code, well you just end up writing a lot of the same patterns over and over again. I need to dedupe this I think.
@kiwu@twtxt.net Ooof 😢 That’s rough!
↳
In-reply-to
»
Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It's insane really, it's a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔
⤋ Read More
@movq@www.uninformativ.de I’ve managed to bring a simple “Hello World!” in mu (µ) (at least on macOS / Darwin / ARM64) down to ~86KB (previously ~146KB) 🥳
↳
In-reply-to
»
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
⤋ Read More
@movq@www.uninformativ.de I think I can get binaries even smaller with a bit more work and effort 🤔 But yeah still working on the native code generation (at least for macOS targets)
↳
In-reply-to
»
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
⤋ Read More
@prologic@twtxt.net Oh! 🤔
↳
In-reply-to
»
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
⤋ Read More
@movq@www.uninformativ.de Oh that’s fine, Mu can compile to native code and so far binaries. at least on macOS are in the order of Kb in size 😂
↳
In-reply-to
»
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
⤋ Read More
@prologic@twtxt.net That might be a challenge, at least in 16-bit Real Mode: The OS follows the model of COM files on DOS, i.e. the size of the binary cannot exceed 64 KiB and heap+stack of the running program will have to fit into that same 64 KiB. 😅 (The memory layout is very rigid, each process gets such a 64 KiB slice.)
And in 64-bit Long Mode, there is no “kernel” yet. The thing in the video is literally just a small bare-metal program.
But some day, maybe. 😃
↳
In-reply-to
»
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
⤋ Read More
@movq@www.uninformativ.de It’d be cool if you could get µ (Mu) running in your little toyOS 🤣 You’d technically only have to swap out the syscall() builtin for whatever your toy OS supports 🤔
Almost all photos turned out to be blurred today. That made sorting a very quick process. Delete, delete, delete, … https://lyse.isobeef.org/waldspaziergang-2025-12-26/
↳
In-reply-to
»
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
⤋ Read More
Seeing this run on real hardware is so satisfying, even if it’s just a small example. 😅
My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).
Here I’m running a little C program (compiled using normal GCC, no Watcom trickery):
https://movq.de/v/b27ced6dcb/los86%2D64.mp4
https://movq.de/v/b27ced6dcb/c.png
Next steps could include:
- Use Rust instead of C for that 64-bit program?
- Provide interrupt service routines. (At the moment, it just keeps interrupts disabled.)
↳
In-reply-to
»
This one is a slightly more 3D looking, as well as the first one, with the tail swirled.
Media
⤋ Read More
@thecanine@twtxt.net I see 🤔 Very cool though! 😎
↳
In-reply-to
»
This one is a slightly more 3D looking, as well as the first one, with the tail swirled.
Media
⤋ Read More
@prologic@twtxt.net Not even entirely sure how I did it myself, but likely a lucky combination of the new tail swirl, the legs closer to the screen being bigger and the head looking slightly to the side (eye & ear position), with bottom part of the hair, going behind the snout. The white is just an outline, around most of my works, so I don’t think that plays a part.
↳
In-reply-to
»
In case you haven’t seen it yet:
⤋ Read More
@movq@www.uninformativ.de @prologic@twtxt.net Holy shit, this is sooo fucking cool! :-) Wow, I absolutely love it. It’s extremely fascinating what these optimizers do.
↳
In-reply-to
»
This one is a slightly more 3D looking, as well as the first one, with the tail swirled.
Media
⤋ Read More
Woof, woof, @thecanine@twtxt.net! That’s cute.
↳
In-reply-to
»
In case you haven’t seen it yet:
⤋ Read More
@movq@www.uninformativ.de I have not, thanks! <3
↳
In-reply-to
»
that's a whopping 36°C today 🥵
⤋ Read More
@prologic@twtxt.net @movq@www.uninformativ.de Oh, I take my 0°C over the 36°C anytime! Even with yesterday’s gray and windy sleet in my face. However, there are definitely more pleasant times to walk in town, I’ll give you that. For example on 0°C sunny today: https://lyse.isobeef.org/waldspaziergang-2025-12-25/
↳
In-reply-to
»
In case you haven’t seen it yet:
⤋ Read More
@movq@www.uninformativ.de I watched a few of these thanks to you! Very cool shit™ 😎
In case you haven’t seen it yet:
Matt Godbolt’s “Advent of Compiler Optimisations”!
https://www.youtube.com/playlist?list=PL2HVqYf7If8cY4wLk7JUQ2f0JXY_xMQm2
↳
In-reply-to
»
that's a whopping 36°C today 🥵
⤋ Read More
@movq@www.uninformativ.de Ooof that’s chilly 🥶
↳
In-reply-to
»
that's a whopping 36°C today 🥵
⤋ Read More
@prologic@twtxt.net And I froze my ass off yesterday at -5°C and strong winds. 🤣
@dce@hashnix.club merry Christmas to you too!
↳
In-reply-to
»
This one is a slightly more 3D looking, as well as the first one, with the tail swirled.
Media
⤋ Read More
@thecanine@twtxt.net Is it because you’ve used white pixels around it to sort of give it aht 3D look? 👀 Hmm? 🤔
↳
In-reply-to
»
@prologic merry Christmas! I keep forgetting you live in our future. 😅
⤋ Read More
@bender@twtxt.net It’s fun living in the future isn’t it 🤣
↳
In-reply-to
»
👋 Merry Xmas 🎄 🎅
⤋ Read More
@prologic@twtxt.net merry Christmas! I keep forgetting you live in our future. 😅
This one is a slightly more 3D looking, as well as the first one, with the tail swirled.
↳
In-reply-to
»
@lyse Lovely! We also just had some snow. 😃 Not a lot, but still. 😅
⤋ Read More
@movq@www.uninformativ.de Hahaha, this is hilarious! :‘-D
↳
In-reply-to
»
👋 Merry (2025) Xmas y'all 🎄 Ho ho ho! 🎅
⤋ Read More
@prologic@twtxt.net 🎄 Merry Christmas and stuff 😅🎅
↳
In-reply-to
»
Oh wow, there might be snow tomorrow! Probably not much, though. Let's see.
⤋ Read More
@lyse@lyse.isobeef.org Lovely! We also just had some snow. 😃 Not a lot, but still. 😅
(Lol, I totally read that as “rootfs”. 🤪)
↳
In-reply-to
»
Oh wow, there might be snow tomorrow! Probably not much, though. Let's see.
⤋ Read More
@movq@www.uninformativ.de Only the roofs are a little white. It’s also windy here. https://lyse.isobeef.org/weisse-weihnachten-2025-12-24/01.jpg
↳
In-reply-to
»
Oh wow, there might be snow tomorrow! Probably not much, though. Let's see.
⤋ Read More
@lyse@lyse.isobeef.org Oooh, nice! ⛄ We only have cold stormy weather over here. 🥴
↳
In-reply-to
»
@lyse Thanks. 😅 (Do I say that? The WM can’t answer. 🤣)
⤋ Read More
Oh, that’s cute: https://movq.de/v/046fb6ee70/s.png DuckDuckGo puts a little helmet on the duck when you search for Skyrim. (Katria is a Skyrim character.)
↳
In-reply-to
»
Happy birthday Katrina! https://www.uninformativ.de/blog/postings/2025-12-23/0/POSTING-en.html :-)
⤋ Read More
@lyse@lyse.isobeef.org Thanks. 😅 (Do I say that? The WM can’t answer. 🤣)
↳
In-reply-to
»
very good blog post that reminded me why it's taking so long to ship bbycll — previously i had computed the hashes of every post before storing them in the database, after realizing it's a much better idea to compute the hashes during runtime and only store the post content & timestamp i'm now having to rewrite every function that reads & writes data. i hope the reason as to why i lost motivation is obvious — thankfully i caught it early enough so that once i'm done rewriting just those functions i should™ be able to finalize 1.0-rc with little hassle
⤋ Read More
@zvava@twtxt.net I might misunderstand what you wrote, but only hashing the message once and storing the hash together with the message in the database seems a way better approch to me. It’s fixed and doesn’t change, so there’s no need to recompute it during runtime over and over and over again. You just have it. And can easily look up other messages by hash.