It's probably because usually normal people don't but routers because they get them included in their internet subscription. So the people buying them have a specific reason to that normal routers don't do
It's a travel router which power users buy to get good connectivity away from home and office. An hotel won't offer you that (and chances are that they'll try to rip you off on their wifi).
Assuming you can find an Ethernet port to supply it, that is. Most hotels don't make them easy to find and use, if they even have them.
More common is that you use the travel router to connect to hotel WiFi and then share out that connection. It's slower than using directly, but it's great for family travel since you can name your travel SSID the same as your home network - all your usual devices will connect automatically, and will use any whole-connection VPN you have set up (most of the gl.inets will do Wireguard, OpenVPN, and Tailscale that I know of straight out of the box, and they will let you into luci or via SSH to configure the underlying OpenWRT directly for anything else). And, of course, it's just one device for hotels that try to limit the number of devices you use.
As far as travel and hotel goes, another huge benefit is that the router enables devices without captive portal support, on a recent trip I can use:
- Fi base station for my dogs trackers (huge for me)
- FireTV stick (no need to trust hotel streaming apps will clear your credentials like they claim)
Also I can WireGuard back home automatically for select IP ranges (no need to configure WireGuard separately on many of my devices)
Yeah and especially the satisfaction that you were able to make a user delighted to use your thing. Fixing bugs, making things faster, adding new features, for me personally I do it because I feels really good when a customer loves to use the thing I've built.
Weather I've done the manual coding work myself or have prompted an LLM to cause these things to happen, I still chose what to work on and if it was worthy of the users' time.
Easier to name it null, not giving it a postal code, using non-ascii characters, two names within the same language, giving the park two addresses, giving the park an address without a location, or just not giving it a name at all.
I think about this by unwrapping the circle to form a straight line. Then you draw an imaginary point in the middle of the line.
Then what are the chances they will all fall on one side of the line or the other? 1/2 because it's divided into two equal lengths.
1. Your answer can be "no" when the true answer is "yes". Consider this process with a circle of perimeter "21":
--------------------- (unwrap the circle)
----------+---------- (bisect the line)
-**-------+--------** (drop four points)
The four points don't fall into either of the two semicircles that you stupidly predefined, but they do fall into a different semicircle.
2. Your answer of "1/2, because it's divided into two equal lengths" is completely wrong for the scenario that you specify.
Consider the case where we drop a single point. We can do the same procedure:
A. Unwrap the circle;
B. Bisect the line;
C. Drop one point.
But even though the line is still divided into two equal lengths, our one point has a 100% chance of falling either on one side of the bisection point, or on the other side.
For the case where we drop four points, the article already gives the correct answer for your method, which is 1/2^3 (because there are 3+1 points).
This approach implies the probability doesn’t depend on N. It only happens to be 1/2 for N=4 (the article goes into this). The trick is that you don’t know beforehand which semicircle all the points can land in, but your unwrapping step assumes you do.
reply