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

Mirage – A programming framework for building type-safe, modular systems

mirage.io

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Mirage – A programming framework for building type-safe, modular systems

#81

Post by samuell »

mk89 wrote: post #54
samuell wrote: post #33

Earlier quoted context omitted.

And on that note, I just found this list of UniKernel projects: http://unikernel.org/projects/ I have especially had hopes for the UniK [1] project, as it was/is written in Go AFAIK. I see now it incorporates work from the Mirage project as well. Not sure what is the status of this project anymore though. [1] https://github.com/solo-io/unik

I didn't read your message, so I just clicked and I found that great nice project from Solo.io (the company behind Gloo Edge, etc.). Freaking awesome... I thought: > Not sure what is the status of this project anymore what the hell! :D last commit was 4 years ago!

Hah, yea, should have checked that :D ... but yea, I stopped hearing news from solo.io / UniK some time ago, so it makes sense.

Re: Mirage – A programming framework for building type-safe, modular systems

#82

Post by Veserv »

naasking wrote: post #78
Veserv wrote: post #72

Earlier quoted context omitted.

That is just infinitely worse than calling write() on a file handle like a regular application. The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all. The only reaso…

> The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary. That's wrong. They rightly believe that traditional operating systems deployments come with much larger attack surfaces.

There is no meaningful security difference between commercial operating systems and hypervisors when considering technically competent, commercially-motivated attackers. No systems built on such insecure systems can stop even minor attacks staffed by a single-digit number of FTEs. Maybe there is a material difference, but it is irrelevant compared to their total inadequacy relative to the present threat landscape. The person who can climb Mount Everest is still no closer to achieving orbit than the person who can only climb a tree.

To move beyond the mere practical aspects, even theoretically you are wrong. The techniques needed to develop a secure hypervisor are basically exactly the same techniques needed to develop a secure operating system. They are almost trivially transferrable. If you can do one, you can do the other. So, again, no advantage to preferring a hypervisor based solution.

Re: Mirage – A programming framework for building type-safe, modular systems

#83

Post by pjmlp »

datadeft wrote: post #35
v1ne wrote: post #8

I'm really sold on the idea: Instead of a full-blown OS, you compile your application with a thin layer of support libraries that provide the OS features that your application needs (network, I/O) and that talks to a hypervisor. I mean, if your application runs in a virtualized environment, there's little need to SSH into the system in the first place (except for debugging purposes). Thus, why bother with a full-blow…

> I'm really sold on the idea: Instead of a full-blown OS, You mean you are sold on the idea of going back to the 80s. We used to have an operating system with every game released[1]. 1. https://youtu.be/kZRE7HIO3vk?t=1114

Well, that is kind of what the maker community is doing with Arduino and ESP32, and what makes them much more interesting to hack around, as yet another UNIX clone.

Re: Mirage – A programming framework for building type-safe, modular systems

#84

Post by naasking »

Veserv wrote: post #82
naasking wrote: post #78

Earlier quoted context omitted.

> The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary. That's wrong. They rightly believe that traditional operating systems deployments come with much larger attack surfaces.

There is no meaningful security difference between commercial operating systems and hypervisors when considering technically competent, commercially-motivated attackers. No systems built on such insecure systems can stop even minor attacks staffed by a single-digit number of FTEs. Maybe there is a material difference, but it is irrelevant compared to their total inadequacy relative to the present threat landscape. Th…

Even if I accepted the claim that the techniques are the same, it's irrelevant. It's simply a matter of fact that standard installs of commodity server operating systems have a significantly larger attack surface than a unikernel system. Sys loggers, email agents, inflexible and insecure user/group access control, and just general ambient authority. Unikernel systems have none of this cruft by default.

Re: Mirage – A programming framework for building type-safe, modular systems

#85

Post by FridgeSeal »

rapsey wrote: post #14
v1ne wrote: post #8

I'm really sold on the idea: Instead of a full-blown OS, you compile your application with a thin layer of support libraries that provide the OS features that your application needs (network, I/O) and that talks to a hypervisor. I mean, if your application runs in a virtualized environment, there's little need to SSH into the system in the first place (except for debugging purposes). Thus, why bother with a full-blow…

