And it is more than likely. US and Iran probably can’t defeat each other militarily (us obviously can, but it requires full scale ground invasion which is not even contemplated at the moment). And both can’t back out of the conflict. So the likely outcome is that the conflict escalates until one of the regimes snaps and it becomes to somehow politically possible to back out.
Collapse of the regime in Iran seems unlikely at the moment because it’s hard and zealous dictatorship with unlimited power and will for violence within the country. In the US OTOH the elections are coming. An administration that started a stupid and absolutely preventable war and then effectively lost faces quite a challenge there despite everything else. This seems like a perfect moment for Iran to create a deterrent for US: attacking us ends your presidency.
If the newest batch of 10,000 is approved, we're up to 17,000 combat troops deployed for this. (Marines there as of Mar 27, another 3,500 in about two weeks, and then at least 1 battalion of the 82nd Airborne, plus another 10,000 requested)
I have heard other units getting pre-mobilization / warnings.
(This would not nearly be enough troops for large scale ground conflict, but it might be enough to go into the island tunnels looking for drones and ballistic missiles while the US tries to hold open the straight by force for... However long that takes)
This is all fine and well, but misses one little detail: drones. In the past conflicts US troops were more or less unreachable for the enemy unless they were advancing on the ground in a challenging terrain like dense jungles or mountains, where an enemy could ambush them. Other then that, US had air superiority, overwhelming firepower and excellent reconnaissance.
After the war in Ukraine things are very different. US troops are not safe as long as they are reachable by an FPV done, i.e., the enemy has to only make it ~20km to US positions. Given the area and terrain in Iran this will be happening all the time. So any troops positioned on Iran's territory will be under constant attacks by FPV drones. This means heavy casualties.
But even if the US forces will manage to clear the FPVs, this is still not enough, because there are dozens of other types of winged long range drones, the most famous being of course Shahed. They are less precise and not so deadly for the troops. They are also much easier to intercept. But that means that you effectively can't set up a safe stationary base, because it will be attacked by hundreds of drones from hundreds of miles away 24x7. There is not enough interceptors to stop that.
This means that a new approach will have to be used by US armed forces which they never tried before. This guarantees heavy losses on the initial stage which will raise a real political shitstorm back home. It looks like the current administration doesn't particularly care about that, but chances are they will not be able to contain the consequences.
> This is all fine and well, but misses one little detail: drones.
That's why A-10s are patrolling the 6 mile wide straight for 2 hours a flight. They can take out the larger Iranian drones much cheaper than any other platform we have. The small dones can't get very far and the US is exceptional at electronic warfare. But that doesn't really change anything, it just maintains the status quo of the straight being too risky for oil tanker insurers.
Ultimately, even if the US goes into the island tunnels after the ballistic missiles and larger drones, it would take huge sums of money to try and keep it open militarily for... who knows how long.
Yes, in principle, this (limited ground invasion to protect the straight) can be done. The cost - both in lives, money and political capital - will be enormous.
One comment though.
> The small dones can't get very far and the US is exceptional at electronic warfare.
There is currently one county in the world which is exceptional in electronic warfare against drones - Ukraine. Then there is Russia. Everybody else is leagues behind, including US. Without real combat experience and proven technologies ready for deployment all your money and fancy equipment are worth nothing. THAADs have the most advanced radars, did it help them in UAE recently?
In Ukraine they basically had to build a network of mini-factories with 3d printers and ad-hoc repurpose of old weapons right behind the front lines. This is to be able to counter Russian drones by enabling fast iteration on EW. US has nothing like that in current doctrine and it’s not clear if this can even be deployed in an expeditionary corps model.
I’m not saying of course that it’s impossible for US to open the straight by military means or to defeat IRGC otherwise, it’s just that it’s a very hard task which got even harder after advancement in drones.
While it's appreciated, that isn't the original link and Ddos "secrets" gate keeps info to people they personally allow. The person who runs it also has been to court for a name change, citing something along the lines of wanting to work in intelligence.
Not a source I would trust unless there is no other option to get the dumps or leaks.
I've been mostly off the GitHub train since the MS acquisition, and think any alternative is a good alternative. Codeberg is great.
I've also been very happy with sourcehut for most of my personal projects for some time. The email patch submission workflow is a tad bit unfamiliar for most, but IMO in today's era raising that barrier to entry is mostly a good thing for OSS projects.
I also strongly prefer a simple CI environment (where you just run commands), which encourages you to actually be able to run your CI commands locally.
Wow what a treat, previously unreleased tolkien satire on one of my own hobby-horses. Put in an order with my local bookstore, so excited to read this!
I had a similar experience yesterday. Was working on some async stream extensions. Wrote a couple proofs of concept to benchmark, and picked one based on the results. I almost never use LLMs to write code, but out of curiosity, asked whatever the newest claude is to make it with all the real prod requirements, and it spit out over 400 lines of code, lots of spaghetti, with strange flow and a lot of weird decisions. Wrote it myself with all the same functionality in right around 170 lines.
Also had a similar experience in the past weeks reviewing PRs written with LLMs by other engineers in languages they don't know well, one in rust and one in bash. Both required a lot of rounds of revision and a couple of pairing sessions to get to a point where we got rid of the extraneous bits and made it read normally. I'm glad the tool gave these engineers the confidence to work in areas they wouldn't normally have felt comfortable contributing to, but man do I hate the code that it writes.
The article didn’t claim that “last wins” is in and of itself an issue, but that the differences between who wins between parsers across services/languages can cause issues. Their position was that everyone should standardize on “last wins,” since that is the most common.
The problem of trying to ensure that each parser behaves the same for all input is twofold:
- JSON and XML specifications are complex, lots of quirks. So not feasible.
- Does not solve the fundamental issue of the processing layer not using the same data that is verified in the verification layer.
Note: the processing layer parses the original input bytes, while the verification layer verifies a struct that is parsed using another parser.
Doesn’t seem vibe coded to me. The crates aren’t unreasonable: data structures, parser, formatter, repl, “util,” some proc macros (which have to be in a separate crate in rust), and a VM.
For folks who seek a rule of thumb, I’ve found SPoT (single point of truth) a better maxim than DRY: there should be ideally one place where business logic is defined. Other stuff can be duplicated as needed and it isn’t inherently a bad thing.
To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting.
Of course no rule of thumb applies in all cases, and the sense for that is hard to teach.
> To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting
Just for fun, this more or less already exists as another acronym: WET. Write Everything Twice
It basically just means exactly what you said. Don't bother DRYing your code until you find yourself writing it for the third time.
And to those who feel the OCD and fear of forgetting coming over by writing twice, put TODOs on both spots; so that when the third time comes, you can find the other two easily. If you are the backlogging type, put JIRA reference with the TODOs to make finding even easier.
> I’ve found SPoT (single point of truth) a better maxim than DRY
I totally agree. For example having 5 variables that are all the same value but mean very different things is good. Combining them to one variable would be "DRY" but would defeat separations of concern. With variables its obvious but the same applies to more complex concepts like functions, classes, programs to a degree.
It's fine to share code across abstractions but you gotta make sure that it doesn't end up tying these things too much together just for the cause of DRY.
reply