Yes. I'm advocating for consideration of Option Z.

Option A is the best practices status quo for a lot of people. "Don't waste time and money reinventing the wheel", "Given enough eyes, all bugs are shallow", etc...

But Option Z is becoming cheap and fast, and given all the eyes, there still seem to be a lot of bugs in Option A.

Maybe it's better to tolerate a few bugs so long as it's not the same bug on everyone's computer.

Maybe you have fewer bugs if you aren't supporting 50 years of backwards compatibility.

Maybe the economics and risks change for the hacker when he can't find bugs offline.

Maybe we should appreciate people researching how to vibe code containers and kernels.

▲

UpsideDownRide a day ago | parent [-]

If we are using only a few LLMs then chances are that they will tend to make same kind if errors when building something. Take LLM prose being annoying - it is so because it is very homogeneous.

So it can very well be worst of bith worlds, worse security on actually homogeneous systems.

▲

xscott a day ago | parent [-]

If everyone prompts, "reimplement Linux", that's possible or likely.

The dude who says, "Give me a microkernel, use QNX request/receive/respond for syscalls, it only runs WASM blobs, device drivers are isolated user mode processes, it only supports HTTPS on one network interface, and the file system is readonly ExFAT" will probably get something different.

I hate low value LLM prose (slop) too, but if you ask it to write like Herman Melville, you'll get few "it's not this, it's that".

Maybe you do still get the same kinds of errors when you ask for VMS, 64 bit memory safe DOS, or a Unikernel. I dunno, but it seems like something that could be improved when it's identified.

▲

TheAmazingRace a day ago | parent [-]

>64 bit memory safe DOS

Ok, you have me intrigued. FreeDOS-64!

	▲	xscott a day ago \| parent [-]
		One COMMAND64.COM, one CONFIG64.SYS, an optional AUTOEXEC64.BAT, and the rest of the computer is yours. Maybe use forward slashes though. :-)