LinLog - Topic Search

This is yet another "thing I will forget, so I'm writing a note here" post.

I've been used to using Claude Code inside the IntelliJ plugin. That plugin is very basic and still in beta, but it works well enough. All it really does is run Claude Code in the integrated terminal, provide the current file as context, and show changes in the integrated diff viewer. But it also pre-configures the setting to allow you to press shift+enter in the Claud Code to enter a newline.

If you fire up Claude Code in a Windows Terminal session, this does not work. To enter a newline, you have to type a backslash followed by enter, which sort of makes sense, but is annoying and unintuitive. There is a /terminal-setup command, but that also doesn't work in Windows Terminal. Apparently Anthropic hasn't gotten around to implementing that yet.

Fortunately, there is a work-around. You can manually add the key bindings to your Windows Terminal configuration.

"actions": [ { "command": { "action": "sendInput", "input": "\u000A" }, "id": "User.sendLF" } ], "keybindings": [ { "id": "User.sendLF", "keys": "shift+enter" } ]

That's what Claude spit out from a scape of Github, anyway. I originally got it from a Redit post that said essentially the same thing, but now I can't find it. Either way, it seems to work just fine.

I recently started working on a web-based project that has some non-standard networking stuff going on in the dev environment. The fix was easy, but took a little searching, hence this post.

The codebase itself is built on Node JS, but I have to run it in WSL. There are various build issues that keep it from building cleanly in Windows and it would be a bit of work to fix that. But it builds just fine under WSL, so it's easier to use that.

The dev setup uses a Docker container running HAProxy. It's set up to proxy the static portion of the website to the shared dev server (which is on the VPN) and direct the traffic for the dynamic part to a local port. So we have a HAProxy running in Docker, the local dev server running in WSL, and the browser running in Windows.

The problem: In the default WSL config, this doesn't work. The proxy to the shared server works just fine. So if I go to wwwlocal.site.com, that works as a proxy to wwwdev.site.com. Perfect! However, wwwlocal.site.com/login is supposed to proxy to localhost:4321, but that results in a 503 error. However, I can go directly to localhost:4321 and it works just fine, so this is clearly a networking issue.

The solution was to just add a few lines to my $home\.wslconfig file on Windows. The following lines did the trick:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

You can read more about these settings here.

Another "note to my future self", recoded here for posterity.

Today I finally got around to making SSH agent work in Powershell with Git. For the last year or so, I haven't had to deal with because my work mostly involved writing PHP code inside of WSL. In that scenario, you're essentially using Linux, so ssh-agent works just fine.

But on native Windows with Powershell...not so much.

I mean, sure, I could just use Git BASH. But why would I want to do that? Powershell is awesome, and even if I probably know BASH better, I prefer Powershell.

But it turns out it wasn't all that difficult to get things working in Powershell. There were two pieces to it:

Use the right SSH agent (i.e. the one that comes with Git).
Write a Powershell adapter for it.

It turns out that there's a Windows service for "OpenSSH Authentication Agent". I'm not entirely sure what installs that, but apparently it's different from the ssh-agent that's installed with the Windows Git package and the ssh-add command from that doesn't seem to talk to it properly.

My solution was to just disable that service and use the plain-old ssh-agent that comes with Git. The only problem with that is that the traditional invocation of eval `ssh-agent` doesn't work in Powershell because it outputs a BASH-formatted script. But that's easily fixed with a couple of regular expressions. So I added this to my Powershell $profile:

Set-Alias ssh-agent "$env:ProgramFiles\git\usr\bin\ssh-agent.exe"
Set-Alias ssh-add "$env:ProgramFiles\git\usr\bin\ssh-add.exe"

# Need to turn off Open SSH Authentication Agent system service,
# then run the ssh-agent from Git.
function Start-SshAgent {
$output = (ssh-agent)
$sock_match = ($output | Select-String -Pattern 'SSH_AUTH_SOCK=(\S+);')
$sock_path = $sock_match[0].Matches.Groups[1].Value
$pid_match = ($output | Select-String -Pattern 'SSH_AGENT_PID=(\d+);')
$agent_pid = $pid_match[0].Matches.Groups[1].Value
$env:SSH_AUTH_SOCK = $sock_path
$env:SSH_AGENT_PID = $agent_pid
Write-Output "Agent pid $agent_pid"
}

Start-SshAgent

And there we go! Now I can just run ssh-add to add my key and Git picks it up as expected.

Minor annoyance: For some reason, WSL GUI windows like to hide themselves. I'm not sure why.

I see this all the time on my Windows 10 work laptop, where I use WSL extensively. It usually happens after my laptop has gone to sleep. I come back in the morning, log in, and all of my open WSL gVim windows are just gone. The processes are still running, they're just not displayed and they're MIA from the Windows taskbar.

Fortunately, this is easily fixed by just starting a new WSL GUI app. So I generally just pop up my Windows Terminal and start a new gVim instance, and then the running instances pop back into existence and they're fine until the system sleeps again.

I have no idea why that happens, nor if it's specific to Windows 10 or anything else. It's just one of those things that's annoying but not a big deal. Rant over.

Note to self: Sometimes, it seems that WSL needs to be updated. I mean, yes, obviously it does. But apparently sometimes Windows updates will break it and you need to manually intervene.

I saw this the other day. At some point, something got updated and when I tried to open a new WSL terminal, it would always fail with the message Error code: Wsl/Service/0x80040326. Oddly enough, the WSL shells and processes I already had running still worked, I just couldn't start any new ones.

Luckily, the fix is pretty simple. You just have to open up a Powershell instance run wsl --update to update WSL and then wsl --shutdown to reboot it. That's it. It's just annoying because that's a manual process - you still need to manually run the update, even if you reboot your computer.

I had a workflow revelation on my work machine the other week: Corporate IT pushed a Windows 10 update that brought me up to a version that actually supports running Linux GUI apps under WSL!

I've WSL GUI apps on my home Win11 system for a while, but having that on my work machine is huge. I use WSL extensively there. See, we've been standardizing our dev environment setup using Lando, which is basically a convenience layer on top of docker-compose. It's a handy tool, but the relevant thing to note here is that it works by directly mounting your project code directory inside the Docker container. This is convenient for Mac and Linux users, but is kind of a problem for Windows users.

As you may (or may not) know, WSL2 is great and out-performs WSL1 in every way except one: cross-filesystem performance. As long as you keep everything inside the WSL filesystem, you're golden and everything is fast. But as soon as you try to cross from the Windows filesystem to the Linux one, or vice versa, performance just falls off a cliff. Sure, it's not a big deal if you just want to edit a file or something like that, but anything that does any remotely significant amount of filesystem access (e.g. running an npm install) is just painful. In my experience, it's not unheard of for the performance penalty to be on the order of 10x.

Clearly that's not something you want to endure as part of your normal workflow. The simple fix is to do all your work inside WSL, which for me means installing Lando in WSL and hosting my code inside WSL. The only problem is managing the code. If you want to do that in Windows, you need to do it over a network share, which works, but isn't exactly a great experience. It also causes various permissions and file ownership issues for apps like Git that actually care about that.

That's where the WSL GUI apps come in. Rather than dealing with the network share hassle, you can just install your favorite GUI tools inside WSL and run them just like you're on native Linux. Problem solved!

Well, mostly solved. Sadly, not everything runs on Linux. In particular, there's no Linux port of SourceTree, which is currently my graphical Git client of choice. But it's not that I particularly like SourceTree - it's just that I hate it less than all the other Git clients I've tried. So I was forced to try some other options.

This part did not go well. I tried a few different options, including GitFiend (which was nice, but would randomly crash under WSL) and Git-Cola, which was also decent, but which I had to drop because if left alone it would occasionally lock up and then somehow take down the entire system if I tried to close it. I have no idea how it managed to do that (presumably some bug in WSL's GUI layer), but that's a different problem. I also attempted to try Gittyup, but I couldn't, because it only offered Flatpak packages. And, of course, the Flatpak daemon (or whatever it's called) won't install on WSL because it's missing some of the system-level stuff that it uses. But that's a different post.

Eventually, I declared GUI bankruptcy and decided to actually learn how to use Fugitive, the Git plugin for Vim. Turns out that Fugitive is actually pretty good and figuring it out was easier than finding a good graphical Git client. But that's also a story for another post.

In any event, having WSL GUI apps is pretty nice. Now I can do all my work in WSL, and still have both GVim and PHPStorm, if I need it, without having to pay the cross-OS performance price. So I can have nice things and good performance. Yay!

The other week I tried to install PHPStorm under WSL2. Because that's a thing you can do now (especially since Linux GUI apps now work in recent Windows 10 updates). The installation process itself was pretty simple.

Download PHPStorm for Linux from JetBrains website.
Now extract the tarball and run the bin/phpstorm.sh script.
PHPStorm should start up.

The next step is to configure your license. In my case, I was using a corporate license server. The issue with this is that you need to log into JetBrains' website using a special link to activate the license. Unfortunately:

By default, WSL doesn't have a browser installed.
Firefox can't be installed because the default build uses a snap image, and WSL apparently doesn't support snap.
PHPStorm doesn't appear to be able to properly deal with activating via a Windows browser (I tried pointing it to the Windows Chrome executable and got an error page that points to a port on localhost).

So how do we get around this? Well, we need to install a browser in WSL and configure PHPStorm to use it. So here's what we do:

Skip the registration for now by starting a trial license.
Download the Vivaldi for Linux DEB package from Vivaldi's website. You could use a different browser, but I like Vivaldi and it offers a convenient DEB package, so I used that.
Install the Vivaldi DEB. WSL will be missing some packages, so you have to run apt install --fix-broken after installing it.
Go into the PHPStorm settings and configure your web browsers to include Vivaldi and set it as the default browser.
Go back to the registration dialog and try again. This time, PHPStorm should start up Vivaldi and direct you to the appropriate link.
Log into your JetBrains account and follow the instructions. The web-based portion should succeed and registration should complete when you click "activate" in PHPStorm again.

There we go - PHPStorm is registered and works. Mildly annoying setup, but not actually that bad.

