These days there are a number of languages and environments withrelatively simple to learn frameworks for doing web activity (I amdeliberately phrasing that broadly). Both node and Go have such things, for example, andoften make a big deal of it.

(I know that 'let's do some web stuff' is a popular Go tutorialtopic to show easy it is.)

All of this makes it sound like these should be good alternativesto the CGI problem (especially with theircollections of modules and packages

The recent Bash vulnerability has people suddenly talking about CGI-BINscripts, among other things, and so the following Twitter exchange tookplace:

@dreid :Don't use CGI scripts. For reals.

@thatcks :My lightweight and simple deployment options are CGI scripts or PHPcode. I'll take CGI scripts as the lesser evil.

@eevee :i am pretty interested in solving this problem. what are your constraints

This really deserves more of a reply than I could give on Twitter,so here'

One of the standard knocks against systemd is that it keeps growingand expanding, swallowing more and more jobs and so on. I've comearound to feeling that this is probably a problem, but not for thereasons you might expect. The short version is that the growingbits are not facing real competition and thus are not being provenand improved by it.

Say what you like about it, but the core design and implementationof systemd went through a relatively ruthlessly Darwinian selectionprocess on the way to its current

One of the things I like about Go is that it's generally very easyto cross-compile from one OS to another; for instance, I routinelybuild (64-bit) Solaris binaries from my 64-bit Linux instead ofhaving to maintain a Solaris or OmniOS Go compilation environment(and with it all of the associated things I'd need to get my sourcecode there, like a version of git and so on). However when I dug intothe full story in order to

I have been very down onPython 3 in the past. I remain sort of down on it, especially inthe face of substantial non-current versions on the platforms I useand want to use, but there's another side of this that I shouldadmit to: I kind of want to be using Python 3 .

What this comes down to at its heart is that for all the nastythings I say about it, Python 3 is where the new and cool stuff ishappening in Python. Python 3

I was recently reading an article on why Go can call methods on nil pointers ( via )and wound up feeling that it was incomplete. It's hard to talk about'the' singular reason that Go can do this, because a lot of designdecisions went into the mix, but I think that one underappreciatedreason this happens is because Go doesn't have inheritance .

In a typical language with inheritance, you can both override methodson child classes and pass a pointer to a child class instance to a

I've recently read some criticism of the security value of VLANs. Since we use VLANsheavily I've been thinkinga bit about this issue and today I feel like writing up my opinions.The short version is that I don't think using VLANs is anywhereclose to being an automatic security failure. It's much more nuanced(and secure) than that.

My overall opinion is that the security of your VLANs rests on thesecurity of the switches (and hosts) that the VLANs are carried

I have in the past talked about passive versus active init systems without quite defining what I meantby that, except sort of through context. Since this is a significantdivision between init systems that dictates a lot of other things,I've decided to fix that today.

Put simply, an active init system is one that actively tracks thestatus of services as part of its intrinsic features; a passiveinit system is one that does not. The minimum behavior of an activeinit system is that it knows what services

For vague historical reasons we've had the mcelog package in ourstandard package set. When we went to build our new 14.04 installsetup, this blew up on us; on installation, some of our machineswould report more or less the following:

Setting up mcelog (100-1fakesync1) ...Starting Machine Check Exceptions decoder: CPU is unsupportedinvoke-rc.d: initscript mcelog, action "start" failed.dpkg: error processing package mcelog (-