This post is an unpublished review for systemd for Linux SysAdmins
systemd. Yes, in full lowercase. If there is ever a technology to cause controversy in the Linux world, this is it. Since its inception in 2010, systemd’s goals were set quite high — replacing the vital part in every Linux system that takes care of the system boot process. It quickly reached maturity, allowing its to be adopted as the main init system in most major distributions just five years later. But even given we are describing events that happened over a decade ago, systemd adoption still raises the temperature in any Linux-related discussion.
David Both’s comprehensive book tackles the “what”, the “why” and the “how” issues surrounding systemd. Carefully divided in 16 chapters, going from explaining the basics and some of the technical and political history behind the project to the different subsystems and aspects covered by systemd, its almost 450 pages can scare people away — but the text is written in a very clear, tutorial-like fashion, and while it can be read sequentially, cover-to-cover, the book is amenable for readers to pick a single aspect and jump straight to the relevant chapter.
One of the frequent criticisms the systemd project has received is that it aims to basically rewrite all of a Linux system, and just looking at this book’s index shows there is some truth to it. The first chapter is an introduction to the systemd project and a brief overview of its history (including the controversies around it), and the following four chapters deal about understanding and controlling the system boot process.
But that still leaves ten chapters to account for — they cover different aspects or sub-projects of systemd, such as time and date issues (synchronization, time specifications, and controlling repetitive tasks), understanding and leveraging the system journal that strongly departs from the old syslog system, network configuration and firewall management, system health and performance debugging — all of them, aspects that in the traditional Unix philosophy were managed by independent programs… And I can identify several systemd sub-projects not covered by this book!
We long-time Unix and Linux administrators took pride in how highly performant and stable systems were supported by the simplicity of our tools; systemd critics point out this massive project has absorbed dozens of individual tools, yielding corporate control over vast swaths of vital system tooling. Truth is… as a sysadmin myself, systemd is today one of my greatest allies.
I appreciate the author evaluates every component independently, including his personal evaluation of each — even stating he prefers working with the traditional programs in several areas.
If there is a criticism I must make about this book is that, although typographically it is well formed and taken care of, given it includes large amounts of console captures, having a maximum width below 70 characters means several lines are unnaturally cut short (and continued with odd indentations). I understand there is probably no “right” way to solve this, but it does affect the feeling of naturally reading the text.
Apple Towson Town Center
In what is hopefully the conclusion of my hunt for a cheap tower server supporting REBAR [1] I have just bought a HP Z4 G4 with W-2125 CPU for $320.
One interesting thing is that it has an adaptor from SATA power to 8 pin PCIe power. According to Wikipedia the 8 pin connector provides 150W at 12V [2]. According to Wikipedia SATA power cables include 3 12V pins each of which can deliver 1.5A [3] which is 54W. The system as I received it had a single SATA power plug connected so potentially 150W could be drawn from a connector designed for 54W. The first thing I did was to connect a second SATA power connector on the same cable so I could have connectors designed for a total of 108W supplying potentially 150W (and definitely more than 75W).
I found two versions of the specs for this system, this version seems to match what I bought as it references W-21xx CPUs [4] while this version matches what I would rather have with a W-22xx CPU [5]. The URL naming scheme implies that there are potentially at least a few other variants out there. So much for the “buy name brand and you can buy two systems with the same model and have them work the same” benefit you hope to get. Why don’t they just name them “G4.1”, “G4.2”, etc?
It seems that W-21xx and W-22xx CPUs are incompatible, so the W-2295 scoring 30,804 multithread and 2,634 single thread on passmark that I hoped to get isn’t an option [6].
The system is well designed for space efficiency, both it and the Z640 are 17cm wide but the Z4G4 allows my to close the lid with the Intel Battlemage card installed which doesn’t come close to fitting in a Z640. It has 8 DIMM sockets and with the ready availability of 32G DIMMS that allows 256G of RAM which is the maximum the motherboard supports. That compares well to the Z640 that only has 4 DIMM slots and the Z6G4 which only has 6.
The system supports a maximum RAM speed of DDR4-2666 which is better than the DDR4-2400 of the Z640 but less than the DDR4-2933 of the Z6G4.
The NVMe sockets on the motherboard are a convenient feature. Most systems I run need at most two NVMe devices so this saves a PCIe slot which is important when dealing with GPUs that take 2+ slots. Also for systems that don’t really need NVMe I can use some of the small NVMe devices that I have no other use for. 128G NVMe devices aren’t even worth selling and 256G will be of little use in the near future. So when I move to gen4 Z servers I can use up some of them without wasting slots.
Using the lesser socket LGA2066 in the Z4G4 is a minor annoyance, but for a single socket system 18 cores is probably enough.
The BIOS has an option for single-socket NUMA, which is basically locking cores in a single CPU to specific RAM channels. I enabled it but it did nothing presumably because I only have 2 DIMMs. When I get more DIMMs I’ll do some tests of that and compare it with NUMA on my Z840.
There are many different variants of the Z4G4 and the only way to recognise them is by the CPU not by any part number or serial number AFAIK. The first difference is between server grade CPUs (the W-2xxx CPUs) and desktop grade CPUs (the i7 and i9 CPUs). The systems with i7 and i9 CPUs don’t support ECC RAM which makes them less reliable, gives smaller limits for RAM
The below table compares the Z640 which is my current desktop PC with the Z4G4, Z6G4, and Z8G4 systems. For the latter 3 I have included multiple options for the parts that differ in different models in the same name series. The Z4G4 I have is an early one which only supports W-21xx CPUs which means a maximum RAM speed of 2666 and the best possible CPU would only be 15% faster than my Z640. I can only use this for ML stuff as it’s the only system I have with REBAR support (which works well).
| Z640 (1 socket) | Z4G4 | Z6G4 (1 socket) | Z8G4 | |
|---|---|---|---|---|
| DIMM slots | 4 | 8 | 6 | 24 |
| Max DDR4 speed | 2400 | 2666/2933 | 2666/2933 | 2666/2933 |
| Max DIMM size | 32G | 64G | 64G | 64G/128G |
| System Max Ram | 128G | 512G | 192G/384G | 1.5T/3T |
| CPU Socket | LGA2011-3 | LGA2066 | LGA3647 | LGA3647 |
| Best CPU | E5-2699A v4 | W-2195/W-2295 | Platinum 8180/W-3275 | Platinum 8180/8280 |
| Motherboard NVMe | 0 | 2 | 2 | ? |
In my previous blog post I concluded that the next step up for me would be DDR5 systems [10]. But now some of the LGA3647 systems are appealing. The Z8G4 would be a decent upgrade from my current Z840 build server and should be affordable long before any two socket DDR5 system becomes affordable.
The Z4G4 doesn’t have any potential for useful upgrades. But for me it was a good cheap way to house a GPU that had already damaged the motherboard of one good system. If the Z4G4 has a PCIe slot break the way my Z840 did then it wouldn’t bother me a lot. It was annoying to discover how limited this variant of the Z4G4 is after buying it, but at that price I can’t complain.
A Z6G4 could be a nice workstation if I found one at a really low price. The only reason I’d seek one out is if I had a need for a desktop workstation with REBAR support, which seems unlikely.
Related posts:
In 2019 I blogged about getting a 4K monitor because of my vision being inadequate for a 2560*1440 monitor [1]. Now I’m using a 40″ 5120*2160 monitor [2] and still trying to find the correct balance between how much I want to see on the screen and what I am physically capable of seeing on screen.
Currently Kitty is my terminal emulator of choice [3]. What I most like about it is the feature of having multiple terminal windows in a single OS window, so instead of having 9 or 16 different xterm instances running all with possible alignment issues I have a single window for all terminals which can be brought to the foreground. The impending 6.7 release of KDE (my favourite Linux desktop environment) [4] includes the feature of per-screen virtual desktops which might be the feature I need to make multiple monitors usable for me. One of the factors stopping me from using multiple monitors in the past was the issue of not getting the alignment of dozens of xterms right if a monitor goes to sleep mode and is regarded as disconnected, moving a few Kitty windows is much easier than moving dozens of xterms (also a tiling window manager isn’t my style).
I’ve just decided that the Terminus font (my favourite out of the monospaced fonts in Debian) is too small for me at 9.0 point. But then I tried 10.0 which looked really ugly and an experiment showed that 10.5 looked good.
This is the best explanation I’ve seen of how ridiculous the whole font point thing is [5]. It doesn’t and won’t ever correlate to pixels. So what we ideally want to do is set the size on screen to match the actual pixel size of the font. I can’t find any software to interrogate a font file and find out what sizes it supports. The web page for the Terminus font says that it supports 6×12, 8×14, 8×16, 10×18, 10×20, 11×22, 12×24, 14×28 and 16×32 [6]. So the question is how to get a terminal program that uses one of those.
Kitty doesn’t and won’t support specifying font size by pixel. I tried some other terminal programs, I started with the Debian Wiki page TerminalEmulator [7] which wasn’t very helpful, I added some new entries to that page. There doesn’t seem to be another option for a terminal emulator with multiple terminals in one OS window that can arrange them automatically. I didn’t even get to the stage of checking whether other terminal emulators supported font size in pixels.
The lcdf-typetools package contains the program otfinfo which gives some interesting information on fonts but nothing about the font sizes in pixels.
Sites like Coding Font to compare fonts [8] can never work properly as the fonts will always be slightly different sizes as the same point size doesn’t mean the same display size.
On my 5120*2160 monitor with 9 Kitty terminal sessions with 9.0 point font they each have 277*50 characters. With 10 point it’s 237*46 but fuzzy and unpleasant to read. With 10.5 point it’s 208*43 which isn’t as good as I’m used to but is still almost 4.5* as many characters as the original 80*25 standard for terminals.
Some time before 2019 I had a 4*4 array of terminal windows that were 100*25 or 120*25. That left some space at the right and bottom so I could open another 8 or 9 terminals that were partially obscured if I needed to. By 2019 before getting a 4K monitor I had a 3*3 array of terminal windows as my standard desktop and a larger monitor that did 4K resolution allowed me to have 16+ terminals again. Now with Kitty I routinely have 9 terminals in a 3*3 array and I can easily open more if I need them and have them resize appropriately.
This situation works reasonably well, but the element of just trying different sizes in 0.5 point increments until I find something that looks good is unpleasant. I should be able to specify the next largest increment of the bitmaps in the font and just have it look good.
It would be good if more people tested the terminal emulators in Debian and added information to the wiki page about them. The current page is useful but needs more information to support the variety of features that people find important.
We need some tools to provide information on fonts in Debian, such as the sizes of bitmapped fonts.
The whole point size thing is just wrong and would ideally go away. The vast majority of font use nowadays is for things that will probably never end up on a printed page so trying to map it to a physical size in fractions of an inch makes no sense. But that’s just one of many horrible things used for backwards compatibility that aren’t going to go away any time soon. Really everything involving inches should go away.
Related posts:
Log in