Slashdot

Last month, my work got a new H.323 video conferencing unit, and today we had our first real test: a lecture given at SFU that was streamed to us. For the most part, it went really well; there were no big screw-ups and everything went as planned. During the second half of the conference, though, the audio was intermittently choppy. I'm not certain, but I think that a local user's Internet radio stream may have caused the problems.

If that's the case and it would surprise me, since I'd assumed we had a pretty damned fast connection to the Internet then I'll need to start adding traffic shaping to our firewall. Working on the firewall is something I've been putting off for a while, since it's a bit obscurelovely pf firewall, littered through with quick rules. But there's a good tool for pf unit testing I've been meaning to try out since I heard about it at LISA. Probably won't be as big a help with the traffic shaping stuff, but at least I'll be reasonably sure I'm not screwing anything else up.

And now I'm wondering just how hard it would be to come up with (handwave) something that would combine automatic form generation, web-based testing code and summary code. We have these multiple conferences that need registration pages; while some of the information is the same (name, email address) some is different (one conference has a banquet, another wants to know if you're going to be attending all three days). Putting all this in a database and using something like Formitable to generate the form seems perfect.

Since I'm already using Perl's WWW::Mechanize and Test::More to test the pages, it'd be nice to have it look at the stuff used to generate the form and use that to test the page. (That's not the clearest way I could put that, but if I don't write this down now I'll never write it down.) And if I could add something that'd automatically generate summary pages for conference organizers, it'd be even better; stuff like email and address is always easy, but being aware of special questions would be nice too. (Though maybe not necessaryhow hard is it to generate summary pages?)

Trouble is, this is a lot of deep thinking that I've never really had to do before. I suspect this sort of thing is a good programmer's bread and butter, but I've never been a programmer (good or otherwise). The more I think about this, the more I can't decide whether this is really hard, possible but too much effort to be worth it, or already done by something I haven't come across yet.

The little things I can handle, though. This crash looks like it's happening because of a mixup between rand(3) and random(3). In Linux, both have a maximum of RAND_MAX, but in Solaris the latter has a maximum of 2^31. This wreaks havoc with the let's-shuffle-the-playlist routine in XMMS, and we end up with a crash. Once I figure out how to program in C, it shouldn't be too hard to get it fixed. :-)

I installed RT at work a couple days ago using pkgsrc. This was the first time I'd ever used pkgsrc, and I have to say I'm impressed. Yes, it's just like a portable ports tree -- but it's just like a portable ports tree, and I'm starting to think that's a very, very powerful idea.

RT went well except for the final install, where it complained and died. Fortunately, it turned out to be susceptible to exactly the sort of one-line patch that I have an affinity for. Not as cool as correcting Theo de Raadt's code, mind you :-) but still a good feeling.

Ah...RT, I've missed you.

• Word-by-word diff of GPLv2 and v3
• New version of Unix Backup and Recovery, by W. Curtis Preston. The first was amazing; this one covers Windows and Mac OS X as well. WANT.
• Good reading and good suggestions. I need to alias ls, fg, mutt, sudo, and to shorten my alias for SSHing to my webserver.
• I think I finally figured out what was going on when my desktop machine at work had a suddenly borked mouse/X relationship: double-clicking was inconsistent, single-clicking was inconsistent, but the keyboard still worked. It happened again a few days ago, and I managed to run xev and verify that things really were messed up: the mouse and all its clicks and motions just weren't registering at all. I managed to figure out what was (probably) going on when I came across this link. In the end, what worked for me was switching to a console and running cat /dev/input/mouse1. Don't know why (yet!) but that seemed to reset everything.

Still to come: Why upgrading is the most important thing EVAR.

People have been calling me out on my last post, and that's good; I love a good argument^Wdebate, and doubly so when it comes from people w/more experience than me. So I'm going to start responding to the comments, laying out where I'm wrong and where I still think I'm right.

I said:

OpenSolaris: If I wanted to upgrade everything by hand, I'd stick with Slackware.

Bzzt! As I found on on a recent episode of BSDTalk, NetBSD's pkgsrc is available for over nine hundred thousand operating systems, including Solaris and Slackware Linux. Tha's right, both premises in that statement were wrong.

Not only that, pkgsrc can be tucked out of the way so that it doesn't interfere with the rest of the system...so I could even throw it on Thornhill right now, Slackware and all, and start using it instead of my own half-assed build script for Apache/SSH/PHP/OpenSSL/mod_ssl (which, in my own defence, works pretty darned well).

In fact, tomorrow I'm heading out to The Other University to set up two new X4200 servers, and I'm seriously considering adding pkgsrc to them -- if only to avoid having to compile (and botch) Lapack and Blas. If that goes well, I may start adding it to the main server here so that we can easily get more up-to-date versions of Firefox et al. (Though I could probably get them from Blastwave...this has been a low enough priority for me so far that I haven't really looked into all my options.)

That is not to say it's perfect:

• While it has six thousand packages or so in its tree, only (...) something like two or three thousand compile.
• Upgrading is less than perfect; as you'd expect, the process is basically remove-and-recompile...and since that goes for dependencies as well (at least in the default case), it can potentially be a while before it all gets back to a useable state:

  It is possible, and in the case of updating a package with hundreds of dependencies, arguably even likely that the process will fail at some point. One can fix problems and resume the update by typing make update in the original directory, but the system can have unusuable packages for a prolonged period of time. Thus, many people find 'make update' too dangerous, particularly for something like glib on a system using gnome. To use binary packages if available with "make update", use "UPDATE_TARGET=bin-install". If package tarball is not available in ${PACKAGES} locally or at URLs (defined with BINPKG_SITES), it will build a package from source. To enable manual rollback one can keep binary packages. One method is to always use 'make package', and to have "DEPENDS_TARGET=package" in /etc/mk.conf. Another is to use pkg_tarup to save packages before starting.

  From the Swedish NetBSD wiki. Though it's nice that manual rollback is doable; that's always my big paranoia when it comes to source-based upgrades.

• Upgrading Gnome in particular is a fucking bear.

That last complaint is not as fair as it could be. I mean, I'm not going to be upgrading Gnome on either Thornhill or the two new Sun machines. And at around 80 packages, it would be damned difficult to try and recompile it all without starting with a clean slate. But this sort of nonsense with Gnome is what put me off the ports tree in FreeBSD.

(I was going to put in something about how Debian doesn't need that sort of thing, but I should research that first.)