3 ms·

Hi. I'm the author. It seems to me that you are unaware that this is part 4 of a series adapted from my 2024 main programme talk at the FOSDEM conference. htt

Hi. I'm the author. It seems to me that you are unaware that this is part 4 of a series adapted from my 2024 main programme talk at the FOSDEM conference. https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/ https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-... This article is just the epilogue and you are misunderstanding it because you lack its context. I turned the talk into 4 articles. This one states the problem: https://www.theregister.com/2024/02/12/drowning_in_code/ https://www.theregister.com/2024/02/12/drowning_in_code/ This one tries to explain the history: https://www.theregister.com/2024/02/16/what_is_unix/ https://www.theregister.com/2024/02/16/what_is_unix/ This one offers a path forwards: https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/ https://www.theregister.com/2024/02/21/successor_to_unix_pla... You just read the epilogue which suggested some ways that people who weren't kernel developers -- as I am not myself -- could help.

superkuh 3y ago
> There is an urgent need for smaller, simpler software. When something is too big to understand, then you can't take it apart and make something smaller out of it. And the first step is stopping the practice of adding 6 extra layers of container/vm/etc abstraction on top of everything making it infeasible to debug or understand.
- lproven 3y ago
  I completely agree. Which is why I propose 9front as an alternative point to start from. But it has few apps, and is too different to readily port to. So, I'm suggesting a way to efficiently run Linux apps on 9front without emulating Linux. So we can use existing tools while working on replacements.