The Linux Experiment

Well it’s been a couple of months now since the start of Experiment 2.0 and I’ve had plenty of time to learn about Gentoo, see its strengths and… sit waiting through its weaknesses. I don’t think Gentoo is as bad as everyone makes it out to be, in fact, compared to some other distributions out there, Gentoo doesn’t look bad at all.

Now that the experiment is approaching its end I figured it would be a good time to do a quick post about my experiences running Gentoo as a day-to-day desktop machine.

Strengths

Gentoo is exactly what you want it to be, nothing more. Sure there are special meta-packages that make it easy to install things such as the KDE desktop, but the real key is that you don’t need to install anything that you don’t want to. As a result Gentoo is fast. My startup time is about 10-20 seconds and, if I had the inclination to do so, could be trimmed down even further through optimization.

Packages are also compiled with your own set of custom options and flags so you get exactly what you need, optimized for your exact hardware. Being a more advanced (see expert) oriented distribution it will also teach you quite a bit about Linux and software configuration as a whole.

Weaknesses

Sadly Gentoo is not without its faults. As mentioned above Gentoo can be whatever you want it to be. The major problem with this strength in practice is that the average desktop user just wants a desktop that works. When it takes days of configuration and compilation just to get the most basic of programs installed it can be a major deterrent to the vast majority of users.

Speaking of compiling programs, I find this aspect of Gentoo interesting from a theoretical perspective but I honestly have a hard time believing that it makes enough of a difference to make it worth sitting through the hours days of compiling it takes just to get some things installed. Its so bad that I actually haven’t bothered to re-sync and update my whole system in over 50 days for fear that it would take forever to re-compile and re-install all of the updated programs and libraries.

Worse yet even when I do have programs installed they don’t always play nicely with one another. Gentoo offers a package manager, portage, but it still fails at some dependency resolution – often times making you choose between uninstalling previous programs just to install the new one or to not install the new one at all. Another example of things being more complicated than they should be is my system sound. Even though I have pulseaudio installed and configured my system refuses to play audio from more than one program at a time. These are just a few examples of problems I wouldn’t have to deal with on another distribution.

-Sigh-

Well, it’s been interesting but I will not be sticking with Gentoo once this experiment is over. There are just too many little things that make this more of an educational experience than a real day-to-day desktop. While I certainly have learned a lot during this version of the experiment, at the end of the day I’d rather things just work right the first time.

Normally my laptop is on my desk at home plugged into a sound system, so I never have to change the volume. However I’m currently on holiday, so that means I’m carrying my laptop around. Last night, I had the audacity to lower the volume on my machine. After all, nobody wants to wake up their family at 2am with “The history of the USSR set to Tetris.flv”. Using the media keys on my laptop did nothing. Lowering the sound in KMix did nothing. Muting in KMix did nothing. I figured that something had gone wrong with KMix and maybe I should re-open it. Well, it turns out that was a big goddamn mistake, because that resulted in me having no sound.

It took about 30 minutes to figure out, but the solution ended up being unmuting my headphone channel in alsamixer. It looks like for whatever reason, alsamixer and KMix were set to different master channels (headphone/speaker and HDMI, respectively), thus giving KMix (and my media keys) no actual control over volume.

Hosts: Aine B, Dave L, Jake B, Jon F, Matt C, Phil D, Tyler B, & Warren G

Missing in action: Dana H, Sasha D

Show length: 0:31:16

Description:

The fifth podcast from the guys at The Linux Experiment. In this reunion episode we kick off the second round of The Linux Experiment.

In this episode:

• New recruits.
• Plans for this experiment.
• And lots more!

Get the show:

• iTunes – Subscribe to the podcast on iTunes
• Podcast Alley – Subscribe to the podcast at Podcast Alley
• RSS Feed – Subscribe to the RSS for the podcasts
• Direct MP3 download – Grab the MP3 right here (right-click, save as)
• Direct OGG Vorbis download – Get the OGG right here (right-click, save as)

Listen here (explicit):

The other day I finally managed to get the classic RTS game Command & Conquer Red Alert 2 running on Linux, and running well in fact. I started by following the instructions here with a few tweaks that I found on other forums that I can’t seem to find links to anymore. Essentially the process is as follows:

• Install Red Alert 2 on Windows. Yes you just read that right. Apparently the Red Alert 2 installer does not work under wine so you need to install the game files while running Windows.
• Update the game and apply the CD-Crack via the instructions in the link above. Note that this step may have some legal issues associated with it. If in doubt seek professional legal advice.
• Copy program files install directory to Linux.
• Apply speed fix in the how-to section here.
• Run game using wine and enjoy.

