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"

source: I've implemented Unicode normalization from scratch

I like to think of code as not that much different than prose, they are both strings of text for communicating information, typically in a fashion of one thing after the other. I think most people would find syntax highlighting for prose to be more annoying than not (outside of perhaps seeing grammar rules for learning). Once I tried reading and writing code without syntax highlighting I found that it encouraged me to actually read and digest code instead of just skimming it. Compare it to reading prose with and without certain subsections highlighted.

Autocomplete strikes me as optimizing the wrong end of the problem. When I'm writing code I generally am spending a lot more time thinking about the problem space or considering possible implementations then I am having my fingers on the keyboard actively typing it out. In general I think the more you're able to think carefully about code in general the smaller it gets, so I find it hard to believe that by making it easier to quickly dump large amounts of text on the screen you're really gaining much. I think there should be a larger focus on reading and understanding code than writing it.

Stuff like code search is quite nice, and even in 9front we do have some scripts and tooling built-in to help us do that. We have programs like 'Bfn' which can search for a function and send it to your text editor, file names with line numbers can also be quickly sent to the editor as well. I think advancements in tooling that helps people move around in code are generally great, the time spent searching for something is generally not something I enjoy. This was perhaps the nicest part of LSPs in my experience. However I do also think that if you make it quite easy to jump around to lots of different files there is less of an incentive to carefully consider how you're laying out your code. How 9front works where there is some tooling to reduce the monotony but not enough to make it easy to traverse a couple million line java project strikes a nice balance for me.

This is not quite the same, if a single magazine starts to become more ads than decent content it is not insurmountable for another company to start a competitor. It's not ad income itself that is bad, it's that in the case of a web browser it is insurmountable for a company to start up a competitor from scratch. It wasn't always the case, but because google has dumped so much engineering in to chrome they've effectively pulled up the ladder behind them.

I know the focus by the DOJ here seems to be more on search and less on the technical control that Google has over the web experience through implementation complexity, however I can only hope that by turning off the flow of free cash more "alternative" browsers are given some space to catch up. Things like manifest V3 show that Google is no stranger to tightening the leash if the innovation of web technologies impact their bottom line, I'd like to have a web where this type of control isn't possible.

I am also skeptical to your claim about removing memory bugs freeing up brain space for logic bugs, at least for Rust. Rust has grown quite a number of language features, that in my experience, result in a higher cognitive load compared to C. If you seriously reduce your reliance on the C macro system (as Plan 9 has shown possible), the language itself is quite simple.