FFC :) this is a European product, and since all of the "software" side of things is in your phone this can be available in other regions, and in the worse case scenario you can hack it in yourself.
Any radio equipment which is compatible with FRS/GMRS will work with PMR446/KDR444/FREENET and the likes which legally "support" mesh networking and repeaters.
FFC regulations are pretty much bull in regards to many handheld radio frequencies and pretty much force limitations on communication equipment which doesn't require a fee.
If you pay for GMRS license you all of a sudden can have repeaters etc. which you can't with FRS even tho they share a frequency range.
The upgraded clock would be really nice; I have a standard RTL-SDR without that, and the clock can drift a lot with temperature: it'll start up a few dozen PPM off, and shift another few dozen when it warms up. Depending on frequency, that ends up being many kilohertz, which is really annoying if you're shifting/filtering/downsampling, as your target signal can drift outside of your filter window.
A constant ppm error is easy to compensate for; less so when it changes.
Since the HackRF is open source, there's a group that makes a lower-cost clone called the HackRF Blue: http://shop.hackrfblue.com/. Their model is $215, and they have some units that have some minor issues (can transmit jut fine) for $150.
I haven't used the HackRF Blue, so I can't compare it to the HackRF One. There are a few comparisons floating around the internet.
In the context of queueing theory, there are many service disciplines that can be used, which are not necessarily FIFO.
Depending on what you're optimizing for, and the behaviors of your system (arrival process, task size distribution, number of servers, preemption overhead, etc.), it can be much better to process things in an order other than arrival order.
In particular, FIFO can mean small tasks end up waiting a long time behind large tasks. (Imagine going into a shop that sells sandwiches and pre-packaged salads; you want a salad, and there are 5 people waiting for sandwiches. Should you have to wait until the clerk makes 5 sandwiches before you can get your salad and leave?)
DNS is surprisingly tricky as a service discovery tool. A lot of clients are poorly behaved, and will cache values for too long (or forever). It'd also be another dependency critical for site functionality.
Patching HAProxy to reload config is really hard. There have been ideas, patches, and discussions on the HAProxy mailing list for a few years now trying to get zero downtime reloads natively supported in HAProxy, but the reality is that it just is not as easy as it might seem.