Talkwards

I’ve tried several ways to keep track of my mouse pointer.  It’s kind of hard from time to time.  Adding more than one monitor does not help at all!

Recently a colleague gave me the tip to make the mouse pointer black… and larger. I tried this and found that the mouse pointer was much easier to spot.  No surprise there, really.  After all, white on white tends to become a bit hard to keep track of, tiny silhouette outline or not.

I was told how to do this in Windows (Control Panel > Mouse > Pointer, but that’s another story).

In Gnome (I’m running Ubuntu 8.10) you do it in the System > Preferences > Appearance dialog (see below).  In my version of Window’s there’s no settings under Appearance > Mouse.

Next you click the “Customize” button:

In the new dialog select the “Pointer”-tab and select the color of pointer you want.  In order to resize it, see the “size slider” below the list of pointers (there seems to be three distinct sizes to choose from).

Click “Close” once you’re done, and voila, you have a new and much easier to spot mouse pointer!

You may have thought GNU/Linux was written by idealistic Unix Gurus camped up with a bunch of Jolt-Colas in their mom’s basement, but a recent report from the Linux Foundation states the opposite. Since Linux kernel version 2.6.11 in Mars 2005 the number of developers has grown from 483 to 1,057 in version 2.6.24 (January 2008). However, the number of sponsoring companies has also grown from 71 to 186 in the same time.

The major contributors aren’t Mom’s Basement Inc. either. Companies like Novell, IBM, Intel, SGI, Oracle, Google and HP rank among the 20 largest contributors (counted in number of sponsored changes, and here sponsoring means paying employees to program those changes).

This is just the Linux kernel (some 8.5 – 9 million lines of code). However, the Linux kernel in itself is of little use to anyone. You have to add the GNU part of GNU/Linux, consisting of commands like fdisk, aspell, bison, ghostview, and wget to that, and you’ll be looking at a much larger number of lines of code. If we go even further adding programs from other projects (like the Mozilla project’s FireFox web browser, or the OpenOffice suite) more lines of code are added (for exact numbers see ohloh.net), and we’re still talking about programs supported by large companies (IBM, Sun, etc).

To sum it all up: no, GNU/Linux is not being written by enthusiasts in the basement anymore. It’s being written by large corporations for competitive reasons. Hardware manufacturers wants to make sure Linux will work on their hardware, software companies can be anything from Linux distribution owners (Red Hat, Novell, MontaVista), use embedded versions of Linux in their consumer hardware (Sony, Nokia, Samsung), or for other reasons (for instance Volkswagen uses Linux for in-car networking between different components).

Professor Avishai Wool presents a system that protects GNU/Linux machines from intrusion and malicious program code by using statistical analysis and policy files defining a programs normal behavior, and if that program deviates from said behavior the system stops it.

Since the analysis is hooked into standard GNU/Linux build tools and uses the source code to derive the policy the system is said to guarantee zero false positives. A system of this type is cited to be able to perform protection from threats long before traditional anti virus solutions has categorized them, and with far less penalty to system performance.

Here’s a list of links for further reading:

• http://www.sciencedaily.com/releases/2008/09/080909111037.htm
• http://ols.fedoraproject.org/OLS/Reprints-2008/bencohen-reprint.pdf

I don’t know why, but from time to time drivers are assigned other “/dev”-paths on my ubuntu 6.10 LTS GNU/Linux server. I think a removable USB driver might have something to do with it…

However, when that happens it is a complete pain in the a$$ because if the driver is relocated, the system cannot find it and if it is mentioned in /etc/fstab the system reasons (justly so, I might add) that if it can’t find the drive it should pull the emergency break and jump into a rescue prompt (where mostly everything is disabled), letting the user (that’s me) deal with the problem.

I usually press the CTRL-D command exiting the shell and getting back to the boot process praying that no vital driver was lost. (I’m not really a guru, just a poor guy trying to make live a little easier).

For some reason (touch wood!) the drives with the boot image or with system specific things on them has never been moved around this way. Usually its the USB drive itself (when I still had it in the fstab) that has moved (I’ll get back on how to make it auto-mount in a later post) or in this latest case, one of the back-up drives.

However, there’s a solution. If you run GNU/Linux you might have seen it in your fstab-file. The use of a UUID to do mount instead of the regular /dev/something. My desktop computer’s fstab looks like this:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options> <dump>  <pass>
proc            /proc           proc    defaults  0       0
# /dev/sda1
UUID=e1f37856-6cfd-43f9-bea0-d4c2e43afe29 /     reiserfs notail,relatime 0  1
# /dev/sda6
UUID=64549135-a478-4aef-bb2a-da37d245dd9c /home reiserfs relatime        0  2

From this rather confusing array of characters (I had to shrink the spaces in order to fit it on the site) you can determine that there’s three devices mounted at start up (proc, sda1 and sda6, I’ve got even more, but the exact number of devices are not interesting for this discussion).

