Wage Gaps
John Bogle, founder of Vanguard, says:
Think about this, and these numbers are in the battle for the soul of capitalism. The real income of the average worker in America has gone, from 1980 to 2004, from $14,900 to $15,900, OK? Well the real compensation of the CEO has gone from [approximately] $400,000 to $6 million, many times over. The CEO is making a statement and it is, "I built this company by myself and all the people that work here didn't help at all. They are entitled to nothing." Well, that is absurd. I have been a CEO for probably 35 of my years, 55 years in this business, an awful lot of them. I know it not to be true.
Really makes you think about the rich/poor gap and the erosion of the middle class.
Xfce 4.4.0 Released!
This is just a copy and paste of my /. story submission, but whatever:
After more than two years since our previous stable feature release, the Xfce Team is proud to announce the release of Xfce 4.4.0. This release features our new file manager, Thunar, as well as many improvements and feature additions to Xfce's core components.
Head over to our brand-new website and take a look at our visual tour, or go straight to the downloads.
Xfce 4.4.0 Released!
This is just a copy and paste of my /. story submission, but whatever:
After more than two years since our previous stable feature release, the Xfce Team is proud to announce the release of Xfce 4.4.0. This release features our new file manager, Thunar, as well as many improvements and feature additions to Xfce’s core components.
Head over to our brand-new website and take a look at our visual tour, or go straight to the downloads.
Digital cameras, libusb, permissions, hal, and other annoyances
At some point in the near past, I stopped being able to access my Canon PowerShot S30 (yeah, it's an old non-PTP camera) as any user other than root. I poked around at the hotplug rules, and everything seemed ok. The device file in /proc/bus/usb was getting correct permissions, but still no good. I even tried setting permissions to rwxrwxrwx, and changing ownership to brian:brian, but still no luck.
So I googled, and googled, and googled. After reading through about 25 Gentoo forum posts, I came upon one thread with a post (at the bottom of page 1) that suggested something different: export USB_DEVFS_PATH=/proc/bus/usb. I thought that seemed somewhat redundant, but tried it anyway, and it worked. So, I thought, if /proc/bus/usb is no longer the default, what is? So I unset the env var, and ran gphoto2 through strace. I saw a bunch of attempts to open files in /dev/bus/usb. Wait... /dev? Sure enough, the device files in /proc/bus/usb are now duplicated as character devices in /dev/bus/usb, and of course the permissions weren't set properly there.
So I grepped through /etc/udev/rules.d for anything related to usb, and found the rule that was creating the entries in /dev/bus/usb. I modified it to set some of the stuff to 0664, with group plugdev owning (this group is specific to Gentoo). The final line, which goes in /etc/udev/rules.d/10-local.rules, looks like this:
SUBSYSTEM=="usb_device", DRIVER!="usbhid", DRIVER!="hub", DRIVER!="hci_usb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.} $${K#.}'", NAME="%c", GROUP="plugdev", MODE="0664"
The "DRIVER!=" bits are so it doesn't set the group and permissions on things like my mouse, keyboard, the USB hub itself, and Bluetooth. Since those "DRIVER!=" bits make that particular rule not match, udev will continue on until it hits the default rule in 50-udev.rules which will set it up for those devices.
Whew. Unplug the camera, plug it back in, and now gphoto2 works as my normal user.
Next I thought it would be cool if Benny's new Thunar volume manager would launch gtkam when I plug in the camera. So I enabled the option in the volume manager to launch something on camera connection, typed "gtkam" in the box, and plugged my camera in. Nothing. sigh
So, I know all of this uses HAL, so I opened up hal-device-manager to have a look. I found my camera in the tree, and, of course, there aren't any property strings in the device nodes that actually identify it as a camera. Great. Clearly, thunar-volman isn't going to know it's a camera if HAL doesn't identify it as such. But, I remembered a page out of the gphoto2 documentation that mentioned something about HAL. As it turns out, HAL ships with a .fdi file that identifies all PTP-type cameras properly (apparently they share common system, subsystem, class, etc. ids), but doesn't identify any older cameras such as mine. Fortunately, it told me what to do. First, run /usr/lib/libgphoto2/print-camera-list hal-fdi >90-camera-libgphoto2.fdi to generate a .fdi file. Then, move it to /usr/share/hal/fdi/information/90local/. Sweet. I unplug and replug my camera, and thunar-volman starts up gtkam. Finally.
Meh. So why was this so difficult? How come no one noticed that libusb changed its default device path to stuff under /dev/ instead of /proc/? I know this hasn't been working for months and months.
Anyway, it's done, and instead of going to bed more or less right when I got home, it's now 2am. Brilliant.
(On a side note, yeah, I know I haven't posted much in the past month. For those brave few of you who care, I'll get back to that soon.)
Xfce goodness
I added my new Xfce Configuration Guide to our documentation repository tonight. I hope it'll get some of you to try out the wonderful creamy goodness that is Xfce. 
http://www.gentoo.org/doc/en/xfce-config.xml
* It might take an hour or two to show up; the mirrors have to finish syncing first.
Xfce goodness
I added my new Xfce Configuration Guide to our documentation repository tonight. I hope it'll get some of you to try out the wonderful creamy goodness that is Xfce. 
http://www.gentoo.org/doc/en/xfce-config.xml
* It might take an hour or two to show up; the mirrors have to finish syncing first.
A new year means new things
...And part of those new things include:
Time for a status update from my last post!
I finished editing flameeyes' autoepatch documents, just before he sent in his retirement announcement (it's still a ways off, though), and before all his troubles with the stupid BSD-4 licence.
Added random bits and fixes to several docs, including a blurb about branding to the Gnome Guide, prompted this forum topic.
Only the first few items on my TODO list have changed from my previous post:
1) VDR guide updates and autoepatch: Done. Massively overhauled the provided patch (Englishification!), and finished Diego's stuff thus far.
2) Other assigned bugs: Much more progress. I got vivo to send in some patches for some ancient mysql docs bugs just before his retirement, so I closed those old bugs. Love closing old bugs! I've thought of a few more things to do on the pcmciautils migration guide, so I'll get those in and email brix for feedback.
3) Ebuilds: Got some help from Diego on this in exchange for the autoepatch docs. 
Some progress.
5) SwifT's alternative handbook: added some more tidbits. Ended up using some material I recently added for...
X) Forgot to add this to the last post, but one thing I suddenly decided to do a few days ago was write an Xfce Guide similar to the Gnome/KDE/Fluxbox guides already available. Something randomly clicked in my mind: we've a huge hole in the docs! I love and use Xfce (4.4-rc2, even) on my laptop! I should write something! Originally I'd meant to have it done over the next few months, to coincide with an upstream release, but...
So it took me all day today (since I was sidetracked for a good 7 hours), but I finally cranked out an Xfce Configuration Guide. It's the first all-new standalone guide I've written in awhile. It's much longer than what you'd expect for a guide on a lightweight desktop, because my approach was threefold.
First, I wanted to show how to install & configure a basic, minimal Xfce, and second, I wanted to show how to go beyond that and create a powerful, full-featured desktop environment that still adheres to the Xfce principles: fast, lightweight, configurable, and modular. Finally, I wanted to write a forward-thinking guide. Xfce-4.4 will hit final release sometime in the coming few months, and eventually the stable Portage tree. Therefore, I tried to write it in a way that's immediately accessible and practical to those who will be installing 4.2 (currently stable), as well as requiring minimal rewriting once 4.4 and all its huge changes hit Portage. To that end, I think I've succeeded. I'm hoping that this will be a real resource to all the folks that come to the forums asking "which one?" and "what should I run on this old hardware?"
I did quite a bit of research these subjects, examining not only the applications used on my (quite underpowered) old laptop, but also what the forumites were suggesting. Alas, many of the threads were quite old (2005), and most packages were no longer available -- a good example would be any gtk-1 apps, such as webbrowsers and email clients -- or too heavyweight to warrant consideration. Firefox and firefox-bin are the heaviest packages by far recommended in the guide, and even they run nicely on 128MB memory, a slow hard disk, and abysmal system I/O.
On a final note, my ISP has been completely sucking tonight. Internet availability has been terribly spotty. It's making it impossible to shop online for a headset for Skype. I got my first taste of Skype a few days ago, though it was only listening in to a few of my fellow devs; I had to use IRC to talk. That was pretty cumbersome, but now I feel the pull of Skype...must use it! It's so much more fun to hang out with the guys in #-dev via VoIP.
Back in Cali… Sorta
After a minor ordeal of a travel day, I'm back in Cali, kinda. I'm heading out to Las Vegas to go to CES Saturday morning.
I surprisingly had a great time being back home. There ended up being plenty to do, I met some new people, and saw a few people I haven't seen in a very long time.
I need to pack, and get some sleep. Aside from some minor dozing on the plane, I've been up for 25 hours, with only a 1.5-hour nap before that. No good.
Linux and Wireless Config
Configuring wireless on Linux is a pain. Gentoo doesn't make the situation any easier: there's a text file in /etc/conf.d that needs to be edited to include your SSID, keys, options, etc., and if you're using WPA/WPA2, you need to mess with /etc/wpa_supplicant/wpa_supplicant.conf as well. If I want to change networks (say, when I visit my dad's house), I have to edit these files and restart the interface.
There's NetworkManager. It looks really cool. Unfortunately, it doesn't work on my PowerBook. It never scans for wireless networks (though it appears to detect my wireless interface ok), and its logging output isn't too useful. To be fair, I haven't had the time to look into it too deeply (after spending hours and hours getting it to build properly, I didn't have much patience for runtime issues), and I'm aware that the Gentoo 'backend' isn't one of the more mature ones. Also: it's ridiculously over-engineered. I do understand all the various cool things you can do with it because of how it's designed and integrated into the desktop, but all of that stuff isn't useful for my general usage.
Oh, and I still can't get NetworkManager to compile without gnome-panel present, which really pisses me off. It doesn't even build a GNOME panel applet, as far as I can tell. Regardless, I use Xfce, as we all should know by now. I've tried to keep the number of extraneous useless libraries and apps installed on my laptop to a minimum, so I don't really want to install most of GNOME just for a network control applet in my systray.
(I'd just like to point out that I think NetworkManager is a great piece of software. It obviously does work very well for some people. Just because it doesn't work for me, or doesn't meet my needs quite as well as I'd like, that doesn't mean I think it's crap. It most definitely isn't.)
I was thinking about what I care about for a wireless network manager. I realised that I don't need/want it to manage my wired ethernet interface. (That's a separate project: just a simple daemon, probably written in bash or perl, that configures/un-configures the interface when a cable is plugged in or removed.) For wireless, I'm thinking about the MacOS X model here. You get a little menu in the menu bar that lets you turn wireless on and off, pick networks, enter security info, and (I think, don't have the Mac in front of me right now) open up the networking settings panel. That's really all I need as well. I don't need fancy system services (I'll count on Gentoo's startup script to try to connect to my default already-defined networks on startup), I don't need it to take care of my ethernet interface, I don't need it integrated into my desktop so all my apps can know whether or not I have a network connection, I don't need a D-Bus service, and I don't need some weirdo 'dhcdbd' thing (I still have no idea what this does or why NetworkManager needs it, and I don't particularly care).
So, I think I'm going to blatantly rip off the Mac and write a little system tray icon (yes, I know, abuse of the systray; sue me) to handle my wireless connections. I was looking at wpa_supplicant, and it appears that it's freakin' awesome. You can use it for connections to unsecured, WEPed, and WPAed networks (among a bunch of other things most people aren't likely to have in their home), and it has a command-line tool to control a running instance of it (wpa_cli), which can add/remove networks, set parameters, force it to reassociate, etc. So I'm thinking I'll just require wpa_supplicant, and do network management through that. There are two things that require root access: 1) bringing the interface up and down, and 2) writing out a new wpa_supplicant.conf file so the system boot scripts can take advantage of any changes (this is optional). We don't need root for wpa_supplicant control, because it can be configured to allow normal users to control it based on their group membership (though on my laptop, the permissions on the control socket were messed up when I first tried it).
Bringing the interface up and down is annoying, since it's a very tiny (yet critical) action, and I need to pay attention to a bunch of security-related issues. One option is to use gksu or some other GUI method of prompting for the password. I like this from a development perspective, as it requires very little work on my part. It's a pain from the user's perspective, though, as I don't feel that a logged-in user should have to enter his/her password every time they want to turn wireless on or off. A lazy option is just to require the user to set up 'sudo' to let them run ifconfig with root privs with no password, but I don't really like that either. I think I'll end up writing a setuid helper app that validates the logged-in user in some other way (perhaps using pam_console).
I'm going to attempt to do it without depending on any Xfce libraries (though I might pull in libexo for the session client and a couple other things). I'd like to create a general-purpose desktop-neutral app here. It's certainly not going to cater to everyone, and probably won't work on all distros without some manual fudging. I just don't have the time or desire to spend that much time on it (yet), and I'll have to rely on contributors to submit patches for their setup of choice, if they care to do so.
Otherwise, it's not that hard. I'll store wireless config in my own format in the user's homedir. There can be an option to write out a system-wide wpa_supplicant.conf file to sync changes with the system so the interface can come up on boot with some default setup. All that's left is a lot of text output parsing (from wpa_cli, which hopefully doesn't change output formats between versions), and good CLI/GUI integration when setting wireless parameters and presenting feedback to the user. Since I'll be in MD for 2.5 weeks, I'll give it a shot, as I don't really have all that much planned while I'm at home.
(I think I'm going to name it 'airconfig'; when I make a website for it, it'll likely be here. If anyone has any thoughts for a more creative name, feel free to leave a comment.)
xfce eyecandy
All right, I finally did it. I went for the eyecandy. I've never set up any thing having to do with composite, transparency, etc., but I figured that since as long as I'm living on the p.masked Xfce edge anyway, I might as well use its built-in compositor. And...it's interesting. I don't particularly like how the panel automatically gets translucent whenever the mouse isn't on it, and it's actually distracting when I have a terminal superimposed on both Firefox and another terminal...I was surprised that the backgrounded Firefox itself becomes clear enough to see the other terminal underneath it.
And yet people dig this stuff? Or maybe they just dig the effects of more nifty compositing window managers like compiz. Anyway, I don't know if I'll stick with it or not. I'm pleased to say that after a little tweaking, it's a minimal resource hit even for my ancient integrated nVidia GeForce2 Go chip. (One of the very first dedicated mobile GPUs, a whole 16MB memory.)
Interestingly, I seem to be running only semi-hardware-accelerated, as I call it. running "glxinfo" gives a segfault, as it can't find the GLX extension to load, despite the visual results. Problem is, I can't enable "AllowGLXWithComposite", as that results in random hard lockups, which is the fault of being forced to use nvidia-legacy-drivers. These older 7xxx drivers are known to have such bugs, but the newer 8xxx drivers don't support my vintage 2001 hardware. Ah, well. At least adding "RenderAccel" to xorg.conf lets me run this stuff with very little noticeable slowdown. I suspect that I am getting hardware accel; it's just confused.
I think I'll bring along this composited laptop to SCALE and show off the wonders of unstable Xfce and the latest eyecandy. Which reminds me, now I need to see about getting all the effects of compiz, but without using that WM or unmerging yet more masked packages. I want to see what else this old graphics hardware is capable of.