Well an operating system talks to hardware and allocates resources, right? The motivation to write a non-toy operating system must be some strong ideas about how to do those things, and they'd have to be pretty fundamental to give up on the vast advantages of interoperability and pre-existing software that would come from just implementing your ideas on top of Linux or whatever.
Past motivations for writing OSes might be expressed as licensing (GNU/Linux), disagreements about fundamental architecture of operating systems (microkernels), need for hard real-time (vxWorks), or the belief that you have the sheer resources and market power to start again and build something better (Windows NT). Security seems like another likely motivation (There's probably a better example than OpenBSD because I don't think they started from scratch).
I quite like the idea that hardware intended for autonomy might benefit from being implemented on bare metal. Devices that AREN'T general-purpose computers, but communicate only with their own hardware and with the outside world by their actions and by communications protocols, well why shouldn't they run on a custom and highly stripped-down OS? You'd expect to get benefits in performance and a smaller codebase for potential security holes. But I don't think the industry is actually headed in that direction.
Some embedded OSes work by basically writing your application as an extension of the OS. So you're essentially running on bare metal there. Usually even for simple devices you want more than one thread/process....and then you start wanting OS stuff.
There's probably a better example than OpenBSD
Kaspersky's new OS is built for exactly that reason.
Also, for completeness, the osDev wiki has a list of OSes built for various reasons....some serious, some for research: http://wiki.osdev.org/Projects
How about some new idea that hasn't been tried before? Maybe you'll find a better way of doing things.
My unix box handles the day-to-day, but the future is coming, and I can't wait.
>Maybe I need to keep posting it when people ask these questions if it consistently has such an effect
That's what I do. It seems to usually work.
Additionally theres a few features I would prefer from a security user experience standpoint
- symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?"
- all applications run in a container
- the application can never touch os filesystem or know about other apps but themself and what the user allows
- requests for hardware trigger permission dialog
- requests for files are handled outside the container
- shared folders are mounted to the container that the user knows are vulnerable
- some folders are an aggregate of the applications folders but the application only views its own
- deletion of an applications folder will permanently delete all if its data. No messy installations or artifacts
- system monitor shows cpu, memory and network usage per application
- applications require permission to use network and outward calls can be captured before being made
Additionally there are features from a dev standpoint
- there is a discoverability system for modified and alternative applications
- there is a focus on ensuring all parts of the os are easily found and modified
- changes to the os filesystem creates forces the user to create a virtual machine, make changes to that then "commit" those changes in bulk
- the user can make these patches available online along with keywords, problem and a tutorial inorder to recreate for discoverability
- heavy focus on user interfaces that can be reused in terminal and gui. Applications that only are available in one or have different experiences will be flagged as such.
But I canonly make this if I know how
Patch your coreutils. Difficulty: easy.
Most of your other needs can be addressed by making a specialized Linux distro (difficulty: hard), rather than writing a kernel that does all of this (difficulty: max). Build your packages to be containerized by default. I suggest using chroot containers and writing some kind of FUSE filesystem to mount in the container and provide controlled access to user files. You'll also want to write or modify a Wayland compositor to suit your needs. You can have this provide the permission prompts and similar things. Difficulty: hard, but very much doable.
Skills to learn: Linux, thoroughly. You should be comfortable making packages, running things in containers, and writing C before you embark on this.
You should definitely build this. I'm working on something similar but my design appeals to fewer people. Feel free to reach out to me if you have questions with anything, email is in my profile.
I guess writing a new kernal is more for rasberry pi/odroid/dev boards? In that case having a detailed explaination on it would be nice