As somebody who does a lot of work in a Linux environment, WSL (the Windows Subsystem for Linux) has become almost a required too for me. A while back, I looked up ways to share files between native Windows and WSL. For various reasons, the most convenient workflow for me is to do much of my work on the code from within Windows, but then run various tests and parts of the build process in Linux. So I wanted to see what my options were.

The option I had been using was to use the mount point that WSL sets up in Linux for the Windows filesystem. In addition to that, it turns out there are a couple of ways to go the other direction and read Linux files from Windows. There's the direct, unsupported way or the the supported way using a network share. Sadly, it turns out none of these are really good for me.

My main problem and motivation for looking into this was simple: performance. When crossing container boundaries, filesystem performance takes a nose-dive. And I'm not just talking about an "I notice it and it's annoying" performance hit, I'm talking "this is actively reducing my productivity" hit. For filesystem-intensive processes, on a conservative estimate, when running a process in Linux, things take at least 2 to 3 times as long when the files are hosted in Windows compared to when they're hosted in Linux. And it's frequently much worse than that. For one project I was working on, the build process took upwards of 20 minutes when the files were on Windows, but when I moved them to Linux it was around 3 minutes. And it's not just that project. Even for smaller jobs, like running PHPStan over a different project, the difference is still on the order of several minutes vs. 30 seconds or so. Perhaps this has improved in more recent versions, but I'm still stuck on Windows 10 and this is seriously painful.

My solution? Go old-school: I wrote a quick script to rsync my project code from Windows to Linux. Not that rsync is super-fast either, but it's not bad after the initial sync. I just set it up to skip external dependencies and run NPM et al. on Linux, so even when there's "a lot of files", it's not nearly as many as it could be. Of course, then I need to remember to sync the code before running my commands, which is not idea. But still, the time difference is enough that I can run the command, realize I forgot to sync, do the sync, and run the command again in less time than just running it once on the Windows-hosted code.

A couple of weeks ago I got the notification on my laptop that I could now upgrade to Windows 11. And since I was feeling optimistic that day, I clicked "yes".

I'm not going to do a "review of Windows 11" post, though. Not because I'm lazy or pressed for time (though I don't deny those charges), but really just because I don't have that much to say. I mean, so far Windows 11 is fine. And I don't mean that in the sarcastic, room-on-fire-this-is-fine meme sort of way. My experience has been genuinely fine. It's not a phenomenal, life-changing upgrade, but I haven't had any problems either.

For the most part, I haven't really noticed much of a change from Windows 10. Yeah, now windows have more rounded corners and the UI in general got kind of a face lift, but those are mostly cosmetic changes. They added some handy window management features that I use on occasion, but I haven't discovered any major features that strike me as must-have's.

The one change I did immediately notice was the start menu. I really don't like the new start menu. I think it's much less useful than the one from Windows 10. For one, the default position is in the middle of the screen, which seems like a pointless change. However, there's a setting to easily change that. But beyond that, it doesn't allow much customization and seems much more focused on being a glorified search box than a menu. You can still pin items to the start menu, but the option to arrange them into groups is gone. Also, the pinned area is now smaller and paginated, which is kind of annoying.

Fortunately, that can be changed too. There are a few options out there for start menu replacement in Windows 11. I went with Stardock's Start11, which give you quite a few options in terms of customizing the start menu experience, including versions of the Windows 10 menu and the "classic" Windows 7 style menu. On top of this, it gives you a number of other settings to manipulate the look and behavior of the start menu and taskbar, such as controlling transparency and texture, swapping out the start button image, and controlling click behavior. It's actually quite well done, and with a $6 price tag, it's kind of a no-brainer if you don't like the new menu.

This week, a note to my future self: undoing a USB drive that was flashed with a bootable image is a pain in the neck.

This week my wife wanted a USB thumb drive so she could take some documents to her mother's house and print them out using her printer, because ours is a pain in the neck and it's out of ink. Well, the good news is that I had two drives handy! The bad news is that neither of them did anything when I plugged them into her computer.

Of course, it turns out that, at some point, I'd used both of these as bootable drives for a something Linux-based. This means, of course, that Windows can't read the partitions, so it can't write files to them. In fact, when I plugged the drives in, nothing happened - they didn't even show up in Explorer. So I had to fix them.

Well, the first one was pretty easy. I just used the "Disk Management" console (a.k.a. diskmgmt.msc). Using that, I was able to see the disk and it's partitions. It was then a simple matter of deleting the existing partitions, creating a new one, and formatting it. Then Windows found the drive just fine.

That didn't work so well for the second disk. The drive showed up with an EFI partition and a lot of unallocated space. I tried to create a partition in that space, but it didn't work. So I eventually ended up downloading Rufus. This is a handy tool that I've used in the past to image USB drives with ISO images. Well, it can also do a plain-old reformat of a drive. I just selected "unbootable" for the boot image, GPT for the partition type, and told it to format. Rufus successfully blew away the entire drive and gave me back a fresh, working USB drive.

So the process wasn't too bad. It's just a matter of realizing what's going on and getting an appropriate tool to fix it.

So here's a random Windows 10 issue: I can't connect to WiFi. But only one particular WiFi access point. And I have no idea why.

On Saturday mornings, I take my son to a social skills class. He's too young to drop off and leave (and I don't really have anything nearby that I want to go to), so I sit in their lounge area and do stuff on my laptop - code, blog, whatever. Well, this fall they moved to a new building, which is really nice. But that means that they changed their network and now my laptop refuses to connect to the WiFi.

This is fairly infuriating, because it's not even remotely apparent what the problem is. My phone can connect to the WiFi with no problem at all - it's just my laptop. Windows doesn't give me any error message or information beyond "could not connect," so I really have nothing to go on in terms of looking for a solution. I've never has problems connecting this laptop to any other WiFi access point, and I don't think anything has changed with it recently.

The problem doesn't seem to be an adapter issue, because I tried plugging a USB WiFi adapter into the laptop and that experienced the same problem trying to connect. So the problem seems to be with Windows. I suppose I could confirm that by booting into some flavor of Linux from a USB drive, but that seems like more work than it's worth.

Searching the web, I found are a number of potential solutions, but so far none of them have made any difference. Most of them involve either "reinstall the drive/network/whatever and hope," which I don't really want to do because of the risk of breaking all networking (and because "reinstall and pray" is a terrible strategy), or changing adapter settings. There were also some suggestions to change settings on the WiFi router, but since I don't control the AP in this case, that doesn't help me.

So at this point, I'm pretty much stuck. My best work-around is to just tether my laptop to my phone, which works, but isn't great because the cellular reception inside the building is kinda iffy. I'd kinda like to fix the problem, but as I said, I really don't have much information to work with, I have limited time (less than an hour once a week), and I don't really want to be doing major updates on my laptop out someplace where I don't even have a secondary system with good internet access. So I guess I just have to live with it.

The most frustrating thing about this is that, in the six years that I've owned this laptop, this is the first real Windows problem I've encountered. I've been running Window 8 or Windows 10 that entire time and, while I've heard plenty of complaints and horror stories about Windows, I never experienced any significant problems. This is the first issue I've encountered that actually bothers me, and I'm at a loss as for what to do about it.

I finally decided to do it - reinstall my home media server. I switched it from Windows 8.1 to Ubuntu 17.10.

The reinstall

Believe it or not, this is actually a big thing for me. Fifteen years ago, it would have been par for the course. In those days, I didn't have a kid or a house, so rebuilding my primary workstation from scratch every few months was just good fun. But these days...not so much. Now I have a house and a kid and career focus. Installing the Linux distribution of the week isn't fun anymore - it's just extra time I could be spending on more important and enjoyable things.

But, in a fit of optimism, I decided to give it a shot. After all, modern Linux distributions are pretty reliable, right? I'll just boot up and Ubuntu DVD, it'll run the installer for 15 minutes or so, and I'll have a working system. Right?

