Would be wiser to only change one variable at once...
Prove that an existing RTOS style library can be written with a simple scheduler working well.
That would go a long way to it gaining adoption in the embedded world, show that traditional solutions work correctly with the new language first.... then move on to an innovative OS.
Sometimes you have to go top to bottom. I think that Alan Kay says something along the lines that you should start with the design of the API. Polya say something similar in how to prove it.
Polya says to start from the solution. The problem is you have to know a definitive solution for this to be applicable.
In the case of this hypothetical OS idea.... Most of what people "would want" from an OS is a made up thing they can't really express. There is no working backwards from a generalization. You work backwards from concrete ideas.
Realistically, the OS everyone wants is "one that runs all of their software." They would prefer one that "doesn't crash." However, starting over with no real software is a non-answer.
Unfortunately the requirement of "one that runs all of their software" is the one that means that most new os's are posix/unix clones of some variety. There is too much human effort invested into the posix userspace for us to start from scratch. In fact even Microsoft seems to be struggling with this inspite of their entrenched position.
So the solution is Unix or (God help us) Win32 forever? I think the nature of the unix user space is one of the things that could stand improving. How about doing something a bit more structured than piping bytes (ascii? UTF8? Latin1? Some binary format? Who knows!) around? Or making tools that don't run in one-shot mode when that's not how they're used (compilers, etc.)?
This need not throw everything away that we have today. Why not make the equivalent of higher level bindings over a C API for command line programs? Or maybe any of a hundred other options that might improve over what we have now? Is unix really the end stage evolution for user space?
> So the solution is Unix or (God help us) Win32 forever? I think the nature of the unix user space is one of the things that could stand improving. How about doing something a bit more structured than piping bytes (ascii? UTF8? Latin1? Some binary format? Who knows!) around? Or making tools that don't run in one-shot mode when that's not how they're used (compilers, etc.)?
The solution is incrementally improving these things. What you're talking about is absolutely the kind of thing I'm interested in. Arguably PowerShell is one piece of the right direction. Show me a better way with compilers etc. and I'm interested (I work in Scala and compile time is a big issue, but I couldn't stand to have SBT as my framework).
> This need not throw everything away that we have today. Why not make the equivalent of higher level bindings over a C API for command line programs? Or maybe any of a hundred other options that might improve over what we have now? Is unix really the end stage evolution for user space?
If you've got a way to introduce one of those things incrementally, I'm interested.
I'm (very slowly) working towards having time to build the hobby OS I've been dreaming about for years. I've been especially inspired by Plan 9, BeOS, and seL4. I love simple, powerful things.
At this point, any new OS that wants to breaks away from Unix/Windows and hopes to gain mass adoption, will need to come with an Unix/Windows emulation layer built-in.
> Realistically, the OS everyone wants is "one that runs all of their software."
I want an OS that's easy to program to the point I don't actually have to rely on third party software too much. This might be a pipe dream but I'm not convinced it's not achievable on some level.
> They would prefer one that "doesn't crash." However, starting over with no real software is a non-answer.
I'm trying to open a discussion about what ideas have been tried in the past, seem good, but for one reason or another didn't catch on.
Why would I even want that? Like, seriously. How much of the computer could I even make? I even studied this stuff in school and understand the basics. Somewhat beyond the basics, actually. Still, I would have zero capabilities to make my own.
Move that to other areas. My car? Forget about it. I could have a fighting chance at building a bike. However, to build a good one, not a chance.
So... why is this something that is even desirable in the computer?
Now. Do I want to be able to fix what I can? Of course. I run emacs, in part because I like that I can pull up the source, quite easily, of any component I am using. I still rely majority on code written by others. And have no shame or concern in doing so.
> Still, I would have zero capabilities to make my own.
That's the point, you don't have much capability to alter the OS you are running. But you should. It's not unachievable but the languages, tools and OS (and maybe HW) have to come together to allow for this.
> Move that to other areas.
Computer is different from any of those since it's fundamentally a machine to model human mind. I always feel like my OS is somewhat restrictive as to what it lets me to do easily and what alterations it lets me to make.
> Now. Do I want to be able to fix what I can? Of course. I run emacs, in part because I like that I can pull up the source, quite easily, of any component I am using. I still rely majority on code written by others. And have no shame or concern in doing so.
Right. But the languages and tools that we use currently don't lend themselves to terseness and correctness. I think that that's the direction of future languages.
I disagree. It is very easy for me to modify Linux. I just don't have the skills to do deep modifications. I used to compile my own kernel. Even made modifications to it. None were worth keeping.
And i don't think languages really help here. Given that many advanced languages have products that are, again, beyond me.
Directly, what sorts of edits do you wish you could do, but feel prevented from doing?
> I disagree. It is very easy for me to modify Linux. I just don't have the skills to do deep modifications.
Part of this is that setting up a development environment is kind of tricky.
> And i don't think languages really help here.
They really do actually.
> Directly, what sorts of edits do you wish you could do, but feel prevented from doing?
Imagine an OS where you can do something like "view source" with html, you can edit it, and immediately re-execute it. I think that the list of things I wouldn't look into tweaking would be shorter.
Emacs basically has this. It is why I mentioned it. There are a set of functions that are compiled c code, but the majority of emacs is just a click away from my looking at it and modifying if I wanted to.
And that is the thing, I rarely want to. Or, I'll want to, but it isn't easy enough to do that I can get it done. Often, the thing I would like to do is a melpa install away. And the amount of code involved with many features is far beyond my skillset, it usually seems.
Prove that an existing RTOS style library can be written with a simple scheduler working well.
That would go a long way to it gaining adoption in the embedded world, show that traditional solutions work correctly with the new language first.... then move on to an innovative OS.