![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
It is a game, but it might also be a card grabber.
It is a game, but it might also be a card grabber.
I did not make this, and you’re supposed to put dummy details there. Don’t put actual credit card information.
Thanks man, my brain was short-circuited on Testcontainers so I couldn’t write better. Also I am stealing the title.
I don’t get it, how would a database container run your unit tests? And unless you know some secret option to stop the database after, say, it is idle for a few seconds, it will continue running.
The purpose is to test database dependent code by spinning up a real database and run your code against that.
For me the value of podman is how easily it works without root. Just install and run, no need for sudo or adding myself to docker group.
I use it for testing and dev work, not for running any services.
No… too hard.
npm ruin dev
running shittier could be a nice prank… depending on how often it gets typed.
That advertisement would be interpreted as Node C
’s advertisement.
The plan is to treat public keys as node’s identity and trust mechanism similar to OpenPGP (e.g. include any node key signed by a master key as a cluster member)
Right now, none of the encryption part is done and it is not a priority right now. I need to first implement transitive node detection, actually forward packets between nodes, some way to store and manage routes, and then trust and encryption mechanisms before I’d dare to test this stuff on a real network.
The UI is desktop only for now, I’ll make the mobile UI some day.
I didn’t know the answer either, but usually you can compose solution from solutions of smaller problems.
solution(0): There are no disks. Nothing to do. solution(n): Let’s see if I can use solution(n-1) here. I’ll use solution(n-1) to move all but last disk A->B, just need to rename the pins. Then move the largest disk A->C. Then use solution(n-1) to move disks B->C by renaming the pins. There we go, we have a stack based solution running in exponential time.
It’s one of the easiest problem in algorithm design, but running the solution by hand would give you a PTSD.
Replacing “Programmers:” with “Program:” is more accurate.
Tower of Hanoi is actually easy to write program for. Executing it on the other hand…
TPM stores the encryption key against secure boot. That way, if attacker disables/alters secure boot then TPM won’t unseal the key. I use clevis to decrypt the drive.
Thank you… I had to learn kubernetes for work and it was around 2 weeks of time investment and then I figured out I could use it to fix my docker-compose pains at home.
If you run a lot of services, I can attest that kubernetes is definitely not overkill, it is a good tool for managing complexity. I have 8 services on a single-node kubernetes and I like how I can manage configuration for each service independent of each other and also the underlying infrastructure.
don’t create one network with Gitlab, Redmine and OpenLDAP - do two, one with Gitlab and OpenLDAP, and one with Redmine and OpenLDAP.
This was the setup I had, but now I am already using kubernetes with no intention to switch back.
I was writing my own compose files, but see my response to a sibling comment for the issue I had.
If one service needs to connect to another service then I have to add a shared network between them. In that case, the services essentially shared a common namespace regarding DNS. DNS resolution would routinely leak from one service to another and cause outages, e.g if I connect Gitlab container and Redmine container with OpenLDAP container then sometimes Redmine’s nginx container would access Gitlab container instead of Redmine container and Gitlab container would access Redmine’s DB instead of its own DB.
I maintained some workarounds, like starting Gitlab after starting Redmine would work fine but starting them other way round would have this issue. But switching to Kubernetes and replacing the cross-service connections with network policies solved the issue for me.
As someone who is operating kubernetes for 2 years in my home server, using containers is much more maintainable compared to installing everything directly on the server.
I tried using docker-compose first to manage my services. It works well for 2-3 services, but as the number of services grew they started to interfere with each other, at that point I switched to kubernetes.
I just uploaded to Github: https://github.com/akashrawal/nsd4k
I only made it for myself, so expect very rough edges in there.
It wants you to put dummy details as fast as you can.