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.
It's a bummer docker still doesn't have an API to explore image layers. I guess their plans to eventually transition to containerd image store as the default. Once we have containerd image store both locally and remotely we will finally be able to do what you've done without the registry wrapper.
You're bang on, but you can do things with dive (https://github.com/wagoodman/dive) and use chunks of the code in other projects... That's what I've been doing. The license is MIT so it's permissive.
But yes, an API would be ideal. I've wasted far too much time on this.
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 forget that governments built the grid. Then they sold them, usually for far less than they're worth to "friendly" companies to get some money to spend. These companies, in a complete baffling coincidence then provided a suspicious number of those politicians with board seats after they retire from government, or "government liason director" positions and the like. Now the government is forever paying interest ... well, not so much the government, of course, the customers are. You and me. The government got the money, spent it, it's gone.
BUT, a while ago rich people started to get off the grid. And this has advantages, such as much greater flexibility in where to live, so they did.
Middle class people could get off the grid, which ironically the government paid them for. So they did.
Companies largely got off the grid (it's more complicated, they built solar plants, then sold the electricity for electricity at night or somehow traded with grids, and locked in these contracts for decades). So they're effectively off the grid.
So who's paying this eternal interest that keeps increasing?
Who isn't off the grid? The governments themselves, and poor people. Governments have, of course, decided they don't pay for the grid themselves (not even for maintenance). It's in your electricity bill ... which due to government financial responsibility (such as the previous German government entrusting all this ... to Putin. Yes, really, that Putin) ... is climbing fast. One might add that one story is that the head of the government that entrusted German energy to Putin was threatened during an official visit to Putin ... by Putin setting dogs on her (he had read she was terrified of dogs) ... she STILL went through with entrusting the energy infrastructure to Putin. Then Ukraine blew up a major part of the infrastructure Putin built. You can't make this up. Personally, I'm the sort of person that if someone sets dogs on me ... anything after that is going to be a tough sell.
So now poor people effectively have an extra tax in high electricity prices that are climbing fast (the increases are now down to 5x the rate of inflation. Yes, DOWN, that's correct). Oh and to make matters worse, as the article points out, it's become ever easier to get off the grid. Which means the people served by the grid ... still dropping. Not just houses in suburbs are disconnecting, but city houses as well. And there may be other reasons. It's green. Or my favorite: the Israeli reason (these people are brilliant and insane). Convincing people to buy solar power because ... it does not disconnect in case of war. Apparently it's popular in Arab countries too.
Since this allowed past governments to spend more money, they now have no problem spending a less, or paying that money back, of course. Yes, that last sentence was a joke. No, in reality they're coming up with ever crueler and more forceful methods to make sure poor people pay the extra tax, such as making it non-dischargeable. Making it a crime to disconnect from the grid. To take it out of unemployment benefits before the person sees the money. To threaten everything a person has in case of non-payment (e.g. school subsidies for their children). Etc.
It isn't working.
Oh and that this debacle, which is entirely the decision of the currently in power party, even if the head of the government was swapped, is driving people in droves to other parties (ie. AfD), is the fault of Zelensky, Putin, Musk, Netanyahu ... and frankly everyone ... except of course the party that actually did it.
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.
I think this is true of a lot of things that are 'in our house' (or on our property). A fatuous hypothetical example might be a large central refrigerator shared between multiple properties.
The apartment building I live in has large central boilers for the hot water, to save space in the apartments. This benefitted the property developer, and is probably more energy efficient (although, just like our solar power example, transmission loss needs to be accounted for), but has downsides for the apartment residents.
A better example is private vehicle ownership, as opposed to public transport. It's a good example of something that has moved from a more centralised control to individual control, with benefits and downsides.
What's the downside of the central hot water? (Or heating.)
I've lived in buildings with this, and others (houses) without, and I much prefer the former. There's nothing I need to maintain, and the 'big' version seems to be more reliable than the single-house-sized heating equipment. The one time I remember the hot water being repaired, the janitor stuck up a note explaining that due to some sort of redundancy we'd still have hot water, but it would be less hot than it was supposed to be.
This wouldn’t be true in modern buildings, but in our case the hot water supply isn’t reticulated, and I’m at the ‘end of a (pipe) line’ so if no-one else sharing the same hot water pipe as me has run their hot water taps for a while, it can take 4 minute to get hot water in the shower.
This was bought up in a body corporate meeting several years ago. The cavities that the pipes run through are small enough that a reticulated system would be hard to retrofit. The suggested (tongue-in-cheek) solution was to “wait until you hear your neighbour showering before you have your shower.” Haha - thanks.
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.
I was just reading Arriving Today[0] which mentioned that people have studied pay-per-mile for US truckers and come up with pretty clear payment rates that are needed to support safe driving behaviors. I think it was about 60c/mile was majority safe speed and length of drive, but the average is 30c/mile and for individual truckers contracting out, it pushes down towards about 20c/mile.
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?
Banks don't have much initiative for investments in IT security. They have insurances.
That's why IT sec all around banking is just the bare minimum required by regulations.
Those sec-specs are also usually at least one decade behind the state of the art… And they get updated only extremely seldom as this would cause "a lot of paper work" at the banks, so the banks are always against any changes to that regulations; and if something changes finally it takes the banks again at least half a decade to adapt to those changes; they can do it like that as the time windows to comply are usually set to be very long, because you know, it's really a lot of paper work…
If each card were a public/private keypair, you could sign a message authorising a payment of X amount at current time, in zero knowledge, without leaking your secret (the credit card number) in every transaction.
Add two factor authentication, if you want, but fix the underlying giant issue first.
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.
I have memorized the CVV for one card I use, and the rest is saved in the browser. So, having to actually get out the credit card would be adding a minor inconvenience. That doesn't matter too much for me, but it probably does mean many millions in revenue for retailers.
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.
