A Summary of Linux vs. Windows XP

As you may have figured out by now, I don’t use Windows XP full-time any more. I only use it for one or two games. Anyway, I don’t think I’ve written a post yet comparing Linux (Arch Linux to be specific) to Windows XP. I keep referring to XP, because that’s the last Windows OS I’ve actually used on my own machines. But the points that follow still pertain to the latest incarnation of Windows (Windows 7), and perhaps all future versions of it.

I just had to get these annoyances about XP out of my system, and let you, my dear reader, know about them. So the following is my very biased point of view as a relatively new, SELF-IMPOSED Linux convert:

Linux pros:

  • Unlimited, sane configurability: Everything you can imagine about Linux can be configured with TEXT FILES (or simple TEXT based interfaces), containing HUMAN-READABLE text. There are no strange “registry” files like in Windows, and hence, no need to invoke strange programs like “regedit.exe” to do your bidding. If you know how to use a text editor (what you Windows folks hideously understand as “Notepad”), then nothing can stand in your way. EVERYTHING is exposed by Linux. An extremely simple root vs. non-root user dichotomy ensures sane, “system files” vs. “user files” separation. Windows is living in the stone age when it comes to user rights/management.
  • Few, if any, viruses: Because the consumer-level Linux ecosystem is so small, evil hackers don’t spend time writing virus programs for it. More on this virus/malware/spyware discussion below.
  • Does not slow down or get unstable with uptime: If you leave your Windows computer on for more than a day, it’s bound to slow down. Linux has never done this to me. Ever. Even with uptimes past 5 days.
  • Simplified, unified, and standardized software installation/upgrade/removal: On Windows, individual programs have to check if a newer version of itself is available. There is no standard for this — some programs do it automatically if you’re connected to the internet, some programs ask for your approval (incessantly), some programs have a “Check for updates…” button that you have to manually click on, and some are just standalone .exe files that you need to manually remove and reinstall with the newer version! This is insanity. On Arch (or any other desktop-user distro), you just type in your shell “sudo pacman -Syu” to do a system-wide upgrade. With a single command, you upgrade every single package that you have installed (after transparently downloading them from Arch’s world-wide network of package “repositories”). Here, “package” means either a program, or system files — even the OS kernel! You can optionally choose to upgrade only certain packages, or to ignore some of them, to customize your upgrade. Some Archers upgrade every day, and others wait a month or more to upgrade. There are no nag screens, popups, or “automatic” upgrades/installs that break behind your back should you choose to shut down your computer.
  • Tons of free, industrial-strength software: Actively-developed open source programs are, quite simply, the most reliable, robust programs around. Take for example the Linux Kernel: this project is one of the finest achievements of software engineering to date. Legions of high-profile companies rely on the Linux Kernel to power their servers (and many thousands of Linux desktop users, like myself, benefit from this same, state-of-the-art reliability). And because free, open source software (“FOSS”) developers are humans too, there are mountains of open source programs for your use. Things like text editors, web browsers, email clients, office suites, image editors, movie editors, etc. all exist for free in FOSS-land. And many of these programs are the very best in their field, because they are extremely actively developed (where new releases come in weeks or months, instead of years). The Arch repositories are packed with FOSS programs. Packed, I say!
  • No malware/spyware: In Arch, there are two types of repositories: official and unofficial. The official repository only has packages that have been examined, tested, and uploaded by sanctioned members of the Arch Linux Team. The unofficial repositories are those repositories that have packages uploaded by anyone. The biggest and most popular unofficial repository is the Arch User Repository (“AUR”), which has thousands of packages. As time progresses, popular packages from the AUR collect votes from users, and the most popular ones receive the blessings of the Arch Linux Team and gets adopted into the official repository, and hence undergo regular, official maintenance. In short, the room for spyware/malware to creep into any of the official repositories is virtually zero. Even if you install an AUR package that has 0 votes for it, the de facto AUR client yaourt will still tell you to examine the contents of all installation files (these are, predictably enough in the Linux world, TEXT files) before executing them. Of course, you could go out of your way to download a suspicious-looking executable file and run it, but such a course of action is rare and remote enough (and downright stupid enough) to ignore.
  • No annoyances: Two things: (1) Because 95+% of software you use will be FOSS in Linux, this means that there will be no annoyances from programs. By “annoyances” I mean things like unrequested popups, tooltips, and screen-real-estate-plundering dialog boxes. This is because FOSS is community-driven — if a majority of users find some feature in a FOSS program annoying, it will get removed soon enough. This feature of FOSS does not get enough visibility, but it is one of the most satisfying: the absence of half-assed work by imminent-deadline-driven, exhausted developers. (2) Because Linux is so configurable, you can configure-away lesser annoyances by editing HUMAN-readable TEXT files 99% of the time. The other 1% of the time, you have to use TEXT-driven interactive sessions, which is just as easy to do.
  • Fast, easy problem resolution: Let’s say you did a system upgrade, and something broke as a result. Because there are hundreds, if not thousands, of users who all run the same system (see “Simplified, unified, and standardized software installation/upgrade/removal” above), your problem will be voiced in your distro’s forum soon enough. Windows users have an instinctive distrust of other Windows users: you have no idea what programs they’ve installed, and which anti-virus programs they have running (if at all!). This is why fixing a Windows problem takes quite a bit of skill and specialized expertise (and why, if you’re a geek, others tend to ask you to fix their Windows problems). Not so with Linux. If you encounter an error, all you have to do is copy/paste the error message (human-readable, SAVE-able error messages are part of FOSS culture) into a search engine and add in the name of your distro and the word “forum”. You are now one or two clicks away from reading the latest word (in the world) on the problem.
  • Gentle, but eventual, path to a true understanding of your operating system’s ecosystem: Here, I define “OS ecosystem” as understanding how and why your operating system behaves the way it does. Windows is a horrible platform to learn how your OS behaves. This is because it actively hides many important concepts from you. For example, do you have any idea how and why a program shows up on the “Add/Remove Programs” list on XP, even though you just removed it? (Answer: NO.) Such mystical voids of system-level confusion are rather rare in the Linux world.

