You should segregate different traffic to different mailing lists

In a comment on my entry about how people can always unsubscribeto things , billings wrote:

We actually run a couple mailing lists at work that are set up so youcan't unsubscribe, because they are the official communications fromthe college to staff, students or faculty (each their own list). Iargued that we should allow people to unsubscribe if they want, butuniversity policy makes us have to maintain the list for stuff likeemergency alerts and official messages from the Dean. [...]


Some rough things about the naming of SAS drives on Linux

This isn't a comprehensive look at the names of SAS drives because SAS(as a technology) has a lot of options. Instead this is a look at howdirectly attached SATA drives behind SAS controllers get named. I assumethat real SAS drives get named the same (but I don't have any to testwith) and I have no idea how things look for SAS (or SATA) drives behinda SAS expander or more complex SAS topologies. Also some of this dependson the SAS controller and


The reasoning problem with describing things with a programming language

Every so often systems need to have things described tothem. Configuration files are one obvious example but there are plentyof others, such as what to do to build software, what to do whenpackages are installed or removed, and what to do when you're startingand stopping services. When you're creating such a system it's oftentempting to make the description take the form of a program written insome programming language, partly because this is often the easy way tocreate domain specific languages and


People can always unsubscribe from your mailing lists

At work, every so often I get added to a mailing list where the peoplerunning the list are firmly convinced that it's so important that someor all of the recipients shouldn't be allowed to unsubscribe. There isno gentle way to put it: these people are operating under a tragic anddangerous misconception. The reality is people can always unsubscribefrom your mailing lists. The only question is where they do it and ifyou find out about it.

Specifically, if you don't allow people


File based engines and the awkward problem of special URLs

I was recently asked a good question on Twitter :

@thatcks Do you publish feed URLs on your blog besides '/blog/?atom'?My reader of choice sadly has issues re: dropping the GET param.

The answer is unfortunately not. So, you might reasonably wonder,why do syndication feeds here use a query parameter? The answer isthat DWiki (the engine behind Wandering Thoughts ) is afile and directory based engine and when you build such an engine,you wind up with a URL namespace


Why comments aren't immediately visible on entries here

Recently, a commentator on this entry left a comment with a goodquestion that was unrelated to the entry. GlacJAY asked:

Why do I need one more click to see the comments?

The most useful answer is that things remain this way as a deliberatedesign decision that I've made because of how I want WanderingThoughts to operate and come across to readers. I could sugarcoat this, but I should be honest: the entries are what I reallywant people to read, not the comments. I see


'Broken by design: systemd' is itself kind of broken

Recently, an article by Rich Felker called Broken by design: systemd has been making the rounds. While I amsympathetic with complaints about systemd, the problem is that thisarticle is both more or less deliberately misleading and factually wrongin various of its sections. Normally I would pass over this (per thelesson of the famous xkcd strip ), but nottoday for various reasons. I'll be quoting from the article to commenton specific issues I have with it.

(To hopefully avoid possible misunderstandings, I


The good and bad of the System V init system

The good of System V init is that it gave us several big improvementsover what came before in V7 and BSD Unix. Firstand largest, it modularized the boot process; instead of a monolithicshell script (or two, if you counted /etc/rc.local ) you had acollection of little ones, one for each separate service. This alone isa massive win and enabled all sorts of things that we take for grantedtoday (for example, casually stopping or starting a service).

The


Init's (historical) roles

Historically (by which I mean since at least V6 Unix), init aka PID 1 hashad three and then four roles:

  1. It inherits orphan processes, ie processes that have had their regularparent exit. Doing this almost certainly simplified a bunch of V7kernel code because it meant that every process has a parent process.

  2. Starting up the user level of Unix on boot. Originally this was doneby running a monolithic shell script, as can still be sort ofseen in OpenBSD. System V init modularized and

Why systemd is winning the init wars and other things aren't

Recently, an article by Rich Felker called Broken by design:systemd has been making the rounds.I have a number of things to say about this article but todayI want to talk about one specific issue it brings up, which issystemd's novelty (or lack thereof) and why it is succeeding.To start with, here is the relevant quote from Felker's article:

None of the things systemd "does right" are at allrevolutionary. They've been done many times before. DJB