How could we make enough antimatter to do something useful? Would we need to go hang out near the sun or deorbit Jupiter's moons with superconducting coils to get enough energy?
Shot exchange is a huge problem, made even worse by the arrival of cheap drones. But you're implicitly assuming that the adversary is on roughly equal economic footing. If your defense budget is $800 billion and your adversary's defense budget is $8 billion, you can afford to spend 100x as much shooting down their missiles as they spend lofting them.
There's also a danger in projecting linearly from the beginning of a war, where invading forces both tend to use more expensive stand-off munitions and also have to deal with more aggressive missile launches. As the defender's own air defense system gets degraded, the invader can switch from expensive long range stand-off munitions to cheaper stand-in munitions (like glide bombs) launched from much shorter range. Additionally, the invader will be able to diminish the defender's ability to launch missile strikes in the first place, either by destroying the launchers, the missiles themselves, or their production, thus reducing the demand on expensive high-capability interceptors.
Drones and mines continue to offer asymmetric warfare options that are very hard to counter without a robust low side on the high-low mix. Ukraine are the world's leading experts in this currently, and hopefully are involved with US and Gulf forces to try to improve this shot exchange ratio.
I am assuming nobody is using nukes though. That completely changes the picture. One must always assume "(some of) the missiles will get through". Traditional MAD does not require boots on the ground - merely the assurance that if Iran gets one nuke through and hits New York, the USA will respond with 100+ nukes. The real question then is what the other "large" nuclear powers (Russia and China, primarily) will do in response to that.
Defense budget is an abstraction. At the end of the day, there are only so many factories with only so many raw inputs producing only so many interceptors per day. You cannot simply increase the defense budget in the event of a war of attrition and then attempt to outspend your enemy. And this is beside the political unpopularity of high defense budgets in peacetime, when they would need to be higher, to build the industrial capacity ahead of when it would be needed.
All true, and of course the $900B plus defense budget of the USA is not dedicated to interceptors to the same degree that Iran's $8B is dedicated to missiles. Shot exchange is fundamentally an economic problem though. The USA is not going to go broke shooting down missiles - they're going to run out of interceptors. Money is a much larger constraint for Iran than the US, but even there, the real constraint is military and diplomatic.
How does this guarantee a political and strategic win for Iran?
Iran was already teetering on the edge of being a failed state: socially, economically, environmentally, and agriculturally. Iran is expending expensive ballistic missiles to force those THAAD and Arrow shoot-downs. Yes, they're winning the shot exchange ratio, but their economy is orders of magnitude smaller than the US. Besides, unlike the Gulf states, the US and Israel are not just sitting around playing defense. They are systematically destroying substantial fractions of the Iranian war machine and have both threatened and attacked domestic and international energy production, the lifeblood of the Iranian economy.
The only true winner of this war, however it shakes out in the end, is Russia. All of the Middle Eastern powers aligned with the US are going to be desperate to rebuild their interceptor stockpiles and will surely get priority over Ukraine, likely for a very long time as the production rates are very low as you've pointed out. Plus, Russian gas and oil are worth a lot more than they were prior to this war, and are being allowed to trade more openly as well.
Iran already bled enough high end regional interceptors, the strategic balance is if they can build enough moped shaheeds that can be assembled in garages to overwhelm whatever comes in theatre. And we know upper limit of US+co interceptor production for next 3-4 years. Economic size =/= productive capability. Ultimately Iran with survivable regional strike complex can existentially threaten gulf state adversaries who are all dependent on desalination while Iran, as shit as their water crisis is, is not. UAE, Qatar Saudi and Israel are like 70-90% desalination. They can threaten Iran economic lifeblood, Iran can literally end their lifeblood. Iran simply has massively more lethal/credible escalation dominance vs GCC. Iran already being failed state ironically allows them to escalate harder - they have much less economy to lose, vs GCC losing economy and biology.
Ultimately if Iran locks down Hormuz long term they can transit tax their way to prosperity, and if they can convince PRC to be enforcer of petro-yuan (big if), they'll basically get unlimited hardware to do so. Not that burning bridges with GCC is PRC first choice, but if Iran can lock down Hormuz, they have leverage to compel PRC to accept arrangement because it's worse than no Hormuz energy. The spoiler obviously is US who would rather toast GCC oil than lose petro dollar. Or Israel being nuke happy.
The secure boot "shim" is a project like this. Perhaps we need more core projects that can be simple and small enough to reach a "finished" state where they are unlikely to need future upgrades for any reason. Formal verification could help with this ... maybe.
I'm gonna keep saying this forever - there are two obvious "killer apps" for crypto:
1. Semi-private blockchains, where you can rely on an actor not to be actively malicious, but still want to be able to cryptographically hold them to a past statement (think banks settling up with each other)
2. NFTs for tracking physical products through a logistics supply chain. Every time a container moves from one node to the next in a physical logistics chain (which includes tons of low trust "last mile" carriers), its corresponding NFT changes ownership as well. This could become as granular as there's money to support.
These would both provide material advantages above and beyond a centralized SQL database as there's no obvious central party that is trusted enough to operate that database. Neither has anything to do with retail investors or JPEGs though, so they'll never moon and you'll never hear about them.
Not only do you not need the blockchain for either of those things, you don't want it.
Think it through. How do you actually "cryptographically hold" someone to anything? You take them to court.
Guess what you can do, right now, without the blockchain? That's right, you can take them to court.
You're just reinventing normal contract law with extra steps.
The cryptographic part doesn't even help you when you can just say in court that "here are our records that show we gave them these packages, here are our records of customers filing complaints that they never got them" and that is completely fine.
This exact thing happens too often. We try to use fancy technology to solve a non-texhnical problem.
With or without blockchain you end up at court. If you build a decentralized trust system, the builder of the system needs to be trusted. If you want to use decentralized trust to do your taxes or other government communication you still need to trust your government. These are all actual examples i’ve encountered.
You pretty much always end up at the legal system. If there js anything to make big impact on it would be that. But that requires world-wide revolution.
AFAIK both of these use cases had many millions of invested dollars dumped into them during the Blockchain hype and neither resulted in anything. It might not be an exact match for (1), but there was famously the ASX blockchain project[0] which turned out to be a total failure. For (2), IBM made "Farmer Connect"[1], which is now almost entirely scrubbed from their website, which promised to do supply chain logistics on a blockchain.
> ASX blockchain project[0] which turned out to be a total failure.
FWIW if you know anything about the ASX, you'll know that the failure was a result of the people running the ASX and not necessarily the tech behind it.
IMHO, most people misunderstand the real utility of crypto.
The thing to keep in mind is that replacing a database with computationally expensive crypto is sub-optimal. Supply Chain tracking falls into this category: why crypto over barcodes and a database?
Governments use Banks with their deterministic processes to manage and guarantee transactions. This is where crypto shines- replacing the entire banking system as an intermediary to manage and guarantee transactions. Crypto can do this better and cheaper than Banks.
There are other domains where the government is the backstop/guarantor and leverages intermediaries to manage the scale. Real Estate comes to mind. Identity is another. Crypto can be useful there.
One last useful crypto application is to replace governments themselves as the backstop and final/guarantor for transactions.
These are ideas that evoke strong reactions. There's a reason the inventor of crypto is anonymous, to this day.
The only "killer app" for crypto*currencies* is being a payment method. Not counting speculation. This is what they are used for right now, but the scale at which this happens doesn't justify their current valuation (even after recent losses).
But is that a better experience than just using your visa? Nobody wants to wait at the cashier for 15 minutes to pay for their groceries, which is what has to happen if you really want the decentralized experience. Otherwise you really are just reinventing a worse, centralized payment rails. Volatility and wait times are features of crypto, not bugs, but they make for terrible payment experiences.
Doesn't lightning settle basically instantly, while still being decentralized? You're just trading signed transactions iirc, with settlement happening whenever.
The settlement happening whenever is a problem. Instant authorization is very different from a practical settlement model.
At least with card networks, there are layers of liability if solvency issues occur. There’s merchant protections from the acquiring bank and if for some reason the acquiring bank fails there is the guarantee of the card network.
On the issuing side there are chargebacks. I hate chargebacks as much as the next startup bro but consumer protections are a necessary aspect of a functioning payment rail. There are reasons we don’t use ACH for everything.
I think hand waving the pesky settlement details is absurd. The settlement process is the payment rail.
If you do want those protections you end up back with a custodial wallet, which brings us back to a centralized model.
I’m not arguing crypto doesn’t have its place in the universe, I am arguing it’s a very bad payments product.
I don’t have a horse in this race, but my only point was you don’t have to wait 15 minutes for a really decentralized experience. Yeah, you do need to be ok with not being able to later chargeback your grocery store, just like with cash. Which is fine for your example of groceries in hand, less great for large purchases over the internet.
Maybe we don’t need an alternative when Visa handles everything, but it might be nice to not pay a 3% markup on everything. Alternatively, we could try to be more like India and Brazil, which each built instant bank to bank transfer setups you can use at the grocery store, without the risks that come with losing debit/credit cards. Convenient without poor people with no rewards cards subsidizing everyone else to cover Visa’s take.
>Yeah, you do need to be ok with not being able to later chargeback your grocery store, just like with cash.
Well the reason that works is because in grocery stores you have a concept of card present so the liability shifts to the issuing bank... so there are no chargebacks. Concepts like card present and card not present demand a centralized authority and really can't exist in a decentralized payment rail, unless you're going to somehow invent decentralized pos hardware for merchants. Once you enter the world of atoms, you have re-introduced centralized trust into your payment rail though.
> Convenient without poor people with no rewards cards subsidizing everyone else to cover Visa’s take.
I fully agree. This is a crappy part of ccs and the best remedy is to disallow rewards programs for credit products. This isn't a fault of the card networks its a fault of issuing banks (and the airlines). Every crypto company in 2021 was offering 8% APY, you think those guys would have been better about this than Amex?
> Maybe we don’t need an alternative when Visa handles everything, but it might be nice to not pay a 3% markup on everything.
I'm actually not bothered by a take from the banks and networks involved. They are underwriting risk and affording insurances to me and the merchant. I guess my main argument is that it's good to have centralized insurance in money transfer facilitation. 3% is high and a failure of Dodd Frank. The Durbin Amendment should have reigned in cc fees and not just focused on debit interchange.
> Alternatively, we could try to be more like India and Brazil, which each built instant bank to bank transfer setups you can use at the grocery store, without the risks that come with losing debit/credit cards.
I don't disagree. As you pointed out it really comes down to the crappy reward programs from the issuing banks that make merchants and poor people suffer.
I don't mind crypto as an idea. I don't have a horse in the crypto race either. What I mind is the notion that it is somehow a viable payment rail. I'm sorry, it's been 20 years and crypto's best use case for payments has been buying acid on the internet because it was the only payment option.
I think one of the most interesting business stories in the world is about the guy who invented the Visa network, Dee Hock. It truly is a story of decentralization at its finest. John Coogan did a great video on him a couple of years ago I highly recommend: https://www.youtube.com/watch?v=RNbi2cUZt1o.
Unless this whole setup is self-hosted (which I doubt), it's also uploaded to some data lake of a company which is in business of profiting from information.
Intelligence agencies are really heading into a golden age, with everyone syncing all the data they have to the cloud, in plaintext. I mean it was already bad, but it's somehow getting worse.
The thing about that is the benefits, saving a couple minutes a day and not having to click to different windows where the information is stored, is apparent and intimidate whereas the harms associated with loosing most, if not all your privacy and security isn't felt in the same type of immediate way, so the dopamine of the positive effects completely overwhelms. It is hard for many people to be able to weigh different cost/benefit in situations where it is so one sided on the immediacy spectrum.
Both. The engine is open source. You can self-host it on any Linux box with KVM. There's also a live API you can hit right now (curl example in the README). Building the managed service for teams that don't want to run their own infra.
>(Do note that people can't just "not pull over" because they know there are no penalties involved; they would still be considered police, and "not complying with a police stop" would, as always, be a real crime with real penalties; if you run from the drone, it would summon actual cars to chase you!)
Or perhaps people will not be able to just "not pull over" because the police drones will be given the power to remotely command their car to stop. Heck, why even have the drones? Just require that the car monitor speeding infractions and report them for fines. Serious or repeat offenders can have their throttles locked out to the speed limit of the current road.
Sure, in the same way that vehicles without backup cameras or even airbags still exist. They will become less common over time. Vehicles don't have to be fully autonomous to provide this "service". They just need to have a reliable grasp of which road segment they are on and what the speed limit is. It will take some time but it won't be long before there are no cars left on the road that lack the (at least theoretical) ability to be controlled via cell radio. Heck, even without a police incentive, this will happen just because remotely disabling a car is a great way to simplify repossession.
I personally happen to think this is a terrible idea, just one cyber attack or regime change away from crippling everyday Americans ability to get around and live their lives, but that probably won't stop it from happening.
I would note that motorcycles, ATVs, tractors, etc. still don't have seatbelts or airbags. And sure, that's partly because, for some combinations of safety feature x vehicle class, they fundamentally can't. But we could have just outlawed public road use by those vehicle classes because of that. We didn't, because the lack of much more basic safety features (e.g. a roll cage) was already "priced in" to our decision to allow those vehicle classes on the road to begin with. These vehicle classes represent different trade-offs in safety-space, that operators of all vehicles sharing the road are highly aware of, maintaining a sort of mutual understanding of vulnerability of the different types of vehicles they're sharing the road with.
(That is: it's not just that motorcyclists themselves are more aware that they could be fatally T-boned (and so drive more defensively / keep more distance to avoid that outcome); it's also that drivers of heavier vehicles who encounter a "trolley problem" where they can either veer to hit a car, or to hit a motorcyclist, are aware that there's far less metal protecting the motorcyclist from the impact — so they are very likely to choose to veer to hit the car instead.)
And because of this, I would expect that we would never truly see the elimination of speed-limiter-less road vehicles, even if all cars were mandated to have them. There's just too many other things on the road (motorcycles, ATVs, tractors and construction equipment, e-bikes, etc) that are designed with these different safety trade-offs, such that they would likely never end up having the speed limiting imposed on them.
And that's enough things still on the road that could be dangerous if they hit someone, that would need to be pulled over for speeding, that I wouldn't imagine we'd see "off-board" speeding enforcement go away any time soon.
A guy on a literbike can drive at such stupidly fast speeds that he can't actually be pulled over already. By and large, society continues to function despite the occasional scofflaw doing 180 in a 55. They don't even tend to kill bystanders all that often.
I would imagine that if, say, 95% of vehicles on the road were incapable of speeding, there would be very little reason for the police to attempt to stop the other 5%. You'd probably still have token speed enforcement, but without the revenue raising potential of frequent speed tickets, it would likely make sense to direct enforcement resources elsewhere.
To wit, in some places you will be issued a DUI (of sorts) for riding a bicycle home from the bar. And it's actually enforced. Talk about the police shooting themselves in the foot.
Strongly disagree. If you're relying on Python garbage collection to free file descriptors in a loop, you have a subtle bug that will rear its head in unexpected and painful ways (and by some unwritten law of software, most notably either at 3 AM or when you have an important demo scheduled). This is true whether you're running in CPython or PyPy. It's not hard to avoid - use `with` or `try...finally`. It's not some newfangled language feature. It's not a surprise - you can't write good RAAI code in Python. It's a sign of someone with a poor grasp of the language they're using. If you find things like this, you should fix them, even if you never intend to use PyPy.
> If you're relying on Python garbage collection to free file descriptors in a loop
Again, that's a proscription for how to write python code for future execution. It's emphatically not a statement for the behavior expected by python code already in production, which tends to rely on this behavior (along with many other such warts and subtleties) implicitly.
And the fact that PyPy doesn't feel the need to clone it (and all the others) explains why PyPy basically doesn't work for existing python code.
I mean, me being an idiot python developer in your eyes does nothing to make the ancient code I received run. It just makes you feel smarter. That's a bad trade.
PyPy needs to be compatible before anyone is going to use it. And it isn't. And so people didn't. And so now it's basically dying as no one wants to work on a project no one uses.
It's not about feeling smart or dumb. I'm not doubting that lack of perfect compatibility is holding pypy back, though I suspect it's more related to C extensions and libraries than it is to bug-for-bug compatibility with the garbage collector. I just think that code which does this specific wrong thing that you've mentioned is already doomed to not work reliably even under CPython.
reply