Windows pros:

  • Industry-leading games: Almost all commercial games are released for Windows.

Seriously, after all of the extremely positive things that I’ve said about Linux, and how Windows fails in each of those areas, what can I say?

Misunderstandings about Linux (unfortunate from the Linux/FOSS community’s perspective):

  • It’s only for power users: No, it’s for people who don’t mind learning why their computer behaves a certain way. If you enjoy driving your car blindfolded, you are the right type of person to use Windows (actually, Mac OSX might be a better candidate).
  • It’s 100% secure: Yes, after all the overwhelmingly positive things I’ve said about the rarity of viruses/spyware/malware on Linux, nothing’s perfect. However, I will at least argue that Linux is more secure than Windows, because Linux does not hide things as much. I mean, there are dozens of sites out there designed to answer the question, “Is svchost.exe a safe process? How about wuauclt.exe?”, all because of how Windows likes to hide things from you. In Linux, pretty much everything is exposed. In Arch, specifically, you can do a “pacman -Qo XYZ” to see which package is responsible for that file. If no package is responsible for it, then that means either (1) a program created that file (e.g., an optional configuration file) or (2) you created it yourself!
  • If you use Linux, you’re an evil hacker: Congratulations, you’ve been brainwashed.

All non-brain-damaged people get sick and tired of Windows’ limitations and shortcomings every day. There are no secrets in the Windows world when it comes to user dissatisfaction. I used to be one of these people. Then one day, I started using Linux. And the difference is night and day. It’s just unfortunate that legions of PC users have been brainwashed to accept non-configurability and the “Windows way” to do a simple task: make the computer work for them for their needs. I used to be brainwashed that way. Here are some things that opened my eyes to just how horrible Windows is out of the box (Windows’ default “feature” vs. Linux’s superior equivalent):

  • “shortcuts” vs. symlinks (downright superior in every way)
  • “drives” (C:\, D:\, … Z:\) vs. mount points (unlimited and customizable)
  • “cmd.exe” vs. zsh/bash/etc (it’s like comparing the speed of a clown’s unicycle with a Formula-1 race car)
  • “Notepad” vs. vim/emacs (I’m at a loss for words)
  • “MS Word” vs. latex/xetex (imagine if MS Word did everything transparently: enter latex)
  • “I need Adobe program XYZ to export to PDF documents” vs. “Not in Linux.” (need I say more?)
  • “CPU-Z” vs. “cat /proc/cpuinfo” (no wonder there’s no CPU-Z for Linux; you don’t need it!)
  • none vs. “sleep 10m; echo ‘alarm message’; mplayer alarm.mp3” (super-simple, customizable alarm)
  • none vs. “sleep 1h5m3s; sudo shutdown -t 1 -hP now & disown; exit” (which means, “turn off the computer 1 hour, 5 minutes, 3 seconds from now”; the long command that starts with “sudo …” is actually aliased to just “of” for me, so I actually only type “sleep 1h5m3s; of”)
  • none vs. “sleep 1h5m3s; sudo shutdown -t 1 -r now & disown; exit” (which means “restart the computer 1 hour, 5 minutes, 3 seconds from now”; I use an alias here as well)

And here are some precious programs/tools that I had zero knowledge of until I entered the Linux/FOSS community:

  • vim (see above)
  • the latex toolchain (see above)
  • ssh (it’s zsh/bash/etc, but on a remote machine)
  • scp (transfer files over to a remote machine, but encrypt it during the transmission for state-of-the-art security)
  • rsync (copy files over to a remote machine; if a similar file already exists there, rsync will take less time to complete the copy)
  • git (source code management system; GREAT for backing up configuration files, text files, etc.)
  • mutt (text-based, no-nonsense email client)
  • gnupg (cutting-edge encryption tool to encrypt your most important files)
  • cron daemon (another TEXT based, no-nonsense way to control which programs/commands are regularly run at which intervals (minutes, hours, days… even years!))

Perhaps the most rewarding feature of using Linux is that there is always something to learn from it. In other words: the longer you use it, the more you learn to control and customize your computing experience (versus “the more I use Windows, the better I get fixing it”).

