Exactly. The bathtub part where the driver is looks like it’s still perfectly in tact, from the floor to the halo.

Yeah, I think this would be the right thing to do. Give them the physical parameters of the battery, but not the capacity. Let them innovate.

It would also be interesting to do something with charging. Like fix the tires so they don’t require a tire swap, but they must recharge for 20 seconds or something. Not enough to charge the whole battery by any means, but the first team to figure out how to dump a meaningful amount of power in would have an advantage.

Realistically, yes. But it’s a phrase and it’s important that they start doing that first. Maybe it’s their intention to do it publicly.

Also, sure, but a Wireguard installation is going to be much more secure than a Nextcloud that you aren’t sure if it’s configured correctly. And Tailscale doubly so.

Please set up Tailscale or a Wireguard VPN before you start forwarding ports on your router.

Your configuration as you have described it so far is setting yourself up for a world of hurt, in that you are going to be a target for hackers from literally the entire world.

There is a lot of complexity and overhead involved in either system. But, the benefits of containerizing and using Kubernetes allow you to standardize a lot of other things with your applications. With Kubernetes, you can standardize your central logging, network monitoring, and much more. And from the developers perspective, they usually don’t even want to deal with VMs. You can run something Docker Desktop or Rancher Desktop on the developer system and that allows them to dev against a real, compliant k8s distro. Kubernetes is also explicitly declarative, something that OpenStack was having trouble being.

So there are two swim lanes, as I see it: places that need to use VMs because they are using commercial software, which may or may not explicitly support OpenStack, and companies trying to support developers in which case the developers probably want a system that affords a faster path to production while meeting compliance requirements. OpenStack offered a path towards that later case, but Kubernetes came in and created an even better path.

PS: I didn’t really answer your question”capable” question though. Technically, you can run a kubernetes cluster on top of OpenStack, so by definition Kubernetes offers a subset of the capabilities of OpenStack. But, it encapsulates the best subset for deploying and managing modern applications. Go look at some demos of ArgoCD, for example. Go look at Cilium and Tetragon for network and workload monitoring. Look at what Grafana and Loki are doing for logging/monitoring/instrumentation.

Because OpenStack lets you deploy nearly anything (and believe me, I was slinging OVAs for anything back in the day) you will never get to that level of standardization of workloads that allows you to do those kind of things. By limiting what the platform can do, you can build really robust tooling around the things you need to do.

I used to be a certified OpenStack Administrator and I’ll say that K8s has eaten its lunch in many companies and in mindshare.

But if you do it, look at triple-o instead of installing from docs.

I wish I could fully endorse Escalidraw, but it only partially works in self-hosted mode. For a single user it’s fine, but not much works beyond that.

It’s like all the vegans vs the people that bitch about vegans.

You’re on the right track here. Longhorn kind of makes RAID irrelevant, but only for data stored in Longhorn. So anything on the host disk and not a PV is at risk. I tend to use MicroOS and k3s, so I’m okay with the risk, but it’s worth considering.

For replicas, I wouldn’t jump straight to 3 and ignore 2. A lot of distributed storage systems use 3 so that they can resolve the “split brain” problem. Basically, if half the nodes can’t talk to each other, the side with quorum (2 of 3) knows that it can keep going while the side with 1 of 3 knows to stop accepting writes it can’t replicate. But Longhorn already does this in a Kubernetes native way. So it can get away with replica 2 because only one of the replicas will get the lease from the kube-api.

Longhorn is basically just acting like a fancy NFS mount in this configuration. It’s a really fancy NFS mount that will work well with kubernetes, for things like PVC resizing and snapshots, but longhorn isn’t really stretching its legs in this scenario.

I’d say leave it, because it’s already setup. And someday you might add more (non-RAID) disks to those other nodes, in which case you can set Longhorn to replicas=2 and get some better availability.

I’ve been playing around with MicroOS, which is based off of OpenSUSE and is supposed to be the successor to RancherOS

If you want to build a new container on top of nginx, that will serve a static site like a champ

Good to hear they have that covered already. Looks like a great tool!

But I could take ‘flower.jpg’, which is an actual flower, and embed a second image, ‘csam.png’ inside it. Your scanner would scan ‘flower.jpg’, find it to be acceptable, then in turn register ‘csam.png’. Not saying that this isn’t a great start, but this is the reason that a lot of websites that allow uploads re-encode images.

The fun part is that it’s still a valid JPEG file if you put more data in it. The file should be fully re-encoded to be sure.

TBH, I wouldn’t be comfortable outsourcing the scanning like that if I were running an instance. It only takes a bit of resources to know that you have done your due diligence. Hopefully this can get optimized to get time to be faster.

If you’d like something a bit more real world, check out k3s and ArgoCD. I use Kubernetes professionally, so I’m certainly biased, but it’s incredibly powerful and with ArgoCD, all of your config lives on GitHub.