The GNU/Linux project has begot the most versatile operating system ever. It’s free, open source and designed to be modified and built upon by its users. The heart of the Linux philosophy is the concept of choice. Linux is about providing its users with the freedom to choose what they want to do and how they want to do it. Because both Linux and the software developed for it is so versatile, there exist hundreds of Linux distributions, each one being nothing more than a different collection of software and configurations running on top of the Linux kernel.

Because of the number of Linux distributions and the degree to which their styles/configurations can vary, a given user usually has the ability to choose a distribution closely suited to their specific needs. To aid the ever-prevalent distro-seeker, many Linux users have sought to provide written reviews of various Linux distros. Unfortunately, many reviews fall short. With the increasing population of Linux users, and the increasing number of Linux distributions, there has been a notable increase in unhelpful reviews.

Which leads to the point of this article, namely, how to review a Linux distro. The idea of reviewing a Linux distro is to inform the reader as to how the specific Linux distro in question is different from the other Linux distros. To do this, a reviewer must provide an analysis of the software and configurations that set the disto in question apart from other distros, putting solid emphasis on the big differences, less emphasis on the minor differences, and no attention to the things that are inherent in all Linux distributions. (If you are writing to inform the writer about Linux, you should do that instead, rather than pretend you are reviewing any specific distro.) This basic principle holds for almost any review of any product. For example, movie reviews tell you why one movie, a four-star action flick, is different than another movie, a two-star romantic comedy. The movie reviewer doesn’t spend time explaining the concepts of cut-scenes and character development, it merely explains the aspects of a movie that make it unique.

This article is aimed at the potential Linux distro review writer. It is split into two main sections: things one should review, and things one should not review. Most of the points have sample topics for that point, some of the points and sample topics are more advanced/technical, some are less so. No good review must cover every point and sample topic in this article, this is just a broad list of good ideas. Suit your information for the knowledge level of your target audience.

Here’s a list of things that make for a good review. This is not an exhaustive list, but it covers a lot of ground.

• Philosophy
  Every Linux distro has a philosophy, namely, a statement of purpose and a set of guidelines for development that support that purpose. “Linux for human beings,” “KISS,” “Free, robust, stable,” “Design for control,” are some philosophies that describe various distros. Anyone using a distro with one of those philosophies would instantly recognize it.
  
  This topic is not optional, you must state the distro’s philosophy and exemplify it throughout your review. Consequentially, it is probably the best place to start your distro review, as what you write thereafter should exemplify the philosophy. Remember, your goal is to show how the distro is unique, and it is the philosophy that dictates why the distro unique. All criticisms or negative points against the distro should be held in light of the distro’s philosophy. Is the distro complicated? That might be worth mentioning, but if the distro strives to put user control first and simplicity is of no concern then complexity is not a short-coming of the distro but rather a side-effect of its philosophy. Rather than criticizing a distro for being too complex, instead note that it is designed for experts. Many reviews fail to evaluate a distro for what it is and criticize a distro for lacking things it does not strive to have.
  
  As boring as it may seem, a quick history of the foundations of the distro might prove very informative. Understanding why a distro was created in the first place can say a lot about what its like today and where it might be tomorrow.
  
  Sample topics:
  • Who is the distro’s intended audience? The newbie, the guru, the average home user, the developer, the server administrator?
  • Does the distro tend to value stability or bleeding edge software? (See later points.)
  • Is the distro designed for users who like to control everything?
  • What is the history of the development of the distro? Why was it created?
  • How robust is a base from-disk install of the distro? (See later points.)
• The parent distro
  If the distro in question is itself based on another distro (many are) you should mention the parent distro and how this spin-off/child distro differs from its parent. Some parent-child relationships are distant, some are close. Some spin-off distros maintain their own package repositories and make their own configuration decisions, some are nothing more than the parent distro with a different default window manager and a few extra pre-installed packages. Telling the reader what the parent distro is and how closely the child is related to it is extremely informative for those either familiar with the parent or who will seek to become familiar with the parent.
