Related, a purely functional package manager, Nix, and a Linux distribution based around it: http://nixos.org/nix/
An immutable operating system
31–40 of 153 posts
Re: An immutable operating system
#32I've always been baffled by Clojure's view on state. It seems like just a rename of the concepts present in most languages today. Ie atom is mutable variable and value is an immutable value. What's the novelty here?
The sole fact that one has to reach over themselves and make a great deal to invoke it when thinking within Clojure's mechanics - they become neither cheap to mentally fiddle around with, nor actually implement within.
(FWIW, though, Clojure's novelty to me was an STM system that I could get up and running without a night's worth of tweaking, and otherwise fall safely into a great deal of attention if something were to go hilariously wrong - most of the other solutions around "back then" seemed to regard themselves as research curios lagging behind in fit and finish.)
Re: An immutable operating system
#33I don't really know how feasible this is without pretty significant performance impact (esp. memory usage), but as a research project, it sounds fascinating. Go for it.
> 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, networking, disk IO...).
Re: An immutable operating system
#34This idea reminds me of what Go is doing with their channels to solve concurrency issues: they're essentially sharing data by copying the data.
Copying data is slow and that's why Go's channels aren't the fastest solution, but they're less complex than dealing with the traditional concurrency issues.
I've written a toy kernel and I just can't imagine copying all process data because 1 little thing changed. However, there's no reason not to pursue this idea, as it may prove to be useful in certain cases. If real-time schedulers have their place, why wouldn't such an OS have its uses? I think Go (and other projects) have proved the concept works, so maybe it's time to see an OS?
Best of luck to you and I hope to hear good news in the future!
Re: An immutable operating system
#35Related, 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)Re: An immutable operating system
#36An 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.
As I mentioned elsewhere, such an OS could have important performance benefits. GC could be made to be incremental at a fundamentally new level. In fact, incremental GC could be nothing more than a series of defrag copies that proceed at a rate just faster than new object creation. Such a system would rock for writing real-time systems.
Important performance benefits compared to what? Systems that are very performance sensitive typically don't use garbage collectors to begin with. They instead rely on techniques to avoid generating much garbage in the first place.
Re: An immutable operating system
#37This idea reminds me of what Go is doing with their channels to solve concurrency issues: they're essentially sharing data by copying the data. Copying data is slow and that's why Go's channels aren't the fastest solution, but they're less complex than dealing with the traditional concurrency issues. I've written a toy kernel and I just can't imagine copying all process data because 1 little thing changed. However, t…
Is it copying all process data? Or copying a reference to the process data and then performing copy-on-write when a process makes changes locally?
Re: An immutable operating system
#38I don't really know how feasible this is without pretty significant performance impact (esp. memory usage), but as a research project, it sounds fascinating. Go for it.
> 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 is probably not even aware of those problems, and will hit a wall when he realizes his new OS has to deal with one of those issues -- and that's assuming he even gets far enough in his project to deal with scheduling or IO. Writing your first operating system is an especially challenging task even when you're not trying to revolutionize the traditional OS model.
I don't suppose this project will actually go anywhere, though I'd be pleasantly surprised to be wrong.
Re: An immutable operating system
#39A garbage collector that knows that all values are immutable will be rather interesting, I think. Typically, a garbage collector will stop the world (i.e. halt execution) to do heap defragmentation of the old generation. When all values are immutable, though, you can defragment the heap by copying a value to another fragment and just swap the internal pointer to the value. This might actually have significant perform…
> This might actually have significant performance benefits.
Not really. On the other hand, it makes the implementation of GCs much simpler.
(immutability semantics also tends to make memory churn much higher, so what little gain you get from a simpler implementation is often lost in the GC having to do more work)
Also, it's not like these things are unstudied FFS.
Re: An immutable operating system
#40An 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.
An operating system whose main goal is not performance is forever going to be a toy of professors.
Be careful! That statement was once true of programming languages.
Over time, larger and larger numbers of people relaxed their expectations for performance in exchange for benefits like greater safety. Simultaneously, implementors invested in optimizing the performance of languages previously considered "slow."
Operating systems may well wind up with the same dynamic.