Yes, not everyone is allowed to use cloud services. There's also the cost. I haven't spent a cent on infrastructure in 5 years (other than my time). Using cloud services comes with extra costs and meetings to justify those costs. Plus, not everyone is in the USA or 1st world country where those costs are negligible. Necessity is the mother of invention.
For an SME with nonetheless critical workloads, 10000 containers is not small. To me that's massive in fact. I run less than 10 but I need those to be HA. uncloud sounds great for my use case.
That's really interesting and cool. In that case calling it imperative rather than declarative is underselling it imho. I haven't worked that much with Terraform but in my usage from the cli, that is how it works too and I consider that declarative.
I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start.
In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective?
> In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer
In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe.
In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.
> In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective?
Yeah, you absolutely could and someone on our Discord has written a 30-line bash script that essentially runs a reconciliation loop with the CLI.
Thanks for the point on underselling by calling it imperative rather than declarative!
I looked into this yesterday for making Caddy HA on my Proxmox cluster and stumbled upon keepalivd. It will provide you with a virtual IP and failover but not load balancing so you'd need to still point that at something like HAProxy for that.
Could be something interesting to integrate though.
I've been posting the manifesto to friends and colleagues every tau day for the past ten years. Let's keep chipping away at it and eventually we won't obfuscate radians for our kids anymore.
Oh, pi has its place: in engineering, for example, it's much easier to measure the diameter of a pipe than its radius: just put calipers around the widest point (outside or inside depending) and you have the diameter. In fact, you probably wouldn't ever measure the radius; in places where you need the radius, you'd just measure the diameter and divide by 2.
But for teaching trig? Explaining radians should definitely be tau-based.
Yes, though more broadly my point was that the radius is the natural measurement of the circle for most things since most things are center-based. But for some physical measurements, mostly based around pipes, "what is the width of this pipe" is the question you need answering, and that is diameter-based. And pi is circumference/diameter, while tau is circumference/radius.
But yes, if the world switched to tau then you wouldn't need pi anymore, you'd just write tau/2 in the rare cases where having the circumference/diameter ratio handy is useful.
I wonder how many places we have in modern math symbols which we use for historical reasons, rather than because it's most convenient overall. I guess we are balancing things here.
Which one of those is preferable? It seems to me that they are both historically based. 10 x 10 is also 100 in base-12 (it's only in base-10 that it looks like 144).
IMHO, in a modern setting base-16 would be the most convenient. Then I maybe wouldn't struggle to remember that the CIDR range C0.A8.0.0/18 (192.168.0.0/24) consists of 10 (16) blocks of size 10 (16).
There’s nothing particularly convenient about base-ten; for real-world uses base-twelve would be preferable thanks to its large number of divisors (and even larger number of divisors of its multiples like 60). Which is exactly why 12 and 60 historically appear in many contexts.
A number theorist would probably want a prime base, so that N (mod 10) would be a field.
A power-of-two base wouldn’t be particularly convenient to anyone except a small minority consisting mostly of hardware and software engineers.
Thanks. I hadn't heard of RustFS.
I've been meaning to migrate off my MinIO deployment.
I recently learned that Ceph also has an object store and have been playing around with microceph. Ceph also is more flexible than garage in terms of aggregating differently sized disks. Since it's also already integrated in Proxmox and has over a decade of enterprise deployments, that's my top contender at the moment. I'm just not sure about the level of S3 API compatibility.
Ceph is quite expensive in terms of resource usage, but it is robust and battle-tested. RustFS is very new, very much a work in progress[1], and will probably eat your data.
If you're looking for something that won't eat your data in edge cases, Ceph (and perhaps Garage) are your only options.
reply