• The package manager
  The package manager is the heart of a Linux distro. It is how the user most intimately adds to and subtracts from his system. The package manager is arguably the most important and unique component of a distro. Even though most package managers offer the same rudimentary functions, you should review the package manager. And the word “review” does not imply that you should confirm that there are indeed commands for installing and removing packages. You need to provide enough information that it’s clear how the package manager feels to the user. Explain what sets the package manager apart from other package managers. Different distributions make it easier/harder to eliminate orphaned packages or check dependency information, and many have different ideas of what security precautions to take.
  
  Sample topics:
  • Does the package manager have a GUI?
  • How easy is it to upgrade all the packages in the system?
  • Does it provide clear output informing the user what its doing?
  • What level of security is offered? Package authenticity verification? SSL downloads?
  • Does it ever require that the user perform manual tasks to complete a package installation/integration into the system? (Ie, removing certain configuration files or backups.)
  • How is the package database stored? How easily human-readable is it? How easily backup-able is it?
  • How many tools are a part of the package manager? How many are necessary for day-to-day use?
  • How easy is it to perform a system upgrade?
• Support/Documentation
  The level of support and/or documentation available for a distro will likely be one of the most significant influences in a user’s experience with a distro.
  
  The interactive support offered by a forum (and the archived support offered by its search function) can be priceless as a user gets started with a distro and has questions as they encounter Linux phenomena they are not familiar with. A wiki can help the user through the install and/or basic system setup, setup common software, configure it the way they want, and fix common bugs. The absence of a wiki can mean many hours of Googling for decentralized information and exasperation, leading to unfixed problems and a poorer user experience. A documentation tree (somewhat rare outside of behemoth distros) can help a user dig deeply into the distro and modify/fix it if they are so inclined.
  
  Sample topics:
  • Does the distro have an official forum? How large is it?
  • Does the distro have a wiki? How expansive is it? Does it cover the configuration of sudo? What are some of the more obscure articles it has?
  • Does the distro have developer-written/contributed documentation?
• The Packages
  While the package manager controls the addition/removal of packages to/from the system, it would be foolish to overlook reviewing the packages themselves. The packages will be composed of compressed archives, arraigned with file hierarchy and package metadata that handles dependency checking, integrity verification, and the like.
  
  It is arguable that the layout of the filesystem be included in this topic. Many distros have their own ideas about how the filesystem should be laid out. If the distro has any peculiarities or quirks to how it uses the filesystem tree, its usually related to the compilation destination of packages.
  
  Sample topics:
  • What type of packaging standard does the system use? How easy is it for a user to create their own packages? (Some users like to assemble their own software and use the package manager to mange their installation. See point on compiling from source below.)
  • Is package downgrading supported?
  • How quickly are packages updated when their official upstream versions are updated? (Don’t be to picky here: Are we talking about weeks or months?)
  • Continuing from the Philosophy point and the above sample topic, does the distro lean towards being bleeding edge or being stable? (This has been mentioned twice. Hint.)
  • Do the developers do extensive modification of the original packages (security patches, extra functionality), or are they provided vanilla as-is? (For example, Debian developers tend to modify packages as they see fit, Arch Linux developers only apply very common patches occasionally.)
  • How are the packages compiled by default? (For example, with or without debug information?)
  • How is Gnome/KDE split up? How many packages compose a full Gnome/KDE suit? (For example: Is Kolour Paint an individual package, or only available as part of the larger KDE Graphics package?)
  • Are there any filesystem layout quirks, additions, or reservations? (For example, is /usr/local ever used by packages or is it reserved for the user? Is Firefox installed into /var?)
• Support for compiling from source
  The package manager’s job is (usually) only to manage pre-compiled packages. But some users like to manually compile some packages from source, such as to apply custom patches to a program or to get speed by optimizing the program for their specific machine. Many users don’t compile much (if any) from source, but the Linux philosophy is deeply rooted in the distribution and manual compilation of source code, and there are many who like/need to do so. How an operating system lets the user compile/managed compiled programs is important to how the operating system works. Those who rely on it will find their experience very dependent on how manual compilation is handled.
  
  If there exist any distro-specific methods for handling the compilation of both supported (packages in the repositories) and/or un-supported (packages not in the repositories) software, it should definitely be included in a review. If the distro has any form of a ports-like system, a review without mention of it is by default incomplete.
  
  And do not ever, ever waste space explaining that you can do “./configure && make && make install”, that you can use “checkinstall”, or that you can use the “install” program itself — every distro has those, they aren’t worth mentioning in the slightest.
  
  Sample topics:
  • Do there exist any specific tools for the system that aid the user in compiling programs from source?
  • How are users supposed to recompile the kernel? Is initramfs or initrd used?
  • If a user does manually compile a program/package, how easily can it be managed by the package manager? (This has been mentioned twice. Hint.)
  • How is the presence of different kernel versions handled?
  • Is there risk of having the manually-compiled program conflict with the packages managed by the package manager, or is there a way to keep manually installed non-package programs separate?
