Rubénerd!

Two machines I've installed the Xfce spin of Fedora 15 on hang after logging in with GDM after the second boot. I haven't the foggiest idea why, but creating a new account fixes it.

In a nutshell, after logging in with GDM on the second boot, the Xfce desktop loads including the panels, but then the system freezes. The cursor can still be moved, but all clicks are ignored.

On a hunch, I...

1. used the classic CTRL+ALT+F2 just before GDM starts to bypass xorg
2. logged in as root
3. created a new account separate from the one created during installation
4. rebooted and logged in with the new account in GDM

Multiple restarts later, and Xfce is working just fine.

This leads me to believe that for some reason on my hardware (a homebrew MSI system and a ThinkPad X40) the Xfce preference files are somehow corrupted when being installed. By creating a new account those files are necessarily recreated when Xfce is started from that account, and those files are free of the bugs. I have no proof of this, but its all I can think of right now.

I use FreeBSD and Arch Linux on some systems because I like building things from scratch, but for getting up and running with full drive encryption, SELinux and [generally] graphics hardware, nothing gets up and running quicker than Fedora, from my experience. Of course by seeding design decisions to someone else, it also means tracking down the reason for bugs like this is harder, though I suppose one could level the same arguments against Mac OS X or Windows even more so.

I'll admit I had reservations about Gnome 3 and the new Gnome-Shell, but having used them for 48 hours now I'm pleasantly surprised... despite some serious artefacting issues!

In defence of change!

After years of work, the latest iteration of the Gnome desktop environment was unleashed upon the FLOSS world in late April. Like the fateful KDE 4, Gnome 3 brings with it a slew of controversy, most of which surrounds its fundamental rethink of the typical desktop metaphor... something I personally think has been long overdue.

It's no secret most contemporary desktop environments for *nix have been modelled on Windows. While I could sympathise with their reasons for doing so, Mac OS X demonstrated you don't need be constrained by start menus and taskbars, and it always felt to me as though they were missing an opportunity to be bold and try something new themselves.

So how did they do at it?

My test machine

My test machine is my venerable IBM ThinkPad X40 with a freshly installed and updated Arch Linux i686. The Intel integrated graphics are crappy, but they sure made it a cinch to get 3D acceleration working with the open xf86-video-intel drivers.

Gnome 3 is also the default version of Gnome in Arch now, and my hat goes off to the team for making it so easy to install.

# pacmam -S gnome
# pacman -S gnome-extra

Like previous Gnome releases, you also need dbus. I went ahead and installed fuse and NetworkManager as well given this was for a laptop I'd be taking to coffee shops and wanting quick WiFi access with.

My impressions

Having used Gnome 3 for two days at uni and at my favourite coffee shop, I've been surprised at just how responsive and fast the system is even on this old machine (no, really!), and how quickly I've adapted to the Gnome-Shell way of doing things.

Instead of a messy desktop of icons or a Start Menu, Gnome-Shell puts your application shortcuts and active windows behind a screen you activate by merely throwing your mouse into the top left corner. I forgot what rule of GUI design this adheres to, but its the same philosophy behind Mac OS X's application menus: instead of having to specifically aim for something, you just throw the mouse against the screen edge and you're where you want to be. Threshold something, I forget.

When you activate the Gnome-Shell, the screen of icons and active windows takes up the entire screen, which also makes sense to me. The Start Menu on Windows (or KDE) has your complete attention when you're using it, so why limit its size to a tiny box?

Like Mac OS X's dock, your favourite applications are located in a favourites panel for easy access, or you can navigate all your applications in categories. Previews of all your active windows are also contained in a tab, much like Mac OS X's Expose which is vastly superior to Windows's awkward Alt+Tab and cluttered taskbar.

Unfortunately like Windows, Linux applications put their files all over the place so you can't merely expose an Applications folder in a file manager and let users launch what they want, like in Mac OS X. This seems to be an acceptable compromise.

What I'm really excited about however is the quick keyboard application launcher. I religiously use Alfred on my Macs (QS before that) and dmenu on my Linux and BSD boxes, so being able to simply type the name of an application I want and hitting enter is so convenient I'm lost when I go to a machine that doesn't have it!

