
The djb way (2007) - vezzy-fnord
http://thedjbway.b0llix.net/index.html
======
rumcajz
One thing to learn from djb is how to write virtually bug-free code.

Much more people would be able to do that if they:

a. Stopped using buggy dependencies b. Focused on the task being solved
instead of on the technology

~~~
seiji
Except, not many people are as smart as djb. But, djb being smart doesn't
automatically make his tools good ideas to use (I'm looking at you, Mr. "I
made my own register allocator because I don't trust compilers").

djb lives in a quaint fantasy toy land where he gets to write whatever he
wants and doesn't have to interface with real world systems at scale. That's
great when you're the author. Your software can be clean if you only write for
yourself and not for 50 million other programmers trying to build software on
top of your tools as well. But, it's painful when you're a user and real world
problems get ignored because the author just never experiences your same
problems (so they never care to fix them).

Much like how a startup isn't 90% code and 10% "company," public software in
2015 shouldn't be 100% writing code all day then dropping .tar.gz files on a
server once every two years while ignoring wider principles of project
governance, collaboration, and feedback/growth processes.

~~~
vezzy-fnord
In practice, you'd be using one of the many successors to djbware today, not
the direct originals. You'd install runit, s6 or daemontools-encore rather
than plain daemontools. They all reuse the same libdjb interfaces and follow
the same code style, otherwise functionally they're supersets.

~~~
cgag
I use void linux ([http://voidlinux.eu](http://voidlinux.eu)) on my laptop and
vps, which uses runit as its init system, and it's beautiful. It's such an
elegant system. Writing the run scripts is so easy, and there's so little you
need to understand to do it.

Rather than learning how upstart or systemd unit files work and learning their
configuration languages, you only need to know how to start a process that
runs in the foreground and logs to stdout.

~~~
icebraining
Here's a template for doing the same in systemd:

    
    
      [Service]
      ExecStart=*path to process*
    

Learning the language is only necessary because some services are more
complex. For example, if you need your process to only start after another,
you must now learn the syntax of runit's sv program.

~~~
JdeBP
Here are some concrete run scripts and service units, side by side:
[http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ru...](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/run-
scripts-and-service-units-side-by-side.html)

~~~
cgag
I was curious if such a thing existed, thanks.

------
pepijndevos
So what are they using for their webserver? [edit]
[http://thedjbway.b0llix.net/services/mathopd.html](http://thedjbway.b0llix.net/services/mathopd.html)

It seems interesting in the same strange way
[http://suckless.org](http://suckless.org) is interesting. A certain pleasure
can be found in running a website as a 300 line C program, but it's not very
useful besides that.

~~~
derefr
It sometimes feels to me that we're missing some essential component of the
software creation toolchain: a configuration-time or link-load-time equivalent
to a compiler's "dead-code elimination" or a linker's "whole-program
optimization" or a runtime's profiling JIT.

In other words, presuming a given program was shipped to you as a source
package, your package management system could contain a pass from a _generic_
program that takes the software "seed"—the generic version that does a lot of
things—reads a configuration file specifying _your_ particular use-case—and
then hardcodes policy-level choices like protocol flags, strips out every code
path that you won't be invoking, removes conditionals altogether where only a
single path is left, inlines functions that have then been made trivial, etc.

It would be sort of like a version of autoconf that works at an AST level; but
also built on the expectation that you'll be able to run it again to generate
a new binary if your business needs change, rather than just serving to enable
you to cook up your program with whatever nasty ingredients are left in your
OS's fridge.

The result of such a source-transform pass _should_ be something like one of
the djb programs: a terse piece of code to achieve your particular goal.
Ideally, you would then take that program and _read_ it before using, because,
well, if your particular goals are reasonable, then the code should be small
enough to fit in your head!

On a tangent, the "unikernel" philosophy, as I understand it, is simply that
if you could throw the entire kernel + OS + your application into such a goal-
oriented streamlining woodchipper, a unikernel application is what would
result.

------
jfb
That is some hagiographic religious bafflegab.

~~~
gopowerranger
And with good reason. I don't know where things are with his software and
methods today but, last I heard, djb's software and methods are world class
ideas that everyone should be using.

~~~
cgh
His software creates new top-level directories off root and this simply hasn't
found wide acceptance among sysadmins. I've never seen eg daemontools used in
the wild for this reason.

~~~
copperlight
Netflix uses daemontools in their BaseAMI[1] for starting up core services
such as Apache and Tomcat. I think this choice was originally made to ensure
consistency in process startup methods across CentOS and Ubuntu. Support for
automatically creating daemontools scripts is baked into nebula-ospackage-
plugin[2].

[1] [http://techblog.netflix.com/2013/03/ami-creation-with-
aminat...](http://techblog.netflix.com/2013/03/ami-creation-with-
aminator.html)

[2] [https://github.com/nebula-plugins/nebula-ospackage-
plugin](https://github.com/nebula-plugins/nebula-ospackage-plugin)

~~~
vezzy-fnord
Yelp uses s6. At least, I'm deducing that from employees being regulars on the
supervision mailing list.

------
2bluesc
Took me a while to notice that it's not written by djb himself.

~~~
JdeBP
It should not have. Bernstein writing about his own designs has a markedly
different appearance.

* [http://cr.yp.to/qmail/qmailsec-20071101.pdf](http://cr.yp.to/qmail/qmailsec-20071101.pdf)

* [https://news.ycombinator.com/item?id=9250118](https://news.ycombinator.com/item?id=9250118)

Even to the writing of Aaron Swartz.

* [https://news.ycombinator.com/item?id=890034](https://news.ycombinator.com/item?id=890034)

* [https://news.ycombinator.com/item?id=9155741](https://news.ycombinator.com/item?id=9155741)