• Release system
  Distros have different styles of updating the end-users installed distro to be the most current version. Some distros have a new, fully-updated version released every 6 months. Some just release all package upgrades on-the-fly and have no concept of different versions. The way the distro handles version releases is significant to the end-user, as usually full version upgrades mean that the developers reserve the right to move stuff around and/or reconfigure things in a noticeable way if they want to, and push those changes through in the next major release. It also means that developers reserve the right to stop providing package upgrades for a given version, resulting in obligatory periodic upgrades.
  
  Sample topics:
  • What factors decide the version releases (if there are any)?
  • How big are the changes between releases?
  • How often are the releases?
  • How long is there support for old releases?
  • Does evidence seem to suggest that performing a version upgrade is smooth, or is the user better off performing a clean install of the new version?
• Startup style
  Summarizing how a distro manages startup scripts/daemons is easy: All you have to do is say whether the distro uses System V or BSD-style init scripts. Users unfamiliar with these concepts can look them up.
  
  How the operating system uses run-levels is a more complex subject, yet a more interesting on. Fewer users will care about this level of detail but more advanced users might be able to intuit more about the nature of a distro from it.
• Robustness of a default install
  Distros vary in what software they provide for a from-disk installation. Some have more, some have less. Some have roughly equal quantities but the theme of the offered software is completely different.
  
  After you install the distro, how much work must be done to get the system up and running with a graphical desktop and a decent collection of tools? What kind of packages are installed, and what aren’t?
  
  Sample topics:
  • Is a default display manager installed or offered? (Which one?)
  • Does the distro rely heavily on sources from the servers, or can you obtain multiple CD/DVDs for a more robust from-disk install?
  • Does the default install include tools for compiling? (GCC, make, etc.)
  • Does the default install offer Apache for install?
  • What are some of the most specific/obscure programs install/offered by the installer? (For example, if a distro provides Compiz and OpenOffice.org straight from disk, that implies the sort of other packages that are installed.)

The above topics cover a lot of ground. Obviously not every detail need be included in a good review, but many of these points are very critical to how the distro works and failure to address a significant number of them will result in an incomplete review of the distro. If there seem to be too many points to address, remember that you’re writing a technical review, not a grand work of fiction. Wordiness can usually be eliminated. If you know what you’re talking about and put some thought into what you write, you can cram a lot of information into three sentences.

One key to remember is that that not all of the information may seem important to you, the author of the review, but it is what separates one distribution from another. Obviously the information has to be appropriate for the audience you are writing for; that is a decision faced by every technical writer.

If you feel unable to address many of these topics in your review then you probably have no business reviewing the distro and are not as familiar with it as you should be. Many people want to pop in a CD, install the distro, play with it for 40 minutes, and then write a review about it. Unless you did your research beforehand and you made very good use of those 40 minutes, you’re not qualified to offer a review. Spend your time learning more about the distro rather than writing about what you do know.

Now a list of things you should not review.

• Plug-n-play drivers
  Do not ever review a distro by saying “I plugged my external wireless card X and it did(n’t) work”. This is the lamest review you can provide, and is my pet peeve to boot. First of all, this will come as a shock to some, almost all distros use the same drivers. Support for hardware is pretty much universal, the same drivers that manage your hardware in one distro probably manage it in most other distros, and this only becomes more true over time. Comparing hardware support between distros is basically pointless. It’s even more pointless when your analysis consists of just one generic external wireless card. If it didn’t work, odds are you didn’t set something up correctly.
  
  Second, the comparison you can make between distros is in how they manage drivers. Some distros have special programs to help the user manage and install drivers. Some distros have lots of automatic scripts set up to help ensure the user never has to manually touch their xorg.conf file, some distros demand the user get involved with the xorg.conf file.
  
  Driver management is a valid comparison point, but generic “I tried wireless device X and PCI device Y” tests are basically worthless. “Here’s how easy/hard it is to install Nvidea’s video driver (module version or userland version, take your pick), here’s a short summary of what is expected of you to do so, and here’s what was done automatically by tools”, by contrast, is an informative review.
  
  Note that it is obviously acceptable to review the quantity of drivers provided by a distro if they seem to have a noticeable shortage/abundance of them, but most distros will have about the same drivers. Don’t mention driver quantity unless its very noticeable.
