I've recently wound up thinking that sysadmins probably use email alittle bit differently than other people, so I've decided to write downsome words on how I use email (as distinct from the tools I use forthis ).

A bunch of my email is archives, in a sprawling set of folders. Iarchive things for a variety of reasons; the major ones are more orless sentimentality (email to and from some people), for active futurereference (for example, I keep a copy

I was all set to write an entry about how you could use Go -style interfaces to create what I calledeasy, type-safe conversions from a variety of types to something youwanted. The sketch of the problem and the idea is that suppose youwant to create an API that accepts arguments in multiple forms ( eg ), for example something in uncompiled stringform or in a compiled efficient form. The usual way to implement this iswith a type switch in your functions ('if argument is a string

Every so often sysadmins have a common form of problem: they need toconfigure program A to run program B with various arguments but programA's configuration system has some sort of baroque system for specifyingcommands and evaluating their arguments. What gets quoted or unquotedwhen, how things are handed to what, and so on are often unclear,unhelpful, or both. Everything works fine in simple cases but if youneed to specify arguments for program B that have troublesome elements(like spaces) or do things like pipelines

Unix needs to grow but the problem withits growth is that the first attempts at anything in particular arealmost certainly going to be not the right answer and not particularlyUnixy (if you're unlucky you get crawling horrors created by people whodon't actually care about Unix). In order to grow towards a truly Unixsolution to any particular problem , youneed to be willing to repeatedly make changes. Often changes will notbe an incremental evolution of the previous change but instead someonelooking at it, going

This is today's learning experience and I will preface it by saying thatI am probably doing things wrong and in not the right CSS way. I willpresent this as a story.

Once upon a time, you write a wikitext to HTML converter and with itsome associated CSS. Your wikitext has tables and the tables shouldbe styled in a certain way, so you wrap the entire generated wikitextin a

In yesterday's entry I mentioned that DWiki (the software behind this blog) is pretty much a worst case for a blogengine as far as speed goes. Today I feel like talking about what makes DWiki slow, and by extension the things that can slow down any dynamic file based blog engine . Part of why is so thatyou (if you are considering writing such a thing) can avoid the mistakesthat I made.

(Some of the slowness is because chunks of DWiki 's code are not exactly

Suppose that you have a system that involves cryptography and atsome point your cryptography indicates that there is a problem, onewhere something isn't verifying properly. Many programs fumble whathappens next in a way that significantly degrades their security ; they give people bad error messages, onesthat make it hard for people to understand what's wrong.

Crypto error messages are very important because crypto error messagesare your one chance to convince people not to go on anyways . Peoplereally want to what they were planning to do

There is a common myth or perception that dynamic websites andespecially dynamic blogs are slow. I've tilted at this particularwindmill before , but today I feel like providingsome actual numbers for DWiki (partly because I just finished some performance tuneups ). DWiki can run either as a CGI (under light load) or as a SCGI server(under heavier load). The interesting load test is for the SCGIserver version, complete with its Rube Goldberg hookup . So let me give you somenumbers for that.

Here is something that I've come to firmly believe: if you have softwarethat uses cryptography, your software should either absolutely refuse towork if the cryptography rejects something or it should have a minimalworkaround for the failure; the worst thing you can do is have a nice'turn off all crypto' option. I wrote one version of why in this entryabout a Yum cryptography failure , but I want torepeat it generally because this is a very important point for usablereal-world security.

In general