The proc device always resides at the file system “proc”, and it does not have nor need a UUID. However the sda1 and sda6 devices are regular hard drives (formatted with reiserfs) and they can change designation, for instance if I start rearranging my sata-cables or start a USB drive in a USB slot with a lower ID than those of my sda drivers (I’m guessing on that one but I’ve seen it on my server so…) These are therefore interesting to mount not by their dev-names but by their UUID’s. The UUID are stored on the drive itself and it wont change unless the drive is reformatted. The drive can be moved, turned off, turned on, it will still have the same UUID.

So, using UUIDs are a good idea when I want to create my new, drives-moving-around-proofed server configuration. The first step is to determine what UUID the drives have. This is done with the following command:

sudo vol_id -u /dev/something

I had problems finding “vol_id”. It was not in the PATH, and could therefore not be run like above. I did a locate (locate vol_id) and found it in “/lib/udev” so I prepended that path to my command. I’ve also to determine how to get the UUID from a swap partition, but for now I’m happy to have the infringing drives on UUID and hope the swap wont move (perhaps with the extra 2GB of memory I also stashed in it will need the swap even less, but anyway)…

You won’t be able to determine the UUID of any drive part of a software raid configuration (but then again, the software raid is able to do its own magic locating of drives regardless of their sd-number — trust me, I’ve done that as well — so they won’t need a UUID anyway — wouldn’t surprise me if raid uses the same scheme behind the scene though)

Let’s look at the changes I did in my fstab file (always make backups before you start messing with this file! If you fail to set it up correctly your system will probably not start at all so have a live-cd handy before trying to do this!):

/etc/fstab before I changed it (just a part of it)

# /etc/fstab: static file system information.
#
# <file system> <mount point>    <type>   <options>           <dump>  <pass>
proc            /proc            proc     defaults            0       0
/dev/sdc1       /                reiserfs notail,user_xattr   0       1
/dev/sdc5       /home            reiserfs defaults,user_xattr 0       2

As you can see the situation is not as clear on this machine as it was on my desktop machine. Here sdc is the main system drive and that alone is a, well not a worrisome problem, but a slight discomfort… sdc never moved around, but being that I have a bunch (8 or 9) sata-cables in a large but far-from-large-enough case I’m bound to switch them around one day or another…

Anyway, using the above vol_id command to get the UUIDs of the drives, I’ve updated my fstab to look like this (still only partial fstab but you get the idea):

# /etc/fstab: static file system information.
#
# <file system> <mount point>    <type>   <options>           <dump>  <pass>
proc            /proc            proc     defaults            0       0
#/dev/sdc1
UUID=716cf691-dabd-4894-8e46-bc02b4c092b4 /     reiserfs notail,user_xattr   0  1
#/dev/sdc5
UUID=9587a32e-ebb2-45ab-9e68-7a66cf43d6b4 /home reiserfs defaults,user_xattr 0  2

Unfortunately I have the same problem as above, the lines wont fit in the editor (or on the site) if I tabulate them correctly, but hopefully you’ll still be able to connect the dots. Every group of white spaces (space, or tab) in the file counts as a field separator. I’ve commented out the “/dev/sdc…” section, added a line feed and replaced it with the “UUID=…” section, and then left the rest of the line intact.

This makes sense since I’ve replaced one identifier (“dev/sdc…”) with another (“UUID=…”). So, after the original “dev”-version of the file has been safely backed up, the entries in the original “/etc/fstab” has been checked and double checked, it’s time to restart and pray this will actually work. :O

Here’s a few links you might want to check out before you give it a try:

• http://linux.byexamples.com/archives/321/fstab-with-uuid/
• http://www.cyberciti.biz/faq/linux-finding-using-uuids-to-update-fstab/

Good luck!

Windows doesn´t work as it used to after I associated the .exe-extension to putty.exe...

I am clumsy. I can only confess. But I still think what I did should not be possible to do. I mean, its not like having a foundation is optional when building a house… why should running exe-files as executables be an option?

Okay, this is what I did: I have an exe file (putty.exe) sitting on my windows start-menu (oh did I forgot to mention this was a problem in Windows? Sorry…) However, I happened to move the folder where this file was located. Not so good perhaps because now, of course, the link to putty fails.

So, I right clicked it and selected properties, trying to figure out if there was a way to redirect the link. There was… kind of… there was the “Open With” button. I thought, hey, that could be it, lets try it and see what happens. So I clicked it, opened it and selected putty.exe. It didn’t work.

Or, well. Windows did what it thought I wanted it to do. The dialog I’ve quickly scanned before selecting a file was the dialog for reassociating the .exe extension … with putty.exe. This however was not in Windows liking, so now whenever I click an exe I get the dialog here to the left.

It would have been really bad if I hadn’t done one good thing that day. I installed cygwin… and weehoo… windows programs can be started from cygwin. Phew! I can tell IT-support the problem is solved… almost!

