First impressions with Arch Linux

I have been considering for some time trying some Linux distro that would be a little faster than [[Ubuntu (operating system)|Ubuntu]]. I made the switch from [[Debian]] to Ubuntu some time ago, and I must say that I am very pleased with it, despite it being a bit bloated and slow. Ubuntu is really user-friendly. This term is often despised among geeks, but it does have a huge value. Often times a distro will disguise poor dependency-handling, lack of package tuning and absence of wise defaults as not having “fallen” for user-friendliness and “allowing the user do whatever she feels like”.

However comfortable Ubuntu might be, my inner geek wanted to get his hands a little bit dirtier with configurations, and obtain a more responsive OS in return. And that’s where [[Arch Linux]] fits in. Arch Linux is regarded as one of the fastest Linux distros, at least among the ones based on [[executable|binary]] [[Software package (installation)|packages]], not [[source code]]. Is this fame deserved? Well, in my short experience, it seem to be.

First off, let us clarify what one means with a “faster” Linux distro. There are as I see it, broadly speaking, three things that can be faster or slower in the users’ interaction with a computer. The first one, and very often cited one, is the [[booting|boot]] (and shutdown) time. Any period of time between a user deciding to use the computer and being able to do so is wasted time (from the user’s point of view). Many computers stay on for long periods of time, but for a home user, short booting times are a must. A second speed-related item would be the startup time of applications. Booting would be a sub-section of this, if we consider the OS/[[kernel (computing)|kernel]] as an “app”, but I refer here to user apps such as an e-mail client or text editor. Granted, most start within seconds at most, many below one second or apparently “instantly”, but some others are renowned for their slugginess ([[]], [[Firefox]] and [[Amarok (software)|Amarok]] come to mind). Even the not-very-slow apps that take a few seconds can become irritating if used with some frequency. The third speed-related item would be the execution of long-running CPU-intensive software, such as audio/video coding or scientific computation.

Of the three issues mentioned, it should be made clear that the third one (execution of CPU-intensive tasks) is seldom affected at all by the “speed” of the OS. Or it shouldn’t be. Of course having the latest versions of the libraries used by the CPU-intensive software should make a difference, but I doubt that encoding a video with [[MEncoder]] is any faster in [[Gentoo Linux|Gentoo]] than Ubuntu (for the same version of mencoder and libraries). However, the first two (booting and start up of apps) are different from OS to OS.


I did some timings in Ubuntu and Arch, both in the same (dual boot) machine. I measured the time from [[GRUB]] to [[GNOME Display Manager|GDM]], and then the time from GDM to a working [[desktop environment]] ([[GNOME]] in both). The exact data might not be that meaningful, as some details could be different from one installation to the other (different choice of firewall, or (minimally) different autostarted apps in the DE). But the big numbers are significant: where Ubuntu takes slightly below 1 minute to GDM, and around half a minute to GNOME, Arch takes below 20 seconds and 10 seconds, respectively.

App start up

Of the three applications mentioned, and Firefox start faster in Arch than in Ubuntu. I wrote down the numbers, but don’t have them now. Amarok, on the other hand, took equally long to start (some infamous 35 seconds) in both OSs. It is worth mentioning that all of them start up faster the second and successive times, and that the Ubuntu/Arch differences between second starts is correspondingly smaller (because both are fast). Still Arch is a bit faster (except for Amarok).

ABS, or custom compilation

But the benefits of Arch don’t end in a faster boot, or a more responsive desktop (which it has). Arch Linux makes it really easy to compile and install any custom package the user wants, and I decided to take advantage of it. With Debian/Ubuntu, you can download the source code of a package quite easily, but the compilation is more or less left to you, and the installation is different from that of a “official” package. With Arch, generating a package from the source is quite easy, and then installing it with [[Pacman (package manager)|Pacman]] is trivial. For more info, refer to the Arch wiki entry for ABS.

I first compiled MEncoder (inside the mplayer package), and found out that the compiled version made no difference with respect to the stock binary package. I should have known that, because I say so in this very post, don’t I? However, one always thinks that he can compile a package “better”, so I tried it (and failed to get any improvement).