• Five minute quirks
  At various times, some distros have what you might call “five minute quirks”, aka, one or two little problems that often need to be ironed out of a fresh install of the system. Sometimes an environment variable needs to be set, sometimes a file needs to be configured, etc. These are bugs not unique to anyone’s specific install of the distro, but rather a very large (if not the entire) user base. One of the developers mis-configured something before release, or some default setting doesn’t work with the majority of hardware, or something like that.
  
  Do not write about these little five minute hiccups in your review. They do not count, they only last five minutes and will likely be fixed in one of the upcoming releases anyway. (See the next point.) Usually the distro’s forum and/or wiki has an easily accessible guide to tell you how to fix the quirks and after a day of usage, the user will not remember it. At absolute most you should say that “minor quirks exist” and say where/how the site addresses these issues. This could be part of your review of the distro’s documentation. Any quirks you fix within five minutes of attempting to do so should not be mentioned. Their fix in the next release will out-date your review.
  
  What’s more, do not write about the stability of a distro based on its five-minute hiccups. Nothing says “I didn’t do any actual research about this distro” like a stability evaluation based on the initial five-minute quirks the distro had as of July 7th.
• Unrelated/temporary bugs
  Do not write about temporary bugs. If the bug is the type that will be fixed within four months, don’t use it as basis for your evaluation of the distro’s stability. This point bears repeating: Whatever you do, do not base your assessment of a distro’s stability on little quirks that will be gone in a couple months. If your readers wanted to read an inane bug listing, they’d browse bugzilla.org.
  
  On that note, do not assess the distro, in any way, based on bugs that are not specific to the distro itself. If the developers of a software package X make a mistake, don’t blame the developers of the Linux distro in question, it’s outside of their control, not their fault, and not their responsibility. It’s irrelevant to your review, so ignore it. If distro X has a bug but distro Y does not, it is possibly that distro Y did not push the new version of the software and thus does not have the buggy version — you can use this to exemplify how “bleeding edge” the distro is. Or its possible that distro Y manually patched the software — you can use this to exemplify how the developers do(n’t) manually patch packages.
  
  You can obviously cite the presence of bugs in your analysis of the stability operating system, but don’t focus on petty bugs. Instead, focus on the release/testing cycle of packages, the speed of security fixes, and frequency of distro-specific bugs. If this means that you actually have to spend some time using a distro and learning about it before you evaluate its stability, cry me a river. If you aren’t willing to do that, don’t comment on it’s stability because you don’t know anything useful about it.
• Artwork
  No one cares what the default desktop color theme of the distro is. Or the default desktop wallpaper. Or whatever. This is my other distro-review pet peeve. As shocking as this may sound, every desktop environment and window manager in the entire universe, throughout every civilization, all of time, and every dimension, can have its color theme changed. If a user doesn’t like the default wallpaper, they will change it. If they don’t like the default Gnome color theme, they will change it. Defaults are irrelevant.
  
  Don’t mention the quantity of community artwork, in the sense of backgrounds and color themes. This is directly proportional to the number of users the distro has and is thus redundant information. And, realistically, nobody cares about it, because most of them will choose whatever distro-neutral artwork they prefer anyway. Users routinely become attached to a certain color theme and will take it with them from distro to distro.
• Installation Process
  This is not a terribly important point, but I’m not a fan of reviewing the installation process of a distro. Most installers, even text-based ones, guide the user through the installation very clearly. Sure a text interface may look a bit daunting to some, but if one just reads the instructions, one can usually just click-through (or, tab-enter-through) the installation with relative ease.
  
  This item might warrant a quick mention, perhaps tying into the distro’s philosophy (ie, in analyzing whether the distro is oriented towards casual or power users), but unless the installation process is exceptionally complicated or buggy don’t devote much space to it. It’s a one-time experience by the user, and a determined user won’t change their opinion on whether to install it based on the installation graphics.

