Live data from Hacker News

Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

phoronix.com

61–70 of 94 posts

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#61
post #19

Earlier quoted context omitted.

As much as I love Plan 9 and Inferno, the reason why they never were a commercial success is because they deliberately broke backwards compatibility with UNIX. (Which was an excellent choice for Plan 9 as a research OS, but perhaps should've been reconsidered for a commercial offering.) They did however accomplish pushing the "UNIX 1.0" into at least 1.1: as awkward as Linux's /proc is, it's still objectively better…

> Linux's /proc is [...] still objectively better than sysctl Is it though? AFAIK there is no way to get an atomic snapshot of the contents of /proc so any attempt to traverse the tree will be met with "No such file or directory" errors as processes end. You can reproduce this with a simple: doas find /proc -name pid -exec cat {} \; Whereas sysctl returns a consistent snapshot of the data requested.

My point is about the elegance of using open/read/write/close (the mantra of Plan 9) versus going through a complex interface full of constants defined in a C header file.

A bunch of shell commands stitched together is the wrong level of abstraction for taking atomic snapshots of anything. Even "ls | xargs cat" suffers from the same problem: ls might output the name of a file that gets deleted or renamed before cat can open it. You'd need to mount a filesystem read-only, or take a snapshot (on e.g. ZFS). You can however use openat(2), which should in theory at least guarantee that if dirfd=open("/proc/123", ...) succeeds, then openat(dirfd, "pid", ...) will not race against another process reusing the same pid.

PIDs being racey by nature is why Linux introduced pidfd_open(2) and friends.

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#62
post #8

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

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

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#63
post #55
post #51

I tried very hard to get onboard with Ubuntu's new server paradigm, I've been using Ubuntu on and off since 2005. Snap is what turned me away. My research (admittedly several years out of date) told me that it was impossible to disable 'auto-updating' of Snaps. Now I see that they're rolling out what is apparently a high availability service built on services deployed through Snap. I don't see how this is viable, if…

This changed a while ago. See "Pause or stop automatic updates" at https://snapcraft.io/docs/managing-updates

Cheers! A step in the right direction.

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#64

Earlier quoted context omitted.

Good choice. FreeBSD and jailed bHyve cells for me.

It's been a few years since I've looked at bhyve. Is it maturing well? Are there any tools that make managing it easier now?

Very stable. Libvirt is supported. So you can now use a GUI [0] [1]

There's a few web control panels too if that's your thing.

I can't fault it. A bit rough round the edges and manual in some places but as expected. Has tackled everything I've thrown at it from Windows Servers to Linux, VPNs to Routers all very well.

You won't get the bells and whistles of an enterprise hypervisor, however for a Tier-2 hypervisor, it's smooth sailings.

[0] https://people.freebsd.org/~rodrigc/libvirt/virt-manager.htm...

[1] https://libvirt.org/drvbhyve.html

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#65
post #4
post #2

So.. we’re back to self-hosting your own services? And IT does another cycle.

We never really left. I work with an enterprisey on-prem product, which we of-course tried to replace with a cloud offer. And in all fairness, it's generally gone well - but because we manage the platform, it sits in the cloud we chose. And that's never going to be the right choice for everyone. So we have some customers who are concerned about national boundaries. We have some customers who offer their own clouds, a…

> It's a minority of customers, but it turns out to be a very valuable minority.

I've been saying this for years. The Ubuntu vision here is appealing: storage and live migration as first class things, because many high value services are never going to be "cloud native," easily scheduled, stateless, ephemeral container apps: the stuff k8s et al. was designed for.

So they have the right model. Now it's down to execution.

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#66
post #8

Earlier quoted context omitted.

> And IT does another cycle. People keep saying that as if it was a bad thing

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…

> Tell me how you mount the filesystem of box2 in a folder on box1

It's not that hard. Just install Ubuntu, then VMware, then Windows, then WSL, then Docker, then a microcloud inside a container, then you can easily run a headless Dropbox client to sync that folder.

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#68
post #46

Earlier quoted context omitted.

Let's assume I have huge server at home with tons of disks that sucks on average 200W 24/7 - most machines idle around 10-50W depending on the periphials I'm in Germany, the country with the most expensive electricity prices - I'm paying 31cent/kWh at the moment. That's about the current market price for consumers - so that's 543,48€/year or 45€/month if that machine would suck 200W on average over the year. If you a…

> I'm in Germany, the country with the most expensive electricity prices - I'm paying 31cent/kWh at the moment. "Most" is an exaggeration, but expensive is true: https://ec.europa.eu/eurostat/statistics-explained/index.php...

Thanks, I guess I read too much local doom news. I also underestimated that intel box from hetzner - it's actually twice as fast as the small AMD server but I guess the idea was clear.

Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"

#69
post #51

I tried very hard to get onboard with Ubuntu's new server paradigm, I've been using Ubuntu on and off since 2005. Snap is what turned me away. My research (admittedly several years out of date) told me that it was impossible to disable 'auto-updating' of Snaps. Now I see that they're rolling out what is apparently a high availability service built on services deployed through Snap. I don't see how this is viable, if…

snaps are horrible and a big deterrent. I stopped recommending ubuntu because of them. Total dead end.
Post reply on HN