aktau

Thanks for the notes. Different as/link is definitely a way for incompatibilities to creep in.

I remember when we still had tcc in Neovim CI. I think it got removed eventually for being too much of a burden to maintain.

How are slimcc/kefir different/easier to drop in?

This reminds me of a great adventure. A long time ago I was travelling through Brazil, in the Amazonas state. I was in Porto Velho and needed to get to Manaus quickly to catch a flight. The boat that would take us there (as I had found in the Lonely Planet) was present on the quay. But the captain didn't feel like going. If I remember correctly, he was waiting for more people. We needed an alternative route quickly.

The captain told us that if we took the bus to Humaitá (a smaller provincial city), we could take a smaller boat that would take us to Manaus. But he warned us that the boat only goes once in three days, and that it would leave soon. The last bus to Humaitá would also leave from Porto Velho promptly.

Despite this flimsy instruction, we didn't see any alternative. So we went. With great luck, we caught the bus and made it to Humaitá (I still have a picture of the boat river transfer the bus took: https://bashify.io/i/CdNcLf).

Our time in Humaitá was surreal. When asked about a boat to Manaus. Everyone told us a different story. There was no harbour (hydroviaria) personal. One person told us the boat to Manaus was named "Caçote". Another person said the boat was named something else. Then someone said it had stopped ferrying years ago. No, we heard from someone else, it would come in 5 hours! Yet another one said it was tomorrow. Someone else felt sorry for us because it had just left. I felt like I was in a (difficult) point and click adventure. There weren't a lot of people in town close to the river, so we ran into the same people from time to time. They would often give different answers to the previous time.

No one was willing to tell us they didn't know. Not a single person out of the 20+ we must have talked to.

In the end, a boat arrived. It went in the direction of Manaus. The captain said that he would only go up to Auxiliadora, and that was still a long way from Manaus. Once again without alternatives (going back to Porto Velho would surely mean we'd miss the flight), we chanced it. In the hopes that getting closer was worth it.

When we arrived at Auxiliadora, it was the smallest inhabited place I had ever been to. Perhaps about 13 houses. Some fishermen. No passenger boat would come for days, they told us. Not to take us to Manaus, neither to take us back. The fishermen had boats, I tried to offer them money so they would take us further. But their day was at an end and they wanted to relax, regardless of what I offered them (we were on a tight budget, but I was desperate enough to offer a significant chunk of a monthly wage, no dice).

Then we found out that on the boat with us, a woman had come who was in a similar predicament as us. She was Brazilian, living in MT and wanting to visit family in Manicoré (which was bigger, and closer to Manaus). Exasperated, she ended up convincing her family to come and pick her up with a speedboat. We hitched a ride. We were very thankful.

When we arrived in Manicoré, I felt like exploring the place. It looked so different from anywhere else I had been, like something out of a movie. But I couldn't. The docks were little more than a collection of wooden jettys (trapiche) that ran everywhere in criss-cross fashion. In order to even get to the quayside we would have to pass through many other boats. In the first one we went through, the captain walked past and I asked him whether he knew of a boat going to Manaus. He signalled where to put my bags. We were leaving.

We reached Manaus in the nick of time.

I love this story, and that time. These anecdotes definitely triggered my memory.

I tried btrfs on three different occasions. Three times it managed to corrupt itself. I'll admit I was too enthousiastic the first time, trying it less than a year after it appeared in major distros. But the latter two are unforgiveable (I had to reinstall my mom's laptop).

I've been using ZFS for my NAS-like thing since then. It's been rock solid ().

(): I know about the block cloning bug, and the encryption bug. Luckily I avoided those (I don't tend to enable new features like block cloning, and I didn't have an encrypted dataset at the time). Still, all in all it's been really good in comparison to btrfs.

What were your (main) problems with Kodi? AFAIK it is written in C++ with Python plugins. Electron would be (on the face) a downgrade yes. But how is a Lua app much smoother?

