It was involved in the previous one, but not in this latest one. All FL2 did was prevent the outage being even wider spread than it was. None of this had anything to do with migration.
If FL2 didn't have the outage, and FL1 did, the pace of the migration did have an impact.
Though this is showing the problem with these things: Migrating faster could have reduced the impact of this outage, while increasing the impact of the last outage. Migrating slower could have reduced the impact of the last outage, while increasing the impact of this outage.
This is a hard problem: How fast do you rip old working infrastructure out and risk finding new problems in the new stack, yet, how long do you tolerate shortcomings of the old stack that caused you to build the new stack?
EasyOCR is significantly worse than Tesseract for clean printed text and , while being orders of magnitude slower; far better than Tesseract for low-quality clean scans and extracting text from pictures (e.g. comics), which Tesseract does not as well.
> how all the popular dynamic languages have slowly become statically typed
Count the amount of `Any` / `unknown` / `cast` / `var::type` in those codebases, and you'll notice that they aren't particularly statically typed.
The types in dynamic languages are useful for checking validity in majority of the cases, but can easily be circumvented when the types become too complicated.
It is somewhat surprising that dynamic languages didn't go the pylint way, i.e. checking the codebase by auto-determined types (determined based on actual usage).
Julia (by default) does the latter, and its terrible. It makes it a) slow, because you have to do nonlocal inference through entire programs, b) impossible to type check generic library code where you have no actual usage, c) very hard to test that some code works generically, as opposed to just with these concrete types, and finally d) break whenever you have an Any anywhere in the code so the chain of type information is broken.
> the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right
See "But how do we solve arrays" part:
> > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the array
Tangential: is "without requiring knowledge of data patterns" a frequently useful requirement? I.e. isn't knowledge of data patterns basically required for any performance optimization?
Querying a local dictionary on each clipboard seems okay; having a feature to request remote dictionaries is okay; making it easy to combine both is dubious but understandable (would be better off as a special flag); but having them combined by default? That's pretty much malicious.
It's talking about querying youdao, which is more translation service. Offline translation < online translation, i.e. I don't want to fallback to local google offline translate language package unless I have no data. I don't use stardict, but it should be completely expected functionality if translating more than words like dictionary.
This entire article should be, Chinese translation program sends clipboard data to it's own website and chinese translation services, but on http.
It's malicious intent! The developer isn't a kid, they're releasing the software for world wide use. It's a simple thing, do not send private data to remote servers without explicitly asking the user!
The "Chinese values" excuse doesn't fly. We're not talking about a random Chinese person, we're talking about a Debian packager. Debian packagers should have values in line with the Debian project's ethos. It's difficult to imagine how somebody to whom Debian's values are alien could even accidentally stumble their way into the position of being a Debian packager.
Don't get me wrong, I'm not saying it's acceptable for a Debian packager, but I think that it's much more likely than malicious intent.
>It's difficult to imagine how somebody to whom Debian's values are alien could even accidentally stumble their way into the position of being a Debian packager
If that was an acceptable response we shouldn't accept people from those cultures into positions where they can affect our privacy. Or we can just stop using "cultural differences" as a bludgeon to whitewash bad behavior.
Not really because "Chinese" is being used here as an indicator of nationality, not ethnicity.
I disagree with using it that way because it feeds into the CPC's propaganda mission to conflate the ethnicity of "Han" with citizenship of the PRC, which aids their cultural imperialism ('Taiwan is "Chinese" and we are "China" so therefore people in Taiwan are our people!'). Also the definition is being stretched to include anyone with even the vaguest ethnic ancestry from within territory ruled by the PRC or historic empires ("China" is a word that basically means "empire")
Anyway I agree that people from the PRC are more used to throwing up their hands at invasions of privacy since the government having total insight into your life is a given there, and to many a positive thing (they may believe it keeps them safe). I also believe that growing up as one of one billion people gives one a sense of useless anonymity - who cares if someone sees your clipboard, there's just too many people for it to matter.
There definitely seems to be a cultural difference when it comes to privacy expectations from Chinese companies and western companies. Doesn't mean it's okay to do this kind of thing in a Debian package, of course, but I can understand how this could've happened.
I heavily recommend writing a known working version in there, i.e. `"httpx~=0.27.2"`, which, in the best case, would allow fixes and security patches (e.g. when httpx 0.27.3 releases), and, in the worst case, would let you change to `~=` to `==` in case httpx manages to break the backwards compatibility with a patch release.
And, of course, always use `if __name__ == "__main__":`, so that you can e.g. run an import check and doctests and stuff in it.
Import checks and doctests you can run before any script code anyway, and exit() if needed. The advantage of `if __name__ == "__main__":`, is that you can import the script as module on other code, as in that case __name__ will not be __main__.
reply