Your tone is very out of place in this thread. If you don't know that something was solved before and you solve it yourself, it is a great feeling and very rewarding.
I love solving crossword puzzles, riddles and similar games. Yes, even though someone else even _designed_ them. We were talking about gaming.
Agree on all those goals. Over the years, I've seen some essays and comments scattered all over the web containing those ideas; it would be great to collate all of those thoughts somewhere.
I can handle the FPGA side. Start with essentially DOS for RISCV. Use qemu for kernel development, and Verilator as the simulator for RTL. Develop a simple graphics unit that is "pluggable" so you can replace it with a more advanced one later (or if the user requires it). Same for networking.
We'll target one of the ICE40 fpgas with an open toolchain. Not that they're great FPGAs, but the open toolchain is what's important.
I've been batting this idea around for a while.
My side projects generally involve creating my own little Garden of Eden on top of as mainstream a system as the world can muster, which appears at the moment to be Ruby driven by a shell, not sure yet if it's appropriate to try something other than bash. I never even get motivated to drop down to making C extensions, much less reinvent hardware.
If I'm going to reinvent anything at this point it will be the shell, which to me is the most powerful UI abstraction tool available atm. My main gripe at the moment is $PATH. If I want my own tool to be called sort, well the answer is don't do that.
Reinvention is only relevant when you can actually add capabilities that didn't exist before. Then you have to communicate those new capabilities with a killer app. Even my little example, nobody's going to care that I fixed shell tool namespacing if I can't articulate why I needed it with a better system for personal computing.
And if I go and do all that work to make a new shell, it has to solve all the same problems that the status quo evolved to solve. Now that I'm thinking about it, the answer to my dilemma is to invert the shell, make a very basic CLI that delegates to the shell when you really need it, but offers an extensible garden that is free of the shell otherwise. Build on Readline, not bash. I never really needed bash anyway.
I mean, don't get me wrong, I'd be very very happy to implement my side project on the hardware and OS that adheres to your proposed doctrine. Openness is great. But the seething shifting mass of backwards compatibility isn't just going to go away after you reinvent it all. You're just resetting the clock.
My problem with things like Haiku and Reactos is that they're trying to emulate systems that have already existed - Beos and Windows, respectively. All I want is a modern DOS, say with a faster/more capable graphics layer.
The closest I've found is Wirth's Project Oberon, but the choice of language meant that there's very little that can be pulled from existing repositories and used directly - not too many people are programming in Oberon. C is a requirement, but you get that with the RISCV tooling.
It can https://en.wikipedia.org/wiki/Free_and_open-source_graphics_...
Combine that with the fact that web chumps think they're 'inventing' when they're solving problems that were solved decades ago, only worse, and most of them don't have the historical background, education, or even interest to know what mistakes they're making. They think its "leveling up" to solve an already solved problem, but in web format, while wasting everyone's time with ads, tracking, gimmicks, for money.
You are not burnt out, or wrong. The web used to be better; computing used to be better. Windows is now a service, and Linux still can't drive graphics card without nonfree drivers. We failed, but I think there might be a chance to fix things.
We need to out together a cohesive document that explains why modern computing needs a serious overhaul, and a plan to get there. The computer should be fast; UI should be appealing, but minimal. It should be understandable and open down to RTL of the processor. The core should be aggressively minimal, and fully understandable. Networks with no central auth should be at least an option (preferably a local mesh). It should be cheap.
I'm thinking like a modern DOS, but for RISCV, fully implemented on an FPGA (goal of course to move to custom silicon for performance improvements later).