> the old snapshot has security holes attackers know how to exploit.
So is running `docker build` and the `RUN apt update` line doing a cache hit, except the latter is silent.
The problem solved by pinning to the snapshot is not to magically be secure, it's knowing what a given image is made of so you can trivially assert which ones are safe and which ones aren't.
In both cases you have to rebuild an image anyway so updating the snapshot is just a step that makes it explicit in code instead of implicit.
where does the apt update connect to? If it is an up to date package repo you get fixes. Howerer there are lots of reasons it would not. You better know if this is your plan.
You get fixes that were current at docker build time, but I think GP is referring to fixes that appear in the apt repo after your docker container is deployed.
If you've pulled in a dependency from outside the base image, there will be no new base image version to alert you to an update of that external dependency. Unless your container regularly runs something like apt update && apt list --upgradable, you will be unaware of security fixes newly available from apt.
Kuala Lumpur gets (generous assumption) about 100 lightning strikes per square kilometer per year [0].
If a single drone could service a lot of square km, then it could conceivably collect a lot of electricity. E.g. if it could service 20 square km: 20 * 100 * 8mWh = 16gWh per year. Not bad, but an upper bound, and it hinges a lot on that first parameter (service area).
True that an offshore wind turbine can produce 15MW. But it can cost $100m+ just for 1 turbine (built and installed). If drones are going up anyway (to protect a city/citizens from strikes), then electricity generation is effectively free, and the marginal cost is equal to the hardware required to capture it (maybe relatively low).
You don't just need to cover the 350km² with drones though, you also need buffering and/or transmission capabilities for absurdly high amounts of power (=> but low amounts of energy).
If you wanted a single buffer for the whole 350km², you'd need transmission capability from any point (or any drone launch station) to your central buffer in the Terawatt range (currently our highest power grid links are in the ~10GW range, so this is pure fantasy already). Utilization (~ capacity factor) for the lighting capture infrastructure would also be abysmally low. You'd basically need to build a ~10TW (generous estimate!) system, where costs in a lot of components directly scale with power, just to get ~10MW of sustained power out.
There is no way you are ever gonna compete with that $100M wind turbine; you could literally have cheap, high-field, room temperature superconductors and be gifted several warehouses worth of supercapacitors, and the whole lighning capture boondoggle still would not make any economic sense.
One major downside is that it becomes really hard to do transactions, especially across multiple files. If you store mostly immutable data though like git (where except the refs every object is immutable, mutating creates a new object) it can work nicely.
Hmm... is the mutability of data really enough to create a need for transactions?
For example here on HN (which afaik also stores the data in files) you can change a comment you wrote. But that type of mutability does not call for transactions, right?
I for one enjoy the convenience of automatically installing python versions. Yes I know how to do it manually. Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions. For that, it's also okay if it does not install the most performant version of the interpreter.
>Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions
You only have to do it once per version with this approach. Then you can create venvs from that base, and it's basically instantaneous if you do it `--without-pip`.
Sure. We've had system package managers for decades. I install a major version once a year and it gets automatically upgraded to the latest patch version by my system package manager, just like everything else.
The limit could depend on a lot of other things. In theory, it's possible that you are paying 100% of revenue on debt service yet still the best option is to take on more debt. This is if you believe that investing the money raised via additional debt provides returns that outweigh the increase in debt service costs. So in that situation, additional debt can even lower the debt service / income ratio.
So this is meant to illustrate that the limit on debt is more a function of the concrete circumstances. In this line of argumentation, debt is not limited by a mathematical formula that just takes GDP and similar statistics as input.
Your analysis leaves out one teeny tiny little thing--the ~6 Trillion dollar federal budget!
If you're paying 100% of revenue on debt service, taking on more debt isn't optional. All other federal outlays must either cease or be funded by new debt. Given current levels of federal spending, that would mean increasing the national debt by ~20% of GDP, per year.
More debt --> higher debt service costs --> even more debt --> even higher debt service costs --> et cetera
Yes, that is a limitation. But this limitation is not too bad.
In many cases, a bug in the translation simply makes the proof impossible. Somebody then investigates why the proof does not go through and finds the bug in the translation.
We only have a problem if the bug in the translation specificially cancels a bug in the original code. If there is no systematic risk, it is quite unlikely that two bugs cancel each other in this way.
Let's say you want to check if use after free can ever occur. Your translation is bugged and translates the whole program to a single "nop". Then the verifier happily asserts that the translated program does not cause use after free.
I doubt the translation would be that bad but it could have more subtle issues of the same kind.
My argument is that you typically also check other properties, like properties describing what your program should do. These other properties likely wouldn't be satisfied by a nop program, and hopefully the same is true for many subtle issues.
Do you know if redispatch costs are included as part of your transmission costs and how much they are? Because if they are, then investing into the transmission lines can decrease transmission costs since the providers need to pay less for redispatch.
I am no economist but couldn't it be that raising pay in few sectors does not cause inflation? I would think that depends on what the people receiving more money spend it on. If they only spend it on things where we have no bottleneck and there is still excess capacity, how would that create inflation? Inflation should only happen if the increased paycheck is used to compete for scarce resources/products. So I think predicting inflation requires a more detailed analysis, especially you need to have a cycle of increased prices and pay.
Length and capacity are two different things; a slice is a pointer and a length, but a Vec<T> (and Go's slices) are a pointer, a length, and a capacity.
That Rust and Go both have "slices" that are slightly different is, unfortunate, but that's just how it goes sometimes.
reply