Remember, your goal, as a reviewer, is simple: Review things from the perspective of the average user you are writing for. Don’t go into pain-staking detail, those details are best left for their own special article, and don’t waste time on things that were (likely) very unique to your experience, because no one else cares.

Even though this article was somewhat long, your distro review doesn’t have to be. If you have an actual depth of information to convey, you can say a lot in three well-crafted sentences.

I’ve designed a theme for the Openbox window manager based on the principle of simplicity and clarity.

I designed the theme because, shortly after my transition to Openbox, I was unable to find a dark theme that was (very) simple, had corners, and didn’t change the colors between active and inactive windows drastically. So I set out to design my own. I originally started by modifying the standard “Syscrash” theme included by default in Openbox, but over time it became unrecognizable and I’ve seen fit to publish it. My theme still uses the four icons from Syscrash, however; I’m no graphics artist.

I call my theme simple because it uses only three colors and has corners. I call it elegant because it blends the colors in simple, consistent, and distinct ways. Its easy on the eyes, but its smooth and the colors distinctly mark their functions. Simple, yet elegant.

There are two variations of the theme, differentiated primarily by their primary color. Both have a grey secondary color with blue accenting. Both have their primary hosting on box-look.org.

• The Black version can be found here.
• The Dark Grey version can be found here.

Port knocking is one of those server security topics that seems to come up every now and then, and when it does it always sparks a bit of debate over matters of practicality.

The idea behind port knocking is simple: The administrator of a server sets up a server with an Internet-accessible service. The admin then closes all the ports on the server, including the ports that the service uses, and starts a daemon that monitors all incoming packets to the server. The daemon then opens the port corresponding to the service when and only when the daemon receives a series of packets on a specific set of ports in the correct order. The packets can be any type — TCP SYNs, TCP ACKs, UDPs, whatever — but they must be sent to the server on the correct ports and in the correct order to cause the daemon to open a service’s port. Thus a port remains closed until someone “knocks” on the correct ports to cause the daemon to temporarily open it.

(Example: If the required sequence is TCP ACK packets on ports 333, 4444, and 55555, then the sequence of ACKs “27, 333, 4444, 55555, 42″ would open the port, whereas the sequence “333, 27, 4444, 55555, 42″ would not. I would tend to use TCP ACK packages, because they look the most boring to someone sniffing a network — more below.)

Thus port knocking adds the security equivalent of another “password” to a service, because a client has to successfully knock on a server’s ports in the correct order in order to open a port for business. Given 2^16 possible ports, about 4 possible protocols, and (usually) about 4 necessary correct port guesses, standard port knocking comes out to the equivalent of a ((2^16 * 4) ^ 4) = 2^72 bit key. This isn’t too shabby a number, in terms of key size, especially if port knocking is just an extra layer of security for a service.

Thus begins the debate on the security practicality of using port knocking.

The main advantage of port knocking is that it conceals the very existence of a service until the port knock sequence is complete. An attacker cannot attack a service he cannot find, and until he finds out how to properly knock, every port on the host will appear closed to him. Thus port knocking is very helpful in situations where a server admin wishes to conceal the very existence of a service. Service concealment was the primary motivation behind the development of port knocking.

Another advantage of port knocking is that it allows a port, when it is opened, to only be open for connection from a specific IP address. The port knocking daemon monitors all incoming packets and when it detects the correct “knock” it can not only open up a port but can open a port that accepts packets from the knocking IP only. Thus a WAN-side service can be told to accept connections only from certain IPs, but those IPs can be decided in real time.

Unfortunately, however, port knocking is a very fragile security policy. Since the knocking packets must always be sent in the clear it has the equivalent security of a password sent in cleartext. Anyone sniffing your network on either the client or server (or anyone who can trick the client into sending the knock sequence to a spoofed server, ie via DNS poisening) end can tell what “knock” is used and replay the packets, effectively negating the security of port knocking. The good news is that unless an attacker is actively looking for a port knock sequence, the knock will look like normal boring network traffic. But if a sniffer is on the lookout for a knock sequence — especially if they know which server it is destined to — it’s impossible to slip the knock past him.

