> The difference between 75 (usually a beautiful day) and 85 (hot) is 23.8C to 29.4C.
If you convert a nice, round number from one system to the other, you'll end up with a more precise, less nice number, which will give the impression that Celsius is harder to use.
In reality, people from metric countries just think in 5-degree increments: 25 is a beautiful day, 30 is hot. It doesn't feel any harder to read than Fahrenheit.
I wonder if there are people that moved to the U.S., switched to Fahrenheit and now find it more intuitive than Celsius. If one is easier than the other, I assume it still doesn't make up for the hurdle of learning a new system.
> I wonder if there are people that moved to the U.S., switched to Fahrenheit and now find it more intuitive than Celsius.
I've done the move twice in each direction. Neither is more intuitive.
When I moved back to C after 22 years in F, I had to adjust again. It took a few months. The other times were after fewer years, but still took (re)adjusting.
For purposes of backup I don't see that large of a difference between a single installer executable and a zipped folder that you'd get after installing a non DRMed game from Steam.
GOG has allowed third party backup software like https://github.com/Sude-/lgogdownloader to exist. I have a full offline mirror of my GOG library that I update monthly that will never happen with my Steam library.
The non-DRMed steam game will stop working after a while if you haven't logged into steam after a very long time. If steam ever went under, your locally installed single player games that work offline will stop working. Ask me how I know.
I've taken to getting a cracked copy of every steam game in my library so that steam can't screw me over again in the future.
Off the top of my head: going in-person to the bank, email, phone call or sms to a number that you previously informed to the bank (say when opening the account), otp a la authy or aegis. None of these require you to be on google or apple's walled garden.
> Since 2020, the rate of bank branch closures in the U.S. has doubled. The majority of those closures come from large and very large banks, contributing to an overall 5.6% decline in total bank branches nationwide since the start of the pandemic.
Nor did GGP's approach require them to be in google or apple's walled garden.
That's exactly the point: there's an easy and common method that many people choose to use, but there is still a perfectly working method for people who choose to not use apple or google.
the part you are missing is that this is the situation for now. Emphasis on for now. Google are already moving to restrict what software your phone can run i.e. they control your device.
Please, don't be so obtuse just for the sake of argument. Any rational, well-informed person can wee where this is going.
I think the upthread argument is the weak one in that regard. "See how terrible it is that banks offer a new method to get more convenient service for people who have an Apple or Google device? Because I choose not to, I had to use a perfectly viable method that people relied upon for decades and that still worked just fine."
That's an example of how the banks are continuing to accommodate customer preference, not the other way around. As to "where this is going", ATMs and debit cards are nearly pervasive and, yet almost 60 years after their introduction, I can still choose to bank with a teller if I insist on not having a debit card.
Do you mind elaborating why a db partitioned like that is not enough for your registration example? If the partitioning is based on the email address, then you know where the new user's email has to be if exists, you don't need to query all partitions.
For example, following your partitioning logic, if the user registers as john.smith@example.com, we'd need to query only partition j.
You're right, the email address example isn't clearcut -- its not an issue at all at registration. From there, you could never allow an email change. Or you could just add a layer for coordination, ex. we can imagine some global index that's only used for email changes and then somehow coordinates the partition change
My broad understanding is that you can always "patch" or "work around" any single objection to partitioning or sharding—like using extra coordination services, adding more layers, or creating special-case code.
But each of these patches adds complexity, reduces flexibility, and constrains your ability to cleanly refactor or adapt later. Sure, partitioning email addresses might neatly solve registration checks initially, but then email changes require extra complexity (such as maintaining global indices and coordinating between partitions).
In other words, the real issue isn't that partitioning fails in a single obvious way—it usually doesn’t—but rather that global state always emerges somewhere, inevitably. You can try to bury this inevitability with clever workarounds and layers, but eventually you find yourself buried under a mountain of complexity.
At some point, the question becomes: are we building complexity to solve genuine problems, or just to preserve the appearance that we're fully partitioned?
(My visceral objection to it is, coming from client-side dev virtually my entire career: if you don't need global state, why do you have the server at all? Just give use a .sqlite for my account, and store it for me on S3 for retrieval at will. And if you do need global state...odds are you or a nearby experienced engineer has Seen Some Shit, i.e. the horror that arises in a codebase worked on over years, doubling down on an seemingly small, innocuous, initial decision. and knows it'll never just be one neat design decision or patch)
Check the other partition for the user name. Create the new user with the same pointer (uuid, etc) to the user’s sqlite file, delete the old user in the other partition. Simple user name changed. Not really that complex to be honest. (After thinking this through I’m probably going to suggest us changing to sqlite at work…)
> if you don't need global state, why do you have the server at all?
2 reasons I can think of right off of the top of my head are:
- validation (preventing bad actors, or just bad input)
> Sampling uniformly such that each distance is equally likely across the line gives at least a 90% chance of choosing a rational.
Let's say the numbers are targets on the line. Your distribution implies the range 1-9 is less dense with targets than the range 9-10. Doesn't that mean you're less than 90% likely to hit something between 1-9?
> You are NOT more likely to throw a dart that lands in 9+ just because you have magically introduced an infinitely tense series of irrationals in that range.
If we turn this around, by forbidding a bunch of values in the 1-9 range from being hit, then won't the probabilities get skewed towards the 9-10 range?
No, because a dart throw is not a uniform draw from set elements. Is a uniform draw of length which the inclusion of irrational numbers does not affect. You are 90% likely to throw something in the first 90% of the line. It doesn’t matter if we say we will round anything in [1,2) to 1. There’s a ten percent chance of falling in that range.
Not a 0% chance because there happens to be an uncountable infinity number of options in [9,10)
There's the Cobra Effect popularized by Freakonomics
Too many cobras > bounty for slain cobras > people start breeding them for the bounty > law is revoked > people release their cobras > even more cobras around
Among the interesting revelations: the rat problem was concentrated in the French Quarter of Hanoi, as that's where the sewerage system was developed. What drained away filth also provided an express subway for rats. Which had been brought to Vietnam by steamship-powered trade, for what it's worth.
(That's only a few minutes into the interview. The whole episode is great listening, and includes a few details on the Freakonomics experience.)
The Cobra Effect is an example of a Perverse Incentive, which is where an attempt to incentivize a behavior ends up incentivizing the opposite: https://en.wikipedia.org/wiki/Perverse_incentive
I think most of the examples fit this, but a few don't.
Really the only complaint I have about the article is this separate heading was unnecessary, and signaled to people who read fast with a short attention span might take that short section as “author assumed knowledge not in evidence”/“I’m not the intended audience”.
reply