The bad

Unfortunately, while great to use even on this older ThinkPad, there are few glaring problems.

1. For some reason some of the fonts are rendered virtually unintelligible despite installing a ton of FLOSS fonts from pacman before installing xorg.

2. There are persistent white artefacts over much of the UI, specifically corners of windows and icons. If I didn't know any better, I'd say it was a CSS border-radius rendering error!

3. Finally, the top bar in Gnome 3 is supposed to be black, but in my setup its completely transparent, and many of the notification icons are missing unless I hover over them with my mouse.

I suspect these issues are PEBKAC though; I'll be enquiring on the Arch forums.

Overall

A solid release, and I'm surprised by how much I'm enjoying using it! I go back to Xfce on my FreeBSD tower and even my Macs and they feel like a step backwards. I suspect a few of the detractors might like it if they were to actually give it a try. I haven't been this pleasantly surprised by a piece of software in a long time!

I'm still getting used to using YUM and RPMs again after being a FreeBSD ports guy for so long. YUM certainly makes it much simpler and faster to update packages, but there are still a few little gotchas! I'm getting used to ;).

From the Fedora tracker. I'll be grabbing the DVD and Xfce releases :).

As with my beloved FreeBSD, Fedora has a /etc/fstab file that lists partitions to be automatically mounted on boot, but with one important difference: Fedora uses a partition's UUID and not its label.

Why?

I was all ready to pose a question in a newsgroup myself, but fortunately Bill Nottingham from this old thread from the Fedora 9 days put it simply:

UUIDs are unique. (In theory, anyway.) Labels aren't.

Bill

Fair enough, I suppose you could have unintentionally labelled two of your drives the same thing. I never have because I like to use unique labels that match their mountpoints to keep things simple, but I suppose if Sarah Palin or Stephen Conroy ever installed Linux they'd probably try a stunt like that.

Anyway so it seemed if I wanted my brand new formatted drive to be mounted when Fedora booted, I needed to find out what the new drive's partition UUID was instead of just using the label I'd just assigned to it.

How do I find out a partition's UUID?

Good question. A cursory Google search returned this page from ServerFault which lists a dizzying array of options with plenty of justifications. blkid worked for me:

# blkid /dev/sda
> LABEL="moe" UUID="#-#-#-#-#" TYPE="ext4"

If this doesn't work, you may not have /sbin in your $PATH. In that case, just run it from that folder, no worries.

Once you've got the UUID, you can finally add it to /etc/fstab/ along with the file system and mountpoint. One extra step compared to FreeBSD, but not too much of a biggie, to use the technical lingo.

It seems all I had to do was mention Fedora a few times and I started getting technical support emails :). I'm still more of a FreeBSD guy, but I hope these help.

Problem 1: No GCC Installed

configure: error:
no acceptable C compiler found in $PATH

This happens if you're attempting to build a C application and you don't have the GNU Compiler Collection installed. Most likely this was because you installed Fedora using the Live CD which (I think, feel free to correct me) doesn't have it, but it's easy enough to install:

# yum install gcc

Problem 2: No GCC-C++ installed

configure: error:
installation or configuration problem
C++ compiler cannot create executables.

Similar problem as above:

# yum install gcc-c++

Problem 3: No grilled cheese sandwiches

The solution:

% echo Grilled cheese sandwiches

A couple of years ago I wrote a post about rzip, and I'm still getting emails and comments from people about it. I've decided to dedicate this post to answering some of these questions so I can point people to it. Grilled cheese sandwiches contain tastyness.

For people coming from a Windows or classic Mac background, file compression on Unix-like operating systems (such as GNU/Linux and BSD) can seem a bit confusing. Unlike the ZIP format which can accept multiple files, most Unix compressors can only work on one file at a time, so we use an archiver to bundle up the files we want to compress first, then feed that archive to the compressor.

Step one: archive files

