NAT busting is a plus. Avoid needing DDNS and opening a port. Also easier setup for accessing other stuff on the network via that computer vs up/down rules with a standard wg config.
For a small setup thats the big thing, but for anything a little more it does key rotation, handles ips for you, and offers "magic dns" which makes all the devices get a nice DNS address when tailscale is on.
NAT busting is a minus. If apps can create holes in your network and “bust your NAT,” your network is not well secured; you should disable UPnP and filter egress.
Also, you gain simplicity but give up to coordination servers, that can be a privacy and security problem.
> This cycle of having a few years where the costs of an approach aren't acknowledged, to a few years where the benefits aren't acknowledged, is very lame.
Well said. I do sympathize with some of the criticisms but only insofar as people who didn't have experience with microservices get sold on a lot of hype, the tradeoffs aren't made clear, and they get burned. The cycle seems to be "This is the silver bullet for programming complexity!" for a few years, followed by a few years of "This isn't a silver bullet!" before the Next Big Thing (TM) comes along and the cycle starts over.
> The more hardcore UBI defenders talk about paying Malibu surfers to surf all day, or to write haikus
I've been following the UBI space for a long time and I've never seen anyone use this as an example - that's just a strawman. What people discuss is the work that is valuable to society but is unpaid such as raising children, caretaking for the elderly, community support, and so on.
A few hundred dollars a month isn't enough to live on, but it moves the needle for those most at-risk for going hungry or becoming homeless. And for everyone else, it gives extra breathing room and negotiating power in the workplace.
Well, the "Malibu surfer" is a recurrent theme. E.g. https://link.springer.com/chapter/10.1007%2F978-3-030-37908-... or https://www.jstor.org/stable/2265291. Van Parijs (author of the last text) is very well known in the field of UBI (some sources even list him as the founder of the idea). The haiku theme often arises in discussions, but I cannot find a source. Anyway, is the same idea: being paid for doing whatever you want or nothing at all.
What you talk about is not UBI, but other schema of basic income conditioned (thus not fulfilling the U).
Anyone who's had to parse free-text international addresses can tell you that this is terrible advice. People type things into computers incorrectly all day long. We prompt users to select things like country from dropdowns with good reason. Imagine having to delete user data for GDPR compliance and needing to determine which of your 1,000,000 users are in the EU from a free-text field. Oh, this user wrote "Czechia" instead of "Czech Republic"? What do you mean they wrote the name with accents? Oh they wrote the name in their native language and not English? Have fun parsing all this:
The parent did say “targeted to a country you do [understand]”. The impression I get is that for most address handling the only thing that’s critical to have structured is the country; probably everything else should be free-text until you have a reason not to[1], at which point you should find someone who deals with them for a living (probably a third-party provider), and even then it's probably best to provide a fallback for the weird edge cases.
[1]: One good reason is that, as you say, people get things wrong—even their own address—on a regular basis, and you may be charged more money if you’re e.g. shipping things with the wrong postal code for the rest of the address. But even then it’s good to provide a workaround if necessary; post office databases can be wrong too!
On paper forms you usef to just draw a line theough the field to make clear that you didn't just forget. I've seen electronic forms that require you enter "N/A" for the same. Would be amusing if someone chamged their name to "N/A".
> always just about 'good enough' to solve the issue at hand
I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.
Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover.
"Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc.
Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)
You're not missing anything, the argument is for how long this duration should be.
The lifetime of the original creator plus $YEARS should be more than long enough for the original work(s) to be made 'canonical'. How is a corporation buying up an IP because it is profitable going to guarantee it remains true to the original author's intentions, or to the desires of fans? If we care about the consumer they should be free to engage with the original works or any derivation thereof as they choose. IP isn't about expanding consumer choice, it's about limiting it - and it certainly isn't a mechanism for guaranteeing the ongoing quality of a series.
I agree libraries are great when dealing with very specific domain problems (who wants to hand-roll a datetime module?). But there are also a ton of libraries that aren't for such specific domains or which attempt to bridge multiple domains (i.e. frameworks).
The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.
