"The Tragedy of systemd", a rebuttal
Posted 2018-11-17 14:46 PST | Tags: software systemd
 
Benno Rice gave an interesting talk at the 2018 BSDCAN, titled "The Tragedy of systemd" -- https://www.youtube.com/watch?v=6AeWu1fZ7bY
 
He presents a very sympathetic narrative about systemd from the BSD perspective, and he does it fairly well, but he also makes some assertions of dubious validity I keep turning over in my head.
 
Early in the talk he proposes there is a "confusion" between system configuration and service bootstrap in traditional UNIXy models. He talks about mounting filesystems and bringing up the network, and how these are "slightly disparate things" which should be treated differently and managed with different tools.
 
From my perspective, one of the strengths of the UNIX approach is that it abstracts a great many "slightly disparate things" as though they were the same thing. Making (almost) everything a file is a good example of this. When I was new to UNIX, it seemed strange to me, but over time I have grown appreciative of how powerful this abstraction can be.
 
When things are sufficiently different that they need to be treated as something other than a file, we have system calls like ioctl() specifically for that, and in my experience that has worked well.
 
Later he made a curious assertion without any accompanying reasoning to support it, that "other things manage services well [..] Windows always had a strong notion of services". He proceeds from there on the assumption that his assertion is true to discuss Windows' contract-oriented (declarative) approach, which he says "has been kind of neat".
 
I've known people to be used to Windows service management, but I've never known anyone who was familiar with both Windows and UNIX who preferred Windows service management. Mostly I've heard them complain that Windows was inflexible and opaque. I've not spent any time configuring Windows services myself, so perhaps some of you with such experience could weigh in on this. Is there anything to be said about Windows' declarative service management approach which warrants admiration?
 
Benno also praises the ideas behind launchd -- "if you need to have services running all the time, and you can't call the system booted until services have started, that's such a pain in the ass" and "We know we'll need this at some point but we won't start it until we actually need it." This is an approach systemd borrowed from launchd, not starting services until something requests them.
 
The problem I have with this approach (which is also applicable to inetd) is that when the system comes up, I want to know that its services will work. The litmus test for this is bringing the service up so that it processes its configuration and finds any errors or missing dependencies. This can be improved upon by monitoring services with things like Nagios, which submits requests and validates the results.
 
If the service doesn't come up until it's needed, then we don't know if it will work until the moment something actually needs it, which seems like a really bad idea. Also, this approach presupposes a lack of monitoring. Production systems absolutely should be monitored. If Nagios hits up a service immediately or soon after system start and starts the service, then why did we bother deferring the service start in the first place?
 
He also talks about how modern systems need to be more reactive to changes around them, which is absolutely true, but IMO the traditional UNIXy toolbox has adapted fairly well in this regard. It's not done yet -- things like changing wireless networks without interrupting TCP connections still needs some work -- but pitching the toolbox entirely is unwarranted.
 
He is dismissive of criticism of systemd as buggy, saying sardonically "it's software" and "we've all had bugs in our code". He says that if we hold init to a higher standard of quality, that implies we can never write another pid 1.
 
That is simplistic to the point of dishonesty. There are certainly ways we can reduce or mitigate bugs in our software. We can make software simpler, so that there are fewer things to go wrong. Less code means fewer bugs. We can also limit critical dependencies so that a failure in one component doesn't cause the system to more broadly fail (as is the case with systemd when dbus fails). We can also hold on to known-good, already debugged software until such a time that new software has absorbed enough debug/release cycles on ancillary systems that we can trust it on mission-critical systems.
 
Systemd as a project does none of these things. It is by no means simple. It contains a great deal of code, and thus a great number of bugs, which its developers have shown themselves reluctant to fix. It is tightly integrated with a variety of far-flung components and is vulnerable to any of them failing. It has been forced into adoption on mission-critical systems before it is ready (as RHEL6/CentOS6 fall out of support and there are no sufficiently good alternatives to RHEL-derived distributions in the enterprise).
 
Benno also says "UNIX as a concept is dead" in that we no longer have a diversity of UNIX systems across which software must be ported, and we don't have to be beholden to POSIX when it is inconvenient. This seemed curious, coming from a BSD developer in a Linux-dominated world. Projects do have reason to be portable. Projects can get away with being Linux-specific because Linux is dominant, but that's no substitute to being portable. How many projects of the past targeted the dominant platform of their time only to be left behind when the dominant platform changed? There is a vast ocean of excellent software which was written for MS-DOS or classic MacOS which were never ported forward to those platforms' successors.
 
