moody__
Joined 3 years ago
Joined 3 years ago
But this is being reversed now and this has gradually been the case over the years. By just using linux are you capable of debugging the kernel? When the code itself grows unbounded in size and complexity, the moat grows more and more. Tomorrow if you had a nasty GPU driver bug or scheduler bug in any of these systems are you personally empowered to make that change? I would argue no. I've had this, I've tried trawling through the kernel to help some nerds debug why ppc64 KVM was not working when running in BE mode and it was completely intractable. I could just be an idiot though, the evaluation of that is left to the reader.
My point with referencing with LLMs is that this has turned this dial up to 11, now you have developers shipping a crap ton of code and complexity is growing more. The more the developers rely on this stuff the more there is this kind of implication that in order for you to keep up you will use it too. Is that carrying the spirit of the luddite?
Also FreeBSD is also taking LLM stuff, OpenBSD doesn't have a policy prohibiting this, NetBSD does.
Linux has gone from attracting hippies to openly endorsing corporate closed-source products, something something live long enough to become the villain.
In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server. Unless someone does a great deal of effort to port all of those environments that people want (nodejs, modern python, etc) you're going to be stuck using a VM and losing a lot of the benefit.
This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux. It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment.
[0] https://www.rfc-editor.org/rfc/rfc5891 § 4.1 "By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C"