Overwhelmingly the most common file archiving tool on Unix-like systems is the tape archiver (tar). This command creates a new tar archive from a folder which may contain files and other folders:

% tar cvf NewArchive.tar ./FolderToArchive/

An alternative is pax, which I prefer because it tends to be more consistent, it archives symbolic links (aka Unix shortcuts or aliases) instead of following them, and it has a few nifty features like being able to specify files that fall within a certain date range.

% pax -wf NewArchive.pax ./FolderToArchive/

Step two: compress the archive

The amount of time and CPU power you have will determine which compression algorithm you'll employ. On Unix systems the two most common are gzip which is fast, and bzip2 which is slower but generally gets better compression ratios. Here are some examples of both compressing the archive we made in step 1:

% gzip -v NewArchive.tar
% bzip2 -v NewArchive.tar

With both gzip and bzip2 you can adjust how much compression they perform by specifying a numeric flag from 1-9. Specify --help for more information.

Step three: just do one step

Now that we know the difference between archiving and compressing, we can save ourselves some time and do them both in one step. Most versions of tar support an extra flag that tells it to compress an archive with the tool of your choice after its been made. "z" specifies gzip and "j" specifies bzip2:

% tar czvf NewArchive.tar.gz ./FolderToArchive/
% tar cjvf NewArchive.tar.bz2 ./FolderToArchive/

Step four: unarchiving

Basically the reverse of what we did before, and again tar can take care of it for us:

% tar xzvf NewArchive.tar.gz
% tar xjvf NewArchive.tar.bz2

Recent versions of gnutar take this shorthand one step further with the "a" flag which automatically determines what compressor to use based on the file name you provide it; for example NewArchive.tar.bz2 tells gnutar with the "a" flag to use bzip2. Unless you're running a very recent Linux distribution or have installed it specifically though, you probably don't have it.

Other compressors

There are many, many other compressors you can use. My current ones of choice are xz and rzip which both achieve far higher compression ratios but require a fast machine with plenty of memory to run in a reasonable amount of time. I discussed rzip back in 2007, but I'll be dedicating a new post on its and xz's use later this week.

Links

Wikipedia	tar	pax	gzip	bzip2
FreeBSD manpage	tar	pax	gzip	bzip2
GNU/Linux manpage	tar	pax	gzip	bzip2

I hope this helps folks :).

Get it? CC cuddling cheese-kun? Warm and fuzzy? C? Get it? When I first started messing around with GNU ncurses I was under the impression it was a simple framework to create interactive, windowed console applications...

In reality it's a complete, really polished environment that extends C in some really nice ways; so much so that I would argue it would be a misnomer to say you're simply writing "C" code any more. It's to C what Cream is to Vim. It's CC with Cheese Kun. I could go on.

Header files

The first sign you get that ncurses is something special is that importing it's single header file gives you all these below header files automatically.

#include <ncurses.h>

#include <stdio.h>
#include <stdarg.h>
#include <stddef.h>
#include <unctrl.h>

In fact you're actively encoraged not to import any of these usual suspects because you'd needlessly inflate your compiled applications. I assume it's doing some clever tricks to only use what's nessisary. It also adds a bunch of it's own functions that provide similar functionality, more on that below.

Booleans

Most people start with C and move on to C++, I went the other way... you can probably see where this is going! When you import you get a boolean data type for C for free. Paroozing the header file it seems to cleverly make sure it doesn't conflict with the C++ bool if that's the language you're using, pretty cool.

#undef TRUE
#define TRUE    1

#undef FALSE
#define FALSE   0

typedef unsigned char NCURSES_BOOL;

#if defined(__cplusplus) /* __cplusplus, etc. */

/* use the C++ compiler's bool type */
#define NCURSES_BOOL bool

#else /* c89, c99, etc. */
[...]

Alternatives to standard in/output

This is what I mean by ncurses almost being like an entire environment for C, it makes so much stuff easier and more fun. As well as supporting the basic C output functions such as printf(), ncurses comes with a bunch of extras that make sense when dealing with GUI-like interfaces in a terminal.

addch();  /* add character to the "window" */
addstr(); /* add string of characters */
printw(); /* equivilent to C's printf() */