> there's little need to SSH into the system in the first place (except for debugging purposes). Pretty big except though. This concept has been done multiple times and has always failed. It's solving a problem that few care about.

I haven’t SSH’d into a machine/container to debug or fix a production issue in years. You flat out can’t even SSH into anything on the last few prod setups I’ve worked on: permissions prevent it, and most containers have sshd and friends stripped out.

I would love a super slimmed down stack to run workloads on. Most of the time when I run workloads, I want to run the workload and nothing else. The OS in the container exists to start the binary I care about and then basically very little else-these applications aren’t making use of a scheduler, or the init system (because again, I’m only running my binary), users and permissions go unused a good chunk of the time. With stuff like quic becoming more popular we’ve got user space networking too, so that’s out. So by this stage we’ve got a whole OSCthats doing almost nothing except passing stuff between layers an incurring a performance and risk overhead.

If we could have the same functionality, with better performance and the same or better security, why wouldn’t I do that?

> This concept has been done multiple times and has always failed

Isn’t it likely that this idea was just “before its time”? The compute landscape these days is pretty different to ~20+ years ago: massively available public cloud compute, prolific container usage, etc. Software stacks are deeper, more ossified and less fully understood than ever, I definitely see solutions that reduce that complexity being appealing.

Re: Mirage – A programming framework for building type-safe, modular systems

#86

Post by pjmlp »

dontlaugh wrote: post #46
pjmlp wrote: post #45

Earlier quoted context omitted.

I not always agree with Rob Pike, but this one is a must. "We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of l…

Ironic, considering how many "different, great ideas about computing" Pike wilfully ignored in the development of Go.

I agree, I came to realise that the end goal was to get Limbo a face lift.

So we didn't got Inferno, rather Limbo in new clothing, which still does dynamic loading much better than Go.

Re: Mirage – A programming framework for building type-safe, modular systems

#87

Post by dontlaugh »

pjmlp wrote: post #86
dontlaugh wrote: post #46

Earlier quoted context omitted.

Ironic, considering how many "different, great ideas about computing" Pike wilfully ignored in the development of Go.

I agree, I came to realise that the end goal was to get Limbo a face lift. So we didn't got Inferno, rather Limbo in new clothing, which still does dynamic loading much better than Go.

We could’ve gotten something more like a simpler Swift if some attention was paid to state of the art in language research and implementation. No nil, composable errors, integrated generics, sum types, etc.

Re: Mirage – A programming framework for building type-safe, modular systems

#88

Post by pjmlp »

dontlaugh wrote: post #87
pjmlp wrote: post #86

Earlier quoted context omitted.

I agree, I came to realise that the end goal was to get Limbo a face lift. So we didn't got Inferno, rather Limbo in new clothing, which still does dynamic loading much better than Go.

We could’ve gotten something more like a simpler Swift if some attention was paid to state of the art in language research and implementation. No nil, composable errors, integrated generics, sum types, etc.

If you like language archeology, compare K&R C with the state of systems programming languages outside Bell Labs, in regards to safety and language features, since JOVIAL was introduced in 1958.

Hence why there is a certain irony towards the opinion UNIX is done, yet the efforts towards language design are as they are.

Plan 9, Inferno and Limbo came to be, and that was it.

Re: Mirage – A programming framework for building type-safe, modular systems

#90

Post by ekianjo »

fhuici wrote: post #79
ekianjo wrote: post #7

Is that similar to Firecracker?

No, though you could use Firecracker to launch a Mirage (or any other) unikernel. Basically from the bottom up the stack is: 1. Hypervisor (e.g., KVM, Xen, Hyper-V), runs directly on the hardware 2. Virtual Machine Monitor (e.g., QEMU, Firecracker), running on the host's user-space (say Linux) and in charge of starting/stopping/managing VMs and interacting with the hypervisor 3. Virtual machines, eg, a Linux VM runni…

Thanks for the explanation!
Post reply on HN