dmuth

Same! I remember a co-worker getting a call from a relative about it so I went to cnn.com. ...only to see it time out. Same with usatoday.com and abcnews.com. At that point I knew that something was happening.

I then happened to remember that abcnews.com.au existed and figured Australia's websites weren't getting hit quite as hard as ours, and I was right. It was front page news there.

We all left the office (which was in Center City Philadelphia) a few minutes later.

stdout and stderr output often ends up in a black hole

Ain't that the truth. Literally every crontab I've written for the last 10 years has had this in it:

2>&1 | logger -t cron-WHATEVER

...and that does a pretty good job of capturing anything that the script emits and making it easy to grep for in syslog the following morning.

But I'm still amazed at how many crontabs I run across that don't capture any output at all.

Beat me to it! I did in fact have experiences like that with Perl in years past.

Your username is nice nostalgia for me. :-)

This is one reason why whenever I build a new project, I build it inside of a Docker container.

That way, the project has just the dependencies it needs, and I know I can rebuild it at some point in the future and will be unlikely to run into problems when I do.

Check your Python version.

Try switching to the newest version of Python with something like Pyenv, or even try spinning up a Docker image with something like:

docker run -it -v $(pwd):/mnt python:3.13 bash

...and try using the utility there. Good luck!

Using CAs and signed certificates in SSH is definitely the way.

If anyone wants to play around with that, without the risk of locking themselves out of a server, I built a little "playground" awhile back whihc is a series of Docker containers that can SSH to each other. Give it a try at https://github.com/dmuth/ssh-principal-and-ca-playground

(I haven't touched the project in awhile, so if there are any issues, please open an Issue and I'll gladly look at it!)

I wrote my first ever TamperMonkey script, to add some tools to a Facebook group that I moderate:

https://github.com/dmuth/facebook-javascript-toolbox

Definitely. This is one of my favorite books due to both the writing style and the "behind the scenes" aspect of living and working in Antarctica.

If you want to test to see if you're successfully sending out IPv6 traffic, I have an endpoint for that:

https://httpbin.dmuth.org/ip/v6

I can offer what much younger me was once told by a senior engineer:

1) With respect to not having whitespace: "Not everyone is as smart as you, and you need to ask yourself, do you want junior engineers working on your code to keep bothering you asking how things work, or would you rather your code by easy to read (and commented) so that they can pick things up on their own?"

2) With respect to complexity: "We are expected to build products that align with business objectives. New and experimental code belongs in your home lab and on your GitHub, not in a production environment."

Depending on how things go with #2, maybe offer to let the engineers spend 20% of their time working on lab projects to improve their product, with the understanding being that the rest of the time they are expected to build products with a minimum of complexity.

I wrote an open source project that may be useful to people here:

https://github.com/dmuth/git-rebase-i-playground

It lets you create a Git repo with synthetic commits and has sample exercises for doing different things within that repo, such as removing commits or squashing commits. (along with hints and answers)

Building this project helped me understand the ins and outs of Git much better and I suspect there will be value for anyone else who works through the examples.

For those curious about how SSH CAs and key signing works, I wrote a blog post about that awhile ago: https://dmuth.medium.com/ssh-at-scale-cas-and-principals-b27...

I also created a "playground" which can be used to stand up such an environment running in Docker containers to better understand the process: https://github.com/dmuth/ssh-principal-and-ca-playground

Hope folks here find them helpful.

That's interesting about the blocksize. I was never impacted by that because I mostly use dd for writing large files, and a large block size always made more sense to me. For example, if I wanted to test writing a 1 GB file to a flash drive, I'd do something like:

dd if=/dev/zero of=/mnt/test.data bs=1M count=1024

Overall, a very informative article though!

Agreed--SSH certificate authorities (and principals) are powerful things that can be used to manage SSH access at scale. My workplace is a large enterprise that uses our own CA for getting access to systems--the keys it issues are good for 8 hours, then we have to grab a new key (using an internal utility).

For anyone who is interested, I put together a little playground which can be spun up in Docker that allows you to play around with and learn how SSH CAs and Principals work:

https://github.com/dmuth/ssh-principal-and-ca-playground

I built something which may be able to help: https://github.com/dmuth/grafana-playground

You'll want to spin this up in Docker Compose, and to add custom hosts upstream of you (such as ISP routers), you can edit the hosts.txt file (to add in human-friendly names such as "upstream") and add those hosts in the HOSTS variable in the docker-compose.yml file.

Feel free to open an issue on the project or reach out privately if you have any questions.

We had something like this in a Philadephia sports stadium as well: https://www.inquirer.com/news/the-secret-apartment-vet-stadi...

If you use LetsEncrypt and Docker, I can recommend HTTPS Portal to automatically manage your SSL certs: https://github.com/SteveLTN/https-portal