On the other hand, when I recompiled Amarok, I did get a huge boost in speed. A simple custom compilation produced an Amarok that took only 15 seconds to start up, less than half of the vanilla binary distributed with Arch (I measured the 15 seconds even after rebooting, which rules out any “second time is faster” effect).

Is it hard to use?

Leaving the speed issue aside, one of the possible drawbacks of a geekier Linux distro is that it could be harder to use. Arch is, indeed, but not much. A seasoned Linux user should hardly find any difficulty to install and configure Arch. It is certainly not for beginners, but it is not super-hard either.

One of the few gripes I have with it regards the installation of a graphical environment. As it turns out, installing a DE such as GNOME does not trigger the installation of any [[X Window System]], such as [[ Server]], as dependencies are set only for really vital things. Well, that’s not too bad, Arch is not assuming I want something until I tell it I do. Fine. Then, when I do install Xorg, the tools for configuring it are a bit lacking. I am so spoiled by the automagic configurations in Ubuntu, where you are presented a full-fledged desktop with almost no decision on your side, that I miss a magic script that will make X “just work”. Anyway, I can live with that. But some thing that made me feel like giving up was that after following all the instruction in the really nice Arch Wiki, I was unable to start X (it would start as a black screen, then freeze, and I could only get out by rebooting the computer). The problem was that I have a [[Nvidia]] graphics card, and I needed the (proprietary) drivers. OK, of course I need them, but the default vesa driver should work as well!! In Ubuntu one can get a lower resolution, non-3D effect, desktop with the default vesa driver. Then the proprietary Nvidia drivers allow for more eye-candy and fanciness. But not in Arch. When I decided to skip the test with vesa, and download the proprietary drivers, the X server started without any problem.


I am quite happy with Arch so far. Yes, one has to work around some rough edges, but it is a nice experience as well, because one learns more than with other too user-friendly distros. I think Arch Linux is a very nice distro that is worth using, and I recommend it to any Linux user willing to learn and “get hands dirty”.

Comments (3)

Making iSight camera work in Ubuntu

As I said in a previous post, I bought a [[MacBook]], and I am making all bits work correctly. Out-of-the-box support from Ubuntu (the only GNU/Linux I tried on the MacBook so far) is excellent, but some things (camera, WiFi…) need proprietary drivers, so some more tweaks are needed.

I have followed the instructions in the Ubuntu community site, as with the procedures detailed in the previous post.

Basically, it all boils down to:

Fetch the Apple drivers for the camera

As root (if, unlike me, you like sudo, then run the following as user, but prepended with sudo), mount the Mac OSX partition (you didn’t delete it, right?) and copy the relevant file somewhere else (the cp command should be all in one line):

# cd
# mkdir /mnt/macosx
# mount /dev/sda2 /mnt/macosx
# cp /mnt/macosx/System/Library/Extensions/
     Contents/MacOS/AppleUSBVideoSupport .
# umount /mnt/macosx

You might have noticed that the Mac OSX partition is not sda1, but sda2. Don’t ask me. It turns out like this after following my own installation instructions. Apple must have decided to install the OS in the second partition for some reason.

Install the required packages

We need a package called isight-firmware-tools. Unfortunately it is not present in the Hardy repos at the moment (it was in the Gutsy ones, I think). You can add a Launchpad repo, editing /etc/apt/sources.list to add:

deb hardy main
deb-src hardy main

Then, as root:

# aptitude update
# aptitude install isight-firmware-tools

You will be prompted for a path to the driver you copied before. You can press Enter without paying much attention, then execute (assuming you copied the driver to your root home):

# cd
# ift-extract -a ./AppleUSBVideoSupport

To activate the driver, restart [[HAL (software)|HAL]]:

# /etc/init.d/hal restart

Test it with [[Ekiga]]

As explained in the Ubuntu community site, you can run Ekiga as user (after installing the ekiga package). Choose V4L2 as video plugin, and Built-in iSight should appear among the Input device list. If it does, the process worked.

Comments (22)

Installing Ubuntu Hardy Heron on a MacBook

Yes, dear reader, I committed the heresy of purchasing an Apple [[MacBook]]. I obviously didn’t do it for MacOS X, for which I couldn’t care less, but for the hardware, which is quite good. I was looking for a laptop as small as possible, keeping price low (it cost 799 eur), and screen not too small (this one has a 13″ one. Maybe even 12″ is acceptable. 13″ sure is).

