Non-CoC modern OS from scratch

no that html ui dude is a retard, he also wants to replace pipes with packets

He's not a retard, he's a shitposter.

It's really tiring to read the papers, but I'll try to work my way through them.
I think I will add RISC-V features into the OS, which will have to be emulated on other architectures. The reason for that is that RISC-V is more modern, and on top promotes freedom.

Yes it does, except they're calling them "privilege levels". Chapter 1.3, github.com/riscv/riscv-isa-manual/releases/download/draft-20181121-c743d2f/riscv-privileged.pdf


Such as?

As far as I understand, Multics rings are a RISC-V thing, and they work different from x86 rings. They offer more fine-grained control.

It's stronger than just handy. It is the necessary level of abstraction. It is not the responsibility of the tool to keep track of where my files are coming from, and change their behaviour to match. I don't know how you use the word "unclean", but a system that forces a separation between files on disk and files in memory creates unnecessary work for all parties to no visible advantage, which I see as a very unclean thing to do.

It always pissed me off that send/recv aren't just write/read. I suppose one difference is that a socket is two sided, whereas file descriptors are normally unidirectional. But this distinction doesn't seem sufficient to justify two separate io apis.

Thanks for defending me user :)

I think that only files should be treated as such: You can seek in a file, tell its size, append, delete, overwrite. You can do no such thing with a socket or pipe. What would be more sensible is to provide a stream abstraction, where you can use sockets, files, microphones, etc., with an API that allows to read/write bytes (even then, there needs to be a distinction between read-only, read-write, and write-only streams). If you want to meme it the UNIX way, then use the stream API for everything. But if you want to have powerful file manipulation primitives (mainly seek, tell), or socket primitives (shutdown, etc.), then you need to access an API that is designed only for files (or sockets, respectively).
I am a big fan of type-safety, and *everything is a file* just doesn't fit right with me.
Also, why would you use filesystem locations to locate a socket or keyboard? It is a fucking filesystem, there to organise data on your permanent storage into named FILES and DIRECTORIES.
Also, in the UNIX file api, not every file operation can be applied to every file, which is why I say it's not clean. Rather than that, I will make a FILE,SOCKET,KEYBOARD,PIPE < IN/OUT-STREAMABLE hierarchy. If something fits into the FILE concept, then all file operations can be applied to it. If something is a SOCKET, then all socket operations can be applied to it. And so on. The UNIX equivalent of a file would then be IN/OUT-STREAMABLE, which applies to almost everything. I would also make a distinction between filesystem locations and pipe names, device names, etc. You could, for example, create a streamable handle to a file via file(location) or file://location, and devices via dev://name.

I never did say, or intend to say, that files in RAM should be treated differently from files on a HDD or SSD or other storage medium. I did say that the API for files should only be applicable to files.

A direct consequence of this is that URLs will be the default way to pass resources, which will also make it easier to pass remote resources, as the programmer would not try to open everything with the file API, but with the streamable API, which would then detect remote URLs and other things, and handle them accordingly to the specified protocol.

Right now I at the stage where I have the following resource types:
Files, devices, pipes, connections, locks, conditions, barriers, events, futures, promises.

The following abstractions exist:
Stream = {file, device, pipe, connection}
Awaitable = {condition, barrier, event, future}

I have taken many synchronisation primitives, as I am convinced that they should be supported for simpler cooperation amongst processes. I.e., if you want to synchronise execution, and need a barrier, then on UNIX, you would have to do some strange IPC, and even simulate the barrier in one master process.