Well...not quite. Turns out Ubuntu didn't like my disk setup. Things went fine until it tried to install Grub and failed miserably. I'm not sure why - the error message the installer put up was uninformative. I assume it had something to do with the fact that I was installing to /dev/sdb and /dev/sda had an old Windows install on it. After a couple of tries, I decided to just crack open the case and swap the SATA cables, making my target drive /dev/sda, and call it a day. That did the trick and Ubuntu installed cleanly. I did have to update my BIOS settings before it would boot (apparently the BIOS didn't automatically detect the change of drives), but it worked fine.

The only real problem I had was that apparently Wayland doesn't work properly on my system. I tried several times to log into the defaut GNOME session and after a minute or two, system load spiked to the point that the GUI and even SSH sessions became unresponsive and eventually the GUI just died. And I mean died - it didn't even kick me back to the GDM login screen.

I suspect the problem is my system's archaic video card - an integrated Intel card from the 2010 era which I have absolutely no intention of ever upgrading. I mean, it apparently wasn't good enough to run Windows 10, so I wouldn't be surprised if Wayland had problems with it. But in any case, Ubuntu still supports X.org and switching to the GNOME X.org session worked just fine. I don't really intend to use the GUI on this system anyway, so it's not a big deal.

The restore

Once I got Ubuntu installed, it was on to step two of the process: getting my data drive set up. It's a 1TB drive that used to serve as the Windows install drive. It was divided into a couple of partitions, both formatted as NTFS. Since I'm switching to Linux and really just wanted one big data drive, this was a sub-optimal setup. Therefore I decided to just blow away the partition table and restore from a backup

I currently use CrashPlan to back up this computer. It's set to back up to both the cloud and a local USB hard drive. So my plan was to repartition the disk, install CrashPlan, and restore from the local hard drive.

This was fairly easy. Installing the CrashPlan client was the first task. There's no .deb package, but rather a .tgz that contains an installer script. It was actually pretty painless - just kick off the script and wait. It even installs its own copy of the JRE that doesn't conflict with the system version. Nice!

Next was actually restoring the data. Fortunately, CrashPlan has their process for restoring from a USB drive well documented, so there wasn't much to figure out. The process of connecting a particular backup dataset on the drive to the CrashPlan client was slightly confusing because the backup interface (as far as I can remember) doesn't really make it obvious that a USB drive can have more than one dataset. But it just boils down to picking the right directory, which is easy when you only have one choice.

The only surprise I ran into was that running the restore took a really long time (essentially all day) and created some duplicate data. My data drive contained several symlinks to other directories on the same drive and CrashPlan apparently doesn't handle that well - I ended up with two directories that had identical content. I'm not sure whether this was a result of having symlinks at all, or if it was just moving from Windows symlinks to Linux symlinks. In any case, it's slightly inconvenient, but not a big deal.

Other services

While the restore ran, I started setting up the system. Really, there were only a handful of packages cared about installing. Unfortunately for me, most of them are proprietary and therefore not in the APT repository. But the good news is that most of them were pretty easy to set up.

The first order of business, since this box is primarily a media server, was setting up Plex. This turned out to be as simple as installing the .deb package and firing up the UI to do the configuration. From there, I moved on to installing Subsonic. This was only marginally more difficult, as I also had to install the OpenJDK JRE to get it to run. I also followed the instructions here to make the service run as a user other than root, which seemed like not such a great idea.

The only thing I wanted to install that I couldn't get to work was TeamViewer. But this wasn't a deal-breaker, though, because the only reason I was using TeamViewer under Windows was because I was running the Windows 8.1 Home and was too cheap to pay for the upgrade to Professional just to get the RDP server. But since this is Ubuntu, there are other options. Obviously SSH is the tool of choice for command-line access and file transfers. For remote GUI access, I tried several variations on VNC, but it eventually became clear that xRDP was the best solution for me. It's not quite as straight-forward to get working, but this guide provides a nice step-by-step walk through. There are also a few caveats to using it, like the fact that the same user can't be logged in both locally and remotely, but those weren't big issues for my use case.

Results

For the most part, the transition has gone pretty smoothly. The setup didn't go quite as smoothly as it could have been, but it wasn't too bad. In any event, what I really cared about was getting Plex and Subsonic up and running and that was pretty painless. So I'm back to where I was originally, but on an up-to-date operating system, which is all I really wanted.

I discovered something enlightening and annoying this morning: PowerShell uses different execution policy settings for the 32-bit and 64-bit versions. This is something I did not know and did not expect.

I'd seen this problem before, but could never figure out what was happening. I'd try to run a command through PowerShell using another program, in this case Vim, and it would fail with the standard error about execution of my profile.ps1 being prohibited by the execution policy setting. Yet when I bring up Powershell on the command line, everything works and the execution policy looks correct:

PS pgeer> Get-ExecutionPolicy -List Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine RemoteSigned

Well, it turns out we're talking about two different versions of Powershell. When I run it from the terminal, I'm using the 64-bit version. But my Vim build is 32-bit, which apparently means that it's running the 32-bit version of Powershell. And that version uses its own execution policy setting. You can confirm that by explicitly opening "Windows Powershell (x86)" from the start menu and running Get-ExecutionPolicy.

As for the fix, it's simple: just run Set-ExecutionPolicy RemoteSigned as admin, but do it in both the x86 and x64 versions of Powershell.

As for why Microsoft chose to make the different builds use different execution policies, I couldn't say. It doesn't make much sense to me. Although, to be honest, I'm not sure why I even need both versions on the same system. Maybe to support interop between commandlets and unmanaged code? Who knows?

Tonight I finally got around to fixing my trackpad. Again.

So here's the thing: like most Windows-based laptops, my little Lenovo ultrabook has a trackpad with two "button" regions at the bottom. They're not separate physical buttons, but they act as the left- and right-click buttons. However, rather than force you to use the right-click pseudo-button, the Synaptics software the comes with the laptop lets you turn off the right-click button and use two-finger-click as the right-click, a la a MacBook Pro. I find this preferable, in particular because my laptop centers the trackpad under the space bar, rather than in the actual physical center of the unit, which means that when you're right-handed, it's easy to accidentally hit the right-click button when you didn't mean to.

Prior to upgrading to Windows 10, I had this all set up and it was fine. After the upgrade, not so much. Sure, the same options were still there, but the problem was the that option to turn off the right-click button did just that - it turned it completely off! So rather than clicking in that region doing a standard left-click, that part of the trackpad was just dead, which was even worse than the problem I was trying to fix.

Luckily, it turns out that the functionality is still there - the Synaptics people just need some better UX. I found the solution in this forum thread on Lenovo's site. It turns out you can just change the value of the registry key HKEY_CURRENT_USER\Software\Synaptics\SynTP\TouchPadPS2\ExButton4Action to 1, which is apparently the standard left-click action. By default, it's 2, but when you turn off the "Enable Secondary Corner Click" (i.e. right-click to open context menu) feature in the Synaptics UI, that gets changed to 0, which is apparently the "do nothing" action.

Long story short: my mouse is much better now.

It's upgrade time again. As I mentioned in my last entry, my desktop/home server had been getting short on disk space - and by "short on disk space," I mean I started to see Explorer reporting the free space as less than 1GB on my C: drive. So it was time for a new hard drive.

Since the only real problem was my 100GB C: partition, I decided to go with more of a "start over" approach and just got a modest 120GB SSD. My Windows 7 installation was about 5 years old, so it had accumulated a fair amount of cruft. For instance, the winsxs folder alone had swollen to almost 14GB. So I reasoned that a clean installation would probably fix most of my problems.

Along with the new hard drive, it was also time for some new software. I started that out with an OS upgrade from Windows 7 Pro to Windows 8.1. Yes, I know - everybody hates Windows 8. But I think it's a good OS, damn it! Sure, I'll grant you that the initial release had some rough edges, but aside from the questionable decision to remove the start menu (which is trivially fixed by installing Classic Start), the 8.1 update fixes every complaint I had.

As a change of pace, this time I decided to try the downloadable purchase of Windows 8.1 from NewEgg rather than waiting for physical media to ship. It turns out that this process is actually pretty simple. You place your order and then get an e-mail with a license key and a link to a downloader program. You run that, give it your key, and it gives you several options for downloading the installation files. One of these is to just download a bootable ISO image that you can burn to disk. So it's actually not as wierd as I initially feared. Of course, the one catch is that the downloader runs under Windows, so this probably doesn't work so well if you're a Mac or Linux user.

The one thing of note here is that this time I decided to save myself a few bucks and drop down from the Professional edition to the standard one. I made this decision after considering the non-transferability of the OEM version and looking at the feature comparison matrix. It turns out the the Pro versino contained exactly one feature that I cared about: the Remote Desktop Server. So I reasonsed that if I could find a suitable remote access solution to replace RDP, then there was no need to buy the Professional edition. And after playing around with TeamViewer for a few days, I decided I'd found that.

It turns out that TeamViewer actually works quite well. For starters, it's free for non-commercial use and it's in Ninite, so there's basically zero overhead to getting it set up. Registering for an account is also free and helpful, though not strictly necessary. The performance seems to be pretty good so far and it has the ability to start LAN-only connections or go through their servers for over-the-Internet access. After using TeamViewer for a couple of days, I was more than convinced that I could do without the Windows RPD server.

Next on the list was a service to run Virtual Box. As you may know, Virtual Box is a free system virtualization package. It works pretty well, but it doesn't come with the ability to run a VM on boot (at least in Windows) - you have to wait until you log in. To fix that, I installed VBoxVmService. This is a little Windows service that will run selected VMs on boot without anyone having to log in and also offers a systray app that allows you to manage those VMs. Previously, I had been using the similarly named VirualBoxService, which does essentilally the same thing but isn't quite as nice to use. Of course, there are some limitiations, but for the most part it works well enough for my setup. All I really wanted to do was have a Linux VM run on boot to serve as a web server because setting the stuff up on Windows was just too much of a pain.

While I was at it, I also decided to give Plex a try. I'd previously been a little turned off by the requirement to create an account, even though I only wanted to use it on my LAN, but it turns out that actually isn't necessary. The account registration is really only needed for remote access. And with Android and Roku apps, Plex provided more functionality and required less work than my home-grown solution of using PHP scripts to generate customized web server directory listings for Roksbox. That was all well and good, but just using Plex is much easier and seems to work better.

So far, things seem to be going pretty well and I'm happy with my new setup. Granted, there are no radical changes to my setup, but in my days of Linux on the desktop, painful upgrades were not always such an uncommon occurrence, so I guess I'm a little battle-scarred.

One last thing to note is that I'm actually kind of impressed with Windows 7. I days gone by, a Windows install lasting for 5 years of heavy use would be unheard of. And even with seriously limited hard drive space, the system was rock-solid and actually performed pretty well. If I'd been inclined to migrate it to the new drive, I probably could have kept that installation going for much longer. Switching back to Windows was definitely a good move.

This entry started out as a quick discussion of consolidating my photos onto Amazon Cloud Drive. However, that didn't happen. So now this entry is about why.

This started out as an attempt to clean up my hard drive. I have a 1TB hard drive in my desktop, divided into two partitions: 100GB for my system "C: drive" and the rest of it allocated to assorted data. The problem is that my C: drive was down to less than 5GB free, so it was time to do some clean-up.

Part of my problem was that my locally synced cloud storage was all in my home directory on the C: drive, including Cloud Drive. So the plan was to move my Cloud Drive folder to the D: drive and, in the process, move a bunch of my older photos into Cloud Drive. After all, I've complained about Cloud Drive, but now that Amazon offers unlimited photo storage to Prime members, why not take advantage of it?

Well, I'll tell you why - because it doesn't work, that's why. For starters, the desktop Cloud Drive app doesn't provide any way to set the local sync directory. Luckily, I did find that there's a registry key for that that you can set manually. So I did that, moved my Cloud Drive folder, and restarted the Cloud Drive app. And then I waited. And waited. And waited some more for Cloud Drive to upload the newly added photos. However, when I came back the next morning, the systray icon said that Cloud Drive was up to date, but when I looked at the website, my new photos weren't there.

OK, so plan B: try downloading the latest version of the Cloud Drive desktop app. My version was from March, so maybe there were somce improvements since then.

And here's problem number two: the new app isn't the same as the one I have. As far as I can tell Amazon no longer offers a desktop sync app. Now they just have a "downloader/uploader" app. It's not sync, though - the process is totally manual. And I can't find any link to the version I have. Presumably it's been replaced by this lame uploader app. I notice that the Cloud Drive website now omits any mention of sync and talks about accessing your data on your computer through the website.

OK, so no upgrade. Plan C: try to get the version I have working. That didn't work out, though. I didn't have the installer anymore, so reinstalling was out of the question. I tried deregistering the app and resyncing my cloud data, but now that was just broken. Cloud Drive synced part of my documents folder, then just stopped and reported that it was up-to-date.

At that point, I decided to just give up. I'd been thinking about switching to OneDrive anyway. It works well enough and fixes the problems I have with Cloud Drive. It also gives me 30GB of free storage and has pretty reasonable rates for upgrades - $2/month for 100GB or 1TB for $7/month including an Office 365 subscription. Plus I've already got it set up on my desktop, laptop, phone, and tablet, so it's just a matter of getting my data into it.

So that's what I did. I changed my OneDrive location to my D: drive by unlinking and relinking the app (which is required for Windows 7 - Windows 8.1 is much easier) and then moved over the pictures from my Cloud Drive as well as the old ones I wanted to consolidate. Hopefully that will work out. It's going to tak OneDrive a while to sync all that data - over 10GB - but it seems to be going well so far. And unlike Cloud Drive, as least OneDrive has a progress indicator so you can tell that something is actually happening.

As for Cloud Drive, I think I'm pretty much done with that. I'll probably keep the app on my phone, as it provides a convenient second backup of my photos and also integrates with my Kindle, but I'm not even going to try to actively manage the content anymore. It seems that Amazon is moving away from the desktop to an all-online kind of offering. That's all well and good, but it's not really what I'm looking for at the moment. Too bad.

Today I finally got fed up enough to fix the problem with fonts in XUL apps on my work desktop.

The problem and its solution are described in this post. Basically, in XUL-based apps like Firefox and Komodo, the text would randomly distort. It would usually happen when scrolling through a page or something like that that causes window redraws. If I scrolled some more, or selected some text, it would go away. And it only seems to happen on this particular system - my laptop doesn't seem affected.

Well, turns out it's a common issue. In my case, I was able to fix it by going into the "about:config" page and changing the gfx.direct2d.disabled setting to true and restarting the app. Turns out that while this page is well-known in Firefox, it's also available in Komodo. You just need use the "preview buffer in browser" tool from the toolbar. Just choose to preview the item in a Komodo tab and then enter "about:config" as the URL. That will take you to the exact same config page you see in Firefox.

I've discovered a small caveat to the technique for OSX-like trackpad behavior that I posted about the other week. I probably should have anticipated this - it seems fairly obvious in hindsight, but didn't seem so at the time.

It turns out that X-Mouse runs in a different user context than the Window UAC dialog. Who knew, huh? The upshot is that any button that's been configured with X-Mouse will revert to its default behavior in the UAC. In other words, you have to click the system-default "left button" to make the dialog work.

Not actually a huge deal, since your X-Mouse config comes back once the elevated process has been launched, but a bit weird.

So a couple of weeks ago I bought myself a new Ultrabook - a Lenovo IdeaPad U310. I've been used to using a MacBook Pro for work and I wanted something with a similar form-factor, but that didn't cost $1300, have an unnecessarily weird keyboard, and run OSX. The IdeaPaf U310 was fairly cheap and seemed like it would fit the bill.

For the most part, I'm pretty happy with it so far. I even like Windows 8.1 well enough (after installing Classic Start Menu, that is). There are only two parts that I'm not crazy about:

The viewing angle of the screen is pretty limited.
The trackpad is harder to use than on a Mac.

While there's obviously not much to be done about the first complaint, I figured the second one could be remedied in software.

Background

Now, the actual problem here is not with the physical trackpad - that works well enough. It's with the click handling. If you're not familiar with a MacBook trackpad, it has no "buttons" as you customarily see on PC trackpads. Rather, you can just press down (as opposed to "tapping") on the trackpad with one finger to "click" - the pad actually gets depressed a bit and makes an audible clicking sound. To do a right-click (or command-click in Mac speak), you just press down with two fingers. It's a little unintuitive at first, but you get used to it and it works pretty well.

The Lenovo IdeaPad, however, doesn't quite do that. It still uses the same "press to click" mechanism, and you can still press with two fingers to double-click. However, it also has two "virtual buttons" at the bottom of the track pad. There's just a small vertical line, about half an inch long, at the bottom-center of the track pad that. You press on the left of that line to left-click and on the right of it to right-click. Even simpler than the Mac. And, in fact, when using a Mac I'd often wished it had something like that.

Problem is, that doesn't actually work out so well all the time. Because there's no tactile feedback as to whether your finger is over the left-click or right click button, it's very easy to accidentally click the wrong one. This is especially the case if you're using the laptop on your lap and so end up with your hand coming at the trackpad from one side.

The Fix

So my solution to this was to try and change the behavior to work like a Mac - that is, make both virtual buttons left-click and use two fingers to right-click. Seems simple enough, but the Synaptics trackpad software that came with the laptop - which is actually quite good and contains a surprising number of options - doesn't support that. The only option it has for the primary buttons is to swap them, which doesn't help.

However, I did find a solution that uses Synaptics in conjunction with X-Mouse Button Control, a little third-party freeware app that lets you remap mouse buttons if various sophisticated ways.

In the Synaptics settings, I configured the "Two-Finger Click" action to "Middle Click". (It doesn't have to be "Middle Click" in particular, just something other than right-click that X-Mouse can recognize.)
I installed X-Mouse and configured it to set the "Right Button" action to "Left Click" and the "Middle Button" action to "Right Click".

So far this configuration is working pretty well. It's not ideal perfect - two-finger clicking on the left-click button doesn't trigger a right click. However, it does prevent those accidental right-clicks, which is what was really bothering me.

This is just another "note to self" post, so that I have something to refer back to later when I forget this again. Nothing to see here - move along.

Without further ado, here's a link for how to configure ISC BIND on Windows. This should have roughly the important details, with the exception of file locations. Per the company guide, I have my BIND files in C:\Windows\System32\dns. Note that this is restricted to admin accounts, so it won't show up in explorer with my regular account. I lost 15 minutes figuring that out the other day. Also, here's a link on the managed-keys-zone error I was getting in the event log. That turned out to be the fix for my problem where BIND was starting, but DNS queries weren't working.

If you're not me and you're still reading this, the motivation for this post was configuring a new development VM for work on my home Windows box. Normally, we're a Mac shop, and the company provides MacBooks for anyone who requests a computer. However, mine broke down and is in the shop, so I had to set up my Windows box with the development environment.

There are just two problems here:
1) Our codebase, despite being PHP running on a Linux VM, is actively Windows-hostile.
2) We require wildcard DNS for subdomains.

