Ubuntu on Intel iMac Review

 Computing  2 Responses »
Feb 262009
 

Yes I know everyone and their dog has already written a review of the Intel iMac, but I have not done so yet. This is a review of the 24″ iMac (and I’m already hating that incorrect capitalisation) with the specific intent of putting Ubuntu on. This is not some kind of weird anti-OSX statement; I already have a laptop with OSX installed on it and it does seem like a fun operating system.

But this is a replacement for my main desktop, and I really want a “proper” Unix on it, and Linux will do in the meantime.

First Thoughts

First of all, the screen stand should allow adjustment in the vertical direction; already I can see myself getting out an extremely old and manky tape drive to sit underneath to raise the screen to an appropriate height. Apple ? Your lack of foresight in not including height adjustment is ruining the look of the system!

Nice keyboard! If you do not type much. I am aware that some people really like the skinny Apple keyboards, but it is not for me even though they got off to a good start by not including Windows keys. Back to the Das Keyboard for me I think. The mouse is similar – there’s this nice funky ball on top which is an improvement over the usual scroll wheel (although I am not too sure how well it would work at speed), but just not enough buttons.  Or at least it does not feel like enough buttons. The “one button” with two effects method as appears to be the case here is a little odd and off-putting.

Perhaps Apple needs a special country kit – “Special Clicky Keyboard And Mouse With Too Many Buttons For The Unix Geeks”. How many people end up using a non-Apple keyboard and mouse ? Perhaps not many, but why not cater to them with alternative keyboards and mice ? My Apple keyboard and mouse will be mostly unused.

Where are the memory card slots though ?  It would make things a bit more complete (and the iMac is about one box doing everything) if there were a sensible selection of memory card slots.

In terms of software (and not OSX itself), one thing becomes immediately apparent when booting (and on previous occasions when trying to boot from CD, diagnosing booting problems, etc.). The Apple firmware breaks the first rule of user interface design! Not something you expect Apple to do.

The firmware needs to be just a little bit more expressive about what is going on. You may well be thinking that as a hardcore Unix geek I want to see inscrutable messages from the firmware about initialising that chipset, addresses of where adapter cards are, cpu values, etc. And of course you are right.

But basic messages about starting the hardware would still be helpful.

More importantly however, the Apple firmware should be letting you know what keystrokes are needed to do “unusual” things like boot from a CD, an external hard disk, start the hardware diagnostics, etc. One of the most irritating things about Apple hardware is the need to provide secret incantations to boot from CD  – you hold the “C” key down for “a while” (how long anyway?).

The Install

At this point the “unusual” choices of Apple bite you when it comes to installing a version of Linux intended for use on mainstream PCs. First you have to install rEFIt, then you install Linux off CD (and mess around with the MBR partition table), then have to remember to “resync” the partition tables.

Seems there’s an EFI partition table and an MBR partition table that need keeping in sync. Having two partition tables immediately strikes me as a dumb idea. When Windows is involved, there is probably no fix for this problem, but why is Linux still not doing things properly ? Or at least not doing the sensible thing by default.

It also means there is effectively a two step boot process – first rEFIt starts, then then starts grub which finally starts Linux; this is not a quick system to boot.

Fixing The Niggles

In any install, there are always little niggles that need fixing. The most obvious is a way to control the brightness of the screen which by default is far too bright. There may well be better solutions out there, but a bit of C coming from http://www.felipe-alfaro.org/blog/2006/09/11/basic-backlight-support-for-macbook-pro

A quick compile and install in /opt/bin/bl and root can set the backlight brightness with :-

bl (1-15)

Adding this in an appropriate way to /etc/rc.local ensures that the backlight is set on every boot.

It also appears that we need to do a bit of hacking to support the sound properly. Adding an option to /etc/modprobe.d/options specifies the “model” of soundcard we are using to get sound working :-

options snd-hda-intel model=imac24

A quick reboot and sound is working (microphone not tested!).