I must reiterate that I am a SELF-IMPOSED Linux convert. I didn’t get pushed into Linux, or had to learn it for some school/work requirement. I did it first as an adventure, and later on, just fell in love with it. No one held hands with me, and the help that I did get came from the internet. Linux reached critical mass years ago, and there are enough forum/blog posts out there to help you if you ever get stuck.

Use Linux!

UPDATE January 3, 2012: I just re-read this post (as I do time to time with my other posts) because Antaku commented on it, and wanted to list some awesome FOSS software that I forgot to mention:

  • diff/colordiff: This is probably the second-most important thing after text editors when it comes to dealing with text files — it tells you the difference between two text files. English teachers: when they turn in their drafts, you can immediately tell what parts they changed in 0.01 seconds. You don’t have to re-read half of it! There are tons of other useful things you can do with diff, any time text files are involved.
  • sha1sum: State-of-the-art file integrity verifier (using the very famous SHA-1 hash algorithm). It generates a 40-byte digital fingerprint, called a “hash”, of any file. You use this hash in a “reverse” fashion to see if your file is bit-perfect (i.e., does it still have the same hash that it had last month? last year?). (BTW, git uses SHA-1 for all of the data it tracks.) You can also use sha1sum as a crude substitute for diff, because two similar files with even just 1 different byte will have different hashes.
  • gcc/clang: Open source compilers for the C programming language — great if you want to learn to program in C and need a compiler. Since C will be around in the lifetime of everyone reading this post, I suggest you learn it. You can interface with Linux in a very, very tight way with C, which is very cool.
  • dd: Great utility whenever you want to move around bytes. Yes, this is a very generic statement, but that’s just how powerful (and useful!) dd can be. If you want to benchmark your new SSD, you can use dd to generate thousands of files filled with random bytes.
  • xxd/hexdump: Hex viewers! Vim uses xxd to turn itself into a hex editor.
  • cat: Short for concatenate. I.e., if you do “cat foo bar quux > ash”, all of the contents of foo, bar, and quux (their bytes) will be joined up into a single file, into ash. It comes in handy lots of times, whenver you’re using a shell.
  • dmesg: Kernel-level log messages (what the Kernel detected, did) for your browsing pleasure. Great for understanding your computer’s behavior at its lowest levels. Does Windows even have an equivalent???
  • iftop: Excellent network traffic viewer. It tells you which IP addresses you are downloading/uploading from. Great for troubleshooting LAN setups in your home.
  • htop: Like Windows’ famous “Task Manager”, but it actually tells you EVERY SINGLE running process, not just what you launched yourself.

Ugly Xmodmap Caps Lock Workaround

So, I decide to do a system upgrade (including all xorg packages) the other day and suddenly xmodmap isn’t working any more. Specifically, these lines in my .xinitrc no longer do the job (of making Caps lock my mod3 key (for use in Xmonad)):

xmodmap -e "remove Lock = Caps_Lock"
xmodmap -e "add mod3 = Caps_Lock"

So after tons of googling, I found this page: http://forums.gentoo.org/viewtopic-t-857625.html.

Basically, to get the same behavior back, I have to have

remove Lock = Caps_Lock
remove mod3 = Super_L
keysym Caps_Lock = Super_L
add mod3 = Super_L

in my (new) ~/.xmodmap file, and then do this in my ~/.xinitrc:

xmodmap -e "remove Lock = Caps_Lock"
xmodmap -e "add mod3 = Caps_Lock"
xmodmap ~/.xmodmap

This is a very, very ugly hack, but even after spending a solid hour trying manual xmodmap commands and this and that and all sorts of combinations, this is the only method that works.

I have no idea which package exactly broke xmodmap’s former 2-liner functionality, but it was sometime in the past couple months, probably. If the old 2-liner starts working again, I’ll let you all know…

Linux Dual Monitor Setup: Nvidia & Xinerama Guide: Rotating just one monitor

I have 2 LCD monitors (both are widescreen) hooked up to an Nvidia card in Linux. For a while, I rotated both of them into a “portrait” view, because, aside from the other benefits a portrait view can give (to webpages and documents), putting two widescreens on a landscape configuration takes up too much horizontal space.

But yesterday, I decided to take a hybrid approach and put my left monitor in landscape view, but my right one into portrait view — i.e., I only wanted one monitor rotated 90 degrees. Of course, this is fairly straightforward in Windows with the proprietary Nvidia utility, but it takes a little bit of work with Linux. I googled around a bit, and found this page. I couldn’t really understand what was going on by just looking at the sample xorg.conf file on that page, so I decided to write out my usual in-depth explanation on the matter.

First, to get this hybrid approach, you have to use Xinerama, and NOT Nvidia’s popular TwinView utility/configuration. This is because TwinView (in Linux) only allows you to rotate BOTH monitors together in the same direction.

The only thing you have to do is edit your /etc/X11/xorg.conf file. First, if you already have TwinView set up to work in a dual monitor configuration, you have to run sudo nvidia-settings, and then change from “TwinView” to “Separate X screen” under the “X Server Display Configuration” settings, like so:

