SkinnyDebbie has moved

I've moved SkinnyDebbie to a new home. Skinny's new home will be able to give the project more of the services it wants and needs. From now on, the best place to get the Skinny is http://skinny.tuxfamily.org/ .

Lenny is out!

Debian gives us a Valentines Day gift by releasing Lenny. :-)
via Slashdot

The Joy of X

I've been doing some work with Lenny in its current pre-released state. It's actually pretty stable and usable, with one 1000-pound gorilla exception: X.

In case you are as new to Linux as I was last year, the X Window System (or simply X) is the name of the service that provides graphics in Linux. There used to be competing flavors of X, but now the world has pretty much settled on the version offered by the X.Org project. In contrast with the myriad choices for file managers, text editors, window managers, etc. that characterizes the rest of Linux, if you want graphics (i.e., GUI), you need to deal with X, and you will almost certainly be dealing with X.Org's implementation.

Right now I kinda wish you didn't.

The 1000-pound issue with the latest (i.e., found in Lenny) version of X involves automatic modes detection. In Etch, when you installed X the installer ran a script that made a reasonable guess concerning what your video system was capable of and then asked you if it got it right. Then it would write the data to /etc/X11/xorg.conf and use that data when delivering services. If you changed/added monitors or video cards you had to rerun the config routine with

# dpkg-reconfigure -phigh xserver-xorg

(as root) and that would generate a new xorg.conf file. The syntax of the xorg.conf file is really painful, especially for your grandmother, but if for some reason you needed to optimize some settings manually, you could. This hasn't been needed on any of the four SkinnyDebbie systems I use. Overall, the arrangement was not ideal, but it was workable.

Then the X people decided to make it ideal. The idea(l) is that the video system should tell the X server what the video system is capable of when the X-session starts up, and X should then use that data. If you change/add hardware, all you need to do is restart your X session. Beautiful.

Except in my Lenny experience a lot of video cards and monitors (especially slightly older ones) do not (correctly) tell the system what they are able to do. And while you can still hand-edit the xorg.conf file to force it to tell X what the video system can do, there is no way to get the data into the xorg.conf file without teaching your grandmother the painful xorg.conf syntax. In other words as near as I can tell, dpkg-reconfigure -phigh xserver-xorg doesn't have a "manual override" mode. Ugh.

Just as bad:
The standard Linux program for resizing/rotating your display is called xrandr. Among its jobs are reporting back to you what the X system says you can set for resolution and refresh rate and allowing you to select the mode you want to use. Except it hasn't worked with any setup I've used using totally autoconfigured X.

I really, really hope this one gets worked out.

Where is Lenny?

Additional development of SkinnyDebbie has been held up by two things. The first is an unbelievable workload this term. I am teaching almost double the standard load. And on top of that (not because I am an idiot, but because I had no choice) I am taking two classes for my PhD program--two classes that are turning out to be much more time demanding that I had anticipated. I am hoping next term won't be as insane as this one.

The second reason is the delay in Lenny's release. It was originally on track for a September/October 2008 release, but due to some release-critical bugs, the final release is now not expected until June of 2009. (See also this and this.)

I don't really want to develop/fix/improve anything with SkinnyDebbie until Lenny's final form sees daylight. Given that there are release-critical (i.e., significant) bugs and the projected timeline for resolution is so long, there is a good chance that important bits of anything I develop now may break by the time the release is finalized, possibly is subtle, hard to find ways. I'd rather have a go at it once the infrastructure is finalized.

In the meantime, what is a light-and-lean Linuxer to do? The big concern I have with Etch is that support for Firefox 2 will soon go away. I'm pretty sure that means no more security updates from Mozilla. Does that mean that Etch will upgrade Iceweasel to v3 in Etch? Will Iceweasel developers backport security updates to v2? I haven't heard anything about this yet.

Given the delay with Lenny and issues with Etch's age, I am considering converting the SkinnyDebbie project to an Ubuntu-based deal. But I need to let this term play out before I can make a good decision. In the meantime, if you are brave you can use SkinnyDebbie as-is with Lenny. Some things won't work--the widgets for setting display resolution for example--but in my testing the overall scheme holds up pretty well.

Samba: passwords

Samba drove me nuts until I figured out that it keeps its own database of passwords. In other words, for each user that you intend to permit access for in Samba, you must also create a password. It's easy enough to do:

sudo smbpasswd -a <username>

but if no one tells you this, you will go nuts trying to figure it out. Not even the official Samba HOW-TO gives you a decent clue about this.

