Stupidly, yes, with carpet bombing. Practically, no, that would be horrible. More horrible, possibly, than taking out the power and water infrastructure.
We can't carpet bomb to regime change. But we can probably depopulate critical areas around the coasts while ships transit. It's stupidly expensive, both in materiel and collateral cost. But it's feasible. Whether we have the bomb-production is a separate question to which I don't have the answer.
> probably depopulate critical areas around the coasts while ships transit.
(looks at map) the city of Bandar Abbas, population ~500k? It's already being hit as it contains the Iranian Navy HQ, but actually depopulating it is a much bigger project.
Depopulation won't stop the IRGC from digging up a Shahed buried in the sand and launching it. The range is so great you would have to pacify the entire east of Iran, an absolutely impossible task.
> Depopulation won't stop the IRGC from digging up a Shahed buried in the sand
Carpet bombing. You don’t get to bury things in the sand, much less unbury them. It’s an old tactic—shaping movement with artillery—except done with remote pieces.
> range is so great you would have to pacify the entire east of Iran
West. Also, I don’t think so. Just critical zones. Worst case, only U.S. escorted and Iran toll-paying ships get through. (Worst case for the world. Not the belligerents. Which…that might be the solution.)
“Operation Crimp began on January 7, 1966, with B-52 bombers dropping 30-ton loads of high explosive onto the region of Củ Chi, effectively turning the once lush jungle into a pockmarked moonscape. Eight thousand troops from the U.S. 1st Infantry Division, 173rd Airborne Brigade Combat Team (including an artillery battery of the Royal Regiment of New Zealand Artillery), and the 1st Battalion, Royal Australian Regiment combed the region looking for any clues of PLAF activity.
The operation did not bring about the desired success.
[…]
By 1969, B-52s were freed from bombing North Vietnam and started "carpet bombing" Củ Chi and the rest of the Iron Triangle. Towards the end of the war, some of the tunnels were so heavily bombed that some portions actually caved in, and other sections were exposed. But the bombings were not able to destroy most parts of those tunnels.”
Carpet bombing doesn't cover a large area. Besides which there is nowhere to stage so an enormous campaign that isn't also in reach of one way drones.
The vast areas in the East are where you can strike shipping. You would only strike the West if your intention was to kill Iranians rather than end the war.
Nor did WW2 England. Look, Churchill had like 24 approval rate after Dunkerque, and the 'british Hitler' had 18%. Bombing London moved those percentages _very_ fast. 'do nothing, win' people have a point most of the time.
Trump casually talks about destroying the energy infrastructure, power plants, desalination plants etc. This is one of the most controversial things that the Russians do in Ukraine - attack the grid when it's cold to try and freeze people to death. To willingly deprive a country of 100,000,000 people of water and power coming into summer would surely be a war-crime.
Different goals. Carpet bombing to deny Iran access to its coast is maneouvre warfare. It’s tactical. Carpet bombing to force Kyiv to capitulate is strategic bombing. It has never worked.
You can't deny access to a coast that large with carpet bombing, especially in a mountainous terrain. It has never worked. You'd need tens to hundreds of thousands of boots on the ground to do that.
If you wanted to try it with bombs, it would take continual re-dropping of hundreds of thousands of bombs every few hours to cover (1600km * 8km) to keep people out, even assuming they have 0 shelter or cover.
> can't deny access to a coast that large with carpet bombing, especially in a mountainous terrain. It has never worked. You'd need tens to hundreds of thousands of boots on the ground to do that
I think this is more an open question than “it has never worked.” Nobody has tried to area deny FPV-drone navigators. Bases on lines of sight and line channels, one could probably back out from transit paths to the places one would need to be to hit that target, and then ensure anything there is turned from psychology to biology before a critical moment. You couldn’t do this with smart munitions, and couldn’t along the entire Hormuz coast. But for critical junctures that our closest allies (minus Kuwait) need to export? The math seems feasible, if fundamentally untackled.
> I think this is more an open question than “it has never worked.”
I don't think so – we were talking about continually carpet bombing Iran to continually deny them access to a 1600km-long coastline. That simply has never worked. Not in Iran, not elsewhere to my knowledge.
> Bases on lines of sight and line channels, one could probably back out from transit paths to the places one would need to be to hit that target
That describes pretty much anywhere in the 7000+ square kilometers we're talking about. A drone doesn't need a runway. Anywhere you can fit a large pickup truck, you can launch a Shaheed drone.
> Nobody has tried to area deny FPV-drone navigators.
I'm not sure what you're saying here. Deny the area to Iran's FPV drones? If so, how? Use FPV drones to deny the area? If so, how? We're talking about continually patrolling 7,000+ square kilometers. The USA has never fielded such a system, and has no publicly known capabilities to do so.
I don’t see how they’ll have different results, just because the aim is different. You just… take cover. Then come back once the planes fly away and continue what you were doing.
Iran already had severe water problems. Attacking the water infrastructure would definitely cause huge civilian casualties. Israel is used to that. Not clear whether America is ready to go into the midterms with an official policy of US-flagged genocide.
There has been (I think) relatively minor hits. And Iran has retaliated in kind (see the latest hit on Kuwaiti desalination plant).
The thing is that while Iran's water infrastructure is vulnerable, the Gulf states are much more reliant on desalination ... and hitting them hard there would be a total disaster ... which Iran is capable of doing, but has so far refrained.
> Attacking the water infrastructure would definitely cause huge civilian casualties
I personally think there is a wide barrier between electrical and water infrastructure. But given water infra has allegedly been hit already, it doesn’t feel like it’s off the table for both sides the way it once was.
I was on LinkedIn last night, and someone posted their new SAAS. The website was basically a calendar where you could log what you did each day of the month. I checked my memory usage, and that site was using 1GB of memory. They were also charging $100 for it...
Among my favorite failed dorking around experiences is pre-Raspberry, when the Arduino was still hobby-level equipment. This was over a decade ago...
With only a few kilobytes of code, you could send a UDP packet directly to your phone, with an app you "wrote" with just a few lines of code (to receive, without auto-confirmation).
That's crazy talk. What will you ask for next? Add functionality to make apps at least as good/capable as they were in the 1990s and early 2000s? And then? Apps that interoperate? Insane.
More seriously and more ironically, at the same time, we've now reached a strange time where even non-programmers can vibe-code better software than they can buy/subscribe to - not because models are that good, or programming isn't hard, but because enshittification that has this industry rotten to the core and unable to deliver useful tools anymore.
Let me be the devils advocate here.
Ok, let's say you optimize that TODO list app to only use 16 mb of RAM. What did you gain by that? Would you buy a smartphone that has less RAM now?
16MB still seems massive for this kind of app. I ran Visual Studio 4, not an app, but an entire app factory, on a 66MHz 486 with 16MB RAM. And it was snappy. A TODO list app that uses system UI elements could be significantly smaller.
What do I gain if more developers take this approach? Lightning fast performance. Faster backups. Decreased battery drain => longer battery service lifetime => more time in between hardware refreshes. Improved security posture due to orders of magnitude less SLOC. Improved reliability from decreased complexity.
Easier to run your todo list at the same time as applications that need the RAM for raw function. Maybe that’s CAD, maybe that’s A/V production, maybe it’s a context window.
It’s been convenient that we can throw better hardware at our constraints regularly. Our convenience much less our personal economic functions is not necessarily what markets will generally optimize for, much like developers of electron apps aren’t optimizing for user resources.
Technically no (except for the gradual performance drop they introduce, + occasional TPM bullshit), but of course in practice, companies see this as a choice of spending money on back-porting security fixes to a growing range of hardware, vs. making money by not doing that and forcing everyone to buy new hardware instead.
I’m running Windows 10 ESU on a 13 year old PC without issues. While it’s admittedly near the end of its life (mostly just due to Windows 11, though I might repurpose it for Linux), I’m expecting the next one to also last a decade or longer.
So is my wife, her laptop is still decent today, but doesn't support Win 11. I'm not worried about Microsoft as much as certain other competitors killing it - similarly to how she was forced to update to Windows 10 in the first place because, one day, out of the sudden, her web browser decided to refuse running on Windows 7.
My "new" computer is a laptop with an 8th-gen i5 and 8 gb ram salvaged from the Windows 11-incompatibility heap (actually 3 of them, so I have 16gb in it). I installed Kubuntu on it and it runs extremely well. I can even install Windows 11 in a VM if I really need it. I'll probably be buying new (old) ram for it and maybe a bigger drive.
We can't ever escape the market forces? You're right, of course if software gets less bloated, vendors will "value-optimize" hardware so in the end, computers keep being barely usable as they are today.
Sure, but the price increase will be less, because less ram. Also, the need to keep buying new computers will decrease, because this year's computer isn't much better then last years (but now we can run more/better software!)
Less bloat is 100% always a good thing, no matter what the market conditions are.
This year's average phone is already going to have less RAM than last year's average phone - so anything that reduces the footprint of the apps (and even more importantly, websites) we're using can only be a good thing. Plus it extends the usable life of current hardware.
>It’s React Native for Windows which is a flavor of React Native that directly calls Windows APIs including, you guessed it, WinUI 3.
>So that’s it. Windows Start has a very small section (that can be disabled) that’s written in a framework that follows React principles and compiles down to native code.
False. React Native doesn't "compile down to native code". It runs actual JavaScript, just not inside a browser, but a standalone JS runtime.
I wonder what engine they are using with ReactNative on Windows. Is it Hermes like with regular RN projects targeting iOS/Android? Or do they run on some system installation of a more traditional engine like V8/JavaScriptCore?
It looks like they were originally on Chakra (the JS engine used by IE9+ and pre-Chromium Edge) but added support for Hermes in 2021 or so and removed support for Chakra last year, so Hermes is now the only option. Edge moved to Chromium in 2019, so this means they actually kept Chakra around for a few years just? for React Native on Windows.
> This was an oversimplification bordering on being misleading. It’s a lighter JS runtime that’s calling native code for rendering controls. The argument still has merit. Just because something in JS doesn’t make it slow or bloated. Interpreted languages will almost always be slower than their native compiled counterparts, but it’s negligble [sic] for these purposes.
Isn't it a full JS runtime? I think by "a lighter JS runtime that's calling native code" you mean it doesn't deal with HTML/CSS rendering, but that's not what JS runtime means. These are separate parts of the browser architecture.
I don't agree it's negligible for this purpose. Core OS functionality should run well on old/cheap machines, and throwing in unnecessary interpreters/JITs for trivial stuff is inconsistent with their recently announced commitment to "faster and more responsive Windows experiences" and "improved memory efficiency".
Also, we need personas! Sally the developer, Mark the UX designer, Taylor the manager. Also, we need to build a community, with the help of evangelists!
If you started your career more than ~2-3 years ago, you were trained on a completely different game. Clear abstractions, ownership, careful iteration, all that. That muscle memory is actively hindering you; preventing you from succeeding.
The people coming up now don't have that baggage. They never internalized "write the code yourself" as the default. They think in terms of spawning systems, letting things run, checking outcomes. It's way closer to managing a process than engineering in the traditional sense. And yeah, that shows up in what gets shipped. A 21-year-old will brute force 20 directions in parallel with agents and just pick what works. Someone more "experienced" will spend that same time trying to design the "right" approach up front. By the time they're done thinking, the other person has already iterated past them.
It's kind of unsettling is how basically all of these "senior instincts" are now liabilities. Caring about perfect structure, being allergic to randomness, needing to understand every layer before moving forward, etc. used to be strengths. Now they just slow you down.
You can already feel the split forming. Younger builders are comfortable letting systems do things they don't fully understand. Senior engineers keep trying to pull everything back into something legible and controlled, kneecapping themselves. That gap is not small.
What I'm seeing in my circle of founders and CEOs is that they're slowly laying off these older devs (cutoff age is around 24yrs) and replacing them with fresh, young talent, better suited for this new agentic era. From their reports the velocity gains are insane; and it compounds. Basically, these older folks are still doing polynomial thinking in an exponential landscape. They are dinosaurs slated for extinction.
Software development keeps going through YOLO->Engineering cycles, and the non-technical business folks are ALWAYS overindexing on the swing, in each direction, while the real pros are trying to navigate the new to find how to best leverage the power of new tooling without abandoning correctness while dealing with the expectations of people with power that far outstrips their comprehension of the domain.
This is the most delusional comment i think i have ever read on this site. It didn't make sense until i read the part about "Founders and CEOs" and realized it was not a post about any serious software enterprise.
What would happen if the Cr and Cb channels used different chroma subsampling patterns? E.g. Cr would use the 4:2:0 pattern, and Cb would use the 4:1:1 pattern.
It is supported in JPEG! It can reduce color bleeding along the axis that each chroma channel controls.
For example, if you make sharp Cr and low-res Cb, you'll get sharper red edges with some yellow bleeding instead of completely blurry red edges if Cr was subsampled.
reply