(untitled)

Has anyone programmed their own OS? I think it would be fun to do a chan driven OS, lainOS anyone? It would just take intermediate skill in C(++)/Assembly

As a kid I really wanted to make my own OS. Now I know how much work it is and I just have the time for this kind of project. Still I find it interesting to know what happens on the low levels. You might be interested in this http://wiki.osdev.org/Main_Page They have some great articles on the subjects.

I believe LainOS actually existed in the early 2000s

I'm working on one. Very slowly. I've big dreams and small hands. I've spent a lot of time designing it and have a good idea of how the system will fit together and how the mess I'm building will be handled by the hardware. I'm mostly targeting x86_64 architectures with a nod towards compatibility. I'm often quite torn between doing it quickly and doing it properly and I usually err on the side of properly. I know it's not going anywhere but it's fun so I may as well take it slow and make something I can be proud of when I'm 70 (even if it's still only half done). It's been a bit weird trying to go from the ground up without worrying about how unix and windows do things. I want to exploit the hardware as much as I can or at least not be incredibly slow and hardware and unix and windows have been optimised for each other. As such on a hardware level I'm not going to do much out of the ordinary. I think it's really important for an OS to have a philosophy. Consistent systems are easier to learn and remember. So, briefly, fuarrrk users I care about programmers. They can care about users. Programming is hard, but I trust that they've got this. There's a high focus on asynchronicity and interconnectedness of components system wide and it's easy to fuarrrk that up and race condition or misunderstand what memory is shared and to make it work the programmer needs to provide accurate metadata on their code and worry about things like where there memory is allocated. The only interface the kernel strictly presents is tied to a directional graph (called the chain). Encoded in this graph is every binary installed on the system along with anything else that offers functions, such as the OS itself, as well as a lot of metadata to make those functions widely useable. At a minimum functions have just enough metadata that you can determine what pages will need to be mapped where in its address space based on its inputs in order for it to work (calls like malloc require extra metadata arguments to make this feasible). You just have to load the right registers and syscall though compilers should optimise this to a normal call when appropriate. Also any function can be called asynchronously and returned token queried (via more functions), there's no fork. The chain itself is complicated and mostly should only be inspected by linkers, shells, sysadmin programs etc. Encoded in the chain owned by the OS is everything on the system, though to an individual program it will only present a portion based on security rules. To keep the chain as simple as possible it follows a few rules. Most nodes have 2 edges (previous and next) and don't care about their ordering relative to each other. There are called PI (position independent) nodes. PD nodes come in two main types. Either they are the beginning of a branch and affect only things within that branch, or they affect everything that comes after them within the chain. Some nodes, usually those associated with security, are a branching node to the OS and an affects everything node to a program. To give an example of a simple system. It's a public computer which needs guests and sysadmins. The graph begins with system management functions, all the stuff the OS needs to get booting. Then memory, filesystems, processes all the normal stuff. Then a security node intended to restrict dangerous system functions. This node has 3 edges away from it. The first branch contains references to which earlier nodes need to be hidden and the rules which control when (i.e. guest or sysadmin). The second and third edges branch the chain for those who do or don't match the rules. The guest chain has a bunch of random user programs. The admin chain contains some admin programs and the "next" node of its final link is connected to the beginning of the user chain. A final security node would hide things that the user programs needed but that aren't available to the user directly, like network functions. At the end of each branch (called a context) there is an init function called on boot. The guests would start a gui the admins maybe an sshd. All programs run within a context and on a secure system the functions to swap contexts etc will be hidden or controlled to normal users. There's a ton more could be said about any of this and I'm still just slowly writing a bootstrap compiler. See you all in a few decades when I have something that boots.

>>2683 Yep. http://lainos.sourceforge.net/

Most colleges actually have a required CompE course that make you build an OS from scratch.

>>4388 It was heavily criticized on: https://bsd.slashdot.org/story/02/03/16/2030250/anime--freebsd--lainos

Tried and failed. Wasted about 2 years of my life on it. Maybe one day ill get back on it.

>>2689 you should look into seL4 and genode, they both incorporate many elements of what you're talking about.