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.
December 28, 2008
September 22, 2008
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:
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.
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.
September 20, 2008
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:
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:
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:
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:
Edit /etc/mpd.conf so that MPD points to the new directory
Add users you want to be able to manage the music collection to the "music" group
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:
Be sure to update the MPD database when you add new music:
You might consider is setting up a cron job to periodically update the database.
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 musicNow 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/musicNote: 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/musicNote: /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/mediaEdit /etc/mpd.conf so that MPD points to the new directory
music_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:
playlist_directory "/srv/media/music"
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]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.
path = /srv/media/music
browseable = yes
read only = no
Be sure to update the MPD database when you add new music:
mpc updateYou might consider is setting up a cron job to periodically update the database.
September 16, 2008
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:
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:
- You can include more that one interface in the /etc/network/interfaces file.
- If you use a network interface card that is removable (PCMCIA, USB, etc.) you may get better results if you specify it as
allow-hotplugrather thanauto. - If you do specify an interface as
allow-hotplugrather thanauto, issuing thesudo /etc/init.d/networking restart
command won't bring up the interface(s). To do that you will need to issueifup < the_name_of_the_interface >
# This file describes the network interfaces available on your systemOf course, your details will differ.
# 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 <>
September 09, 2008
MadWifi and SkinnyDebbie
My main SkinnyDebbie test machine is an Acer TravelMate 508T laptop. It has no built-in Ethernet. I don't think I need to say that it has no built-in WiFi. It has one PCMCIA slot.
I use a 3Com OfficeConnect 10/100 LAN adapter card (PCMCIA) for Ethernet connectivity. I've never had to do anything special to make the lappy's networking go with any Linux distribution I have tried. It just works "out of the box." I also have a D-Link DWL-G630 WiFi card (also PCMCIA). It works "out of the box" in Xubuntu, but not in SkinnyDebbie. This is a summary of how I got it to work.
I bought the D-Link card because it was listed as Linux compatible at http://linux-wless.passys.nl/ (and because of favorable comments at Newegg). The site says that my card is compatible with MadWifi drivers--drivers that have been developed to support Atheros chipsets. The process below is adapted from MadWifi's own newbie installation guide; however, I had to do some extra stuff and not do some other stuff to make it go in SkinnyDebbie. I expect that the instructions below will work for any MadWifi-compatible card. There are lots of little steps here, none of which are large or complicated, but all of which add up to some tedium. Sorry about that.
Preparation
I use a 3Com OfficeConnect 10/100 LAN adapter card (PCMCIA) for Ethernet connectivity. I've never had to do anything special to make the lappy's networking go with any Linux distribution I have tried. It just works "out of the box." I also have a D-Link DWL-G630 WiFi card (also PCMCIA). It works "out of the box" in Xubuntu, but not in SkinnyDebbie. This is a summary of how I got it to work.
I bought the D-Link card because it was listed as Linux compatible at http://linux-wless.passys.nl/ (and because of favorable comments at Newegg). The site says that my card is compatible with MadWifi drivers--drivers that have been developed to support Atheros chipsets. The process below is adapted from MadWifi's own newbie installation guide; however, I had to do some extra stuff and not do some other stuff to make it go in SkinnyDebbie. I expect that the instructions below will work for any MadWifi-compatible card. There are lots of little steps here, none of which are large or complicated, but all of which add up to some tedium. Sorry about that.
Preparation
- I started with my wired Ethernet card in the laptop. The WiFi card was not physically in the machine.
- Verify that your WiFi card is compatible with the MadWifi drivers at http://linux-wless.passys.nl/. Be sure to check the vendor/product code of your card as well as the product ID because manufacturer's routinely change chipsets in their cards without changing model numbers! If it's not listed as working with MadWifi, then don't install the MadWifi drivers.
- Open a terminal and type:
sudo aptitude install network-manager network-manager-gnome
This will install a network management system and notification tray applet that takes a lot of the headache out of setting up and signing on to WiFi networks. - When that's done, type
sudo aptitude install module-assistant build-essential - When that's done, type
sudo m-a update
sudo m-a prepare
The above will install the header files needed to build the MadWifi drivers. - When that's done, type
geany ~/.icewm/startup
In the text editor window that opens, right after the linexscreensaver -no-splash &
add the linenm-applet --sm-disable &
Save the file and exit Geany.
- Download the drivers from the Madwifi home page. I used v0.9.4. If something doesn't work in what follows, it may be because of a version change.
- In ROX-Filer, navigate to the
*.tar.gzfile you downloaded and double click on it to extract it. - Open a terminal and navigate to the directory where you extracted the package. (This may be a good time to get to know ROX-Filer's Window -> Terminal here command or it's keyboard shortcut, `.)
- Type the following in the terminal:
sudo ifconfig ath0 down
sudo ifconfig wifi0 down
You will probably get warnings or errors. Don't worry about them. - Now type the following:
cd scripts
./madwifi-unload
./find-madwifi-modules.sh $(uname -r)
cd ..
This removes any old modules, which you almost certainly don't have anyway. We are now ready to build the drivers. - Still in the terminal, make sure you are at the top level of the downloaded and extracted MadWifi directory and type:
sudo make
sudo make install
Both of the above may take some time. You should not see errors. If you do, curse the Linux gods and give up. - Type:
sudo geany /etc/modules
In the text editor window that opens, add the following line to the bottom:ath_pci
Save the file and exit Geany. - Logoff and power down the computer. Replace the wired Ethernet adapter card with the WiFi adapter card.
- When you start the computer and login again, you should see a new icon in the notification tray. When you click on it, you will be able to select and sign into available WiFi networks
SkinnyDebbie and the Macintosh PowerPC
I tried loading SkinnyDebbie onto an old Macintosh Cube.
"Linux on PowerPC?" you ask? And at 450 MHz? Debian is one of the few distributions that officially supports the PowerPC architecture. And SkinnyDebbie on i386 at 500Mhz works just fine. So it seemed natural to try.
It worked. In fact, I am really happy not just that it works but also with how well it works. So far I have found only four gotchas--two having to do with SkinnyDebbie and two having to do with Larger Issues. The SkinnyDebbie ones are easy to fix. The Larger Issues are not.
First the SkinnyDebbie stuff:
IceWM's network traffic monitor doesn't work. This is caused by the fact that (at least on my Cube), eth0 gets assigned to FireWire networking and eth1 to Ethernet. The fix is easy: open
The volume control is batty. The Cube uses a USB sound card and SkinnyDebbie is currently using ALSA. It turns out that Debian Etch doesn't play perfectly with this combination--on either PowerPC or i386 platforms. I'll say more about this in a later post, but the fix is again simple: use
And now for the Larger Issues:
Flash is very limited. Adobe doesn't make a version of Flash for Linux on the PowerPC. Why would they? There are a couple open source alternatives--Gnash and Swfdec--but neither will do Flash video. So, no YouTube on PowerPC Linux for you. It's just not possible in any PowerPC Linux at the moment. The best workaround is to download videos with any of the million YouTube download services and then watch them in VLC.
Java is at best a PITA. Sun doesn't make a version of the Java Runtime Environment for Linux on the PowerPC. If you want/need Java, the best workaround seems to be GCJ and its bundled GIJ interpreter. I have had success in compiling command-line apps from scratch in GCJ, but I have not had success with GUI apps using GIJ. This definitely needs more research to see just how viable a solution it is.
I am hoping Lenny (the next Debian release, due later this month) works as well as Etch on this hardware. Should it be enough to make you abandon Mac OS? Given that the next OS X release may not support PowerPC, you might think so. But this isn't really a good enough reason since maintenance support for older OS X releases will likely continue for quite a while. The decision to switch in this case needs to be made based on what you want from the OS and operating environment. OS X is certainly more polished and easier to use than SkinnyDebbie. But it costs more and doesn't let you run at least one thing that makes Linux really attractive.
"Linux on PowerPC?" you ask? And at 450 MHz? Debian is one of the few distributions that officially supports the PowerPC architecture. And SkinnyDebbie on i386 at 500Mhz works just fine. So it seemed natural to try.
It worked. In fact, I am really happy not just that it works but also with how well it works. So far I have found only four gotchas--two having to do with SkinnyDebbie and two having to do with Larger Issues. The SkinnyDebbie ones are easy to fix. The Larger Issues are not.
First the SkinnyDebbie stuff:
IceWM's network traffic monitor doesn't work. This is caused by the fact that (at least on my Cube), eth0 gets assigned to FireWire networking and eth1 to Ethernet. The fix is easy: open
~/.icewm/preferences and add eth1 to the list of monitored network devices in the NetworkStatusDevice field. When you restart IceWM, you should now see the network traffic monitor. (Make the same change as root to the corresponding file in /etc/skel to make the change happen for new users as well.)The volume control is batty. The Cube uses a USB sound card and SkinnyDebbie is currently using ALSA. It turns out that Debian Etch doesn't play perfectly with this combination--on either PowerPC or i386 platforms. I'll say more about this in a later post, but the fix is again simple: use
gnome-alsamixer or aumix-gtk instead of alsamixergui and comment out the volume changing hotkeys in ~/.icewm/keys.And now for the Larger Issues:
Flash is very limited. Adobe doesn't make a version of Flash for Linux on the PowerPC. Why would they? There are a couple open source alternatives--Gnash and Swfdec--but neither will do Flash video. So, no YouTube on PowerPC Linux for you. It's just not possible in any PowerPC Linux at the moment. The best workaround is to download videos with any of the million YouTube download services and then watch them in VLC.
Java is at best a PITA. Sun doesn't make a version of the Java Runtime Environment for Linux on the PowerPC. If you want/need Java, the best workaround seems to be GCJ and its bundled GIJ interpreter. I have had success in compiling command-line apps from scratch in GCJ, but I have not had success with GUI apps using GIJ. This definitely needs more research to see just how viable a solution it is.
I am hoping Lenny (the next Debian release, due later this month) works as well as Etch on this hardware. Should it be enough to make you abandon Mac OS? Given that the next OS X release may not support PowerPC, you might think so. But this isn't really a good enough reason since maintenance support for older OS X releases will likely continue for quite a while. The decision to switch in this case needs to be made based on what you want from the OS and operating environment. OS X is certainly more polished and easier to use than SkinnyDebbie. But it costs more and doesn't let you run at least one thing that makes Linux really attractive.
August 18, 2008
Use ROX-Filer to open containing folders in Firefox/Iceweasel
Update: See this for an easier way to accomplish the same goal.
One of the slightly bothersome things about using ROX-Filer with Iceweasel in Debian Etch (and I suspect Firefox in other distributions) is that Iceweasel won't "open containing folders" with ROX-Filer from Iceweasel's Downloads window. I was therefore pretty jazzed when I found this link at Rubylution that shows you how to tell Firefox (and Iceweasel) to use a specific file manager to open folders.
Of course I tried it, and of course it failed. The problem is that Firefox/Iceweasel sends the specified file manager the name of the directory in the form of a
So here's what you do:
Create an executable
Remember to make it executable.
Now create the file that sed will use to convert encoded characters in
Once you've done this, you can use the method described at Rubylution to set
Caveats: The script and sed file should be considered beta. I have done my best to make sure that the files render properly in HTML, but conversion gremlins may exist. If you find any problems, please let me know.
Reinventing the wheel? Probably. I'm pretty sure someone else has already done something very similar to this, or there may be an easier way to do the same thing. But in the two minutes I spent trying, I wasn't able to find anything.
*This is true at least in Firefox 2 and the version of ROX-Filer that's part of Debian Etch. I don't know what Firefox 3 does nor if the latest release of ROX-Filer handles file URLs.
One of the slightly bothersome things about using ROX-Filer with Iceweasel in Debian Etch (and I suspect Firefox in other distributions) is that Iceweasel won't "open containing folders" with ROX-Filer from Iceweasel's Downloads window. I was therefore pretty jazzed when I found this link at Rubylution that shows you how to tell Firefox (and Iceweasel) to use a specific file manager to open folders.
Of course I tried it, and of course it failed. The problem is that Firefox/Iceweasel sends the specified file manager the name of the directory in the form of a
file://<filename> URL, and ROX-Filer doesn't get file URLs.* So, I wrote a script that uses sed to decode the URL to a form that ROX-Filer understands and then calls ROX-Filer with the decoded path.So here's what you do:
Create an executable
/usr/local/bin/rox-open-url:#!/bin/bash
# Opens input argument in rox, where input argument is assumed to be a URL
# of the form file://<path-to-file>
# Mithat Konar 17 Aug 2008
# Requires sed and /usr/local/share/rox-open-url/urldecode.sed
##############################################################
# strip away file:// prefix and decode remaining characters
thePath=`echo "$1" | sed 's/^[fF][iI][lL][eE]:\/\///' | sed -f /usr/local/share/rox-open-url/urldecode.sed`
rox "$thePath"Remember to make it executable.
Now create the file that sed will use to convert encoded characters in
/usr/local/share/rox-open-url/urldecode.sed:s/%08/\\b/g
s/%09/\\t/g
s/%0[aA]/\\n/g
s/%0[dD]/\\r/g
s/%20/\ /g
s/%21/\!/g
s/%22/\"/g
s/%23/\#/g
s/%24/\$/g
s/%25/\%/g
s/%26/\&/g
s/%27/\'/g
s/%28/\(/g
s/%29/\)/g
s/%2[aA]/\*/g
s/%2[bB]/\+/g
s/%2[cC]/\,/g
s/%2[dD]/\-/g
s/%2[eE]/\./g
s/%2[fF]/\//g
s/%30/0/g
s/%31/1/g
s/%32/2/g
s/%33/3/g
s/%34/4/g
s/%35/5/g
s/%36/6/g
s/%37/7/g
s/%38/8/g
s/%39/9/g
s/%3[aA]/\:/g
s/%3[bB]/\;/g
s/%3[cC]/\</g
s/%3[dD]/\=/g
s/%3[eE]/\>/g
s/%3[fF]/\?/g
s/%40/\@/g
s/%41/A/g
s/%42/B/g
s/%43/C/g
s/%44/D/g
s/%45/E/g
s/%46/F/g
s/%47/G/g
s/%48/H/g
s/%49/I/g
s/%4[aA]/J/g
s/%4[bB]/K/g
s/%4[cC]/L/g
s/%4[dD]/M/g
s/%4[eE]/N/g
s/%4[fF]/O/g
s/%50/P/g
s/%51/Q/g
s/%52/R/g
s/%53/S/g
s/%54/T/g
s/%55/U/g
s/%56/V/g
s/%57/W/g
s/%58/X/g
s/%59/Y/g
s/%5[aA]/Z/g
s/%5[bB]/\[/g
s/%5[cC]/\\/g
s/%5[dD]/\]/g
s/%5[eE]/\^/g
s/%5[fF]/\_/g
s/%60/\`/g
s/%61/a/g
s/%62/b/g
s/%63/c/g
s/%64/d/g
s/%65/e/g
s/%66/f/g
s/%67/g/g
s/%68/h/g
s/%69/i/g
s/%6[aA]/j/g
s/%6[bB]/k/g
s/%6[cC]/l/g
s/%6[dD]/m/g
s/%6[eE]/n/g
s/%6[fF]/o/g
s/%70/p/g
s/%71/q/g
s/%72/r/g
s/%73/s/g
s/%74/t/g
s/%75/u/g
s/%76/v/g
s/%77/w/g
s/%78/x/g
s/%79/y/g
s/%7[aA]/\z/g
s/%7[bB]/\{/g
s/%7[cC]/\|/g
s/%7[dD]/\}/g
s/%7[eE]/\~/gOnce you've done this, you can use the method described at Rubylution to set
rox-open-url as the command to use to open containing folders.Caveats: The script and sed file should be considered beta. I have done my best to make sure that the files render properly in HTML, but conversion gremlins may exist. If you find any problems, please let me know.
Reinventing the wheel? Probably. I'm pretty sure someone else has already done something very similar to this, or there may be an easier way to do the same thing. But in the two minutes I spent trying, I wasn't able to find anything.
*This is true at least in Firefox 2 and the version of ROX-Filer that's part of Debian Etch. I don't know what Firefox 3 does nor if the latest release of ROX-Filer handles file URLs.
August 17, 2008
Tweaking the Debbie
I've made a few tweaks to SkinnyDebbie, some to fix bugs, some to make some behavioral improvements. In particular, I have:
If you are an early SkinnyDebbie adopter and want to implement these changes, let me know and I'll send you a custom updater script.
- Added /usr/local/bin/rox-open-url and /usr/local/share/rox-open-url/urldecode.sed
- Added config-iceweasel-defaults.sh to install process that modifies Iceweasel default preferences (/etc/iceweasel/profile/prefs.js) to download files to home directory (with prompt) and use rox-open-url to "open containing folders".
- Changed ownership of /etc/X11/xdm/Xsetup to root
- Changed tooltip and properties text for "Screen resolutions" control panel.
If you are an early SkinnyDebbie adopter and want to implement these changes, let me know and I'll send you a custom updater script.
August 06, 2008
SkinnyDebbie is done
The initial release of SkinnyDebbie is done. What started as something that I thought I could put together in a few evenings has turned out taking far, far longer than that. But I think the results have been worth it. There are aspects of the user experience that still need cleaning up, but overall I think it's a pretty decent lightweight desktop.
Most of my time was spent writing scripts to make system administration easier for less-than-sys-admin types. Automounting in particular was a royal time hog. If you are insane enough to actually read all the custom scripts (both the ones that do the installation as well as the ones that are installed as part of SkinnyDebbie), you will be able to track the development of my Linux competence.
I've decided to give SkinnyDebbie its own website. For the time being, it will be hosted at http://birotechnology.com/skinny. I am hoping this is a temporary situation and that a more suitable location will present itself. I'm also hoping to flesh out the installation instrutions a bit more once I have recovered a bit from the last few days of development and testing.
Now, please go forth and install. And then let me know what you think.
August 05, 2008
automounting - part 2
Here is a brief (!) summary of the problems I encountered in setting up automounting in SkinnyDebbie and what I did to get it to behave. The whole process relies on hal and ivman. Maybe there is a better way to do this; if so I would love to learn how.
In no particular order ...
If media is present when user starts machine, the media automounts under ivman's account, and then a regular user can't unmount it.
Solution:
Turning off the ivman daemon is handled by the SkinnyDebbie installer. I wrote a custom script (start-ivman) to handle user startup that checks the above at IceWM startup. I also wrote a control panel widget that repairs the above if it breaks (e.g., after an ivman package update).
The default SkinnyDebbie behavior is that automounting will be started for the first user that is logged in and not for subseqent users until the first user logs off. In practice this is fine because SkinnyDebbie is intended for single-user logins. The start-ivman script warns the user if someone else is already using automounting.
Not all media automounts, USB hard drives in particular
Solution:
It's not at all obvious to the regular user where/when removable media is inserted
Solution:
There are several custom "annc" scripts (anncRoxMedia, anncCDDA, anncDVDvideo) that get called per media type. These scripts check to see if ROX's pinboard is running; if it is, then it will announce the insertion of media. The IceWM startup delays the start of ROX's pinboard by a few seconds so that the user doesn't get bombarded with media announcements when logging in.
If user logs off without unmounting stuff, the folders remain in /media but the media is not mounted
Solution:
User needs guidance in good habits (i.e., unmount before remove)
Solution:
CD and DVD media don't mount ... ever
See "Not all media automounts, USB hard drives in particular" above.
In no particular order ...
If media is present when user starts machine, the media automounts under ivman's account, and then a regular user can't unmount it.
Solution:
- Disable ivman daemon so that the ivman user doesn't do any mounting:
# update-rc.d -f ivman remove - Start ivman under the user's account at login so the regular user can mount via ivman.
Turning off the ivman daemon is handled by the SkinnyDebbie installer. I wrote a custom script (start-ivman) to handle user startup that checks the above at IceWM startup. I also wrote a control panel widget that repairs the above if it breaks (e.g., after an ivman package update).
The default SkinnyDebbie behavior is that automounting will be started for the first user that is logged in and not for subseqent users until the first user logs off. In practice this is fine because SkinnyDebbie is intended for single-user logins. The start-ivman script warns the user if someone else is already using automounting.
Not all media automounts, USB hard drives in particular
Solution:
- Add /etc/hal/fdi/policy/mountpolicies.fdi as documented in http://gentoo-wiki.com/HOWTO_ivman (2009.10.30 update: I think this has been moved to http://en.gentoo-wiki.com/wiki/Ivman).
- Remove CDROM and DVD but not FLOPPY entries from /etc/fstab.
- Remove CDROM and DVD but not FLOPPY links from /media.
- Remove CDROM and DVD but not FLOPPY links from /.
It's not at all obvious to the regular user where/when removable media is inserted
Solution:
- Edit ~/.ivman/IvmConfigActions.xml so that:
ROX-Filer announces the insertion of media and prompts the user for desired action (e.g., open /media directory, launch CD ripper, etc.)
ivman scans on init - Add /media link to the desktop
- Add /media link to Rox's bookmarks
- Add /media link to IceWM's "start" menu
There are several custom "annc" scripts (anncRoxMedia, anncCDDA, anncDVDvideo) that get called per media type. These scripts check to see if ROX's pinboard is running; if it is, then it will announce the insertion of media. The IceWM startup delays the start of ROX's pinboard by a few seconds so that the user doesn't get bombarded with media announcements when logging in.
If user logs off without unmounting stuff, the folders remain in /media but the media is not mounted
Solution:
- Write script pumountall that pumounts everthing and use it to unmount everything at logoff (via ~/.icewm/shutdown).
User needs guidance in good habits (i.e., unmount before remove)
Solution:
- Write script pumount-fb, which does pumount with GUI feedback.
- Tell ROX-Filer to use script pumount-fb to unmount.
CD and DVD media don't mount ... ever
See "Not all media automounts, USB hard drives in particular" above.
July 13, 2008
automounting
To be concise, automounting of removable media in Linux hurts.
SkinnyDebbie's first release has been held up by issues surrounding automounting. Getting automounting to sorta work is easy. Getting it to be reliable and usable is another story. I think I've finally gotten things figured out to the point where the system is sufficiently usable and reliable. But I would like to make sure that there are no gremlins hiding in the works. When mountpoints go bad, the results can be fairly ugly.
I also want to add a bit of UI sweetness to the automounting deal: I'd like the the appropriate folder to open in the file manager when the media is mounted to let the user know that the media has, in fact, been mounted. This shouldn't be too tough -- but then that's what I thought about automounting in general.
One annoying thing: Linux does not consider audio CDs and video DVDs mountable media. That means that you literally cannot mount either of these kinds of discs and browse their files on the command line or in your file manager. This doesn't mean you can't open discs in applications designed to read from them (e.g., VLC, Xine, Audacious); it just means that you can't ls, mv, cp, etc. the files on the discs. In theory, it's possible to set things up so that when you insert, say, an audio CD, an application that can read audio CDs will launch and open the CD in the application.
I'm dithering on whether this is a good idea or not. It's a good idea because it makes the life of the end user easier. But it's a bad idea because the application the system designer thinks is best for reading CDs or DVDs may not be the application the user prefers to use. In this case, the psuedo-automount is just a nuisance to the user. As near as I can tell, configuring what application is associated with CD/DVD media isn't that easy either.
Like I said, it hurts.
SkinnyDebbie's first release has been held up by issues surrounding automounting. Getting automounting to sorta work is easy. Getting it to be reliable and usable is another story. I think I've finally gotten things figured out to the point where the system is sufficiently usable and reliable. But I would like to make sure that there are no gremlins hiding in the works. When mountpoints go bad, the results can be fairly ugly.
I also want to add a bit of UI sweetness to the automounting deal: I'd like the the appropriate folder to open in the file manager when the media is mounted to let the user know that the media has, in fact, been mounted. This shouldn't be too tough -- but then that's what I thought about automounting in general.
One annoying thing: Linux does not consider audio CDs and video DVDs mountable media. That means that you literally cannot mount either of these kinds of discs and browse their files on the command line or in your file manager. This doesn't mean you can't open discs in applications designed to read from them (e.g., VLC, Xine, Audacious); it just means that you can't ls, mv, cp, etc. the files on the discs. In theory, it's possible to set things up so that when you insert, say, an audio CD, an application that can read audio CDs will launch and open the CD in the application.
I'm dithering on whether this is a good idea or not. It's a good idea because it makes the life of the end user easier. But it's a bad idea because the application the system designer thinks is best for reading CDs or DVDs may not be the application the user prefers to use. In this case, the psuedo-automount is just a nuisance to the user. As near as I can tell, configuring what application is associated with CD/DVD media isn't that easy either.
Like I said, it hurts.
July 02, 2008
An inadyn wrapper
Inadyn is a lightweight command-line tool for updating dynamic DNS addreses. Its use is supported by DynDNS, FreeDNS, and others. Binaries are available for Windows and Linux, and Debian and Ubuntu both have inadyn packages. Overall it seems like a good choice for a dynamic DNS update client.
In Linux, administrators usually set inadyn up to run as a daemon. But for regular desktop use this might present some problems. Most notably, if a network connection is not available when inadyn starts, it just exits. Another problem is that setting up a daemon can be a little scary for new users.
So I came up with a little script that can be run at login that launches inadyn not as a daemon but as a regular process. If the process is already running, it will warn the user. If the process didn't start, it will warn the user. If everything goes ok, it lets the process run and quietly retires.
You will have to hand-edit the 'inadynOptions' variable below to make it suit your needs. The whole thing looks like (you may need to copy/paste the text into a text editor if the left margins are cropped):
Be sure to set the file in which you save the script to be executable (using
You will also need to make /usr/sbin/inadyn executable by regular users. In a terminal:
To start the script in Xfce, open "Autostarted apps" and add an entry for
To start the script in IceWM, add
to your ~/.icewm/startup file (don't forget the & at the end of the line!). Adding just
seems to work as well.
In Linux, administrators usually set inadyn up to run as a daemon. But for regular desktop use this might present some problems. Most notably, if a network connection is not available when inadyn starts, it just exits. Another problem is that setting up a daemon can be a little scary for new users.
So I came up with a little script that can be run at login that launches inadyn not as a daemon but as a regular process. If the process is already running, it will warn the user. If the process didn't start, it will warn the user. If everything goes ok, it lets the process run and quietly retires.
You will have to hand-edit the 'inadynOptions' variable below to make it suit your needs. The whole thing looks like (you may need to copy/paste the text into a text editor if the left margins are cropped):
#! /bin/bash
# (c) 2008 Mithat Konar
# 2008-07-25
# Try to start an inadyn process. If it starts and doesn't quit right away
# (perhaps because the network isn't available) exit the script leaving the
# inadyn process running. Otherwise, prompt the user that it's not running
# and give the user the chance to try again or quit.
# Requires zenity
# =========
# constants
# =========
# use absolute paths only ... relative paths and env variables not tested! really!!
inadynOptions="--input_file /home/mithat/.inadyn/inadynAfraid.conf" # options to pass to inadyn
timeBetweenTries=20s # time between attempts to restart the process
# ==========
# UI strings
# ==========
uiAlreadyRunningTitle="Inadyn already running?"
uiAlreadyRunning="It looks as though
inadyn $inadynOptions
is already running.
Shall I force it to start anyway?"
uiNotRunningTitle="Inadyn not running"
uiNotRunning="Inadyn isn't running, possibly becuase the network isn't up.
Try again?"
# =========
# functions
# =========
# tryToStart() will try to start the process "inadyn $inadynOptions"
# it does not check to see if the process is running
# requres global variables 'timeBetweenTries' and 'inadynOptions'.
# writes the PID of the process to global variable 'PID'.
# if startup was successful, sets global variable 'isRunning' to
# process information, otherwise isRunning will be blank.
function tryToStart()
{
/usr/sbin/inadyn $inadynOptions & # try to start it
PID=$! # capture the process ID
sleep $timeBetweenTries # give it some time
isRunning=`ps aux | grep "inadyn $inadynOptions" | grep "$PID" | grep -v grep` # check
}
# ======
# "main"
# ======
isRunning=`ps aux | grep "inadyn $inadynOptions" | grep -v grep`
if [ -n "$isRunning" ] ; then
zenity --question --title "$uiAlreadyRunningTitle" --text "$uiAlreadyRunning"
if [ $? -eq 1 ] ; then
echo -e "$0: User cancelled"
exit 1
fi
fi
tryToStart # try to start the process
while [ -z "$isRunning" ] ; do # while the process isn't running ...
zenity --question --title "$uiNotRunningTitle" --text "$uiNotRunning"
if [ $? -eq 1 ] ; then
echo -e "$0: User cancelled"
exit 1
fi
tryToStart # try to start the process
done
Be sure to set the file in which you save the script to be executable (using
chmod or your file manager).You will also need to make /usr/sbin/inadyn executable by regular users. In a terminal:
sudo chmod u+s /usr/sbin/inadynTo start the script in Xfce, open "Autostarted apps" and add an entry for
bash -c "<path to the script>"To start the script in IceWM, add
bash -c "<path to the script>" &to your ~/.icewm/startup file (don't forget the & at the end of the line!). Adding just
<path to the script> &seems to work as well.
June 29, 2008
SkinnyDebbie : an introduction
It has required more work than I originally expected, but I think SkinnyDebbie--a light-and-lean proof-of-concept "distribution flavorizer"--is almost ready for its first public release.
SkinnyDebbie is a scripted installation scheme that lets a user set up a light-and-lean Debian-based Linux system without a huge hassle. It should be especially attractive to users of systems that are not powerful enough to run the Gnome, KDE or XFCE desktop environments.
SkinnyDebbie's main job is integrating the following windowing and desktop components into an efficient desktop environment:
It won't install a boatload of applications the way full-fat distributions do--mostly because if you are running a light-and-lean setup you are probably challenged for storage space. Thus, I figured it was best to leave the decisions regarding what application software you need up to you. However, it does install Debian's branded version of Firefox and Thunderbird (called Iceweasel and Icedove respectively) because not having a Web browser and (arguably) email is utterly insane.
Philosophy
SkinnyDebbie is what I am calling a "flavorizer". It is not a Linux distribution. Rather, it is a set of scripts that when run will configure a standard Linux distribution (a Debian Network Install in this case) to match a given target "flavor", using as much as possible the packages that are already part of and maintained by that distribution.
Why build SkinnyDebbie as a "flavorizer" instead of making an independent distribution? Simple. A "flavorizer" approach lets light-and-lean users directly benefit from the security updates and other improvements/upgrades of a major distribution. A SkinnyDebbie user gets a light-and-lean system that is 100% (ok ... 98%) pure Debian, and that means the user can participate in and benefit from Debian's excellent community support and other resources. (Or, if I were trying to sound ubercool, I would say that it means the user can leverage Debian's excellent community support and other resources.)
Known limitations
Networking works superfine if you are using an Ethernet connection and DHCP. This will be all most users will need. But if you plan to use a wireless connection or do not want to use DHCP, you will have to figure that out on your own. And if want to go old-school with a dialup modem, you're again on your own. I'm not saying it's not possible; I'm just saying that you will have to figure out what additional packages need to be installed and how configure things by yourself.
Advanced power management (sleep, suspend) is completely untested. It may work, it may not; but testing and tweaking it's not a priority.
Accessibility features (large print, high-contrast window decoration, etc.) don't exist.
Internationalization is a bit of a problem. The custom scripts and other bits are written to make it easy to implement translated versions, but no translations are available at present.
Installation
I'll post information regarding how to install SkinnyDebbie as soon as I finalize a couple small details and figure out how to host it. See you soon.
SkinnyDebbie is a scripted installation scheme that lets a user set up a light-and-lean Debian-based Linux system without a huge hassle. It should be especially attractive to users of systems that are not powerful enough to run the Gnome, KDE or XFCE desktop environments.
SkinnyDebbie's main job is integrating the following windowing and desktop components into an efficient desktop environment:
- IceWM: a lightweight yet full-featured window manager
- ROX-Filer: a fast and light file and desktop manager
- XDM: the classic display manager that is more resource-friendly than GDM or KDM
- Dropline Nuovo!: an icon set that is more inviting than the default Gnome icons
It won't install a boatload of applications the way full-fat distributions do--mostly because if you are running a light-and-lean setup you are probably challenged for storage space. Thus, I figured it was best to leave the decisions regarding what application software you need up to you. However, it does install Debian's branded version of Firefox and Thunderbird (called Iceweasel and Icedove respectively) because not having a Web browser and (arguably) email is utterly insane.
Philosophy
SkinnyDebbie is what I am calling a "flavorizer". It is not a Linux distribution. Rather, it is a set of scripts that when run will configure a standard Linux distribution (a Debian Network Install in this case) to match a given target "flavor", using as much as possible the packages that are already part of and maintained by that distribution.
Why build SkinnyDebbie as a "flavorizer" instead of making an independent distribution? Simple. A "flavorizer" approach lets light-and-lean users directly benefit from the security updates and other improvements/upgrades of a major distribution. A SkinnyDebbie user gets a light-and-lean system that is 100% (ok ... 98%) pure Debian, and that means the user can participate in and benefit from Debian's excellent community support and other resources. (Or, if I were trying to sound ubercool, I would say that it means the user can leverage Debian's excellent community support and other resources.)
Known limitations
Networking works superfine if you are using an Ethernet connection and DHCP. This will be all most users will need. But if you plan to use a wireless connection or do not want to use DHCP, you will have to figure that out on your own. And if want to go old-school with a dialup modem, you're again on your own. I'm not saying it's not possible; I'm just saying that you will have to figure out what additional packages need to be installed and how configure things by yourself.
Advanced power management (sleep, suspend) is completely untested. It may work, it may not; but testing and tweaking it's not a priority.
Accessibility features (large print, high-contrast window decoration, etc.) don't exist.
Internationalization is a bit of a problem. The custom scripts and other bits are written to make it easy to implement translated versions, but no translations are available at present.
Installation
I'll post information regarding how to install SkinnyDebbie as soon as I finalize a couple small details and figure out how to host it. See you soon.
June 25, 2008
DPI: part 1
Another example of "too much choice can be a bad thing" rears its head in the way that Linux renders text. The headaches arise out of the interaction between a few variables, some of which may or may not be known. Lets try to break this down a little bit.
Screen resolution
The easiest variable to understand in Linux's windowing/font-rendering system is what most people call screen resolution. It's also the easiest part for Linux's X.Org windowing system to get right. Screen resolution is simply a measure of the raw number of pixels used to draw your display. Common sizes are 800x600, 1024x768, 1280x800, etc. These are familiar numbers to Windows users.
The X.Org server installation process executes a command that 1) tries to determine what resolutions are supported by your connected display, 2) asks you which ones you want to use, and 3) writes a configuration file /etc/X11/xorg.conf that stores this and other information. Sweet. Easy.
Screen size
Screen size refers to the actual physical size of the display, measured in millimeters. This is where things can start to go a little wonky. When the X.Org server installer creates its main configuration file (i.e., /etc/X11/xorg.conf), it also asks the display (not you) how big it is. Sometimes a display knows how big it is, sometimes it doesn't. If the display reports a size in a way the installer understands, this information gets stored in the configuration file. If the display doesn't, then it doesn't.
The result is that sometimes X.Org server knows how big your monitor is, and sometimes it doesn't.
DPI
DPI stands for dots-per-inch and is probably the hardest concept to get your head around -- and the hardest part for Linux to get right.
Font sizes are typically defined in points, where one point equals 1/72 inch. Therefore, a system that renders fonts on a computer screen needs to know how many dots-per-inch it should use to draw the text. If the DPI setting is not correct, then all text will appear either too small or too large.
It's quite natural to think that a screen's DPI should simply equal the number of pixels in a dimension divided by the physical size. If we have a 1024x768 screen and the screen is 10.7" wide by 8" high, then we should get 96 DPI in both horizontal and vertical dimensions. If we have an 800x600 screen that is the same physical size, then that should result in 75 DPI. However, life in Linux-land is not quite that simple. One of the reasons is technological, the other is contextual.
First the technological issue. Remember above we said that the X.Org server configuration process tries to figure out physically how big your screen is? A problem arises when for whatever reason the screen's physical size doesn't get recorded into the /etc/X11/xorg.conf configuration file. This happens often enough, and when it does, the poor system simply has to guess what DPI to use. The results can be pretty tragic.
The contextual issue is a result of the way things work in Windows and MacOS. In both of these systems, the DPI is fixed no matter what physical screen size you have. Windows' default is 96 DPI, although you can change this to 120 DPI by using the "large fonts" mode. (In fact, you can tell Windows to use whatever DPI you want, but I've never seen this in practice so I am concluding that it is rarely done.) Apparently, MacOS defaults to 72 DPI.
Some Linux developers assert that Linux should follow Windows' "defacto" standard and set systems to 96 DPI, no questions asked. Some developers (therefore?) assume 96 DPI when they develop their software. Others don't. This results in a situation where you can't get all your software to look right no matter what your DPI setting is without additional tweaking.
Note that this DPI concept only affects text rendering. The sizes of icons and similar things are usually set in pixels, and a pixel is a pixel in Linux.
Overriding DPI
Normally, X.Org will try to calculate your system DPI based on the screen size and the display's resolution. If it doesn't know the screen size, it will make a guess. However, it is possible to override the calculated/guessed DPI setting. Since this is Linux, there's more than one way to do it, and I have listed the methods I have actually used below. Except for one they all involve editing configuration files. If the following doesn't work for you, please do some Googling and let me know what else you find.
1. Overriding DPI with a local configuration file
I have used this method with Debian Etch and Xubuntu 7.10. It did not seem to work with Xubuntu 8.04, so expect your milage to vary. It is, however, the easiest way to set DPI.
If a file called .Xresources doesn't already exist in your home directory, create it. (Rememeber that the '.' makes the file hidden!) Add the following line to it:
where
When you log out and log back in, you should be using the new DPI setting. If not, delete the file and try another method.
2. Overriding DPI using a session manager's global configuration file
The following will only work if you are using XDM (rather than the more common GDM or KDM) as your session manager. However, you can do something similar with GDM and KDM. I have used this with Debian Etch using XDM instead of the default GDM, and it works as expected.
Make a backup copy of the file /etc/X11/xdm/Xservers. (This will let you get back to where you were in case you mess something up.) Open /etc/X11/xdm/Xservers as root in a text editor. Find the line towards the bottom of the file that looks something like
The line in your file may not be identical to the above, but it should be similar. Add a
If the line already has a
Restart the X server (by rebooting or typing Ctrl-Alt-Backspace) and log back in. You should now be using the DPI you specified.
3. Overriding DPI with the global X configuration file
This is the most foolproof method and also the most difficult. Basically, we are going to hand edit the /etc/X11/xorg.conf file and tell it the size of the screen we have so that it produces the desired DPI. I am using this method on an old laptop with an 800x600 screen running Xubuntu 8.04 and it works.
Make a backup copy of the file /etc/X11/xorg.conf. (This will let you get back to where you were in case you mess something up.) Open /etc/X11/xorg.conf as root in a text editor. Find the section in the file that begins
(In case you forgot, one inch equals 25.4 millimeters.)
As an example, the section from the xorg.conf file used in my 800x600 laptop system looks like:
Don't change anything else! Just add (or edit) the one line that specifies the monitor's size. The dimensions you use should be either the real physical dimensions of the screen (in mm) or values that you have calculated to produce the DPI you want.
Restart X (reboot or Ctrl-Alt-Backspace) and see the results. From what I gather, there are some video cards that require even more xorg.conf tweaking to make behave, so if this doesn't work, do some Googling with xorg.conf and the brand/name of your card.
In case something goes wrong
If you really mess up your /etc/X11/xorg.conf file, you can regenerate it by running from the command line:
for the simple version, or:
to set each and every option. Depending on your distribution, you may need to delete the messed up /etc/X11/xorg.conf file before it will be replaced. You should also execute the above if you change displays.
4. Overriding DPI when not using a session manager
This is also a foolproof method, but it only works if you don't use a session manager and instead use the command-line to start the window system. (If you are using SLiM, I believe you can tweak it to use this method as well.)
The standard way to start X from the command line is the
Make sure you get all the dashes correct.
Looking forward
In an upcoming post, I will let you know what appears to be best practices regarding DPI settings. But first I need to do some more work on this. In particular, it looks as though there are DPIs for Xserver DPI and for Xft (the tool used to render Linux's "pretty" fonts) and it looks like they don't need to agree. And then there's the fonts themselves.
It really is a bit of a mess, isn't it?
Screen resolution
The easiest variable to understand in Linux's windowing/font-rendering system is what most people call screen resolution. It's also the easiest part for Linux's X.Org windowing system to get right. Screen resolution is simply a measure of the raw number of pixels used to draw your display. Common sizes are 800x600, 1024x768, 1280x800, etc. These are familiar numbers to Windows users.
The X.Org server installation process executes a command that 1) tries to determine what resolutions are supported by your connected display, 2) asks you which ones you want to use, and 3) writes a configuration file /etc/X11/xorg.conf that stores this and other information. Sweet. Easy.
Screen size
Screen size refers to the actual physical size of the display, measured in millimeters. This is where things can start to go a little wonky. When the X.Org server installer creates its main configuration file (i.e., /etc/X11/xorg.conf), it also asks the display (not you) how big it is. Sometimes a display knows how big it is, sometimes it doesn't. If the display reports a size in a way the installer understands, this information gets stored in the configuration file. If the display doesn't, then it doesn't.
The result is that sometimes X.Org server knows how big your monitor is, and sometimes it doesn't.
DPI
DPI stands for dots-per-inch and is probably the hardest concept to get your head around -- and the hardest part for Linux to get right.
Font sizes are typically defined in points, where one point equals 1/72 inch. Therefore, a system that renders fonts on a computer screen needs to know how many dots-per-inch it should use to draw the text. If the DPI setting is not correct, then all text will appear either too small or too large.
It's quite natural to think that a screen's DPI should simply equal the number of pixels in a dimension divided by the physical size. If we have a 1024x768 screen and the screen is 10.7" wide by 8" high, then we should get 96 DPI in both horizontal and vertical dimensions. If we have an 800x600 screen that is the same physical size, then that should result in 75 DPI. However, life in Linux-land is not quite that simple. One of the reasons is technological, the other is contextual.
First the technological issue. Remember above we said that the X.Org server configuration process tries to figure out physically how big your screen is? A problem arises when for whatever reason the screen's physical size doesn't get recorded into the /etc/X11/xorg.conf configuration file. This happens often enough, and when it does, the poor system simply has to guess what DPI to use. The results can be pretty tragic.
The contextual issue is a result of the way things work in Windows and MacOS. In both of these systems, the DPI is fixed no matter what physical screen size you have. Windows' default is 96 DPI, although you can change this to 120 DPI by using the "large fonts" mode. (In fact, you can tell Windows to use whatever DPI you want, but I've never seen this in practice so I am concluding that it is rarely done.) Apparently, MacOS defaults to 72 DPI.
Some Linux developers assert that Linux should follow Windows' "defacto" standard and set systems to 96 DPI, no questions asked. Some developers (therefore?) assume 96 DPI when they develop their software. Others don't. This results in a situation where you can't get all your software to look right no matter what your DPI setting is without additional tweaking.
Note that this DPI concept only affects text rendering. The sizes of icons and similar things are usually set in pixels, and a pixel is a pixel in Linux.
Overriding DPI
Normally, X.Org will try to calculate your system DPI based on the screen size and the display's resolution. If it doesn't know the screen size, it will make a guess. However, it is possible to override the calculated/guessed DPI setting. Since this is Linux, there's more than one way to do it, and I have listed the methods I have actually used below. Except for one they all involve editing configuration files. If the following doesn't work for you, please do some Googling and let me know what else you find.
1. Overriding DPI with a local configuration file
I have used this method with Debian Etch and Xubuntu 7.10. It did not seem to work with Xubuntu 8.04, so expect your milage to vary. It is, however, the easiest way to set DPI.
If a file called .Xresources doesn't already exist in your home directory, create it. (Rememeber that the '.' makes the file hidden!) Add the following line to it:
Xft.dpi: <dpi>
where
<dpi> is the DPI you want to use. For example, to force the system to use 96 DPI:Xft.dpi: 96
When you log out and log back in, you should be using the new DPI setting. If not, delete the file and try another method.
2. Overriding DPI using a session manager's global configuration file
The following will only work if you are using XDM (rather than the more common GDM or KDM) as your session manager. However, you can do something similar with GDM and KDM. I have used this with Debian Etch using XDM instead of the default GDM, and it works as expected.
Make a backup copy of the file /etc/X11/xdm/Xservers. (This will let you get back to where you were in case you mess something up.) Open /etc/X11/xdm/Xservers as root in a text editor. Find the line towards the bottom of the file that looks something like
:0 local /usr/bin/X vt7 -nolisten tcp
The line in your file may not be identical to the above, but it should be similar. Add a
-dpi <dpi> option to the line that specifies the DPI you wish to use. For example, to force 96 DPI, you would add the option as below::0 local /usr/bin/X vt7 -dpi 96 -nolisten tcp
If the line already has a
-dpi option, then change the number to reflect the DPI you want.Restart the X server (by rebooting or typing Ctrl-Alt-Backspace) and log back in. You should now be using the DPI you specified.
3. Overriding DPI with the global X configuration file
This is the most foolproof method and also the most difficult. Basically, we are going to hand edit the /etc/X11/xorg.conf file and tell it the size of the screen we have so that it produces the desired DPI. I am using this method on an old laptop with an 800x600 screen running Xubuntu 8.04 and it works.
Make a backup copy of the file /etc/X11/xorg.conf. (This will let you get back to where you were in case you mess something up.) Open /etc/X11/xorg.conf as root in a text editor. Find the section in the file that begins
Section "Monitor" and add a line (or edit the line if one already exists) that specifies the width and height of your screen (in mm) using the syntax:DisplaySize <width> <height>
(In case you forgot, one inch equals 25.4 millimeters.)
As an example, the section from the xorg.conf file used in my 800x600 laptop system looks like:
Section "Monitor" Identifier "Configured monitor" DisplaySize 246 184 EndSection
Don't change anything else! Just add (or edit) the one line that specifies the monitor's size. The dimensions you use should be either the real physical dimensions of the screen (in mm) or values that you have calculated to produce the DPI you want.
Restart X (reboot or Ctrl-Alt-Backspace) and see the results. From what I gather, there are some video cards that require even more xorg.conf tweaking to make behave, so if this doesn't work, do some Googling with xorg.conf and the brand/name of your card.
In case something goes wrong
If you really mess up your /etc/X11/xorg.conf file, you can regenerate it by running from the command line:
$ sudo dpkg-reconfigure -phigh xserver-xorgfor the simple version, or:
$ sudo dpkg-reconfigure -plow xserver-xorgto set each and every option. Depending on your distribution, you may need to delete the messed up /etc/X11/xorg.conf file before it will be replaced. You should also execute the above if you change displays.
4. Overriding DPI when not using a session manager
This is also a foolproof method, but it only works if you don't use a session manager and instead use the command-line to start the window system. (If you are using SLiM, I believe you can tweak it to use this method as well.)
The standard way to start X from the command line is the
startx command. You can pass the command a parameter that tells it what DPI to use. For example, to start X windows and tell it to use 96 DPI,$ startx -- -dpi 96Make sure you get all the dashes correct.
Looking forward
In an upcoming post, I will let you know what appears to be best practices regarding DPI settings. But first I need to do some more work on this. In particular, it looks as though there are DPIs for Xserver DPI and for Xft (the tool used to render Linux's "pretty" fonts) and it looks like they don't need to agree. And then there's the fonts themselves.
It really is a bit of a mess, isn't it?
May 06, 2008
Update
It's been a while since my last post. I've been busy developing a scripted install for a light-and-lean Debian system, and it's turning out to be more work that I originally expected. Most of the additional work is coming from the critical need I saw for some service applications as well as a few tweaks to pre-existing Apps.
I think I see the light at the end of the tunnel ... as well as an attractive fork in the road: the latest version of Ubuntu (Hardy Heron) while having a sorta-stupid name is an LTS release. That makes it quite attractive, especially given that Debian Etch may be aging a bit.
I think I see the light at the end of the tunnel ... as well as an attractive fork in the road: the latest version of Ubuntu (Hardy Heron) while having a sorta-stupid name is an LTS release. That makes it quite attractive, especially given that Debian Etch may be aging a bit.
March 26, 2008
File managers
Linux gives you a choice of about a million different file managers. They differ in how much they do, how they do it, whether they are text or graphic based, etc. I have been able to narrow things down from the available choices to three that make sense to me. Each have their pros and cons and are discussed below.
The standards for selection are that the manager be fully GUI based and it must behave well. Even though this whole deal is about being light and lean, I consider ncurses or otherwise not fully GUI managers just too primitive for most users—including myself.
The three finalists currently on the shortlist are Thunar, ROX-filer, and PCManFM. An honorable mention needs to go out to XFE. It has its heart in the right place, but I just couldn't get it to look right.
Thunar
Thunar is the file manager used in the Xfce desktop package. Although part of the Xfce desktop, there is nothing to keep you from using it under other window managers.
Pros:
* Looks good.
* Automounts removable media (this is huge).
* Talks to Firefox/Iceweasel's download window—meaning that "Open" and "Open containing folder" links in Firefox/Iceweasel's download window work as expected.
Cons:
* It's the biggest of the three and therefore takes a relatively long time to load.
ROX-filer
ROX has been around for a while and is part of a larger ROX-desktop initiative. It is actively developed and has a strong following. Many of the parts that make up the whole ROX-desktop world are also worth investigating, particularly the concept of "zero install"—which replaces the idea of installing software with the idea of requesting software execution.
Pros:
* Fastest of the three
* Built-in drag-and-drop desktop management (and more).
* Looks, while not as conventional as the other two, are good. You might even call it cute.
Cons:
* Locating and selecting files/directories using just the keyboard is frustrating (e.g., typing the name of a file does not select it).
* Doesn't talk to Firefox/Iceweasel
* No "sidebar"
PCManFM
If I remember correctly, PCManFM is developed as a side-project by a Taiwanese medial student. (And I whine because I never seem to have enough time ...) It's designed to be lightweight and useful.
Pros:
* Faster than Thunar (but not as fast as ROX).
* Has tabbed panes.
* Can manage the desktop (though support for this in the version I tried was not very good).
Cons:
* Development is slow
* Doesn't talk to Firefox/Iceweasel
* Some reports of stability issues
Of the three, I think ROX has the most balanced promise, and that is what I am trying to make go at the moment. However, the other two are still quite tempting—especially Thunar's automounting.
The standards for selection are that the manager be fully GUI based and it must behave well. Even though this whole deal is about being light and lean, I consider ncurses or otherwise not fully GUI managers just too primitive for most users—including myself.
The three finalists currently on the shortlist are Thunar, ROX-filer, and PCManFM. An honorable mention needs to go out to XFE. It has its heart in the right place, but I just couldn't get it to look right.
Thunar
Thunar is the file manager used in the Xfce desktop package. Although part of the Xfce desktop, there is nothing to keep you from using it under other window managers.
Pros:
* Looks good.
* Automounts removable media (this is huge).
* Talks to Firefox/Iceweasel's download window—meaning that "Open" and "Open containing folder" links in Firefox/Iceweasel's download window work as expected.
Cons:
* It's the biggest of the three and therefore takes a relatively long time to load.
ROX-filer
ROX has been around for a while and is part of a larger ROX-desktop initiative. It is actively developed and has a strong following. Many of the parts that make up the whole ROX-desktop world are also worth investigating, particularly the concept of "zero install"—which replaces the idea of installing software with the idea of requesting software execution.
Pros:
* Fastest of the three
* Built-in drag-and-drop desktop management (and more).
* Looks, while not as conventional as the other two, are good. You might even call it cute.
Cons:
* Locating and selecting files/directories using just the keyboard is frustrating (e.g., typing the name of a file does not select it).
* Doesn't talk to Firefox/Iceweasel
* No "sidebar"
PCManFM
If I remember correctly, PCManFM is developed as a side-project by a Taiwanese medial student. (And I whine because I never seem to have enough time ...) It's designed to be lightweight and useful.
Pros:
* Faster than Thunar (but not as fast as ROX).
* Has tabbed panes.
* Can manage the desktop (though support for this in the version I tried was not very good).
Cons:
* Development is slow
* Doesn't talk to Firefox/Iceweasel
* Some reports of stability issues
Of the three, I think ROX has the most balanced promise, and that is what I am trying to make go at the moment. However, the other two are still quite tempting—especially Thunar's automounting.
March 21, 2008
Guides
I added a new "Guides" section in the Links section (on the right) where I will try to summarize what I've learned so far in this adventure in a way that's operationally relevant. A beta version of the first guide, "A Lighter Debian", has been posted. I have also added a "Recommended Practices" section to make deciding what to do a little easier. Following these will be "An Even Lighter Debian" that documents how to make an, er, even lighter Debian. Eventually I will also publish a "Minimal usable Debian" guide to help you setup a minimal GUI system that you can then tweak to your heart's content.
March 19, 2008
Xubuntu--the hard way
I recently tried installing Xubuntu "Gutsy Gibbon" on an older laptop using a whole bunch of methods: the "alternate" Xubuntu 7.10 installer CD, the "alternate" Ubuntu 7.10 installer CD, the "server" Ubuntu 7.10 installer CD ... and they all failed. In all cases, the problem was the same. After the installer booted off the CD and moved through some preliminary information gathering, it would complain that the CD-ROM from which it had been loading was no longer mounted/found (Do you want to install the drivers from a floppy?).
Eh?
A visit to the Ubuntu forums didn't really help... a couple other people had the same problem but with no solution. My best working theory at this point is that the problem is caused by the CD-ROM being an older LG device. There was a time where installing (some?) Linux would allegedly destroy (some?) LG CD-ROM drives. I think that this made a lot of developers paranoid and build kernels without support for many (all?) LG CD-ROM drives. Or not.
In any case, I managed to work around the problem and get Xubuntu installed. That's the good news. The bad news is that the system doesn't recognize the CD-ROM drive, but I was expecting that to happen anyway.
Here's what I did:
1. Download the "Minimal CD" version of the Ubuntu install CD--which basically does a network installation, sucking in what it needs over the Internet.
2. When you get to the point in the process that asks you if you want to install a desktop environment, indicate that you want XFCE/Xubuntu.
3. There is no third step.
It took forever to download the desktop environment, but it worked. It's a little interesting (and scary) that I didn't have this problem with Debian Etch, and I hope the next version of Ubuntu fixes the problem and/or the next version of Debian doesn't break it.
Eh?
A visit to the Ubuntu forums didn't really help... a couple other people had the same problem but with no solution. My best working theory at this point is that the problem is caused by the CD-ROM being an older LG device. There was a time where installing (some?) Linux would allegedly destroy (some?) LG CD-ROM drives. I think that this made a lot of developers paranoid and build kernels without support for many (all?) LG CD-ROM drives. Or not.
In any case, I managed to work around the problem and get Xubuntu installed. That's the good news. The bad news is that the system doesn't recognize the CD-ROM drive, but I was expecting that to happen anyway.
Here's what I did:
1. Download the "Minimal CD" version of the Ubuntu install CD--which basically does a network installation, sucking in what it needs over the Internet.
2. When you get to the point in the process that asks you if you want to install a desktop environment, indicate that you want XFCE/Xubuntu.
3. There is no third step.
It took forever to download the desktop environment, but it worked. It's a little interesting (and scary) that I didn't have this problem with Debian Etch, and I hope the next version of Ubuntu fixes the problem and/or the next version of Debian doesn't break it.
SLiM
I decided to take a closer look at SLiM--the Simple Login Manager--as used by Fluxbuntu (instead of GDM). SLiM is light (about the same as XDM) and it looks really good, even in its default state. What more could you want?
Turns out that while SLiM makes logging into your session easy, it makes powering off or restarting your system from the login screen something of a pain. You need to use "special names" or setup special accounts with special permissions. Either approach is 1) not intuitive from the user's point of view and 2) a security risk. The developers say that implementing a better method is on the TODO list. Once this is done, I think SLiM will be a credible and much more attractive alternative to XDM.
Turns out that while SLiM makes logging into your session easy, it makes powering off or restarting your system from the login screen something of a pain. You need to use "special names" or setup special accounts with special permissions. Either approach is 1) not intuitive from the user's point of view and 2) a security risk. The developers say that implementing a better method is on the TODO list. Once this is done, I think SLiM will be a credible and much more attractive alternative to XDM.
February 14, 2008
A Debian alternative?
I just noticed that Debian has a single-CD distribution that uses Xfce as the window manager, Thunar as a file manager, and GDM as the desktop manager. It's a full-featured install, with GIMP and OpenOffice goodness standard. It seems a credible alternative to Xubuntu.
I installed it on a 128MB/466Hz machine as well as in the virtualized environment on my 1.7GHz laptop. In both cases I configured Xfce and GDM to use the minimal amount of eye candy, and in both cases the result seemed better than Xubuntu under similar circumstances. However, I will need some more testing to be sure.
Debian with Xfce/Thunar/GDM still eats a lot of RAM. On the 128MB/466MHz machine it's just barely tolerable. I really wish that Ubuntu and Debian would consider IceWM for their light-and-lean distributions as still nothing I have found beats it for performance and RAM use. I keep hoping to find something that's easier to install but as fast and usable (and maybe a bit more sexy) than IceWM/ROX-filer/XDM, but still no luck.
I installed it on a 128MB/466Hz machine as well as in the virtualized environment on my 1.7GHz laptop. In both cases I configured Xfce and GDM to use the minimal amount of eye candy, and in both cases the result seemed better than Xubuntu under similar circumstances. However, I will need some more testing to be sure.
Debian with Xfce/Thunar/GDM still eats a lot of RAM. On the 128MB/466MHz machine it's just barely tolerable. I really wish that Ubuntu and Debian would consider IceWM for their light-and-lean distributions as still nothing I have found beats it for performance and RAM use. I keep hoping to find something that's easier to install but as fast and usable (and maybe a bit more sexy) than IceWM/ROX-filer/XDM, but still no luck.
Subscribe to:
Posts (Atom)