5 ms·

Other than the educational value of doing so, what would be a reason to write a brand new operating system? Obviously there is a lot to learn about existing op

Other than the educational value of doing so, what would be a reason to write a brand new operating system? Obviously there is a lot to learn about existing operating systems by coding you own, much in the way that writing a new languages teaches you about existing languages, but what are some creative applications of a hand made operating system?

formula1 10y ago
I know Ive wanted to make changes to my own for a while. At very least default ui, menus and shortcuts after installation. These are modtly ux changes though 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
- Sir_Cmpwn 10y ago
  > symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?" 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.
  - formula1 10y ago
    I appreciate the inspirstion, I'll see to get started on it tonight. I was looking into fuse before which inspired much pf the filesystem shinanigans
- winter_blue 10y ago
  Several of the features you've described are present in mobile operating systems, like Android and iOS. For example, "the application can never touch os filesystem or know about other apps but themself and what the user allows" and "requests for hardware trigger permission dialog". Android and iOS both have this model. Most of what you've described can be implemented in the application layer, and don't require writing a new kernel, and the few others could be implemented with small patches to existing well-established kernels like Linux or FreeBSD. We've already got the infrastructure for the container-related features you've described, so implementing what you want is a matter of creating an system-level policy that allows applications to only run in containers and enforces the other restrictions you've described.
  - formula1 10y ago
    Many of the features are certainly inspired by mobile and docker and related technologies certainly it seem possible. 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
- JdeBP 10y ago
  Starting from scratch is one way to achieve this. But I suggest that you look into the GNU Hurd if starting from scratch seems daunting. Its potential is underused by the likes of Arch Hurd and Debian Hurd. One of the things that it can do is substitute user-supplied intermediaries, for just about anything, for selected processes.
kj01a 10y ago
It's fun.
- fuball63 10y ago
  OS class was one of my favorites in college, and I was recently reading about the MikeOS project and it really inspired me to try and do it again.
qwertyuiop924 10y ago
Well, for one thing, you can explore computing ideas and paradigms that fall outside the realm of UNIX. What if instead of a filesystem, there was a persistant collection of live objects (with attributes and functions and everything), like Smalltalk? How about a system where there's a unified abstraction for both network and local I/O, ala plan9? How about some new idea that hasn't been tried before? Maybe you'll find a better way of doing things.
- fuball63 10y ago
  This is where the education part is also helpful. It's been so long since I made a primitive OS that I wouldn't even know where to improve. But even some of the concepts in TempleOS are fascinating.
  - spc476 10y ago
    Well, there's Synthesis OS (http://valerieaurora.org/synthesis/SynthesisOS/ http://valerieaurora.org/synthesis/SynthesisOS/), a "just in time" operating system that can recompile itself on the fly to provide customized system calls.
    - qwertyuiop924 10y ago
      See? that's fascinating. My unix box handles the day-to-day, but the future is coming, and I can't wait.
      - spc476 10y ago
        That particular future has been around for 25 years.
        qwertyuiop924 10y ago
        That one has been, yes. Others have not.
    - 10y ago
rm445 10y ago
> Other than the educational value of doing so, what would be a reason to write a brand new operating system? 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.
- ktRolster 10y ago
  I quite like the idea that hardware intended for autonomy might benefit from being implemented on bare metal. 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 http://wiki.osdev.org/Projects
  - nickpsecurity 10y ago
    Two, older examples are RTEMS and eCos. RTEMS is basically a single application with some OS code linked in. eCos was interesting in that it let you delete what you didnt need out of the OS. JX is an interesting, modern example where the OS is mostly a microkernel, parts of drivers, and JVM. Everything else, including driver logic, is in the JVM and depends on developer's needs.

formula1 10y ago

I know Ive wanted to make changes to my own for a while. At very least default ui, menus and shortcuts after installation. These are modtly ux changes though 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

Sir_Cmpwn 10y ago
> symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?" 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.
- formula1 10y ago
  I appreciate the inspirstion, I'll see to get started on it tonight. I was looking into fuse before which inspired much pf the filesystem shinanigans
winter_blue 10y ago
Several of the features you've described are present in mobile operating systems, like Android and iOS. For example, "the application can never touch os filesystem or know about other apps but themself and what the user allows" and "requests for hardware trigger permission dialog". Android and iOS both have this model. Most of what you've described can be implemented in the application layer, and don't require writing a new kernel, and the few others could be implemented with small patches to existing well-established kernels like Linux or FreeBSD. We've already got the infrastructure for the container-related features you've described, so implementing what you want is a matter of creating an system-level policy that allows applications to only run in containers and enforces the other restrictions you've described.
- formula1 10y ago
  Many of the features are certainly inspired by mobile and docker and related technologies certainly it seem possible. 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
JdeBP 10y ago
Starting from scratch is one way to achieve this. But I suggest that you look into the GNU Hurd if starting from scratch seems daunting. Its potential is underused by the likes of Arch Hurd and Debian Hurd. One of the things that it can do is substitute user-supplied intermediaries, for just about anything, for selected processes.

kj01a 10y ago

It's fun.

fuball63 10y ago
OS class was one of my favorites in college, and I was recently reading about the MikeOS project and it really inspired me to try and do it again.

qwertyuiop924 10y ago

Well, for one thing, you can explore computing ideas and paradigms that fall outside the realm of UNIX. What if instead of a filesystem, there was a persistant collection of live objects (with attributes and functions and everything), like Smalltalk? How about a system where there's a unified abstraction for both network and local I/O, ala plan9? How about some new idea that hasn't been tried before? Maybe you'll find a better way of doing things.

fuball63 10y ago
This is where the education part is also helpful. It's been so long since I made a primitive OS that I wouldn't even know where to improve. But even some of the concepts in TempleOS are fascinating.
- spc476 10y ago
  Well, there's Synthesis OS (http://valerieaurora.org/synthesis/SynthesisOS/ http://valerieaurora.org/synthesis/SynthesisOS/), a "just in time" operating system that can recompile itself on the fly to provide customized system calls.
  - qwertyuiop924 10y ago
    See? that's fascinating. My unix box handles the day-to-day, but the future is coming, and I can't wait.
    - spc476 10y ago
      That particular future has been around for 25 years.
      - qwertyuiop924 10y ago
        That one has been, yes. Others have not.
  - 10y ago

rm445 10y ago

> Other than the educational value of doing so, what would be a reason to write a brand new operating system? 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.

ktRolster 10y ago
I quite like the idea that hardware intended for autonomy might benefit from being implemented on bare metal. 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 http://wiki.osdev.org/Projects
- nickpsecurity 10y ago
  Two, older examples are RTEMS and eCos. RTEMS is basically a single application with some OS code linked in. eCos was interesting in that it let you delete what you didnt need out of the OS. JX is an interesting, modern example where the OS is mostly a microkernel, parts of drivers, and JVM. Everything else, including driver logic, is in the JVM and depends on developer's needs.