Back when I wrote about using tc to limit the outgoing bandwidthof a web server , I expressed a wish:

For our purposes it would be nice to do something sophisticated toaggregate all HTTPS requests from a single IP address together in asingle 'flow' for tc-sfq(8) . In theorythis is possible with tc-flow(8) but inpractice I can't figure out a command line that works right (despiteconsulting eg tc-sfb(8) 'sexample).

I recently shared a war story about how we had load problems ona new web server but not an older one because of a missing firewallrule . In a comment, Aristotle Pagaltzis asked how we'd realized that we had amissing firewall rule. This is a good question, because the sequenceof events involves a certain amount of luck and coincidence. Sohere's that story, which may be a useful example of systemadministration in action in practice (ie, it's kind of messy).

When I wrote about how early SunOS did diskless workstations , I got a good question in acomment:

Obviously this is slow, but having an indeterminate number of userssharing a circa 1982 mechanical hard drive sounds like a problematicamount of slow. Was this ever truly worth doing? I know hard driveswere wildly expensive back then, but surely the work slowdown fromhaving multiple users sharing a single hard drive in this fashionwould mean the ROI for those hard drives would seem obvious?

One answer is that

Today, for reasons outside the scope of this entry, we needed to dounscheduled reboots on a number of Ubuntu 26.04 servers that peoplelog in to and use. As is our usual process, we didn't reboot these onthe spot; instead we ran ' shutdown -r +NN "" ' so that people would have a little bit of warningbecause the impending shutdown would be periodically announced ( bysystemd, because this is systemd-based these

I mentioned recently that we'd moved a very popular data set fromour main web server to a new one that only handled that data set . On the new web server, wefound it necessary to set an absurdly high Apache connection limit of4,000 concurrent requests, because Apache could run out otherwise (andcould even run out at 4,000, it was just less often).

Our main web server has a much lower concurrent connection limit butit didn't experience these

GNU Coreutils are whatthey sound like; a GNU version of a bunch of basic, core Unixprograms such as 'mkdir', 'head', 'chmod', 'cp', 'mv', and so on.For a long time, talking about 'GNU Coreutils' was unnecessary and youcould just talk about 'Coreutils'. Then some people decided to rewriteCoreutils in Rust, the uutils coreutils , whichstill wouldn't be very important for most people except that Canonicaldecided to make

I mentioned recently ( when I dug into systemd and your user D-Bussession bus ) that some of my machineswere set up so that they sometimes started another D-Bus session busdaemon for me. After having done some experimentation I can say thatthis isn't necessary (or really, proper) and I've now stopped doingit. You might wonder how I got myself into this situation, and that'sa story of history.

On my primary desktops , I've never used

Recently I was peripherally involved in a Fediverse discussion about(C's) argc and argv (the arguments to your main() , the start of a Cprogram). Famously, argv[] is an array of pointers to your program'sarguments ( including the nominal name of the program ),and it's sort of traditional to terminate it with a NULL pointer(although this isn't required by the Single Unix Standard; its execve() specification is silent on this). If

When I wrote up how V7 gave us environment variables , I mentioned that up to V6, exec(2) had a limit of 510 bytes of command line arguments (including argv[0],the nominal name of your program). You can see the check in the V6kernel exec() code in sys/ken/sys1.c (where it returns E2BIG in this case). You might wonder where thislimit comes from and why.

When you exec