That’s a crappy pressure vessel holding 350ml of 80psi air, for about 100J of stored energy. I’m not entirely sure I’d be comfortable with that, especially anywhere with my face in the line of fire it it fails.
Those two pressure vessels are highly engineered and are wrapped with materials with pretty good tensile strength. Also, they’re made out of materials (fabric and rubber) that absorb a decent amount of energy when they tear and that don’t fragment. And the whole assembly usually de pressurizes slowly.
Having personally blown up beverage bottles by overpressurizing them (be very very careful doing this!), when they go, they go violently.
I’m no expert, but I think this is a matter of international politics. Imagine if Iran had closed the strait last year. I suspect a rather large coalition would have shown up, quite quickly, to do their best to reopen it. But instead almost every relevant player is pissed off at the US and Israel and has no desire to join in the hostilities.
Not to mention that Iran did not want to have thousands of fancy missiles and bombs lobbed at them, but since that happened anyway, why not close the strait?
> But instead almost every relevant player (...) and has no desire to join in the hostilities
Almost correct, but days ago there was an UN meeting where a resolution to bring forth a naval response from many countries to reopen the Strait by force was voted, and it was vetoed by China and Russia (IIRC also by France).
That news became old very quickly, but it was a move done to force USA to concede a ceasefire because it made the US the only player who could make an offer with Iran to reopen the Strait, even if in undesirable terms.
The fact that this meeting happened and a resolution was blocked made Trump and the US incapable of blaming the EU of not helping reopening the Strait.
If you want evidence that bombs do not settle the issue, you can consider the current Iran war. The US and Israel have dropped a rather impressive number of bombs on Iran. As far as I know, most of them worked. But whatever issue the leaders of the US and Israel thought they were going to settle is most definitely not settled. The regime has changed from Ayatollah Khamenei to Khamenei, the US’s military position is dramatically worsened, and, while Iran has a lot of rebuilding to do, they are arguably in a strategically stronger position than they were before. Maybe you think Iran’s continued existence “can’t happen period”, but Iran still exists and the US’s ability to anything about it is very much in doubt.
It's so fascinating to read comments like this and realize we live in completely different worlds, wouldn't you agree?
On one hand, I see the US parked 3 aircraft carriers outside of Iran, loaded up ground-based bombers, blew up most of Iran's existing leadership and completely destroyed their air force, navy, and is (well was, until yesterday when Iran capitulated) conducting bombing campaigns on HVTs, military infrastructure, missile launchers, and production facilities and yet, since they haven't destroyed all of the missile launchers in the first 5 weeks of the war I now read, from you, that Iran is "in a strategically stronger position than they were before", and the US military position has "dramatically worsened".
How can this be? Where do you get your news from? I'm curious to read what you are reading about this war. It's mind-blowing how different and counterintuitive it is. Like how is the US military in a dramatically worse position? What specific factors are you talking about? Missile capabilities? Air defense? Did Iran recently sink a US aircraft carrier? I would think if something dramatic happened I'd read about it somewhere but I haven't heard of anything majorly bad happening to the US during the course of this war.
If Iran is in a strategically stronger position, why did they need fewer missiles and missile launchers and less military equipment to get stronger? Are you saying by destroying their equipment and killing their leaders that they grew stronger and more capable? If that's the case, why didn't they just kill their own leaders and dismantle their military equipment themselves?
I think we don't have different facts or sources so much as different perspectives.
There's a Starcraft-like perspective in which you're right. The US has repositioned a bunch of long-range-attack units and has consumed a lot of single-use weapons, with which we have removed most of Iran's defense towers and generally destroyed a good deal of their fixed military assets. Maybe the US has reduced the other team to a mostly a bunch of drones. It looks like the US's team will definitely win.
But there are quite a few things about this analysis that don't really apply to the real world. First, we're not playing last man standing. The US's goal isn't to wipe Iran off the map -- it's goal is (hopefully) to ensure stability for itself and its allies and to let the probes (commercial trade) go around the map freely. But the US has not even come close to removing enough of the Iranian forces to allow weak units to go through the strait safely (or even perhaps strong units). Secondly, one needs to count units more carefully: Iran has on the order of 1M military units left -- the US has destroyed several thousand big, obvious, expensive units but has barely touched the total. Sure, the US also has a lot of military units, but they are not in Iran and it would be an utterly terrible idea to send hundreds of thousands of troops.
Additionally, one needs to zoom the map out. There are lots of other important things going on. Just one of them is that there has been a standoff for decades across the Taiwan Strait. It's been fairly stable because no one involved wants to start a shooting war that they will lose (yes, all parties can easily lose simultaneously). The US gets significant economic value from having Taiwan be independent and friendly to the US. But a bunch of those single-use weapons used in Iran and some very high value US units had previously been near the Taiwan Strait are are not any more.
Also, the US lost some very very high value units that it no longer has the ability to rebuild (cough, AWACS, cough).
Here's some good reading for a less tongue-in-cheek perspective:
> Also, the US lost some very very high value units that it no longer has the ability to rebuild (cough, AWACS, cough).
We can build them if we want since we built them before.
But the US is likely moving away from AWACS toward other platforms precisely because they're big easy targets, especially when they're sitting on the ground at an air base. It's unfortunate but not a big deal - we would expect a country armed with thousands of missiles who is then launching them toward both military and non-military targets to land some hits. Aerial refueling tankers are actually the weak link if I had to guess.
But the reporting around these developments and activities doesn't always hit the mainstream media so the sources can be a little lackluster. That's what I have so far though ^^
> Iran
I'm not sure how you are defining military units, but the only ones that really matter much now are missile launchers which are used to disrupt the free transit of oil through the Straight. It has only been a few weeks. The US can just slowly blow these up over time and end most of Iran's capabilities here. The main issue is the cost to the international community for doing so which subsequently affects the US, albeit less so than most other countries.
But there are many options here. The US for example just forced Iran to agree to a ceasefire and to stop attacking ships in the Straight. I don't mean to suggest Iran doesn't also have capabilities, but the commentary on this is very one-sided in favor of Iran and I think that needs, well, it needs balance and it also needs additional thought. Too many people are so caught up in hating Donald Trump that they're not thinking clearly. (not you in particular or anything)
> Taiwan
Agreed it is incredibly important. Likely the US has judged the risk of China attacking Taiwan at this juncture to be acceptably low. Although it's also worth noting that in the past 6 months (just because I forget the timeframe) the US has put the hammer on both of China's primary oil trading partners. You can't fly jets and operate tanks without oil and that's not going to change anytime soon. It's very nuanced. I agree all parties are likely to lose in an engagement there - it would be a nightmare depending on what China actually did and could immediately involve the US, Japan, SK, and NK along with China in a very nasty war.
No it's not. International law is generally exceptionally clear that one war crime doesn't justify another, and using civilians as human shields is about as core a war-crime as war-crimes get.
> The prohibition of using human shields in the Geneva Conventions, Additional Protocol I and the Statute of the International Criminal Court are couched in terms of using the presence (or movements) of civilians or other protected persons to render certain points or areas (or military forces) immune from military operations.[18] Most examples given in military manuals, or which have been the object of condemnations, have been cases where persons were actually taken to military objectives in order to shield those objectives from attacks. The military manuals of New Zealand and the United Kingdom give as examples the placing of persons in or next to ammunition trains.
The situation in Iran is not this. The suggestion was that humans might volunteer to go to non-military sites.
As an extreme hypothetical, are humans living in their homes acting as human shields for those homes? How about people at school? How about people parading on a bridge? Does it become different if someone threatens to blow up a bridge and people parade there in response?
Eh, the quoted text, and also the literal text of the Fourth Geneva Convention, Article 28 [1], doesn't qualify "certain points or areas" as only "military sites". While the other side should only be attacking military sites I don't see how that could possibly justify protecting non-military sites with human shields.
> As an extreme hypothetical, are humans living in their homes acting as human shields for those homes? How about people at school? How about people parading on a bridge?
Generally speaking I read this as not, because they aren't being "used to" render those points immune from attack, they just happen to be doing so. Hypothetically if you were to rush civilians back to their homes in an evacuated town to protect it from an attack - or as you suggest organize parades on bridges that are threatened - that would seem to meet the "used to" requirement.
Article 54 gives some sites that may not be attacked. Maybe a protected person cannot render at least those sites “immune” since they are already immune.
If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks. Well, as long as the PQ key exchange holds up, and I am personally not as optimistic about that as I’d like to be.
> If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks.
Let me rephrase it to see if I understand correctly: so it is fine to keep using my security keys today for authentication (e.g. FIDO2?), but everything else should use PQ algorithm because the actual data transfers can be stored now and decrypted later.
Meaning that today (and for a few years), my Yubikey still protects me from my key being stolen when my OS is compromised.
Looking forward to a PQ yubikey rev. I would buy a box of them today so I could start experimenting!
Another challenge of the transition is how much silicon we have yet to even implement. Smart cards? Mobile acceleration/offloading? We're at the mercy of vendors.
Is this also true for other TPM/snitching/DRM chips out there? IE will every existing device eventually become jailbreakable in the future or will we unfortunately not even get that benefit from all this?
The timeline here is for when major governments have access to CRQCs. It will be much longer than that (barring an AI singularity or something) before you have access to one.
I was in this field a while back, and I always found it baffling that anyone ever believed in the earlier large estimates for the size of a quantum computer needed to run Shor's algorithm. For a working quantum computer, Shor's algorithm is about as difficult as modular exponentiation or elliptic curve scalar multiplication: if it can compute or verify signatures or encrypt or decrypt, then it can compute discrete logs. To break keys of a few hundred bits, you need a few hundred qubits plus not all that much overhead. And the error correction keeps improving all the time.
Also...
> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f**d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon.
This part is embarrassing. We’ve had hash-based signatures that are plenty good for this for years and inspire more confidence for long-term security than the lattice schemes. Sure, the private keys are bigger. So what?
We will also need some clean way to upgrade WebAuthn keys, and WebAuthn key management currently massively sucks.
> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon.
compare to SGX, a more critical impacted component is TPM chip, secured/measured boot depends on TPM, and cost of replacing all servers and OS ...
A lot of TPMs are “fTPM”s, which are implemented in something resembling software. It’s an open question whether the hardware in question has usable roots of trust, but a lot of TPM applications don’t actually require endorsement. And some servers have plug-in TPMs.
Of course, many critical components on a motherboard and CPU verify their firmware using non-post-quantum keys, which is another issue.
If you click the link to the actual paper, you’ll find:
> Next, we sought to explore the potential benefit of targeting the age-related increase of FTL1 in the hippocampus of aged mice. We performed targeted stereotaxic injections of a high-titer virus encoding shRNA sequences targeting either Ftl1 or luciferase control into the CA1 and dentate gyrus hippocampal regions of aged mice (Fig. 3b and Extended Data Fig. 5a,b).
There are lots of bio research techniques that can be applied to mice that you wouldn’t necessarily want to do to yourself…
> On x86 a spinlock release doesn't need a memory barrier (unless you do insane things) / lock prefix, but a futex based lock does (because you otherwise may not realize you need to futex wake).
Now you've gotten me wondering. This issue is, in some sense, artificial: the actual conceptual futex unlock operation does not require sequential consistency. What's needed is (roughly, anyway) an release operation that synchronizes with whoever subsequently acquires the lock (on x86, any non-WC store is sufficient) along with a promise that the kernel will get notified eventually (and preferably fairly quickly) if there was a non-spinning sleeper. But there is no requirement that the notification occur in any particular order wrt anything else except that the unlock must be visible by the time the notification occurs [0]; there isn't even a requirement that the notification not occur if there is no futex waiter.
I think that, in common cache coherence protocols, this is kind of straightforward -- the unlock is a store-release, and as long as the cache line ends up being written locally, the hardware or ucode or whatever simply [1] needs to check whether a needs-notification flag is set in the same cacheline. Or the futex-wait operation needs to do a super-heavyweight barrier to synchronize with the releasing thread even though the releasing thread does not otherwise have any barrier that would do the job.
One nasty approach that might work is to use something like membarrier, but I'm guessing that membarrier is so outrageously expensive that this would be a huge performance loss.
But maybe there are sneaky tricks. I'm wondering whether CMPXCHG (no lock) is secretly good enough for this. Imagine a lock word where bit 0 set means locked and bit 1 set means that there is a waiter. The wait operation observes (via plain MOV?) that bit 0 is set and then sets bit 1 (let's say this is done with LOCK CMPXCHG for simplicity) and then calls futex_wait(), so it thinks the lock word has the value 3. The unlock operation does plain CMPXCHG to release the lock. The failure case would be that it reports success while changing the value from 1 to 0. I don't know whether this can happen on Intel or AMD architectures.
I do expect that it would be nearly impossible to convince an x86 CPU vendor to commit to an answer either way.
(Do other architectures, e.g. the most recent ARM variants, have an RMW release operation that naturally does this? I've tried, and entirely failed AFAICT, to convince x86 HW designers to add lighter weight atomics.)
[0] Visible to the remote thread, but the kernel can easily mediate this, effectively for free.
[1] Famous last words. At least in ossified microarchitectures, nothing is simple.
> > On x86 a spinlock release doesn't need a memory barrier (unless you do insane things) / lock prefix, but a futex based lock does (because you otherwise may not realize you need to futex wake).
> Now you've gotten me wondering. This issue is, in some sense, artificial: the actual conceptual futex unlock operation does not require sequential consistency. What's needed is (roughly, anyway) an release operation that synchronizes with whoever subsequently acquires the lock (on x86, any non-WC store is sufficient) along with a promise that the kernel will get notified eventually (and preferably fairly quickly) if there was a non-spinning sleeper. But there is no requirement that the notification occur in any particular order wrt anything else except that the unlock must be visible by the time the notification occurs [0]; there isn't even a requirement that the notification not occur if there is no futex waiter.
Hah.
> ...
> But maybe there are sneaky tricks. I'm wondering whether CMPXCHG (no lock) is secretly good enough for this. Imagine a lock word where bit 0 set means locked and bit 1 set means that there is a waiter. The wait operation observes (via plain MOV?) that bit 0 is set and then sets bit 1 (let's say this is done with LOCK CMPXCHG for simplicity) and then calls futex_wait(), so it thinks the lock word has the value 3. The unlock operation does plain CMPXCHG to release the lock. The failure case would be that it reports success while changing the value from 1 to 0. I don't know whether this can happen on Intel or AMD architectures.
I suspect the problem isn't so much the lock prefix, but that the non-futex spinlock release just is a store, whereas a futex release has to be a RMW operation.
I'm talking out of my ass here, but my guess is that the reason for the performance gain of the plain-store-is-a-spinlock-release on x86 comes from being able to do the release via the store buffer, without having to wait for exclusive ownership of the cache line. Due to being a somewhat contended simple spinlock, often embedded on the same line as the to-be-protected data, it's common for the line not not be in modified ownership anymore at release.
> I suspect the problem isn't so much the lock prefix, but that the non-futex spinlock release just is a store, whereas a futex release has to be a RMW operation.
> I'm talking out of my ass here, but my guess is that the reason for the performance gain of the plain-store-is-a-spinlock-release on x86 comes from being able to do the release via the store buffer, without having to wait for exclusive ownership of the cache line.
I don’t think so. The CPU is pretty good about hiding that kind of latency — reading a contended cache line and doing a correctly predicted branch shouldn’t stall anything after it.
Using LOCK CMPXCHG or even plain CMPXCHG does not make sense unless it is done in a loop, which tests the success of the operation.
Implementing locks does not need this kind of loops, which may greatly increase the overhead, but only loops that do simple loads, for detecting changes, or the invocation of a FUTEX_WAIT, which is equivalent with that.
Besides loops that wait for changes, any kind of lock may be implemented with atomic read-modify-write instructions (e.g. on x86 XCHG, LOCK XADD, LOCK BTS and so on, and equivalent instructions on Armv8.1-A or later ISAs) that are not used in loops, so they have predictable overhead. For example, a futex may be used by a thread that waits for multiple events, if the other threads use a locked bit-test-and-set on the futex variable to signal the occurrence of an event, where each event is assigned to a distinct bit.
CMPXCHG and the equivalent load-and-lock/store conditional are really needed far less often than some people use them. The culprit is a widely-quoted research paper that has shown that these instructions are more universal than simple atomic fetch-and-operation instructions, allowing the implementation of lock-free algorithms, but the fact that they can do more does not mean that they should also be used when their extra power is not necessary, because that is paid dearly by introducing non-deterministic overhead.
A simple atomic instruction has an overhead much greater than an access to the L1 cache or the L2 cache, but typically the overhead is similar to that of a simple access to the L3 cache and significantly lower than the overhead of a simple access to the main memory, which remains the most expensive operation in modern CPUs.
Moreover, while mutual exclusion can be implemented reasonably efficiently with locks, it is also used far more often than necessary. It is possible to implement shared buffers or message queues that use neither mutual exclusion nor optimistic access that may need to be retried (a.k.a. lock-free access), but instead of those they use dynamic partitioning of the shared resource, allowing concurrent accesses without interference.
Organizing the cooperation between threads around shared buffers/message queues is frequently much better than using mutual exclusion, which stalls all contending threads, serializing their execution, and also much better than lock-free access, which may need an unpredictable number of retries when contention is high.
You are misunderstanding me, which is perhaps understandable, since I’m talking about the minutiae of x86, not locking in general.
When unlocking a futex-backed mutex, one needs to do two things. First, one needs to actually unlock it: this is a store-release in modern lingo, and on x86 almost any store instruction has the correct ordering semantics. Second, one needs to determine whether to call futex_wake, which is conceptually just reading a flag “is someone waiting” and then branching on the result. The problem is that the load needs to be ordered after (or at least not before) the store.
x86 provides two main ways to do this, MFENCE and LOCK. For whatever reason, at least Intel has tried pretty hard to optimize LOCK, and it’s often the case that LOCKed operations on a hot cache line is faster than MFENCE. (I have benchmarked this, and Linux uses this trick.)
My point is that the specific algorithm of unlocking a futex-backed mutex does not require the full ordering semantics of MFENCE or LOCK. And my secondary observation is that x86 has some non-LOCKed RMW instructions, one of which is plain CMPXCHG. Unlocked CMPXCHG is much faster than LOCK anything or MFENCE — I’ve benchmarked it. There are also the flag outputs from operations like ADD. And I’m speculating that maybe some of these instructions are secretly actually ordered strongly enough for futex unlock.
reply