You can see some pictures of it at my MacBook gallery.

If you, like me, are used to PCs, then there are a few things to note:

  • It has a different layout in the keyboard. Most prominently, some keys are missing: Del, PgUp, PgDn, Home, End. Some others (Win key, AltGr) have substitutes that can be mapped. Also the equivalent to AltGr and right Ctrl are kind of swapped: the key closest to the SpaceBar is right “cmd” (could be right Ctrl), and the farthest one is left “alt” (could be AltGr)
  • The [[touchpad]] has a single button, and tapping on it won’t click. There is no zone on it to use as vertical scroll, either. Luckily the latter can be fixed via software, so that in Ubuntu the touchpad does behave correctly: you can tap-click, and you can scroll with a smooth movement of a finger. The single-button issue is not present in USB mice: they work “normally”.

I would like to outline here the process of installing Ubuntu (Hardy Heron) in this machine. For that, I recommend reading (as I did), the following links:

Repartition of the hard disk

My Mac came with 120 GB (109 real) of HD, all of it devoted to OS X. Unfortunately, the Ubuntu installer can not cope with resizing of [[HFS Plus|HFS+]] partitions. Fortunately, OS X itself can. You can make use of [[Boot Camp (software)|Boot Camp]] as follows: go to Go->Utilities->Boot Camp Assistant. There you can (should) reduce the existing HFS+ partition to the bare minimum (in my machine it was 22GB, because OSX already uses 17GB, and it won’t accept less than 5GB of free disk). Leave the rest unassigned, and quit.

Installation of multi-boot system

The first hurdle in our Linux installation is that the Mac machines do not have a “normal” [[BIOS]]. The BIOS is important for Linux/Windows installations, so this is a drawback. Macs come with a thingie called [[Extensible Firmware Interface]] (EFI), instead. However, there is a nice little tool called rEFIt that can help us with it.

To install rEFIt, you can follow the instructions at its Sourceforge site. I followed the Automatic Installation with the Installer Package instructions. Basically I downloaded the Mac disk image from the download page, opened in the Mac OSX file browser, double-clicked it to open it, then double-clicked on the rEFIt.mpkg file inside, and followed the instructions.

This will make the rEFIt menu appear in the next reboot, but only if you hold some key while booting (I think it’s “C”). If you want the menu to always appear, do the following in a terminal, inside Mac OSX:

% cd /efi/refit
% ./

Installation of Linux OS

After doing the above, you should reboot with an Ubuntu installation CD inserted. If the EFI installation was correct, you will be presented with the rEFIt menu, in which you will have two big icons (OSX and the Linux CD), and five small ones below (“Start EFI Shell”, “Start Partitioning Tool”, “About rEFIt”, “Shut down computer” and “Restart computer”).

Use the left-rigth arrow keys to select the Ubuntu CD, and press Enter. At that moment, or after installing Ubuntu (I don’t recall), the computer could complain saying: “No bootable device — insert boot disk and press any key”. If so, reboot and, in the aforementioned rEFIt menu, choose the second small icon, “Start Partitioning Tool”. This tool will prompt you to update the [[Master boot record|MBR]]. Accept, and let it do its magic.

When booting with the CD, you will have the option to make an absolutely normal Ubuntu installation. The Ubuntu MacBook page says that Boot Camp will complain if you make more than two partitions in total. It will, but for me this is ridiculous, since OSX is already eating up one. There’s no way I will install any Linux in a single partition (withouth even swap!). If you do not care about opening Boot Camp ever again (I don’t), do a totally normal install. I created two 8.5GB partitions for / (one for Ubuntu, another one unused for the future), a 750MB swap partition, and the rest (73GB) as /home (potentially shared among the two Linux I could install).

After the installation, reboot and you will find the aforementioned rEFIt menu. Choosing the penguin icon on the right side will take you to the [[GNU GRUB|GRUB]] screen you probably are accustomed to. What this means is that you have to go through two boot menus when booting, but that’s a minor issue, I think. The first menu is an EFI menu, in which you choose OSX or GRUB. The second one is the GRUB menu that lets you choose among different installed kernels.

And I think that’s it…

