On the one hand this idea is brilliant - on the other hand if it caught on, there are some obvious opportunities for malware intrinsic to the approach :'(

I think I'd be too chicken to subscribe.

Make the CI pipeline create a Docker image that contains Debian slim and the man pages installed.

On the other hand, it's Docker, so you know every blog will use their own base image.

Guys: Serve your blog via Docker itself. Docker image names are _already_ URLs. You could literally just have people do `docker pull myblog.com/recipes:latest` or `myblog.com/recipes:lasagna`.

Edit: and navigate like so: `docker image myblog.com/recipes` to list all recipes. God I love APIs.

And add search logic to the tag, so you don't need to know the name of the post, just the right word(s) to find it and let the "I'm feeling lucky" algorithm pick the right one :)

And then someone ports that back to regular Docker, and we get a whole new dimension of software supply chain security issues :).

I can't tell how much of this is sarcasm. Turning what started out as a problem of "How do you load arbitrary remote TROFF sources into man" into "throw docker at it" because someone suggested an intermediate solution of "apt" which introduces security issues and no one posed that there might be an alternative that obviates any need for containerization. I mean these two things could be further from each other on the scale of incredibly lightweight to massively heavyweight.

Or maybe this is a microcosm of why docker and kuberwhatever happens so much.

It's the nerd version of that Reddit pattern of organic comment chain, each reply adding e.g. a line of song - only with pushing an absurd idea to the limits.

I'll bite: with GP's take, docker-compose would make for a good webring/blogroll. Or use it as bookmarking system.

  cd blogs/cooking
  docker-compose up
  # 20 different recipe blogs available as man pages

Exactly this. Just having fun.

I can confirm that I was jesting when I said to use Docker here :^)

I thought we were just riffing, I wasn’t actually proposing this as a genuine technical solution. Just a fun thought experiment :)

It's probably more satire than anything else.

Weekend project: Docker pull blog posts over DNS

Docker is the example implementation of "containers do not contain". At least I would use podman.

How does HTTP(S) Same Origin policy work with local file:/// URLs?

TIL there's no `ls -al /use/share/man/** | man --html`; though it would be easy to build one with Python's http.server, or bottlepy, or bash,.

Prompt: An http server ( with bash and /dev/tcp/ ) that serves HTML versions of local manpages with linkification of URLs and references to other manpages

> How does HTTP(S) Same Origin policy work with local file:/// URLs?

It doesn't since file:/// is just a uri and not part of the http protocol

If I open an HTML copy of a manpage that contains JS from a file:/// URL, can it read other local files and send them to another server with img URLs?

If so, Isn't it thus probably better to run an HTTP server over a permissioned socket than to serve static HTML [manpages] from file URLs [in a [DEB] package]?

file:/// is always going to be local to the machine reading the URI. So if you're serving a page that has a file:/// uri in it and someone on another machine clicks on it, they wont be seeing the file (unless they happen to have the same path on their machine). If the goal is get them that file, then yes, it'll need to be served.

CVE-2019-11730: https://nvd.nist.gov/vuln/detail/CVE-2019-11730

_adds to their TODO list :D_

Please also create an AUR package for Arch Linux.

Release as a Flatpak and make it distro agnostic!

Make it even better and release an AppImage!

Even even better, put it on the web so it’s accessible from anywhere

wow, there. Lets not get crazy there. It's plenty enough to support multiple package managers, but what you are considering is just too much!

Okay, just create an iOS application.

This is now in progress.

https://github.com/capjamesg/jamesg.blog.deb has all you need to build a man-page-only deb file using:

git clone https://github.com/capjamesg/jamesg.blog.deb cd jamesg.blog.deb dpkg-deb --build --root-owner-group jamesg.blog sudo dpkg -i jamesg.blog.deb

You should see:

... Processing triggers for man-db (2.9.1-1) ...

Which indicates the man page for `man jamesg.blog` is available. There is just a placeholder in there for now. I will perhaps finish this tomorrow!

NB: This may become a blog post soon :D

first thing came to my mind when i read the blog. it would be a very cool thing. i hope this becomes a thing.

Release your blog as an Electron application please.

How would that fit on a RK07 disk?

There's some precedent for this. Debian used to provide access to the now-defunct Linux Gazette, and still offers numerous informational packages (package docs, manpages, info pages, RFCs, Linux HOWTOs, and more), all of which can be served locally through the dww package, "Read all on-line documentation with a WWW browser":

<https://packages.debian.org/bookworm/dwww>

(Joerg Jaspert was the former maintainer of Linux Gazette packages: <https://people.debian.org/~joerg/> (2002).)

This remains to me one of the best examples of integrating information delivery and documentation on an operating system I've ever encountered. Notably, it makes both manual and info documents more useful and usable than their traditional terminal-based interfaces.

There are Debian-associated blogs (Debian Planet), though I don't believe that was ever packaged for Debian itself.

Frankly, RSS is probably a better option for blog subscription.

You could read LG without dwww just fine by just pointing the file:/// path.

I remember getting all of those with the Debian Sarge DVD's, good stuff, among the Anarchist Faq, the 'Derivations' math book, and tons offline documentation when I didn't have internet at home.

dwww need not be limited to localhost access, meaning that a single Debian system can serve docs to others (LAN, intranet, public Internet, ...).

Of course, all of the documentation that's exposed via dwww is accessible on that host's filesystem. But dwww also provides a few additional affordances: Web-formatted output, a directory of installed documentation (organised by source / type), and (if you have swish++ installed), full-text search.