I use twine for the same reason. Dirt cheap. Lasts forever. Doesn't leave residue on your cables. The downside is I end up cutting the twine when I need to use the cable but a couple inches of twine in insignificant.

Relevant comic expressing the same idea: https://www.facebook.com/twonks/posts/great-job-/13130659843...

I have my own domain. I've been asked for my email, to which I replied "myname@foo.example" and they replied "myname@foo.example.com?".

edit: Changed domain based on ButlerianJihad's suggestion

The perfect opportunity to write "myname@foo.example"!

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

A real domain, for all your fake purposes!

"Do you mean 'myname@foo.example.com'?"

Good suggestion! Fixed.

> who the author is

The article has the author listed at the top. If you click on it, you'll see which university he works for. With his name and university, you can Google to find his wikipedia page.

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

> If not for NAT, we'd all need a firewall

You still need a firewall regardless of NAT. Otherwise, every time you take your computer outside of your home, you're no longer protected. Any attacker or compromised device on your hotel, airport, or coffee shop wifi network would have direct access to your machine.

> being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily.

These are all possible using light containers. For example, on FreeBSD I will spin up a jail which runs wireguard, and then I'll bridge that to another a jail. That 2nd jail is running entirely off wireguard without any other way to access the network. Since it is a jail, it is isolated. And backing up is as simple as a zfs snapshot and zfs send. I assume the same is possible on Linux.

I would argue non-safe binaries are not safe in a container either. And even with full VMs, there have been an embarrassing number of escape exploits over the years.

> seeing how much of my old third-party config I can replace with builtins

There are projects that seek to do just that. I'd recommend taking a look at them to get an idea of whats possible with an almost-entirely-vanilla emacs setup.

  Examples:
  https://codeberg.org/ashton314/emacs-bedrock
  https://github.com/LionyxML/emacs-solo

Those are both fantastic starting points. I wanted to get even more barebones, though, just for the experience of building it up myself from scratch. The options you mention are a far more practical approach than this. I’m just not feeling entirely practical this week.

This is why I prefer "gratis" vs "libre" instead of "free as in speech" vs "free as in beer". gratis/libre are clear and succinct.

As for an actual answer: parties, weddings.

Weddings tend to have a free speech or two, too!

I'm sure this has already been answered somewhere in slashdot hundreds of years ago, but why not just go with "free as in freedom"? And perhaps use the word freedom insted of free when possible

Because freedom isn't free!

But in all seriousness, "free as in freedom" seems fine to me but it is replacing the already unambiguous "free as in speech". You're still stuck with the sometimes-confusing "free as in beer" and they're still cumbersome compared to gratis/libre.

That only works if your audience knows what libre and gratis mean.

> Or maybe you pipe into xargs and pray your filenames don’t have spaces:

> find . -name '*.log' | xargs rm

No need for prayer:

  find . -name '*.log' -print0 | xargs --null rm

That uses null as a delimiter instead of linebreaks.

Related: I wish there were a portable way for xargs to treat newlines as delimeters but not other spaces. Since 99.9% of the time that's what you want. (GNU's has this with -d/--delimiter, but BSD's, and thus macOS's, doesn't.)

--null/-0 is portable and helps, but it means the input has to be NUL-delimited, which is... rare. Sure, find has -print0 but (a) I wish I didn't need to do that, and (b) sometimes it's nice to just pipe `ls` output into xargs, without a `... | while read i; do echo -ne "${i}\0"; done | ...` kludge in the pipeline.

Because spaces in filenames is just common enough to be something that will bite you eventually, but newlines in filenames are a straight evil that you can basically always say is the filename's fault.