Practical computer tips, with a smattering of digital philosophy

Monthly Archives: January 2009

The first question that I imagine will come to the mind anyone who stumbles upon this page (eg, you) is what the heck “technosophy” is supposed to mean.  Addressing that question seems to me to be as appropriate an introduction as any to this blog, since you’ll probably otherwise feel inclined to huff off muttering about lunatic bloggers who make up pretensious and meaningless words.  Without further ado, then, here’s my reasoning:

Techno: from Gk. tekhno-, combining form of tekhne “art, skill, craft, method, system,” probably from PIE base *tek- “shape, make” (cf. Skt. taksan “carpenter,” L. textere “to weave.”

Sophy: suffix meaning “knowledge,” from O.Fr. -sophie, from L. -sophia, from Gk. -sophia, from sophia “skill, wisdom, knowledge.”

Online Etymology Dictionary

Technosophy: The act of engaging with an art, craft, method, or system with wisdom and knowledge.


Technosophy, in short, is what we are all in the process of (learning? following? creating?) as we collectively venture further into the digital universe.  This blog is intended to chronicle my own discoveries along the trip.   To the technically inclined, don’t worry; despite what it might seem from this linguistically outrageous and moderately grandiose introduction, many of my posts are practical, hands-on computer tips, which I’ve picked up during my 7+ years as a tech support guy.  Yet the more humanities-oriented types have nothing to fear either, for scattered among this technical gibberish you’ll find a variety of more conceptual pieces – brief essays in which I try to tease out how technology is affecting us as we continue to integrate it into our daily lives.

I gladly welcome any additions or suggestions you would care to offer.

Places malware hides, update #2: search engine redirection

I’m happy to report that I just stumbled across a bit of information that fixes a serious flaw/oversight in my malware removal how-to guide, and sheds a great deal of light on the inner workings of one of the more obnoxious families of malware currently slithering around on the Internet.

For those of you who are anxious to get to the fix, check the symptoms section (directly below) to make sure that these instructions apply to your situation, and then jump straight to the larger text at the very bottom of the page.

The malware that this fix addresses is a rather common breed, often bundled in with some larger malware packages – but there’s no question it’s an extremely nasty monster in its own right, because it has the ability to:

  • Block access to the websites of all securty / anti-malware sofware vendors (if you can’t access, or, for example, this bug might be the culprit), thereby preventing your antivirus engine (assuming you’ve got one) from downloading virus definition updates.
  • Hijack all the major search engines (,, etc.) by turning every search result link into a redirect that sends you to some random commercial website.  That is, while the bug allows you to access and even submit requests to search engines, it somehow replaces all of the links provided by any given search with bogus urls, often starting with “go” (ie,…, or…) that turn out to be redirects to webpages which are at best utterly useless, and at worst potential hosts for more downloadable malware (I think I’ve seen and, among others).
  • Generally slow down your web browser
  • Disable the Windows firewall on System startup
  • Prevent anti-malware applications, particularly MalwareBytes Anti-Malware, from installing or running.
  • Cause a variety of other mischief, which seems to vary somewhat on a case-by-case basis.  I’ve seen the first three symptoms on every system that’s been infected with this thing, however.

Those of us who know a bit about networking will probably be tempted (as I was, repeatedly) into thinking that this bug simply relies on the age-old trick of mucking with the hosts file – which makes it all the more infuriating when you open your hosts file and discover that it is apparently completely uncompromised.  No, this particular varmint is considerably more subtle and sophisticated than a simple hosts-file corrupter.  In fact, it’s not even an executable, nor an executable .dll – which means that there’s no way to either find or kill it using a task manager (even Process Explorer) – because it technically isn’t a task.  As it turns out, the bug is actually nothing less than a full-blown system driver, powering a virtual device that actually doesn’t exist – but one which (as far as Windows is concerned) is every bit as real as your mouse or graphics card.  And in the course of investigating this bug, I’ve discovered that Windows seems to protect all files associated with active devices in such a manner that they are completely impossible to see, much less delete. Which means that the general malware-removal method I outlined previously will do absolutely nothing to kill this thing – except, of course if the driver is no longer loaded.  That means that those who opt to clean out their system32 and system32/drivers directories via a Linux live CD will have no trouble at all – but those who aren’t inclined towards that kind of thing will need a different solution.

Happily, a solution has been found by an enterprising member of the tech community, who was so kind as to outline his procedure here (condensed version) and here (original source of fix).  The instructions are stellar, but they direct you to try to remove the thing using automated tools (most of which won’t work, because the virus will prevent them from running)  before telling you how to remove it manually.  Since this strikes me as an enormous waste of time, I’ve excerpted the manual removal instructions here:

Go to Start > Control Panel > System > Hardware > Device Manager > View > Show Hidden Devices.
Scroll down to “Non-plug and Play Drivers” and click the plus icon to open those drivers.
Then search for “TDSSserv.sys”
Right click on it, and select “Disable”
Note: If you select Uninstall, it will install itself again when you reboot the system, so DON’T select Uninstall.
Restart your pc.
You can now update your Antirus/Malware/Rootkit softwares and the rubbish will stop.
Its now up to the Anti-Virus/Malware/Spyware companies to make an effort to stop this, and not rely on simple basic home PC user’s like myself to save the world
In simple terms, TDSSserv.sys is a service/server redirecting all software updates to (your own computer) so they won’t update

I would offer one addendum to these instructions: once the driver has been disabled and the system restarted, go ahead and delete all of the files in your system32 and system32/drivers folders starting with “TDSS”, as well as any other residual files that seem suspicious (again, see my original evil-file-identification algorithm for details).  There’s really no point in waiting around for your anti-virus program to delete them, which is exactly what will happen the next time you run a virus scan – which, by the way, you should do immediately.

If you’re an extremely zealous/through sort, you could even go and remove (*carefully*) all the instances of “TDSS” in the registry, but I’ve never done so, and no computer I’ve worked on has suffered as a result.  Once the driver files themselves are decomissioned/deleted, the bug is vanquished.


Google search optimization section (ignore this):


cannot run malwarebytes, cannot install malwarebytes, searches redirected, google not working, cannot use google, go somewhere else, broken, cannot acces, cannot update anti-virus, blocked

Linux: keyboard stops responding after computer has been idle

Chances are that if you’ve read this far you have a pretty good idea what I’m talking about, so I’ll refrain from describing the phenomenon in detail here, and simply refer you to this discussion from the Ubuntu forums.  In general, however, what happens is that an afflicted computer will somehow kill the power to its own keyboard (and, in some cases, its mouse as well) upon resuming from sleep or screensaver mode.  It does this for no apparent reason, and (in my experience) at totally random intervals.  The operating system isn’t technically frozen, but it might as well be – particularly if you (like me) have your computer set up to prompt you for a password after being idle for x minutes.  The only way to “fix” the problem is to pull the plug on your computer (do a cold reset) – never a particularly pleasant or safe experience, and potentially a truly disastrous one if you happen to have unsaved documents open at the time of the failure.

At any rate, I’ve yet to find any particularly convincing theory as to what might cause (or prevent) this phenomenon, so after a few bouts of research and much tinkering I’ve decided to put forth my own.  I sincerely hope someone will (a) benefit from it, (b) test it, and/or (c) provide evidence that it’s totally and completely wrong.  My main interest here is just to hone in on what’s actually causing the problem, because although it seems to be fairly widespread, few in the linux development community seem to be paying it much heed.

Anyway, to get to the point:

Based on my experiences so far, I’m guessing the freeze has something to do with GL (3D) screen savers, because that’s the only consistent, (likely) unchanged feature I can think of across the two installations on which I’ve experienced this problem (SuSE 10.2 and Ubuntu 8.10). If your keyboard is periodically freezing up, try disabling your screen saver, and see if that helps at all.

I realize that this notion may make absolutely no sense from a technical perspective, but I’m going off of pure empirical evidence here, and the evidence stands as a follows:

– This kind of failure always occurs during a period when a given computer is idle – when one would expect a screensaver to be invoked.

– I’ve often noticed various strange screen saver glitches and “artifacts” appearing immediately prior to the failure; sometimes the screen saver might fail to appear entirely; sometimes it might be fragmented, and certain sections of the screen would seem to be covered by black boxes, and so forth.

– The Ubuntu discussion mentioned above, which is by far the longest analysis I’ve been able to find of the issue, ended without really concluding anything, but some participants thought that the problem might be caused by compiz.  I’m almost positive this isn’t the case, however, because I’ve encountered the issue under SuSE 10.2, which definately was not using compiz.

–  I disabled my screensaver entirely a few days ago on my Ubuntu installation, and my keyboard hasn’t yet failed.

–  Even if the GL screen saver engine were known to be buggy, who would make it a priority to rewrite/debug it?  My guess is that screen savers probably aren’t on anyone’s list of top 100 (or 1000) development priorities.

“Don’t be Evil”? Google’s content policy certainly ain’t angelic

Some of you will doubtless already be experts on Google’s privacy policies (or lack thereof), and many of you have probably heard vague mentions of some of their more disasterous public appearances – but to all those who haven’t had a chance to actually read Google’s formal statement of its policies regarding user-supplied content, be warned: the following will blow your mind.  At least, it should.  If the statements below don’t at least give you pause for thought, I’d  suggest that you really need to take a closer look at the long-term implications of these kinds of policies (which, in fariness, are hardly unique to Google).

Without further ado, here are the golden words, which (as far as I can tell) apply to every single one of Google’s online services (gmail, calendar, docs, bookmarks…)

“11. Content licence from you

11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.

11.2 You agree that this licence includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.

11.3 You understand that Google, in performing the required technical steps to provide the Services to our users, may (a) transmit or distribute your Content over various public networks and in various media; and (b) make such changes to your Content as are necessary to conform and adapt that Content to the technical requirements of connecting networks, devices, services or media. You agree that this licence shall permit Google to take these actions.

11.4 You confirm and warrant to Google that you have all the rights, power and authority necessary to grant the above licence.

Are you really comfortable with every word that you write or read on-line being scanned, indexed, store, and shipped off to a variety of unspecified coorporations for the purpose of giving you a “more immersive web experience?”  Or having an email to your cousin used in Google promotion?

If you’re even moderately outraged,  good.  But hold on – there’s a rather complex caveat that might confound your ire.  Though I too find this whole arrangement thoroughly noxious, I must admit that google’s overall philosophy towards content ownership does in some ways seem remarkably in-tune with the “open culture”/ creative commons / copyleft movements – trends which I heartily applaud and support.  The question of whether anyone can truly be said to “own” content in the Web 2.0 universe – and whether or not, in this day and age, the whole notion of content ownership is in fact totally obsolete – is one of great importance, and as much as I’m loathe to admit it, google’s “you no longer have exclusive rights to anything you produce on-line” doctrine can some ways been seen as little more than an unapologetic – and even, perhaps, foresighted – dose of reality.

That’s not to say I’m not extremely upset by this kind of corporate philosophy.  After all, it seems highly ironic, in light of the fact that the copyright-reform movement is widely viewed as an egalitarian campaign against the tyranny of large corporations, that some of the entities most interested in shoving the doctrine of shared content ownership down our throats are in fact some of the largest companies in existence (Google, Yahoo, Microsoft, etc.).  Still more grating is the fact that they’ve taken a (again, in my view) fundamentally positive  principle, and warped it to make it serve their business interests (ie, targeted advertising), and that they’ve been allowed to do so simply because they have the ability to dictate their terms of use from positions of extreme power.  After all, who doesn’t use Google?

Forward-looking though they may be, Google’s policies still rankle.  And I’m not sure I’m entirely comfortable with the kind of future such polices forshadow.

Any thoughts?

uid= and gid= are (no longer) valid mount options for xfs (in /etc/fstab)

I’ve just spent an invigorating hour trying to figure out a solution to the (apparently rather common) “I want to mount a partition at boot, but I don’t want it mounted as root” conundrum.

For many file systems, the mount man pages tell us, this problem can simply be solved by adding uid=<your user id #>,gid=<your group id #> to the options section of the fstab entry for the partition in question, which will cause it to be mounted with you as the owner.  For the record, the problem can also be theoretically be solved by allowing the partition in question to be mounted with root as the owner, and then laboriously going through and changing the owner of every file in the partition (chown <you> /<the pesky partition>/* -r).  But honestly, who wants to do something that inelegant?  (Okay, fine: yes, I probably would have gone  right ahead and resorted to this, but for reasons which remain unclear to me this didn’t work in my particular situation).

Edit: Though this may have worked once, I haven’t gotten it to work on any modern version of Ubuntu.  I’m not sure what happened, but if I ever find out, I’ll update this post again.

However, I happen to be using XFS, and the mount man pages make no mention of the uid= and gid= options being suitable for use with XFS filesystems.  Since the man pages also say nothing about them NOT being usable with XFS filesystems, however, I gave them a try, and am now happily reading and writing from my mounted partition as myself.

I know this is probably pretty basic stuff for some of you, so please feel free to chortle depreciatingly, if the mood strikes you.