Ente has a killer feature of supporting actual end-to-end encryption for photos. That alone puts them above many other competitors.

For an ideal ('spherical cow in a vacuum') type of homeless person, sure.

Be careful with the setrlimit/ulimit API family, generally it doesn't do what you want. You can limit virtual memory (but... why?) or specific segments like stack, etc. There is also RLIMIT_RSS which sounds like what you'd want, but alas:

    RLIMIT_RSS
        This is a limit (in bytes) on the process's resident set (the number of virtual pages resident in RAM).  This limit has effect only in Linux 2.4.x,  x  <  3 and there affects only calls to madvise(2) specifying MADV_WILLNEED.

I also disagree with the conclusion "No hardware can compensate for a query gone wrong". There are concepts like 'quality of service' and 'fairness' which PG has chosen to not implement.

hah, you weren't joking... https://poc.bcachefs.org/ https://www.theregister.com/2026/02/25/bcachefs_creator_ai/

Unless you want to insmod things in your main kernel like a cowboy, I don't see why you'd need architectures to match. Cross compilation is the proper way (for some architectures it would be quite hard to find a machine capable of compiling the kernel before the heat death of the universe...)

Don't get me wrong, I don't mind old aesthetics, but... yes? Well I wasn't exactly alive in 1978 but all the screenshots look like they are at least 20 years old

Firstly, the original comment was about UI rather than aesthetics. Secondly, as with everything else in Emacs, you can customise the appearance however you want. Those screenshots are from vanilla Emacs which is admittedly rather ugly. Most people heavily customise, or use an Emacs distro like Spacemacs (https://www.spacemacs.org/) or Doom (https://github.com/doomemacs/doomemacs?tab=readme-ov-file) which have more sensible default appearance configs.

20 years ago was in 2006, not 1978.

mlockall(2) + tty/framebuffer based graphics should do the trick

When you say you use local model in OpenCode, do you mean through the ollama backend? Last time I tried it with various models, I got issues where the model was calling tools in the wrong format.

That's exactly why I'm asking! I'm still mystified about whether I can use ollama at all. I'm hopeful that the flexiblity might become interesting at some point.

zr?

vim folds are fully programmable. For me a bigger issue was git calling vimdiff for each file, which I fixed with my own difftool: https://gist.github.com/PhilipRoman/60066716b5fa09fcabfa6c95...

I ran in to a couple problems when trying that script (details below), but I'm really happy that you shared it, because I had not seen ':windo diffthis' before, and that method of scripting diffs. I'll definitely be customising it!

(I found that my mac machine doesn't support the '-printf' option, and also I was attempting to run 'git bvd main' on a branch but it seems it does a recursive directory diff, so I'll use 'git diff --name-only' as the input to the awk command).

Edit: worked nicely! I haven't used tabs much in vim so is a slightly new workflow but otherwise very handy

> For me a bigger issue was git calling vimdiff for each file,

If you configure vimdiff as the difftool in your git config, just doing a `git diff` would show you the diff for each file sequentially.

I think that's an oversimplification. Voting does not have the same dynamics as soccer goals. Maybe a better analogy would be that the team is already winning 5-1 and in the last minute someone makes it 5-2. Good job of course, but can't really be said to influence the outcome.