Dec 052008
 

I recently encountered a dead blog entitled “Linux Haters” and instantly thought up writing about tedious fan-boys that think that the operating system they like is the best and everyone should use it. I’ve no time for people like that as they tend to annoy rather than educate. I’ve no problem with people who prefer to use Windows, Linux, Solaris or OSX; it is their choice. Of course in the case of Windows, I do have to wonder why 🙂

But one of the links on that blog led to a place that (amongst other things) ranted about how FOSS projects always have dumb names, and that these projects need a big dose of marketing intelligence. He went on to whinge about the word-games often embedded into the project name.

First of all, he misunderstands how many open source projects start – with a geek or a group of geeks deciding they want something different. Either a new package or a variation on an existing one. There are no marketing types in sight, and the geeks involved probably have no great expectation that they are coming up with the next big thing – they are just having fun and hoping to come up with something useful for themselves. So what if they have a bit of fun playing word games to come up with a name for their project ? Not only do many such projects end up disappearing without a trace, but as marketing types have fun playing with words, why can’t geeks ?

Perhaps the names they come up with are not as punchy as a name thought up by a marketing department, but weirdness does have its own value in this area. A name such as Amarok does tend to stick in the mind more than Music Player 52. And over time, formally weird names such as google and yahoo do tend to become more normal if they are attached to popular projects.

Secondly he specifically criticises names invented by geeks for being recursive acronyms … but does that matter ? He specifically names GIMP which is admittedly particularly guilty being a recursive acronym with no termination. But most users won’t care … once they learn that GIMP does images (and most distributions will tell you so in the menu), they are not going to care that the name is an infinitely recursive acronym … they will just get on and use it.

Thirdly he overlooks the fact that some of the names may in fact have “sensible” names but are in fact sensible names in non-English languages.

Finally he tails off into a moderately incoherant rant with more insults than proper facts.

Perhaps “funny” names do put people off, but perhaps not. Most people are in fact more concerned with compatibility (they use Word because everyone else does) or features.

And of course there are more than a few commercial software packages whose name is not entirely sensible … does Photoshop have anything to do with setting up a shop to sell photos? What does Trent do ? Or Cedar ?

Jan 072007
 

I recently replaced an elderly SGI Octane2 workstation which had 2 CPUs (400MHz MIPS-based), 1.5Gbytes of memory, and 3 elderly SCSI disks with a nice new Sun Ultra40 … 2 AMD Opteron 248s, 2Gbytes memory, and 2 mirrored SATA drives. It is interesting to compare the difference between an old-fashioned workstation originally designed in the middle to late 1990s with a 21st century PC. Not that I’m going to produce hard numbers from useful benchmarks … that is just too much work, and in some ways it is the feel of the differences that are important.

Of course this is not really a fair comparison. Whilst the SGI Octane is now very elderly and due to SGI managerial incompetence has not kept pace with PC performance as it should have done, it is after all a machine that originally cost 10-20 times the cost of the PC I am comparing it to. In car terms, I’m comparing a 20-year old Mercedes with a new and cheap Ford. I should point out that much of the software I am using is very much the same on both machines … the Enlightenment window manager, Sylpheed Claws as the mail client, Firefox as the browser, LyX as the word processor, and a text terminal for much of the remainder.

The PC is considerably quicker than the SGI of course. The graphic user interface is a good deal snappier, and most of the applications offer very welcome improvements in performance. With the exception of GIMP however, none of this performance increase is really essential; my old SGI ran pretty much everything my PC does, fast enough to get the job done. GIMP performance is the reason I upgraded, and here the difference is quite dramatic … filters that previous required patience now run almost instantly; when you are repeatedly trying things out in GIMP on quite large images this performance increase makes some things feasible that simply were not before.

There is one area where the SGI does offer some advantage over the PC; something I was expecting. The PCs disks are overall somewhat faster the the disks in the SGI (and of course I don’t have to pay to mirror my disks!), but the SGI tends to work more smoothly under high load. I’ve noticed before with the ‘low end’ on disks in PCs, that if you start to drive your disks very hard, the computer will sometimes stutter. Essentially the SGI was slower, but smoother under high disk load than the PC.

If was not for the need to run GIMP extensively (and the appeal of more standard add-on hardware like USB hard disks), there is no reason why I could not continue with the SGI. The tendency we have in the computing arena of replacing computers every few years is not a healthy one.

Oct 152006
 

First of my real blog entries on IT … or computing, or anything related to technology really.

I work in computing so it is hardly surprising that I have a few opinions on it (or IT), but I’ll try to restrain myself from getting too technical.

Today’s entry is about how having too much knowledge can actually slow you down when trying to resolve an issue. You see, I had a bit of a problem on my SGI workstation when trying to run GIMP or Ufraw (both of which are essential to doing any kind of photographic work). When trying to use either, the application would crash with a little error message saying that I had run out of memory. This was kind of hard to believe as I have 1.5Gbytes of memory in the SGI, and I was not processing any unusually large files.

However I had recently upgraded the software on my workstation, so my instinct was to blame that. The error message indicated that the problem was with a component called glib so I spent hours recompiling that component using multiple different versions so see if I could eliminate the problem. No luck. I even read the source code to the relevant part of glib and tried a couple of experiments to see what was wrong that way. No luck.

After all that time, I spent some more productive time hunting in the appropriate place to find out my problem was probably related to an IRIXism … rqs which was not written to take into account just how many shared libraries applications based on GNOME use these days. A quick fix using rqsall and all was fixed.

Ignoring all the technical details, my knowledge of how Unix works had led me down the wrong path because all the symptoms seemed to indicate an application problem where the real problem was with the operating system. A quick hunt where all the experts hang out showed where the problem was. If I had looked to begin with, I would have saved myself a great deal of time!

However hunting down the wrong path was useful … it helped me practice some skills which need occasional use.

Oh! Don’t assume that my experience is common with those who use Linux. If you stick to a stable distribution and don’t mess too much you will not see this sort of thing.