3,881 karma · joined August 8, 2015
There are some significant regulatory issues with the current popular mesh network protocols in the USA, namely that neither MeshCore or Meshtastic are compliant with the actual FCC regulations. 100x bandwidth because you're breaking the rules isn't the same as 100x bandwidth legally.
Here is the issue discussing this in the MeshCore repository: https://github.com/meshcore-dev/MeshCore/issues/945
Most phones have them.
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
Be aware that parts of their stack use a custom license for some components... but a large portion of it is OSS Apache 2.0, which is nice if you can stick to those parts!
In middle school, in an attempt to get around the school firewall, I copied the HTML code from that website to my own to play Minecraft at school. Since my domain wasn't on the blocklist, it worked! But when my friends started using it to play, even after they hadn't bought the game, I resolved to add a login wall.
I built a backend proxy in PHP that would POST their credentials to the Minecraft API to make sure they had purchased the game. I still think it's funny to think I had no ethical qualms about circumventing the school firewall, but piracy was where I drew the line.
If you're learning Elixir right now, I can't recommend enough to also learn a bit about Erlang. The OTP and BEAM VM sit underneath both systems, and learning about what's going on under the hood helps a ton when troubleshooting production issues!
This was the biggest thing I noticed as well- core OTP concepts like gen_servers and supervision trees aren't covered in the language tour, the docs, or even the "Gleam for Erlang Users" page... it makes sense that it's missing if it's pre-1.0, but I was very confused when I didn't find anything about it at all.
Though he was on the older side when I took his course, he still brought laughter and enthusiasm to his classes, and set the tone for the rest of my college career. He will be missed!
Erlang was originally designed for implementing telephony protocols, where interrupted phone calls were not an acceptable side effect of application updates.
If the portion of the app you were hot upgrading was an OTP process like a GenServer, you could theoretically wait for some sort of atomic coordination mechanism to make that fully qualified function call after the new code has loaded, at least in theory.
We use hot code reloading at my work, but haven't had a reason to atomically sync the reload. Most of the time it's a tmux session with `synchronize-panes` and that suffices. If your application can handle upgrades within a module smoothly, it's rare to have a need for some sort of cluster-level coordination of a code change, at least one that's atomic.
Beyond just accidental confusion, I'd be worried about real legal issues with trademark infringement. Trademarks primarily exist to prevent customers from being confused about which business they're interacting with, and this is a great example of the types of things they're trying to prevent. (I am not a lawyer, so take this with a grain of salt.)
He will be dearly missed.
With rolling deployments, your only choice is to wait until that connection drains by completing or failing the download. If that doesn't fit your use case, you're out of options.
If your application is an Erlang app, you could hot code reload an unaffected part of the application while the download finishes. Or, if the part of the application handling the download is an OTP pattern that supports hot code reloading (like a gen_server) you could even make changes to that module and release e.g. speed improvements mid download stream. This is why Erlang shines in applications like telephony, which it was originally designed for.