Idea for an OS design - feedback appreciated

[Maddie]

I was thinking of a unique way to make an operating system, because nobody wants another boring UNIX clone. I've come up with an idea that I quite like:

• my OS (name pending) will have a microkernel, with different parts of the system (drivers, memory management, parts of the scheduler, etc) running as daemons

• each daemon will have a respective program to interface with it, and control that part of the system

• most user programs will be scripts that call these interface programs to do stuff, although the interface programs can be called from the shell or through system calls

• this approach will make all programs do things in the same way, avoiding solutions to problems that work, but aren't very clean, elegant, or user-friendly (see UNIX)

I'd like to hear the forum's thoughts on this design, and maybe hear the advantages or disadvantages of it.

[bloodline]

That basically describes my own OS, and most other Microkernel OSs

[Maddie]

It's unique in that all user programs will be bash-like scripts that only call the interface programs, I don't plan to port GCC for this reason, although I may port NASM.

[bloodline]

It's unique in that all user programs will be bash-like scripts that only call the interface programs, I don't plan to port GCC for this reason, although I may port NASM.

I'm not sure what advantage this offers? You will pay a large performance, memory and security penalty, for no good reason.

[Maddie]

I think it would be cool

Also, why would it not be as secure? If anything , wouldn't it be more secure because everything is done through interface programs?

[bloodline]

I think it would be cool

Also, why would it not be as secure? If anything , wouldn't it be more secure because everything is done through interface programs?

Thinking it would be cool, is a very good reason to make it! I thoroughly support this approach

But you asked for comments and I don’t see any advantages… Unix with a decent shell offers this functionality already.

[bloodline]

So the only real advantage I can think of is that you can build an complete “user space” environment to run under your OS of choice which might help speed development and testing of that side of it.

[rdos]

It's unique in that all user programs will be bash-like scripts that only call the interface programs, I don't plan to port GCC for this reason, although I may port NASM.

Bash basically IS UNIX, so you are just writing another UNIX clone that only works with UNIX scripts.

[Ethin]

If you don't port GCC (or a compiler in general) how are you going to port any programs? Unless of course you plan to write a compiler for every single language that you want your OS to support? (Good luck doing that in shell scripts... I imagine that would be an utter nightmare.)

[bloodline]

If you don't port GCC (or a compiler in general) how are you going to port any programs? Unless of course you plan to write a compiler for every single language that you want your OS to support? (Good luck doing that in shell scripts... I imagine that would be an utter nightmare.)

That’s a really good point! Porting software would be next to impossible… while my own OS isn’t a UNIX I will try to have as much of the standard C libraries and make it POSIX compatible where it makes sense to do so (i.e. filesystem access), just to make the porting of software viable (if not easy).

[Maddie]

I don't plan to port any software, aside from possibly NASM. porting software would be for another project.

[bloodline]

I don't plan to port any software, aside from possibly NASM. porting software would be for another project.

As I said, I think it would be a totally fun project and encourage you to do it. But remember that without any software an Operating system (which is essentially just a hardware abstraction layer) is pointless.

[eekee]

• most user programs will be scripts that call these interface programs to do stuff, although the interface programs can be called from the shell or through system calls

I love this part! I'd say the more you can put in scripts, the better. I used Plan 9 & 9front for years, wrote many scripts and script wrappers, but when I couldn't do something without modifying the C code, I was often totally stumped. I couldn't follow those geniuses code.

Another thing I learned from Plan 9 is you can have a scripting language with a syntax which is both simpler and more powerful than Bourne shell. It's called rc. I found it much easier to learn than Bourne shell, and its native lists are a Good Thing. On the negative side, it has very little built in and I got tired of piping data through the various shell utilities; they're all different languages and you often have to watch your word separators on both ends of the pipe. I would have very much liked a somewhat more complete scripting language, but not too complete. Languages like Python have got too serious; they're not so much fun any more. Anyway, here's a rc man page. (The bi-directional pipes are specific to Plan 9, if I remember right.)

Not commenting on the other points because it's been months since I thought about those systems. I've forgotten stuff. I set my sights very low and then my health quashed even those hopes. I've got hopes regarding my health though.