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

141–150 of 153 posts

Re: An immutable operating system

#141

Post by vidarh »

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.

We're running everything on our own fully owned colocated servers, yet we're running everything in virtualised environments. Private clouds are attractive for many of us because of the management benefits of being able to use a VM as the unit of deployment. It also makes sense to increase isolation, as colo space is expensive enough to justify servers that are much more powerful than many of the apps we run needs (our typical new setups start at 16-24 cores these days, and I expect that to be 32-48 cores by year end), so we want to co-locate many apps on the same servers but don't want them to able to interfere too much with each other.

In fact, we have some systems where things are even deployed in containers inside VMs for various reasons...

Re: An immutable operating system

#143

Post by lukego »

dzderic wrote: post #105
lukego wrote: post #59

Earlier quoted context omitted.

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

Packets between internet hosts spend about 10,000,000ns in transit and they traverse around $10,000,000 worth of network elements on the path. These numbers are both worth optimizing. I'd say that the lowest hanging fruit for operating system hackers like myself is the cost i.e. serving more customers with fewer boxes. That latency figure is tougher because it's mostly due to the speed of light rather than processing time.

Re: An immutable operating system

#144

Post by yvdriess »

gohrt wrote: post #89
augustl wrote: post #57

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.

Haskell

The current Haskell execution engine is very imperative indeed.

Instead of graph reduction, you could drive your execution in a completely immutable way by using string reduction. I don't think this has been explored much, I only found mention of it in 80s FP books (and Dybvig's thesis).

Re: An immutable operating system

#145

Post by stcredzero »

cgrand-net wrote: post #140
1amzave wrote: post #133

Earlier quoted context omitted.

> immutable structures can't create cycles Perhaps I'm misunderstanding something, but doesn't "tying the knot" in Haskell do just that? (Create a cycle from immutable structures.)

Tying the knot is possible only if you have pervasive laziness.

Which is precisely why an immutable OS that's Clojure all the way down might be desirable.

Re: An immutable operating system

#146

Post by im3w1l »

sbierwagen wrote: post #112
dzderic wrote: post #105

Earlier quoted context omitted.

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.

Accidentally clicked on the wrong icon and downvoted you, sorry, my bad.

I gave a corrective upvote :)

Re: An immutable operating system

#147

Post by ansible »

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…

Network switches don't handle most packets at the OS level, but in hardware.

Re: An immutable operating system

#148

Post by sitkack »

stcredzero wrote: post #86
barrkel wrote: post #29

Earlier quoted context omitted.

Generational GC usually depends on write barriers to detect creation of references to newer generations inside older generations. Immutability prevents the mutation of older generations, so no new references can occur. So I expect generational GC to be easier to implement. I wouldn't expect it to be faster or slower though, because programs will need to be written differently to cope with the limitations on mutabilit…

In the case of Clojure, log is log base 32, so it's close enough to O(1) as to make no difference in most circumstances.

But the constant factor is Z, a very large number. A number so large it has a color and name. It pays taxes, has lunch and sees movies on the weekend.

Re: An immutable operating system

#149

Post by cgrand-net »

stcredzero wrote: post #145
cgrand-net wrote: post #140

Earlier quoted context omitted.

Tying the knot is possible only if you have pervasive laziness.

Which is precisely why an immutable OS that's Clojure all the way down might be desirable.

I don't get if you imply that Clojure has pervasive laziness or not. The contract of lazy sequences is too loose to make tying the knot not a brittle hack -- and I think it's a good thing.

Re: An immutable operating system

#150

Post by stcredzero »

cgrand-net wrote: post #149
stcredzero wrote: post #145

Earlier quoted context omitted.

Which is precisely why an immutable OS that's Clojure all the way down might be desirable.

I don't get if you imply that Clojure has pervasive laziness or not. The contract of lazy sequences is too loose to make tying the knot not a brittle hack -- and I think it's a good thing.

I'm referring to the article. The Clojure inspired OS would, I suspect. If no one has referred to the unrefined parts, what would be the problem?
Post reply on HN