What are the implications of the AGPL license for this (if any)?
my understanding is that you can't sell this cloud as a service (AWS would not be able to use it)
Sure they can, they just have to make the code available that is in what they deploy.
Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
91–94 of 94 posts
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#92Earlier quoted context omitted.
> mount the filesystem of box2 in a folder on box1. This is not possible due to the CAP theorem. (You will need to severely rethink your concept of "file" at the very least.)
DEC did it 40 years ago.
"It" doesn't really work in practice, which is why nobody uses it in production settings.
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#93Earlier quoted context omitted.
It wouldn't be a bad thing if people learned from the previous iteration. But they don't. In fact, what they generally do is layer an implementation of the stuff they forgot last time on top of the preceding iteration which lacked it. So now, we have clusters of Linux boxes, built with a ton of new tooling on top of Linux because Linux is a UNIX and traditional UNIX doesn't have networking or clustering in the design…
> Go on, then, 2 PCs on a LAN, both running a bare Linux kernel and a shell for init. Call them box1 and box2. Tell me how you mount the filesystem of box2 in a folder on box1. Running /bin/sh on a bare kernel isn't a unix system. A unix system has daemons, at which point we get enough supporting tooling to make use of the very much built into the kernel NFS and 9P support and mounting files from one machine to anoth…
> Running /bin/sh on a bare kernel isn't a unix system.
That's true and you're right.
However, what I was specifically discussing here is core kernel functionality versus layering it on top, and for that, I had to describe things in an artificially simplistic way, because Linux folks tend to think Linux invented everything and is everything and start to go on about in-kernel Ethernet drivers and in-kernel NFS and so on and because they get busy counting trees, they miss the fact that they are lost in the forest.
I am not advocating the use of bare kernels here. I am not saying this is a rigorous or fair comparison.
What I am trying to demonstrate is the fundamental difference between having networking and a networked system as core parts of your system design, as opposed to bolted on later.
It's integral in Plan 9. Whereas Linux is a UNIX, and therefore must implement things later on top of a core design which assumes that all machines are standalone multiuser minicomputers with dumb text terminals.
This is such a fundamental part of the design of Unix that it is everywhere and it's very hard to show to Unix users that it's there... because it's the material of the walls, the floor, the ceiling and the door and so it's hard to see.
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#94Earlier quoted context omitted.
It wouldn't be a bad thing if people learned from the previous iteration. But they don't. In fact, what they generally do is layer an implementation of the stuff they forgot last time on top of the preceding iteration which lacked it. So now, we have clusters of Linux boxes, built with a ton of new tooling on top of Linux because Linux is a UNIX and traditional UNIX doesn't have networking or clustering in the design…
Features are backed by code. The code has to exist somewhere, in previous systems it ran as ring0. Is this where you want your privesc ?
This is missing the point.
The point is that if functionality is core to what you are doing with your OS, then it ought to be a core part of that OS and not layered on top.
If that would make the kernel of your OS too big and too complex then the design of your OS is wrong.