3 ms·

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

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.

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.