Resistance to change is a defensive measure we all have to prevent wasting time learning something new for the sake of change. It can go too far. It has gone too far the way many retain that other OS. You know the kind:

  • never used anything else
  • hires someone every year to re-install/delouse that other OS or pesters an acquaintance to do it for less
  • accepts the idea that computers slow down (HAHAHA!)

These behaviours are irrational acts of the lazy. They are not idiots incapable of deeper thought. They are just using poor judgment and are resistant to change. The Blog of Helios does use the “idiot” term today. I guess enough resistance to change warrants the term but I think “stupid” is more appropriate. There cannot be that many idiots in the gene pool or we would not have gotten this far as a species.

I try not to be stupid but I did use that other OS for far too long:

  • I used a dozen different architectures of hardware, some even without an operating system, just stand-alone programmes
  • I like the old days of automobiles when anyone with wrenches and screwdrivers could fix their own vehicle. I try to fix my own PC and I rarely am stopped
  • my computers do not slow down. I run GNU/Linux. It has no brakes.

I had an example of this last item in operation in my school this week. I converted a lab to use GNU/Linux by adding a 5 year old PC as a terminal server and converted the 20 PCs in the lab to thin clients. It was a struggle because of various hardware and software issues like having to edit the boot loader configuration of that other OS to preserve it (Why? Some resist change…), many hardware problems in the old equipment (Remember 4MB video cards?), but it was worth it:

  • booting of clients in 30s instead or 3 minutes
  • login takes 5s instead of a minute or so
  • the largest application opens its window in 2s

This weekend, I added four more clients. The users of that other OS, who find they have to have the latest processor just to keep the bloatware moving fast enough cannot understand how one old PC can give 24 people good performance simultaneiously but it is easy if you

  • waste no cycles doing M$’s bidding
  • do not waste cycles running malware
  • do not clog network connections with spam
  • avoid features like “roaming profiles” which suck the life out of your network

So, including a switch from that other OS, my old PCs actually speed up! Isn’t that a refreshing change? I converted ten year old clients and a five year old PC into something wonderful. Students are excited about it and the increased performance is an obvious reward for the effort of changing. Most people are not stupid. They just need a little guidance. By asking the old boxes to do less, they get it done sooner. Simple concept. It works.

I believe if you cannot describe in numbers knowledge is of an uncertain kind:

  • the clients use 48 MB of RAM to do the job now instead of 384 MB and swapping madly with XP
  • the clients use only about 20% of their CPU time when busy
  • the clients need only about 2 megabits/s of network bandwidth each so there is no bottleneck at the gigabits/switch/ NIC on the server
  • the server PC has 2 gB RAM and runs at about 50% CPU utilization on AMD64 1.8 gHz

Those used to their machines dragging with fragmented file systems and the like would appreciate a machine giving snappy performance with 2000 context switches per second. There is no bottleneck in this system except RAM is a little tight (swap reached 1.6 gB), but then I am running a LAMP stack on the same machine… Those who object that the students are not all working on 200 MB images with GIMP are being picky. Students read, write and think. This system works for them.

Want to take a tour of the lab? What have I left running?

sh-3.1$ ssh old
Last login: Fri May 8 21:20:34 2009 from
pogson@old:~$ su
old:/home/pogson# nmap -sP 192.168.0.*

