After reading all 4 parts (up to part IV), this is pretty underwhelming.
The author makes a lot of noise about reinventing OS and mentions "heresy" a lot, but his main idea is a non-preemptable thread which runs an event loop. You know, like Erlang's BEAM; or running one boost::asio event loop per core; or Windows 3.11; or, going back to embedded examples, using nesC/TinyOS.
Additionally, there are also a lot of random ideas which have no explanation and have obvious known problems that need to be addressed: "vast majority" of processes is shared-nothing; non-stop record/replay debugging on every API call; same kernel API for devices with 32 KB and 32 GB of RAM; "API groups" which are replacing libraries; optional preemption. One can certainly make them work, but this is non-trivial, and author does not provide any answers (actually he just does not mention possible problems at all)
I feel that the author maybe had some ideas, but run out of steam? Or maybe the comments caused him to re-think the his ideas? Either way, the last post was in 2019, so I guess we will never know.
I am surprised ithare.com would publish such incomplete / partially incorrect series.
Related: The keynote presentation from OSDI (Operating Systems Design and and Implementation) online conference: “It’s Time for Operations Systems to Rediscover Hardware”:
The presenter says that, of the 103 papers about operating systems published by OSDI in 2020 and 2021, only three were not about Linux!
I just watched that too. Must have read the same comment. Anyway I agree with the first YouTube comment. It's only partially Linux's fault. SoC vendors would never want to give up control of the software that runs on the SoC to just anyone, so there's not really anything Linux can do about it even if it wanted to.
"Build your own SoC" is not really a viable solution for most people.
Covered a few months ago:
I know I shouldn't "judge a book by it's first few paragraphs", but the "40-50 years old = bad" is such an annoying fallacy in tech.
It's like throwing out proven fundamentals of how to build a bridge just because we went from horse and buggy to cars.
(I say this as a nerd that desperately wishes for a lisp os that goes down to the metal, for plan 9 to be popular, etc.)
I think you could actually justify it with something sufficiently radical, but TFA fails to do that.
The author mixed up VAX the computer architecture and VMS the operating system.
To make progress in OS architecture, it’s optimal to have a clear view of the failings you want to address. The author seems to have a fundamental misunderstanding of basically everything.
Unix is garbage in a lot of ways. But there’s nothing to see here.
In the future, OS will be a DB-like, and Clojure will be the best DML, The future OS kernel will be a data-oriented scheduler (with Computer hardware and software integration architecture diagram)
https://github.com/linpengcheng/PurefunctionPipelineDataflow...
Reference
1. The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model
https://github.com/linpengcheng/PurefunctionPipelineDataflow
Its mathematical prototype is the simple, classic, vivid, and widely used in social production practice, elementary school mathematics "water input/output of the pool". My theory rebuilt the theoretical foundation of the IT industry, It makes the computer theory system fully & perfectly related to mathematics in a simple and unified way: from hardware integrated circuits and computer architecture, to software programming methodology, architecture, programming language and so on. It solve the most fundamental and core major problems in the IT industry: The foundation and core of the IT theory lack mathematical support.
2. Why my "warehouse/workshop model" can achieve high performance and low power consumption (take Apple M1 chip, Intel AVX-512, Qualcomm as examples)
https://github.com/linpengcheng/PurefunctionPipelineDataflow...
3. Foxpro Database-oriented programming paradigm is the development direction of the future programming language
https://github.com/linpengcheng/PurefunctionPipelineDataflow...