It is a convoluted process that is, at times, ridiculous but it’s worth it for such a classic game. Even better there is a bit of a ‘hack’ that will allow you to play RA2′s multiplayer IPX network mode but over the more modern TCP/IP protocol. The steps for this hack can also be found at the WineHQ link above.

Happy gaming!

As you may be able to tell from my recent, snooze-worthy technical posts about compilers and makefiles and other assorted garbage, my experience with Linux from Scratch has been equally educational and enraging. Like Dave, I’ve had the pleasure of trying to compile various desktop environments and software packages from scratch, into some god-awful contraption that will let me check my damn email and look at the Twitters.

To be clear, when anyone says I have nobody to blame but myself, that’s complete hokum. From the beginning, this entire process was flawed. The last official LFS LiveCD has a kernel that’s enough revisions behind to cause grief during the setup process. But I really can’t blame the guys behind LFS for all my woes; their documentation is really well-written and explains why you have to pass fifty --do-not-compile-this-obscure-component-or-your-cat-will-crap-on-the-rug arguments.

Patch Your Cares Away

Read more…

If you run into the following error trying to build LFS from a Ubuntu installation:


make[1]: *** No rule to make target `/mnt/lfs/sources/glibc-build/Versions.all', needed by `/mnt/lfs/sources/glibc-build/abi-versions.h'. Stop.


The mawk utility installed with Ubuntu, and symlinked to /usr/bin/awk by default does not properly handle the regular expressions in this package. Perform the following commands:


# apt-get install gawk
# rm -rf /usr/bin/{m}awk
# ln -snf /usr/bin/gawk /usr/bin/awk


Then you’re just a make clean; ./configure –obnoxious-dash-commands; make; make install away from success.

I went to play around with my Linux from Scratch installation after getting a working version of KDE 4.7.3 up and running. For a few days now my system has been running stood up to light web browsing use and SSH shenanigans, and hasn’t even dropped a remote connection.

This was until this evening, when I decided to reboot to try and fix a number of init scripts that were throwing some terrible error about problems in lsb_base under /lib/ somewhere. The system came back up properly, but when I startx‘d, I was missing borders for most of my windows. Appearance Preferences under KDE wouldn’t even lanch, claiming a segmentation fault.

There were no logs available to easily peruse, but after a few false starts I decided to check the filesystem with fsck from a bootable Ubuntu 11.04 USB stick. The results were not pretty:


root@ubuntu:~# fsck -a /dev/sdb3
fsck from util-linux-ng 2.17.2
/dev/sdb3 contains a file system with errors, check forced.
/dev/sdb3: Inode 1466546 has illegal block(s).

/dev/sdb3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)


Running fsck without the -a option forced me into a nasty scenario, where like a certain Homer Simpson working from his home office, I repeatedly had to press “Y”:

At the end of it, I’d run through the terminal’s entire scroll buffer and continued to get errors like:


Inode 7060472 (/src/kde-workspace-4.7.3/kdm/kcm/main.cpp) has invalid mode (06400).
Clear? yes

i_file_acl for inode 7060473 (/src/kde-workspace-4.7.3/kdm/kcm/kdm-dlg.cpp) is 33554432, should be zero.
Clear? yes

Inode 7060473 (/src/kde-workspace-4.7.3/kdm/kcm/kdm-dlg.cpp) has invalid mode (00).
Clear? yes

i_file_acl for inode 7060474 (/src/kde-workspace-4.7.3/kdm/kcm/CMakeLists.txt) is 3835562035, should be zero.
Clear? yes

Inode 7060474 (/src/kde-workspace-4.7.3/kdm/kcm/CMakeLists.txt) has invalid mode (0167010).
Clear? yes


I actually gave up after after seeing several thousand of these inodes experiencing problems (later I learned that fsck -y will automatically answer yes, which means I’ve improved my productivity several thousand times!)

I was pretty quick to assess the problem: the OCZ Vertex solid state drive where I’d installed Linux has been silently corrupting data as I’ve written to it. Most of the problem sectors are in my source directories, but a few happened to be in my KDE installation on disk. This caused oddities such as power management not loading and the absence of window borders.

So what goes on from here? I plan to replace the OCZ drive under warranty and rebuild LFS on my spinning disk drive, but this time I’ll take my own advice and start building from this LiveUSB Ubuntu install, with an up-to-date kernel and where .tar.xz files are recognized. Onward goes the adventure!

One of the biggest problems about running irssi in a terminal in screen is that there aren’t any notifications by default if you are mentioned, or if there is activity in a channel. By running these commands, you will be able to get these notifications. They can be tailored based on the notifications that you want.

