Where’s the part where anybody defrauded anybody? This was clearly incompetence that benefited nobody (certainly the developers would rather not have TITAN implode and all of this USDC locked in a contract...). Embarrassing yes. Fraud? Pretty clearly no
Polygon right now has capped the number of validators at 100, and the protocol atop which it is built (Tendermint/“Peppermint”) only remains fast and cheap if the “active set” of validators remains small. Polygon team have said they will introduce an “auction” mechanism for new validators to join the active set, but one would anticipate that will just favor validators with large stakes (i.e. the existing validator active set). Cosmos/ATOM is the sort of keeper of Tendermint and responsible for the reference implementation and they too cap the validator active set at 125 or 130. Practically speaking none of these L2s are very decentralized. They are fast and cheap which is what most people want but practically pretty centralized...(i.e. project founders and early operators are totally capable of launching 50% or 2/3rds attacks...they probably just don’t want to, and the small “active set” of validators is likely to mostly stay the same). A genuinely decentralized PoS L2 (i.e. can accommodate very large number of validators) that is also fast and cheap is something I’d love to see
DigitalOcean Spaces offers S3 API compatible object storage (i.e. you can use any S3 client library without modification) and a seamlessly integrated CDN that is markedly cheaper than CloudFront: https://www.digitalocean.com/products/spaces/
Having used and written on this subject extensively, you are right but in practice these approaches mean something along the lines of making a single primary key lookup (like 0.1 to maybe 3ms in most cases) to save many tens or hundreds of queries (in addition to the cost of rendering/templating) to build the nested content, so it is still extremely practical.
Honestly, as a person who prizes Apple’s products and happily depends on them for work, personal life, etc. I think Tim Cook needs to either open up sideloading or be promptly fired and replaced by somebody who will. None of this sits well with me. It is a situation we do not need to be in. I agree that he is a moral coward, and in far too important and dangerous a position to be so.
I strongly feel that at this point the intuitive solution would be a broad boycott/protest of Apple’s products until they elect to allow sideloading of applications on iOS. They shouldn’t even _want_ to negotiate moral issues like this and I feel it’s just really ugly for them to be in a position to arbitrate matters of such gravity when they don’t have to be. Enough people will continue to use the App Store for convenience that I doubt it would have any substantial consequence for revenue, and even if it did, this is such an intuitively ugly thing that I would argue whatever the cost is it is worth it. Even dependent as I am on Apple products for my work, it may pain me too much to buy another if this is still going on come the time.
I have worked extensively in both frameworks and would add to this:
* Django has comparatively limited I18n and localization faculties compared to Rails (with Django’s i18n built atop gettext, which I always found kind of brittle with .po files/string-based keys)
* No intelligent/efficient class reloading in development. The whole development server just restarts when you make changes
* No reloader for the shell (horrible for developer ergonomics - you can't just type "reload!", you have to restart the shell to pull in any change)
* Caching faculties in Django are much more limited - no template digests (to make template fragment caching much more robust)
* ActiveSupport has also always been a god-send for productivity. It may seem small but things like “Array#to_sentence” and the time functions (i.e. 1.day.ago) are incredibly useful.
* No default assumption of multiple environments (no default development/testing/production configuration files, environment detection, etc). This is pretty ridiculous for a web application framework.
* No built in credential encryption (makes keeping a team in-sync with keys for integrations a comparative pain)
* Dependency management is much more challenging in Python. The de-facto virtualenv + requirements.txt combo is lossy (no dependency graph) and awkward compared to bundler. There are other solutions here but something so foundational shouldn’t be so hard.
Django was the first web application framework I learned and I still work with it professionally from time to time (as recently as ~2 months ago). I am just a bit stunned by how much it has fallen behind in terms of its broad state of maturity, community/ecosystem, productivity, etc.
I am surprised that nobody has raised the question of whether this is 15% of gross pay, pre-tax or 15% of net pay, post-witholding (well assuming W2 positions)? Those are very different things, especially in states like CA/NY where I imagine many candidates might end up being placed. In those contexts 15% of gross might be more like a 25-30% effective share of the developer's net income (?)
Just to add to this - it is true. I have researched this subject incidentally many months ago. ON Semiconductor is one of the more relevant companies in this domain. They are a public company with a market cap of $8.5B. You can look at their Ezairo series of system-on-chip products - they are built for digital hearing aids (with all consideration of power requirements, DSP/programmability etc).