zbobet2012
That's a "large" organization problem. But large is actually, not that big (about 5-10 scrum teams before this is a very large problem).
It also means on critical systems separating high risk and low risk changes are not possible.
Like all engineering decisions, this is a set of tradeoffs.
> Chinese workers work longer hours more happily and they’re physically faster with their hands; they can do things that American labor can’t. It’s years of accumulated skill, but it’s also a culture that is oriented around hard work and education that the United States no longer has. In China, there are no people who are too fat to work. The workers don’t storm off midshift, never to return to their job. You don’t have people who insist on being paid in cash so that they can keep their disability payments, while they do acrobatics on the factory floor that the non-disabled workers cannot do.
It's an actual joke to present something with such a derogatory view of the median American worker with no data to back it up. Most of America's "labor class" is in fact Mexican, the country with the highest annual hours worked per year. Secondly hours worked does not relate directly to productivity. American workers are the most productive in the world. [1]
More importantly, _we don't manufacture like this anymore, even in China_. Doing "acrobatics" on the factory floor is now obsolete. Much of what's said here fails to acknowledge that we would _not_ build our supply chains the same way as China does. China had a surplus of human labor (one that's facing an impending demographic crisis) and so used human labor in ways modern western countries would not and do not.[2]
[1] https://www.weforum.org/stories/2018/01/the-countries-where-... [2] https://ifr.org/ifr-press-releases/news/global-robotics-race...
Reproducing these supply chains is more possible than this article states. Doing it via destroying our economy however will not work.
Now sometimes folks (the Windows team famously did this) build systems which identify which tests to run based on changes that occur in the codebase, but that's _not_ easy.
Agreed hybrid presents real opportunity.
Traditional codecs have always focused on trade offs among encode complexity, decode complexity, and latency. Where complexity = compute. If every target device ran a 4090 at full power, we could go far below 22kbps with a traditional codec techniques for content like this. 22kbps isn't particularly impressive given these compute constraints.
This is my field, and trust me we (MPEG committees, AOM) look at "AI" based models, including GANs constantly. They don't yet look promising compared to traditional methods.
Oh and benchmarking against a video compression standard that's over twenty years old isn't doing a lot either for the plausibility of these methods.
http://therisingsea.org/post/mast30026/
Has a good introduction to space, and the notion of a manifold, and what a Minkowski space is.
If you have more than 500k of assets in this form, you should have multiple funds and bank accounts.
Again, you need the collapse of the US currency if you are a) not exceptionally wealthy or b) not wealthy and incredibly financially uninformed.
That interest rates change is global.
The only situation where the value of the fund can be less than what you put in is the collapse of US currency, which savings account insurance can not protect against either.
And frankly if that's the case I wouldn't be betting on FDIC or equivalent insurance actually working anyways.
But even "less" secure ones are heavily regulated to be kept at 1$ of NAV and SPIC backed.
Simply addressing compression efficiency without considering the other constraints makes for an impractical codec.
If your encode complexity is too high, then you can't handle real-time (live) use cases, and your compute requirements may make practical use for large libraries like social media impractical.
If your decode complexity is too high mobile devices will suffer from severe battery drain or simply won't be able to decode, even in hardware. Dedicated hardware may also have to much complexity to implement in a cost effective way.
For example his note about "Categorical descriptions" and then the explanation about maps/and spec at 25:00[1] seems to indicate he's unfamiliar with the difference between extensional and intensional type theory.
The core difference between the two is extensional type systems decide equality on the observable behavior of the output. For example if two functions take the same input, and produce the same output extensional type systems/theories say they are the same. The problem with this is type equality is then undecidable.
Extensional type systems also struggle because there are more than one way things might be equal! For example two string might be equal if you ignore case, but unequal if you don't. So if we want our type system to check if two functions are equal under case insensitivity an extensional type system will struggle with this.[2][3]
Now in fairness to Rich, these concepts come more from the math community, especially the notion of types being equal under different paths, and in the case of Homotopy type theory are burred in unapproachable language and concepts... even by mathematicians standards.
He also talks about select from spec, and it not preventing you from passing types broader types, and the necessity of specifying deeper type.[4] But, that's just an eliminator defined on the type[5].
Now most strongly typed programming languages suffer from the issue he identifies when talking about not making brittle systems [6] and the issues you get with coupling around taking a map/struct/product type C = A X B (e.g a map C = {A: something, B: something}), and you require A so you're function should be good but you fail to compile because the function says A, and now you're passing C.
It's frankly pretty annoying in places like Java that if you have a Point = Int x Int y you can't use it in functions which take a Tuple = Int x Int y. I'd actually say that's the common observation that both Rich, the Go Inventors, and the TypeScript folks have all made. You need to care about the extensional type of your input (and output) fairly often. And carring around the intensional type causes both dependency issues and just some general PITA's.
[1] https://www.youtube.com/watch?v=YR5WdGrpoug&t=1504s [2] https://math.stackexchange.com/questions/4486995/what-is-an-... [3] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Ext... [4] https://youtu.be/YR5WdGrpoug?t=2668 [5] https://www.quora.com/In-type-theory-what-is-an-eliminator-a... [6] https://youtu.be/YR5WdGrpoug?t=2823
I will also say I used clojure + aleph to write the only significant application I ever released which never had a reported bug or outage. It ran for seven years and that application was under constant heavy load (more than 10k TPS).