2009-10-04-133053_914x657_scrot

The reason we do this (if you already have nvidia-settings installed) is because it auto-generates a working xorg.conf for us. The thing is, under TwinView, you just have 1 option for everything in Xorg — i.e., you just have Device0, Screen0, Monitor0, but now with the “Separate X screen”, you have Device1, Screen1, etc. Not only that, but your old, irrelevant TwinView settings will be automatically deleted or commented out, so it will save you a couple minutes of work (and any typos as well — typos will prevent X from booting!). After that, it’s just a matter of tweaking the xorg.conf file to suit your needs. (BTW, the reason why the right monitor looks like it’s not aligned vertically correctly with the one on the left is because of a manual adjustment — it’s the 333 pixel shift adjustment I made; read on below for more on that).

Here is my current, working xorg.conf with just 1 monitor rotated:

Section "ServerLayout"
Identifier     "Layout0"
#Screen      0  "Screen0" RightOf "Screen1" # put it on the RIGHT (other options are Below, Above, LeftOf, RightOf;
# alternatively, you can put an absolute, pixel X and Y offset (so RightOf
# would be 1680 0
Screen      0  "Screen0" 1680 0 # NOTE: Screen 0 MUST be defined BEFORE Screen 1!!!
Screen      1  "Screen1" 0 333 # put this screen on the top left, but adjust it down a little bit to match the portrait screen on the right
InputDevice    "Keyboard0" "CoreKeyboard"
InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "Module"
Load           "dbe"
Load           "extmod"
Load           "type1"
Load           "freetype"
Load           "glx"
EndSection

Section "ServerFlags"
Option         "AutoAddDevices" "False"
Option         "Xinerama" "1"
EndSection

Section "InputDevice"

# generated from default
Identifier     "Mouse0"
Driver         "mouse"
Option         "Protocol" "auto"
Option         "Device" "/dev/psaux"
Option         "Emulate3Buttons" "no"
#Option         "ZAxisMapping" "4 5" # for the Logitech MX 400
EndSection

Section "InputDevice"
Identifier     "Keyboard0"
Driver         "kbd"
Option         "XkbModel" "pc105"
Option         "XkbLayout" "us,fr,de"
Option         "XkbOptions" "grp:shifts_toggle"
EndSection

Section "Monitor"
Identifier     "Monitor0"
VendorName     "Unknown"
ModelName      "Acer X222W"
HorizSync       31.0 - 81.0
VertRefresh     56.0 - 75.0
Option         "DPMS"
Option         "Rotate" "Right" # for portrait mode
EndSection

Section "Monitor"
Identifier     "Monitor1"
VendorName     "Unknown"
ModelName      "Acer X222W"
HorizSync       31.0 - 81.0
VertRefresh     56.0 - 75.0
Option         "DPMS"
EndSection

Section "Device"
Identifier     "Device0"
Driver         "nvidia"
VendorName     "NVIDIA Corporation"
BoardName      "GeForce 8800 GTS"
Option         "RandRRotation" "on"
BusID          "PCI:1:0:0"
Screen          0 # i.e., the monitor on the RIGHT (physically)
EndSection

Section "Device"
Identifier     "Device1"
Driver         "nvidia"
VendorName     "NVIDIA Corporation"
BoardName      "GeForce 8800 GTS"
BusID          "PCI:1:0:0"
Screen          1 # the monitor on the LEFT (physically)
EndSection

Section "Screen"

Identifier     "Screen0"
Device         "Device0"
Monitor        "Monitor0"
DefaultDepth    24
Option         "metamodes" "DFP-0: 1680x1050 +0+0"
SubSection     "Display"
Depth       24
EndSubSection
EndSection

Section "Screen"
Identifier     "Screen1"
Device         "Device1"
Monitor        "Monitor1"
DefaultDepth    24
Option         "metamodes" "DFP-1: 1680x1050 +0+0"
SubSection     "Display"
Depth       24
EndSubSection
EndSection

Probably the most important options are the “Screen” options under the “ServerLayout” section — these define which monitor starts where, and the relationship between the two monitors. The “Screen” options are defined by a X-axis (horizontal) and Y-axis (vertical) offset — you can only use positive numbers, I think, and so this means that if a screen is defined as “0 0”, it is on the top left corner of the imaginary monitor “plane,” so to speak. I.e., increasing the X-axis offset moves your screen to the right, whereas increasing the Y-axis offset moves your screen down. For me, my left monitor is slightly adjusted down by 333 pixels, so that it matches up smoothly with my rotated monitor on my right (my setup, physically, looks like a sideways “T”). I’m not sure if the “RandRRotation” option is necessary — it probably is not — I’m too lazy to check after fiddling with my xorg.conf all day yesterday. The other options should be self-explanatory, along with the comments.

 

