Physically they can ramp down to 50% but generation is pretty much a sunk cost at that point so it makes the bad economics even worse. That would mean that you are paying of the order of $240/MWh instead of $120/MWh.
For comparison solar/wind are about $30-40. Levelizing with pumped storage pushes that up to $60-$70.
IIRC France and Germany almost exclusively use gas for load following. Even at current prices it's vastly cheaper than using a NPP to do it.
When capex costs more than other technologies plus storage, and it reduces your neutron economy and thus the life of your fuel it's just curtailment with extra steps.
There is a distinction between being able to access the source code, and a tool giving it to you without any context of the underlying license it is governed by.
GP was saying that GitHub has an unfair advantage in that they have instant access to all GitHub code, whereas everyone else is rate limited.
I'm pointing out that this limitation is not meaningful because everyone can access all GitHub hosted source code through BigQuery, where they won't be rate limited.
Good teams still document these. Amazon is apparently a leading example where the documents are considered the source of truth.
However many organisations have limited technical leadership enforcing quality, and management layers not willing to invest in these assets.
Unfortunately some 'modern' practices are being interpreted to make the processes like Agile the most important thing, and reducing the importance of things like code/system quality and knowledge management.
Yes, but you would split a monolith into smaller microservices. It's inaccurate language to say you'd split a monorepo into smaller microservices (as GP describes), that's a conflation of two different but related concepts.
The OP is incorrect, most of the large organisations he cites do not practice trunk-based development.
Google has a monorepo and what could describe as 'submit patch for code review'. Only certain engineers can approve reviews and trigger the patch being applied to the trunk.
Many of the others also have variations, but unlikely that any organisation with 1000+ engineers has a monorepo with all of those engineers directly committing to it.
Google collects immense of data about people's actual visits.
Backlinks used to be a proxy for how authoritative things were
You don't need the proxy when you have the record of where people actually visit.
That's very effective for the top results. But if legit sites cannot rank in the first spots they'll get orders of magnitude fewer visits than the scam sites that employ SEO hacks to get the first places.
Very few large organisations, and zero distributed ones like a collection of multiple government departments, can turn around a massive collection of security fixes in 2 weeks.
I believe Google's Security team usually gives vendors 90 days before they go public.
ES had a business model. It was open-core, but with critical features like Security and Access-Control hidden behind their paid support.
The core disagreement was that Amazon (and many other contributors) wanted to add that to the base distribution, and Elasticsearch fought them for years on it, deliberately breaking any community plugins that got a solution working.
Enough blame for the current situation on all sides.
Yeah, I simplified things for the sake of argument, but just to be clear, the whole open core business model was a huge conflict of interest and has convinced me that open core is a way worse conflict of interest than other ways to monetize (enterprise support, operating cloud service etc).
So, to call Elastic a successful open-source business model isn't quite accurate, and you're correct to point that out.
I don’t, I work for a non-profit that refuses to run proprietary software such as Elasticsearch 7.1.1 in prod. Not sure why you made that blind assumption. Very bizarre.
Thank you for pointing this out. I used to run elasticsearch on a project and these pay walled features were a large source of frustration to the point that eventually I recommended moving it to the AWS service because we were already paying amazon anyway and in a large organization it is a huge pain to contract another vendor.
