If preventing Iran from having a nuclear weapon was really the goal, the JCPOA was working and should have been upheld and extended.

Put the blame on Iran's access to nuclear weapons where it belongs: with the astoundingly stupid decision to tear that deal up because it was Obama that signed it.

After the JCPOA was nullified, Iran went from sub-3% enrichment to above 50%. And that is squarely on Trump because he created the conditions for it.

If there is an Iranian bomb, it's because Trump caused it to be so. Stop using his fucking excuses for this idiotic war that didn't have to be, and nobody wants.

For various values of "enriching", and none of those values allow for a usable nuclear explosive. But don't let that get in the way of your propaganda bullshit.

The JCPOA had these limitations, which Iran was complying with:

No enrichment past 3.67% which is suitable for civilian energy / medical use and NOT WEAPONS in any way
A limit on the total amount of UF6 stockpile (300kg or equivalent)
A limit on the number of centrifuges (5060 operational)

I have sources to back my claims. Where are yours?

Stop parroting lies. Jumpin' Jesus.

It's certainly more plausible than some cuts we've seen; but it's hard not to still see it as the usual "described as fat-trimming; inevitably ends up reaching bone" exercise just because of how software usually ships. Not everything ships in full abject brokenness; but at least for commercial-grade software (specialty formally verified stuff and projects that have been laser focused on solving a specific problem that bothered an academic computer scientist in 1980 since 1980 can be a different story) you don't generally see software that makes you think "Nope, it's finished, any additional resources allocated would be wasted or actively spoil the product. There are no edge cases that could have used a little more love, nothing interesting but currently too rough or subject-to-change to use".

Even if you go with a fairly optimistic view of productivity effects, 10%-ish gain and no serious side effects, just axing 10% of the employees so you can status-quo the product with lower payroll costs absolutely seems like a chop-shopping move when the status quo for software is so mediocre. As PE cuts go they don't seem to be speedrunning the hollowing-out and immediately going to a skeleton crew of junior vibe coders and a 'support' chatbot; but precious little software ships in a state where "efficiency is up 10%" means that you've already maxed out possible product quality and just need to start cutting people since you no longer have anything for them to do. If the optimistic projections pan out they might be able to approximately maintain their existing level of polish with fewer people; but that level was always a compromise.

It's good to know that this is purely a matter of technological change; no need to look at the classic "get picked up be PE chop shop"/"gradually get stripped for parts" hypothesis. Seems very credible.

An interesting notion, considering they're now rocket powered!

As someone who lives in a country where every single vehicle on the road here is imported, I have no problems with BYD being subsidised if the price I pay is lower.

Right. And what about animals that don't read clocks? When my dog thinks it's time to go on a walk but I'm still at the office? What then?

Can we just stop fucking around with the clocks? The whole "oh noes people will be waiting for a school bus in the darksies!" is ridiculous - we have street lamps, and every school bus I've seen for years stops every 100 feet anyway. And any overly concerned parent isn't having their kid ride the bus - they're doing the school run and making traffic in every school zone a fucking nightmare already.

It makes more sense to shift the school schedule by an hour than fucking up all of society.

This would have been useful 10 years ago in certified embedded systems development. But it's not 10 years ago, and basically everyone in that realm is already doing this with regular Linux distros that don't have boutique publisher problems.

What would cause me to move from Debian to this monstrosity, when I can already make a read-only root with crypto attestation and use systemd sysext / confext to plug in things / remove things without changing the root filesystem per certification requirements?

This is a solution looking for a problem, and the problem was solved a long time ago.

Everything this summary is talking about is already available to do with Debian, and can be done better with Debian.

I don't want to build a monolith image for if some tiny config change or patch is needed. This is why systemd sysext / confext exist.

Extra irony that this is already solved by systemd, and this guy is trying to answer a question that his previous project already answered, and answered better.

It's even stupider than that.

You can already do a read-only immutable file system. Embedded systems and avionics already does that, and specifically in avionics it's a design mandate. But we sure as shit don't want to run a full reimage on an LRU while the tail is on the ground for 40 minutes with weight-on-wheels and the flight is closed. That doesn't work.

The irony: systemd fixes this with sysext / confext primitives. We can push new images to /var/lib/extensions-available while in the air, and they benignly sit there until a release agent gets the go-ahead to deploy, and then it symlinks to /var/lib/extensions and `systemd-extension refresh` to merge the extensions with the immutable root filesystem. Rollback is deleting the symlink and running the same command. Each image can be crypto-signed for attestation, software BoM, blah blah blah like they're talking about with this.

This shit is literally going backwards from what already exists. Much like everything else this guy does, he's answering a question that already has acceptable answers, in ways that are worse than what we already have. I'm not running some snowflake distro where I have to wait weeks for security patches when Debian is right there and already can do everything being talked about.

"Hey, let's ignore the actual problems of why people are against us building data centers everywhere, and instead we'll just change the name!"

And then they wonder why people want to screw these guys with their pants on. Renaming the thing doesn't materially change the thing, and just pisses people off because you clearly see there is a problem, and choose not to address the problem and instead play games.

Refrigeration systems have heaters on the evaporator coils to defrost them periodically. Telling the control system to turn on that heater and leave it on will easily accomplish that.

I did this too, in less than 11 days, and mine runs on bare metal on a raspberry pi. You can download the image here. It also runs it's own busybox, and sbase (suckless.org rewrite of busybox) and kubectl and quake, doom, helm, duck db, ffmpeg etc etc I did a write up about it here back in October: Bluetail OS you can download a copy of the 0.0.1 release here https://bluetailos.s3.us-west-... runs in qemu of course, on a raspberry pi 3 A+ profile on 512mb memory
 
Lots of progress since then, refactored a bunch of stuff runs a lot better on bare hardware and has better usb mouse/keyboard support. Oh and it has a usb network adapter as well.

Allegedly the same known-vulnerable Danfoss controllers as in the prior french incident; just chilling out on the internet for easy access. I assume we'll have breathless reports crediting agentic hack swarms by midday along with security vendors assuring us that faith in their next generation machine-speed solutions will save us; but apparently the bar is in hell in terms of low-hanging targets.

"As technology and job responsibilities evolve, accommodations may be reviewed to ensure they remain reasonable and workable."

Translation: We'll grand the accommodation for now while our lawyers figure out a way around it.