I very rarely listen to them in that form, but I honestly like the idea that in a post-Carrington event, zombie apocalypse or mad-max style future where electricity or electronics become scarce, I can (if desperate enough) listen to them with a nail and a cone.

Last time I asked, user hackmiester pointed me to https://goughlui.com/2016/05/03/project-the-definitive-colle...

The "Texas Instruments DSP based Modems" linking to USR-Sportster-bong-bong.wav is pretty close to what I remember.

edit: hackernudes reply is perfect. The youtube auto generated subtitles are pleasing too.

Amazingly still works on Win 11 and still seems to keep it local (bypassing the windows search), so I'm pleased to report consistent results for 30 ish years.

Of course, now I've mentioned it out loud, it'll be the next thing to go...

I don't know if it's just me being old and grumpy, but everything windows 8 and later (server 2003) seems like half-baked, unfinished enshittification. Trying to do something even vaguely "advanced" to a network adapter puts me back in windows 95 land along with the run box. The "manage" pane with device & disk manager and logs is from a totally bygone era yet it seems to still be the only way of getting that information. The worst bit is, I'm not complaining. All the bits that look and feel like they've been forgotten since Windows 2000 are the easiest, least infuriating bits of the system I interact with.

I was going to point out that with the variance in FM demodulation chips, using a pile of FM receivers probably wouldn't get you perfectly synced audio these days at all, even more so if it's going through usb/software/audio stacks.

Then I re-read the Ops comment and this actually seems to be a network of _transmitters_. I'm not sure what problem they're trying to solve, but I can't believe multiple PiFMs is ever the answer.

Commercial DAB radio does use single frequency networks (with tight timings and clever calculated offsets), and I am somewhat curious how analogue FM responds with regard to offset destructive interference, but this isn't that.

Please don't do this. For context, a car FM transmitter is limited to 250nW (in many jurisdictions). A Pi GPIO pin with the right bit of wire is potentially capable of 10mW or more. 40,000 times more powerful and a lot more noisy. One could be causing problems for people surprisingly far away.

https://en.wikipedia.org/wiki/Thornborough_Henges

As it stands at the minute, the clocks are a mere 5 microseconds out and will slowly get better over time. This isn't even in the error measurement range and so they know it's not going to have a major effect on anything.

When the event started and they lost power and access to the site, they also lost their management access to the clocks as well. At this point they don't know how wrong the clocks are, or how more wrong they're going to get.

If someone restores power to the campus, the clocks are going to be online (all the switches and routers connecting them to the internet suddenly boot up), before they've had a chance to get admin control back. If something happened when they were offline and the clocks drifted significantly, then when they came online half the world might decide to believe them and suddenly step change to follow them. This could cause absolute havoc.

Potentially safer to scram something than have it come back online in an unknown state, especially if (lots of) other things are are going to react to it.

In the last NIST post, someone linked to The Time Rift of 2100: How We lost the Future --- and Gained the Past. It's a short story that highlights some of the dangers of fractured time in a world that uses high precision timing to let things talk to each other: https://tech.slashdot.org/comments.pl?sid=7132077&cid=493082...

Of all my many gripes with Teams, it usually handles code surprisingly well. Single `inline` and triple backtick blocks usually render as you'd expect.

OneNote on the other hand doesn't support a code-block at all, and is worse (if you can believe it) than storing cli commands in Word docs.

A lot of it depends on the size and skill-set of your team and the escalation routes available to you, but in general (and off the top of my head):

- Get the first people on scene to give a summary of the problem as they know it. Make sure everyone actually agrees on what the problem is and what symptoms have been observed. Understand what areas people are currently investigating and make sure they aren't trampling over each other or actually making the situation worse [1]

- Make sure the situation hasn't evolved whilst the first on scene have been investigating the initial symptoms. It's easy to get lost in the weeds digging into a handful of monitoring alerts only to look up and realise there's now 300 and the original problem is only a small part of what's going on.

