Suppose that you have a Linux NFSv3 client that mounts a largenumber of filesystems from a much smaller number of fileservers , which naturally means it mounts a bunchof filesystems from each fileserver. Modern NFS is TCP based, andTCP requires one or more connections in order to make things go.In this situation, you might wonder how many connections the kernelmakes; for example, is it one connection per filesystem, or oneconnection per N filesystems, or so on.

As I found out some years ago when

Process signals are a famously tricky part of Unix in practice(although they can sometimes seem simple in theory). Recently Ifound myself wondering how old various Unix signals are. The answerturns out to be older than I expected for most signals, althoughit's difficult for me to tell exactly how far back they really gobecause of our limited sources for very early versions of ResearchUnix.

We have relatively good information as far back as V4 (FourthEdition), the first version of Unix that was

Back in the old days of mechanical hard drives (HDDs, aka 'spinningrust'), it was possible to feel that you had a reasonable generalunderstanding of their performance because they were physical objectswith relatively straightforward general operating principles. Forexample, they read your data by moving 'the' drive head to the trackand then listening to the track as it spun past underneath the headto read either the individual sectors you wanted or (toward theend) the entire track (and then extracting what you wanted

There's a relatively widespread view that the Maildir mail storageformat is the solution toany issue that one is having with traditional mail message storage.In general I feel that Maildir only solves some problems and makesothers worse (although that entry waswritten in the days of HDDs with very limited IOPS). In our specific environment, we've foundthat Maildir over NFS to our fileservers is actually pretty terribleonce you have a large Maildir folder, one with thousands of messages.

Our IMAP server is Dovecot,

We have been operating our Unixenvironment for a very long time now; at this point, the core ofthe environment goes back more than 30 years. One of the thingsthat happens when you operate an environment for 30 years or moreis that your setup winds up with things that exist in part becauseof historical compatibility, and that aren't necessarily how youwould design things today. One of those things is how mail inboxeswork in our environment.

If you go back 30 years ago,

Bring Your Own Device (BYOD) is perpetually popular withinuniversities for multiple reasons , includingthe straightforward reason that it saves the university a lot ofmoney to assume that various groups can be required to have (anduse) their own devices for some things .However, there is a fundamental difference between BYOD at auniversity and BYOD in a corporate environment that makes universityBYOD more risky in a security sense.

Organizations have a strong interest in making sure that the devicespeople use to do their work (and access to

In an ordinary conventional company (or more broadly many organizations),everyone present not merely matters to the company but also is paid by the company and activelywork for it. They're an employee or a contractor of the company,they get paid for it, and they think of their relationship with thecompany this way. Even in sectors that are plagued by 'unpaidinternships', I think that such people still think of themselvesas working for the company, just for free.

This is not how universities

Both the Prometheus and the GrafanaLoki ecosystems are mostly configuredwith a large amount of YAML. Since we use both, this has resultedin me writing a fair amount of YAML. I've never tried tosystematically learn YAML; like a lot of other things to do withconfiguration files, it's something that I tended to pick up as Ineeded to know specific things. I sort of learned general ideas,copied examples, diagnosed and fixed complaints, and so on.

A while back I decided to

Grafana Loki is a nice and easyto set up way to send your (Linux) systemd logs (and other logs toowith more work) to a central log server where you can then convenientlysearch them and do some other things. In a simple setup, you'regoing to set up a single 'does everything' Loki server, install Promtail on your client machines to ship their logs to Loki, and then probablyinstall Grafana (perhapsbehind a web server frontend) and connect it to Loki so you