Starting Nmap 4.62 ( ) at 2009-05-10 09:12 CDT
Host old-o07 ( appears to be up.
MAC Address: 00:0D:88:36:C0:F3 (D-Link)
Host old-o08 ( appears to be up.
MAC Address: 00:0D:88:36:C3:19 (D-Link)
Host old-o12 ( appears to be up.
MAC Address: 00:15:E9:B0:FD:12 (D-Link)
Host old-o15 ( appears to be up.
MAC Address: 00:50:BA:AA:54:79 (D-link)
Host old-o16 ( appears to be up.
MAC Address: 00:50:BA:86:5E:B5 (D-link)
Host old ( appears to be up.
Nmap done: 256 IP addresses (6 hosts up) scanned in 1.697 seconds
old:/home/pogson# for f in 7 8 12 15 16;do echo $f;ssh 192.168.0.$f cat /proc/cpuinfo|grep z;done
cpu MHz : 451.035
cache size : 64 KB
clflush size : 32
cpu MHz : 863.875
cache size : 256 KB
clflush size : 32
cpu MHz : 451.034
cache size : 64 KB
clflush size : 32
cpu MHz : 451.040
cache size : 64 KB
clflush size : 32
cpu MHz : 601.396
cache size : 256 KB
clflush size : 32

There. The typical CPU is 450 MHz and the caches are 64kB. They make great thin clients and lousy clients for that other OS. Should we chuck them and pollute the planet? Should we burn less fuel by switching to modern hardware? Yes, if we use thin clients and a hot new server, the performance will be a bit better and we will use a lot less power, but this is what we have with which to work. We do the best we can and the students appreciate it.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in Linux in Education, technology and tagged , , . Bookmark the permalink.

2 Responses to Stupidity

  1. It depends on the apps. If you say a GNU/Linux terminal server is unsuitable because it does not run M$’s Word, I would disagree. Lots of folks find a suitable substitute. Other apps that are more specialized, like running some prototype factory machine serial number 1, would be unsuitable because there may be no reasonable substitute.

    Another factor is ubiquity. If the unsuitable app is only used by a tiny fraction of staff, leave that fraction with that other OS or thick clients. It makes a lot of sense to save on N seats where N is large but not all seats. For example in this place there are about 60 PCs now. There is only one person who has to deal with a M$-only application. It’s a funny one… The application uses MySQL and SUN Java but the supplier ships it in an .exe. I would bet it is a self-extracting archive and once unpacked, I could figure out how to run it in GNU/Linux. There might be some file-system naming conventions that need changing. I could likely move the mysql client app to GNU/Linux as Java code and hook it up to the GNU/Linux version of MySQL. It’s on my todo list, but for one user it is not a high priority. There will soon be a surplus of XP machines here as I put GNU/Linux out.

    Several sources give a figure of about 80% of business seats being suitable for migration to GNU/Linux thin clients. e.g. see 2.2.1 in IBM’s Linux Client Migration Cookbook Version 2. That shows a range of users who are very easy to migrate to GNU/Linux to about the typical office setting. There are corner cases however. Where the bandwidth to the screen is manageable thin clients make sense.

    In the RedBook, IBM gives an example of a user with an unmigratable application:

    “Since the user role for this workstation is primarily for writing books, Adobe FrameMaker is the most important application, and the most important infrastructure components are printing and access to network file shares.The first thing to note about the Adobe FrameMaker application is that there is no appropriate Linux alternative. There is no Linux native version, and moving to another application on Linux is not acceptable from a business point of view. In other words, FrameMaker is a unmigratable application that has to be handled in the manner described in 4.7.2, “Terminal Server, Citrix Metaframe, or NoMachine NX solutions” on page 100.

    I would argue that it is perfectly possible to write books efficiently using GNU/Linux, but, assuming the business feels a particular app from a particular supplier is a necessity, IBM points to the possibility of running it via a terminal server. It is also perfectly possible to have a desktop client with windows open to processes running on several terminal servers at once, so the app runs where it wants and the user can be on a standard GNU/Linux box. Assuming there is a per-server and per-seat price for licensing such apps, this may be quite a reasonable way to go. It is not reasonable to say that if there is one app for one user that does not run on GNU/Linux a whole organization cannot migrate. The cost of clients is the sum of the costs of each category of client. It may be an unnecessary complication to have different types of clients but it may be quite simple to have all GNU/Linux clients and two or more types of terminal servers.

    Munich migrated 300 applications to GNU/Linux and figured it was worthwhile. If an outfit has only a few, go for it. Large organizations often overlook the fact that they have enough licences to pay developers to write an application from scratch to do the job. SUN did that. They had 20000 users of Office and bought StarOffice for less than one round of licence fees. Smaller organizations may not have that luxury but they also may have simpler systems so there is a reasonable chance to migrate. Remember, there was a time when no one had an M$ system, so it is possible. Accepting that it is impossible is accepting lock-in and paying whatever it costs forever, not a good business model.

  2. miguel says:;leftCol

    I’m interested. And I think that the
    possibility of doing Linux TS app server is dictated by apps; i.e. by whether all required (no substitutes) apps exist in Linux versions.
    Please confirm or contradict.

Leave a Reply