Nov. 17 — Managing third-party packages in 9front

I've been growing tired of manually handling random software, so I decided to find a simple way to automate the process and ended up making a sort of "package manager" for 9front¹. It's really just a set of shell scripts that act as a frontend for git(1) and keep a simple database of package names and URLs.

Running the pkginit script will ask for a location to store the source files for installed packages (/sys/pkg by default) which will then be created if non-existent.

And that's it! No, really. Now you can provide a URL for a git repository to pkg/add like so:

pkg/add gits://shithub.us/bubstance/gridchat

This repo will then be downloaded to the package store, built/installed/cleaned with mk, and added to .pkglist. Multiple URLs can be provided to download multiple packages at once.

Removing packages is handled by pkg/del using package names instead of URLs:

pkg/del gridchat

This will perform mk uninstall followed by removing the source directories and purging entries from .pkglist.

Managed packages can be listed with pkg/ls. Adding the -c flag will show a count of packages instead.

Finally, updating packages is handled by pkg/up, which fetches the latest version of the repository and performs the same mk operations as pkg/add.

Notes:

• Packages without an uninstall target in their mkfile will cause pkg/del to exit without removing sources or purging the .pkglist entry. Tell the authors that they should add one. ☺
• Entries in .pkglist that lack a corresponding source directory in the store will be pulled automatically when running pkg/up. This means that a pre-generated and properly formatted .pkglist² can be placed in the store after initialization to quickly install the entire list of packages with a single incovation of pkg/up.
• Packages are updated in the order in which they were installed. For this reason, adding a package like npe should be done before packages that depend on it; e.g., uxn.

Future:

• Find way to skip building packages that have no updates.
• Find way to silence output from mk for a -q quiet option.

1. /rc/pkginit
2. /lib/example_pkglist

Feb. 9 — Managing my RSS feeds in 9front

After getting by for the most part with only the most basic 9front cpu server setup, I recently decided to start exploring the different capabilities of auth-specific systems like secstore(1) and cron(8). Article on secstore to come, but in the meantime I figured I would write about what I've learned regarding using 9front's cron system to schedule basic tasks.

In my search to transfer even more of my day-to-day computing tasks over to my 9front machine, I realized that there was one key piece of software that I was still missing: an RSS feed reader of some kind. In the search for options, rrss¹ and rssfill² came up repeatedly while searching.

While rrss looked to be very slick and robust with its full browser-based feed, I didn't really need all of the bells and whistles for the time being. I instead went with the rssfill approach, mostly because it seemed like it could be easily reproduced without much fuss and involved using the built-in functionality of the news(1) program. It also is written in C as opposed to Go, which can be nice if one doesn't wish to install an entire extra language on their machine – not a jab at Go, of course; I love Go.

Once I had downloaded and compiled the program, I looked at the provided example script for fetching feeds. It was perfectly suitable, but I wanted to split things up a bit and have a separate list of feeds that would be easier to edit in the future. I cobbled together my own little newsup³ script in a minute or two and went about setting up cron.

The cron daemon (auth/cron) needs to be run on an auth server. My current testbed system is a Thinkpad T420 running as a combination auth+cpu+fs server, so it was as simple as adding the following to the file /cfg/$sysname/cpurc:

auth/cron >>/sys/log/cron >[2=1] &

and rebooting. This was followed by running auth/cron -c to create the appropriate file for my user in /cron/$user/cron and opening trusty ol' sam to add another single line:

1 1,3,5,7,9,11,13,15,17,19,21,23 * * * local cron/newsup

This will run my newsup script every two hours, every day. The local bit runs the specified command on – you guessed it – the local machine as opposed to an alternate known host, which is another great example of the flexibility found throughout Plan 9. After placing newsup into a new $home/bin/rc/cron directory and writing out my feedlist as $home/lib/feeds⁴, I waited a few minutes and then ran news. It worked first try – a nice list of articles and git commits to browse along with the joy of knowing that I can now ditch yet another aspect of my non-9 computing.

1. rrss(1)
2. rssfill
3. /rc/cron/newsup
4. /lib/feeds

Jan. 2 — A brief story about an eclipse

I was looking through some old boxes today and found something interesting.

During the "Great American Eclipse" of 2017 I was working at a horrible job in a state where we only saw around 70% coverage. I wasn't able to take a proper photo for various reasons, and right at the time that we were going to get the best view I was completely swamped with paperwork deep in a room with no windows.

While I was scribbling away, my coworker – a man who on every other day hated my guts more than any other person I have ever met – put his hand on my shoulder from behind, motioned for me to follow him, and made me walk outside. He then handed me a viewer¹ he had made by taping together some scrap cardboard and a piece of welder's glass.

I was in a particularly bad place mentally at the time, so it meant a lot to me that he went out of his way to do something like that, no matter how seemingly insignificant it may have been.

In lieu of that eclipse photo I wasn't able to take, here's a plot² of the view as I would have seen it from my house – made using astro(7) and scat(7).

1. [alex_mask.jpg] (~384KiB)
2. [2017-08-21_plot.png] (~8KiB)