Yesterday I made the case for why you mostly shouldn't run an NTPdaemon and should instead synchronize time onyour servers through periodic use of ntpdate or similar programs.However, mostly is not all of the time and I think that there aretimes when running an NTP daemon is the right answer.

So here is a list of when I'd run an NTP daemon:

• Your servers need accurate time, where they're always within a fewmilliseconds or less of true time (for some definition of true

In my entry on switching from ntpd to chrony , Imentioned that we don't have many machines that run full time NTPdaemons. In reaction, Sotiris Tsimbonis asked in his comment:

You mean you don't have many machines that run full time NTP daemons and service others as a time source , right?

How do you keep time synchronized in your systems if not by runningntpd? an ntpdate cronjob?

This brings up a heretical position of mine.

I'm a professed time maven. Not only

I've been running some version of NTP(D) on my machines for a very long time now. In the early 1990s theUniversity of Toronto was lucky enough to have Dennis Fergusson,who was very interested in time keeping and wrote a version ofntpd ; I caught myinterest in NTP from the general UofT Unix sysadmin environment atthe time and kept it ever since.

When I first vaguely noticed chrony ,it was on my Fedora laptop; way back in Fedora 11, Fedora

Back in March I wrote about how ARM servers had better just work , which pointed to various articles onwhat seemed to be a fairly problematic situation around basicquestions like whether there was a standard way to boot Linux onARM based servers. Today skeeto asked what I'd make of the news of Red Hat Enterprise Linux introducing ARM server support .So I opened my mouth on Twitter and gotsome very useful replies from Jon Masters , who isRed Hat's chief ARM architect. The short version of the answer

When I talked about PseudoColor displays and window managers , I described things assuming that there wasonly a single hardware colormap. However, if you read the X11documentation you'll run across tantalizing things like:

Most workstations have only one hardware look-up table for colors , soonly one application colormap can be installed at a given time.

(Emphasis mine.)

'Most' is not all, and indeed this is the case; there were Unixworkstations with PseudoColor displays that had multiple hardwarecolormaps.

Yesterday, I described how X11's PseudoColor is an indirect colormap , where the 'colors' you assigned to pixels wereactually indexes into a colormap that gave the real RGB colourvalues. In the common implementation (an 8-bit 'colour' index intoa 24-bit colormap), you could choose colours out of 16 million ofthem, but you could only have 256 different ones in a colormap. Thislimitation creates an obvious question: on a Unix system with a

If you've been around X11 long enough and peered under the hood abit, you may have run across mentions of 'truecolor'. If you'vealso read through the manual pages for window managers with asufficiently long history, such as fvwm , youmay also have run across mentions of 'colormaps'. Perhaps you'rewondering what the background of these oddities are.

Today, pixels are represented with one byte (8 bits) for each RGBcolor component, and perhaps another byte

I tweeted :

That sure was a bunch of debugging because I forgot that my systemd.service file that runs scripts needed

Type=oneshot
RemainAfterExit=True

(... or it'd apparently run the ExecStop script right after theExecStart script, which doesn't work too well.)

Let's be specific here. This was the systemd .service unit tobring up my WireGuard tunnel on my workmachine, which I set up to run a 'startup' script (via ExecStart= ).Because

So I said a thing on Twitter :

Unpopular Unix sysadmin opinion: long system uptimes are generally asign of multiple problems (including lack of security updates).

(This is a drum that I've beaten before ,more or less.)

In response a number of people raised the possibility of long uptimesthrough kernel live patching ( eg ) andI was rather unenthused about the idea and the technology involved.My overall view is that live patching really needs to be designedinto the system from the ground up in