14 Followers
137 Following
271 Posts
Husband, Father, Software Developer, with interests in #scifi and #fantasy, #videogames, Off-roading in my #jeep, #electronics, #3dprinting, #CAD, #CNC, #linux, and #archery, among other things.

@tankgrrl I use a Asus zephyrus M16 from 2022 sitting on a laptop stand with a 120mm noctua fan behind it to keep the internal fans from going so much. Those noctua fans are nice.

Doesn't help for when I'm not at the desk, but I'm doing something similar where the laptop drives the nice monitors and can occasionally go places with me too.

@mos_8502 Also, when openclaw was first released, I set it up on a "spare" mini-pc that I eventually plan to use for a CNC mill, but haven't created the brackets to mount it yet so it's been sitting idle on my desk.

I set it up with no access to anything, and let it use an LLM running on ollama on my laptop. I can only run smaller models there, so the "assistant" was kind of dumb and got things wrong more often than one of the big models might.

It was an interesting experiment, in that I learned a lot more about running local models, what the different quantization choices do, and setting up a telegram bot so that I could communicate to it from my phone.

I tried to get it to set reminders for me, so it could ping me on telegram when something needed to me done, but the weak LLM it was using kept messing that up. Again, I suspect it could be a lot more useful with a stronger LLM, but I wasn't willing to put money into running it, or willing to trust it with credentials for anything real.

@mos_8502 When I was setting up to see what the 6502 compiler output looked like, I created a simple factorial function, and set up compiler toolchains for llvm-mos and calypsi. After comparing the generated assembly for both, I wanted something larger to work with, so I used claude with this prompt:

create a c program for the commodore 64 that bounces a sprite around the screen.

It initially generated code that used cc65 and included the c64.h file, but when it updated the Makefile, it "realized" I was using llvm-mos, so it removed the header and defined macros for all of the registers it accessed.

The code was decent, it was a single main function, kind of long, but not horrible. The sprite data it generated was a little more diamond-ish than I wanted, but when I compiled it and ran it in vice it worked.

One thing I did change in the code was that it had repeated the code to cycle the color of the sprite when it bounced, I moved that to a new function instead.

When lawmakers and advocacy groups frame queer existence itself as a threat to young people, age-verification laws become ideological enforcement instead of regulatory policy. https://www.eff.org/deeplinks/2026/03/rep-finke-was-right-age-gating-isnt-about-kids-its-about-control
Rep. Finke Was Right: Age-Gating Isn’t About Kids, It’s About Control

What’s at stake is whether “protecting children” becomes a legal pretext for embedding government control over the internet to enforce specific moral and religious judgments—judgments that deny marginalized people access to speech, community, history, and truth—into law.

Electronic Frontier Foundation
@mos_8502 Have you considered writing code to generate the map at runtime? Something like wave function collapse would work nicely, and you can “seed” the map with points of interest for a story if you want.

I spent a few hours getting a compiler toolchain set up for building #c64
programs. I tried #calypsi and #llvm, and so far llvm-mos generates much more compact code. I also tried using the rustc, compiling to llvm intermediate, then compiling that to 6502. The resulting binary didn’t quite work, so I’m going to build a custom rustc and try that. The code it generated was highly optimized. Using the same backend, #rust generated larger code than C, but it was aggressively optimized for speed instead of size.

For example, when copying sprite data from a const array it generated a lot of STA ops using the same values stored in registers, since the data was highly repetitive. The same code in C copied a const array using a loop. If I had to guess, the Rust code was much faster, and might be a couple bytes longer. For the entire program, the same code written in C was a couple hundred bytes smaller (like 500 vs 700 or so). Once it actually works, I’m going to do a deeper dive on the generated code.

@sj Same! Then it could match everything else I use for tracking time.
I wish I could switch my oven clock to 24-hour time.
@mos_8502 If you’re still looking for more memory to squeeze, I did some testing this morining and found that the mos-llvm package produces much more optimized 6502 code than calypsi does.
@wronglang @mos_8502 @mmu_man So thankfully they didn’t integrate an LLM with systemd itself, and are instead likely to be using an LLM to generate code in systemd. The former would be much worse I think. The worst of the likely effects of the latter could be mitigated with careful code review.