Yesterday I was bitching about how inflexible Moveable Type's templates are. Today I found Brad Choate's MT PerlScript. This looks like just the ticket. Thanks to Mark, where I discovered this little gem. Perl may make baby Jesus cry, but that's just 'cause baby J wasn't a l33t hax0rr!

Network Associates has sold PGP, which it had put in the closet after buying, to a newly formed company called the PGP Corporation.

This is great, PGP is an privacy product for the grass roots, and in today's environment the grass roots people need privacy more than ever. Millions of people now use the Internet for routine communications, and the Net is a very un-private place - few people realize that their email is about as private as a postcard.

Despite this, the US government (with the EU close behind), rather than following a policy of protecting the privacy of its citizens, has been doing the exact opposite. Your email can now be collected, stored, read, searched, profiled, etc. without a search warrant. You have no right to control how big corporations use and distribute your private data, such as your medical records. I'm talking about the law as it is today, not to mention the even more reprehensible stuff Congress is being paid to make into law for tomorrow.

Of course I've used the free PGP on Unix, but I also used to have the commercial PGP for Windows, because I use W2K as my desktop platform. With security tools, the more convenient they are to use the more you will use them, so I want to have encryption right there in my email program, file explorer, etc. Hopefully the new PGP company will ride these trends (increased Net usage and decreased individual privacy) to help more people protect themselves, and make themselves some money doing so.

Looking through the PGP Corporation's press releases, they've got Bruce Schneier and Phil Zimmermann on their technical advisory board. They got the money to buy the PGP licenses from VC's, which shows that it's still possible to get VC funding for a startup. I'm sure it helped that their business plan involved immediately acquiring proven, existing products. It's interesting to note that they got $14 million in funding - I wonder how much they bought PGP for from Network Associates. In boomtimes $14 million wasn't enough to buy a product that only existed in PowerPoint, much less something at version 7 with cash left over to fund development and corporate operations. NA probably got more than cash, but shares in a startup don't have a lot of buying power these days.

Are there any Unix blogs out there? There has been a boom in Java blogs lately, but there don't seem to be any specifically on Unix. I guess most Unix geeks with blogs have a wider focus. This section of my site is mostly filled with Unix stuff because that's where my head is right now, but I don't see it as a Unix blog.

I've played around with a few different blogging packages, and so far I like MT well enough. It's a mature piece of software compared with most of the alternatives, and I like the fact that it is both server based and produces flat output. My only gripe is that it is, in fact, a blogging package. This means it's designed with the blogging paradigm firmly in mind, so it's hard to twist and bend it to do exactly what I want.

My main gripe is the templating language doesn't have quite enough oomph to it. It offers a set of tags useful for making blog-shaped pages, but not much else. There are no conditionals - I can automatically create a list of links to each category in the sidebar, but it can't recognize the current category and mark it up differently - leaving it unlinked and flagging it with an icon, for example. I can't tell it to leave certain categories out.

I also can't easily add different data types or fields to the typical blog entry. I want to treat books specially, so I can automatically create Amazon links with my affiliate code. Plus bookmarks. I want to have a different set of links for each category page.

It's possible to stretch and bend MT in ways it wasn't obviously intended, but writing Perl plugins looks like the best way to get the functionality I want. It shouldn't be necessary, though, the MT templating architecture ought to be a bit more flexible than it is.

In the end I settled on MT for kief.com because I don't want to bother either writing Yet Another Goddam Blogger, spend a lot of time helping an existing blogger like Roller, or build blogger functionality on top of a framework like JPublish.

I was seriously considering these things a few weeks ago, because I was planning to get into online publishing as a line of consulting work, but it now looks like I'm going to take on a lot of Unix sysadmin work, so I won't have the cycles to spare. So MT will let me run my site with a minimum of hassle, and if I do get some cycles maybe I'll tackle some of those minor annoyances.

This weekend I've started re-reading the UNIX System Administration Handbook, AKA "The Purple Book" or simply The Book. This is the third edition of the book I was recommended as the "Red Book" back when I stared as a Sysadmin, some 6 or 7 years ago (damn, has it really been that long?). When the new edition came out a little while back there was a lot of bitching because it's price has bloated to $68, but it's still a worthy tome.

The main appeal of this book is that it's a practical, real-world guide for sysadmining from a bunch of crusty old-school Unix geeks who know their stuff inside and out. They don't talk about managing Unix boxes in an idealized environment, instead they assume that you, like they, are dealing with a network including a hodgepodge of various flavors of Unix (as well as those pesky Windows boxes).

I started to read it from the beginning, planning to read it through, but quickly got distracted by wondering what it has to say about particular issues I'm dealing with now, so I've been jumping around it. Towards the end there is a chapter about dealing with the organizational politics, including tips on how to retire old systems in spite of the users who refuse to learn new things. When they talk about dealing with power outages, they suggest taking advantage of the opportunity to leave crusty old machines you want to get rid of power off, and wait to see if anyone complains; if they don't, it's safe to get rid of.

