Notices by Wolf480pl (wolf480pl@mstdn.io), page 3

@ignaloidas hmm what do you mean devops side / what is your current role?

IME, anything from "make Jenkins notify people that their docker image is built" to "develop a way to shrink persistent volumes on k8s" to "automate removing permissions in 15 different systems when offboarding an employee" can be done with python and shell (and a bit of groovy in case of Jenkins).

And while many of the tools I use are written in golang, I rarely have to write any golang code.

@quad but in either case it immediately shows up in metrics...

@ivesen @nadia
there's also this:
https://www.youtube.com/watch?v=IawfrWLDN4U

which is sub-ambient but above-freezing and yes, the IHS is a problem...

(please someone tell me I'm wrong, or that there are other reasons I didn't take into account)

I was wondering why the colder a CPU is, the further you can overclock it...

And by colder I don't mean more watts of heat taken away from it at the same die temperature, I mean lower temperature at the same heat flow.

Well, one of the limiting factors of overclocking is square signal becoming insufficiently square. That's because of stray capacitance. But a capacitor alone can't round the edges of a square signal - it needs some resistance on where the signal is coming from.

1/

Idk how stray capacitance reacts to temperature. But if it's anything like ceramic capacitors, it should have more capacitance when it's cold, right? So that can't be it.

And what about resistance?

Well, semiconductors have higher resistance when they're cold, and lower when they're hot, right? So that shouldn't help either.

But! the silicon is only a small part of the chip. The rest is wires. Layers upon layers of tiny metal wires. And in metals, resistance increases with temperature.

2/

So my guess is that the reason overclocking benefits from sub-ambient temperatures is that the metal wires in the CPU have less resistance when they're cold.

@ivesen yeah, the cold bug

> When you're throwing a workload at it, you can go to, say, -160C, but when you reboot, there's no more workload, all of a sudden you can't boot anymore. Then you have to increase to -140C to boot."

https://www.pcgamer.com/overclocking-a-cpu-to-7-ghz-with-the-science-of-liquid-nitrogen/

I'm guessing at that point there isn't enough free charges in the silicon for it to (semi)conduct.

But IIRC there is a sweet spot and it's below zero... lemme do some seraching

@ivesen I mean T_die.

The aggregate of the readings of the dozens of temperature sensors built into the CPU silicon.

@ivesen but yeah I guess it can be confusing.

I just opened GamersNexus's last livestream where the AMD guys visited him to do some XOC, skipped to the part when they started running some benchmarks, and they were saying their target with that particular CPU is -120°C, because at -130°C it won't boot, and at -125°C it only sometimes works.

And it wasn't clear if they meant Tdie or Tpot

@Nepiant @quad like, imagine one day you're competing in CTFs or reading up on the latest CPU vulns or some other novel difficult exploits that require immense skill to pull off

And the next day you go do pentests for a customer whose webapp uses outdated libraries with known vulns, and also has a mongodb with default password exposed on the internet, and holds the door open for you despite not knowing you.

And you know that most companies are like that

@domi in theory that should be doable as a Framework extension module...

@lanodan @nytpu @lispi314
oh, in the sense that it's not a single git repo everyone has - yes, that would be a problem.

I wish they were still doing source CDs :/

@lanodan @nytpu @lispi314
also being a debian downstream distro is one of the sanest ways of doing infrastructure-as-code with Debian

@lanodan @nytpu @lispi314
yeah, you typically become a debian downstream instead of forking it

@lanodan @nytpu @lispi314
IIRC (some?) Debian source packages use an upstream source tarball + -debian tarball (containing the debian/ directory, including patches and buildscripts) that gets extracted on top of it, and then patches get applied.

It's not as clean as I would like, but in principle the stuff authored by Debian is separate from upstream code.

You just need pre-compromise build-essential, upsteram tarballs, and audited *-debian tarballs.

@lanodan @nytpu @lispi314
(assuming by compromise you mean "someone tried to put a backdoor in the source packages")

@lispi314 @nytpu I think another way to become resilient against link rot is to have all the source code of the packages you use in one place.

There used to be source CDs but most distros don't fit on a CD or a DVD anymore. So either mirrors like Debian does, or keeping the source code of everything you install on your local disk (or a NAS).

A while ago I was of the opinion that Gentoo users are uniquely well prepared for an apocalypse, but that may've changed recently

I remember my dad's RedHat came on 4 CDs: 2 Binary Discs, one Source Disc and one Documentation Disc.

If it worked the way I think, you could take it to a desert island and rebuild everything from source, with just those 4 CDs and an x86 computer.

Today a Debian mirror has 100+ GB of source packages and 600+ GB of binaries just for amd64.

But at least it's one place, heavily replicated. And IIRC it's supposed to work on a desert island.

2/

@jonty Fiat Punto Door Connector