skalibs

Mirror/fork of https://skarnet.org/software/skalibs/
git clone https://ccx.te2000.cz/git/skalibs
Log | Files | Refs | README | LICENSE

djblegacy.html (5613B)


      1 <html>
      2   <head>
      3     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      4     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      5     <meta http-equiv="Content-Language" content="en" />
      6     <title>skalibs: the djb legacy</title>
      7     <meta name="Description" content="skalibs: the djb legacy" />
      8     <meta name="Keywords" content="skalibs c unix djb legacy library libstddjb" />
      9     <!-- <link rel="stylesheet" type="text/css" href="//skarnet.org/default.css" /> -->
     10   </head>
     11 <body>
     12 
     13 <p>
     14 <a href="index.html">skalibs</a><br />
     15 <a href="//skarnet.org/software/">Software</a><br />
     16 <a href="//skarnet.org/">skarnet.org</a>
     17 </p>
     18 
     19 <h1> The DJB legacy </h1>
     20 
     21 <h2> Who is this DJB guy, and why is he so special anyway&nbsp;? </h2>
     22 
     23 <p>
     24 <a href="https://cr.yp.to/">Dan J. Bernstein</a> is a cryptologist and
     25 a mathematician; he's also the author of a widely known and used MTA,
     26 <a href="https://cr.yp.to/qmail.html">qmail</a>, as well as a few
     27 lesser known pieces of software.
     28 </p>
     29 
     30 <p>
     31  For some time he was quite active in some Unix software-related
     32 Internet newsgroups and mailing-lists; he quickly became a
     33 controversial figure of the Unix programming community, mostly
     34 by being extremely vocal against well-known authors of
     35 "mainstream" Unix software and by suggesting designs so removed
     36 from traditional software design that a normal human reaction is
     37 to first view him as a complete nut.
     38 </p>
     39 
     40 <p>
     41  I do not care for controversy. I am interested in the code. I was
     42 a sysadmin at the time, and still learning to program in C beyond
     43 what they teach you in school (i.e. not much). I had heard enough
     44 horror stories with sendmail; so I gave a shot at qmail, trying to
     45 understand its design principles and the way it was made. And then
     46 I fell down the rabbit hole.
     47 </p>
     48 
     49 <p>
     50  Look, I don't care what you think of the guy, I don't know him
     51 anyway, and this is totally beside the point. The only thing that
     52 matters is that DJB's software is <strong>right</strong> in so
     53 many ways. This software <strong>works</strong>. DJB's design
     54 principles are <strong>sound</strong> and elegant; they are
     55 sound foundations to build <strong>reliable, secure, and
     56 low resource-consuming</strong> software. And the design,
     57 when you get used to it, feels so unix-ish: it's Unix the way it
     58 should have been from the start.
     59 </p>
     60 
     61 <p>
     62  Studying DJB's software was the best course in C/Unix programming
     63 I ever had. Now I <em>teach</em> C/Unix; and I am really glad I
     64 learned from the best.
     65 </p>
     66 
     67 <h2> Building beyond DJB's works. </h2>
     68 
     69 <p>
     70  There's already
     71 <a href="http://thedjbway.b0llix.net/">a lot you can do</a> with
     72 pristine DJB software and some brains.
     73 </p>
     74 
     75 <p>
     76  However, I mostly see DJB as a pioneer. He showed it was possible
     77 to think Unix differently and build secure, reliable and efficient
     78 software without investing millions of dollars into it; now it is
     79 up to software architects and programmers to use the breakthrough
     80 and build upon it. There's a real demand for quality Unix software
     81 out there; it's time to supply. And
     82 <a href="http://thedjbway.b0llix.net/friends.html">I am not the only
     83 one</a> thinking this way.
     84 </p>
     85 
     86 <p>
     87  So, skalibs.
     88 </p>
     89 
     90 <p>
     91  One of the "DJB philosophy" key points is to <em>question the
     92 interfaces</em>. You have a task to do; you have existing interfaces.
     93 What do you do?
     94 </p>
     95 
     96 <ul>
     97  <li> Most people don't even think about it and use the existing
     98 interfaces, even if it amounts to cramming a square peg into a
     99 round hole. This is why buffer overflows exist. This is why
    100 people use abominations such as
    101 <a href="https://www.opengroup.org/onlinepubs/9699919799/functions/gets.html">gets()</a>,
    102 <em>which is still in the Single Unix Specification as of version 4,
    103 in freaking June 2011</em>. This is why the System V
    104 initialization scheme is still prevalent in Linux distributions,
    105 despite being one of the slowest and most unreliable of all
    106 initialization schemes. This is why people still use the
    107 atrocious "libresolv" DNS client library. </li>
    108  <li> An alternative way of thinking is to ask yourself:
    109 "Is the interface I have adequate for the task at hand?"
    110  <ul>
    111   <li> If yes: perfect, use that interface. </li>
    112   <li> If no: then <em>do not use</em> that interface, duh. Design a
    113 better one and use it: so the complexity will be split and the code
    114 will be easier to maintain. </li>
    115  </ul> </li>
    116 </ul>
    117 
    118 <p>
    119  Interfaces should be questioned <em>right down to the libc</em>. You
    120 cannot build strong software on flakey foundations. And from a system
    121 and network programmer's point of view, one thing is clear: <em>most
    122 standard libc interfaces suck.</em> There is no buffered asynchronous
    123 I/O. There is no timed I/O. There is no heap management helper. Even
    124 <a href="libstddjb/safewrappers.html">simple system calls are not
    125 always guaranteed to succeed!</a>
    126 </p>
    127 
    128 <p>
    129  That is where skalibs comes from. skalibs results from questioning
    130 the libc interfaces, and providing replacements or additions where
    131 the existing interfaces do not make it easy to write reliable, secure
    132 and efficient software. It is <em>inspired by</em> DJB's work. It is
    133 not a shrine or anything of the kind.
    134 </p>
    135 
    136 <h2> Conclusion </h2>
    137 
    138 <p>
    139  So, in short, DJB is not a guru, I'm not a mindless brainwashed fan,
    140 and the "DJB advocates" are not a cult. We just think DJB brought
    141 something to Unix and more generally to the software programming world;
    142 we learned from him, we write software following
    143 sound principles that he was one of the first to really apply, and we give
    144 credit where credit is due.
    145 </p>
    146 
    147 <p>
    148  Use our software. You will never want to go back.
    149 </p>
    150 
    151 </body>
    152 </html>