codethief

If you're already using a Pixel, why base your custom, very much stripped down version of Android on LineageOS as opposed to GrapheneOS? From a security perspective, that's insanity.

(I would actually love to see a GrapheneOS-based version of this!)

How so?

Do they? https://longbets.org/1/ has yet to be settled. Either way, I doubt an LLM could fool anyone here who who knows how LLMs work into thinking it is human, at least not for an extended period of time (think about context length/compression, prompt injections, …).

> I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these.

While I get your point, a lot of vibe-coded agent TUIs (Claude Code, GitHub Copilot CLI, …) aren't exactly fast, either.

> First, a TUI is usable with only the keyboard.

Is it? Many TUIs these days don't allow me to configure my usual key bindings for moving my cursor within input fields. Meanwhile, GTK offers (used to offer) a way to customize key bindings across all GTK applications. (Unfortunately, they removed that feature in recent versions. Now I understand why people always get so upset about the GNOME devs…)

This was what stood out to me, too! And this:

> Packfiles are the fundamental building block of Git storage and Git networking.

(emphasis mine)

> His approach was storing the objects in a distributed hash table. This was only possible thanks to JGit, a custom Git implementation in Java. Like any good ol' Java library, JGit provides enough interfaces and factories and interface factories to abstract all the details of a normal Git repository, including replacing its on-disk packfiles with a DHT. Although the system worked and results were good enough for normal Git operations, the limitations of the Git protocol (which again, require packfiles to be sent over the network regardless of how you store data on the server) made the git clone performance bad enough to discard the design altogether.

Looks like Java enterprise design patterns aren't all bad after all :-) and the git ecosystem would have profited from a bit of abstraction and separation of concerns here, where network protocol, git domain model, and storage layer are evolved somewhat independently. The domain model is what everyone in the ecosystem needs to agree on, the network protocol is what at least the given local & remote host need to agree on, but storage is mainly a local concern.

Of course the question is whether git would have today's market and mind share if they had gone down that path. The ecosystem would be a lot more heterogeneous, evolving network protocol would probably take much longer, etc.

Ah yes, so if I understand correctly, you're referring to the fact that, e.g., on Linux a typical Secure Boot setup will verify the kernel (if at all) but not the rootfs. Yes, that's of course a huge issue (as is mutability of the rootfs in the first place). I think what I had in mind is indeed more akin to the "verified boot" setup you described.

Agreed, I was excited about this until I found

  To get started, sign in with Vercel:

  fx login

in the README on Github.

> The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.

Interesting. Could you elaborate? I always thought that Secure Boot is reasonably secure (provided you can set it up in the first place).

Sure, the form of the function being maximized will usually depend on the environment.

> It maybe can be, but what is the maxima that is being solved for exactly?

Survival rate/reproduction rate/rate of genes being spread?

Yes, though since it's a "micro" VM, it shouldn't take up nearly as many resources as a regular VM. Some hypervisors also implement memory ballooning to not take up memory that's not being used, but I'm not sure whether Docker Sandbox's hypervisor implements that.

Exactly! As I've argued here on HN before, such an "LLM in a box" might end up being serviced/upgraded once or twice a year by a company very similar to the one servicing the coffee machine at the office. In contrast to databases, storage, etc. it doesn't matter much if the box breaks at some point – they'll just come by and replace it with a new one – and there's barely any software on the box to speak of, at least none that requires continuous development and feature upgrades, beyond rolling out security patches. This makes the business case drastically different from cloud and SaaS offerings, where most of the moat is in the software and the state maintenance (and the vendor lock-in of course). The LLM in a box is destined to become a commodity.

While I agree that a proprietary solution is not great and personally I'd avoid it, too, I am getting https://news.ycombinator.com/item?id=9224 vibes. :-)

As the sibling said, Docker Sandbox is not based on standard Docker containers. It spawns micro VMs.