He then talks about how "change can be scary" and "change threatens what we find familiar". These are true things, but he makes it sound like anyone who opposes systemd is a narrow-minded neanderthal. He also does not recognize that some change can be genuinely bad, or that there might be other ways to change which are less bad. He assumes that since people are reacting badly to the changes represented by systemd, then those people will always react badly to changes, and challenges people to overcome their "kneejerk reactions" and accept systemd rather than be opposed to all change in general.
 
As someone who dislikes systemd on the basis of its design and implementation, that felt a little disingenuous.
 
He said a lot more which I'm still mulling over, but these points stood out to me as rather uncompelling, and they make me view all of his points with a sharply critical eye.
 
Blog comments are not working at the moment, but please feel free to reply via these alternative channels:
 
   * My LQ blog -- https://www.linuxquestions.org/questions/blog/ttk-652585/
 
   * IRC channel ##slackware-help on freenode
 
   * Facebook -- https://www.facebook.com/ttkciar
 
   * Twitter -- https://twitter.com/ttk_ciar
 
   * Email (please let me know if I may share your message via this blog) -- ttk (at) ciar (dot) org

 
General Purpose Cartridge Saga Update -- Treading Water
Posted 2017-10-28 15:12 PDT | Tags: defense gpc ballistics
 
(Note: This wasn't going to be the next entry I would write, but it ended up being the one that got finished before the other.  Writing is hard!)
 
It's been five years since I last wrote about the General Purpose Cartridge: http://ciar.org/ttk/mbt/guns/gpc.2012-10-23.html
 
To rehash, the GPC is a hypothetical military rifle cartridge suitable for replacing both, NATO's legacy 5.56x45mm assault rifle cartridge and its 7.62x51mm full-power rifle cartridge.
 
In order to accomplish this, the GPC would have to satisfy a variety of semi-contradictory criteria:
 
      * It must be as lightweight as 5.56x45mm (or nearly so), to avoid increasing the soldier's burden,
 
      * Its recoil must be sufficiently gentle that carbines firing it in automatic mode are controllable,
 
      * Its terminal ballistics must at least match that of 5.56x45mm at short range (lethality at 50m),
 
      * Its terminal ballistics must at least match that of 7.62x51mm at long range (lethality at 800m)
 
      * Its external ballistics must at least match that of 7.62x51mm at long range (flat trajectory, low wind drift).
 
 
These criteria made the GPC a thorny enough subject, but recent events have made writing about it even more difficult:
 
      * The US Army has moved the goalposts to an undisclosed location with the introduction of new "enhanced performance" cartridges -- the M855A1 for 5.56x45mm and M80A1 for 7.62x51mm,
 
      * The terminal ballistics of these new cartridges do not fit neatly in existing analytical models,
 
      * Since the Army has decided to go lead-free, should a GPC also be lead-free or should it incorporate lead for its ballistics-enhancing characteristics?
 
      * Since the UK MoD is moving towards nonfragmenting bullets (with inferior terminal effects), should a GPC also be restricted to nonfragmenting bullets?
 
      * The methods used in my previous two articles had flaws: the empty brass weights for some cartridges were underestimated, and the lethality model was too primitive,
 
      * The AMU has purportedly decided on the new "264 USA" as its GPC cartridge, of which very little is yet known.
 
      * The AMU has argued making changes to its small arms doctrine to accomodate the characteristics of the 264 USA.  These arguments are relevant to the GPC concept as a whole, and could be used to justify altering its criteria.
 
So, before I can write about the GPC again, I need to purchase samples of more cartidge types and measure them, and update my methods.  I need to learn more about the ballistics of M855A1 and M80A1, and of 264 USA.  I need to justify my reasons for using or not using lead, and using or not using fragmenting bullets.  I need to decide whether the AMU's arguments are sufficient to justify changing the criteria for the GPC (particularly its weight constraint).
 
I haven't given up on the subject, but these things take time.  In the meantime I will try writing about these various issues separately.

 
Writing is Hard, Programming is Easy
Posted 2017-10-23 15:08 PDT | Tags: blogging
 
My last entry was four months ago.  So much for my determination to write something for this space every day!
 
It's not for lack of things to write about, but every time I sit down to write something, I think it would be nice to have more features for this blog (like comments and search), and end up working on the next version of the blogging software instead.  Writing software is a lot easier than writing blog articles.
 
As an interim solution, I could publish blog entries to Facebook as well as to here, and interested readers could post comments to Facebook.  That would suck for those of you not yet trapped in the Facebook quagmire, but perhaps would be better than nothing.
 
So .. yeah, let's try that.  Another article coming soon after this one.

 
Entropy Pump
Posted 2017-06-25 11:49 PDT | Tags: blogging entropy
 
So .. WTF is an "Entropy Pump", and what does it have to do with "blogging against inevitability?
 
Entropy has to do with irreversible transformations -- once an egg is scrambled, one cannot put it back together.  Once energy is converted into heat, one cannot reclaim 100% of that energy from that heat.
 
Eventually everything runs down.  This is inevitable.  Entropy cannot be reversed.
 
But it can be shuffled around!
 
Entropy pumping is a characteristic of all living things, as they incorporate low-entropy substances into themselves (food, clean water, sunlight, etc) and export entropy away from themselves.  They keep themselves ordered and energetic at the expense of making the rest of the universe less ordered and less energetic -- accelerating the Heat death of the universe to delay their own.
 
Fortunately the universe is much, much bigger than living things, so it doesn't mind so much.  Our planet is feeling a bit of strain -- more on that in future entries.
 
One corollary to this is that all causes are ultimately hopeless.  In the end the universe will die, and everything that came before it will come to naught
 
In the much shorter term, living things die.  The entropy pump grows less efficient, disorder accumulates, order decays, and eventually the pump can't keep itself sufficiently ordered to keep pumping.
 
This, too, is inevitable.
 
But we keep pumping anyway, don't we?
 
That's what this blog is about.  All causes are hopeless, but we strive to succeed regardless.  The words I write might be whispers against the wind, but I write them anyway.  History marches stubbornly on, but that doesn't mean I can't dance my own jig.
 
All entropy pumps are doomed to fail, but I'll keep mine running as best I can.

 
New Blog Seems To Be Working
Posted 2017-06-25 10:56 PDT | Tags: blogging software
 
Welcome to my new blog, "Entropy Pump"!  I finally gave up on Blosxom and wrote my own blogging software from scratch.  It ended up taking less time than all the hours I sank into trying to make Blosxom not suck.
 
That having been said, it is not complete.  The search feature doesn't work yet, there is still no way for visitors to leave comments, there's no way to link to a specific post, and pagination is broken.  If I don't fix pagination before posting twenty posts, only the twenty newest posts will be displayed, with no way of accessing older posts.  So I'd better fix pagination!
 
Also the side-panels to the right of the screen, over there --> are not very interesting.  I'll come up with more interesting content and replace them.
 
I'm fairly pleased at how the html and css turned out.  This page has a much spiffier look-and-feel than my old blogs hosted by LinuxQuestions and Slashdot, and it absolutely puts my main website to shame.  It's not great (I kind of suck at css) but finally feel like I can provide people links to my blog without feeling embarrassed about it.
 
Thinking the top priority will be permalinks for posts .. the title of each post should be a permalink.  Second priority will be pagination.  Then I can think about full-text search (Lucy or dezi?).  Also, maybe improving the markup a bit.  It would be nice if "Lucy" and "dezi" were links to https://metacpan.org/pod/distribution/Lucy/lib/Lucy.pod and https://dezi.org/ respectively, but right now the blog only knows how to expand full URLs and Wikipedia references.
 
As introductions go, this one's pretty boring.  Perhaps another entry is in order, ruminating on the significance of "Entropy Pump".  Will do that soon.
 
UPDATE 2017-06-25 12:25 -- adding permalinks was really, really trivial.

 
Test Post
Posted 2017-06-24 23:26 PDT | Tags: test
 
This is a new Blog, and it needs posts.  This is a test post.
 
Got to hit all of the features!  That means http://ciar.org/ttk testing all the features.
 
Ebedding an image:
 
That's enough.  Time to see how it works.