The use of BIND is to address the second problem. For the occasions when someone tries to run the VM on Windows, BIND is used to send the DNS queries for our development domain to the VM. Of course, we could just set the Windows DNS server to the VM itself, but that has the down side that your DNS breaks when you shut off the VM.

And if you're curious about the first problem, all you need to know is that our codebase is full of directories named "v.", which is just fine on UNIX-based systems, but is an invalid directory name on Windows. There's a good reason for that - trust me - but it's too long to explain without the relevant context. (Of course, there's no reason that it has to be "v." - the guys who came up with that could have just used a different naming convention. But they didn't, and now we're stuck with it.)

Note to self: just because Powershell defines aliases that mimic many of the standard UNIX commands does not mean they function the same way.

Last night, I was trying to migrate my company's Subversion repository to Mercurial - not for production use (yet), just as an experiment. After eventually getting the latest Mercurial installed on the Ubuntu 8.04 VM that hosts our Subversion repository, I tried running hg convert -s svn /path/to/svn/repo /path/to/hg/repo. As expected, the conversion process took some time, but chugged along nicely...for a while. Eventually, it hit an error and came back with:
svn: In file '/build/buildd/subversion-1.6.9dfsg/subversion/libsvn_ra/ra_loader.c' line 595: assertion failed (*path != '/')

I Googled around a bit, but still have no idea what that error message means or how to fix it. My best guess is that something is borked in our repo - not broken enough to break SVN, but maybeSo I tried a different tack - take the repository dump I had, import it into a fresh repository, and try again. That didn't go so well....

Since the SVN VM has a very small drive, I decided to load the dumpfile on my local Windows box. As you may know, svnadmin load reads streams, so you have to either pipe the dump file in or redirect standard input. Well, my first instinct was to do something like this:
svnadmin load newrepos < dumpfile.repo
One problem with that: the "<" character that you normally use for redirecting STDIN is reserved in Powershell. Drat! So I figured I'd just use a pipe instead:
cat dumpfile.repo | svnadmin load newrepos
So I ran that and waited. And shortly after I started waiting, I noticed my system slowing down. And then things started grinding to a halt - it was just barely responding. When I finally managed to get resmon up, I noticed that Powershell was eating nearly all of my system's RAM! And the command still hadn't produced a single line of output!

I'm not sure exactly what Powershell was doing, but it must have something to do with the Get-Content commandlet (for which "cat" is an alias) not liking the 1.4 GB dump file. Why it would use up more than twice the size of the file in memory, I'm not sure.

Anyway, I just switched to cmd.exe and did the input redirection method, which didn't eat huge amounts of memory. However, it didn't work either. The import died shortly after starting with an error about a bad transaction. Looks like the gods of revision control are not smiling on me today.

I sometimes forget that UNIXy things aren't as easy on Windows.

Today I spent way too long trying to figure out why PHP file uploads weren't working on IIS 7. First, I was getting permission denied messages on "C:\Windows\Temp". OK, that's fine, we'll just change upload_tmp_dir to something else, say "C:\Inetpub\wwwroot\uploads".

So I change that in my php.ini and restarted IIS. The result? Same permission denied message on "C:\Windows\Temp". Hmm.... Apparently, according to the docs, if you don't have write permissions on the upload_tmp_dir, PHP falls back to the system default. So I checked the permissions - IIS_IUSERS has read/write permissions. Apparently that's not good enough. I ended up adding write permissions for the "Users" group, which didn't sit well, but worked. However, after I removed write permissions for that group, just to check if that was the fix, it still worked. (Edit: Apparently it actually didn't work after that. Man, I really must have been out of it last night.)

