7 ms·

The djb way (2007)

62 points by vezzy-fnord 11y ago

pepijndevos 11y ago
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.
- wtbob 11y ago
  It seems pretty useful that despite being a decade-old installation and being linked to from HN, it is responding near-instantaneously. Likewise, the suckless tools are useful in that they just work. That's pretty useful too.
- derefr 11y ago
  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 11y ago
That is some hagiographic religious bafflegab.
- gopowerranger 11y ago
  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.
  - joosters 11y ago
    Please don't use his ideas about human-unreadable log files... Look, djb is a damn good programmer and writes some amazing, reliable software. It's just not all that user or admin friendly. I'd go mad in a world where everyone used his 'world class' ideas on software...
    - vezzy-fnord 11y ago
      I presume you're talking about the use of TAI64N timestamps. Making them human-readable is a pipe to tai64nlocal away. djb's software is, in fact, quite user and admin-friendly. However, most people simply aren't used to the modular toolkit approach way of doing things beyond basic text processing. The djb philosophy is really the Unix philosophy, and so it comes off as quite shocking to see software written like that when you're used to monolithic blobs. But there is so much insight to be gleaned that, unfortunately, most people ignore precisely because to them user friendliness means building inflexible kitchen sinks. I especially do not consider the latter to be admin-friendly in the slightest.
      - joosters 11y ago
        It's IMO the wrong way around. Logs should be human-readable without needing a separate program. Computer code can convert a human-friendly timestamp into a more CPU-friendly one with minimal effort. We have these processors that can do it, so why not let them? Why does djb choose to make life difficult for humans?
rumcajz 11y ago
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 11y ago
  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.
  - sfk 11y ago
    In 2015 open source software development is 90% about doing peripheral work, sit in committees of various foundations, force people to use a different infrastructure every two years, and generally, avoiding real work as much as possible.
  - vezzy-fnord 11y ago
    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 11y ago
2bluesc 11y ago
Took me a while to notice that it's not written by djb himself.
- JdeBP 11y ago
  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

The djb way (2007)

62 points by vezzy-fnord 11y ago

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.

wtbob 11y ago
It seems pretty useful that despite being a decade-old installation and being linked to from HN, it is responding near-instantaneously. Likewise, the suckless tools are useful in that they just work. That's pretty useful too.
derefr 11y ago
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 11y ago

That is some hagiographic religious bafflegab.

gopowerranger 11y ago
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.
- joosters 11y ago
  Please don't use his ideas about human-unreadable log files... Look, djb is a damn good programmer and writes some amazing, reliable software. It's just not all that user or admin friendly. I'd go mad in a world where everyone used his 'world class' ideas on software...
  - vezzy-fnord 11y ago
    I presume you're talking about the use of TAI64N timestamps. Making them human-readable is a pipe to tai64nlocal away. djb's software is, in fact, quite user and admin-friendly. However, most people simply aren't used to the modular toolkit approach way of doing things beyond basic text processing. The djb philosophy is really the Unix philosophy, and so it comes off as quite shocking to see software written like that when you're used to monolithic blobs. But there is so much insight to be gleaned that, unfortunately, most people ignore precisely because to them user friendliness means building inflexible kitchen sinks. I especially do not consider the latter to be admin-friendly in the slightest.
    - joosters 11y ago
      It's IMO the wrong way around. Logs should be human-readable without needing a separate program. Computer code can convert a human-friendly timestamp into a more CPU-friendly one with minimal effort. We have these processors that can do it, so why not let them? Why does djb choose to make life difficult for humans?

rumcajz 11y ago

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 11y ago
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.
- sfk 11y ago
  In 2015 open source software development is 90% about doing peripheral work, sit in committees of various foundations, force people to use a different infrastructure every two years, and generally, avoiding real work as much as possible.
- vezzy-fnord 11y ago
  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 11y ago

2bluesc 11y ago

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

JdeBP 11y ago
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