gridengine qmon font problems

Even after you get gridengine installed, you’ll have some lovely font problems when using qmon. After trying a few things, the easiest is just to follow the advice at this web page and set the fonts to fixed. Note that copying $SGE_ROOT/qmon/Qmon to $HOME is an important part — updating the file directly won’t work. This should be done on the system with the qmon binary (should be obvious, but you never know).

If you decide to try and fix the fonts themselves, remember that the fonts need to exist on the Xserver rendering the qmon dialog, not necessarily the one on the system where qmon is being run from. In other words, if you’re doing X11 forwarding from a remote host to your desktop, it’s your desktop’s X11 server that needs the fonts, not the fonts on the remote host. Thanks to this post clarifying that pesky detail.

And finally, if you decide to poke around and get non-fixed fonts working, you’ll probably need these RHEL packages (via):

  • xorg-x11-font-utils
  • xorg-x11-fonts-100dpi
  • xorg-x11-fonts-75dpi
  • xorg-x11-fonts-misc

and possibly futzing with xfs and fc-cache. I tried this approach and fixed the initial error messages from the X server (yay!) but resulted in boxes instead of glyphs (boo) and failed back to fixed fonts.

gridengine RPM for RHEL5 (and CentOS 5) is broken…

…and here’s how you fix it.

After installing gridengine, before running install_sge (or install_qmaster / install_execd):

  1. edit /usr/share/gridengine/util/install_modules/install_common.sh
  2. find the CreateGSEStartUpScripts() function and nuke the entire contents of the “if [ $create = true]; then” up until (but not including) the “if [ $euid = 0 …]” line.
  3. save and exit the file
  4. edit /usr/share/gridengine/util/install_modules/install_qmaster.sh
  5. find the StartQmaster() function and change the ‘$SGE_STARTUP_FILE -qmaster’ line to read ‘/etc/init.d/sgemaster’ and remove the remaining contents of the function up until (but not including) the ‘$INFOTEXT …’ line
  6. save and exit the file

Now you can run the appropriate installation program.

The problem is that the RHEL5 packaging tries to remove the gridengine startup scripts and replaces them with its own startup scripts. Sadly the job wasn’t well done (and obviously wasn’t tested). I’ve notified the package maintainers but this will get you going until the package has been fixed (given that the package has existed in this form since 2008, I’m guessing it isn’t that popular of a package as-is).

Introducing Seregil, my new MacBook Pro

Yesterday I received my new 15″ MacBook Pro from FedEx and I’m sure I’ll be spending the next several evenings getting it all set up. I’ve christened it Seregil from the character of Lynn Flewelling’s Nightrunner series. (I always name my computers from characters in books — usually those I’m reading or have read recently.) It is spec’d out thusly:

  • MacBook Pro
  • 15″ high-density anti-glare screen
  • i5 2.4GHz CPU
  • 8GB RAM
  • 128GB SSD

For the past 4 years I’ve used Linux systems exclusively and when it came to purchase a new computer I decided to jump to Mac. Moving to Linux from Windows was the most productivity-enhancing change I’ve ever made and I’m hoping the swap to Mac doesn’t set me back. What appeals to me so much about Macs is that they have the classic unix underpinnings with an elegant GUI.

Currently I have a Windows VM which I use solely to put music on my iPhone. That’s going straight to /dev/null. Instead I’ll be creating a Fedora 13 (14?) VM as a backup for those things that just need a Linux touch to them. For instance, I’m going to give Apple Mail a chance, but if it just doesn’t pan out, I’ll run Evolution on the VM using VMware Fusion with Unity. I’m interested to see if The Gimp, Inkscape, and other X-Windows dependent apps behave better running in the VM rather than directly on the OS X X-server. While they function well, they just aren’t really integrated into the OS X UI.

I already have Adium, Unison, Moneydance, LibreOffice (aka: OpenOffice), and Chrome installed and configured. My iPhone library is moved over and correctly synching with my phone thanks to a bit of work getting the Library IDs sync’d between the two. Now to get VMware Fusion installed and that Linux VM created.

Fedora 13: taking the plunge on the laptop

Fedora 13 was released yesterday and I’ve decided to take the plunge on the laptop and upgrade it from Fedora 12. After I kick the tires for a bit I’ll upgrade my desktop.

The last time I did this I was frustrated that I had to download all of the packages twice, once for each system. This time around I decided to fix that. I discovered this page that talks about various methods of caching the download after the first time. My initial thought was to use the “rsync /var/cache/yum and keepcache=1” approach as it’s by far the easiest to implement. The problem is that the IBM script that wraps around preupgrade to make sure that all the IBM pieces get upgraded/added properly has a nasty habit of ‘yum clean all’ing at inconvenient times if you need to restart preupgrade which would clear the cache (yes that’s a defect, they don’t seem interested in fixing it).