Also, because port knocking requires the equivalent of a symmetric key problem, port knocking does not scale well to services that must handle many individual connections. The pork knocking “key” must be distributed securely to everyone who needs access to the server’s service. Any cryptographer and/or security auditor will tell you that the symmetric key distribution infrastructure for this sort of thing is both annoying and brittle — the larger the infrastructure to be maintained, the larger the hassle and the larger the potential for single point failure.

Obviously, scalability does not matter to the individual wishing to SSH into his home computer, but it is of major concern to anyone operating a server with more than four or five users, especially if users must be added, revoked, and have their “knocking keys” rotated. This is a classic (annoying) symmetric key distribution problem.

Port knocking is also impractical for popular/busy servers because the popularity of a server contradicts the very goal of port knocking: to conceal the very existence of a service on a server. If an attacker is aware of the nature of his target and knows (or at least has an idea of) what services the server has, he will not be satisfied if his port scan turns up empty. If he expects certain services to exist on the server, and if he is in any way persistent, he will investigate the server until he finds the services he knows exist, thus he willinvestigat the potential use of port knocking sooner or later. This does not result in instantaneous defeat of course, but the port knock is only a secure as a password sent in cleartext, which is a bad security measure to have to fall back on. The exact situation will dictate how easy the knock will be to sniff.

This quick assessment should make it obvious that the only practical use for port knocking is on small servers. Realistically, the service itself should be secure enough in both configuration and implementation to not require the additional security of port knocking — it is an Internet service, after all — but port knocking does add yet another level of plausible security, and the paranoid never underestimate defense in depth.

All things considered, port knocking is not too useful, despite being a fun idea. The only place I’ve actually observed it in use was by people at DefCon looking for any way to add any level of security to their home computers. But, obviously, those are the “I will because I can” types. Plus, when you’re at DefCon you use anything to secure your home server that you can get. But outside of the experimental world, port knocking is only an interesting notion, it never sees wide-scale usage for a reason.

Note that Port knocking is not the same thing as Single Packet Authentication. Port knocking was the initial attempt to gain security by service invisibility. SPA is the more secure successor to port knocking, developed to address key problems in port knocking. I will cover SPA in another article.

Update 6-30-08 (PCManFM v4.5):
As of v4.5, PCManFM started to add an integrated feature to disable delete confirmation, fullfilling the goal of this patch. (The upcoming official feature appears to disable confirmation when a trash can is used.) This new feature does not yet fully work but the code is similar to the patch. Since the author has not seen fit to activate the feature and is clearly working on it, I do no anticipate releasing patches to work with any version beyond v4.3.

This patch adds the option to enable/disable delete confirmation in PCManFM, a popular, light-weight, tabbed file browser. Default behavior in PCManFM is to always prompt the user for confirmation when deleting a file (the classic “Are you sure?” prompt), a feature some find inconvenient. This patch adds an option to the Preferences menu that allows the user to select whether or not they wish to be prompted on deletion.

To the right is what the Preferences menu looks like after the patch. (The dark colors are due to my GTK theme, they have nothing to do with the patch.)


Patch version: v2 (June 26, 2008)
Last tested against: PCManFM v0.4.3
• Download •

Applying the patch is simple. First download and extract the PCManFM code. Then apply the patch to the source. Either:

…from the parent directory with: …or from the actual source directory with You can then compile PCManFM with the standard:
Patching was pretty minimal, save for one file: pcmanfm-{$version}/data/ui/prefdlg.glade . In the original source, practically the entire XML UI design file is devoid of whitespace, including newlines (for optimization), which makes a nimble patch for it impossible, thus this entire file must be redistributed. This file holds the entire visual layout for the Preferences menu, thus the patched prefdlg.glade file will have to be updated whenever the official PCManFM package updates the Preferences menu layout (something unlikely to happen).

Aside from that issue, since the editing was very simple and inline with the basic structure of the program itself, I see no reason why it shouldn’t work for on many PCManFM releases to come. (If things change, I’ll update the patch, though.)

Some OSs lend themselves to compiling from source very easily. If you use such an OS (Arch Linux, Gentoo, FreeBSD, etc) you may wish to write a script to apply the patch and rebuild the package. For Arch Linux, move the patch to your /var/abs/local/pcmanfm directory and add the patch to the PKGBUILD via: I’m unfamiliar with Gentoo’s ebuild format, but I’m sure that modifying an ebuild would be similar.

