So AI is attempting to replace SAP as the traditional way of testing if you company is strong enough ?

While I guess that because of the international isolation the country might survive for a while without without international connectivity, they have reportedly shut down the local internet and phone networks as well, which also means payment cards and ATMs don't work.

And I don't think the regime can keep that for long if there is still expected to be something resembling a working country.

I agree, this really shows how bad things have gotten for the regime.

Iran relies heavily on digital transactions because of the hyperinflation, there is not enough physical cash anymore. Soon people are going to the street simply because they can't buy food anymore.

Are you sure it actually works ?

Outdated but signed ROM with tons of unfixed CVEs will be still considered totally fine.

Latets Lineage OS or Graphene OS will be rejected.

Um, no - if you do this on suborbital trajectory you totally obliterate a bunch of empty space for the <10 minutes until all your garbage falls back.

If you actually manage to make it into an orbit (with a much much bigger and much more expensive rocket) you will most likely do the same (eg. not hitting the intended satellite) with the added bonus of littering random orbits over time and hitting random satellites.

And if you want to say "they will deny orbit for everyone!" - well, good luck without far too many orbital class rockets for anyone of their size to have.

Not to mention Starlink orbits being (as alterady state so low they are self-cleaning), GPS orbits being far too high to even reach, let alone to saturate with garbage & same for GEO sats.

I don't think MCP is a fad - I think it is the 2020s equivalent of:

- Active X

- asbestos

- leaded gasoline and paint

- radium medicines

Well, with the exception of the first 3 actually being quite useful.

An LLM could never write this.

More likely Asad will get another buddy to play Sounter Strike with - both he and Yanukovich must be bored to death by now in 2 people.

Starlinks are in self cleaning orbits & are actually being moved even lower due to solar minimum & better capacity:

https://www.space.com/space-exploration/satellites/spacex-lo...

And any weaponized junk schrapnel a DiY iranian ASAP missile would deploy would be sub-orbital and would all come down in a couple minutes.

I guess it is to a degree unavoidable - ukrainian units are using a lot of crowdfunded starlink terminals on the front, so even if you geo fenced usage only to the virtual cells outside of Russia controlled territory, you would also disable ukrainian sets at the front. So if Russians smuggle sets from other countries, they might not be really easy to tell from the "good" sets crowdsourced by the ukrainians and used at the front.

As for use in long range strike UAVs I'm sure ukrainian units have specially registered units that will work anywhere but again, Russian long range kamikaze drones you have a smuggled unit that only activates once on ukrainian territory and be used for terminal guidance or reconnaissance. By the time the system spots a new terminal moving quickly in the wrong place the thing would have rammed into a civilian building somewhere.

It doesnt matter where starlink terminals came from, all end up registered with Ukrainian MOD. Btw Poland pays subscription on ~50K of those.

There are 9400 active Starlink satellites & they can be launched 28 at a time on a partially reusable rocket. The orbit they operate on is largely self cleaning due to being quite low. The satellites operate in many planes and bands + form a mesh network with laster interconnects.

Sure, if you want to try that and bankrupt Iran even more via its militarry rocket program, you can do that and maybe destray a handfull satellites, provided you can actually hit them and the rocket/s does not fail. And you might even get a nice casus belli as a free extra.

Its a false belief that distro based package management workflows are, or ever were, more secure. Its the same problem, maybe one step removed. Look at all the exploits with things like libxz

There was also the python 2.7 problem for a long time, thanks to this model, it couldn't be updated quickly and developers, including the OS developers, became dependent on it being there by default, and built things around it.

Then when it EOL'd, it left alot of people exposed to vulnerabilities and was quite the mess to update.

> Look at all the exploits with things like libxz

You mean 1 in history vs several every week? Looks to me that there actually is a difference.

The robust and secure distro based package management workflow that shipped the libxz backdoor to everyone, and broke openssh key generation, and most of the functionality of keepassxc?

>workflow that shipped the libxz backdoor to everyone

Isn't it the case that it didn't ship the backdoor? Precisely because of the thorough testing and vetting process?

In other words, it didn't hit any people running Stable distros, only users on Beta versions or rolling releases.

Sounds like an improvement - having beta builds for people to catch those before they arrive in a stable GNU distribution seems the ideal workflow at glance.

On top of that the number of such issues is tiny compared to language distros.

Distro packaging is not perfect, but it is much, much better.

App devs are part of the distro release process. They verify stability with other packages.

It's OS, it's a collab endeavour

where do you get all these trusted people to review your dependencies from?

it can't be anyone, because you're essentially delegating trust.

no way there's enough trustworthy volunteers (and how do you vet them all?)

and who's going to pay them if they're not volunteers?

Language-specific package managers are a natural outgrowth of wanting portability across platforms.

Never in a million years.

Rust's Cargo is sublime. System apt / yum / pacman / brew could never replace it.

Cargo handles so much responsibility outside of system packages that they couldn't even come close to replicating the utility.

Checking language versions, editions, compiling macros and sources, cross-compiling for foreign architectures, linking, handling upgrades, transient dependency versioning, handling conflicts, feature gating, optional compilation, custom linting and strictness, installing sidecars and cli utilities, etc. etc.

Once it's hermetic and namespaced, cargo will be better than apt / yum / etc. They're not really performing the same tasks, but cargo is just so damned good at such important things that it's hard to imagine a better tool.

It's got all the same issues as npm though. The fact that it's so cool makes it a magnet for adding deps. Rust's own docs generator pulls in > 700 deps

When distros figure out how I can test my software with a dep at version A and the same dep at version B in a straightforward way, then we can talk.

NPM forcing a human to click a button on release would have solved a lot of this stuff. So would have many other mitigations.

I run them inside a sandbox.

The npm community is too big that one can never discard it for frontend development.