This is not really an alternative if you care about the security of your host system. Docker Sandbox uses micro VMs for a reasons.

Bubblewrap is not nearly as secure as a proper VM.

It is supported on Linux…

https://docs.docker.com/ai/sandboxes/#get-started has instructions for Ubuntu.

> So what "sandboxing" does this add that is not already present in Docker

Docker Sandbox spawns a micro VM, not a standard container isolated by host kernel mechanisms (Linux namespaces etc.)

> supports acceleration with WHP

On Windows 11, too? At least for hardware virtualization in VMWare one would have to disable Windows Device Guard & Credential Guard for that.

> Does anyone have a better alternative?

Not necessarily better but OpenSandbox[0] by Alibaba seems similar.

[0]: https://github.com/alibaba/OpenSandbox

Do you mean like Docker has supported for years…? (Just configure krun as Docker's OCI runtime.)

Obviously, there's a reason why Docker released Docker Sandbox as a separate product:

- Barely anyone bothers to configure Docker/Podman with a different OCI runtime like krun. Heck, most people don't even know about OCI runtimes in the first place. Case in point: Most people here in this HN discussion are proposing using "standard" containers (with the default OCI runtime) for sandboxing. This is what I was trying to get at.

- A sandbox for agent needs tighter network control.

As for differences between the krun OCI runtime and Docker Sandbox (which also uses libkrun), let's please continue the discussion here: https://news.ycombinator.com/item?id=49240662 .

Yes, you can run Podman with different OCI runtimes, in the same way as you can run Docker with different OCI runtimes, and some of these OCI runtimes are microVM-based.

This is not what the person I was responding to is doing, though.

As for differences between the krun OCI runtime and Docker Sandbox (which also uses libkrun), let's please continue the discussion here: https://news.ycombinator.com/item?id=49240662 .

That's not correct. Virtio devices have different security properties and many of them expose the host system to considerable risks. Using containerization on the host is one way to limit the latter. See e.g. https://github.com/libkrun/libkrun/#security-model for more details.

I'm afraid I don't want my sandboxes to live in the cloud, though. :-)

To everyone sharing their favorite container-based sandboxing solution: Docker Sandbox does not use containers for isolation. It spawns the workload in a libkrun-based micro VM, which has vastly different security properties.

Yes, pretty much, except for one detail:

> That runs the codex OCI in a qemu microvm.

AFAIU it's actually the other way around: krun spawns a libkrun-based (not QEMU-based) VM inside a crun container. Source: https://github.com/libkrun/libkrun/discussions/538#discussio...

So with your solution you get the additional security benefit of containerizing the hypervisor on the host.

> exactly this

This is nowhere near "exactly this". Docker Sandboxes uses micro VMs, you just use regular containers which have completely different security properties.

In my experience it's mostly the UX/DX where Gondolin is lacking. For instance, I don't want to set up a JavaScript project every single time I need a sandbox. Instead, I just want to place a config file somewhere in my repo or my home dir and be done with it.

So I wrote a wrapper around Gondolin which allows me to do that and a few other things: https://github.com/codethief/tuor

(Warning: Still very much experimental / underdocumented.)

Agreed, bad posture (not just neck but in general) can cause both tinnitus and RSI-like symptoms in my experience and I have been able to tackle both with proper exercising.

Where I don't agree is the following:

> Turns out the process to straighten your neck - even after like three decades - with just some casual invest everyday only takes about a month or two.

While you can make progress quickly (in the sense that your symptoms become less severe), fixing your posture usually takes much, much longer than that. In fact, if we're being honest here, it's never a one-time fix that you do for some $TIME and then stop doing. The reason being that forces & activities that cause or exacerbate bad posture (sitting, carrying a back pack, sleeping on the side, various sports, doing no sport at all, wearing shoes with a high heel drop, …) are not a one-time thing, either. They act continuously, and so "fixing your posture" must be a continuous life-long activity, too.