August 2008 Archives

It seems in Vista, unless I'm missing something, I'm not the most important person on my single-user machine.  Something called 'Trusted Installer' is.  So if the uninstaller can't handle uninstalling an application that's put files in C:\windows, say, I can't delete them myself.

I found this out during my Windows SUA/Interix escapades.  Several times I tried to uninstall, and got the response that the uninstaller didn't have the privileges to delete the files it had placed under C:\windows.  It suggested that I might like to do it.  Well, I tried, but Windows Explorer wouldn't let me do it either, saying I didn't have the rights.  I hacked away at it and eventually managed to get rid of most of the directory tree using the Cygwin command line.  Some of the files, though, I just couldn't get rid of.  I wish my workstation would not stop me from doing things.  This seems to be the security approach in Vista: I'm not going to let you do this action (delete a file, open a web site...) because you might endanger yourself.

I've been working with Interix (Windows Subsystem for Unix Applications) instead of Cygwin for about a month now, to provide the Unix environment I want/need on my Windows systems.  Overall, I like it.  I like the idea of it being part of the OS instead of an application.  I like how it can use Active Directory for accounts, instead of having to generate /etc/passwd files as Cygwin does.  I like how fast it is: depending on what I'm doing, anything up to 10 times faster and 10 times less memory consumption than Cygwin.  I like how it has native Unix file sharing, and processes so monitoring tools like top still work.

I'm still working on some of the things that haven't worked smoothly.  I've only been using it for a month versus five years or more with Cygwin, so I wouldn't call them dislikes yet.  I'm installing release 6.0 of SUA/Interix, which runs on Windows Server 2003 R2 and Server 2008, and the Enterprise and Ultimate versions of Windows Vista.  I'm installing it on my workstation which has a dual core Xeon processor, and a number of compute nodes that have dual quad-core Xeons.

First, the system tools (like ls) are the straight BSD kind.  Which is fine, but I've become used to the GNU file utilities, such as the -B switch to ls to suppress Emacs backup files~, or the -m switch for MB for du.  I can always download the source and build them myself - gcc is supplied with the installation - but there have been some issues and this leads me to the bigger issue: 64 bit support.

I'm running an all 64-bit environment.  I regularly work with files up to 50 GB and most of my machines have 12 GB of RAM.  So 64 bit is a must.  It's been tricky to get full 64 bit Interix installed and running, and in fact I haven't managed it yet.  But I read that it's supported, so I believe it.  The problem is that system tools tend to be 32 bit so they give random results for large files - du reporting that a 5 GB file is 1 GB, say.  I've found that if I install the bundle of tools from Interix, I get the 32-bit variety and from there it's hard to install the 64-bit variety.  So after several installs and uninstalls I've settled on this sequence on my workstation runnign Vista Enterprise:
- Turn on 'Subsystem for Unix Applications' in 'Programs and Features' in the Control Panel.
- Download and install the Microsoft 'Utilities and SDK for Subsystem for Unix-based Applications'.  This is a menu option after you've turned on SUA.
- Next, I don't install the tools from the Interix site.  If you follow their instructions, this is the next step.  However I've found these either don't test or don't detect my 64-bit hardware, so I get the 32-bit utilities.
- Now, I download the 'Bootstrap Installer' from Interix and run it.  This just installs the package handling utilities (pkg_add, pkg_upgrade etc) and a few small Unix programs to allow the packages to be installed.

The problem now is that packages have to be installed individually, with a special switch to specify that only the 64-bit versions are to be installed.  This goes like this: <pkg_upgrade -M strict64 -L packagename.  It's a bit clunky, as if there isn't a 64-bit version of the given package, the command just fails instead of installing the 32-bit version which would be better than nothing.  So you have to do it again without the -M switch.

That's where I stand now.  If this all works I'll script up the installation so I can deploy it on any number of machines.  For now I'm taking it slowly.