Just a helpful tip to would-be script writers out there: It is advisable to examine your script before you run it. I learned this lesson the hard way recently.

Before the upgrade to v2.22, the Gnome desktop environment kept each user’s “trash can” in the folder ~/.Trash. Performing a “soft” delete of a file merely moved the file to the trash can, where it would await permanent deletion.

Being a security-conscious person, I made a habit of shredding my deleted files when I emptied the trash. Since there exists no built-in feature to do so, I wrote my own simple script to do it for me, as follows.

#!/bin/bash

# Empty the "trash"
cd ~/.Trash
shred -n 3 *
sync
rm -rf *

It performed its elementary task perfectly.

However, when Gnome upgraded to v2.22, the location of the trash can changed (for better compliance with the FreeDesktop.org standards) to ~/.local/share/Trash. In this folder exist two folders, “files” and “info”, which contain the actual deleted files and info for their undeletion, respectively.

So I had to upgrade my script to shred the new trash can. At the same time I decided to add an option to empty the trash without shredding the files because sometimes I would have large non-sensitive files (such as Linux distro ISOs) that I didn’t care to spend time shredding. So I rewrote my script in less than a minute to this:

#!/bin/bash

# Empty the "trash"
if [ "$1" = "shred" ]; then
	cd ~/.local/share/Trash
	shred -n 3 files info
	sync
fi
rm -rf files info
mkdir files info
chown b-con:users files info

Since I was working on various other school/personal projects, I made the changes without thinking too much about it and quickly moved on to other tasks.

If you have any experience with programing, a quick glance through that revised script should raise a serious red flag.

That’s right, my script only changed into the trash directory if I was performing the shred operation. If I was not performing the shred operation, it did not change directories and merely deleted “files” and “info” from my current directory. I had placed one line of code just one line too low.

I suppose it goes without saying that in my home directory I keep a folder called “files”. This is where I store dozens of miscellaneous files, such as half-finished writings for this website. The first time I executed the script without the “shred” optoin while in my home directory, which was that very day, the contents of my “files” folder disappeared.

When I noticed what had happened several days later, I nearly had a heart attack. I spend a long time looking through various logs and my bash history, trying to determine what had happened. I was mad that something had the audacity to touch files in my home folder. I was ready to strace every binary on my system. However, seeing the presence of the new “info” folder eventually sparked my memory and I realized what had happened. Needless to say, I felt more than just a tad embarrassed.

I recovered just about everything from a lucky three-week-old backup I had made by chance, so all ended well. But still, that’s one lesson I’ll not soon forget: Always proof-read your bloody code, even just briefly.

In just four days of wearing my new favorite sweatshirt on campus for the first time I got four separate complements on it. Three people asked me where they could buy it.

Unfortunately, this sweatshirt is not explicitly for sale anywhere. I had it custom made because I couldn’t find anything like it.



(For those of you who like the sweatshirt and that I directed to my site, this is what you’re looking for.)

I love my sweatshirt, I’d sell it on a store like CafePress if I could find one that has black sweatshirts. Since I can’t, the next best thing is to provide the instructions to get one.

The image: You can get the image I used for the screen-printing here. However, the company I used for the screen-printing required you to upload an inverted version of the image (last I checked), which you can download here. If one doesn’t work try the other.

The company: The company I used to screen-print the image is Blue Cotton. I chose the Hanes Pullover sweatshirt (Printing -> Sweats -> Hooded Sweatshirt -> F170 Hanes Pullover Hood), but they do offer other sweathirts. The Hanes sweatshirt has the advantage of having the lowest polyester content (90% cotton) of any of their sweatshirts, which is a good thing for a screen print and has the side benefit of being very comfortable.

The sizing: For my sweatshirt, an extra-large, I chose to make the image 9.5 inches wide (be sure you lock the width/height ratio when scaling) and put it 2 inches below the collar (you’ll have to eyeball this measurement). It took a long time for me to decide on those dimensions, but I finally did and I think it’s the perfect size, which is saying something. You might want to scale the width for sweatshirts of different sizes, my rough guess would be to subtract/add .75 to 1 inches per size smaller/larger.

So all you have to do is go to the website, select your sweatshirt, upload the image, set the width/placement, and order it.