I will keep on writing when I have time, at least about how to make WiFi work, and also how to configure [[Compiz Fusion]]. Yes, the X3100 graphics chip that the MacBooks carry is blacklisted, as not working with CF. But, believe me, it does work!

Comments (6)

A hurdle in the instalation of Ubuntu Hardy Heron

I decided to give a try to Ubuntu Hardy Heron, and installed the [[amd64]] version of it in my laptop.

My gripe is caused by a really annoying issue with the installation in a multiboot system. I have a laptop with four root partitions (Windows, Debian, Fedora and Ubuntu), and obviously [[GRUB]] generates the menu that allows me to choose at boot time. The file that GRUB reads is /root/grub/menu.lst, at /dev/sda5 (the Fedora partition, which was the last one).

The annoying issue I mention is that the installation is absolutely smooth but a [[bootloader]] is not installer. What this means is that when I reboot the computer after installation, I always get the old GRUB menu, and the new OS does not appear in the list.

The only solution I found is to do the following:

  1. Do a normal install of Ubuntu, but do not reboot
  2. Open a console (after installation Ubuntu lauches a GNOME live session)
  3. Locate the kernel and initrd images I need. They are, respectively: /target/boot/vmlinuz-2.6.24-16-generic and /target/boot/initrd-img-2.6.24-16-generic.bak
  4. Mount /dev/sda5 into /mnt/root3
  5. Edit /mnt/root3/boot/grub/menu.lst (the old GRUB menu), and add the lines:
  6. title --------- Ubuntu 8.04 TLS Hardy Heron - sda6 ----------

    title Ubuntu Hardy Heron - kernel 2.6.24
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.24-16-generic root=/dev/sda6 ro quiet splash
    initrd /boot/initrd.img-2.6.24-16-generic.bak

  7. Reboot

After that, the new Ubuntu appears in the GRUB list.

The procedure is not incredibly difficult, but for a beginner it would be a major showstopper. And, in any case, it is a really sad error.

Comments (3)

Compiz Fusion under Debian Lenny on my laptop

I have a previous post with what I’ve done to my laptop, and in that post it’s not mentioned, but I managed (quite a while ago) to make Beryl work under Ubuntu Dapper Drake. Dapper is getting older, but I am not having good experiences installing Edgy and Feisty on the laptop. I have managed to install Debian Etch with no problem, but the wireless driver was not working properly (for me, a showstopper) until Lenny.

So now I have a Debian Lenny partition, plus three other: the original WinXP, the Ubuntu Dapper I am still using as “main” OS, and a Fedora 7 I installed just because it came in a DVD with a magazine I bought for a train trip I had not brought any reading material with me :^)

Since I am on vacation, and I have plenty of time (although I don’t want to spend all of it on my comp), I decided to give Compiz Fusion a try, mostly after seeing what it its capable of.

First things first, the specs of my laptop are:

Fujitsu-Siemes Amilo PI1536
CPU: Intel Core 2 Duo T7200 2×2.0GHz
RAM: 2x1Gb
HD: 120Gb SATA
Display: 15.4 WXGA
Graphics: ATI Mobility Radeon X1400 (128Mb dedicated/512Mb shared)

The only relevant parts above are that it has an ATI graphics card (which, under Linux, sucks), and that it has Core 2 CPUs, which are amd64-capable (which is both great, for performance, and sucks, for drivers and software compatibilities). So, my second step was:

Installation of ATI drivers

If you want to take the best out of your ATI card, you have to tell your graphics server to use the fglrx driver, and not the default vesa one. You can install this driver from the official Debian repositories, but for me those packages (fglrx-driver and related ones) didn’t do it.

So, I googled a bit, and followed the most widespread recommendation: to install the latest non-free (sigh) driver from the ATI site. For that, I chose the options: Linux x86_64 -> Mobility Radeon -> Mobility Radeon X1400 -> Go, reaching this page, and downloading this 38MB binary (for the record, the 32bit version of the drivers is exactly the same .run file).

Next, I followed the remaining information in this excelent thread in Namely, I downloaded the needed packages (the code is copy-paste-able):

% aptitude install module-assistant build-essential dh-make debhelper debconf libstdc++5 linux-headers-$(uname -r) ia32-libs

