Ha, that’s funny! I got my PhD from NTNU, but never actually noticed that in English it becomes NUTS… NTNU is a Norwegian acronym for Norges teknisk-naturvitenskapelige universitet.
Interesting! I grew up before network cards was a thing in home computers (Commodore 64 and Amiga), but a group of my friends organized what we called «meetings» which I would characterize as your traditional LAN party. I remember at some point that we hooked up two Amigas over a fairly long parallel cable and were able to send data across. Cannot recall if we actually were able to copy larger files between them though. Fun times!
Yeah, while I’ve seen some great libraries that follow the practice of minimizing their dependencies, I’m a bit annoyed with the amount of dependencies that docker will bring along [1]. I’ve been on the lookout for alternatives for my docker needs, but the state of podman, buildah and some others that I checked is similar. They all bring in roughly the same number of dependencies… if anyone knows of a stripped down Go lib that can be used to build from a Dockerfile, pull, and run a container, I would be grateful for any suggestions. Heck docker / moby isn’t even using go.mod proper.
Wow, that's massive. I guess it's inevitable that a popular piece of open-source software for end-users will be compelled to accrue dependencies due to popular demand for features that require them.
I feel Telegraf made a good compromise: out of the box, it comes with a _ton_ of stuff[1] to monitor everything, but they make it possible to build only with pieces that you need via build tags, and even provide a tool to extract said tags from your telegraf config[2]. But lots of supply-chain security stuff assume everything in go.mod is used, so that can results in a lot of noise.
Thanks! That’s an interesting approach. Haven’t seen that before. I think a better approach (in a monorepo) might be to use separate go.mod files for each module, allowing the user to configure only the needed parts separately. But I haven’t seen it used much.
Just watched this… Thanks for posting. It is very nicely presented and intuitive as usual from 3blue1brown. Can definitely recommend this if you want to get a bit deeper understanding of quantum computing than the usual surface level nonsense that I usually come across.
I can't say. It's definitely not the same as running on bare metal. Then again, any benchmark in a test environment is just an approximation of the real thing. To see how anything will act in the real environment, you have to run it there.
In our use case we wanted a way to quickly and easily set up benchmarks that would allow us to compare our software to our competitors under the same conditions. Given that Benchi can run the same benchmark scenario for different tools, the results are comparable with each other. We also run all benchmarks on an empty AWS EC2 instance, to minimize any other factors. But does that mean that the collected results show the absolute limit of what the tools can handle? Probably not. Under different conditions, results can change, but that's just the nature of benchmarks.
Depends on what you are testing and how... Virtual network adapters, routing, file system redirection, etc. all have some overhead and will impact things differently. IME U haven't seen too many things affect performance more than 3-5% on native Linux. If you're using Windows or Mac as a host OS, then volume mounts to the host in particular are really going to affect the results.
