TOPIC: YAST
Command Line Software Management
2nd December 2009One of the nice things about a Debian-based Linux distribution is that it is easy to pull a piece of software onto your system from a repository using either apt-get or aptitude. While some may prefer a GUI, but I find that the command line offers a certain extra transparency that stops the "what's it doing?" type of question. That's never to say that the GUI-based approach hasn't a place, and I only go using it when seeking out a piece of software without knowing its aptitude-ready name. Interestingly, there are signs that Canonical may be playing with the idea of making Ubuntu's Software Centre a full application management tool with updates and upgrades getting added to the current searching, installation and removal facilities. That well may be, but it's going to take a lot of effort to get me away from the command line altogether.
Fedora and openSUSE have their software management commands too in the shape of yum and zypper, respectively. The recent flurry of new operating system releases has had me experimenting with both of those distros on a real test machine. As might be expected, the usual battery of installation, removal and update activities are well served, and I have been playing with software searching using yum too.
One thing that has yet to mature is in-situ distribution upgrading, à la Ubuntu. In principle, it is possible, but I got a black screen when I tried moving from openSUSE 11.1 to 11.2 within VirtualBox using instructions on the openSUSE website. Not wanting to wait, I reached for a Live CD instead, and that worked a treat on both virtual and real machines.
Being in an experimental turn of mind, I attempted the same to get from Fedora 11 to the beta release of its version 12. A spot of repository trouble got me using a Live CD in its place. You can perform an in-situ upgrade from a full Fedora DVD, but the only option is system replacement when you have a Live CD.
Once installation is out of the way, YAST can be ignored in favour of zypper and yum is good enough that Fedora's GUI-using alternative can be ignored. It's nice to see good transparent ideas taking hold elsewhere and may make migration between distros much easier too.
BBC Radio Player and Linux
13th November 2007It's been a while since I mentioned anything that might be aurally related, and then this rears its head. The Xine plugin beloved by the instance of Firefox on my Ubuntu box simply refuses to play ball with the BBC's Listen Again feature; 6Music shows are what I am trying to catch later. RealPlayer is on the system, but Firefox simply refuses to locate it. On its own, it plays live radio from the BBC and Ireland's Today FM but, unless I need to do some digging, that's not much use for the Listen Again service. It may be some hard-wiring done by Canonical as part of their packaging of Firefox: might be related to their preference for Free Software. If I can be bothered, I might replace it with the usual version to see if RealPlayer can be picked up: I do seem to remember reading somewhere that this was a possibility...
Yes, I could use one of my Windows VM's, but I have found another way courtesy of openSUSE 10.3. No, I haven't changed Linux distro, yet the reason that openSUSE has made a sudden appearance on this blog in recent times has got to do with my acquiring a copy of the latest issue of Linux Magazine. It came emblazoned with a DVD containing both 32-bit and 64-bit variants of openSUSE's latest version and, wanting to have a look at how KDE appears these days, I knocked up a VM and installed the 32-bit variant thereupon.
Unexpectedly, that has afforded a Linux solution to my BBC Radio Player conundrum. openSUSE's Firefox instance can find RealPlayer once you have it installed. That process involves a spot more work than if it was Free Software: you need to add an extra software repository to YaST (openSUSE's configuration utility). The breadcrumb trail is YaST -> Software -> Software Repositories and hitting the Add button fires up a wizard that needs the following settings to set things up as needed:
Protocol: http
Server Name: download.opensuse.org
Directory on server: /distribution/10.3/repo/non-oss/suse/
Authentication: anonymous
Once the new repository was set up (I named it Non-OSS), I found the RPM and YaST took care of the rest. So, what started out as an exercise in curiosity has now found a use. While network traffic may cause playback to stutter, I have what I want without once starting up Windows. Sorting out Ubuntu may happen, but it is a lesser priority and I don't want to disrupt my computing environment in any event.
Setting up openSUSE in VMware Workstation
12th November 2007While it should have been as straightforward as following the instructions on the openSUSE website, a bug in VMware Tools derailed things for me. The usual procedure would have you starting by selecting Install VMware Tools from the VM menu before popping into the virtual machine to do the rest. Once binutils, gcc, gcc-c++, kernel-source and make are in place, the next steps should involve using YaST to install the RPM for you to run the vmware-config-tools.pl script from the terminal.
However, a bug in compat_slab.h puts a stop to any hopes of installing the vmhgfs component. That's needed if you like to enable the shared folders feature; looking in /mnt/hgfs then would get you to any shared folders. While everything else will be there, why miss out on one piece of functionality when it comes in useful?
Having found a useful thread on the subject, here's my way forward: it is as the expected procedure up to the point of installing the RPM. With VMware Tool installation on a Linux guest, you have two options: use RPM as described or use the compressed tarball. The latter seems the better course. Extract the contents into a folder and navigate to that folder. When there, go into vmware-tools-distrib/lib/modules/source and extract the file vmhgfs.tar. Proceed into the resulting vmhgfs-only contained wherever you put it and perform the following edit of compat_slab.h:
Change
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)
to
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)
After that, recreate and replace vmhgfs.tar before issuing the following command in the terminal window while in the vmware-tools-distrib directory: ./vmware-config-tools.pl (anything prefixed with "./" picks up the file from the current working directory rather than where system binaries are stored). Though a kernel compilation will be involved, all the defaults should be sensible. Hopefully, all will work well after this.
Update: I am left with a number of outstanding issues that I need to resolve. Lack of internet access from the VM is one of them, and a constant forgetfulness regarding the nationality of my keyboard (it's British) might be another. In the interim, I have removed VMware tools until I can spend some time setting these to rights. That means internet access has returned, and the British keyboard layout is being interpreted correctly for now...