alienscience @ alienscience @programming.dev

Posts

0

Comments

9

Joined

2 yr. ago

I do this for sites where I don't care at all about security. One minor tip, that will protect against automated attacks if the password is cracked, is to add part of the website name into the password (e.g "mystrongp4ss!lemworld") .

A human could easily crack it, but automated systems that replay the password on different sites would probably not bother to calculate the pattern.

I also use KeepassXC and Synthing together and I am very happy with this combination.

One tip that I have, if you are worried about the security of the database file being shared, is to get 2 Yubikeys and use these, along with a strong passphrase, to protect the database file.

I enjoyed reading the Phoenix Project and learnt a lot from it. It is a classic for very good reasons.

There was another follow up book -- The DevOps Handbook that went into more detail about solutions to the problems raised in the Phoenix Project. I got a lot from the DevOps handbook but I found it quite a heavy read.

Years later I found a smaller, but super practical book, that covered much of the same subject matter -- Operations Anti-Patterns, Dev Ops Solutions. I recommend this Manning book after the Phoenix Project.

But then I haven't read the Unicorn Project yet, so that is a book for the list.

The only thing you should keep an eye on is probably the license? But I’m not the right person to discuss about licensing :/

It is normal practice to keep the same copyright notice and add your name to it, e.g for this project I forked in 2021: https://code.alienscience.org/alienscience/dnsclientx/src/branch/master/LICENSE

I think that Kreya is worth a mention:

• It has more complete OAuth2 support than Insomnia.
• Saves to human readable files.
• Usable free tier.
• Cheap Pro tier pricing.

Just to add to this point. I have been running a separate namespace for CI and it is possible to limit total CPU and memory use for each namespace. This saved me from having to run a VM. Everything (even junk) goes onto k8s isolated by separate namespaces.

If limits and namespaces like this are interesting to you, the k8s resources to read up on are ResourceQuota and LimitRange.

The person that found this is a hero.

Whenever I see slightly weird behaviour, there is a temptation to just move on because there isn't enough time, running software is complicated, and there is something else I want to do. I will try to change my attitude in future in case it uncovers a backdoor like this -- it would be educational too.

For a fun comparison, a reasonable 1TB USB Stick costs slightly less than 1TB of AWS egress.

The manifest of my Kubernetes cluster is managed in a Git repository and is automatically deployed via a GitOps tool named Flux CD. When I push changes to the repository, such as adding a new application or upgrading Docker images, the deployment occurs within a few minutes.

This is the way.

Although I use Flux ImageUpdateAutomation instead of Renovate Bot. Did you consider using Flux to do auto updates? Are there any downsides that made you choose Renovate Bot instead?