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

101–110 of 153 posts

Re: An immutable operating system

#101

Post by agumonkey »

cfallin wrote: post #80
agumonkey wrote: post #35

Earlier quoted context omitted.

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)

Mutability/immutability goes pretty deep philosophically... all of those projects are basically built on persistent data structures, but persistent data structures can be seen as just one type of "making time explicit". In other words, with mutability, a variable (or data structure) takes different values at different times, while with immutability, you can still have time but you name each version through time expli…

How could I forgot SSA. The idea here is what about re-expressing things by pushing immutability at lower level as a common base.

Re: An immutable operating system

#102

Post by vinkelhake »

stcredzero wrote: post #83
vinkelhake wrote: post #36

Earlier quoted context omitted.

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.

You're making my point for me here. This kind of technology might make it possible to write even more performant soft real-time systems but still have the productivity benefits of GC.

I don't think I am. Trading performance for productivity is completely different discussion. It sounded like the claim here was that immutability in the OS (whatever that means) might result in a system with better performance.

We have programming languages where everything is immutable (Haskell). This results in programming techniques that generate a lot of garbage. We have not seen that this results in programs with better performance than those that do not generate garbage to begin with. Why would it be different in an operating system?

Re: An immutable operating system

#104

Post by cwp »

userbinator wrote: post #96
_delirium wrote: post #23

Earlier quoted context omitted.

I think this is becoming less true: people are willing to trade off performance for safety and flexibility, given the right circumstances. For example, running everything inside of virtualized Linux instances is less performant than running in bare-metal Linux, but virtualization is nonetheless taking off like crazy.

> but virtualization is nonetheless taking off like crazy. I think that's more due to hosting providers being able to sell far more "machines" than they have hardware for.

Ok, so people are willing to trade off performance for safety, flexibility and price.

Re: An immutable operating system

#105

Post by dzderic »

lukego wrote: post #59
procrastitron wrote: post #54

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…

> For an operating system latency is more important than through put One interesting exception to this rule is operating systems for network packet routers. These need to be optimized for throughput over latency. I mean, the difference between 10 and 20 million packets per second is important, but the difference between 10 and 20 microseconds of processing delay is not. This is a fun area to be in at the moment becau…

When you're talking about an average latency of single digit us for a regular switch and < 500ns for a low-end performance switch, the difference between 10 and 20 microseconds is massive.

Re: An immutable operating system

#106

Post by augustl »

timclassic wrote: post #84

I haven't written any Clojure, but I have written a good bit of Erlang. My understanding of the Erlang Virtual Machine tells me that it solves a lot of the problems you describe regarding immutable data. For example, per-process garbage collection due to immutability, message passing via copying data, etc. I think you would be well-served to experiment with and learn some Erlang to help inform your design. In fact, E…

I'm an Erlang noob, but afail the model is pretty different. I'm imagining a shared-everything system, where immutable values are freely passed around with no copying. Erlang is more of a shared-nothing system. Also, Erlang requires multiple machines to shine, but an OS is more about managing one machine.

I do think message passing have a bright future, though, and my OS will not work at all in a shared-nothing manycore system..

Re: An immutable operating system

#108

Post by banachtarski »

sillysaurus2 wrote: post #76
procrastitron wrote: post #54

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…

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

throughput != latency

Re: An immutable operating system

#109

Post by lmm »

cwzwarich wrote: post #85
sillysaurus2 wrote: post #76

Earlier quoted context omitted.

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

Tracing garbage collection has better throughput than reference counting, but reference counting has lower and more predictable latency. If you were actually going to try do tracing GC on the operating system level, you would probably have to use one of the more involved GC algorithms that require kernel support like Azul's C4 collector.

> you would probably have to use one of the more involved GC algorithms that require kernel support like Azul's C4 collector

Which shouldn't be such a problem if you're already writing an OS?

Also AIUI the only "hard part" of C4 is making sure objects don't get modified while they're being moved (that's what the barrier's there to detect) - which isn't a problem if everything's immutable.

Re: An immutable operating system

#110

Post by iElectric2 »

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…

We actually solved that problem and purely functional distribution exists, its called NixOS
Post reply on HN