That's fair, that example would be better with a modest timeout (e.g. if podman had a bug that caused it to hang), without taking away from the main points. Updated.
The post shows long-running stop scripts / containers and demonstrates them delaying shutdown (not with KillMode none though)
@CGamesPlay network.target's "primary purpose is for ordering things properly at shutdown: since the shutdown ordering of units in systemd is the reverse of the startup ordering, any unit that is order After=network.target can be sure that it is stopped before the network is shut down if the system is powered off."
Some useful Ignition configs can be found in the https://github.com/coreos/coreos-baremetal examples. For those wondering about the format, they're converted to JSON and served to machines.
I think many Linux users have hacked around and messed up settings. This line was meant for those who have been in that situation, to say "hey btw, that screen was a login shell" (even took a picture of it). Just adds a little context, it doesn't resonate with everyone.
I think booting to a console when you expect a desktop can be scary, especially if you don't know how to undo whatever you did.
~/.profile is executed only at login on Ubuntu so changing your PATH there will be applied the next time you login. You can source the ~/.profile in your current non-login shell if you need the PATH change right now. I've tried to tweak the second paragraph in the "When not to modify .bashrc?" section to make this more clear.
The problem is that running an MPI program on a remote node starts a new non-interactive SSH session. That SSH session has no parent login session, so it won't inherit environment variables from any session that read the .profile file. And because the SSH login is non-interactive, the only file that the shell inside the SSH session reads is .bashrc.
Sure, you could source .profile manually, but this is awkward to code inside an MPI application. In addition, this will cause .bashrc to get sourced twice, because your shell already read .bashrc when it started the SSH session. Hopefully your .bashrc is idempotent, but even so, it feels wrong to have to read .bashrc twice.
It has to do with the fact that the GP put the URL in < > and HN assumed the trailing > was part of the URL. Just remove the trailing > in the URL and it'll work.
Someone asked about the opposite on Twitter: https://twitter.com/DannoHung/status/1585350836074446869