So now, uploads work, but I have no idea what's going on or what the proper ACLs are. It's probably just too late and I need to go to bed. But for future reference, make sure to change the permissions on Windows when working with uploads.

In honor of Raymond Chen, it's link clearance time! This one is devoted to Windows utilities I've discovered over the last few weeks.

First up is the Elevation PowerToys. This is just a bunch of scripts related to privilege elevation. In particular, I like the "elevate" command included with this. It's kind of like sudo for UAC - you use it to elevate to admin with a UAC prompt rather than having to use runas.

Next is Shell Link Extension. As the name suggests, this is just a shell extension for creating symlinks and hardlinks. It's a bit rough around the edges, but it's nice not to have to drop down to a cmd.exe prompt.

On a more eye-candy note, I recently discovered PuttyTray, an improved version of PuTTY. It includes systray integration and supports configurable window transparency. The eye-candy support is fairly limited compared to the options available in the UNIX world (how many configuration options did aterm have just related to transparency?), but overall it's not too bad.

Similarly, I also just discovered PowerShell Glass. Basically, it's just a utility to enable Aero glass in PowerShell terminals, rendering the window transparent. While it's a nice idea, it doesn't seem to work that well. Sure, the window turns transparent, but I can't read what's in it half the time. The text and background coloring isn't quite right and isn't configurable to any great degree, so depending on what's behind your terminal window, it can be very hard to read.

Edit: Apparently I spoke too soon on the PSGlass colors. I Googled it yesterday and noticed a comment that the transparency seems to work best with the dark blue Aero color scheme. So I tried changing my color scheme and, lo and behold, it worked. Turns out I had my desktop set to the "frost" scheme, which looks like it's probably the worst possible setting for PSGlass. The "twilight" (dark blue) setting does seem to be the most readable, but it's a little too blue for my taste. I ended up settling on "slate", which still gives you readable text when the window is active, but is a little less "in your face" color-wise.

As previously mentioned, since switching my desktop to Windows, I've set up a Subversion service using SlikSVN and an SSH service using Cygwin. So this week, I figured I'd try getting them to play together so that I can do Subversion over SSH and not have to open up another port in my firewall. It eventually worked out, but wasn't as painless and it should have been. And it was totally my fault.

As you know if you've ever used Subversion over SSH, it's pretty simple. You just change your protocol, point SVN to the repository on the remote server, and supply your OS login credentials. So, since I already had an account set up on the server and svnserve running, I figured this should work:
svn ls svn+ssh://myuser@myserver/myproject
But no dice - I got the message "svn: No repository found in 'svn+ssh://myuser@myserver/myproject'"

Hmm..... Time to Google.... Oh, that's right - you can't use the root directory supplied to svnserve over SSH! Instead, you have to supply the full path to the repository and project. But wait - my repository is on the D: drive...so how do you reference that? Well, SSH is running on Cygwin, so we can use Cygwin's drive mapping. So change that command to:
svn ls svn+ssh://myuser@myserver/cygdrive/d/myrepos/myproject
That should work, right?

Yeah...not so much. That definitely should work, but I'm still getting that "no repository found" message. So what's the deal?

A little searching revealed that, behind the scenes, the svn+ssh:// protocol runs a command similar to this:
ssh myserver svnserve -t
Turns out that the problem was in that command.

See, the svnserve portion runs on the Subversion server, which, in this case, is inside Cygwin on a Windows box. However, I have two copies of svnserve - one from Cygwin and one from SlikSVN, and they don't both work the same way.

For SVN+SSH to work, I need to pass the repository path in with the Cygwin path mapping, and SlikSVN doesn't understand that. Thus the need for Cygwin's SVN. However, SlikSVN is first in my path when I connect via SSH, so it's SlikSVN's svnserve that's getting run inside Cygwin. Hence the "no repository found" message.

After a bit of experimentation, it turns out that this is really easy to fix. All you need to do is set the PATH in your Cygwin .bashrc file to explicitly put the Cygwin binaries first. Just add the following line to the end of the file:
export PATH=/bin/:/usr/bin/:/usr/local/bin/:$PATH

So, problem solved. Unfortunately, it took a lot longer than I would have thought, mainly because I couldn't find anyone else who had the same problem. So hopefully anyone else who's crazy enough to set things up this way will come across this post if they have any problems.

I've been catching up on some of my back episodes of .NET Rocks the past couple of days. I'm currently about 3 months behind on my podcasts, so I've got plenty to listen to.

Anyway, I was listening to show 537 with James Kovacs at the gym this morning, and he mentioned something interesting toward the end. When asked what he's been into lately, he said he'd been playing with Vim. Imagine that - a hard-core Microsoft guy playing with Vim. That just gives me a good feeling.

I've always been frustrated by how people in the Windows world seem to think "text editor" equals "Windows Notepad". Even experienced people. You always hear them refer to opening something in Notepad, or typing things into Notepad, etc. This from people who've been in the business for 10, 15, or even 20 or more years! I mean, they must be aware that there are better editors out there. Is "notepad" just used as a generic term, a shorter version of "text editor"? I wish somebody would explain that to me.

But getting back to the topic, it was nice to see James mention Vim. Despite Carl's and Richard's comments about VI being an antique, Vim really is remarkably powerful. Granted, it takes some effort to learn, but once you've got it down, you can do some pretty complicated stuff in just a couple of keystrokes. It's always nice to see that MS A-listers can recognize the power of tools like Vim, and not just us transplanted UNIX geeks.

There was one annoying side-effect of installing the Cygwin SSH server - I had to create an account for it. Not that this is inherently a problem, but I noticed that the new "Privileged service" account showed up on the login screen. That needed to go.

Turns out that hiding an account in Windows 7 is actually pretty easy. Just a simple registry entry - create a DWORD with the name of the user to hide and value zero under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" - and you're all set. Nice to know.

Yeah.... So remember how I was messing with freeSSHd last weekend? I'm thinking that was a waste of time.

While the native shell thing in freeSSHd was cool, I had two big issues with it. First, the terminal was buggy. I got lots of weird screen artifacts when I connected to it - the screen not clearing properly, weird random characters hanging around after a lot of output, etc. Not the rock-solid terminal experience I'm used to.

The second thing was something that occurred to me after trying out a couple of SSH sessions. If freeSSHd is using a native shell, with native file paths, how is that going to work with SCP and SFTP? How does it account for drive letters and path delimiters? Turns out the answer (at least for SFTP) was restricting access to a certain pre-defined directory ($HOME by default). For SCP...well, I still haven't figured out how that's supposed to work. But either way, this is decidedly not the behavior I was looking for.

So instead, I decided to go the old-fashioned way and just install Cygwin and use their OpenSSH server. And you know what? It was completely painless. I just used this handy LifeHacker entry to get the auto-config command and the necessary settings, and I was done. I started the service, connected to the SSH server, and all my stuff was right where it was supposed to be. I have a solid, familiar terminal, access to my whole system via SCP and SFTP, and NT authentication worked out of the box. Heck, the hardest part was figuring out the funky non-standard UI of the installer's package selection dialog. I should have just used Cygwin from the beginning and saved myself some effort.

Well, after my dismal failure yesterday, I mostly got FreeSSHd working. Not sure if it was worth the effort or not, but we'll see.

Turns out the problem was with my expectations. Or maybe I can blame it on the (extremely) minimal documentation. You see, I said "yes" when asked if I wanted to run freeSSHd as a Windows service. Now, I figured that starting the freeSSHd program in the start menu while the service was running would allow me to configure that service and view its status. Yeah...not so much. Apparently running the config program actually tries to start another instance of freeSSHd. Hence why I was getting errors that the the port was in use. It was already being used by the service and I was unwittingly trying to spawn another instance.

It turns out that to configure the service, I need to start the config program, do my stuff, close the config program, and restart the service. At least, that seemed to do the trick - I'm not actually sure how much of it was necessary. After that, freeSSHd ran quite nicely.

My one remaining problem was authentication. I wanted to use NT authentication, which freeSSHd gives as an option. The problem was, it didn't quite work. After creating a user and setting it to NT authentication, I was able to log in...and that's it. I connected with Putty, entered my password, and freeSSHd immediately disconnected me. No warnings, no errors, nothing in the logs - just immediate disconnection.

The really odd thing was that NT authentication worked just fine if I ran freeSSHd by starting the config program rather than as a service. Running it as service, though, disconnected every time. The only time it didn't was when I disabled the "new console" option. Then the session would just hang and not accept input, which wasn't an improvement. I tried various settings and Googled fruitlessly, but no luck. I still have no idea what was going on. After mucking about with this for probably an hour and a half, I finally gave up and changed my freeSSHd user to use a SHA1 hashed password. That worked just fine, but feels like defeat.

The one thing I do like about freeSSHd so far is that it allows you to select your command shell. You actually get a native Windows shell instead of being forced into Cygwin weirdness. I changed mine from the default cmd.exe to PowerShell. That should make for a more pleasant experience.

Well, I did my Windows 7 install the other day. One day later, I'm doing pretty well. Ran into some problems, but so far the results are not bad.

Unsurprisingly, the actual install of Windows 7 was pretty uneventful. Pretty much the same as a typical Ubuntu installation - selecting partition, entering user info, clicking "next" a few times, etc. Nothing to report there.

The initial installation of my core programs was pretty easy too, thanks to Ninite. They have a nifty little service that allows you to download a customized installer that will do a silent install of any of a selected list of free (as in beer) programs. So I was able to go to a web page, check off Opera, Thunderbird, Media Monkey, the GIMP, Open Office, etc., download a single installer, and just wait while it downloaded and installed each program. Not quite apt-get, but pretty nice.

My first hang-up occurred when installing the Ext2IFS. Turns out that the installer won't run in Windows 7. You need to set it to run in Windows Server 2008 compatibility mode. And even after that, it was a little dodgy. It didn't correctly map my media drive to a letter on boot. It worked when I manually assigned a drive letter in the configuration dialog, but didn't happen automatically. It was also doing weird things when I tried to copy some backed-up data from my external EXT3-formatted USB drive back to my new NTFS partition. Apparently something between Ext2IFS and Win7 doesn't like it when you try to copy a few dozen GB of data in 20K files from EXT3 to NTFS over USB. (Actually, now that I write that, it seems less surprising.) The copy would start analyzing/counting the files, and then just die - no error, no nothing. I finally had to just boot from the Ubuntu live CD and copy the data from Linux. Still not sure why that was necessary.

