I believe probonopd is maintaining that fork as part of their work on AppImage - so it does have an active user group, which is great.

(The AppImage docs suggest using zsync as a mechanism for making images updateable: https://docs.appimage.org/packaging-guide/optional/updates.h...)

(iirc) It was originally slid.es and the slides.com domain was added later, I know it's not an answer to your exact question, but slid.es was a pretty good start point too :-)

(It became a defacto go-to tool for slide decks for me because it was so memorable)

You’re absolutely right. We started as slid.es which is still my personal favorite domain :)

LXCFS can be used with Docker as well (although the integration is manual) which can be quite helpful (eg we're using it with docker-compose and find it very helpful)

Yes it does, but it's very transparent - until you run into a few things that make it obvious, eg if you disk-image size limits, or memory limits.

I work with a few people who believed it was native, and used it for quite a while, until things started going wrong and we logged in to the vm to fix them.

Kinda my point. The reason docker is popular is simply that most of the devs are lazy, not very knowledgeable in the actual underlying technology and very short-sighted.

And docker marketing has very effectively used that to their advantage.

`readlink -e /proc/$$/exe` would be a simple solution on linux -> /proc is such a fun treasure trove of process info :-)

(Not sure it macOS has as much info in /proc?)

> Not sure it macOS has as much info in /proc?

macOS does not have procfs

> macOS does not have procfs

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

It also got dropped from OpenBSD:

> It was removed from OpenBSD in version 5.7, which was released in May 2015, because it "always suffered from race conditions and is now unused".[2]

The OpenBSD people don't say what you should replace it with, but backing up in the paragraph, the FreeBSD people do:

> As of February 2011, procfs is gradually becoming phased out in FreeBSD.[1]

Chasing that reference:

https://lists.freebsd.org/pipermail/freebsd-fs/2011-February...

> Why is procfs deprecated in favor of procstat?

[snip]

> The security issues are long-standing and there have been many over the years, but the real reason is something that's less evident (or at least less directly apparent):

> Simply put, procfs on FreeBSD has been neglected. There isn't a lot of attention being given to it, and the only modifications in recent months/years have been generally minor compared to the rest of the tree. You can review some of the commits yourself:

> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/procfs/

> Others like yourself have asked what the state of procfs is, going back as far as 2005. Be sure to read the reply as well:

> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/20...

Here's the FreeBSD procstat manpage:

https://www.freebsd.org/cgi/man.cgi?procstat

Aside from bitrot, is there a reason to prefer procstat over procfs?

Do you have any resources about /proc you'd recommend?

`man proc' is quite good. https://man7.org/linux/man-pages/man5/proc.5.html

/proc is Linux specific, but it's extremely useful. A lot of tools are actually built on top of it, for example ps.

  ngarvey@cheapo:~$ strace ps aux |& grep cmdline | head
  openat(AT_FDCWD, "/proc/1/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/2/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/3/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/4/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/9/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/10/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/11/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/12/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/13/cmdline", O_RDONLY) = 6
  openat(AT_FDCWD, "/proc/14/cmdline", O_RDONLY) = 6

Actually it was copied from Solaris, https://docs.oracle.com/cd/E19253-01/816-5174/proc-4/index.h...

does not work in Fish Shell.

  fish: $$ is not the pid. In fish, please use $fish_pid.

  readlink -e /proc/$$/exe

                     ^

The useful thing I've found from this is that "AEG" in Australia is the same as "RIDGID" (orange) in the US and the batteries are compatible.

So I've been able to buy tools that are not available as AEG tools in Australia (ie they're not offered in the product range here). I purchased them skin only to avoid any charger incompatibilities (and use the AEG batteries and charges with the RIDGID tools).

It might work in reverse that buying AEG from Australia is now a cheaper way to get RIDGID tools because the Australian dollar is quite weak compared to the US dollar.

I didn't know the `CTRL-x * ` expansion; it appears to work in zsh for brace expansion:

  $ touch asdf-{gh,jk}-l
  # CTRL-x *
  $ touch asdf-gh-l asdf-jk-l

In zsh you can use tab to expand globs/braces/variables as well.

A related article and associated discussion: https://news.ycombinator.com/item?id=22220342

What is the reasoning for implying that Japan are handling the problem more effectively than others?

A friend of mine living in Japan thinks there's a "burying their head in the sand" type mentality going on.

They've only performed 32,000 tests (which is 16,484 people); which makes it hard to know exactly how the disease is spreading there.

https://www.reuters.com/article/us-health-coronavirus-japan-...

Heard the same... we will see how it is.

Thinking here is Abe/Japan do not want to delay the Olympics, so aren't testing...

It would be an acceptable reason for cancellation coverage with a lot of travel insurance (ymmv, but I know of less-logical reasons for cancellation that were covered).