We've built a tool using LD_PRELOAD that speeds up SAT and QBF solvers (but the same idea could be used to speed up other programs too). The idea is to fork, then LD_PRELOAD the other program and overwrite its read functions (and equivalents to also capture inlined read functions). The child process loads some solver which will try to read its input from STDIN. The overwritten read is triggered and instead of just reading, our library shim connects to the parent process. The parent process feeds the child with data, the shim converting the data into text, feeding it to the solver as if it would be reading from a file. Now once we are finished with stating the problem and want to query it (i.e. send assumptions, in QBF or SAT solver speech), we issue a fork command, which lets the child process fork again into a second process, while the solver program thinks it is still in the read() call. We then feed the assumptions only to this grandchild, close its STDIN, and return the result to the calling parent process. When there's another assumption, we can issue the fork again and send assumptions to the new instance, never having to process the full problem again
This is nice when the formula is large and the assumptions are small and numerous, which (e.g. for parallelization) was very useful in our research.
The copy on write nature of fork() of course also helps, effectively reducing the required RAM to keep solvers in memory.
The best of all this, it works remarkably well on Linux and is even (mostly) POSIX conforming!
Check out our paper: https://ceur-ws.org/Vol-3201/paper1.pdf
Or just the code: https://github.com/maximaximal/quapi
Sounds quite a lot like the Common Lisp experience when using Sly and Emacs. You can (trace) every function and see lexical scopes of variables, even bind them if you execute some s-expr that does not currently have some variable under that symbol.
The distributed aspect is a bit more difficult though. I don't know if there is a system that truly got this right. Maybe Erlang's BEAM VM together with a good debugger I don't yet know about.
Because we don't want to use 20 IPv4 addresses for the cluster of 20 nodes, when we only have so much addresses assigned to our institute. We could have gone the NAT route, but then we'd need to have some router. And if we designate the head node as router, all traffic would not go through the switch directly, but first through the head node and then out. This would mean that the nodes are less independent, as they have this one additional choke-point. Our university gave us a /64 for this network, so we just used that and it worked flawlessly, also for university-internal distro-package fetching and host-cluster connections.
Also, research software is usually working nicely with IPv6. If we encounter something that would really need IPv4, we could update the thing and give it some local subnet - but currently we were lucky.
Yes, I did this on my personal network. I'm in Linz (Austria), the nearest tunnel to a german speaking country that's listed on tunnelbroker.net was Berlin (if I remember right). Everything worked rather well, but I then decided against it, because of the GeoIP implications (with one IP being in Austria and one in Germany) and the added latency. It's noticable when SSHing somewhere whether I'm Linz-Linz or Linz-Berlin-Linz, especially when a small lag spike happens, which is rather frequent with the cable-based network our ISP is offering. It wasn't worth it to half-slowdown our network just to not rely on jumping through some dual-stack node in the university.
If anybody from Liwest (our local ISP) reads this - IPv6 would be really nice! :)
We are IPv6-only on our institute-internal CPU compute cluster based on slurm. Only the head node has an IPv4 address, so that it can be reached from IPv4 only clients (sadly, there are still quite a lot). All nodes inside the cluster talk over IPv6. And all other computers with IPv6 access use that to communicate to the head node. We are transitioning to IPv6-only for internal services and try to avoid using IPv4 addresses, only going back to it when something needs to be accessed from the outside.
Sadly, our local ISP is still IPv4-only, meaning we cannot even access our IPv6 hosts while at home, so we need to fall-back to IPv4 quite a lot. Also, the Cisco VPN is still IPv4 only (because of lacking resources to add IPv6 support), so not even the VPN helps. We need to jump over some dual-stack host then.
When speaking to the local ISP, they just reply that it's not planned soon, they don't have resources for it, and "they evaluated IPv6 and don't have a reason to support it". Me/us giving them reasons was not enough it seems.
Very nice setup! As a sort of informal successor to dynmap, there's now (or rather since 1.13) also BlueMap [1]. It renders the map in 3D in the browser and you can look sideways at your builds. Truly impressive.
https://www.spigotmc.org/resources/bluemap.83557
You could have a look at CPack: https://cmake.org/Wiki/CMake:Packaging_With_CPack
It was created to be used with the C++ build system CMake, but can be used without it too. I use it to automatically build debian packages from Jenkins, but it also supports tarballs, RPMs, NSIS (Windows), PackageMaker (OS X), and cygwin packages. Hope this helps a bit!