Here are some of the not-so-obvious details: for me, my “DFP-1” is my LEFT monitor and “DFP-0” is my RIGHT monitor. Apparently, the “primary display” is by default DFP-o (e.g., in Windows, the Nvidia utility detects DFP-o (my RIGHT monitor) as screen “1 of 2”, so I have to manually set DFP-1 (2 of 2) as my primary screen) — the only reason why I have it like this is because for some reason, my BIOS stuff shows up on DFP-1, and not the default “primary” DFP-0, and I’ve always liked my BIOS to show up on my LEFT screen by default — hence the reason why DFP-1 is on my left and DFP-0 is on my right. I hope that made sense. It probably didn’t, so here is a screenshot:

Each monitor has a resolution of 1680×1050, but now, my virtual desktop has a 2730×1680 resolution (1680 + 1050 = 2730). DFP-0 is physically rotated so that the bottom side sticks out to the far right — i.e., it’s rotated counter-clockwise 90 degrees — so that the clean, button-less bezel of its top area matches up nicely with the unrotated DFP-1. And so, we rotate “Right” under the “Monitor” section for Screen 0. This is probably the most sensible way for most people, since almost all monitors that do have buttons at all (to make an uneven, fatter bezel where the buttons are) have them at the bottom of the monitor.

Here are the advantages that you get with Xinerama in the above setup:

  • Moving the mouse from the right to the left is always continuous and seamless. This is even true when moving from the far edges of the portrait monitor into the widescreen one (see notes in screenshot). Finally, the virtual screen behaves EXACTLY like how the monitors look in the real world. (This behavior is available in Windows; however, there are two shortcomings that are not found in Xinerama: (1) when the mouse is on the top or bottom edge of the portrait monitor, your mouse becomes “stuck” and does not transition smoothly over to the widescreen monitor on the other side (see screenshot above); (2) even though you can adjust the monitors by simply dragging the icons around (which is very user-friendly, I must say), the adjustments are very course and you cannot adjust things down to the last pixel.)
  • Maximizing a window maximizes to the monitor’s area (i.e., the window maximizes up to either the landscape or portrait view), and not the big, virtual landscape of 2730×1680 pixels; even the applications behave intelligently!

A (temporary) disadvantage:

  • Since I’m using Xmonad as my window manager, popup dialog boxes automatically spawn to to the top-left of the virtual screen — i.e., if they’re small enough, they fit entirely into the unviewable area on the top edge. I have to manually flatten the image into the tiled area to see the contents of it. However, this is Xmonad’s fault, and there is probably a hack out there to fix this sort of thing. Even so, since I don’t really use GUI applications that have a lot of popup dialog boxes in the first place, this is a non-issue.

For a long time I thought that Xinerama was an ATI thing, but apparently, it works for Nvidia as well. The xorg.conf layout looks much nicer, and simpler with Xinerama, and is much more flexible with it (e.g., the 333 pixel shift). If you change the few lines in my xorg.conf above that deal with rotations, you could even do without TwinView as well and just use Xinerama for a basic dual-head setup without any rotated screens.

Minor Update, February 25, 2010: A comment in the screencap was incorrect. Thanks Bela!

(Belated) Update November 4, 2010: Removed obsolete bugs and workarounds (In short, commit 21ed660f30a3f96c787ab00a16499e0fb034b2ad was introduced in into the xserver code in the spring of 2010, and fixed this issue of left vs. right monitors b). Xorg 1.8.1.902 works perfectly fine with either monitor being rotated into portrait mode.

Update June 20, 2012: Nvidia driver version 302.17 has made some changes to how you describe which monitor to rotate. Here is my current Xorg file, called “10-dual-monitor-hybrid.conf” which lives under /etc/X11/xorg.conf.d:

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0 # NOTE: Screen 0 MUST be defined BEFORE Screen 1!!!
    Screen      1  "Screen1" 1050 295 # push this screen down (vertically) 295 pixels from the top to match the portrait monitor on the left
    Option         "Xinerama" "1" # dual-head won't work properly without this!
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Acer X222W"
    HorizSync       31.0 - 81.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "Acer X222W"
    HorizSync       31.0 - 81.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8800 GTS"
    BusID          "PCI:1:0:0"
    Screen          0 # i.e., the monitor on the LEFT (physically)
    Option "NoLogo" "1"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8800 GTS"
    BusID          "PCI:1:0:0"
    Screen          1 # the monitor on the RIGHT (physically)
    Option "NoLogo" "1"
EndSection

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "metamodes" "DFP-0: 1680x1050 +0+0 { Rotation=left }"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "metamodes" "DFP-1: 1680x1050 +0+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Notice that the screen rotation settings are now taken care of under the “metamodes” option in the “Screen” section of the monitor you want to rotate. The recent Xorg versions do not use the usual /etc/X11/xorg.conf file any more (it has been like that for many months).

Nvidia & Rotated Screen Partial Workaround

Currently, there is a bug in the latest Nvidia drivers for Linux. It is the bug described in the following threads:

I suffer from the same “border anomalies” because I too, use Xmonad and Nvidia drivers, with two rotated screens. I lived with the annoyance for a few months (I even emailed Nvidia a bug report), until, by accident, I discovered a partial workaround — for all urxvt terminal windows. Since I usually do all my important work in urxvt terminal windows anyway (only exceptions being firefox and maybe OOo Writer), it really is a lifesaver. The fix for urxvt windows is as follows: in your ~/.Xdefaults file, put in the following property for urxvt’s resources, like so:

