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:
- InfoDoc #83061 says that from mid-July, we'll need to register for a free Sun Online Account in order to get patches.
- InfoDoc #82023 says that Sun will be turning off anonymous ftp access to patches in late August.
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
patchdiag.xref index file) via http, not
anonymous ftp, so it will be affected sooner. (I'm not sure if it'll
require a pca update, or if you'll just be able to plug in a
Sun Online Account ID and password as if it was a SunSolve one.)
Moral: I should get registered soon and start experimentation, no matter how annoying it's sure to be.
An odd choice of hostname
Today's winner of the amusing hostname prize is '
server1-gay-it.it.net', which is what the IP address 126.96.36.199
currently claims to be in SMTP (the first name) and its PTR records (the
second name; there is no matching A record).
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.)
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
def; another is