There’s no need for it to be temporary.

The battery started with something like a 45km range and by the time it died it was reporting 33km but was being more like 25km. The warranty expired about 6 months before it really stated going downhill.

Judging by some of the comments I see here though, the culprit may have been situational. We regularly recharged it whenever we got home to keep the level high rather than letting it go down throughout the day. We did this because we use the bike a lot and didn’t want to be trapped on the other stuff of town with a dead battery and heavy af bike.

For this new battery though, well try to limit the charging a little more though and see what happens I guess. I’ll report back in a few years.

That’s both encouraging and annoying. The battery was conveniently out of warranty when it finally died.

Interesting. That’s good to know. Perhaps this new one will last longer?

The thing is though, 700 charges doesn’t sound like much as we end up charging it every day given the distance we put on the bike. We’d go through 700 charges in less than 2 years.

I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run helm install ... either directly or via the CI and stuff is deployed.

So for example at my last job, our GitLab CI just had a section triggered exclusively for merges into master that ran helm install ... for all three environments. We had three values.yaml files, one for each environment, and when we wanted to deploy a new version, the process was:

1. Create a tag for our release version (ie. 1.2.3) and push it to the repo. This would trigger a build and push the resulting image into the container registry.
2. Push an update to the repo with the new tag set in the appropriate Helm values file. If we wanted to deploy 1.2.3 to development but not yet to staging or production, then the tag: value in each of the environment files would look like this:

• k8s/chart/environments/development.yaml: tag: 1.2.3
• k8s/chart/environments/staging.yaml: tag: 1.2.2
• k8s/chart/environments/production.yaml: tag: 1.2.2

Once that change is pushed, the CI will automatically apply it with helm install ... and make sure that all three environments are what they’re supposed to be.

As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:

The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:

#!/bin/sh

while ! nc -z postgres 5432; do
  echo "Waiting for postgres..."
  sleep 0.1
done
echo "PostgreSQL started"

touch /tmp/ready

exec "$@"

I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.

Kubernetes. For a homelab, the stripped-down k3s is fantastic and surprisingly easy to get going.

Once you’ve got Kubernetes set up, you can lean on all the many tools already out there for things like deploying complex projects (Helm) and monitoring (Prometheus/Grafana). OpenLens is a nice piece of software you can use to monitor and control your cluster too, as is k9s.

I’ll just leave this here.

I’m not surprised. Have you seen what they’re charging for the batteries? We had to buy a new one for our e-bike and it came to about £600. Just for the battery.

“Sir David Attenborough, 100 years old today” would have be a lot better.

It was downvoted because it’s not true.

I’ve had Gentoo (and later, Arch) on my Surface Pro 3 for a decade. It’s fully supported, touch screen and all.

Good point. I’ve added a link for intergenerational context ;-)

“Dystopian” is a great word for this.

What do you think this is, Frogger?

While this isn’t true for the US, it is true for Switzerland. Valentina Tereshkova went to space in 1963, while Swiss Women’s Suffrage was established by a referendum in 1971.

I don’t see Cambridge on the list. Whew!

It’s a bit of a long read, but this was our experience.

TL;DR: The NHS has doubled down on midwifery, which has resulted in two classes of care:

• Battle-hardened nurses who switched to maternity
• People with little formal education, who think that “hypnobirthing” and nice music is a reasonable replacement for actual medicine.

It’s a roll of the dice as to which one you get.

I suspect that anyone who’s had to deal with childbirth in this country would say: “duh”.

As this is a new project, have you considered hosting your code somewhere other than GitHub? Codeberg and GitLab are similarly user-friendly platforms without the many downsides of supporting Microsoft.

I’ve never tried it, but I haven’t heard that it was thwarted yet.