Beware that the ia32-libs packages is not mentioned in the thread (assuming that you already have it installed), but it is required.

Next, run the ATI binary inside a dedicated directory (I did it as root, but it is not compulsory):

% mkdir /root/fglrx
% cd /root/fglrx
% mv wherever-I-downloaded-it/ .
% chmod +x
% ./ --buildpkg Debian/lenny
% rm or mv the .run file wherever you want

This generates a bunch of .debs in the /root/fglrx dir. Next, install them, and compile the driver (for this, you do need to be root):

% dpkg -i fglrx-*.deb
% cd /usr/src
% m-a prepare
% m-a a-i fglrx

The thread mentions modifying the /etc/X11/xorg.conf file in two ways. First, disable compositing, adding:

Section "Extensions"
Option "Composite" "Disable"

to it, and then running:

% aticonfig --initial
% aticonfig --overlay-type=Xv

For me, both were superfluous, because I made a copy of my Ubuntu xorg.conf, and them made minimal changes (if at all). However, the first change (disabling compositing) was straightforward wrong. If I want to use Compiz Fusion, I need to have it. Relevant excerpts from my xorg.conf:

Section "Module"
  Load  "i2c"
  Load  "bitmap"
  Load  "ddc"
  Load  "dri"
  Load  "extmod"
  Load  "freetype"
  Load  "glx"
  Load  "int10"
  Load  "type1"
  Load  "vbe"


Section "Device"
  Identifier  "aticonfig-Device[0]"
  Driver      "fglrx"
  Option      "VideoOverlay" "on"
  Option      "OpenGLOverlay" "off"


Section "Screen"
  Identifier "aticonfig-Screen[0]"
  Device     "aticonfig-Device[0]"
  Monitor    "aticonfig-Monitor[0]"
  DefaultDepth     24
  SubSection "Display"
    Viewport   0 0
    Depth     24
    Modes    "1280x800" "800x600" "640x480"


Section "DRI"
  Mode         0666

Section "Extensions"
  Option "Composite" "1"

After all this fuss, and to ensure you have it all running OK, try to insert the module as root:

% modprobe fglrx

Then, make sure it loads everytime you reboot (include it in /etc/modules if necessary, but it shouldn’t be).

Next, reload the X server, and check that now it is running the fglrx driver, by doing the following (as user is fine):

% fglrxinfo

It should display something like the following:

display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.0.6650 (8.39.4)

If, instead, it says something about mesa3d, it didn’t work.

Now, the second step is…

Installing Xgl

With the standard server we have a problem. We can load the fglrx driver, but we can not activate compositing (see last three lines of my xorg.conf file above). If we activate compositing in the xorg.conf file, the ATI driver will not be loaded (don’t ask me why, it just seems to happen). If we deactivate compositing, the ATI driver gets loaded, but without compositing, we can not use Compiz.

The solution is to install Xgl which is an X server (or, I think, a kind of layer that runs on top of the server) that allows for the above trick. There seem to be two “ways” of getting proper compositing: Xgl and AIGLX. The general agreement on the net seems to be that the latter is “better”, but only the former seems to work with ATI cards (read the “AIGLX with AMD (ex-ATI) Proprietary Drivers” section in the AIGLX Wikipedia article, because it hits the problem dead-on). With Xgl I can make use of the fglrx driver and have compositing at the same time.

We are lucky here, because there are Debian repositories for Xgl. I found out about them in this howto in Most of the info there is mostly… ehem… useless (for me), but reading it I found a repo for Xgl. I just have to add the following line to my /etc/apt/sources.list (beware that the original mention in the page says “binary-i386”, and I had to change it to “binary-amd64”):

deb binary-amd64/

I then had to do aptitude update, and I (of course) got an error telling me that some signatures couldn’t be verified (read my own article about secure APT and/or the wonderful Debian wiki to know more). I think the key is 11F6E468, and it corresponds to Francesco Cecconi (mantainer of the repo). It is downloadable from (follow instructions on my previous post, or the ones in the Debian wiki). If you want, do not skip reading the parent page of the repository.

After the keys are OK, it’s just a matter of doing (as root):

% aptitude update
% aptitude install xgl

