Jan
16
Apparently Dell will be pre-installing FireFox in the UK
Filed Under Computers & Tech on January 16, 2006 | Leave a Comment
There have been rumors around about this for a few weeks now and try as I might the closest to an authoritative source I can get is a post on Blake Ross’ blog (he is a FireFox co-creator). Should this turn out to be true it could have quite an impact on the browser usage on the web, particularly for UK sites. I can only see it as a good thing. I also enjoyed some of the rumors I’ve seen about the reasons for this on the web, the best being that it’s a ploy by Dell to reduce the amount of support they have to give because it will cut down on spy-ware infections and the invasion of those annoying porn pop-ups!
Dec
8
Breezy Badger release of KUbuntu continues to dissapoint
Filed Under Computers & Tech, System Administration on December 8, 2005 | Leave a Comment
Following on from my last article about Breezy I’m afraid things have not gotten any better. KUbuntu is just broke! At first I thought the mac style control panel was really cool until I discovered that I can’t get into administrator mode on any of the dialogs. I click the button, enter the password, the border goes red, the panel goes blank, stays blank for some timeout period and then brings me back to the non-admin display. I can click that button all I want but I can never edit any settings that you need to be root for. Yet again not acceptable from a Linux that is supposed to be for "human beings".
Nov
30
Breezy Badger release of KUbuntu very disappointing
Filed Under Computers & Tech on November 30, 2005 | Leave a Comment
I’d read some good things about the Breezy Badger release of Ubuntu on Planet MiNDS> so I figured I’d give it a go. Simply put, I’m not impressed. Things started off bad when the installer messed up because it made retarded assumptions and now that it’s up and running it is still causing me trouble.
Why the Breezy Badger Install sucks
Firstly, the installer made two assumptions that resulted in me having to intervene and switch to a terminal to sort it out. That’s all well and good for seasoned Linux Users but is totally un-acceptable for a distro that makes a big deal out of being "Linux for Human beings".
Firstly, I find it retarded that the installer even tries to go online, but it does. Fair enough. Where things get really retarded is when it tries to go online WITHOUT ASKING IF YOU NEED TO USE A PROXY! It just sat there. I figured it would time out ….. 5 minutes pass ….. another 5 minutes pass …. I give up and switch to a terminal and kill the process. The installer recovers but skips some setup steps. It was all recoverable later but only with some vi editing and farting round on the command line. Again, no problem at all for a seasoned Linux user but a really big deal for Human Being like my mother!
Secondly Breezy decided that after it had detected my graphics card it should set the resolution, not to a safe number like Windows or OS X would do nor did it ask me what I wanted like Fedora does, nope, it just decided to set the resolution as high as the graphics card can go. Thing is my monitor can’t go as high as my graphics card so as soon as my machine re-booted after the install I got a blank screen when X started and a message from my monitor telling me it couldn’t handle what it was being fed. I fixed it by firing up a terminal and editing /etc/X11/xorg.conf but again, no average user is going to be able, or willing, to do that!
In summation, the installer could have saved me a lot of bother and made the whole experience more pleasant by asking me two simple questions:
- Do you use a proxy and if so where is it?
- What resolution would you like from this list your graphics card can handle?
These are simple things that would have made a huge difference and that the Fedora installer lets you do in a nice GUI. When it comes to installers, KUbuntu is FAR behind Fedora as far as the average user is concerned.
After the Installation
There are also two things that are really annoying me now that the system is installed. Firstly, I installed both FireFox and Thunderbird with apt yet when I try to open a link from within Thunderbird NOTHING happens. It’s not that it uses the wrong browser, it just doesn’t use ANY browser! I’ve been copying and pasting links all day and quite frankly it’s a real PITA!
Secondly, I can’t get the MS fonts from apt like I could on the previous release of KUbuntu. I’ve enabled all the repositories and I’ve tried every apt-cache search permutation I can think of and still no joy. It says there is a package that other packages refer to that does what I need but it can’t find the blooming thing!
On a less important note, Niall gave me exceptionally high hopes on the shinneyness of the GUI describing it as "OSX shinny" in his recent post about Breezy, but I was disappointed. It’s nice, very nice even and certainly nicer than the previous KUbuntu or the latest Fedora but it’s still far from OS X shinny I’m afraid.
Conclusion
If you are a Human Being and you want to use Linux, use Fedora!
Links
- Ubuntu – www.ubuntulinux.org
- Fedora – www.fedora.redhat.com
Nov
19
Synergy on OS X – the easy way
Filed Under Computers & Tech, System Administration on November 19, 2005 | 6 Comments
If you have multiple machines on your desk and you are fed up of having a mess of keyboards and mice all over the place then Synergy is just the thing you need. What makes Synergy even better is that it works cross-platform so you can share a single keyboard and mouse between Linux, OS X, any Unix and even crappy old Windows!
To find out more about installing synergy on non-OS X platforms or
about the practicalities of setting up a Synergy server checkout
Synergy’s home page: http://synergy2.sourceforge.net/
The synergy home page allows you to download binaries for OS X but that package literally gives you just the executable file for the server and client and nothing more. If you want Synergy to be easier to use and install on OS X don’t get it from the Synergy website, get Synergy KM instead.
SynergyKM gives you a nice Synergy icon on the Menu Bar to allow you to easily see and change Synergy’s state (see screen first shot below). SynergyKM also adds an extra panel to your System Preferences to allow you to configure Synergy both as a client and a server (see second screen shot).
You can get SynergyKM here: http://software.landryhetu.com/synergy/
Addendum – 24-11-05
For some reason when you are using Synergy to connect your Mac to another keyboard and mouse and you have a hot-corner set up to lock the screen it doesn’t work while Synergy is on. If you turn-off synergy it works fine. for the last week I’ve been turning off Synergy each time I wanted to lock my computer and that’s just not ideal at all so I did some Googling on the matter and found a good solution.
You can get a padlock icon to appear in your Menu Bar and when you click on that one of the options in the menu is "Lock Screen" (see first figure below). This will allow you to lock your screen even while using Synergy. Getting this padlock is a little counter intuative but here goes:
- Open the "Keychain Access" program in your Applications/Utilities folder
- Open the prefferences for this app (Keychain Access -> Preferences)
- I nthe "General" pane check the checkbox labled "Show Status in Menu Bar"
Simple as that!
Nov
3
Could this be a glimpse of a bright future?
Filed Under Computers & Tech on November 3, 2005 | Leave a Comment
I read an article in Yahoo News today from MacCentral that was about a MacMini clone (called the MiniPC) by the Taiwanese computer manufacturer AOpen. At first I thought it was just anther rip off of a good idea by Apple (which it is, the new machine is almost identical to the MacMini in both spec and appearance) but something else caught my eye, honest and transparent pricing!
There are two versions of this tiny PC which have identical hardware but a dramatic difference in price, a Linux version ($399) and a WinXP version ($499). This gives consumers and accurate idea of how much of the price of their PC goes to Microsoft (20% in this case).
In my experience, your average consumer just assumes that Windows ‘comes free’ with their computer because many manufacturers will not sell you a machine without Windows (I have personal experience of both Dell and Fujitsu-Siemens refusing to sell me a PC without Windows). With pricing like that of the new MiniPC that illusion will be shattered and when you combine that with Microsoft’s efforts to make life hard for those using pirated versions of Windows, I think there will be many more people pushed away from Windows.
Hopefully this is the start of a bright new future rather than just a blip on the radar. If other manufacturers start to follow suit ordinary people will, for the first time, start to genuinely consider Linux as a real alternative to Windows.
Oct
4
The CORRECT way to install Sun Java on Debian/Ubuntu
Filed Under Computers & Tech, System Administration on October 4, 2005 | Leave a Comment
This little guide is just a greatly padded out version of instructions I got from Misha but since we have quite a few Ubuntu users and quite a few Java programmers in MiNDS> this should come in quite useful.
Basically this is the Debian way of installing the Sun JSDK so that it can be managed with dpkg and hence easily upgraded or removed at a later date.
Firstly, since Ubuntu IS a distribution of Debian really I will just refer to Debian in these instructions but the instructions also apply to Ubuntu and in fact it was on Ubuntu that I tested this. Also, these instructions assume that you are logged in as a user who has access to root via sudo.
The way this will work is that we will use a Debian package called java-package to turn the binary Linux installer we get from Sun (or IBM and others too) into a proper Debian package (.deb) and then we will use Debian’s package manager (dpkg) to install that Debian package.
The first step in the process is to install the java-package program that will allow us to create the .deb file. To do this simply type:
sudo apt-get install java-package
If you are asked for a password it is for sudo and you should enter your own login password.
The next step is to go to java.sun.com and download the Linux binary installer for the JSDK that you want to install. DO NOT DOWNLOAD THE LINUX RPM FILE!
The next step is to use java-package to turn this binary file into a Debian package, to do this move into the folder where you downloaded the binary file from java.sun.com.
NOTE, if you are doing this in the college on your machine for your 4th year project you will have to copy the binary file to /tmp and work from there because local root does not have access to your NFS mounted home directory.
For this step you will need fakeroot, if you don’t have it installed install it with apt-get like so:
sudo apt-get install fakeroot
Once you have fakeroot installed and you are in the right directory start the packaging with the command (replacing file_from_sun.bin with the actual name of the file you got from Sun):
fakeroot make-jpkg file_from_sun.bin
This will now appear to run the Sun installer but rather than installing it into your system it is extracting it to a temporary fake root file system and then creating the .deb file from the files in that fake file system. During this stage you will be asked to agree to the Java license agreement.
When the above command completes (will take a few minutes) a .deb file will have been created in your current folder. This is the file that we will now install with dpkg as follows (replacing name_of_deb_file.deb with the actual name of the .deb file created):
sudo dpkg -i name_of_deb_file.deb
And hey presto you are finished, when ever you want to get rid of that JDK all you have to do is (replacing name_of_deb_file_without_The_extension with the name of the generated .deb file but with the .deb extension left out, e.g. sun-j2sdk1.5):
dpkg --purge name_of_deb_file_without_The_extension
You can then install a new JSDK in the same was as described above or just leave your system Java free (heaven knows why you’d do something mad like that!)
Oct
3
Beating Bugzilla into submission on OS X
Filed Under System Administration, Computers & Tech on October 3, 2005 | Leave a Comment
I had been warned that Bugzilla was a pain to install but when I read the instructions on their webpage I thought it all looked pretty simple, turns out it WAS a pain to install!
The trouble was caused by two things:
- CPAN modules refusing to build on OS X
- Bugzilla making ridiculous assumptions that just don’t stand up to reality, namely:
- You will always want to use /usr/bin/perl
- sendmail will always be in /usr/lib/sendmail
For details on how I resolved these issues read on.
Firstly, getting Perl to behave itself. The simplest solution to this problem is not to use Perl that comes with OS X but to use DarwinPorts or Fink to get Perl in order. I used DarwinPorts because I have had bad experiences with Fink and really like DarwinPorts. Anyway, it worked like a charm, all the modules I needed were available via DarwinPorts and installed with no issues at all. One thing to note is that this does not patch up the Perl in /usr/bin but rather installs a whole new Perl in /opt/local/bin. One slight annoyance was that to get DBI::MySQL I also had to install a copy of MySQL from DarwinPorts. This is fine because you don’t actually have to USE it, just have it there. As it happens the guys at MySQL have an excellent binary distribution of the MySQL server these days so there is no need to get it from DarwinPorts. I also already had other databases installed and running on my MySQL install so I was in no humor to have a second MySQL server running just for Bugzilla! The one complication here is that the default location for the MySQL socket in the DarwinPorts Perl is the location the DarwinPorts MySQL server uses and not the one the default MySQL server uses. Since I am not using this MySQL I had to tell Bugzilla not to use the default socket but the one I was actually using. You do this by editing localconfig. In my case I had to set the following:
$db_sock = '/private/tmp/mysql.sock';
Now, you can probably imagine how using DarwinPorts’ Perl caused the first of the assumptions made by the Bugzilla installer to break down. The Perl that comes with OS X is at /usr/bin/perl and is used by loads of stuff on the system (so I can’t replace it with a symlink to the right Perl), the Perl from DarwinPorts is at /opt/local/bin/perl. Although I explicitly ran the installer for Bugzilla with this Perl in the hope that it would be smart and realise that it should use that Perl for everything, it still set all the shebang lines to #!/usr/bin/perl and hence although Bugzilla passed the installer’s tests with flying colours, it crashed in a heap when you tried to use it because it went running off to the wrong Perl!
I figured that if the shebang lines were not generated by setting them to the Perl running the installer then there MUST be a configuration option to allow you to specify what Perl should be used. I tried looking really hard but with no joy. I looked on the online documentation, no joy, I tried their mailing list, not even a reply so I took the bull by the horns and wrote my own Perl script to change all the shebang lines for me:
#!/opt/local/bin/perl
use strict;
print "\n\n";
# get the files in the directory
opendir(THISDIR, ".");
my @files = readdir(THISDIR);
closedir(THISDIR);
#loop through the files
foreach my $file (@files){
# skip files that are not cgi files
next unless $file =~ m/\.cgi$/;
print "Processing file: $file\n";
# get the contents
open(CGIFILE, "$file");
my @contents = <CGIFILE>;
close(CGIFILE);
# write it back out but with the correct shebang line
open(CGIFILE, ">$file");
if($contents[0] =~ m/^\#\!/){
print CGIFILE "#!/opt/local/bin/perl\n";
}else{
print CGIFILE $contents[0];
}
for(my $i=1;$i < scalar(@contents); $i++){
print CGIFILE $contents[$i];
}
close(CGIFILE);
}
print "\n\n";
This got Bugzilla up and running and talking ot the DB but desepite the fact that I had sendmail up and running on the server Bugzilla now had a hissy-fit each time you tried to add a bug or do anything that caused it to try to send an email. This is where the second retarded assumption made by the Bugzilla peeps was the culprit. firstly, their error reporting sucks donkey dick and was of no use at all so into the code I dived. After some poking around inside the source tree I figured the problem must lie within Bugzilla/BugMail.pm and sure enough in the last function of that file (line 868 of 876) I found this:
open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i")
Yup, they had hard-coded in the location of sendmail! Again, there is no way to set the location of sendmail in any config file I could find so I had to manually edit this line to look like this:
open(SENDMAIL, "|/usr/sbin/sendmail $sendmailparam -t -i")
Once that was done all was fine and Bugzilla is now working but I really shouldn’t have had to jump through so many hoops to get it working!