Once in a while someone needs to either replace or reconfigure their display monitor to correct refersh rates and or resolution settings. It's a very simple procedure in Hardy. I haven't tried it in Intrepid or above yet. I'll post back after testing in 8.10. Anyway just paste the code below in a terminal screen. Once the GUI comes up, just click on the monitor icon to the right of the model listed in the drop down box, look through the list and make your pick. The rest is self explanatory.
gksudo displayconfig-gtk
Monday, February 16, 2009
Saturday, February 14, 2009
Open Office 3 on Ubuntu Hardy
Lots of people are wanting to install Open Office 3 on Ubuntu Hardy including some of my family members. I'll keep this sweet and short and assume that you already know a little bit about Ubuntu.
1) Go to System>Administration>Software Sources
2) Add this to the sources list:
deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu hardy main
3) Let the sources list applet reload and update
4) Run the Ubdate Manager from; System>Administration>Update Manager
5) Install the updates
6) Enjoy Open Office 3 on your Hardy installation
1) Go to System>Administration>Software Sources
2) Add this to the sources list:
deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu hardy main
3) Let the sources list applet reload and update
4) Run the Ubdate Manager from; System>Administration>Update Manager
5) Install the updates
6) Enjoy Open Office 3 on your Hardy installation
Tuesday, February 10, 2009
Reinstall all of your packages after a fresh Re-install of Ubuntu
People sometimes have to do a reinstall of their Ubuntu system for various reasons (been playing/experimenting with configuration/drivers/other packages or just because something is badly broken) but remembering all the extra packages you have installed can be a chore - but here is the simple solution:On your old system (assuming it is still working), start up Synaptic and go:
File-Save Markings and choose a file name along with a location (like a USB drive) that you can use when you have installed your new system)
This file contains a list of all your currently installed packages, and when you have installed and booted up your new system (and configured your repositories to the best for your location ) then start up Synaptic and go:
File-Read Markings and point it at your saved file, and after that has completed then select Apply to kick off the download & installation of all of those packages you had installed previously!
There are also apt-get command line functions that achieve the same outcome, so those who don’t have/use Synaptic can still do this.
You will still have to do any special configuration changes that you had on the old system, but at least all of the packages are now in the new system.
This is also very handy for moving to new hardware/duplicating setups etc.
Be aware that doing this between different Ubuntu versions may cause complications because some packages may not be in a later version or have different names.
Note:- Don’t forget to backup your sources before you reinstall.
sudo cp /etc/apt/sources.list ~/sources.list.backup
Otherwise if you have added any PPAs or other sources, this tip won’t work.
Kudos to dcstar
File-Save Markings and choose a file name along with a location (like a USB drive) that you can use when you have installed your new system)
This file contains a list of all your currently installed packages, and when you have installed and booted up your new system (and configured your repositories to the best for your location ) then start up Synaptic and go:
File-Read Markings and point it at your saved file, and after that has completed then select Apply to kick off the download & installation of all of those packages you had installed previously!
There are also apt-get command line functions that achieve the same outcome, so those who don’t have/use Synaptic can still do this.
You will still have to do any special configuration changes that you had on the old system, but at least all of the packages are now in the new system.
This is also very handy for moving to new hardware/duplicating setups etc.
Be aware that doing this between different Ubuntu versions may cause complications because some packages may not be in a later version or have different names.
Note:- Don’t forget to backup your sources before you reinstall.
sudo cp /etc/apt/sources.list ~/sources.list.backup
Otherwise if you have added any PPAs or other sources, this tip won’t work.
Kudos to dcstar
Thursday, February 5, 2009
Install Vista Fonts on Ubuntu
- On Ubuntu run:
sudo apt-get install cabextract - Download PowerPoint Viewer 2007.
- Extract the .exe:
cabextract -F ppviewer.cab PowerPointViewer.exe - Prepare a separate target installation directory:
sudo mkdir /usr/share/fonts/vista - Extract the actual fonts:
sudo cabextract -F '*.TT?' -d /usr/share/fonts/vista ppviewer.cab
Tip: You may substitute ~/.fonts instead of /usr/share/fonts for local, single-user installation which does not require root access. - Update the cache:
fc-cache -fv
Wednesday, February 4, 2009
Making Linux FEEL faster...
What we want is perceived performance
Take a file manager for example. Let's focus on Konqueror (it's a nice case study, and it's a nice file manager). Suppose I hit the home button on my panel, which shows one of the (usually hidden and prelaunched) Konqueror instances and prompts it to browse my home directory.
If you have lots of RAM, it won't be a problem -- both Konqueror and the contents of your home directory will be in memory, so it'll be blindingly fast. But if you're rather short of memory, it's a different matter -- what happens next determines whether you feel your computer slow or fast.
If Konqueror has been paged out, it will appear to be frozen (or take longer to "start up") for a couple of seconds, until Linux has paged necessary code paths in. If, on the contrary, my home directory has been evicted from the RAM cache, Konqueror will show up instantly and be responsive, while the home directory loads.
I'd much rather wait for the directory display than have to wait for Konq to unfreeze because it was paged out. The difference is that in the first scenario, I can close the window, use the menus, navigate among the window controls, change the URL, abort the operation; in the second case, I'm screwed until Linux decides to fully pagein whatever Konq needs.
What we want is perceived performance, not throughput. It matters to me that I can manipulate my file manager half-a-second after I've hit the home button. It doesn't matter to me that, because of this preference, the home directory actually takes one second longer to finish displaying.
Variations of this pattern can be found everywhere: in file open dialogs, in multimedia applications with collection managers, basically everywhere an operation requires some sort of progress report.
The solution
There are two distinct and complementary measures we'll take to solve this problem. Keep reading to find out about them.
Tuning swappiness to prevent impromptu RAM hijacking
Swappiness is the name Linux kernel developers gave to the preference between paging applications out to disk and (in practice) shrinking caches. If it's close to 0, Linux will prefer to keep applications in RAM and not grow the caches. If it's close to 100, Linux will prefer to swap applications out, and enlarge the caches as much as possible. The default is a healthy 60.
The irony of this preference is that, in fact, paging an unused application out generally produces a net performance increment, since the cache really helps a lot when it's needed -- but this net performance increment translates to a net drop in perceived performance, since you usually don't care whether a file uncompresses a few seconds later, but you do care (a lot) when your applications don't respond instantaneously.
On a desktop computer, you want swappiness to be as close to zero as possible. The reason you want to do this (even though it might hurt actual performance) is because this will immunize your computer to memory shortages caused by temporary big file manipulations (think copying a big video file to another disk). The cache will still be as big as possible, but it won't displace running applications.
With swappiness turned down, the Linux kernel no longer attempts to enlarge the cache by paging applications out. Not unless you're experiencing an extremely high memory shortage.
To make the change:
sudo gedit /etc/sysctl.conf
Paste this to end of the file:
vm.swappiness=10
Filesystem caches are more important than other caches
We've already established that the filesystem cache is important because, without it, file browsing goes extremely slowl. Now lets tell Linux that we want it to prefer inode/dentry cache to other caches.
Back to the terminal we go:
sudo gedit /etc/sysctl.conf
Paste this to the end of the file:
vm.vfs_cache_pressure=50
Values close to 100 provide no gain. Values close to zero can cause huge swap activity during big filesystem scans.
Know this - These tips work well for me, however ymmv and as always - If you don't understand any of what I've said here, just leave your system alone. There is always the possibility that something COULD go wrong (though very unlikely), so play with this at your own risk.
It's a good practice to back up any file you are altering (prior to making that change and saving). If you back up the files mentioned and something goes wrong, it's always very easy to fix.
Good luck - and enjoy the improved speed of your desktop.
Disclaimer: The preceeding information was taken from rudd-o.com. I have posted the edited content here for my own use, and other family members to refer to.
Take a file manager for example. Let's focus on Konqueror (it's a nice case study, and it's a nice file manager). Suppose I hit the home button on my panel, which shows one of the (usually hidden and prelaunched) Konqueror instances and prompts it to browse my home directory.
If you have lots of RAM, it won't be a problem -- both Konqueror and the contents of your home directory will be in memory, so it'll be blindingly fast. But if you're rather short of memory, it's a different matter -- what happens next determines whether you feel your computer slow or fast.
If Konqueror has been paged out, it will appear to be frozen (or take longer to "start up") for a couple of seconds, until Linux has paged necessary code paths in. If, on the contrary, my home directory has been evicted from the RAM cache, Konqueror will show up instantly and be responsive, while the home directory loads.
I'd much rather wait for the directory display than have to wait for Konq to unfreeze because it was paged out. The difference is that in the first scenario, I can close the window, use the menus, navigate among the window controls, change the URL, abort the operation; in the second case, I'm screwed until Linux decides to fully pagein whatever Konq needs.
What we want is perceived performance, not throughput. It matters to me that I can manipulate my file manager half-a-second after I've hit the home button. It doesn't matter to me that, because of this preference, the home directory actually takes one second longer to finish displaying.
Variations of this pattern can be found everywhere: in file open dialogs, in multimedia applications with collection managers, basically everywhere an operation requires some sort of progress report.
The solution
There are two distinct and complementary measures we'll take to solve this problem. Keep reading to find out about them.
Tuning swappiness to prevent impromptu RAM hijacking
Swappiness is the name Linux kernel developers gave to the preference between paging applications out to disk and (in practice) shrinking caches. If it's close to 0, Linux will prefer to keep applications in RAM and not grow the caches. If it's close to 100, Linux will prefer to swap applications out, and enlarge the caches as much as possible. The default is a healthy 60.
The irony of this preference is that, in fact, paging an unused application out generally produces a net performance increment, since the cache really helps a lot when it's needed -- but this net performance increment translates to a net drop in perceived performance, since you usually don't care whether a file uncompresses a few seconds later, but you do care (a lot) when your applications don't respond instantaneously.
On a desktop computer, you want swappiness to be as close to zero as possible. The reason you want to do this (even though it might hurt actual performance) is because this will immunize your computer to memory shortages caused by temporary big file manipulations (think copying a big video file to another disk). The cache will still be as big as possible, but it won't displace running applications.
With swappiness turned down, the Linux kernel no longer attempts to enlarge the cache by paging applications out. Not unless you're experiencing an extremely high memory shortage.
To make the change:
sudo gedit /etc/sysctl.conf
Paste this to end of the file:
vm.swappiness=10
Filesystem caches are more important than other caches
We've already established that the filesystem cache is important because, without it, file browsing goes extremely slowl. Now lets tell Linux that we want it to prefer inode/dentry cache to other caches.
Back to the terminal we go:
sudo gedit /etc/sysctl.conf
Paste this to the end of the file:
vm.vfs_cache_pressure=50
Values close to 100 provide no gain. Values close to zero can cause huge swap activity during big filesystem scans.
Know this - These tips work well for me, however ymmv and as always - If you don't understand any of what I've said here, just leave your system alone. There is always the possibility that something COULD go wrong (though very unlikely), so play with this at your own risk.
It's a good practice to back up any file you are altering (prior to making that change and saving). If you back up the files mentioned and something goes wrong, it's always very easy to fix.
Good luck - and enjoy the improved speed of your desktop.
Disclaimer: The preceeding information was taken from rudd-o.com. I have posted the edited content here for my own use, and other family members to refer to.
Subscribe to:
Posts (Atom)