I use it for my blog and have never had any issues with certs being renewed well in advance of their expiration date.

"Never ever copy your private keys on a computer somebody else owns."

FTFY.

In more detail: if your private keys ever leave your computer via the network, it's a good idea to consider your private keys compromised and to burn them and create new ones.

If you're in an organization which uses SSH CAs and Principals (see https://dmuth.medium.com/ssh-at-scale-cas-and-principals-b27... for details), you'll only need to create a single keypair, get it signed, and you're good to go again.

I got in a painfully stupid argument with a middle-age IT admin “we don’t want to our employees installing apps”

If they think that any domain that ends in .app is for installing apps, their mind is gonna be blown about some of the sites on .net and .org domains...

Very cool. I see my page (https://hnbadges.netlify.app/?user=dmuth) has the "colorful" flag, probably due to the profanity I have in my bio. :-)

I don't disagree with your post, but one thing I want to mention is the origin of the term "Incident Commander"--it doesn't exist to be cool, but rather derives from how FEMA handles disasters. I suspect its usage in IT became a thing because it was already used in real-life, and it made more sense than creating a new term.

If you have two hours, you can take the training that describes the nomenclature behind the Incident Command System, and why it became a thing:

https://training.fema.gov/is/courseoverview.aspx?code=is-100...

This online training takes about 2 hours and is open to the general public. I took it on a Saturday afternoon some years ago and it gave me useful context to why certain things are standardized.

Oh god yes!

When I'm interviewing someone, especially for a senior position, I want to make sure that they know what they say they know on their resume. Having code up on GitHub, or an actual working side project is a great way to show those things off.

Even code that doesn't look great, but shows that some level of effort was made to learn a new technology is okay. If anything, it then gives me a jumping off point in the interview to ask the candidate about that project, why it's in that state, why certain decisions were made, etc.

I am seriously having a difficult time thinking of downsides in listing a personal project, so I say go for it.

Not a doctor, but I have/had similar problems, and saw a number of doctors and specialists about this.

Whatever it was, it wasn't understood by medical science, but the best thing we were able to pin it down to was "muscle spasms". Over time, I found that seeing a myofascial specialist, yoga, and physical therapy (read: Apple Fitness Plus) helped.

If you'd like to chat more about this topic or just pick my brain, my email is my username AT my username DOT org.

Someone tell me if I'm missing something, but isn't the whole point of hosting things in a virtual environment so that when you want to switch/upgrade OSes, you stand up a second server and start migrating apps over one at a time?

I can't understand why that doesn't done here.

If a bank shuts down and goes into FDIC receivership, it re-opens the next day.

Have I got a story for you.

What you described normally happens.... Unless the bank fails so hard that no buyer for it is found, and then the FDIC insurance kicks in.

I know, because it happened to me back in 2012. :-) My bank failed, and they were in such bad shape that nobody wanted to buy it! I got an email on a Saturday morning stating that my bank had failed. Here's a copy of said email: https://imgur.com/a/HR42BxZ

The following Thursday, the check from the FDIC for the contents of my bank account arrived in the mail.

I couldn't load the site either, but it reminds me of something I built a couple of years ago that let me analyze the happiness of specific Twitter users: https://github.com/dmuth/twitter-aws-comprehend

Some interesting takeaways from my experiment:

- President Obama's tweets became a LOT happier once he left office.

- Donald Trump's tweets were less negative than one might think! I did some digging and found most of the "happy" tweets were made by his social media team--the tweets made by him personally were quite angry.

If anyone does want to get more into the internals of Git without playing with a production repo, I built a "playground" awhile ago which creates a simple Git repo of synthetic commits which you can then play around with:

https://github.com/dmuth/git-rebase-i-playground

I know it says "rebase -i", which originally what I built it for (and what the exercises in the README are for), but you can really do whatever you want in it, and blow away/rebuild the repo with the included script.

Enjoy!

Genuinely curious, is this true for most people?

In my experience, understanding the code 6 months later isn't the challenge, but rather understanding why I made the set of decisions I did with regards to any tradeoffs I made when writing the code.

The best way I can think of to try and keep that from happening is to comment, comment, and comment some more. Specifically, I try to explain not just the HOW but the WHY of a certain approach that I took. The way I see it, if using a little more disk space for comments saves me a little time from having to try and remember why I did something 6 months later, I'm cool with that. :-)

When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew.

This is the comment I came here for. (see what I did there?)

I also sometimes keep multiple versions of the same line in comments, such as when I'm trying to a tricky regex work. For example, I might have code that looks like:

  # x = regex1 # Original line
  # x = regex2 # Doesn't work
  # x = regex3 # Nope
  # x = regex4 # Also nope
  x = regex5 # Currently testing this

When I get a working solution, I comment out all but the line that works and commit that.