At least one good thing. The problem is rather easily solved. Let’s see if I can remember the steps the rather stressed out support technician went through. Open “My Computer”, select “View” in the the menu and go to associations in the dialog. What we want to do is associate the “Application” association (There are a number of other “Application”-associations but we never touched them… and if they haven’t been changed, don’t touch them, and if they have, I’ve no clue what extension they should have so … don’t touch them…)

Since this is a “built in” association it won’t be in the list of associations, we have to create it again (?!). Click “New” and in the new dialog enter “EXE” as the extension and from the drop down select “Application”. Don’t push any buttons! Without having to push any buttons, but with the kind mercy of the Gods of Windows, a message that the “EXE association has been changed” will appear along with a button to reset it to the default settings. Push the “reset”-button.

And this good folks is how my problem was solved. I came a cross a few “regedit-hacks” but I wouldn’t recommend them unless this solution doesn’t work. Also make sure to reboot after you’ve reset the association because for me assorted things like remote desktop links and some such started to get broken after a while. (Don’t ask. I have no clue why!)

Good luck and don’t experiment with your computer, naughty! You can break something for real…

I’m just back from a head spinning experience of extreme Windowsism.  A file that refused to be renamed, or deleted… until ten minutes later…

What happened was that I wanted to rename a file.  Like I usually do, I clicked the file, then pressed F2, got the “editable” view of the file name and started typing.

Nothing happened.

I clicked around, trying to see if the computer was just slow or something like that.  Well… the file explorer did not respond at all…

It was frozen.  So I waited for it to unfreeze.  Which it didn’t.  It apparently had crashed.

I force-quitted.  Restarted and retried.  After all, perhaps it was just a fluke?  Right?

Nope.  Same exact problem.

I scratched my head, thought for a bit and rejected a number of alternative ways to go.  I guessed it was time for the daily reboot… again today.  And rebooted the system.

Once back in the catalogue (five minutes later) I found the same problem persisted.  No rename, no file explorer, nothing but kill the program.

I was able to “solve” the problem however, by copying the file.  Once I had it was in fact possible to rename the copy.  All I had to do now was to remove the old file and, although kind of axy (as in trying to carve an inch high wooden statuette with an axe), the problem would be solved.

The file did not want to be deleted.  However, the file explorer did not freeze this time so chalk one up for windows?  Or not.  Shutting down the file explorer and restarting it did not help either.  It was time to harvest the vast experience of the firm.

I asked around in the office landscape trying to find someone that could help, and I got a number of helpful advice like “have you restarted the file explorer?” or “have you rebooted the machine?”  All of which was rather not what I hadn’t already tried.

Finally someone suggested: “put two files in the same folder where the problematic file is placed, name them so they appear just above and just below the file with the problem, put something like ‘erase me’ at the end of them, wait a week and delete the file then.”

After having hyperventilated for a while to get the whole concept into my head and make it stick long enough to do what the guy had suggested I went ahead.

My magic file was named something like “My document 2.rtf” so after some experimenting with names that would place the file exactly where I wanted them I came up with:

My document 2.rte.delete.me.txt
My document 2.rtf
My document 2.rtg.delete.me.txt

Now for the mind blowing finale.

Once I had the files in place my folder looked like:

My document 2.rte.delete.me.txt
My document 2.rtg.delete.me.txt

The magic file had disappeared!  Finally deleted!!  Only about ten minutes after the button was pressed!!!

That was when I noticed the dialogue boxes saying “The file cannot be renamed, it has disappeared.”  They were, in true windows style hidden under the file explorer window…

Aha, was my first thought, problem solved…  Then I felt a chill going down my spine.  Didn’t I try to rename before I deleted?  Or did I try to delete first and rename later?

No! my mind screamed.  I had a file, whose content was important but whose name was wrong.  So deleting before renaming would be stupid.  And renaming after I’d copied the file and renamed the copy would be equally stupid (not to mention impossible… there was already a file with that name…)

Somehow windows had confused the order of the operations?!  BRRRRR!!!

You might think, hey he was working with a networked drive and the net was having some kind of problem or the order of the packages got confused.  It’s a good idea, it could really happen, even though I think the Samba protocol (or whatever windows have chosen to call it) should be able to handle packages coming in haphazardly without getting confused like this, and the most probable result of Samba not managing that should be some kind of failure, even total failure demanding the drive to be remounted (or a blue screen or whatever XP uses when the OS-programmers run out of money, time or happiness).

Enough about networked drives… the drive in question was local!  No network, no delays, not even cables (USB/FIREWIRE/eSATA or what have you)… unless you count the system bus.  Does windows use TCP/IP on the system bus?

Well… thank God I have my important files on another OS altogether!  Not to mention on RAID and USB backup…

Computers are scary… Windows computers are terrifying!