So instead I thought I’d go with just the ‘Squid with cache’ route. That doesn’t work nearly as well as one would hope due to all the various mirrors that could be used. The raw Squid cache might work well for a large organization but doesn’t hack it for what I want.

I ended up with the ‘Squid with IntelligentMirror‘ approach which seems to be working well so far. The RPMs are still being downloaded onto the laptop but I’ve validated they’re correctly being stored on the desktop so when I get ready to upgrade it, the process should be significantly faster.

As a reminder to myself: use the intelligentmirror-0.5 package and not the intelligentmirror-1.0.1 package, despite what this file says. The 1.0.1 package just serves up the pre-cached files but doesn’t actually do the caching.

Making your monitor easier on the eyes

As someone who sits in front of his computer at least 8 hours every day, I’m pretty picky about my monitors. Three years ago I forked out my own money for two 1600×1200 LCDs from Dell and love them. Oddly I’ve never poked around with the monitor’s color temperatures.

Yesterday I stumbled, via slashdot, over Redshift. This little jewel adjusts the color temperature of your monitor to match the level of the sun throughout the day at your particular location on the earth. In other words, the color temperature of the monitor subtly changes throughout the day: warmer in the mornings, cooler during the day, warmer in the nights. (The “cool” and “warm” labels make intuitive sense if you see the colors — the warmer colors have a red cast to them and the cooler colors have a blue cast to them —  although they are opposite of the actual color temperature measured in Kelvin and the actual temperatures outside at that time of the day.)

The first time I used it the change was very abrupt. By default my monitors have a very cool, almost icy blue, color. Redshift adjusted that up to a warmer color. Determined to give it some time I used my computer throughout the rest of the day and in all honesty forgot about it. The color setting was retained from the overnight hibernation and I decided that I liked the change enough to change my system such that it starts Redshift when my X-windows session starts. Doing so required stopping it, which adjusted the colors back to the defaults, and starting it back up again. Wow – the difference (excuse the pun) is night and day. The default icy blue color was noticeably harsher on my eyes.

I’m probably going to adjust the coolest color to be a bit blue-er but overall I think I’ve had less eye-strain yesterday and today.

I’m a spot color guy living in a process color world

Growing up in a print shop gives me a unique knowledge of all things print. Stray too far outside of the spot color domain however and I have to start getting resourceful.

My family’s business has always used offset presses. And even while they have T-heads to enable the simultaneous printing of 2 colors — the ink has always been Pantone spot colors. This means that whatever we designed, be it on the old negative-creating typesetter circa 1980 or Adobe InDesign, would come out black-and-white in the end to be “converted” to a single spot color on the presses. [Aside: I’m not even going to get into the use of halftone screens and the camera in order to make printable photos — lets just gloss all over that and say it all ended up in black and white.] At no time did I ever need to delve into the process color domain. I knew it existed, I grok the basic concepts, but I didn’t have to concern myself with it.

Recently Benjamin was designing a banner in Inkscape that was to be printed by a 3rd party vendor who specifically requested the document be in CMYK. I dug around and discovered that while Inkscape has some tentative support for CMYK, it is unable to export EPS files in that color space. The work-around is to import the SVG file into Scribus and create the EPS from there as Scribus has better color management support. The tricky part is that Benjamin had used three high-resolution JPEGs in the SVG — JPEGs that were in the sRGB color space. I attempted to use jpegicc utility from littlecms to convert the image from the sRGB color space to a CMYK color space using an Adobe ICC file which succeeded. However, viewing these images did not give me a comfortable feeling that they would look good in print. I ended up punting the work altogether and asked a friend to use Adobe PhotoShop to do the conversion. I was then able to do the Inkscape -> Scribus route to get the final EPS format.

The banner was reported shipped yesterday. Hopefully my color space wrangling worked and it’ll look good upon arrival.

Inkscape development dependencies on Fedora 12

Just FYI, if you’re wanting to compile Inkscape from source, you’ll need (at least) the following dependency RPMs on Fedora 12:

  • gc-devel
  • glib-devel
  • gtk+-devel
  • gsl-devel
  • libxml
  • libxml-devel
  • poppler-devel
  • poppler-glib-devel
  • libsigc++20-devel
  • glibmm24-devel
  • cairomm-devel
  • pangomm-devel
  • gtkmm24-devel
  • ghostscript
  • ghostscript-devel
  • jasper-devel
  • ImageMagick-devel
  • ImageMagick-c++-devel
  • libwpd-devel
  • libwpg-devel

Fedora 12 and VMware Player 3.0

