If they win, the US government collected taxes they shouldn't and those would be returned. Saying the "US taxpayer will pay for it" is equivalent to saying the US taxpayer pays for your tax refund. (And also, Nintendo is a "US taxpayer.")
The consumer did pay for it (not "taxpayers", per se) . Tarriffs went up, prices surged, and consumers paid that. Now companies get a refund and probably won't lower prices unless they feel there was extremely adverse effects.
It's completely irrelevant if the consumer won in any of this.
It's about if the United States is a country that respects the rule of law, or some failed 3rd world state, where the law is only respected if the dear leader likes it.
The first one is much better for economic development
Twenty years ago, I was strongly anti IDE and pro text editor. In the last ~10 years or so text editors have gained features previously only found in IDEs and IDEs have improved their performance and brought in features from text editors. I would argue the distinction between text editors and IDEs at this point is academic.
The main difference is "IDEs" typically contain custom, ad hoc text editors in them. They don't allow you to build transferable skills that can be used to edit any text. People who use them will typically use some other editor to make documents, another one for their notes, and one per programming language.
I started using Emacs 15+ years ago because you can easily make it into an IDE, but it works for any text. Essentially it's like learning to use a kitchen knife vs buying a mincer, a grater, a food processor, a mandolin, and whatever other single-purpose tools they're peddling at the kitchen shop today.
Since then, the Emacs way has caught on. I see stuff like Atom and VSCode as just vastly inferior forms of Emacs. They can all be text editors or IDEs if you want them to be.
>People who use them will typically use some other editor to make documents, another one for their notes, and one per programming language.
I'll never be convinced that that is a bad thing. And honestly, by the time you make emacs have the features that dedicated editors have, it's not emacs anymore anyway.
I'm (still) very interested about this project. Two years ago, I came across this when setting up a Raspberry Pi based "home lab" Kubernetes cluster (https://github.com/tantalic/shaving-yaks). I ran into some issues (I believe all Raspberry Pi specific) and ended up going with k0s. While I am happy with k0s, I do wish Kairos worked out for me and I might have to give it a try again soon.
I have been a happy Base user since 2011. I don't use it all that often, but anytime I need to explore a database file or take a CSV and turn it into a database for some investigation it is the first tool I turn to. Happy to be able to be able to pay for an upgrade after this long!
For anyone who thinks that may be a hand wave, there isn't a standard way to normalize email addresses. If you're building to the spec, then the local part can be processed case-sensitively, so Django lowercases the part after @ only. Others strip out stuff like gmail's +tags and really get into the weeds of how different email providers process emails.
In my mind, the "Right Thing to Do" would be to follow the precident established by OpenPGP's `.well-known` email-hashing in Web Key Directory (not the prefix of course, and barring technical arguments justifying deviation, which may be considered on merit).
> SHA-1 hashed and z-Base-32 encoded [to distinguish it from a fingerprint]
> The local part is always lower-cased before the encoding. [...] A common example for case-insensitivity are visiting cards which capitalize the canonical lowercase mail address for easier reading.
reply