Ansible exists because it makes things idempotent, which is great when you have to do a thing on 1,000 servers because you can just fix the role and re-run it.

Bash can be idempotent but isn’t by default, so you either spend time making and idempotent bash script or you spend time learning Ansible to accomplish the same thing in a reusable way

This is only true if you aren’t internally mirroring those packages.

Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.

This isn’t how it works, you can invoke your right to a speedy trial at any point you want. You can spend 2 months waiting and then invoke it if you want.

The timer starts from when you invoke it, though.

The 2 issues, which she may be caught in, are that it’s “speedy” from the perspective of a court, and that it really means “free from undue delays”.

There is no general definition of a speedy trial, but I think the shortest period any state defines is a month (with some states considering several months to still be “speedy”).

A trial can still be speedy even past that window if the prosecution can make a case that they genuinely need more time (like waiting for lab tests to come back).

It’s basically only ever not speedy if the prosecution is just not doing anything.

Xmage is basically an unofficial variant of MTGO that does support actual multiplayer. All the cards are free, you don’t even have to grind to get them.

It is ugly as sin, but so is MTGO.

I think that article proves the opposite.

> While xz is commonly present in most Linux distributions, at the time of discovery the backdoored version had not yet been widely deployed to production systems, but was present in development versions of major distributions.

Ie if you weren’t running dev distros in prod, you probably weren’t exposed.

Honestly a lot of packaging is coming back around to “maybe we shouldn’t immediately use newly released stuff” by delaying their use of new versions. It starts to look an awful lot like apt/yum/dnf/etc.

I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.

Per below, xz is also an example of us getting lucky.

> I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.

Yes, but this also has nothing to do with native vs. non-native.

This is the security equivalent of having a better lock than your neighbour. Won't save you in the end but you won't be first. Then again, yours could also be broken and you don't get to tick of that audit checkbox.

It’s a fundamentally different and riskier paradigm. Nuclear weapons at rest are inert, and can even be disarmed. If the lock falls off the gate at the compound, the nukes won’t spontaneously explode.

Antimatter is always “armed” and is only rendered safe by containment. If containment fails, it explodes. It’s more like keeping a massive stockpile of fluorine, but somehow worse and harder to contain.

> They just want their invoicing system to just f-ing work for a change.

Time will tell, but I'm dubious this will hold longer-term. I don't doubt that Claude can write the code, but I am dubious Claude can manage it sanely. Does it have backups? Does the guy that wrote it know how to restore those, or can Claude do it? Can Claude upgrade the backend and/or migrate the data when the backend changes, or is this going to be running known CVEs in a month?

This has sort of always been a thing via hiring CS students as interns. I don't doubt most of them could jam out something that looks like Slack or Gmail. The problems aren't apparent immediately, they become apparent when you realize it doesn't handle invalid responses well and the backups are hosed so you just lost a bunch of data.

Even that doesn’t really make sense to me, unless they’ve done it in a way where everything has to move at once.

Everywhere I’ve worked, if a migration is causing this much downtime then you kill the migration or slow it down. If every change has a 10% chance of bringing the site down, you only do a change every week or two until you can work out the kinks.

...or you keep fighting forward with the migration, because if it's seen as a failure then some pretty big heads will have to roll...

Reminds me of the bank for my business where a larger bank with terrible IT bought a smaller bank with great IT - guess which systems they standardized on? Online banking is still much worse than before and the web interface still says "will be migrated by end of 2023" for some parts. Many customers just left and complaints were widely reported in the media. I probably should leave, too.

I mean, they are seemingly breaking every week or two so that might be what they are doing.

You may be surprised how many people can't mentally disassemble basic mechanical systems. I just helped a family member change the handle/arm on their toilet, and they'd been waiting a month for someone else to help. My mom is currently waiting for me to pick up some drywall anchors to re-mount a (small, lightweight) light fixture.

There are a lot of people who don't understand this stuff to a degree where they don't even know whether a repair is dangerous or not. My family member was afraid that if they messed up installing the toilet arm they'd flood their house.

Those people are very capable of having a few repairs a month, just on random stuff. Cabinet hinge screws wore out their hole and just needs a bigger screw, shower curtain mounting is loose and needs new anchors, an outdoor light fixture with a bulb cover needs a new lightbulb and they can't figure out how to get the cover off, etc.

Even better, why would they bother? If it's a non-monetary hack (i.e. for data), hacking them back won't undo leaking the data. If it's a monetary hack, there are surely much better recovery options than trying to do a hack-in-kind to take it back.

It also seems incredibly risky. This US admin might be okay with it, but will the next? For multi-national corporations, will other nations be okay with it? I wouldn't think countries unassociated with the conflict would be happy with digital privateering.

> For multi-national corporations, will other nations be okay with it?

imagine hacking back and accidentally hitting a hospital killing someone in the process

that is a fast line to get an Interpol terrorist arrest request on your head, sure the US won't hand you over, but have fun to never leave the US and get assets abroad sized

I wouldn’t bet my freedom on the current US admin sticking their neck out to save me. Domestically, they’re hemorrhaging polling numbers and can’t eat the PR hit of “innocent people in a random country died because of what we said”. Abroad, we are in a much weaker position than we were a couple years ago both in terms of alliances and economics. We feel very vulnerable to foreign tariffs with the economy as it is.

Does that happen to state sponsored Iranian hackers?

the comments are about "private firms hacking back"

not about highly specialized groups hacking first

but also "professional hackers" have screwed over hospitals before and confirmed it was accidental, so potentially yes

worse Iranian terrorist with hacking skills might intentional target hospitals and they might not sit in Iran so disconnecting Iran is unlikely to help at all with such a threat

At first I thought this was a joke comment, like you could accidentally fire a hacking missile and hit a hospital… but you’re serious?

Hacks that need to cross an air gap are often self-replicating. Ie you get an email with a compromised PDF, and your phone starts distributing it to everything else on the same network so if you connect your phone to the air gapped network it can get in.

Then you end up with collateral damage if your wife or roommate or whatever works at a hospital and they take their infected device to work.