Lodra

Head nod regarding the ranked choice voting

The simplest way is certainly to use a hosted service like GitHub Pages. These make it so easy to create static websites.

If you’re not flexible on that detail, then I next recommend Go actually. You could write a tiny web server and embed the static files into the app at build time. In the end, you’d have a single binary that acts as a web server and has your content. Super easy to dockerize.

Things like authentication will complicate the app over time. If you need extra features like this, then I recommend using common tools like nginx as suggested by others.

Absolutely a good perspective on the surrounding infra! I fully agree. Thanks for sharing.

An interesting discussion! You’re probably right about most Lemmy instances. But it’s entirely possible that some instances are running a modified version of Lemmy that collects more data. And only those admins will understand why. They could sell it as easily as any company.

You need to trust your service providers or accept what they’re doing.

I can agree that crisp, cold air has a taste sometimes. But I would never describe it as milky. To be fair, I’m not sure how to describe sooo

The CEO now seeks help from Phutar Afrayughum, a psychic and extrasensory perception specialist who allegedly helped Google increase their marketshare in the messaging app market, and was also involved in developing the Material Design framework.

Seems like a legit article :shrug:

As someone who can make some fairly well educated guesses about the programming.dev infra and effort, I find this entire project is kinda fascinating. Keep it up!!!

Do you have any public info available on the operating costs (time + money)? How do you fund everything?

I recently dug into this because I accidentally trashed my wife’s OS which was encrypted with bitlocker. PITA btw and I couldn’t beat the encryption

Bitlocker encryption key hash is stored in 2 possible places. First is an unencrypted segment of the encrypted drive. This is bad because it’s pretty easy to read that hash and then decrypt the drive. The second place is on a Trusted Platform Module (TPM) which is a chip on the motherboard. This is better because it’s much more difficult to hack. It can be done but requires soldering on extra hardware to sniff the hash while the machine boots up. Might even be destructive… I’m not sure.

Either way a motivated attacker can decrypt the drive if they have physical access. For my personal machines, I wouldn’t care about this level of scrutiny at all.

Anyways you can see if any open source solutions support TPM.

I recently changed my personal email. Updated every account I knew of (thanks Bitwarden!!). Updated about 120 accounts, closed maybe 20, and 5 or so can’t be changed.

Of the ~120 that I changed, I think about half of them were easy to change. Not much confusion. There was a clear enough process. Etc. Most of the rest were difficult to change but I could do so on my own eventually.

Something like ~10 accounts required emails and phone calls to support.

A few were terrible. Things like updating my email address in 10 places for one account. Or the updates go fine but just didn’t work, requiring many repeat attempts or phone calls.

So it’s a real problem in my experience. But not the norm. Maybe 1/10 rather than 9/10

OpenTelemetry

First is complexity. A simple helm chart works great but more elaborate charts can turn into a maintenance problem. This is especially when managing a large number of apps and need to establish and maintain standards across them. E.g. you want to add a new label to every helm chart you use. You now get to making 60 PRs for 60 charts. Or you can tie them all together with chart dependencies. This can be done well but almost never is. It's just too easy to build a bad helm chart. Kustomize allows you to do this from a "top-down" perspective

Second is modifications. Consider as an example that you want to run filebeat as a sidecar container on some pod to capture its logs. But the helm chart you're using doesn't include this feature. You have two choices: modify the pod when it's created with a mutatingwebhook or similar (super complicated solution) or you can copy/fork the chart, add the functionality, and maintain it going forward. Kustomize just doesn't have this problem. You can just modify a base manifest with overlays.

Last is the nature of Go templates which helm charts are based on. Everything outside of {{ }} is just plaintext. This leads to a ton of limitations. Got a whitespace issue? You'll probably find out at runtime. Want your IDE to identify syntax issues, provide, intellisense, etc. on the final manifest? Good luck! You need to render that chart first. With Kustomize, every manifest is structured text (yaml). So you get the benefits of all standard tooling for yaml data in your IDEs and CI/CD pipelines.

Honestly, I could keep going (helm releases ugghhhh!). But helm definitely wins on one point and it's a big one; Helm is the standard for distributing k8s manifests. So every meaningful project supplies helm charts. Kustomize doesn't even come close on this one. That said, I think Kustomize manifests are just simpler to build. So having an official base manifest for every project just doesn't matter too much.

I started using git meaningfully about 10 years ago. Mercurial maybe 6 years ago but not very much. And I was not a fan. Especially how it tracks things recursively.

So honest question. Why?