Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An immutable operating system

augustl.com

Post reply on HN
Print view View original

41–50 of 153 posts

Re: An immutable operating system

#41

Post by eloff »

mhurron wrote: post #12
eloff wrote: post #6

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.

Sometimes 'toy of professors' (research) is the point. Not everything has to run a social network and not everyone is working on a twitter clone.

Oh I'd love to see him do it, because it would be a great research platform. Don't get me wrong. But that didn't seem to be the goal. Maybe I just interpreted the article wrong.

Re: An immutable operating system

#43

Post by masklinn »

optymizer wrote: post #34

This 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…

> they're essentially sharing data by copying the data.

No. Go only copies the immediate values, if you send a pointer the pointee is shared for instance. Go's concurrency is shared-memory.

Erlang copies (almost[0]) the data sent between processes, and has process-local heaps.

[0] binaries above 64 bytes (IIRC) are refcounted and shared.

Re: An immutable operating system

#44

Post by sehugg »

mtrimpe wrote: post #3

I gave an un-conference talk at Clojure days Amsterdam called "Purely Functional OS" on this exact topic and we had an incredibly interesting discussion about the topic. The conclusion we kept coming back to is that it's technically not all that difficult to implement, but that to make it usable in the real world would mean that computers would have to get a lot more cautious about source vs. derived data. The main t…

in the current state of technology it's impossible to determine what is derived data that can be easily recomputed and what is essential data without which the current state could not be recomputable.

Can you elaborate more on that statement? I see it as an expensive problem, but not impossible.

If you have a completely deterministic VM/instruction set, you can recompute any function output from any set of inputs. If you have non-deterministic input (network, input devices, randomness, etc) you can store those inputs to replay at a later time.

I don't know if it's always necessary to store non-derived data. Do you need to save all keystrokes? All mouse moves? All network packets? Probably not. If those network packets just result in displaying a graph on the screen, they can probably be thrown away. Maybe you can throw away the headers and just compute based on the packet data. Or maybe you can simply store the fact that a stream of data that matches a cryptographic hash was received. It depends on what function receives that non-derived data.

So I think the difficulty would be designing a system that would isolate derived data and replayable/recomputable/refetchable data, and the processes that compute that data -- and do so with reasonable efficiency. I think this could be done at the process level rather than the instruction set level (though you would have to have a restricted instruction set -- i.e. limited floating-point).

Re: An immutable operating system

#45

Post by ams6110 »

Sort of a sidebar: The term "atom" doesn't seem to have the same meaning in all languages.

Atoms in Clojure are reference types, and they are mutable in a controlled way (they can be changed to refer to another immutable value).

In Erlang, an "atom" doesn't refer an immutable value, it is the immutable value. An Erlang atom by definition cannot ever be any other value.

Re: An immutable operating system

#46

Post by augustl »

optymizer wrote: post #34

This 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…

Thanks a lot :) I cannot imagine that the web will ever work on this OS.. How do you implement a mutable system (JavaScript) with an immutable core? So it's definitely not for everyone.

Re: An immutable operating system

#47

Post by [deleted] »

pmr_ wrote: post #33
thinkpad20 wrote: post #2

I 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…

[deleted]

Re: An immutable operating system

#48

Post by justinpombrio »

stcredzero wrote: post #7

A 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…

Haskell's generational garbage collector is able to use some tricks to take advantage of the fact that values in Haskell are (almost all) immutable:

http://www.haskell.org/haskellwiki/GHC/Memory_Management

Re: An immutable operating system

#49

Post by lisper »

augustl wrote: post #19
RyanZAG wrote: post #14

Earlier quoted context omitted.

I don't see how immutability makes much difference to garbage collection. Garbage collectors don't look at the value inside memory they are collecting, only whether something live is still retaining that part of memory. Whether the value is mutable or immutable has absolutely no bearing on the performance or logic of the GC. Either something is still using the memory, or it is free to collect. Also you've just descri…

The actual GC of freeing memory is indeed possible (and common) without stop the world. Heap defrag is another story, though. This involves moving objects to different locations in memory, and if the memory is mutable, measures like stop the world is required since multi-byte move is not atomic.

Doesn't matter. In an immutable model, the old copy is guaranteed not to change, so you can safely copy it non-atomically. (That's one of the big benefits of immutability.)
Post reply on HN