urxvt*depth: 32

For some reason, this fixes the strange border behavior completely for all urxvt windows in Xmonad. I stumbled on this workaround when trying to make my urxvt windows transparent (which don’t work for me — probably because I use xwinwrap to play a screensaver permanently in the background).

BTW, I also use the option “urxvt*fading: 33” to make inactive windows fade out a bit, even though this setting is a bit buggy at the moment (probably as a result of the xwinwrap thing and also how Nvidia’s drivers are still messing things up in the first place). Still, the fading option is worth a try if you haven’t done so yet — it’s much faster to recognize active urxvt windows than from just using xmonad’s border’s alone (I use a 1-pixel wide white/black border in xmonad).

UPDATE November 11, 2009: Nvidia’s latest driver, 190.42, seems to have fixed this issue. Rotated screen + border issue has been resolved according to their changelog, and I have noticed the change myself in my desktop’s rotated monitor.

Use your /etc/hosts file to save time

I was installing Arch Linux on yet another machine (new laptop), and was pleasantly surprised by a little tidbit in the Arch Wiki pages — specifically the Beginner’s Guide (which is continually improved and updated fanatically by the Arch community). In short, you can alias host addresses in your /etc/hosts file. This can be for web addresses (www.google.com) or addresses on your LAN. Here is the example and explanation given by the wiki page:

“Tip: For convenience, you may also use /etc/hosts aliases for hosts on your network, and/or on the Web, e.g.:

64.233.169.103   www.google.com   g
192.168.1.90   media
192.168.1.88   data

The above example would allow you to access google simply by typing ‘g’ into your browser, and access to a media and data server on your network by name and without the need for typing out their respective IP addresses.”

Putting your hostname aliases in your /etc/hosts file is great, since all of your programs use it. Firefox, your terminal/shell, git, etc. They all reference this file. So if you’re using git, you can do git clone ssh://username@hostname-alias/… to clone a repo from your LAN, as I described in my post here, instead of ssh://username@192.168.0.2/…. So now all of your hosts on your LAN will be much easier to remember. Here’s my /etc/hosts file:

#
# /etc/hosts: static lookup table for host names
#
#<ip-address>    <hostname.domain.org>    <hostname>
127.0.0.1        aether.localdomain    aether
# aliases
192.168.0.20   exelion
192.168.0. 21 luxion.e
192.168.0.22   luxion.w
# End of file

I’ve aliased luxion.e to my laptop’s ethernet adapter, and luxion.w to its wireless adapter. After setting up your aliases in /etc/hosts, you should get in the habit of writing out your (sane) hostnames for all your LAN computers, instead of painfully writing out their numeric IP addresses. (And I’m sure you’d want to alias your hostnames even more with the advent of IPv6 — and its rather long IP address format.)

MPD – A Brief Guide

The Music Player Daemon, aka MPD, is a great little application to handle music on your linux computer. Until recently (when Linux really started to take off and gain popularity), MPD has been notoriously difficult to get to work properly. I decided to write this small intro to MPD after having used it for about 6 months. This is a little guide to it to get you started on using MPD as your music manager.

The World of MPD

First, what MPD is:

  • MPD keeps track of your music library. It does this by defining a music directory, to which you can easily add symlinks to all the various places where you store your music on your computer.
  • MPD tracks changes to your music library (any time an mp3 is removed, or a new album added, you simply update the MPD database file — which takes three or four seconds at most).
  • MPD can store playlists.
  • MPD can play songs, and output this information to various devices, such as your physical speakers (usually via your alsa sound drivers, but it can be any audio driver on your system), or even a http port for remote web listening (via icecast).

What MPD is NOT (what most people get confused about):

  • MPD cannot by itself determine: which songs are played and in what order. Nor does it come with any controls such as PAUSE, STOP, NEXT TRACK, etc. MPD, quite simply, can either: play a song, or do nothing while it is running. MPD’s behavior is controlled by clients, such as GMPC, Sonata, etc (my personal favorite is ncmpcpp).

The downside of this dichotomy between what MPD is and what it is not, is that you must install two applications to get the same functionality as any standard multimedia player like iTunes. However, there are many, many advantages of splitting up music-playing from music-controls. First, mpd will hardly crash and will be error-free due to its simple nature. Second, you gain the ability to access your large music collection from other computers in your home network without much fuss. This means that you can do things like: make your laptop act as a remote control for your desktop’s music output (the desktop’s speakers), or even create multiple MPD instances for specific purposes simultaneously (e.g., alsa and also icecast output).

Typical Setup

For most people, they only need one instance of MPD running and have it configured so that it plays songs directly to their computer speakers. So their MPD configuration file will look something like this (comment lines removed to save space):