(My personal pet peeve is that Kodi still doesn't know how to minimize CPU consumption when one is doing nothing on the UI. It should just stop rendering. This means I have to turn Kodi off on my HTPC+server setup to stop it from pushing my CPU in a higher power consumption mode.)

“What do you get if you multiply six by nine?”

(One) source: https://www.reddit.com/r/Fedora/comments/1mjudsm/comment/n7d...

Why does one need the second (old-ish) Fritz!Box? Doesn't the first one already have DECT?

Also, does this not require a landline number?

> Agree on mullvad, buy giftcard on amazon.

I've heard this before. Is this just to add another hop in the chain to make it harder for someone to track the user down? Apart from someone needing to order Amazon to pony up the details ("Which credit card was this Amazon item bought with?")

Is there another layer of privacy I'm missing?

Any LLM-based code review tooling I've tried has been lackluster (most comments not too helpful). Prose review is usually better.

> So we run dozens of parallel CLI agents that can review the code in excruciating detail. This has completely replaced human code review for anything that isn't functional correctness but is near the same order of magnitude of price. Much better than humans and beats every commercial tool.

Sure, you could make multiple LLM invocations (different temporature, different prompts, ...). But how does one separate the good comments from the bad comments? Another meta-LLM? [1] Do you know of anyone who summarizes the approach?

[1]: I suppose you could shard that out for as much compute you want to spend, with one LLM invocation judging/collating the results of (say) 10 child reviewers.

For Go, there is https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks. There are some missing things from C++ Thread Safety annotations, but those could be added.

Can't wait! Do you have any idea how far along this is? Is it likely to be months, quarters, years?

(Funny expression, that. I'll wait, of course. It'll be a happy day when this works again and I can slowly make progress RE'ing again.)

Thanks for the note.

Your corruption frequency anecdote matches mine. I don't have the mental werewithal to deal with that. I won't go back to radare2 until they change their project file stability somehow.

+1

I once tried learning how to RE with radare2 but got very frustrated by frequent project file corruption (meaning radare2 could no longer open it). The way these project files work(ed?) in radare2 at the time was that it just saved all the commands you executed, instead of the state. This was brittle, in my experience.

I don't have a lot of free time, so I have to leave projects for long periods of time, not being able to restart from a previous checkpoints meant I never actually got further.

IIUC, one of the first things Rizin did was focus on saving the actual state, and backwards/forwards-compatibility. This fact alone made me switch to Rizin. To its credit, my 3-year old project file still works!

Now for the downside: there is apparently a gap in Windows (32-bit) PE support, causing stack variables to be poorly discovered: https://github.com/rizinorg/rizin/issues/4608. I tested this on radare2, which does not have this bug. I'm hoping this gets fixed in Rizin at some point, at which point I'll continue my RE adventure. Or maybe I should give an AI reverse engineer a try... (https://news.ycombinator.com/item?id=46846101).

Sorry about that, I can no longer edit my comment.

Do you have any relation with the project apart from working at the same company?

More links with discussion:

Reddit discussion: https://www.reddit.com/r/linux/comments/1qw4r71/microsofts_n...

Project lead James Morris announcing it on social.kernel.org: https://social.kernel.org/notice/B2xBkzWsBX0NerohSC

From the GitHub page:

LiteBox is a sandboxing library OS that drastically cuts down the interface to the host, thereby reducing attack surface. It focuses on easy interop of various "North" shims and "South" platforms. LiteBox is designed for usage in both kernel and non-kernel scenarios.

LiteBox exposes a Rust-y nix/rustix-inspired "North" interface when it is provided a Platform interface at its "South". These interfaces allow for a wide variety of use-cases, easily allowing for connection between any of the North--South pairs.

Example use cases include:

  - Running unmodified Linux programs on Windows
  - Sandboxing Linux applications on Linux
  - Run programs on top of SEV SNP
  - Running OP-TEE programs on Linux
  - Running on LVBS

This is great. I'd love to do something similar for Ground Control (2000, https://en.wikipedia.org/wiki/Ground_Control_(video_game)).

Do you have a writeup of how you did it? Both (regular) tooling (radare2? rizin? IDA? ...) and how the LLM did (or did not) use it?

In the little spare time I have, I've been able to reverse engineer the "compressed" file format (ended up being basically a XOR'ed zlib-compressed TAR-like archive), but not much else. I have not used LLMs to help me.

> I changed read/write_file to put contents in the state and presented in the system prompt, same for the agents.md, now working on evals to show how much better this is, because anecdotally, it kicks ass.

Can you detail this a bit more? Do you put the actual contents of the file in the system prompt? Forever?

That matches what I recall too, back when I ran a very cheap integrated intel (at least that's what I recall) card on my underpowered laptop. I posted a few days ago with screenshots of my 2009 setup with awesome+xcompmgr, and I remember it being very snappy (much more so than my tuned Windows XP install at the time). https://news.ycombinator.com/item?id=46717701

Perhaps worth mentioning: https://github.com/stapelberg/rsync-over-grpc.

I still have some screenshots in my GitHub repository of what my ArchLinux with AwesomeWM (X11) looked like in 2009.

Those screenshots also contain the RSS, as luck would have it.

34MiB when on the desktop (clean), running X.org, AwesomeWM and xcompmgr (for compositing). Screenshot: https://github.com/aktau/awesome/blob/master/screenshots/200...

57MiB with a couple of applications open. From memory: urxvt running htop, thunar (XFCE file manager) and the Mirage image viewer (which is Python, not otherwise known for efficiency). Screenshot: https://github.com/aktau/awesome/blob/master/screenshots/200...

Nowadays, even with a tiling WM that's supposed to be lightweight (say: Sway), the minimum appears to be well over 300MiB (see https://www.reddit.com/r/linux/comments/1njecy5/wayland_comp...). GNOME 49 takes up around 1GiB last time I tried it (NixOS). Interestingly https://www.reddit.com/r/swaywm/comments/oghner/how_does_the... from 5 years ago mentions Sway only using 115MiB. What happened?

Theories I have:

  - 32-bit to 64-bit means all points are double the size. That would account for something.
  - Wayland vs X11. I should compare Sway versus X.org+i3.
  - General library and system daemon bloat.

> They were using tori primitives for the chain mail, and curve primitives for the clothing. (I.e., the clothing was actually woven out of curve primitives for the threads.)

That sounds mind-blowing. Is this documented anywhere?

This is new to me. Can you elaborate please? Perhaps a link to somewhere showcasing this (and contrasting this to other solutions).

(I agree with other commenters' assessment about the importance of the authors complaints, and recommend others checkout the Go memory regions proposal.)

For those interested, here's an article where Miguel Young implements a Go arena: https://mcyoung.xyz/2025/04/21/go-arenas/. I couldn't find references to Go's own experimental arena API in this article. Which is a shame since it'd be if this knowledgeable author traded them off. IIUC, Miguels version and the Go experimental version do have some important differences even apart from the API. IIRC, the Go experimental version doesn't avoid garbage collection. It's main performance benefit is that the Go runtimes' view on allocated memory is decreased as soon as `arena.Free` is called. This delays triggering the garbage collector (meaning it will run less frequently, saving cycles).

It's not the original source, but https://github.com/dpjudas/SurrealEngine is an active reimplementation of UE1.

I was not aware of bkt. Thanks for the link. It seems very similar to memo, and has more features:

  - Explicit TTL
  - Ability to include working directory et al. as context for the cache key.

There do appear to be downsides (from my PoV) as well:

  - It's a rust program, so it needs to be compiled (memo is a bash/zsh script and runs as-is).
  - There's no mention of transparent compression, either in the README or through simple source code search. I did find https://github.com/dimo414/bkt/issues/62 which mentions swappable backends. The fact that it uses some type of database instead of just the filesystem is not a positive for me, I prefer the state to be easy to introspect with common tools. I will often memo commands that output gigabytes of data, which is usually highly compressible. Transparent compression fixes that up. One could argue this could be avoided with a filesystem-level feature, like ZFS transparent compression. But I don't know how to detect that in a cross-FS fashion.

I opened https://github.com/dimo414/bkt/discussions/63 so the author of bkt can perhaps also participate.

Those commands are a (1) harder to grok and (2) do not actually use the memoized result (tmpfile.zst) to speed up a subsequent run.

Can you give a more complete example of how you would use this to speed up developing a pipeline?

Yes, I know. I should've taken a different example. But it's also realistic in a way. When I'm doing one-offs, I will sometimes take shortcuts like this. I know awk fairly well, and I know enough of jq that I know invoking jq . pretty prints the inbound json on multiple lines. While I know I could create a proper jq expression, the combo will get me there quicker. Similarly I'll sometimes do:

  $ awk '...' | grep | ...

Because I'm too lazy to go back to the start of the awk invocation and add a match condition there. If I'm going to save it to a script, I'll clean it up. (And for jq, I gotta be honest that my starting point these days would probably be to show my contraption to an LLM and use its answer as a starting point, I don't use jq nearly enough to learn its language by memory.)

The name of the memo is the command that comes after it:

  $ memo my-complex-command --some-flag my-positional-arg-1

In this invocation, a hash (sha512) is taken of "my-complex-command --some-flag my-positional-arg-1", which is then stored in /tmp/memo/${USER}/{sha512hash}.zst (if you've got zstd installed, other compression extensions otherwise).

up(1) looks really cool, I think I'll add it to my toolbox.

It looks like up(1) and memo(1) have similar use cases (or goals). I'll give it a try to see if I can appreciate its ergonomics. I suspect memo(1) will remain my mainstay:

  1. After executing a pipeline, I like to press the up arrow (heh) and edit. Surprisingly often I need to edit something that's *not* the last part, but somewhere in the middle. I find this cumbersome in default line editing mode, so I will often drop into my editor (^X^E) to edit the command.
  2. Up seems to create a shell command after completion. Avoiding the creation of extra files was one of my goals for memo(1). I'm sure some smart zsh/bash integration could be made that just returns the completed command after completing.