Adventures & experiences in contemporary technology
Linux Mint 14 may be out now but I’ll be sticking with its predecessor for now. Being a user of GNOME Shell instead of Cinnamon or Mate, I’ll wait for extensions to get updated for 3.6 before making a move away from 3.4 where the ones that I use happily work. Given that Linux Mint 13 is set to get support until 2017, it’s not as if there is any rush either. Adding the back-ported packages repository to my list of software sources means that I will not miss out on the latest versions of MDM, Cinnamon and Mate anyway. With Ubuntu set to stick to GNOME 3.6 until after 13.04 is released, adding the GNOME 3 Team PPA will be needed if 3.8 arrives with interesting goodies; there are interesting noises that suggest the approach taken in Linux Mint 12 may be used to give more of a GNOME 2 desktop experience. Options abound and there are developments in the pipeline that I hope to explore too.
However, there is one issue that I have had to fix which stymies upgrades within the 3.2 kernel branch. A configuration file (/etc/grub.d/10_linux) points to /usr/share/grub/grub-mkconfig_lib instead of /usr/lib/grub/grub-mkconfig_lib so I have been amending it every time I needed to do a kernel update. However, it just reverts to the previous state so I thought of another solution: creating a symbolic link in the incorrect location that points to the correct one so that updates complete without manual intervention every time. The command that does the needful is below:
sudo ln -s /usr/lib/grub/grub-mkconfig_lib /usr/share/grub/grub-mkconfig_lib
Of course, figuring out what causes the reversion would be good too but the symbolic link fix works so well that there’s little point in exploring it further. Of course, if anyone can add how you’d do that, I’d welcome this advice too. New knowledge always is good.
It might just be my experience of the things but I do tend to take claims about laptop or netbook battery life with a pinch of salt. After all, I have a Toshiba laptop that only lasts an hour or two away from the mains and that runs Windows 7. For a long time, my ASUS Eee PC netbook was looking like that too but a spot of investigation reveals that there is something that I could do to extend the length of time before the battery ran out of charge. For now, the solution would seem to be installing eee-control and here’s what I needed to do that for Ubuntu 11.04, which has gained a reputation for being a bit of a power hog on netbooks if various tests are to be believed.
Because eee-control is not in the standard Ubuntu repositories, you need to add an extra one for install in the usual way. To make this happen, launch Synaptic and find the Repositories entry on the Settings menu and click on it. If there’s no sign of it , then Software Sources (this was missing on my ASUS) needs to be installed using the following command:
sudo apt-get install software-properties-gtk
Once Software Sources opens up after you entering your password, go to the Other Software tab. The next step is to click on the Add button and enter the following into the APT Line box before clicking on the Add Source button:
ppa:eee-control/eee-control
With that done, all that’s need is to issue the following command before rebooting the machine on completion of the installation:
sudo apt-get install eee-control
When you are logged back in to get your desktop, you’ll notice a new icon in your top with the Eee logo and clicking on this reveals a menu with a number of useful options. Among these is the ability to turn off a number of devices such as the camera, WiFi or card reader. After that there’s the Preferences entry in the Advanced submenu for turning on such things as setting performance to Powersave for battery-powered operation or smart fan control. The notifications issued to you can be controlled too as can be a number of customisable keyboard shortcuts useful for quickly starting a few applications.
So far, I have seen a largely untended machine last around four hours and that’s around double what I have been getting until now. Of course, what really is needed is a test with constant use to see how it gets on. Even if I see lifetimes of around 3 hours, this still will be an improvement. Nevertheless, being of a sceptical nature, I will not scotch the idea of getting a spare battery just yet.
Like other Linux distributions, Fedora has the software repository scheme of things for software installation and updating. However, it could do with having the ability to remove unwanted repositories through a GUI but it doesn’t. What you need to do instead is switch to root in a terminal using the the command su -- and entering you root password before navigating to /etc/yum.repos.d/ to delete the troublesome [file name].repo file. Recently, I needed to do this after upgrading to Fedora 14 or Yum wouldn’t work from the command line, which is the way that I tend to update Fedora (yum -y update is command that I use and it automatically does all installations unattended until it is finished doing what’s needed). The offending repository, or “Software Source” as these things are called in the GUI, was belonging to Dropbox and even disabling it didn’t make Yum operate from the command like it should so it had to go. Maybe Dropbox haven’t caught up with the latest release of Fedora but that can be resolved another day.