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 Snap is still dead set on updating things on their own schedule. I certainly wouldn't trust it without some in-depth testing and validation to ensure that Canonical can't remotely DoS me by pushing some new update that I can't opt out of.
Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
51–60 of 94 posts
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#52Earlier 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…
> 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.)
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#53So OpenStack?
But actually less features than OpenStack. Kind of weird that they didn't just package OpenStack. A vendor to manage it for you would actually provide business value
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#54So.. we’re back to self-hosting your own services? And IT does another cycle.
Some of us never left... I can't justify paying that much money just to execute some code on another person's server.
It can be cheaper to run things in the cloud if your workload is very spiky or short lived.
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#55I 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
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#56This is going to be very uncomfortable when Supermicro sues Canonical over a trademarked term. Supermicro has been selling Microclouds for years, and is a well known product line in the industry.
Just like it was a very uncomfortable situation when Anderson sued Microsoft over the term windows? Canonical is selling a piece of software, supermicro a line of servers. And based on their own site it isn’t trademarked. Notice there’s no r next to the microcloud server but there is next to microblade. https://www.supermicro.com/en/products/blade
[deleted]
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#57This was my take, FWIW. https://www.theregister.com/2023/11/16/canonical_microcloud/
This demo is very hard to follow indeed. They are just jumping around, demoing features, but not talking about how it all fits together.
I agree, but as I said in the article, the first stage of the demo failed, and after some frantic attempts to tear down and rebuild the cluster, they gave up, moved on to later stage of the demo, and then came back to it.
Which is why it's incoherent and doesn't fit together.
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#58Earlier 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.)
And yet, that's how Plan 9 boxes talk to one another.
I think maybe you are misinterpreting my post as saying "mount the entire disk used by box1 on box2 simultaneously".
Although when it comes to that, I would also note that DEC's AdvFS did more or less that, 20+ years ago, and it's FOSS now:
https://en.wikipedia.org/wiki/AdvFS
And it's also what the DragonflyBSD team are attempting to make happen in HAMMER2.
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#59At home I have a small server farm of cheap Ryzen PCs. Mostly continuous integration and testing for open source projects, but also some LLM. If I have some idea, I just throw it into farm and see results a few days later. It is slower than renting in cloud, bit about 4x cheaper. It also heats my house a bit in winter...
You must have cheap electricity where you live...
I am in Czechia, pretty expensive, but I heat with electricity anyway (don't ask).
If you want machine with 8 real CPU cores, 128GB RAM, 8TB SSD storage... It only take 110 Watts under full load. Electricity cost compared to cloud fees is tiny.
Re: Canonical Launches MicroCloud to Deploy Your Own "Fully Functional Cloud"
#60Earlier 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.)
And yet, that's how Plan 9 boxes talk to one another. I think maybe you are misinterpreting my post as saying "mount the entire disk used by box1 on box2 simultaneously". Although when it comes to that, I would also note that DEC's AdvFS did more or less that, 20+ years ago, and it's FOSS now: https://en.wikipedia.org/wiki/AdvFS And it's also what the DragonflyBSD team are attempting to make happen in HAMMER2. https:…
Wasn't DEC doing that with VAX/VMS 40 years ago with VAXclusters?