Apparently, you can set Debian Etch up to sync Samba and user passwords, but I haven't gone there yet.

Music Playing Daemon: setup

I've been having way too much fun with MPD lately. It is now my default tool for music listening at home. I am using Music Player Minion, Ario, and QMPDClient on my Windows laptop to control the server, gmpc as a Linux GUI client (Etch doesn't have Ario or QMPDClient), mpc for terminal one-offs, and ncmpc for SSH sessions. Phew. I haven't gotten around to trying Bluetooth devices, etc. It's all quite cool.

As with many things Linux, setting up MPD can be a bit confusing. Below I describe my current setup, which was designed for a reasonable but not paranoid amount of security. It's all quite geeky. If you are not capable of this level of geek, you might want to stay away from MPD until you are.

I will assume that you have already installed MPD and (optionally) Samba. You can point MPD at any directory for it's source of music. Since it's a server and gets launched at system startup (at least in Debian Etch and therefore SkinnyDebbie), I decided the best place to store files is in a system directory rather than directory inside a user's home directory.

So here's what to do:

Make a group called music:

sudo groupadd music

Now create a directory to store your music collection -- I suggest /srv/media/music. Set the directory to be owned by mpd and of the music group:

sudo chown mpd:music /srv/media/music

Note: The group name created above does not need to match the directory name.

Set /srv/media/music so that members of the group music have write permission and all other have read permission:

sudo chmod 775 /srv/media/music

Note: /srv and /srv/music need to have their read and execute bits set for everyone. This will happen by default on most systems, but if this isn't the case in your case:

sudo chmod 755 /srv
sudo chmod 755 /srv/media

Edit /etc/mpd.conf so that MPD points to the new directory

music_directory         "/srv/media/music"
playlist_directory      "/srv/media/music"

While you are in /etc/mpd.conf, to make MPD is reachable by clients outside the localhost, comment out the line:

bind_to_address    "localhost"

by placing a # in front of it. Now is also the time to set a MPD server password if you want one, change its port number, etc.

Add users you want to be able to manage the music collection to the "music" group

sudo usermod -a -G music <username>

Note: the user must logout and log back in for changes to take effect.

Optional: if you are using Samba to share files on the network, create a share called "Music" and make it fully public by adding to /etc/smb.conf:

[Music]
path = /srv/media/music
browseable = yes
read only = no

Linux's underlying permissions will keep members who are not in the "music" group from writing to the directory. Note that whatever you copy into this folder will be owned by the user who copied it in. Therefore permissions must allow MPD to read all files. This will happen by default on most systems, but if you have problems you can check this.

Be sure to update the MPD database when you add new music:

mpc update

You might consider is setting up a cron job to periodically update the database.

Oldschool wireless

There's a really good guide to setting up WiFi without using NetworkManager at http://ubuntuforums.org/showthread.php?t=202834.

Why would you want to do this? Because when you do, the wireless LAN connection comes up automatically when you boot the machine. This is a really good idea if you are running any servers (e.g., the outrageously fun MPD). Of course it's a really bad idea to run a server off a wireless connection whether it comes up automatically or not, but sometimes you just can't snake cables where you want your machine to be. And if you're not running any servers, it spares you the bother of having to type in connection authorization at login. If you do a lot of roaming, then giving up NetworkManager (or the similar netapplet) may not be such a great idea; but if you don't, this approach may save you from some bother.

The only things I would add to what is posted in the Ubuntu forum are:

1. You can include more that one interface in the /etc/network/interfaces file.
2. If you use a network interface card that is removable (PCMCIA, USB, etc.) you may get better results if you specify it as allow-hotplug rather than auto.
3. If you do specify an interface as allow-hotplug rather than auto, issuing the
   sudo /etc/init.d/networking restart
   command won't bring up the interface(s). To do that you will need to issue
   ifup < the_name_of_the_interface >

My main SkinnyDebbie test machine has one PCMCIA slot and no built-in networking. I tend to swap out a wireless and a wired Ethernet card. My /etc/network/interfaces file looks like this:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
#auto eth0
iface eth0 inet dhcp

allow-hotplug ath0
#auto ath0
iface ath0 inet dhcp
wpa-driver madwifi
wpa-ssid ufart
wpa-ap-scan 1
wpa-proto WPA
wpa-pairwise TKIP
wpa-group TKIP
wpa-key-mgmt WPA-PSK
wpa-psk <>

Of course, your details will differ.