For some reason the module that is used to gain access to the iMac temperature probes is not loaded automatically. Adding applesmc to the end of /etc/modules gets this loaded (after a reboot or manually with modprobe applesmc). Unfortunately there does not appear to be an immediately obvious way of using this except from the command line.

The wireless network controller apparently works after the addition of the proprietary driver that shows up after doing an update. Admittedly I cannot say for sure because I use a wired setup.

Lastly the IR receiver. I will admit this has currently defeated me although that is partially because I am not that interested. I will of course update this if I get it to work.

Later: Screen Calibration

I later took a look at setting up the screen properly. Proper controls for the screen would have been nice, but configuring from the system turns out to be relatively easy.

First of all I used the OSX screen calibration tool in “expert” mode to generate in ICC file containing the screen profile. Doing this may well be possible inside Ubuntu; I just happened to know where the tool was in OSX.

I then installed xcalib :-

apt-get install xcalib

This could be used to set the monitor profile from the earlier generated ICC file.

Conclusion

It works. After a week or so using it, I am no longer thinking of the iMac as a system being installed and tested but as my standard desktop.

Solaris – Always Mount All ZFS Filesystems In Single User Mode

 Computing  2 Responses »
Feb 252009
 

Traditionally I have always mounted just the filesystems I needed in single user mode whilst tinkering in Solaris. Turns out this is a dumb method for ZFS filesystems.

What happens is that the zfs mount command will create any directories necessary to mount the filesystem. Later this can stop other ZFS filesystems from mounting when the tinkering is finished. This could be an argument for not creating hierarchies of filesystems, but that’s rather extreme.

The better solution is to mount all the ZFS filesystems in one go with :-

zfs mount -a

Revisiting Unix Basics: The df Command

 Computing  No Responses »
Feb 082009
 

I was reading a comment about the df command (in relation to reserved filesystem space) and realised that the clueless newbie was right; it is odd that df does not mention reserved space. Of course it would also be wrong for df to lie about the matter too. I then realised that df is long overdue for a bit of refreshing. If you look at the typical output of the df command, you will find it inconveniently cluttered :-

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/datavg-810root
                       12G  7.8G  4.3G  65% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
varrun                2.0G  416K  2.0G   1% /var/run
varlock               2.0G     0  2.0G   0% /var/lock
udev                  2.0G  3.1M  2.0G   1% /dev
tmpfs                 2.0G  344K  2.0G   1% /dev/shm
lrm                   2.0G  2.4M  2.0G   1% /lib/modules/2.6.27-7-generic/volatile
/dev/sdb1             130M   36M   88M  29% /boot
/dev/mapper/datavg-opt
                      2.0G  776M  1.3G  39% /opt
/dev/mapper/datavg-810var
                      5.0G  1.4G  3.7G  28% /var
/dev/mapper/datavg-home
                      256G  116G  141G  46% /home
/dev/mapper/datavg-vmachines
                       96G   62G   35G  64% /vmachines
/dev/mapper/datavg-bragspool
                      256G  6.2G  250G   3% /var/spool/brag
/dev/mapper/datavg-herpesbackup
                       16G  4.6G   12G  29% /var/herpes
/dev/sda1             463G  147G  293G  34% /mdata
/dev/scd0             2.4G  2.4G     0 100% /media/CIVCOMPLETEEU
/dev/mapper/datavg-cdimages
                       32G  1.9G   31G   6% /cdimages
/dev/mapper/datavg-ontapsim
                       16G  498M   16G   4% /sim

Part of the problem is that df does not do quite what it claims to do … to report free space on the mounted filesystems. It also gives some (a very small amount) of additional information about the relevant filesystems … particularly the device the filesystem is mounted on. This “helps” to make the output more cluttered that it needs to be. It is possible that there are those who will argue that the device is the filesystem and not where it is mounted; they are arguably right, but when you use df you are either looking at where in the Unix file hierarchy there are places that have less space than is comfortable, or for places that have enough space to put that big file you are about to download.