What's also really cool though are the functions for reading in data from the keyboard which is much nicer than vanilla C:

getch()   /* get character */
getstr()  /* get string of characters */
getnstr() /* same as above, but measured */
scanw()   /* equivilent to scanf(); */

Why?

I'm surprised by the number of people asking me why, in 2010, I'm interested in writing console applications, because we all know console applications are passe and unsexy. I'm hoping in the coming weeks when I start writing code for a few projects (and am hopefully allowed to publish some of it) you'll see why. There's still a ton of life in this environment and I'm really excited to see what I can accomplish in it.

Tim O'Reilly and Richard Stallman, by RedMonk. Great picture!

Personally I don't think either term is ideal. Despite the Free Software Foundation repeatedly telling us "Free Software" refers to liberty and freedom not price, I doubt the typical English use of the word will ever change. "Open Source" as advocated by the Open Source Initiative also isn't ideal given it simply describes the ability of users to view code without mentioning how such code could be used.

I avoid confusion and this debate like many others by simply calling it free and open source software. I do admit I love both movements and value their importance, but frankly we all need to stop this infighting and come up with an all encompassing term.

I guess though one could say one of the points of FLOSS is the ability to fork or create new software when other solutions are licenced too restrictively or don't serve their purpose well, and that this includes terms as well. Who's to say even if we did come up with a term we all agreed upon that we'd agree on it in perpetually?

I'm off to connect to my FreeBSD machine through OpenSSH on my Arch Linux sub-notebook, this argument is making my head hurt!

As you might remember a few months ago I switched from FreeBSD to Arch Linux on my 2002-era Compaq Armada M300 sub-notebook which I use for downloading torrents and as a coffee shop computer. Since then I might have figured out how to get my wireless card working on FreeBSD after all, but that's for another post.

One thing I have really noticed using the GNU Project's userland tools on Linux instead of FreeBSD's userland tools on FreeBSD is while the GNU tools generally have more features, the difference in the quality of the bundled documentation, specifically manual pages (Wikipedia) is huge. There's absolutely no comparison, FreeBSD's manual pages are more comprehensive, complete and better written.

As a FreeBSD user who has been spoilt silly and has come to expect this level of documentation, to use GNU/Linux has been somewhat of a shock. Often manual pages for the GNU userland tools contain a blunt dictionary style description of what the tool does, followed by a skeleton explanation of each of the options and a reference to a URL.

For example, check out the first screen of the manual page for the ls command for Linux and FreeBSD respectively, before the options are presented. Given Mac OS X's BSD underpinnings the man page for ls is the same too.

GNU/Linux

NAME
ls - list directory contents

SYNOPSIS
ls [OPTION].... [FILE]...

DESCRIPTION
List information about the FILEs (the current directory by default). Sort entries alphabetically if one of the -cftuvSUX nor --sort.

Mandatory arguments to long options are mandatory for short options too.

FreeBSD (and Mac OS X)

NAME
ls -- list directory contents

SYNOPSIS
ls [-ABCFGHLPRSTW@abcdefghiklmnopqrstuwx1] [file ...]

DESCRIPTION
For each operand that names a file of a type other than directory, ls displays its name as well as any requested, associated information. For each operand that names a file of type directory, ls displays the names of files contained within that directory, as well as any requested, associated information.

If no operands are given, the contents of the current directory are displayed. If more than one operand is given, non-directory operands are displayed first; directory and non-directory operands are sorted separately and in lexicographical order.

The following options are available:

What I've since learned is the GNU project eschews manual pages for Texinfo pages which you access with a separate command. According to the Wikipedia page on the subject, Texinfo pages are designed as tutorials as well as general references, meaning they're more like books and less like traditional help files.

While I understand the merits of this approach, I still think this shunning of manpages or the lowering of their development priority is a bit short sighted. Even if the benefits of Texinfo pages are real, I don't see why one should be developed at the expense of the other.

I guess to be fair, this is something I'd get used to eventually if I switched to GNU/Linux as my primary OS.