- If there isn't one already and you're not better doing something else, become incident commander. When done right it's an extremely important and useful role.

  - Take over external communication and protect the team from distractions
  - Start assessing escalation options
  - Take copious notes and keep a timeline 
  - Act as a shared memory and keep people honest 
  - Have a less panicked, wider (non minutia) view of the problem
  - Start collating and pulling up documentation/schematics so the people at the coalface can quickly query it rather than getting distracted searching for it.
  - Be ready to jump, for when someone inevitably asks "can someone check..." or "does anyone know"
  - Keep track of the "shared truth" of the incident as it evolves. What have we witnessed, what do we believe is the cause, _why_ do we believe that? Have we invalidated anything, do we need to reassess, are we sure logical lynchpins aren't confirmation bias or dyslexia?
  - Onboard new people and hand over if appropriate.

If you get a moment, it can also be a good time to assess how useful your monitoring is during an actual event.

[1] "Hey, server x has flagged on monitoring and my ssh session is hung waiting for a login prompt!" I've been round the houses enough to know this is probably OOM and if I just wait, I'm likely to finally get in. I also know that saying this in a room of 20 technical people, means the server is now processing 22 new ssh sessions and now no one is getting anywhere.

[2] The famous Malcolm in the Middle intro where Hal is tasked with changing a lightbulb and ends up repairing the car. Except in my example the bulb is actually fine and there's a power cut we missed. https://www.youtube.com/watch?v=AbSehcT19u0

I'm a big believer in thinking you have backups being worse than knowing you don't, so anything that encourages people to believe $(flash memory) is suitable as long-term cold storage is actually, really bad.

I agree there's no need to copy & wipe cards immediately, but treating them as "film" is inherently flawed and setting yourself up for failure. The amount of people that turn up in data recovery forums unable to access old, important, "backed up" (memory card/ssd on a shelf) photos is depressingly high.

Juniper themselves stated in the manual that this base model device didn't support SCTP, though on ever other level it was faster, more capable and more featureful than the mid-range but much older device it replaced. The MSP didn't have a clue that we (or anyone else for that matter) used SCTP so missed the single footnote mention that the command to enable SCTP forwarding might not be available on some base-level devices.

In their defence, I'm not sure _I'd_ have thought to check if SCTP was supported and I had it running on my network. It works over the internet, it's basically IP, how could it not be suppo---oh.

I had a similar problem a few years back with a technophobe Grandma who wouldn't use whatsapp and a stingy aunt who'd moved to the states.

Used a Fritz!Box as it'll act as a DECT<->SIP server so my grandma could keep picking up her usual handset. Had a rule which matched the aunt's phone number so it got bounced via my FreeSwitch server rather than her PSTN, and some least-cost routing rules to pick a US based provider SIP provider with a +01 PSTN number so my aunt saw the incoming call looking local and could ring back if necessary at a cheap rate.

Honestly, the weird technical abominations we come up with to try and serve family members. The same Grandma went through a phase of falling, not being able to get up and then waiting hours for an ambulance to arrive. Would she tell the family? Would she sod. Was her regional ambulance service still dispatching jobs via pager message? You betcha. Did this end up with an SDR, POCSAG decoder and a regx looking for her postcode? Absolutely not; why would you ask such a thing?

My old company/offices had site internet provided by one of the top 50 UK Managed Service Providers. They swapped out the on-site router not many years ago as the fibre to site was being upgraded from 100mbit to gigabit and so a new Juniper firewall with GBE ports was required.

Turns out the newer, faster, shinier, though albeit lower model numbered'd Juniper SRX fundamentally didn't support passing SCTP data and suddenly we lost access to all our remote stuff that used it. Ended up on a call with the MSPs Head of Networks (who was not a stupid person), but their opening gambit was "Are you sure you mean SCTP? Oh. What is that then?"

There was also numerous weird kernel bugs with implementations on CentOS 5, 6 and 7 which all would manage to get themselves into weird states where only a reboot would clear - not really what you want from a multi-endpoint, 'copes and recovers well from network weirdness' tunnelling protocol.

Which is a shame, because I have a number of problematic links (low bandwidth, high latency) that wireguard would be absolutely fantastic for, but neither end supports it and there's no chance they'll let me start terminating a tonne of VPNs in software on a random *nix box.

This video is done by hand and explains a bit more about how and why it works: https://www.youtube.com/watch?v=hB6eY73sLV0