I’m a math major, and I like elegance. Euler’s Identity is my favorite mathematical expression: it’s a simple expression of universal truth via constants. It’s fascinating how the five most fundamental constants of math are all uniteable in a single, simple expression.

In addition to math, I like t-shirts. I tend to treat t-shirts as billboards for things that I like — you won’t find a blank shirt in my drawer. As need had it, in winter of ‘07/’08 I found myself in need of a new sweatshirt. Like the rest of my upper-body apparel, I wanted it to say something interesting. I wanted the sweatshirt to be “nice-ish” so that I could wear it to “nice-ish” events, so I didn’t want a busy/complicated design. it had to be simple, yet elegant. Settling on a simple expression of Euler’s Identity was easy. My second stipulation was that the sweatshirt had to be black.

I started my search at the obvious place for a weird request like that: CafePress. I found a couple of sweatshirts with Euler’s Identity, but a) They had obnoxious brand logos, and b) Cafepress doesn’t sell black sweatshirts. After an extensive search of the Internet, it became obvious that no one offered anything like what I was looking for (shocking, considering the obvious demand). So I decided to have the shirt custom screen-printed.

Thus I was faced with two tasks. The first task was creating the image I wanted to be screened onto the sweatshirt. The second task was finding someone to screen-print the image. Neither task turned out to be as simple as it might seem.

Creating the image was difficult because the only decoration for the black sweatshirt was going to be the bold, white text of Euler’s Identity. Thus the styling of the text was very important. In order to truly do the equation justice, and make the sweatshirt look as simply elegant as possible, the font had to be perfect. Not fancy, but not boring. Just slightly elegant.

Getting the image screen-printed turned out to be difficult because there were two major conditions for the screen-printing: I had to be able to have a transparent background, and I was not going to order in bulk. Most custom screening companies violated the former of these two requirements, and the few that allowed background colors required bulk orders. In addition, some companies didn’t offer sweatshirts in black.

Finally, however, a solution was reached. I designed the image using the “i” and “pi” symbols generated by a Linux-based LaTeX front-end called eqe. I generated the rest of the equation using characters from the Tahoma font in the Linux-based image editor KolourPaint. I needed a very large size image to achieve a sufficient DPI, which was recommended to be at least 90. Both programs allowed me to create the images at a large size with excellent quality, but not a size quite large enough. So I used Gimp to expand the size and I used its anti-aliasing feature to keep the font’s smooth despite being enlarged. The result is shown here. (This is a scaled-down version of the image, for bandwidth reasons. Click the image to download the full-size image, the one you would use for actual screen-printing.)


View the inverted version.

I also found a company, called Blue Cotton that allows one to screen-print an image, choose a color to make transparent, and doesn’t require a bulk order. (Choose Printing -> Sweats -> Hooded Sweatshirt -> F170 Hanes Pullover Hood.) Thrilled to have a working image and a working company, all I had to do was manually place the image on the sweatshirt. I spent (no joke) probably 3 hours total moving the image around on the shirt, higher, lower, bigger, smaller, trying to get it just the right size and at just the right height. Finally I decided on a 9.5 inch width at 2 inches below the collar, which I am pleased to say is the perfect size/placement (for an XL).



Also, kudos go out to my girlfriend for her extreme patience with me. The sweatshirt was a Christmas present from her to me. Being a nit-picky perfectionist, it was decided that I had actually best do the bulk of the designing. I didn’t even finish the design until the end of January.

Ever one to customize that which I use, I’ve take the time to design my own GDM Login Theme for the Gnome desktop manager for the X Window system.

My inspiration to create the theme actually started with the background image. I’m not graphics artist and I never create my own artwork beyond the simplest of images, but I know when I see an image I like. The background I used for this theme is a blue-colored fractal from Beautiful Fractals. The moment I saw the image, the center circle practically demanded that someone insert a user name prompt in it. So I did.

The theme only comes with a background resolution of 1280×1024. It scales nicely to fit other resolutions so I didn’t care to create separate themes for different resolutions. The original wallpaper, however, comes in many resolution sizes so it’s easy to modify it if you care to.

E-mail me with any bugs and/or problems. No graphics requests, please, I can’t fulfill them. (And yes, the wallpaper itself is asymmetrically shifted by a couple pixels to the left.)

This GDM theme is available Gnome Look