The things described at that link cannot be fixed in any simple way.
There it is said that Ginux does not implement mutual exclusion in the right way for a multiprocessor.
To implement this correctly and in a way that ensures high performance even on CPUs with hundreds of cores is one of the most difficult parts of an operating system kernel, much more difficult than just implementing the system call interfaces, to enable a user program to run.
Other point is that Ginux is vulnerable to some races caused by interrupts, which is again something difficult to get right in an operating system kernel, unless you copy exactly the corresponding code from the Linux kernel.
From a practical point of view, Ginux cannot be called anything else except a toy operating system kernel, at the level that previously could have been a home project for one student at an OSes course.
Of course, despite being a toy, Ginux is an impressive accomplishment by being good enough to run an unmodified Linux user program, and its implementation with an LLM has required at least an order of magnitude less time than a human student would have needed.
Still, there is a very long way from a demo like this to seeing an LLM that can generate autonomously a real operating system kernel, without further interaction with a human after the initial specification.
It should be remembered that the main purpose of an operating system kernel is not implementing the API of the system calls used by the user programs, which is the trivial part of its functions. The kernel is the manager of the shared resources of a computer system, like CPU time, memory, peripherals, which allocates them to user programs and ensures that their usage is maximally efficient and that the user processes cannot use the shared resources otherwise than as decided by the kernel. This is something that Ginux has not accomplished at all, based on the description from the link provided above.
> There's always one of two of you rabble going "You dared defy the kernel community!
No. It's very simple. 1) do QA and follow the release cycle, 2) act like a person when interacting with other developers.
If you fail to do both, you should not be surprised that people go through great lengths to not have to deal with you and all your nonsense.
The fact that after all this time you still feel compelled to gaslight everyone with this victim mentality shows that you still have a long way to go to, and a lot of soul searching to do.
The kernel doesn't have any kind of coherent testing strategy. That was a big part of the problem, because that means the subsystems that do test their code, like bcachefs, get stuck picking up the slack for the subsystems that don't.
I was spending a lot of my time just doing QA for the rest of the kernel.
You seem to just be painfully misinformed - or you're outright trolling.
Sir Overstreet still seems insistent on having done no wrong on account of fixing user bugs taking priority over literally everything, so clearly there’s a mindset clash that’s gonna prevent a re-merging unless that Torvalds decides to change the same procedure he’s been doing for the past 2 decades or Overstreet knocks his own ego down a peg.
> I can’t remember anyone earning the level of hostile treatment he did and getting kicked out.
You don't seem to be following it very closely, as apparently you failed to come across the history of abuse and hostile behavior of bcachefs's maintainer.
Apparently they got fixed by now.
reply