I also had some interesting issues trying to install an SSH server. I initially tried FreeSSHD, which seemed to be the best reviewed free server. The installation was easy and the configuration tool was nice. The only problem was, I couldn't get it to work. And I mean, at all. Oh, sure, the telnet server worked, but not the SSH server. When set to listen on all interfaces, it kept complaining that the interface and/or port was already in use when I tried to start the SSH server. When bound to a specific IP, it gave me a generic access error (literally - the error message said it was a generic error).

After messing around fruitlessly with that for an hour or so, I gave up and switched to the MobaSSH server. This one is based on Cygwin. It's a commercial product with a limited home version and didn't have quite as nice an admin interface, but seems to work sell enough so far. The one caveat was that I did need to manually open port 22 in the Windows firewall for this to work.

The biggest problem so far was with setting up Subversion. Oh, installing SlikSVN was dead simple. The problem was setting up svnserve to run as a service. There were some good instructions in the TortiseSVN docs, but the only worked on the local host. I could do an svn ls <URL> on the local machine, but when I tried it from my laptop, the connection was denied. So I tried messing with the firewall settings, but to no effect. I even turned off the Windows firewall altogether, but it still didn't work - the connection was still actively denied.

I started looking for alternative explanations when I ran netstat -anp tcp and realized that nothing was listening on port 3690. After a little alternative Googling, I stumbled on to this page which gave me my solution. Apparently, the default mode for svnserve on Windows, starting with Vista, is to listen for IPv6 connections. If you want IPv4, you have to explicitly start svnserve with the option --listen-host 0.0.0.0. Adding that to the command for the svnserve service did the trick.

The last week or so, I've been going back and forth over what to run as the primary OS on my upgraded home desktop. Right now I'm running Ubuntu 10.04 on it, but I keep thinking maybe I should switch to Windows 7. I'm using it to run Win7 under VMWare anyway, so I'm wondering if I should just invert the arrangement and run Ubuntu under VMWare instead.

So to help myself decide, I'm going to list out some of the various pros and cons. Of course, this is just for my case - this is not universally applicable, your mileage may vary, etc. I'm basing this list on my usage patterns over the last 2 year, since I started running Windows on some of my personal (i.e. non-company) machines again.

Every-day desktop software

This is obviously one of the biggest categories, and one of the reasons I'm leaning toward Windows 7 in the first place. For my every-day non-development desktop computing needs, I need the following tools:

Web browser
E-mail client (no, I don't want to use a web client, even if it's GMail)
Desktop RSS aggregator with multi-system syncing (no, I don't particularly like Google reader, except as a back-end)
Multi-format universal video player
Music player/manager
Podcatcher
Comic book reader

For items 1, 2, and 4, I already have favorite apps that are cross-platform - Opera, Thunderbird, and VLC. So those requirements are a wash.

Pro-Windows

On Windows, I'm currently using FeedDemon for RSS and MediaMonkey for music, and I quite like both of them.

On Linux, I don't have favorite apps for those. Recently, I've been using Exaile for music, but I'm not particularly attached to it. I just haven't found anything good since Amarok 2 came out (which I absolutely hate, despite really liking Amarok 1.x). As for an RSS reader, I've tried Liferea, but didn't particularly care for it. Mostly I've been either reading my feeds on a Windows box or just using Google reader, which I'm not crazy about.

Pro-Linux

On the Linux side, I do have a favorite comic reader an podcatcher: ComiX and gPodder respectively. However, I don't think either of them are really irreplaceable. While I don't have any complaints about gPodder, my podcatching needs are fairly basic - download and transfer to my MP3 player. I have a feeling the podcasting features of MediaMonkey would be just fine for this. The same is probably true of ComiX - I don't really need any complicated management features, just a good viewer for comic archives. I've played with a few other comic readers, and there are probably several that could do the job. For instance, HoneyView seems like it would fit my needs quite well.

Verdict: I have to go with Windows on this point. Most of the every-day stuff I really care about is either cross-platform or Windows-only, while I'm not really so attached to my current Linux tools.

Development tools

The development tools are a little different from the every-day tools. In part because, in many cases, there isn't really much of a choice. In the case of things like language-specific IDEs, you either use a particular tool and just use whatever platform it's supported on, or you make things waaaaay harder on yourself than they need to be. In other words, if you want to be idealistic in your platform choice, you suffer for it.

In my case, I'm currently doing mostly LAMP and FLEX work, and want to get into more .NET stuff on the side. That means that I need not only the IDEs and development tools, but also the supporting servers for those environments. I also need good command-line and scripting utilities as well as a good desktop virtualization package.

Currently, I favor Komodo Edit and gVim for PHP, Python, and other general-purpose coding, with a little Eclipse mixed in on occasion. Both of those are cross-platform, as are PHP and Python. For supporting servers, I also need MySQL, PostgreSQL, SQLite (more of a library than a server, but I'll list it with the other databases), and Apache, all of which are also cross-platform. So in terms of what I can use, it's a wash on all of that.

Pro-Linux

However, while most (if not all) of the LAMP stack runs on Windows, it's kind of a second-class citizen. In my experience, it's much easier to install and administer this stuff on Linux. Of course, that could just be because I'm more familiar with them on Linux, but that's not really the point.

In addition, Linux gets some points for the command-line. Granted, now that Powershell has come along it's not nearly as many as Linux used to get, but it still wins on ease of installing packages and having things like FFMPEG.

Pro-Windows

Obviously, Windows wins on everything dot-NET. IIS, Visual Studio, SQL Server - all of them are Windows-only and must-haves for anyone wanting to do "professional" .NET work, by which I mean work that "counts" on your resume. (No, Mono with MySQL isn't good enough, unfair as that may be.) It also wins on the FLEX front. While the FLEX SDK is cross-platform and runs on Linux, the IDE, Flash Builder, only runs on Windows and Mac. It's Eclipse-based, so you'd think it'd run on Linux, but it doesn't. Don't ask me why.

Windows also gets a small win on virtualization. Mostly, I use VMWare, plus a bit of VirtualBox, both of which are cross-platform. However, anybody who ever has to do IE compatibility testing will tell you how handy VirtualPC is. Not in and of itself, but rather because Microsoft puts out pre-configured images for testing IE 6 and 7. Just download, extract, and run - no hunting down copies of Windows with the appropriate IE version. Granted, it's annoying that the Windows installs on those images expire every few months, but they're still useful.

Verdict: I think I have to give Windows the edge on this one too, much as it pains me. I just need the Windows-only tools, and it's easier to run the resource-sucking ones like Visual Studio and Eclipse natively than in a VM. And as for the LAMP server tools, I can easily set up an Ubuntu server VM to run in the background without assigning it too many resources.

Remote access

I've gotten very used to being able to access my home desktop from anywhere. Therefore, I need some kind of secure, easy to use method for connecting to it. I also need it to be something I can set up on someone else's computer in 5 minutes without admin access. I do use Opera Unite for some of this, but that doesn't cover everything - I want something a little more robust and general purpose.

Pro-Linux

Let's face it - SSH rocks. There's just no getting around it. It's secure, simple to install, simple to set up, and simple to use. Also, it gets you full access to the command line, which is pretty powerful. I also tunnel VNC over SSH for nice, easy graphical access to my machine.

Pro-Windows

Let's face it - Remote Desktop beats the pants off of VNC. I mean, it's not even close. Granted, VNC is cross-platform, but RDP offers more features and it's a lot faster.

Also, there are SSH servers available for Windows. They're not as "native" as SSHD under Linux, but they still offer remote command-line shell (usually based on Cygwin, so it's Linux-like) as well as SCP and SFTP.

Verdict: It's pretty much a draw on this one. The SSH support for Linux is better, but Windows has some SSH and better remote graphical capabilities.

Inertia

When switching platforms, you need to account for overcoming the inertia of your current environment. That means coming up with new tools, new customizations, new data organization, etc.

Pro-Linux

Eight years is a long time. That's about how long I've been running Linux exclusively on my home desktop. I've been building up my environment since the bad-old-days when Netscape Navigator 4 was the best browser available and you had to recompile your kernel if you wanted to use a CD burner. I have scripts that won't run on Windows, symlinked configurations that won't work on Windows, and, or course, lots of things organized in a very UNIXy way.

Pro-Windows

The nice thing about Windows 7, as opposed to previous versions, is that it's a bit easier to organize things in a UNIXy fashion. Plus, there's always Cygwin and so forth. But really, there's not much to say here. The only saving grace here is that most of my existing Linux investment isn't irreplaceable.

Verdict: Linux, obviously. But while the margin is pretty good, it's not overwhelming. I don't do that much in the way of heavy customization anymore, so it's actually not as big an issue as it would have been a few years ago.

Final Verdict

Well, I'd say it's pretty obvious at this point. The preponderance of the pros seems to be on the Windows side.

On the one hand, the idea of this transition makes me a little uncomfortable. I've been a Linux user for a long time, and will continue to be one on the server-side. But at the same time, the more I think about it, the more sense this transition makes. While I'm still a Linux fan, I've grown less concerned with the desktop side of it. These days I'm more interested in things "just working" than in twiddling with my desktop or finding free software to do something I could as easily do with freeware. By the same token, distance has dulled any animosity I may have harbored toward Windows.

So we'll see how it goes. I actually installed Win7 on my desktop yesterday afternoon (I started this entry a week ago - just didn't get around to posting it). I'll be posting updates on my difficulties and migration issues. Hopefully it will be a pretty smooth process.

Ah, Raymond Chen. You can always count on him for a good tip stated in a way that makes it seem blindingly obvious.

The other day I got a couple of good tips from his blog. While writing a simple batch script to wrap up executing some Selenium RC test cases, I had the need to change to another directory and then change back. A little Googling led me to this page, where Raymond expounds on the eminently useful %CD% environment variable, which stores the current directory. (Of course, I ended up just using pushd and popd, which I'd forgotten Windows had, but that's not the point.)

On the same page, Raymond links to a handy little 90-byte batch script that does the equivalent of the UNIX which command. I thought that was really great. In fact, that's something I've always wanted. I've got the UnxUtils, which includes a Windows port of which, but it's just not the same, because it requires you to specify the file extension. I'm not much of a batch scripter, so I never would have thought to even try doing that in a batch file. Go Raymond!

Well, the new year is upon us, we have a new president, and the economy is in the toilet. So I figure this is as good a time as any to try something new. That's why I'm switching to Windows.

Of course, I'm not switching switching. My home desktop is still running Kubuntu 8.04 and will be for the foreseeable future. However, a couple of weekends ago I burned a System Rescue CD, shrank the Kubuntu partition on my laptop, and set it up to dual-boot Windows XP. I also resurrected the long-dormant Windows partition on my PC at work. I'm still keeping Kubuntu around on both systems (at least for now), but I'm making an effort to actively use Windows more often than not.

There are a number of reasons for this. For one, I've been getting a little fed up with Linux lately, especially after the last Kubuntu upgrade. I'm thoroughly unimpressed with KDE 4, I'm getting tired of things crashing randomly under KDE 3, and I find that I just don't use or want to use much Linux-specific software anymore. It's also been a while since I felt really connected to the community and I was never really a "true believer" in Free Software or the power of Open Source in the first place. So I just feel like I don't have as much of an anchor in the Linux world anymore, despite using it every day.

The Windows world, on the other hand, seems to have a lot to recommend it these days. For instance:

It's the native platform for .NET. I did a little .NET work at my last job and quite liked it. I've been wanting to get deeper into .NET and C# for a while now and using Windows will allow me to do that more easily.
Yes, I know Linux has Mono, and that's all well and good. But let's face it - it's just not the same. For one thing, Mono isn't as complete as Microsoft's runtime. For another, the tooling just isn't there - MonoDevelop is a fine IDE, but it can't hold a candle to SharpDevelop, let alone Visual Studio. And, of course, Mono isn't as marketable, as most of the companies looking for .NET developers are working on Windows.
Powershell. I've been wanting to try out PowerShell for a while. I keep hearing about it on .NET Rocks and RunAs Radio and it seems really cool. Again, there is a Mono port (called PASH) in the works, but it appears to be only about half done, whereas PowerShell on Windows is pretty much mainstream now.
It has everything I need and more. I don't remember where or when, but within the last few months, I came to a realization: pertty much all the software I care about runs on Windows. Granted, there are a many programs I use on a regular basis that are UNIX-only, but all the stuff I really need is cross-platform: Opera, Firefox, Komodo Edit, Vim, PHP, Python, Apache, MySQL, PostgreSQL, etc. There are even Windows ports of most of the common UNIX utilities (awk, sed, grep, etc.), not to mention Cygwin. As for the things that don't run on Windows...well, I found I'm just not all that attached to those programs, and there are Windows programs that do the equivalent anyway. So really, even with switching to Windows, my toolset doesn't change that much.
It's just more marketable. Let's face it - the economy is bad and I haven't the money or the inclination to move to where the jobs are. In other words, if I wanted to live in New York City or California, I wouldn't be working in Rochester right now. So it makes sense for me to develop my skills in a direction that's in demand in my area.

From the online research I've done, Java and .NET seem to be the most in demand in the Rochester area. Java may be bigger, but the fact is that I know jack about Java, whereas I have some experience with VB.NET and C#, so that seems like a more viable path. By contrast, there's usually only a handful of PHP jobs available, and apparently PHP developers are a dime a dozen anyway. And despite all the hype, I've only ever seen 1 Ruby job available within 50 miles of my house.

So off I go on this new adventure. Hopefully it will all go well and I'll emerge a happy and productive .NET developer. The only problem is I might have to change the name of this blog.

Well, I feel stupid. I just finally got syntax highlighting for PowerShell to work in Vim. I did a little Googling and found my solution in the PDF document linked form this article. Why you need an 8 page PDF to explain this is a completely different issue.

Turns out I was just missing some lines in my filetype.vim file. I already had the syntax, indent, and file type plugins, I just didn't think to add the code to activate them (for some reason I thought that stuff was loaded dynamically). However, page 6 of that PDF gave the answer:
" Powershell au BufNewFile,BufRead *.ps1,*.psc1 setf ps1
I just added those lines to my filetype.vim, below the corresponding entries for Povray files, and voilà! Syntax highlighting now works.

Here's a quick and useful tactic for dealing with file attributes on FAT32 drives. I got the idea from this post on the Ubuntu blog

My new MP3 player (which I'll be blogging about when I have more time) uses a FAT32 filesystem. I needed to change the attributes on some of file attributes so that it would show the media folders but hide the system folders. Why I needed to do that is another story. Anyway, the point is that there was no obvious way to do this from Linux and since charging the MP3 player seems to reset these attributes, I didn't want to have to rely on a Windows machine being handy.

After way more Googling than I thought necessary, I discovered that you can do this with good old mtools. The really old-school people in the audience will probably remember them from the days when floppy disks were still in common use. Well, it turns out that they can be used with USB mass storage devices too.

The first step, after installing mtools of course, is to set up a drive letter for your USB device in your ~/.mtoolsrc file. This can be done by adding something like the following:
drive s: file="/dev/sdb1" mtools_skip_check=1
The first line associates the S: drive letter with the device file for my player. The mtools_skip_check line suppresses errors which, I believe, arise from the fact that this is a USB device, not an actual floppy disk. Either that, or there's something about the FAT that mtools doesn't like, but can still work with.

Once that's set up, I was able to simply use mattrib to change the file attributes and [cdoe]mdir[/code] to show the attribute-sensitive directory listing. The actual commands look something like this:
mdir S: mattrib +h S:/TMP mattrib -h S:/MUSIC
Note the use of the S: drive letter to prefix paths on the root of the device. The +h and -h flags turn the hidden attribute on and off respectively. Also note that you can have the device mounted while doing this - mtools doesn't need exclusive access as far as I know.

Eventually, I'll be scripting this so that I can (hopefully) run it automatically after charging my player. Ideally, that script would include some HAL or udev magic to detect the dynamically assigned device node and add that to the mtoolsrc file. When I get around to writing that, I'll post the result.

It's time for another tale of IT pain. You remember CRAPS, the pathological police system we're required to use? Well, it struck again.

Today I had to travel to a nearby police agency to assist them with their CRAPS installation. They were having problems with the data transfer between the field units and the office. This is normally accomplished via a removable USB drive. In order to ease this procedure, CRAPS includes a feature to automate the copying of data files to and from the USB drive. Basically, the user clicks a button and the data files get compressed and moved in the appropriate direction.

The problem with this feature is that it's not very friendly from a configuration point of view. You see, CRAPS doesn't actually know anything about USB drives. It just knows about paths, and they're configured statically. So you actually have to tell the software, "use drive F: for the data transfer."

What's worse, CRAPS isn't even very smart about handling paths. As you probably know, when Windows detects a USB mass storage device, it assigns it the next available drive letter, so you can't depend on the same devince getting the same letter every time. However, CRAPS requires that a CRAPS administrator configure the drive letter ahead of time and it cannot be changed by a regular user. So the user ends up with, for example, a drive with multiple partitions, he can't use it until an administrator can reconfigure his system. Which sucks.

The first problem today was that CRAPS can't even join paths properly. We were having problems with the data transfer feature mysteriously failing on a couple of workstations. The USB drive path was correctly set to E: in CRAPS. However, just on a lark, because I know how cranky CRAPS can be, I tried chaning it to E:\. And you know what? It worked. *THWACK* (That's the sound of me smacking myself in the head.)

My second problem was partly Windows, partly the fact that I didn't set up this other agency's network. You see, on one workstation, the USB drive was being mapped to F:, but the primary network share was also being mapped to F:. The result? The network share clobbers the USB device and you can't access the USB drive until the network share is disconnected.

This is a fairly well known problem. As I understand it, the cause is that drive mapping is done on a per-user basis, and while network shares are mapped by the user, USB drives are mapped by a system account. There are a number of possible fixes, of course, but they all kind of suck - especially if you don't have any significant ownership over the system you're working on.

Nothing is ever as easy as it should be. Which is why "IT land" sucks.

I know there are those in the Linux community who will regard this as equivalent to spitting on the cross while blaspheming the holy spirit, but sometimes I feel sorry for the people at Microsoft. They have a tough job and they are frequently blamed for things that aren't their fault.

What made me think of this was Jeff Atwood's follow-up to his Windows spyware post.

I understand the pressure to be backwards compatible. There's no end of Vista blowback based on minor driver compatibility issues. The "if it doesn't work, it's automatically Microsoft's fault, even if the software or hardware vendor is clearly to blame" mentality is sadly all too common. But given the massive ongoing Windows security epidemic, was defaulting regular users to Administrator accounts-- exactly like Windows XP, Windows 2000, and Windows NT before it-- really the right decision to make?

In many ways, Microsoft is in a perpetual no-win situation. On the security front, for example, they are besieged by the evil forces of malware. However, every time they try to improve the situation, end users scream blood murder. For example, was the weird "quasi-administrator with prompting" a good idea? Probably not, but it's better for the average user than silently allowing the installation of spyware, and yet everyone seems to hate it. But what's the alternative? To make accounts regular users by default? How would the average Windows user would feel about that? I don't know, but I have read a many comments by recent converts to Linux who seem to think that entering a password just to install some software is completely stupid and unreasonable, so I can't imagine it would be universally hailed as a great improvement.

And, of course, there's always the breakage that accompanies any OS upgrade. For example, remember Windows XP Service Pack 2? I seem to recall widespread complaints about things breaking when that was rolled out. And we're seeing the same thing now with Vista. And who do people blame? Is it the ISV who are still coding with Windows 98 in mind? No - they blamed Microsoft.

What really kills me about this situation is when I read Raymond Chen's accounts of the efforts of the Windows App Compatibility team. For example, consider this sample chapter from his book. From the cases he mentions there, it is completely obvious that Microsoft takes backward-compatibility seriously. Very seriously. In fact, you might even say they take it too seriously.

Think of it this way. On Linux you're lucky if you can get source compatibility for an application that's more than 5 years old. Microsoft has binary compatibility with a large range of programs that are 10 or 15 years old. They're working with third-party binaries, diagnosing obscure bugs, and implementing fixes to keep the applications working, even though it's by sheer luck that they ever worked in the first place. As a programmer, it's hard to overstate how impressive this is. And yet all anyone ever focuses on is the problems they didn't fix.

Then there's the political angle. There are lots of people out there who seem to think that Microsoft can do no good. Everything they do is viewed with suspicion. Anyone who works for Microsoft has to contend with accusations that he is either in on the conspiracy or is bowing down to "the man" every time he says something they MS-haters don't like. That's got to be at least a little demoralizing. And while a certain degree of animosity is certainly warranted (as it is with practically any large business), it's not like Microsoft has been running child sweatshops or dumping toxic waste in the local drinking water. It just seems way out of proportion.

So no matter what the people in Redmond do, it seems like there's always somebody pissed off at them. And it's a shame, because they really do do some good work. The .NET world has lots of neat technologies and is a very cool place for developers. Even though OpenOffice may be good enough for many, MS Office is by far the best office suite available. And, last but not least, Windows, despite it's flaws (and they are legion) is a very impressive feat of software engineering. Not to mention that Microsoft employs a number of very bright people.

So, to the Linux community, I say, let's give Microsoft a chance. I'm not asking you to like MS, or to start using any of their products. Let's just be honest and realistic. Most people in the community aren't shy about placing the blame on them, but give credit where credit is due. We rightly object when people blame free software for not being a panacea, what with hardware incompatibilities and the lack of certain software. We should at least hold MS to the same standard and not judge them for failing to satisfy everyone.

Here's a weird one. For some reason, my Digitalway MPIO FL100 MP3 player can't see files that are copied onto the removable SD card from Windows. But files copied from Linux show up fine. Is it just me, or does that seem a little backwards?

What happened was that I wanted to listen to a few podcasts this morning. I didn't feel like running downstairs to get the SD card out of the MP3 player, and I didn't want to download them from work, so I just dumped the files on my USB thumb drive before I left the house. When I got to work, I whipped out my portable USB SD card reader, copied the files from the thumb drive to the SD card, and slapped the SD card back in my MPIO. I turned the player on, started browsing the playlist and...nothing. The files just weren't there.

My frist thought was that something must have gone wrong. Maybe I disconnected the card too early and the files didn't copy. So I hooked the SD card back up to my Windows XP workstation and checked. Hmm.... The files were definitely there. Were they corrupt? Didn't seem to be. The file sizes looked right and they played in Windows Media Player.

Maybe it was because the card was almost full. It's a 1GB SD card and there were only 6MB left. Maybe the MPIO can't quite address a full gigabyte. So I moved the files I was trying to play off the card, deleted a few old files, and moved the new ones back. OK, now I've got about 50MB free, which has always been enough before. But when I plugged the card back into the MPIO, it was still a no-go.

After a few more unsuccessful variations on this same process, I started to wonder if the problem was with the SD card reader or even Windows itself. After all, this never happened with my internal SD card reader on my home Kubuntu system. So just for the heck of it, I fired up a copy of Kubuntu running in VMware. I plugged in the SD card reader, moved the MP3s off the card, unmounted and remounted, and moved them back on. This time, when I put the card back in the MPIO, it saw the files. I was able to select them in the playlist and they played perfectly.

At this point, the question is: What the hell happened? According to fsck.vfat, the SD card uses a FAT32 filesystem with long filename support and doesn't show any errors. Theoretically, Windows should be able to read and write that with no problems. And it can - but not in a way the MPIO can read. Is there some extension to FAT32 that Windows uses but Linux and the MPIO don't? Is this due to some implementation-specific detail where the MPIO agrees with Linux but not Windows? There's got to be some rational explanation for this. Does anybody have any ideas?

It's funny how learning things about one platform can teach you about another. Despite all the differences, there are still lots of little similarities that carry over from one to another. In a way, it's kind of comforting.

Take today, for example. I was having a slow day at work, so to control the bordom, I downloaded some old episodes of Scott Hanselman's podcast, Hanselminutes. The episode in question was on the top ten Windows tools/features you didn't know you had. The first tip (#10) was that you can still use the keyboard in the middle of a drag-and-drop operation. So, for example, you can still alt+Tab, use a VirtuaWin hotkey to switch desktop, and just generall do a bunch of stuff I never thought to do with drag-and-drop. It just struck me as both very handy and so obvious I can't believe I never thought of it.

So, naturally, the first thing I did was try it out. Unsurprisingly, it worked and was very cool. And just as naturally, the second thing I did was fire up Kubuntu Edgy in VMware to see if it worked in KDE. And guess what - it does! Not that I should be surprised - there's no reason I know of why it wouldn't work in KDE. It's just that when you go back and forth between Linux and Windows, you get used to the idea that everything is always different. This was one of those "freebies" you discover every now and then that makes you feel nice.

In fact, the relative closeness of KDE to Windows is what attracted me to it in the first place. I started off with the Unices back when GNOME and KDE were in the 1.x releases and - let's face it - they both sucked. Thus I was an old-school AfterStep user for several years and then migrated to ROX and Sawfish. But while ROX was nice, and I really bought into the idea of how it worked, the user experience was just too different from Windows. After a while, going back and forth started to feel jarring. I just had to bring the two closer together. And since there's not much you can do about the interface for Windows, it was obvious that the Linux side would have to change.

I really appreciate it when KDE and other Linux desktop projects make things more Windows-like. Windows might get some things wrong, but there is also a lot that it gets right. Real respect for the user is fixing the geniune problems with the interface he's accustomed to, not making things different for the sake of being different or for some abstract design principles. I think Tog said it best in discussing the differences between Windows and Macs:

Consistency is a funny thing. The most important area of consistency is the area most people don't even think about; which is why it is the most important area. What am I talking about? Shortcut keys. Button ordering. And all those other little things users learned way-back-when, soon absorbed into habit, and never considered again. The way a lot of these work is backwards in Windows. No, let me correct that. It was backwards in Windows, until Windows hit a 90% market share. Now, it is backwards in Macintosh.

It's been a very "IT" kind of afternoon.

I started out the morning well, got some coding done, and was in "the zone" up until about 10:50. The then fire alarm went off. I don't know why, because there wasn't any major fire. Maybe it was a drill/test, maybe some kid pulled the fire alarm. Who knows.

Anyway, I had to go stand outside in the unseasonably cold weather (it's in the 30°F range this week) for about 10 minutes. That sapped a great deal of my motivation. Then I had to stand in line for another 10 minutes while the guards checked IDs put people through the metal detector. That pretty much knocked me out of the zone for the rest of the day.

So this afternoon was devoted to Windows XP trouble-shooting, because it's reliatively brain-dead. I worked with a laptop user to finally track down a long-standing error message that had been showing up in one application. And by "track down" I mean I finally got to actually see the error message and quickly diagnosed it as a file permission problem. I would have done that a long time ago, except that these laptops have no connectivity to our network and are almost never available at a time and location where I can look at them. Plus nobody ever bothered to tell me the exact error message, which makes it a little harder to figure out what's going on. While I try to keep my skills sharp and up-to-date, I have to admit that I'm still woefully lacking in the telepathic debugging department.

Now that I've got that problem tracked down, I'm presented with another. This problem affects 20 odd laptops. How do I fix it on all of them without having to go around and physically touch each of them? Remote access is out, so the first obvious solution is to get the users to do it. However, that won't work because I can't give them the admin password. The second obvious solution is to pawn it off on the help desk, but they'd never go for that. After all, we operate on the "whoever touches it first is stuck with it forever" theory of assigning support tasks. Hardly an optimal algorithm, but that's the way it is and nobody with any power is willing to rock the boat.

That leaves me with one option: script that sum bitch! I might not be able to trust the users with complex instructions, but I can certainly trust them to dump some files on a flash drive and double-click an icon.

The only problem is administrator access. The Windows runas command prompts for passwords. I need something that can use a stored password from a batch file, preferably one kept in an encrypted file. Luckily, a little Googling turned up just such a tool: lsrunase. That looks like it should do the trick. Another quick Google for a Windows command reference to find the CACLS command and I should be good to go. All I need to do now is write the batch file and test it out on one of the laptops. But that'll have to wait for tomorrow.

You ever have one of those moments when you almost wish you could string Bill Gates up with his own entrails? I had one of those moments yesterday morning.

My problem was not Bill Gates or even Microsoft in general, but their representative to the common man: Windows XP. I was bitten by that annoying Explorer bug where it blocks for several seconds at a time for no particular reason. I had to clean off my D: drive because it's is a measly 30GB, which is just barely enough to house the data I've accumulated over the last five years, plus my collection of virtual machines. However, it seemed like every two minutes, when I clicked something, explorer would lock up. No apparent reason, no inordinate disk or CPU activity - it just stopped responding. Then, after 5 to 20 seconds, it would pick up where it left off.

Now, this has happened many times before, but never quite so often in one session. It was positively maddening. It's a good thing I was drinking decaf, or I probably would have ripped my monitor to pieces.

Things went slightly better today, but I did have an issue with deleting a file. Basically, the progress dialog displayed for way, way, way too long. Like a minute or two for a 1MB file. It's just ridiculous.

The worst part is, it's not like I can just stop using Explorer. If this were a UNIX, I could just switch desktops or file managers. But on Windows, that just doesn't work.

Oh, don't get me wrong - there are alternative shells and file managers, but I've never found any of them to be very good. At least not the free ones (I haven't tried any of the paid-for options because my boss is kind of cheap). Most of the free file managers seem to focus on useless features like dual-panes and integrated file viewers (that's why we have file associations - duh!). And the third-part shell replacements...they just feel like second-class citizens. Plus I've found that things tend to break when Explorer isn't running.

Linux, Programming, and Computing in General

Site Map

Location

The reinstall

The restore

Other services

Results

Background

The Fix

Every-day desktop software

Pro-Windows

Pro-Linux

Development tools

Pro-Linux

Pro-Windows

Remote access

Pro-Linux

Pro-Windows

Inertia

Pro-Linux

Pro-Windows

Final Verdict

About Me

Search

News Feeds