Now you are done installing, but will have to actually use Xgl. This gave me some headaches, not because I didn’t know where to put things, but because I didn’t know exactly what to put. I read, and followed, the instructions in, and (after all, the blog seems to be useful for someone: myself) a previous post of my own.

I am using GDM, so my final setup was the following: first generate a suitable entry in the GDM menu, by creating a file named /usr/share/xsessions/xfce4-xgl.desktop (or whatever, but in the same dir, and ending in “.desktop”), and putting the following inside:

[Desktop Entry]

The string after “Name=” is the one that will appear in the GDM menu, and the one after “Exec=” what will be executed when selecting that entry.

Next, we have to create the string we promise above (/usr/local/bin/startxgl_xfce), and put the following inside:

# Start the Xgl server:
Xgl -fullscreen :0 -ac -accel glx:pbuffer -accel xv:pbuffer -fp /usr/share/X11/fonts/misc & sleep 5 && DISPLAY=:0
# Start Xfce:
exec xfce4-session

As you can see, I am telling Xgl to load a font (with -fp) that was giving me headaches, because the server would die saying that the font was missing when I didn’t include that option. Your mileage may vary.

Now, everytime we select the entry labeled “Xfce-Xgl” in the GDM menu, we will have the Xgl server running.

Installing Compiz Fusion packages

I think the aforementioned repo has compiz packages, as well as the default Debian Lenny repos. But net consensus seems to be that they are not the way to go. Everyone praises two repositories: Treviño’s and Shame’s. I chose the latter, adding the following line to my /etc/apt/sources.list:

deb ./

I think I went through the same chores as above for key verification, Shame’s key being A42A6CF5.

After that, I installed the following package (it installs all of the needed packages):

% aptitude install compiz-fusion-all

After that, and inside my “Xfce-Xgl” session, I just did the following, as some googling revealed:

% compiz --replace