This book covers a lot of topics, and no, as some Amazon reviewers complain, it doesn't cover them in depth. But it's not shallow. The authors rightfully assume you can learn more details about configuring DNS or whatever from other sources, and they refer you to plenty of good places for more info. But they do more than just introduce you to what a topic like DNS is, they discuss the practicalities that you won't get from the vendor documentation, like how to make it play well with other parts of the system, what it's hazards are, and what alternatives to consider. What does this book give that others don't? Why. They explain why to do things, which means you'll understand how to figure out the best way to do them.

Looking over the Amazon reviews, I should also point out that this is a systems administration book. Users and even power users may find this book has almost nothing of interest to them. Even someone running a Linux box or two at home probably doesn't care about how to set up a backup system for dozens of boxes, or managing hundreds of user accounts. I suggest looking over the table of contents before you fork over the $68. Also be aware that the book doesn't teach everything you need to know to be a systems administrator - you'll need to learn how to use the shell, write scripts, and use many tools, somewhere else, not to mention having reference material on hand.

I recommend Unix Power Tools for learning how to really, really, use Unix. These two are the foundation of my Unix library.

What this book has in it is the stuff you're not going to get from vendor or tool-specific resources. It's the kind of lore you would learn from working with a group of crusty old systems admins.

Brett Morgan continues the discussion of OSS as a learning tool.

One of the problem's I see with fresh out of uni coders is that the biggest project they have worked on is usually say 2 months coding (in a team of say 3 coders), so they have no real understanding of what working on 10k loc project is like. They have no idea of the real need for code documentation (because it was small enough to fit in their heads), they have no idea of the need for refactoring (we hand it in, and then we never see it again), and a total lack of ability to communicate.

So, here is a thought. Take a class of third year CS students. Bring up a CVS server and slave it to some large project. Force the students to then work at understanding the code base. Then get them to work out small projects to make changes to the tree. Make sure to update the tree nightly from the main CVS server to keep the students on their toes.

I definitely agree that CS programs don't give students as much exposure to real team development as it could. Whether it's an existing OSS project, or simply a large class project, something like this could be very cool.

The project for the Operating Systems course I took was developing an OS that ran on a MIPS simulator. We worked in teams of 2 or 3, and every few weeks we had a new piece of the system to write; process scheduler, virtual memory manager, file system, etc. Very cool. I'm not sure whether you could have an entire class work on the whole thing, a big part of the value of the course was building up each component from scratch.

But what could be very educational would be to force teams to swap code after each module. So after you finished the file system, you have to use a different team's file system code to write your virtual memory management component. Students would learn very quickly to like comments and good code design.

Anthony Eden suggests that entry-level programmers should produce an open source project as a good learning experience.

I certainly think working on existing OSS projects should be a standard part of any programmer's learning process, whether they are students or veteran coders. Working on other peoples' code is the best way to learn and improve your coding skills - you learn new things by looking at their code, and puzzling out bugs is challenging and satisfying. Plus it builds the good habit of looking under the hood of whatever tools and systems you use. If you've got source available, you should be comfortable digging into it when necessary.

As Anthony says, open source programmers are aware that other programmers will be looking at their code, which often makes them more careful. Not only can this help develop good coding habits, better code is better learning material. I've recently started writing articles for the Java Boutique, and I'm using examples from OSS code, especially from Jakarta projects. As well as providing me with good example code, I hope it will encourage my readers to go look at the full code themselves, and maybe make it a habit.

Of course bad code has its value as well. One of my most character building experiences was at my first Real Programming Jobc, tackling code written by someone who had left, and either didn't expect or didn't care that someone else might see his work later. Hundreds of lines of code in a single function, wrapped in a single conditional with dozens of "else if"s, each conditional repeating the same code with minor variations.

I'm not an OSS zealot. I use Windows 2000 on my desktop, Solaris on my server (mainly because I got the box as a leftover from a startup). Whatever tool is appropriate for the job. As a programmer and a Sysadmin, open source tools are usually the most appropriate tool for me, because they give me more power - the power to open the cover to find and fix problems, the power to reshape the tool for my own needs, and the power to reuse code and ideas. It's not ideology, it's pragmatism.

The kief.com site is getting a serious overhaul under the covers, although I'm using the same design with some tweaks. I've had this site for probably 5 years or so, maintaining it "by hand", that is, using Homesite and FTP. The site is usually at least 6 months out of date.

I've moved the site to my server in London and installed Moveable Type, a content management system written in Perl and oriented towards weblogging. The main thing I get out of this is a web-based interface that makes updating the material on the site a snap, so hopefully I'll chuck new tidbits on the site pretty often. We'll see how it goes.

At the moment the site is still under construction - a horrible cliche, but I'm tinkering with the templating and configuration, and throwing up new posts during the process, so the site has rough edges and broken pieces. Of course this would be inexcusable for a serious web site, but this isn't a serious site. If I get it shaped up the way I want there will hopefully be useful info on various topics of interest to me, so more people may look at it on a regular basis. But at the moment even my family rarely looks at it, so if there are dangling links, no biggie.