Adventures & experiences in contemporary technology
I must admit that there have been times when I logged off from my main Ubuntu box at home to dispatch a runaway process that I couldn’t kill and then log back in again. The standard signal being sent to the process by the very useful kill command just wasn’t sending the nefarious CPU-eating nuisance the right kind of signal. Thankfully, there is a way to control the signal being sent and there is one that does what’s needed:
kill -9 [ID of nuisance process]
For Linux users, there seems to be another option for terminating process that doesn’t need the ps and grep command combination: it’s killall. Generally, killall terminates all processes and its own has no immunity to its quest. Hence, it’s an administrator only tool with a very definite and perhaps rarely required use. The Linux variant is more useful because it also will terminate all instances of a named process at a stroke and has the same signal control as the kill command. It is used as follows:
killall -9 nuisanceprocess
I’ll certainly be continuing to use both of the above; it seems that Wine needs termination like this at times and VMware Workstation lapsed into the same sort of antisocial behaviour while running a VM running a development version of Ubuntu’s Intrepid Ibex (or 8.10, if you prefer). Anything that keeps you from constantly needing to restart Linux sessions on your PC has to be good.
I have gone and downloaded the next to four gigabytes of the 64 bit variant of Fedora 9 using Bittorrent and so thought that it might be a good idea to set the thing up in a VirtualBox virtual machine. However, that stratagem got scuppered by VirtualBox’s not supporting 64 bit operating systems. I do have VMware Workstation and, since that supports what I was doing, I resolved to set up Fedora there. After my plan’s getting shelved, my trying out VirtualBox is a matter that remains outstanding…
I have recently encountered an odd situation following my recent upgrade to Ubuntu 8.04: when I use VMware Workstation to run Windows XP in full screen mode, the keyboard no longer acts as it should. For instance, Caps Lock and Num Lock keys stop working as does the Shift key. Logging out and back in again is the least that’s needed to set things right but there has to be a better way to fix the problem. I am not saying that it’s limited to the scenario where I saw it happen but it’s still very odd behaviour. If you have a solution, please let me know. Of course, I’ll keep you posted if I find one. In the meantime, I’ll be avoiding full screen mode with VMware as much as I can.
Update 1:
I have done a spot of digging on this one since and gained the impression that there might be a conflict between VMware and the version of X.org Server that comes with Ubuntu. A restorative trick that I have seen suggested is to issue the following command in a terminal, replacing "gb" with your own locale, but I have yet to see if it works:
setxkbmap -rules xorg -layout "gb"
In any case, it looks as if it is not a permanent fix but just a way to keep working without resorting to system restarts, logging off and back on, etc.
Update 2:
I can now verify that the comand quoted above works for me. Of course, it would better to find a permanent fix and even better for the behaviour never to occur at all but any fix is better than none whatsoever.
Here’s the command that does the deed for me on Ubuntu:
uname -a
I usually only need it to find out what header files I need for any VMware repeat installations or reconfigurations.
With every change of kernel, a re-installation of VMware becomes necessary and my move to Ubuntu "Hardy Heron" 8.04 was punctuated by the same activity. However, the advent of the 2.6.24.x kernel meant that my usual means was no longer successful so a new approach was needed. That involved the mysteriously named vmware-any-any patch and version 116 of this seemed to set things to rights for me. Stopping the installation before vmware-config.pl runs is the best course of action and it will only fail anyway. Downloading vmware-any-any-update-116.tgz, extracting from the archive and running runme.pl using sudo continues the process. It seemed to have worked for me but I must wonder at why VMware seem unbothered by the idea of keeping up with Linux kernels and C compilers. It would certainly have removed the need for the user community needing to anything about the problems that others and I keep seeing; it’s a very unusual arrangement.
One of the unexpected features of VMware is that you are left to set the virtual machine to use resolutions above and beyond that allowed by your own monitor and graphics card combinations. From a web development or design point of view, this is incredibly useful when you consider the sizes of the screens that come with PC’s these days: some of them make my 17′ Iiyama ProLite E431S take on the appearance of having proportions close to that of a postage stamp. While getting a bigger screen sounds a very nice idea and 24′ models are supposed to allow for excellent productivity, I plan to stick with what I have and VMware facilitates this with a top resolution of 2360 pixels by 1770 pixels when you get VMware tools set up on your guest OS; Windows XP is what I have been using with these higher resolutions. You do have to pan about a bit because you can only see part of the screen when the resolutions climb beyond your own monitor settings and it does exercise your hardware but being able to see how things look in resolutions larger than anything that you can access (1600 by 1200 is as high as it goes for me for a real machine and that belongs to my workplace) is very much worth it. It certainly allowed me to fine tune my online photo gallery, something that makes me relax a little more now that I have done the required optimisation for different screen heights.
One of the nice things about the Linux/UNIX command line is that you get the options of stringing together a number of commands on one line for submission of all for processing at one go. Separating them with && does the trick but I noticed that semicolon delimitation worked as well. Here’s a line that will install VMware for you in one fell swoop:
sudo apt-get install linux-headers-$(uname -r) build-essential gcc-3.4 && tar xzf VMware-workstation-6.0.2-59824.i386.tar.gz && export CC=/usr/bin/gcc-3.4 && cd vmware-distrib && sudo ./vmware-install.pl
Another trick is to direct the output of one command into another like the following which subsets a process listing:
ps -aux | grep "wine"
It’s all good stuff and is the sort of thing that shows why so many Linux/UNIX types love their command line so much.
Over the last week, I have had VMware misreport the speed of my CPU and have virtual machines like they’re on speed. To cure it, I tried restarting the PC a few times but that yield no joy, even if it did work the last time that VMware did this on me. Following some instructions from the Ubuntu forums set things back onto an even keel again. The commands required follow:
sudo apt-get install linux-headers-$(uname -r) build-essential gcc-3.4
tar xzf VMware-workstation-6.0.2-59824.x86_64.tar.gz
export CC=/usr/bin/gcc-3.4 && cd vmware-distrib && sudo ./vmware-install.pl
The first of these adds in a specific version of the GNU C compiler while also adding kernel headers; the latter weren’t needed on my system since I already had them. The second extracts files from the tarball while the last performs the required installation rites.
It was the prospect of having Photoshop Elements going on Linux that got me thinking about working with WINE. The cause of that was Elements’ inability to edit, create and save files to a VMware shared folder. As it turned out, there was more to my WINE adventures than getting Elements working. Because I was in learning mode, those adventures turned out to be messy ones with WINE getting uninstalled and reinstalled a number of times. For the last of these, I forced matters by installing from a DEB package rather than going through Ubuntu’s normal channels. The openSUSE journey was a bit more orderly and that VM option remains if I want to go experimenting more.
Along the way, I got the Windows version of Opera going as a test. When trying out WINE in former times, I never tried installing applications into it like I do now. I don’t know if this was because I hadn’t made an important connection or that wasn’t the way that things used to be. Flushed with the success of Opera, I went further and discovered that Dreamweaver 8 and Altova’s XMLSpy 2007 Professional work without my breaking a sweat. Photoshop Elements was another story and one that I have told before. Apple’s iTunes was another thing that I tried but without success, even with a useful guide on Wine Reviews; for some reason, I’m having trouble getting the installation to complete successfully. I think that I’ll leave my tinkering at that for now but my general impression is that WINE works well these days, even if there is the odd crash or inexplicable disappearance of an application window. The latter happened with Dreamweaver and XMLSpy and I needed to log off and back on again to clear the slate for further progress.
When you buy a piece of software and get accustomed to its ways of working, it is natural to want to continue using it. That applied to a number of applications when I moved over to Linux in the latter half of last year and one of these was Adobe’s Photoshop Elements 5.0, a purchase made earlier in the year. My way forward was to hang on to Windows by way of VMware. However, Elements fails to edit or save files in the Linux file system accessed through VMware’s shared folders feature. I have yet to work out what’s happening but the idea of using a more conventional networking arrangement has come to mind.
Another idea that intrigued me was the idea of using WINE, the Windows API emulator for Linux. You can get it in the Ubuntu and openSUSE software repositories but the WINE website has more to say on the subject. That’s only the first stage though as you might see from WINE’s Wiki page on Photoshop and its kind. However, their advice is a spot incomplete so I’ll make it more explicit here. You need to run Winetricks from its online home as follows:
wget kegel.com/wine/winetricks; sh winetricks fakeie6
wget kegel.com/wine/winetricks; sh winetricks mdac28
wget kegel.com/wine/winetricks; sh winetricks jet40
The first line flicks a switch to fool Microsoft components to install thinking that they are installing into a Windows system with IE on board. Without this, the rest will not happen. The second installs Microsoft’s native ODBC drivers; Elements will not function at all without these if my experience is any guide. The last step is to add JET support so that Elements’ Organiser can get going. With all of these in place, having a working Photoshop Elements instance under Linux should be a goer. Apart from the odd crash, things seem to be working OK on Ubuntu and openSUSE seems hospitable too. Further experimentation may reveal more.
Update: The WINE Wiki has now been updated (and links back here!). As per dank’s comment, the above lines can be condensed into what you see below:
wget kegel.com/wine/winetricks; sh winetricks fakeie6 mdac28 jet40