Comment by e-dant | Hacker News Reader

Comment by e-dant | Hacker News Reader

I’m wondering if this really is too aggressive.

On Linux, sure it’s not possible to directly crash another program you’re talking to via a socket alone (ignoring bad data on the socket).

But you can absolutely kill them. Anything running as root can kill anything else. Can even reboot and bring down the whole system.

Maybe a bit harder and a bit more unusual, but at least for containers, root privileges are common. And yeah, sure, there’s a cgroup there are you’re more limited. But you get the idea.

It’s also a bit different from the (conventional?) wisdom about being “liberal in what you accept, conservative in what you emit” though that’s a bit more tied to networked systems.

Though, maybe it’s inevitable that a system has to be liberal in what they accept.

How else can you change the api slightly without breaking existing programs?

Hubris isn't a general-purpose OS, it runs on a low-level processor inside the Oxide server rack. I believe Hubris doesn't even allow new kinds of processes at runtime; all possible executables must be determined at compile time.

> I believe Hubris doesn't even allow new kinds of processes at runtime; all possible executables must be determined at compile time.

This is correct, yes.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

> I believe Hubris doesn't even allow new kinds of processes at runtime; all possible executables must be determined at compile time.

Correct. From [0]:

"Hubris is an aggressively static system. The configuration file defines the full set of tasks that may ever be running in the application. These tasks are assigned to sections of address space by the build system, and they will forever occupy those sections.

Hubris has no operations for creating or destroying tasks at runtime. Task resource requirements are determined during the build and are fixed once deployed. This takes the kernel out of the resource allocation business. Memories are the most visible resources we handle this way, but it applies to all allocatable or routable resources, including hardware interrupts and memory-mapped registers – all are explicitly wired up at compile time and cannot be changed at runtime."

[0] https://cliffle.com/blog/on-hubris-and-humility/

Reply on news.ycombinator.com