First one is definitely AI-ese, but the rest, I cannot tell if they are just business platitudes or AI. Sigh.
433 karma · joined October 10, 2012
Each RGB pixel would be 2x2 grid of
``` G R B G ```
So G appears twice as many as other colors (this is mostly the same for both the screen and sensor technology).
There are different ways to do the color filter layouts for screens and sensors (Fuji X-Trans have different layout, for example).
the good thing is that you afterwards the cap table of the subsidiary or the spunoff can evolve (ex: waymo / amp can raise money independent of the parent company).
I don't have a skin in the game, but I personally think that the definition of FOSS is too rigid and strict and is not evolving. There has been many challenges over time (LGPL's linking exception, tivoization, AGPL trying to fight against SaaS, Open Core business models, ...); and we are really bestowing very harsh moral standards for people who are trying to do the right thing.
For me, Sentry, being 10+ years in its existence (I used it ever since its logo was a Starcraft II unit), never participated in the usual enshitification of the software, being labeled as "NOPE" is disingenuous. I would gladly pay for Sentry because I love the software, and I also know that if shit hits the fan, I can self-host it (though the configuration for self-hosting got progressively difficult over time, but that's the complexity of modern SaaS stack). I can make similar arguments to other tools in this site that I'm familiar with.
"creating the first ever first-class language with green-threading at its core."
... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the sync/async function coloring nightmare.
I think channels have too many footguns (what should its size be? closing without causing panics when there are multiple writers), thus it's definitely better "abstracted out" at the framework level. Most channels that developers interact with is the `Context.Done()` channel with <-chan struct{}.
Also, I'm not sure whether the go authors originally intended that closing a channel would effectively have a multicast semantics (all readers are notified, no matter how many are); everything else have pub-sub semantics, and turns out that this multicast semantics is much more interesting.
I like the term "market economy" or "commercial society" more, because it does capture more of what's happening on the market and the society.
Though, this was a real product, with almost 10 years of operation; very few products last this long, and the product wasn't immediately shuttered after the acquisition, so it is unfair to categorize them into the same OIJ bucket.
In general, the whole `==` versus `===` is a silly argument in a typescript codebase, because if you know the types of the arguments, `==` behaves predictably.
It feels quite ridiculous, especially if you are managing "soft" resources like IAM roles via Terraform / Pulumi. At least with real resources (say, RDS instances), one can argue that Terraform / Pulumi pricing is a small percentage of the cloud bill. But IAM roles are not charged for in cloud, and there are so many of them (especially if you use IaaC to create very elaborate scheme).
- 1. multiplexing protocol implemented on top of HTTP/2 - 2. serialization format via protobuf
For most companies, neither 1 or 2 is needed, but the side effect of 2 (of having structured schema) is good enough. This was the idea behind twrip - https://github.com/twitchtv/twirp - not sure whether this is still actively used / maintained, but it's protobuf as json over HTTP.
More plausible scenario is them becoming an abandonware, but even in those cases the community can carry the torch.
For example, BigQuery has natural support for arrays and nested data, and it's quite nice / essential for good data modeling. For example, "tags" can be stored as `Array<Struct<Key, Value>>`, and this can be used to implement things like, "search with fields with particular tags".
This reduces the cognitive burden of remembering which tables join with which, especially if we know that a relationship is solely relevant in one context. I.e. Tags can only be joined to the main table, and no other joins are sensical.