51–60 of 92 posts
Does anyone know if there might be Arm support coming? This strikes me a a nice fit for some single board computers.
EDIT: here as well: https://mirage.io/docs/install maybe you need a Solo5 backend that can run on ARM; and finally: https://github.com/Solo5/solo5/blob/v0.6.3/docs/building.md#...
What is the benefit over using containers, as in Docker? Whether you use a container runtime or an actual hypervisor comes down to pretty much the same thing, operationally. Both keep your self-contained services alive and distributed. From the application perspective, a container also contains only those parts of an OS the app actually needs, and defers everything else to the host. The only caveat about MirageOS see…
Earlier quoted context omitted.
> 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.
In the kind of corporate environments I work on, you won't be doing any SSH into the production containers. Nothing that a classical UNIX admin would expect is installed on those images.
Earlier quoted context omitted.
Mirage is a unikernel. The catch here is Ocaml. You can design your unikernel "bare metal" in any way you want and make it do nothing but the essentials you need ... and design it in any language you want as long as that language is OCaml.
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
> Not sure what is the status of this project anymore
what the hell! :D last commit was 4 years ago!
Earlier quoted context omitted.
Isn’t this the same idea behind unikernels?
Mirage is a unikernel. The catch here is Ocaml. You can design your unikernel "bare metal" in any way you want and make it do nothing but the essentials you need ... and design it in any language you want as long as that language is OCaml.
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
Earlier quoted context omitted.
> 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.
In the kind of corporate environments I work on, you won't be doing any SSH into the production containers. Nothing that a classical UNIX admin would expect is installed on those images.
Though last I looked it wasn't nearly as mature as MirageOS.
Earlier quoted context omitted.
> 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.
In the kind of corporate environments I work on, you won't be doing any SSH into the production containers. Nothing that a classical UNIX admin would expect is installed on those images.
Earlier quoted context omitted.
In the kind of corporate environments I work on, you won't be doing any SSH into the production containers. Nothing that a classical UNIX admin would expect is installed on those images.
Yes. Welcome to the hell of "No debugging, no fixing anything. Call vendor support and hope for the best"