/set beep_msg_level CRAP MSGS PUBLIC NOTICES SNOTES CTCPS ACTIONS JOINS PARTS QUITS KICKS MODES TOPICS WALLOPS INVITES NICKS DCC DCCMSGS CLIENTNOTICE CLIENTCRAP CLIENTERROR 
/set beep_when_window_active ON 
/set beep_when_away ON 
/set bell_beeps ON

We live in an old house, which has the unfortunate side-effect of lacking a wired network of any kind. All of our machines connect to a wireless network, and my desktop is no exception. I’ve got an old WUSB54GC wireless stick that was manufactured some time in 2007. In computer years, this is way old hardware. But with a bit of work, I managed to get it working with my Gentoo install.

This bitch is old... but it works

I started out by installing the NetworkManager applet with a tutorial on the Gentoo Wiki. This was a straightforward process, and after a restart, the applet icon appeared in the top right corner of my screen. If you left-click on the icon, it drops down a menu that lists your wireless interfaces. Under the Wireless Networks heading, it said that it was missing the firmware necessary to talk to my hardware.

The next step was to look around the net and figure out the firmware/kernel module combination that supports this stick. I found my answer over at the SerialMonkey project, which is run by a group that took on maintenance of older Ralink firmware after the company of the same name dropped support. According to the SerialMonkey hardware guide, my stick (or at least a very similar stick called the WUSB54GR) works with the rt73usb kernel module and related firmware.

This known, there are two methods of proceeding. Those running older kernels may need to manually compile the necessary packages using instructions similar to these, from the Arch Linux project. For more modern kernels, the Gentoo project provides a Wiki entry detailing the necessary steps.

After following the steps in the Gentoo Wiki entry, I restarted my system, and now have full wireless support. Genius!

So my base Gentoo installation came with Gnome 2.3, which while solid, lacks a lot of the prettiness of Gnome’s latest 3.2 release. I thought that I might like to enjoy some of that beauty, so I attempted to upgrade. Because Gnome 3.2 isn’t in the main portage tree yet, I found a tutorial that purported to walk me through the upgrade process using an overlay, which is kind of like a testing branch that you can merge into the main portage tree in order to get unsupported software.

Since the tutorial that I linked above is pretty self-explanatory, I won’t repeat the steps here. There’s also the little fact that the tutorial didn’t work worth a damn…

Problem 1: Masked Packages

#required by dev-libs/folks-9999, 
required by gnome-base/gnome-shell-3.2.1-r1, 
required by gnome-base/gdm-3.2.1.1-r1[gnome-shell], 
required by gnome-base/gnome-2.32.1-r1, 
required by @selected, 
required by @world (argument)
>=dev-libs/libgee-0.6.2.1:0 introspection
#required by gnome-extra/sushi-0.2.1, 
required by gnome-base/nautilus-3.2.1[previewer], 
required by app-cdr/brasero-3.2.0-r1[nautilus], 
required by media-sound/sound-juicer-2.99.0_pre20111001, 
required by gnome-base/gnome-2.32.1-r1, 
required by @selected, 
required by @world (argument)
>=media-libs/clutter-gtk-1.0.4 introspection

This one is pretty simple to fix: you can add the lines >=dev-libs/libgee-0.6.2.1:0 introspection and >=media-libs/clutter-gtk-1.0.4 introspection to the file /etc/portage/package.accept_keywords, or you can run emerge -avuDN world –autounmask-write to get around these autounmask behaviour issues

Problem 2: Permissions

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE "/var/log/sandbox/sandbox-3222.log"

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: mkdir
S: deny
P: /root/.local/share/webkit
A: /root/.local/share/webkit
R: /root/.local/share/webkit
C: ./epiphany --introspect-dump=
/var/tmp/portage/www-client/epiphany-3.0.4/temp/tmp-introspectSfeqBO/functions.txt,
/var/tmp/portage/www-client/epiphany-3.0.4/temp/tmp-introspectSfeqBO/dump.xml
--------------------------------------------------------------------------------

This one totally confused me. If I’m reading it correctly, the install script lacks the permissions necessary to write to the path /root.local/share/webkit/. The odd part of this is that the script is running as the root user, so this simple shouldn’t happen. I was able to give it the permissions that it needed by running chmod 777 /root/.local/share/webkit/, but I had to start the install process all over again, and it just failed with a similar error the first time that it attempted to write a file to that directory. What the fuck?

At 10pm at night, I couldn’t be bothered to find a fix for this… I used the tutorial’s instructions to roll back the changes, and I’ll try again later if I’m feeling motivated. In the mean time, if you know how to fix this process, I’d love to hear about it.