music_directory "/home/shinobu/.mpd-untracked/music"
playlist_directory "/home/shinobu/.mpd-untracked/playlist"
db_file "/home/shinobu/.mpd-untracked/mpd.db"
log_file "/home/shinobu/.mpd-untracked/mpd.log"
pid_file "/home/shinobu/.mpd-untracked/mpd.pid"
state_file "/home/shinobu/.mpd-untracked/mpdstate"
sticker_file "/home/shinobu/.mpd-untracked/sticker.sql"
user "shinobu"
bind_to_address		"192.168.0.110" # bind it to this computer's IP address if someone on the LAN wants to use this mpd
port				"6600"
save_absolute_paths_in_playlists "yes"
follow_outside_symlinks "yes"
follow_inside_symlinks "yes"
audio_output {
    type			"alsa"
    name			"Exelion ALSA output"
    format			"44100:16:2"	# optional
    mixer_device	"default"
    mixer_control	"PCM"
}
replaygain			"track"
volume_normalization "yes"
filesystem_charset		"UTF-8"
id3v1_encoding			"ISO-8859-1"

It’s very straightforward. All of the essential files and folders are customized and defined in the config file. (My mpd directory is .mpd-untracked, since these files/folders are not tracked by my git folder containing all of my dotfiles. See my previous two posts for more info on that setup.) The config file itself resides at /home/shinobu/syscfg/mpd/cfg-alsa — a customized path and filename, which is referenced each time MPD starts on bootup (in my .xinitrc file), with the command “mpd /home/shinobu/syscfg/mpd/cfg-alsa”. MPD will daemonize itself when it is called, so calling it from your .xinitrc file without the “&” argument at the end of the line is OK. Notice how the above configuration avoids running into permission problems, since everything resides under a normal user’s directory.

I then start up ncmpcpp, which by default looks to the mpd host as localhost and port as 6600 — matching the (default) values in my MPD config file above. And it all works rather beautifully.

Multi-MPD Setup for Music Sharing

Back when I still used iTunes (about 3 years ago), I remember it had this neat feature to share your music with anyone on your local network. You can do the same thing with MPD. The trick is to add a separate MPD instance for this feature. I myself have this multi-MPD setup on my desktop, with one MPD for alsa-only output (as seen above), and a second MPD for icecast-only output. Icecast, by the way, is a more general solution not wholly related to MPD for sharing music over the internet — we can use icecast since it plays rather well with MPD (UNIX philosophy FTW!). Since my desktop has a second MPD instance so that it works with icecast, my laptop can now take advantage of the huge music collection that I have on it, remotely (well, as long as I’m on the home network in my case).

Here’s my MPD config file for icecast output:

music_directory "/home/shinobu/.mpd-untracked/music"
playlist_directory "/home/shinobu/.mpd-untracked/playlist"
db_file "/home/shinobu/.mpd-untracked/mpd.db"
log_file "/home/shinobu/.mpd-untracked/mpd-icecast.log"
pid_file "/home/shinobu/.mpd-untracked/mpd-icecast.pid"
state_file "/home/shinobu/.mpd-untracked/mpdstate-icecast"
sticker_file "/home/shinobu/.mpd-untracked/sticker.sql"
user "shinobu"
bind_to_address		"192.168.0.110" # bind it to this computer's IP address if someone on the LAN wants to use this mpd
port				"6601"
save_absolute_paths_in_playlists "yes"
follow_outside_symlinks "yes"
follow_inside_symlinks "yes"
audio_output {
    type			"shout"
    name			"exelion HD mpd stream"
    encoding		"ogg"			# optional
    host			"localhost"
    port			"8000"
    mount			"/mpd.ogg" # i.e., "http://192.168.0.110/mpd.ogg" is the live stream
                                           # (provided that MPD is actually playing a song)
#--------------------------------------------------------------------------------------------------#
# See 'source password' in /etc/icecast.xml for password                                           #
#--------------------------------------------------------------------------------------------------#
    password		"hackme"
#--------------------------------------------------------------------------------------------------#
# Use 'bitrate' or 'quality'. Use 'bitrate' for static bitrate, or 'quality' for variable.         #
# Use one or the other -- not both!                                                                #
# bitrate                     "128"                                                                #
#--------------------------------------------------------------------------------------------------#
    quality			"10"
#--------------------------------------------------------------------------------------------------#
# 'format' is the audio format of the stream. The first number is the sample rate in Hertz (Hz);   #
# 44100 Hz is equal to cd quality. The second number is the number of bits per sample; again 16    #
# bits is the quality used on cd's. The third number is the number of channels; 1 channel is       #
# mono, 2 channels is stereo.                                                                      #
#--------------------------------------------------------------------------------------------------#
    format			"44100:16:2"
    protocol		"icecast2"		# optional
    user			"source"		# optional
    #description		"My Stream Description"	# optional
    #genre			"jazz"			# optional
    #public			"no"			# optional
    #timeout			"2"			# optional
}
replaygain			"track"
volume_normalization "yes"
filesystem_charset		"UTF-8"
id3v1_encoding			"ISO-8859-1"

