71–80 of 153 posts
Why make the system language a Lisp instead of a language that is by default immutable? I'd think Haskell is a shoe in for something like this and you'd have a head start with House: http://en.wikipedia.org/wiki/House_(operating_system)
I'm not sure how this would look very different from current pure functional languages. Think about programming in Haskell. Everything is immutable but you can compile down to machine level binaries. So at some point the programmer is presented with an abstract immutable model and under the hood some runtime does real pointer arithmetic and all. Even garbage collectors could be optimized already for knowing that the…
Earlier quoted context omitted.
The author could focus on an existing embedded RTOS and fork from there. Enough cherries to pick one.
But is he going to find one that follows his "all has to be immutable" approach? I somewhat doubt it. Do you know of any existing OS that works like what the author describes?
For example, there are discussions in the RTOS world to take a closer look at Rust (Google embedded Rust) which is why the terms "new OS", "GC" and "experimental" triggered my response to look over there for a starting point.
Earlier quoted context omitted.
> don't really know how feasible this is And I suspect neither does the author. I looked at the previous project (OpenGL Renderer) which comes in at 250 lines of code and barely any functionality. The current project is has no code at all. I'm all for sharing ideas, but this is somewhat lacking. The design document touches on the memory model, but ignores all the other problems an OS has to solve (scheduling, network…
The author could focus on an existing embedded RTOS and fork from there. Enough cherries to pick one.
I wrote an operating system in a purely functional dialect of Lisp; http://losak.sf.net There are a few things I learned in the process that I think are relevant here: 1. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant…
Is the assumption that mark and sweep is slower than real-time memory management? It's actually been proven false, e.g. the .NET CLR runs faster than native C code in certain situations.
If you use reference counting, then there is a lazy variant that gives you just that; no pauses due to reclaiming free memory.
Reference counting is extremely slow because of how memory caching works. Whenever you update reference counts, you're trashing the CPU cache. It seems like there's no way refcounting could be faster than mark and sweep due to this. What am I missing?
An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.
The goal of Linux was not performance, it was to create a free OS. The fact that it has become a high quality performant OS is a side-benefit (driven by external commercial factors, much later in its development timeline).
Also, Linux found a niche, and stopped being a toy very early, much before people started really caring about performance.
Earlier quoted context omitted.
Author here. The language is the part I also dread the most, and is also the part that will be the least unique and the least interesting to "re-invent".. I'll look into finding an existing language that runs on bare metal and that has (or supports) immutable values.
Rust?
An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.
Related, a purely functional package manager, Nix, and a Linux distribution based around it: http://nixos.org/nix/
I see a number of projects sharing similar traits: - DVCS - btrfs,zfs - rethinkdb - persistent datastructures (cons cells, fp trees) - nix package management, virtualenv, containers - react/pedestal (pushing ux delta upgrades)