That is a bit extreme. Wanting to preserve the environment isn't the same as wanting to let everyone starve, it's quite the opposite. Spend a minute or two looking up soil erosion, and extrapolate 100 years.
It depends who's definition of organic you are using. Demeter and Biogro, which are the certifications I am familiar with prohibit most conventional artificial fertilisers.
I grew up on an organic orchard, so don't get excited about artificial sources of nitrogen for agriculture and horticulture. It is better than getting fertiliser from fossil fuels, but it is still not great.
I naively sent the Docker developers a PR[1] to add this functionality into mainline Docker back in 2015. I was rapidly redirected into helping out in other areas - not having to use a registry undermined their business model too much I guess.
Wow. Did you read the next three paragraphs to the end of the article:
| Policymakers are now attempting to come up with solutions. “You can make solar play nice with the grids,” ...
| Yet the best solution would be for energy firms to respond to the competition and sort themselves out.
The article is talking about:
* how solar is disrupting the traditional utility model
* in countries where the utilities provide a poor service wealthy people are doing there own thing producing their own power with PV
* how this leads to less customers for the utility leading to more expensive power for people who cannot afford to generate their own power
* that solutions like grid-tied home PV instead of independent systems provides a better outcome for everyone in the area.
I don't think it it to much of a stretch to say that the article is advocating for, as you say, "a hybrid centralized baseline + local generation and storage."
You are reading that very narrowly. The paragraph is simply pointing out that solar power is cheaper when built out in a centralised way because of:
* economies of scale for construction and maintenance
* higher utilisation. They don't spell it out exactly, but it is pretty clear fro m the context that, "lots of self-generated power will ultimately be wasted", is eluding to a wider geographic area needing more panels to satisfy all demand when each house has an independent system, rather than being grid tied.
Sounds like as well as mandating limited on-duty time government needs to mandate pay for waiting time is same as pay for driving. This would reduce the incentive for drivers to drive more hours.
This is not so straightforward when drivers are paid by the kilometer. In such cases government could mandate minimum waiting pay rate is average equivalent hourly pay rate of driving hours from same shift, or such like.
This would be more secure than what I proposed, but requires changes that are out of the control of the credit card companies.
For the card to sign the transaction, you need to add some kind of card interface to the users device. Maybe this is what happens with chip cards when you use it at a shop with a card terminal.
Sure, there is a trade off, but they have it wrong for online fraud from stolen credit cards.
The three digit CVV code should be a one time passcode (OTP). Banks have been using these since the 1990s for online logins.
Using 90s technology, the card issuer would issue one of these OTP fobs along with the card. It has the card number printed on it, a button and a LCD screen where the OTP is displayed. The CVV is already sent through to the computer that authorises the transaction, the software that checks the CVV would need to be changed.
So we have a trade off of the user having to have a separate thicker card, to fit the battery, for online use.
I just googled, you can get batteries that are 0.4mm X 22mm x 29mm, a credit card is 0.76mm. Eink is old technology now with the right performance characteristics. I suspect in volume using this technology you could integrate the OTP device in the standard card form factor for less than a couple of dollars a card.
So with a bit of innovation the friction of payment / fraud tradeoff goes away.
This all strikes me as fairly obvious to someone designing these things, is there another tradeoff going on here?
For reasons I wont go into here, I built a system with a similar approach 10 years ago. The system was horizontally scaleable. There was no database tier, instead each server had a replica of the database locally which were used for reads. The servers discovered each other other and nominated one server as the master, which writes were sent to. Replication was done by having the master sending the DML queries to a writer process on each server. When a new server joined the cluster it was sent a copy of the entire database and a stream of queries for it to catch up before it joined the cluster. There were other tricks to make sure reads from replicas waited until the replicas were sufficiently up to date.
It worked fine as the system was read heavy and write light. SQLite serialises writes so does not perform well with multiple writers, particularly if the write transactions are long running. Reads were blazingly fast as there was no round-trips across the network to a separate database tier. The plan for dealing with performance problems if/when they arrived was to shard the servers into groups of customers.
I moved on and the next developer ripped it out and replaced it with Postgres because it was such an oddball system. I came back six months later to fix the mess as the new developer messed up transactions with the new database code.
Technically using SQLite with replication tacked on works fine. Superficially it is all the same because it is SQL. However the performance characteristics are very different from a conventional Multi Version Concurrency Control databases such as Postgres.
This is where the problem lies with this kind of database - developers seeing SQL and assuming they can develop exactly the same way they would with other SQL databases. That said I love approaches that get away from the database architectures of last century.