As you can see, much of the configuration is exactly the same as my first MPD config file. You’d want it like this, since you’d want it to use the same music collection and list of playlists. (Well, if you had a private stash of music you didn’t want anyone in your LAN to know about, you’d point to a different music folder.) So the music directory, playlist directory, and database file are all the same. However, you’d want a different set of logfiles for this second MPD instance, so those values are changed. The same goes to the pid and state files. The port number is 6601, so that it doesn’t conflict with my first MPD. The final difference is the audio output, which is set to “shout” and not “alsa”. The “shout” output works with icecast, and the values in here, like port 8000 and “hackme” as the password, are taken straight from the default icecast intallation’s xml file (/etc/icecast.xml — of course, you can call icecast with a different config file location than the default one).

It’s important that you make this second MPD output solely to icecast. If you put in alsa output here, you’ll end up with two different songs playing simultaneously on your desktop’s speakers! (Aside: MPD is perfectly capable of outputting to multiple audio outputs, so you could, if you wanted, make one MPD instance output to both alsa and icecast — suitable if you’re the only one at home and you want your music to “follow” you to all the computers connected to the LAN.) As for icecast itself, you can also call it from your .xinitrc file, after your mpd-calling lines, like so: icecast -b -c /home/shinobu/syscfg/icecast/cfg.xml. The -b flag daemonizes icecast (required since you’re calling it from your .xinitrc file), and the -c flag merely points to the correct config file location. My icecast config file looks like this:

<icecast>
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65535</burst-size>
    </limits>

    <authentication>
        <source-password>hackme(~</source-password>
        <relay-password>hackme(~</relay-password>
        <admin-user>admin</admin-user>
        <admin-password>hackme(~</admin-password>
    </authentication>
    <hostname>localhost</hostname>
    <listen-socket>
        <port>8000</port>
    </listen-socket>
    <fileserve>1</fileserve>

    <paths>
        <basedir>/usr/share/icecast</basedir>
             <logdir>/home/shinobu/.icecast-untracked/log</logdir>
             <webroot>/home/shinobu/.icecast-untracked/icecast/web</webroot>
             <adminroot>/home/shinobu/.icecast-untracked/icecast/admin</adminroot>
        <alias source="/" dest="/status.xsl"/>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
      	<loglevel>1</loglevel>
      	<logsize>10000</logsize>
    </logging>
    <security>
        <chroot>0</chroot>
    </security>
</icecast>

Here, the value for the <source-password> tag must match the password specified in your icecast-MPD’s config file. I’ve left it to the default “hackme” here for demonstration purposes — you should change it to something more secure (better safe than sorry!). My password is like @#$k23lsdf9. Make sure the directory in <logdir> exists. As for the <webroot> and <adminroot> directories, copy them straight out of /usr/share/icecast/web and /usr/share/icecast/admin, and place them into your custom location. This will take care of those annoying permission errors that users often face.

Now, on your remote computer, such as your laptop, you need (1) an MPD client, and (2) a music player, like mplayer, to intercept the raw .ogg music stream from your desktop with the icecast-MPD setup. In my ncmpcpp config file on my laptop, I have custom values for the mpd_host and mpd_port fields to be my desktop’s IP address 192.168.0.110 and 6601, respectively (matching the values in the second MPD config file above). So when I fire up ncmpcpp on my laptop, it connects over the LAN network into the music collection residing in my desktop, all with the magic of MPD. Once I activate the ogg stream by playing a file, I can then access this stream with mplayer — specifically, with mplayer -ao alsa -softvol -volume 10 -volstep 1 -prefer-ipv4 http://192.168.0.110:8000/mpd.ogg. I have this long command aliased, of course, to a hotkey in my XMonad configuration file. And within a couple seconds, I get a top-quality, ~500 kbps ogg stream right on my laptop (the quality setting in my MPD config file, set to “10”, is the maximum quality supported by the ogg format; 500 kbps, or a little over 60 KBps, should be nothing on your home ethernet LAN).

So here’s what’s happening with this second MPD instance on my desktop, configured with icecast output: MPD keeps tabs on what my music collection consists of from port 6601, and “plays” to port 8000 — converting my current mp3/flac file into an ogg stream, which is then served by icecast. From my laptop, I then connect to this MPD by the desktop’s IP address and MPD port of 6601 with ncmpcpp. Then, once I tell MPD to start playing, I can then access the ogg stream with mplayer on my laptop. Mplayer simply looks to http://192.168.0.110:8000/mpd.ogg. When icecast on my desktop receives this request from my laptop’s mplayer, it gives the go-ahead and essentially acts as a bridge between my desktop’s icecast-output MPD and my laptop’s mplayer. Mplayer then takes this ogg stream, and outputs it onto my laptop’s speakers using the alsa drivers.

Here’s a picture to describe what’s going on. (The latest LibreOffice Drawing app is really a pleasure to use!)

So I hope this post proves useful to people who are new to Linux and are struggling to get MPD (and especially with Icecast) to work.

EDIT July 17, 2010: Prettier/simpler graphic uploaded.

UPDATE April 7, 2011: Cleaner source code format; fixed some typos; updated graphic.

UPDATE November 1, 2011: Grammar fixes and some rewordings. I’m delighted to say that even after 2 years of using MPD, I still use the setup described in this post. Talk about configuration stability!