Spoiled rotten
I have two monitors at home, connected to my box for hacking. A nice 22″ Eizo with 1280×1024 resolution and an even nicer 24″ Eizo with 1920×1200. I’ve used them for a long time back in Germany and when I finally got around to set them up, I well…
… well, I was disappointed. They seemed… …small. 3,7 million pixels seem small. Why is that?
Because when I started the new job, I got two 30″ 2560×1920 monitors. And I got used to almost 10 million pixels of screen real estate in just a few days.
My very first “real” computer had a whooping 64k pixels (320×200 on the C64). I now have more than 150 times the screen space I had back then. And I could still use “a little more”.
monitor netstuff screenspaceCentOS 5.2 on a D945GCLF2
Everyone goes green these days and with the new Intel Atom 330 processor, it seems there is a perfect choice for a little home server box that sits in a corner, serves files and music and does all the little chores that keep a home network running.
So I got one of these buggers from Newegg, together with a small case and installed it. Various reviewers stressed that the R8168 chip on the board is not supported out of the box by CentOS 5.2 but there is an open source driver for download from Realtek so that does not matter.
However, this box was not intended to come with a DVD drive. And installing from the net without working network card is not that simple.
Possible solutions
- Get a DVD drive, burn a CentOS 5.2 install image, install from disk. Bring the driver onto the box by using a thumb drive.
- Buy a $10 el cheapo network card (the board has a PCI slot), use it for installing.
- Understand the problem, fix it. Install from the network.
You guessed right. I am a stickler for details, so naturally I chose 3.
The solution is actually pretty easy: Get a driver disk for CentOS 5.2, boot an install media using “linux dd”, insert the driver disk. The Anaconda installer picks up the driver from the driver disk and goodness ensures.
However, after an hour of goggling, it seems that either no one has ever done this successfully before or at least not bragg^Wblogged about it.
The facts are these:
Building a driver disk is one of the best kept secrets in the Linux world. The required toolset is called “ddiskit-0.9.9″ and kept in the depths of the RedHat web site.
And, to put insult to injury to the Linux hacker community: It took a Java weenie such as me about an hour to put a working driver disk together. Which I used to install from the net.
Once, you have the installation going, you will need to reinstall the driver every time you do a kernel upgrade. Luckily, there is a package of scripts called “dkms” available from EPEL and Dag Wieers built a package for the r8168 driver, which I update to the latest version of the driver available. This package automatically updates the driver whenever you install a new kernel.
And, to avoid that elite Linux kernel hackers have to do this all again and again, get it here:
* Linux driver disk for i386 CentOS 5.2 (kernel 2.6.18-92.el5)
* Linux driver ISO image i386 CentOS 5.2 (kernel 2.6.18-92.el5); if you want to use a thumb drive, loopback mount this image and copy all files onto the drive.
* R8168 driver disk kit
* Updated dkms-r8168 package for CentOS 5.2, use with dkms from EPEL (Source).
@ImplementedBy madness
Consider a codebase of considerable size, thus being open-source.
This codebase uses Google Guice to wire its innards together. Last time I looked, it had a central FoobarGuiceModule which listed all of the classes wired together. When I integrated that codebase into $DAYJOB, I wrote a DayjobGuiceModule to manage the things different for me. No biggie. I knew where to look, in a single place.
Three months later, the FoobarGuiceModule is all but gone. Instead, the authors decided to sprinkle the most unfortunate decision ever made by the Guice authors (maybe this is where the nickname comes from) over the code: @ImplementedBy.
Instead of one (or maybe a few, when the code is not monolithic, let’s say three) place where the configuration is centralized, it is now spread out over 32 (!) (that is thirty-two) different interfaces which all happily tell you that they are implemented by someone else. Including a few that chirp out that they are implemented by demo-code that you want to override lest you will not be able to integrate the code into your own stuff.
Oh, and you must follow the project from SVN. It has no release yet (even though it is almost a year now in open source).
Maintenance nightmare. If you have a different opinion, let me know. I would be happy to hear a good justification for @ImplementedBy. Or, in the words of Bob Lee:
“@ImplementedBy is an experts only feature; it’s not for everybody. You have to weigh the benefits and consequences in context. @ImplementedBy may not be as robust as a completely separate interface, but it is more concise, and it’s better than depending directly on a concrete class. If you’re only using an interface to simplify unit testing, @ImplementedBy is a perfectly pragmatic compromise.”
pulse-audio and vmware-player - get sound going on Fedora
vmware is a PITA concerning sound. However, it is possible to get it to run with pulse-audio. This is how it works:
- Get the current vmplayer from vmware.com. It is free and it comes in a 32 and a 64 bit version now. I used vmplayer 2.5 (64 bit version) on Fedora 8.
- Get the VMWare DSP preload library called vmwaredsp-1.3. You might have some trouble finding it on the web because many Google links point to an outdated location. Its current home seems to be http://platan.vc.cvut.cz/ftp/pub/vmware/.
- Compile it. If you use the 64 Bit version, you might need some tweaking for the compiler names and it has trouble finding the arts sources. Match the Makefile in the 64 directory to the one in the 32 directory and you should be fine.
- There should be three libraries in either /usr/lib (32 bit) or /usr/lib64 (64 bit).
- Go to the vmplayer install directory. In my case, this is /usr/lib/vmware/bin/
- open the launcher.sh in an editor and look for the line “$binary” “$@”.
Replace it with
if [ `basename $binary` = “vmplayer” ]; then
LD_PRELOAD=libvmdsp.so VMDSP_BACKEND=esd “$binary” “$@”
else
“$binary” “$@”
fi - You are done.
To verify operation, open the pulse-audio volume control and select the playback tab. Whenever a sound is played in your virtual machine, there should a playback stream pop up.
Lessons learned today
- When driving a convertible, don’t ignore a thunderstorm on the horizon.
- USVs are useful. Especially during a thunderstorm.