paritybit.ca

Raw content of https://www.paritybit.ca.
git clone https://git.sr.ht/~jbauer/paritybit.ca
Log | Files | Refs | README | LICENSE

commit 95fdf849516769bc501ba6a4991080bf01102cb4
parent 0fff2de693aee3e2b9a00c6fe1cc7ff6ad77a4a4
Author: Jake Bauer <jbauer@paritybit.ca>
Date:   Sat, 20 Aug 2022 20:12:25 -0400

*

Diffstat:
Mcontent/garden/plots/index.gmi | 1+
Acontent/garden/plots/os-project.gmi | 37+++++++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/content/garden/plots/index.gmi b/content/garden/plots/index.gmi @@ -18,3 +18,4 @@ The Plots are where active projects live. Here you can find actively worked on t => ios-evaluation.gmi Evaluating iOS as a Linux/BSD user => buy-nothing-site.gmi Buy Nothing Site => server-monitor.gmi Server Monitoring Made Easy +=> os-project.gmi Project -Create An Operating System- diff --git a/content/garden/plots/os-project.gmi b/content/garden/plots/os-project.gmi @@ -0,0 +1,37 @@ +# Project -Create an Operating System- + +## Jonathan Blow on how an operating system should work + +=> https://www.youtube.com/watch?v=k0uE_chSnV8 + +* Current OSes have too many processes running by default before you're even doing anything with your computer(400 in this discussion) +* Current OSes have way too many executables by default (4500 in this discussion) +* A functional OS should not be doing very much. If a user wants to do a bunch of work that's good but the OS should not be large +* No drivers +* Most things should happen in userspace +* Programs should be able to go over the network without talking through the kernel +* Processes communicate through memory mapping/memcpy +* Few processes running +* Processes super-sandboxed from each other, basics of how OS works, not additional thing +* Core interface that OS implements should be as simple as possible -> facilitate DMA with hardware, handle memory pages, etc. +* Basically microkernel but better +* This ideally would be a lot more performant because you don't have to keep going through kernel space or use syscalls for every little thing +* No installs/invisible installs, you just run it, program shouldn't be able to access anything else anyways so no need for install, it runs in its own little sandbox +* All code position-independent so no static/dynamic libraries, just one library type which could be statically or dynamically linked at compile time (ideally statically, but in such a way that the program knows what code came from which library so if a security patch is needed we can know which processes need to be updated/changed). +* Command line programs and library functions should be the same, with the command line possibly implementing extra interface stuff, but either way no separation +* It's not a good idea to have a ton of software on your OS, most software is bad and fluff and really not needed +* Don't try to replicate functionality of Linux, Windows, MacOS, etc. +* Batch scripting is not a good idea because it usually turns into programs to just run programs +* No PATH variable because programs can't arbitrarily read the FS, but maybe more structured folder? +* No registry + +## Jonathan Blow on Drivers + +=> https://www.youtube.com/watch?v=xXSIs4aTqhI + +* Communication over DMA +* Each process implements own TCP stack (i.e. it's basically in a library) +* What we have now is a mess where drivers from anyone get complete access to the kernel +* Drivers are a mess anyways, a program to connect to a printer should just connect to the printer, not need to go through a middleman +* Stuff like sound is solved, but very broken/complicated in a lot of OSes, it should be simple to stream sound to devices, no need for 100s of drivers +* Make the hardware target the software, not the other way around. One software stack/protocol is really simple to maintain compared to 100s of different pieces of software to support 100s of different devices (i.e. standardize on some set of protocols or say "if you want to support this OS, you have to do this in your hardware"), if not then use a userspace translation program, so at least this "driver" doesn't have kernel access.