What about nerdctl + containerd?

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

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?

Still difficult in that example. Bossa can’t force the other company to do anything.

As the person criticizing the top level comments, I just want to say thanks. This is a straight answer and an option that I wasn’t aware of. Looking into it!

Huh. Why??

I got the same as @mintycactus@lemmy.world using Firefox Focus on IOS. Which I’m rather pleased by

Sorry, I don't have any info for you. But if you can't read the box, I bet you can run those images through an ocr tool and then give the output to Google translate or similar.

Another suggestion to solve it. Collapsing could be done with a long touch instead of a tap. So tapping would do nothing unless you tap a link. Touch and hold for a half second or so would collapse the text. Might be a little tricky to not mix with scrolling?

Well I am only able to offer some lame answers. Mostly because quality answers would take a very long time to construct. But here you go

• This really depends on what your building. Maybe find a n established project that's similar to yours and mimick its structure. There are many patterns available.
• Google it, try it, repeat. Python is loaded with "syntactic sugar". That leaves you with lots of options for how to structure and format your code. Which leads to many varying opinions. This is extra noteworthy for larger dev teams because of varying experience levels. You might be able to write a short, clear but of code that some devs won't understand. Lots of good options leads to a lack of clear choices. Opinions will vary.
• Again, lots of options. I like using the Black formatter because it gives you very few options and forces you into some style choices. Even the ones I don't like 🙂
• Oh boy. Google it. Extensively. Google it for several hours and then read some source code. Do this every time you start a new project 😂.
• I don't have a specific tutorial unfortunately. But the idea is that your "pyenv" directory will contain the packages your project depends on. Maybe the python installation too. And every one of these items will be a specific version. Because this is all installed in a single directory for each project, you can easily have different projects use and rely on different versions of the same dependency. This avoids all sorts of problems where you accidentally build and test locally using the wrong package version. I think a common practice is to create the "env" folder in the root of your git repo. And add "env/" to your gut ignore. Don't trust that exact syntax btw 😅

Apparently, someone else posted the same solution that I did while I typed it out. Sorry for the duplicate but at least weagree on the solution! A warning on this one though. You want to use a feature branch too. Otherwise you'll mix your changes for cool-stuff with new changes for and from even-cooler-stuff. It may become more confusing and difficult to merge.