posts/embrace-the-bloat.en.html

   1 <!-- subject: Embrace the Bloat -->
   2 <!-- date: 2021-05-16 12:44:36 -->
   3 <!-- update: 2021-07-31 01:25:21 -->
   4 <!-- tags: bloat, suckless, xscreensaver, stupid light -->
   5 <!-- categories: Articles, Techblog  -->
   6
   7 <p>‘I’m using slock as my screen locker,’ a wise man once said.  He had a beard
   8   so surely he was wise.
   9
  10 <p>‘Oh?’ his colleague raised a brow intrigued.  ‘Did they fix the PAM bug?’ he
  11   prodded inquisitively. Nothing but a confused stare came in reply.  ‘slock
  12   crashes on systems using PAM,’ he offered an explanation and to demonstrate,
  13   he approached a nearby machine and pressed the Return key.
  14
  15 <p>Screens, blanked by a locker a few minutes prior, came back to life,
  16   unlocked without the need to enter the password.
  17
  18 <!-- FULL -->
  19
  20 <p id=b4 style="margin-top:2em">No, I wasn’t the one in the story, but I might
  21   just as well had been.  At the time when I witnessed this conversation I was
  22   using slock as well preferring it over a ‘bloated’
  23   xscreensaver.<a href="#f4"><sup>1</sup></a> In theory reducing ‘bloat’ is a sound idea.
  24   As Steve McConnel reports in Code Complete, there are 1-25 bugs per thousand
  25   lines of code.  Therefore, using software with fewer lines of code reduces
  26   number of vulnerabilities one is exposed to.
  27
  28 <p>Alas reducing ‘bloat’ is rarely a rational pursuit.  Hardly anyone is
  29   analysing security implications or resource usage, rather people are motivated
  30   by a dogma proclaiming that ‘bloat’ is evil and software without ‘bloat’ is
  31   divine.<a href="#f5"><sup>2</sup></a>
  32
  33 <p>But that dogma is not always correct.  slock has 395 lines of code
  34   while <code>xscreensaver</code> has nearly half a million.  And yet, time and
  35   time
  36   again, <a href="https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/">Jamie
  37   Zawinski has been proven right</a>.  Similarly, one could argue that LibreSSL
  38   has been a premature fork and free software community would have been better
  39   served by all resources focusing on OpenSSL rather than splitting some of the
  40   efforts to a library whose big selling point was removal of features.
  41
  42 <p>A common argument brought up in discussion about ‘bloat’ is that of UNIX
  43   philosophy to write programs which do one thing and do it well.  For example,
  44   does GNU cat need a <code>--show-all</code> switch?  It could be replaced with
  45   a sed script and removing its handling would improve cat, right?  Except
  46   what’s often lost in that reasoning is that now everyone has to write and
  47   maintain a non-trivial sed script rather than having a shared tool used by
  48   millions of people and maintained by a well established project.
  49
  50 <p>Am I saying that we should push as much code into every application?  Choose
  51   tools with the biggest binary size?  Bring in huge dependencies because
  52   we can?  No, of course not.  Programs with well defined scope and devoid of
  53   unnecessary features have their advantages (including security ones), but
  54   comparing number of lines of code is rarely a good metric by itself.  It’s
  55   good to try and understand where those additional lines come from.  Even if
  56   there is no difference in set of features between two programs, one might be
  57   larger because
  58   it’s <a href="https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html">better
  59   optimised</a> (seriously,
  60   they <a href="https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/">don’t
  61   joke around</a>) or
  62   uses <a href="https://www.jwz.org/xscreensaver/toolkits.html">a more
  63   secure</a> design.
  64
  65 <p>Size of the executable or number of lines of code are a poor proxy for other,
  66   actually significant properties of a system.  If you care about security, look
  67   at the design of a piece of software and how historically its project reacted
  68   to vulnerabilities.  If you want maximum speed, first make sure that
  69   executable size is actually a problem (especially since smaller binary may
  70   mean fewer optimisations).  If you are after minimising space, firsts make
  71   sure that you cannot spare those few cents to get another GB of storage.  Make
  72   sure you’re optimising what you actually care about and not an irrelevant
  73   proxy metric.
  74
  75 <p>PS. It has since been pointed out to me that there may be a better term for
  76   what I’m talking about here.  The concept
  77   of <a href="https://andrewskurka.com/stupid-light-not-always-right-or-better/">stupid
  78   light</a> which apparently originated from hiking.  Just like blind pursue to
  79   shed weight when going camping can get you soaking wet, blind pursue to shed
  80   bytes, lines or code or dependencies can get your screen unlocked without
  81   a password.  But remember that the flip side of the analogy also works.
  82   Stuffing your backpack full of unnecessary items may cause you to miss your
  83   goal just like adding tones and tones of code may break your project.
  84
  85 <p id=f4><a href="#b4">1</a> It was pure luck that I wasn’t affected by the
  86   bug.  My account password was long and complicated.  While good for security
  87   it got annoying fast when I had to type it each time I returned with a fresh
  88   mug of tea.  Because of that I was running a modified version of slock which
  89   verified entered password against a hard-coded hash rather than my system
  90   credentials.  As an aside, this had additional benefit
  91   of <a href="/2021/start-your-passwords-with-slash-bang/">preventing my account
  92   password being leaked</a> if I ever tried to unlock a screen after forgetting
  93   to lock it beforehand.
  94
  95 <p id=f5><a href="#b5">2</a> Worse still, some people are motivated by
  96   a ‘GNU is bad’ attitude.  It’s not uncommon for Internet forums to witness
  97   someone trying to claim GNU tools are bad by bringing up number of lines of
  98   code or size of the binaries.