Over the Christmas break I took the plunge and upgraded my Fedora 11 desktop to Fedora 12 (this was after testing the upgrade on my laptop first). Things went seamlessly until I went to run VMware Player 3.0 which was installed pre-upgrade. VMware Player successfully recompiled the kernel modules but kept crashing after the GUI would come up. Thanks to some googleing, forum posts, and a bit of redirection I came across this post. I went for easy route and just added the line:

pref.vmplayer.downloadPermission = “deny”

to ~/.vmware/preferences and the GUI comes up as expected.

IDE thoughts (aka Hating Eclipse)

When I first started programming, way back in the early 1990s, the first IDE I was exposed to was the Borland C++ DOS IDE that came with my copy of Borland C++ (on something like 31 3.5″ disks and a huge box of printed manuals). I started using Microsoft Visual C++ sometime after starting TAMS in 1995 and eventually moved over to Visual Studio after it came out in 1997. All along the way these IDEs were intuitive, easy to use, and still very powerful.

After starting IBM in 2000, I did less and less C/C++ coding and much more scripting work (shell and perl primarily) and web development in PHP. The scripting work didn’t require the use of a full-blown IDE and I did most of my perl development in Scite, a very sophisticated text editor but not a full IDE. The PHP code was developed either in Scite and FTP’d up to the sever or directly on the server using vi/vim.

After about a decade without working with a full IDE, I decided about a week ago that it was time to test the IDE waters out again — primarily for integrated version control support. Against every rational fiber in my body, I decided to try Eclipse.

Up until last week I had an irrational hatred for Eclipse primarily because Lotus is using it for every desktop program they create from Notes to Sametime. Yes, they bundle this huge java-based IDE with dozens of unnecessary plugins that you can’t remove due to dependency hell, just to have an IM session. And of course each one comes with its own bundled java JRE. After being acquired, Rational was forced down this ungodly road as well. Even the most recent version of IBM Tivoli Directory Integrator was moved to Eclipse. At IBM, there is no escaping Eclipse.

Knowing my hatred was primarily an architectural/philosophical issue I decided to give Eclipse a chance for what it was actually developed for: an IDE. I’m happy to say that my hatred is no longer irrational but is well founded: Eclipse sucks.

Unlike all of the other IDEs I’ve ever used, Eclipse is completely unintuitive. My needs weren’t all that difficult: I need a project containing a list of PHP files. I need to be able to edit and save those files. I need to be able to run the scripts through the command line PHP interpreter. And finally I need to be able to commit changes to my local SVN repository.

The project containing PHP files was easy. Editing and saving the files seemed to work OK too, although I’m still not use to its autocompletion stuff and my tab settings still aren’t correct (both user error I know). I’m completely unable to run the files through the PHP interpreter despite multiple times trying to figure it out. It is totally unclear to me how to check files into the SVN repository and at one point while trying to commit something Eclipse helpfully told me that an error occurred then deleted my file. I proceeded to spend the next 2 hours using ext3grep to the file back.

I acknowledge that the bulk of my hatred is just that initial learning curve. I get that Eclipse is very flexible and configureable but that also makes it unintuitive and unforgiving. Unless I can have some Eclipse-guru come sit beside me for a few hours and help me get things set up, I’m not going back.

For now I’m going to explore other IDE options like Komodo and Zend Studio to see how they fare (see also Seven great PHP IDEs compared from developerWorks). If they’re even remotely better than Eclipse they’ll be worth buying.

Running CUDA-enabled BOINC clients on Fedora 11

At the start of the summer I finally got BOINC running on my CUDA-capable NVIDIA graphics card. About the same time I stopped running BOINC since the last thing I needed over the summer was a space heater under my desk. Now that fall is officially upon us, I’m willing to burn some CPU cycles — and warm my feet. I started up BOINC only to discover that it isn’t recognizing the CUDA device any longer. Hurmph.

After some digging it appears that the problem was that some Fedora update along the way tightened up security such that the user running the BOINC service (ie: boinc) was unable to access the /dev/nvidia0 device. Following these instructions I was able to get the permissions fixed and the whole thing working.

Granted, setting up CUDA in the first place was a herculean task since the CUDA libraries have to exactly match the NVIDIA X11 driver versions. Then you have to make sure BOINC knows about the library (ln -s /usr/local/cuda/lib/libcudart.so /var/lib/boinc/libcudart.so for instance). The whole matching versions thing is quite the pain in the ass as the X11 drivers can be updated more frequently than the CUDA drivers forcing you to either delay updating the X11 driver install until the CUDA driver matches or upgrading the X11 driver and having CUDA disabled until the CUDA driver catches up.

Oh well, that’s what happens when you live on the bleeding edge!