Some notes on my first experience with Go
I've finally wound up writing my first Go program. The program is a Goversion of what seems to have turned into my standard language testprogram , namely a netcat-like program that takes standardinput, sends it off to somewhere over the network, and writes tostandard out what it gets back from the network. Partly because Go madeit easy and partly due to an excess of new thing enthusiasm the programgrew far beyond my initial basic specifications.
(I'm somewhat bemused but a netcat-
Go: using type assertions to safely reach through interface types
To start with, suppose that you have a Go net.Conn value, call it conn , that you want to shutdown() (forwriting) on if possible. Some but not all specific concrete net connection types make this available as a .CloseWrite() method (egit's available for TCP sockets but not for UDP ones), but net.Conn isan interface type and it doesn't include a .CloseWrite() method soyou can't directly call conn.CloseWrite(
The meaning of listen(2)'s backlog parameter
I was all set to write an entry where I was going to mention in passingsomething about the effects of listen(2) 's backlog parameter. ThenI made the mistake of actually testing things to see if I understoodthings correctly. Now I am writing a different entry.
If you read your typical Unix manpage for listen() , it will saysomething like:
The backlog argument defines the maximum length to which the queueof pending connections for sockfd may grow.
Ha ha. As if. In practice
The source of C's dependency hell for linking
C famously has a dependency hell problem for linking (both static anddynamic, although the static linking one is often more tractable). Thisis the problem both of what libraries you need (including what librariesare needed by the libraries that you need) and in what order you needthem; it often results in people cramming ever-increasing numbers oflibraries into their compiler command lines in the hopes that one ofthose libraries satisfies things.
As I alluded to in a comment on this entry , the root of that
The strikes against Solaris 11 for us
A commentator on my entry thinking about FreeBSD for future ZFS-basedfileservers left a comment that contains anynumber of things that I want to react to.
You shouldn't necessarily draw your conclusions in regards to Illumosor Solaris 11 based on your experiences with Solaris 10. S10 is veryold and much behind S11 and Illumos, especially when it comes to ZFS.
I've written about our view on ZFS features before , although focused mostly on later versions ofSolaris 10.
Some brief opinions and notes on uWSGI
From my perspective, uWSGI isa WSGI server with a boatload of additional features and optionsthat I'm not interested in. It will serve your WSGI applications via either FastCGI or its own 'uwsgi' protocol;the former is supported by most everything and the latter is supportedby at least nginx . The problems with uWSGIare twofold; it is fearsomely complex and its documentation is mostly written asreference for people who already understand it.
(I started out planning to write some sort of opinionated quickstartguide to WSGI
Finding out what TLS/SSL cryptography people actually get with your servers
One of my hobbies is slowly improving the SSL (okay, TLS) securitysettings on our various TLS-enabled servers, in pursuit of both betterpractical security with real clients and things like forward secrecy . In an ideal world things would comepreconfigured with the best setups possible, but that doesn't alwayshappen in the real world (note thatthose settings are from 2010, which means that they are now obsolete).Part of doing a good job of this is testing things to make sure
SSL/TLS cipher names (aka 'cipher suites') and what goes into them
Since I just researched this for the Nth time, it is clearly time thatI write it down once and for all. I need to start with a high speedoverview of TLS (for my own memory if nothing else).
(All of this is annoyingly confusing and complex.)
TLS conversations themselves are encrypted by some variety of symmetricstream cipher and have some sort of 'message authentication' aka asignature. The key for the stream cipher is arranged during the initialTLS handshake using one of a variety of
The cost of an API mistake in the socket module's fromfd()
Suppose that you get handed a file descriptor that is asocket and you want to turn it into a Python socket object (clearly you are on Unix). The socket module has a Unix-only fromfd() function with the argument signature:
socket.fromfd( fd , family , type [, proto ])
So how do you determine the family and type of the socketfile descriptor you have, since you have to supply them?
Ha ha, silly you. The helpful socket module answer is 'we
Some notes on Linux's ionice
I was all set to write an entry praising ionice as a perhapsoverlooked but rather handy little command, but then I decided toactually measure things on Ubuntu 12.04 to make sure that I wasn'tfooling myself. Now you (and I) get a different set of notes.
In theory, ionice allows youto prioritize a command's IO the way that nice(1) theoreticallyprioritizes its CPU usage. This would be a handy way to allow, say, abig but relatively