solaris/PatchAccessChanges written at 16:34:45; Add Comment
Impending changes to access to Solaris patches
Through the pca news page I found out some impending changes to access to Solaris patches. There are two changes:
I'm honestly not sure how these two interact, since it's hard to enforce having accounts with anonymous ftp.
However, pca currently
retrieves patches (and the
Moral: I should get registered soon and start experimentation, no matter how annoying it's sure to be.
sysadmin/OddHostname written at 16:14:54; Add Comment
An odd choice of hostname
Today's winner of the amusing hostname prize is '
I do have to wonder what sort of naming scheme gave rise to this. (It has neighbors with different 'serverN' PTRs, so it's not just one machine.)
python/WSGIGoodBad written at 01:24:22; Add Comment
WSGI: the good and the bad
WSGI is the Python 'Web Server Gateway Interface', which is a standard interface between web servers and Python web applications. The idea is that you write your app as a WSGI app, then glue it to the web interfaces of your choice: CGI-BIN, SCGI, a standalone testing web server, whatever. The WSGI stuff encourages a stacking model, where modular middleware can be transparently inserted above applications to handle various more or less generic things.
(Ian Bicking gives examples of a bunch of WSGI middleware here.)
A while back I converted DWiki into a WSGI application, and in the process I built up some opinions about the good and the bad of of WSGI.
The good: the ideas. A generic execution environment for web apps is very nice, and the 'stack of simple pieces' approach to apps is a powerful and addictive idea. Plus, WSGI gateways are relatively easy to write, and for apps the interface is pretty simple.
The bad: the complex implementation, which imposes what I call the 'WSGI tax'.
The WSGI tax exists because WSGI had to fit into several existing web server environments, all different, in order to get people to adopt it. To cope with all of them, the full WSGI protocol has a bunch of complex requirements, and general WSGI servers (including all middleware, since it acts as a server for the layer below it) has to support all of them. Not only does this require a pile of cookie-cutter code in each middleware component, but the requirements significantly complicate what you can do when.
I really like the idea of stackable little bits, and I've been very happy with using it heavily in the post-conversion DWiki. But the WSGI tax is too much for me, so DWiki uses a much simpler internal protocol for its stackable layers and appears as monolithic WSGI app to the outside world.
(For scale, a typical DWiki stackable layer is ten to twenty lines of
Python. The smallest is three lines, not counting the
* * *
Atom feeds are available; see the bottom of most pages.