But… it didn’t work :^( It complained in the following manner:

Fatal: Failed test: texture_from_pixmap support
Checks indicate that it's impossible to start compiz on your system.

I found a lot of pages, threads and howtos in the net stumbling upon this same problem (for example, this one at, but none with the answer. Really. None. The most enlightening tips where the use of the -v, -h and --help switches for compiz. The first one requests verbose output, the second one help about “short” options, and the third one help about the “long” options. With the latter I discovered the --force-fglrx switch, which saved the day! Yes, I now use the following command to start Compiz:

% compiz --replace -c emerald --force-fglrx

I have two things to say at that point. First: this Compiz Fusion is visually astonishing! It is full of great ideas, and has a lot of settings to play with. The second thing is not so nice: some glitches are present. For example, my Konsole windows get transparent background for no reason, and the refresh is horrible (when text reaches the bottom on the terminal, it starts to overwrite itself. One must hide and un-hide the window for proper refreshing, which is unacceptable). The latter also affects other windows, which, all in all, makes it unsuitable for much comfort.

However, Compiz Fusion is new, hot and experimental. I love playing with it, but right now it can not be relied upon. On the bright side, in the three days from my installation, the packages have been updated three times! I suppose some aptitude upgrade cycles will fix the issues eventually.

And that’s it, dear reader.

Comments (6)

What I’ve done to my laptop

OK, this entry is just a reminder for myself.

Install ATI drivers

I followed the instructions at this wiki. For the record, I used method 1, and it worked.

Update: The link above seems dead. Read a a more recent post about Compiz Fusion under Debian Lenny for info on ATI drivers instalation.

Install a SMP kernel

My CPU is an Intel Core 2 Duo T7200… I want a SMP kernel, otherwise I am wasting one of the two cores!

Problem is, the friggin Ubuntu has no 2.6 kernels labeled “SMP”. Why, oh why!? OK, I found out: all 2.6.*-686 kernels are actually SMP, even if they don’t say anything. If you have 1 CPU, fine. If you have more, they’ll be detected at boot time. No more “-smp” in the kernel names.

Wireless with 686 kernel

The default 2.6.15-686 supports the wireless just fine, but installing a 686 kernel (required for SMP, see above) seems to break the wireless. However, the solution is easy. As stated in this Ubuntu forum thread, one just needs to install the “restricted” kernel modules corresponding to her kernel (in my case 2.6.15-27-686):

% aptitude install linux-restricted-modules-2.6.15-27-686

After that, reboot. I guess that the new module is loadable (try modprobe ipw3945), without having to reboot… dunno. Also, if you want to have the restricted modules package upgrade automatically, install linux-restricted-modules-686.

WPA encription for WiFi

Update: Read a more recent article: WPA under Ubuntu/Debian.

Install a 64-bit kernel

OK, installing the mainstream 32-bit Ubuntu was a success. Now I have given Ubuntu amd64 a try (amd64 is for both EM64T (Intel) and AMD64 (AMD)).

Everything went smooth, except installing the ATI drivers (as explained above): the screen froze black when loading GDM. To solve this, I read the troubleshooting section in the link above, and found out that I could either add:

Load "extmod"


SubSection "extmod"
  Option "omit XVideo"
  Option "omit XVideo-MotionCompensation"
  Option "omit XFree86-VidModeExtension"

to the Section "Modules" of /etc/X11/xorg.conf (beware, it’s one OR the other, not both). For me the Load "extmod" did not work, but the SubSection "extmod" did.

Now, for the Xgl thing in 64-bits…

Xgl for 64-bits

I followed the instructions in a previous post, but I found out that some packages were missing, so I manually downloaded them from the Xgl.compiz site. Namely, I downloaded them from the “Edgy” section. However, it didn’t work for me :^(

Update: Compiz Fusion under Debian Lenny in a more recent post.

Comments (2)

GParted and my laptop

OK, yesterday I bought a laptop (my first ever), and I am so excited about it! It’s specs:

Fujitsu-Siemes Amilo PI1536
CPU: Intel Core 2 Duo T7200 2×2.0GHz
RAM: 2x1Gb
HD: 120Gb SATA
Display: 15.4 WXGA
Graphics: ATI Mobility Radeon X1400 (128Mb dedicated/512Mb shared)

I chose it for its high quality CPU, and half-decent graphics card. It turns out most sellers have a large Core Duo stock, but a pitifully short list of Core 2 Duo models. Hence, they want to sell their already outdated Core models, and offer little choice in Core 2s (and a bit higher prices, although Intel sells them both at similar prices). The little choice in Core 2 Duos made it difficult to me to find what I was looking for, but I finally did.

However, this post is not only dedicated to spread my happiness. I also wanted to praise the Free Software program GParted, which I just used.

As any laptop+Linux user has experienced, usually Windows is pre-installed and shipped with the computer. In my case, I wanted to have it, so no problem with that. The bad part is that, of course, the whole hard disk is usually a single partition, with Windows being in it. Since I wanted to install Linux also, I had to make partitions. Although the laptop came with CDs for all the software that comes pre-installed (Windows included), I wanted to try to resize the Windows partition, and make room for the other partitions, without destroying the Windows installation.

I downloaded an Ubuntu ISO, burned it, then restarted the laptop with it. Good thing of Ubuntu is that its CD is a Live CD, which means that can be run without installing anything in the hard disk. Ubuntu started flawlessly, and I was presented with a GNOME desktop. There, I started GParted, and a simple, yet visually pleasing, GUI opened, and I point-and-clicked all the settings, which took me from:

1x 111Gb partition under NTFS


1x 15Gb (NTFS)
1x 512Mb (swap) probably wasted disk, but oh well…
3x 10Gb (ReiserFS)
1x 50Gb (ReiserFS)
1x 18Gb (NTFS)

This way, the second NTFS partition can be used to store files Windows can access (I have to try if Linux can access that. If not, I’ll reformat with FAT32), and I still have room for three Linux distro installs (10 Gb Reiserfs), and a big home/ that all Linux-es can share.

Now, the delicate part… rebooting into Windows. I held my breath while the computer rebooted, but it did so fine. Windows started without problem, it just performed a disk integrity check at startup (which finished OK), and then said it had found new hardware, which turned out to be the second NTFS partition (the E: drive now). As we are used to with the stupid Windows, I was told to reboot to have the system recognize the recently-discovered hardware. So I did, and it worked!

Now Windows is installed in the 15Gb NTFS partition (and recall I didn’t reinstall anything. What was there, is still there), and sees a second 18Gb partition. As for Linux, I am looking forward to installing Debian, Ubuntu or something…

Comments (3)