Next the command itself has an obscure command to make it easier to type on a slow type-writter like terminal (those who are below a certain age will not realise that we used to comminicate with Unix machines using a terminal that was more like a printer than the screens we use today). It might be better named fsspace with an alias of diskspace for those who want to concentrate on what worries them rather than on what worries the machine.

Next why not take advantage of certain features that have crept almost silently into the command line over the last few decades ? Why not adjust the output to the width of the terminal window (look for the $COLUMNS evironment variable), spacing things out or even adding more information when you have enough space?

Finally if you were to dig around the df command a little bit you will encounter something peculiar called “inodes”. Now I know what an inode is, and I dare say quite a few people reading this will know, but if you do not, knowing how many inodes there are is not very useful information. It is relatively rare (these days) for a filesystem to run out of inodes so this information has a low priority, and why not use a term more understandable than “inodes” ?

Changing a term is something to be avoided in most circumstances which is why we still have “inode” where even the originator of the term has to guess that the “i” means “index”. I would suggest that something like “fileslots”or perhaps “fslots”

We now have the basic specification of something that should look like :-

% diskspace
Filesystem                            Size  %Used %fslots  Avail
/                                      12G    70%      3%   3.6G
/lib/init/rw                          2.0G     0%      0%   2.0G
/var/run                              2.0G     0%      0%   2.0G
/var/lock                             2.0G     0%      0%   2.0G
/dev                                  2.0G     0%      1%   2.0G
/dev/shm                              2.0G     0%      0%   2.0G
/lib/modules/2.6.27-7-generic/vola+   2.0G     0%      0%   2.0G
/boot                                 130M    29%      0%    88M
/opt                                  2.0G    40%      1%   1.2G
/var                                  5.0G    18%      0%   4.1G
/home                                 256G    52%      0%   124G
/cdimages                              32G    65%      0%    12G
/mdata                                463G    36%      1%   280G

This could be improved in some ways – for instance it would be helpful to skip over certain of the filesystems that are not strictly speaking backed by disk. However it is beginning to be useful.

Or would be if the code exists. Fortunately it does.

Passwords Are Dumb …

 Computing  No Responses »
Jan 142009
 

But not writing them down is dumber.

Supposedly we are not supposed to write down passwords, but who can remember hundreds of passwords ? In the distant past where the advice to not write down passwords was first suggested most users would have had just a few passwords.

Gradually things become more IT-orientated, and users would start complaining about the number of passwords they had to remember.

And we made things simpler for them by coming up with single-sign on mechanisms. Which was the wrong thing to do. Yes it makes things easier, but now a single compromised password will open up many different systems.

And of course we have the web with zillions of web sites that insist that each are important enough to have a unique account for. More passwords to “remember”.

Trying to tell people not to write passwords down is in the end going to reduce security. Firstly users will use the same password in many places so that they have fewer passwords to remember, and secondly they will write those passwords down. Why not let them do it right ?

So how can password be written down securely ? Well the first possibility is to use a secure password store so that passwords are held in an encrypted form. The second is to write them down using a consistent system to encode the passwords in some way (for example adding 1 to every digit, and moving each letter down 1) and splitting the usernames and passwords into seperate lists.

And of course encourage them to use different passwords in different places so that if one becomes compromised they will only have one site broken into.

But is it time to move on from passwords ?

We (as users) do not really want to enter passwords to use things. The login screen is an interruption in the flow of activities. We need something that will allow a distant server to establish the identity of ourselves without a login screen. Preferrably using something similar to Kerberos.

This will probably require an initial authentication process. Again the use of passwords should be avoided (except for critical services such as banking). Why not use some form of biometrics ?

Solaris, ZFS, and LVM

 Computing  No Responses »
Jan 082009
 

If you think that you can use a ZFS volume as a Solaris LVM metadevice database, you will be wrong. Whilst it works initially, the LVM subsystem is initialised before ZFS this cannot find the databases. Whilst this may seem to be a perverse configuration at least one administrator has tried it – being me!

 Older Entries  Newer Entries