There is no way legacy projects are going to switch to Deno. Even when Deno is 100% compatible, the only advantage Deno provides is slightly higher performance. Node’s complexity problem? All those configs needs to be supported for compatibility anyway. Typescript? The project already has tsconfig.json set up, so they might as well continue to use tsx. Security? I bet users will just get tired and use -A all the time.

To benefit from Deno, Node’s legacy needs to be shed.

Wine is a different case. The reason Wine makes sense is because Windows is so much worse than Linux that even with scrappy game compatibility, Linux offers a better experience. For Linux users, the alternative to Wine is not switching to Windows, it is not being able to play games. On the other hand, legacy Node projects have a very easy alternative… just continue to use Node.

And btw Bun is making the same mistake.

Through compatibility, Deno established an upgrade path.

Sure, but Node compatibility needs to work, and it needs to work reliably. Which means every last detail of Node needs to be supported.

This is what I am trying to convey… the engineering effort to make an objectively better JS runtime while being Node compatible is likely too much effort. Many popular Node projects are already having issues with Deno. Now imagine how the compatibility scene will look like with every single proprietary Node project out there.

So instead of trying to replace NodeJS or offering an upgrade path for existing Node projects, incentivize formation of ecosystem around Deno.

Statistically speaking, you are right.

We test our code locally, but we cannot test the workflow. By definition, testing the workflow has to be done on a CI-like system.

There is nektos/act for running github actions locally, it works for simple cases. There still are many differences between act and github actions.

It might be possible for a CI to define workflow steps using Containerfile/Dockerfile. Such workflows would be reproducible locally.

Time for the yearly barrage of “Setup CI”…“Fix CI” commits.

That is my experience with basically every CI service out there.

Testcontainers uses ‘ryuk’ to clean up containers and it needs docker socket mounted within its container to work. So if you had any hardening config that prevents the docker socket access within a container e.g user namespace or SELinux then Testcontainers doesn’t work.

And I think it would be nice if Testcontainers ‘just worked’ with Podman without any additional steps.

Nothing else. Though docker socket issue was important enough.

1. It might be a card grabber.
2. Don’t put real card details of course.

It wants you to put dummy details as fast as you can.

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.