"Incompatible Browser" on FAFSA

I visited the FAFSA website recently (today, actually) and was greeted with the following message on Firefox:

"We have redesigned FAFSA on The Web with you in mind! All your FAFSA options can be accessed by clicking Start Here.

Click Close to continue.

We hope you enjoy the new look and features!"

Naturally, I clicked Close to continue, then clicked Start Here to access all my FAFSA options. Immediately I was greeted by an Incompatible Browser error (https://fafsa.ed.gov/FAFSA/app/errors?page=incompatibleBrowser) from the website. The error page does not actually take any action for a browser, it just prints out some information. In case that link dies, the gist of it is this:

Supported Mozilla Firefox Browsers:
Windows XP - Mozilla Firefox 3.5.x and 3.6.x
Windows Vista - Mozilla Firefox 3.5.x and 3.6.x
Windows 7 - Mozilla Firefox 3.5.x and 3.6.x
Macintosh Operating System 10.5 - Mozilla Firefox 3.5.x and 3.6.x
Macintosh Operating System 10.4 - Mozilla Firefox 3.6 

There's the problem: Firefox 3.6.16 on Linux is not supported. Supported by what, you might ask? One answer is that a script or application calling itself BrowserDetectService doesn't like it (from the same error page):

[Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.16) Gecko/20110322 Fedora/3.6.16-1.fc14 Firefox/3.6.16]
[BrowserDetectService:OS[UNKNOWN] browser[FIREFOX] browser version[FIREFOX3_6] AppName[FAFSA1112] detection status [BLOCKED]]

The first line is the User Agent (UA) string as sent by my browser. The second line is the output from this erroneous BrowserDetectService. I shudder to think that this may be an enterprise web service, making it accessible to Education Department applications other than just FAFSA. Not one to give up easily, I changed Firefox's UA string and logged on. Then, Just to be a smartass, I changed the UA on Seamonkey and successfully navigated the site with that. I went to the same error page and got the following:


[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)]
[BrowserDetectService:OS[WIN7] browser[IE] browser version[IE8] AppName[FAFSA1112] detection status [SUPPORTED]]

Note the detection status of "SUPPORTED" vs. "BLOCKED" in the BrowserDetectService line; the crucial difference is the operating system. So clearly it is supported by my browser, since I was able to use the site. However, I should not have to perform a hack like that to access a public government website. Artificial barriers like this one are deceptive and discourage the adoption of free/OSS software by creating a false perception of incompatibility.

At the end of the error page we see this little irony:

*Compliant Web Browser - Standard
For the past few years, every major Web browser released has been built around a set of open standards designated by the World Wide Web Consortium, a non-profit organization charged with overseeing the continuing development of the Web. What this means is that one piece of code now looks the same on every modern browser, whether it be Internet Explorer, Firefox, Safari, Opera, or others. The majority of our users are using these modern browsers, so we can present content which is optimized for them.

That's kind of the point, isn't it? Firefox is Firefox, regardless of the operating system. So are Opera, and Safari, and Chrome. Yes, there are slight rendering differences between platforms. A lot of these can probably be attributed to often incorrect assumptions made by many of us in the tech world. Installed fonts (I don't have a font named "Arial"), screen resolution, browser settings and many other factors can affect spacing, shift elements and break functionality of even the most carefully planned layout or application.

Let's talk standards then, since that is their defense. First let's check compliance with the W3C XHTML standard: http://validator.w3.org/check?verbose=1&uri=https%3A%2F%2Ffafsa.ed.gov%2F (11 errors in the markup). Next, the W3C CSS2 standard: http://jigsaw.w3.org/css-validator/validator?profile=css21&warning=0&uri=https%3A%2F%2Ffafsa.ed.gov%2F (18 errors in the stylesheets). Clearly, standards compliance is a flimsy excuse.

So I've described the problem; what about the solution? Don't use UA detection, for one thing. Correct browser detection boils down to coding with two simple principles in mind:

1. Target the standards and not particular browsers
2. Use feature oriented object detection

These recommendations are repeated all over the web, but probably most succinctly at https://developer.mozilla.org/en/Browser_Detection_and_Cross_Browser_Support. Many  methods exist to address these problems and gracefully degrade the application. Javascript libraries such as jQuery point the way by encouraging detection of general features which are necessary for proper application support.

In fairness, I must note that 11 markup errors and 18 CSS errors on the FAFSA site is actually an admirable level of compliance, as you will see if you check this very blog and many, many other sites. Nice job, Google!

See also: http://jeffhoogland.blogspot.com/2011/03/no-fafsa-for-foss-users.html

IDE-Experienced

Since I've been working on a lot of Drupal sites lately, my primary Integrated/Idiosyncratic Development Environment (IDE) has been Eclipse. The PHP editor, debugger and other tools (part of the PDT)  as well as Subversion, CVS and a bunch of other plugins make Eclipse a good choice for cross-platform development teams working on a wide range of project types. It's usually easy to set up and extend, but I did experience one problem on my Linux (FC12) laptop: Eclipse Update did not work at all, so the usual simple installing/updating of plugins by checking them off a list wasn't an option.

After some googling, I found that the problem was a bug (also here and many other places), which may or may not have been fixed on certain GNU/Linux distributions or with certain versions of Eclipse. The workaround mentioned here was the quickest fix, with one small improvement: I renamed the "eclipse" executable to "runeclipse" and named the shell script "eclipse", which calls the renamed executable. This way, all references to the original executable (think menus, .desktop files, Eclipse restarting itself) run the shell script with GDK_NATIVE_WINDOWS=true. So, Eclipse problems solved. Subversion integration worked without a hitch, and I was up and running.

The next project I'm working on is a C#/ASP.NET web application, with a heavy API of its own and plenty of library goodness to develop and integrate. The app will run on Windows/IIS, but I want to use my native desktop environment (GNOME/Linux) for .NET development. Plus, I'd really like to hack some GNOME apps, many of which run on Mono. Rather than attempting to make Eclipse run everything, I thought it was time to try out the obvious choice, MonoDevelop. Browsing the Fedora repositories (including RPM Fusion), I found the newest package available was 2.1. Since MonoDevelop doesn't maintain a Fedora package (hmm, I'm starting to see a pattern here) and I wanted 2.22, I embarked upon a good old-fashioned installation from source.

Things got interesting right away. Using the instructions from the README file in the source directory, I typed:

./configure --prefix=`pkg-config --variable=prefix mono`

First error:

checking for MONO_ADDINS... configure: error: Package requirements  (mono-addins >= 0.4) were not met:

No package 'mono-addins' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.

Alternatively, you may set the environment variables MONO_ADDINS_CFLAGS and MONO_ADDINS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

I already knew mono-addins was installed; I had done this earlier because I (almost always) RTFM. However, I had done it the nice, graphical Fedora/GNOME way: using gpackagekit to search for "mono-addins", selecting it and clicking "Apply". I checked just in case:

Yes, I actually make it a point to manage my system using the GUI tools provided with GNOME. After several years of remote Linux and FreeBSD systems administration using only SSH terminal sessions, I thought it was time to see how much functionality I could get out of a free desktop like a normal Windows or Mac user. It's the ultimate test for me and the feature set; I only resort to terminals when the GUI malfunctions or is missing a feature. Kind of like fisticuffs with one hand tied behind your back. More on that later.

Okay, then: man pkg-config tells me that pkg-config is a utility used to return metadata about assemblies to callers such as the configure script above. Running pkg-config --libs mono-addins returned:

Package mono-addins was not found in the pkg-config search path.
Perhaps you should add the directory containing `mono-addins.pc' to the PKG_CONFIG_PATH environment variable
No package 'mono-addins' found 

A quick check of the search path, and sure enough there was no PKG_CONFIG_PATH environment variable set. Yet pkg-config --list-all showed a long list of registered packages. Searching for *.pc, the configuration files turned up in both /usr/lib/pkgconfig and /usr/share/pkgconfig, but no mono-addins.pc. I had installed mono-addins from a Fedora repository, and confirmed that the libraries were in their correct locations. Then I checked some of the other libraries, such as monodoc:

What a surprise - the monodoc-devel package literally is just the .pc file. In fact, many of the devel packages for mono are just pkg-config files. Why package a 207-byte file separately? Who knows. I installed the devel packages for mono-addins and all the other mono and *-sharp packages, and configuration succeeded.

After this, I ran make and make install, which gave plenty of warnings but finished without error. It even installed a menu item in my Applications -> Programming list, and MonoDevelop started up quickly on the first launch. Hopefully this experience will help someone else, and I'll post more as I continue to use MonoDevelop.

Google Chrome comes to Linux (and other browser comparisons)

Just in time to save my Fedora experience from buggy plugin support and bad font rendering, along comes Google Chrome in its first public beta for Linux. First impression: this browser is so impressive I will probably leave Firefox for it.

I've used Chrome on Windows since the first public betas, and while it has been fast, simple and powerful, I never saw a compelling reason to switch from Firefox, of which I have been a faithful user and proponent since early betas as well. Until I decided to eat my own dog food and switch to Linux (specifically Fedora 12).

A picture is worth 1000 words, so without further ado check out the differences in rendering (click images to see full size). I'll update this post at some point with a full review of Linux browser options.

Google Chrome rendering Blogger

Firefox 3.5 rendering Blogger

Of course, the standard developer tools are present and accounted for:

For the fun of it, I took screenshots of some other Linux browsers. They look a lot like Firefox even though two use different rendering engines. Epiphany (bottom) and perhaps WebKit in general seems to do a little better at subpixel hinting.

Galeon, a good Gecko-based (like Firefox) browser for gnome

Konqueror, a full-featured KDE browser using KHTML

Epiphany, a Webkit-based (like Safari and Chrome) browser

NVidia Drivers on Fedora 12

I'm not the only one who had problems installing the proprietary NVidia drivers on Fedora 12, so I thought I'd post the surprisingly simple solution here. The color profile options and OpenGL support are well worth it:

1. To save a lot of headaches, install the standard VESA video driver first. On a fresh install, select the second option for installation ("Install with a basic video driver" or something like that). This will allow the NVidia driver setup to load its kernel module without interference from other loaded modules such as the "nv" or "nouveau" drivers. Most errors during installation are a result of other modules being loaded. You can edit grub.conf and blacklist the loaded driver as suggested here, but starting with the VESA driver is much easier.
2. There has been some confusion surrounding the Supported Hardware lists for different driver versions on the NVidia site. These lists comprise the latest chipsets supported by the driver version; in almost all cases the unified drivers continue to support legacy GPUs. In my case, an NVidia Quadro NVS 135M in a Dell laptop, version 190.53 works fine. Download the latest driver for your platform.
   
3. Switch to a console session (e.g., Ctrl+Alt+F2) and shut down X. "init 3" should suffice.
4. Run the driver setup (sh ./NVIDIA-Linux-x86-190.42-pkg1.run). It should automatically compile the correct kernel module and configure your xorg.conf or equivalent.
5. Reboot. You should see the NVidia logo when the screen mode switches.
6. The driver also installs a .desktop launcher for the X Server Settings interface shown above. If you don't see it on your app menu or anywhere else, the utility is called nvidia-settings and can be launched from a terminal window.
7. Enjoy.

Notes:

• To automatically apply any changes made in nvidia-settings when you start X, place the following in your .xinitrc or other startup script:
  nvidia-settings --load-config-only
• There appeared to be a bug in KDE causing a huge delay in menu response when the proprietary NVidia driver is used. My solution was to use GNOME.
• Fedora kernel updates may cause the video driver (and therefore X) not to load; if this happens simply reinstall the driver and it should recompile the kernel module.
• I have since tried 190.52 and 190.53 on this laptop and found that the Fedora updates were slightly behind the driver releases. If you try a new driver version and it causes performance problems such as the smallest apps showing a "Starting " window for several seconds, wait for another system update then try the driver again.

Other Resources:

http://www.linuxquestions.org/questions/fedora-35/fedora-12-nouveau-nvidia-driver-solution-771248/

http://linuxsoftwareblog.com/blog/?p=232

Introduction

Welcome to Code#. This blog will evolve into a series of HOWTOs, critical articles, implementation examples, and so on gleaned from my career in IT, especially software development and using open source software. Hopefully this will become a useful resource for others and myself in the future.

I have tinkered with electronics, computers and code for as long as I can remember. Since starting out at a small local computer shop in 1998, I have worked for Expression Networks, LLC in various roles including CTO, did a short stint as a contractor at Capital One, and landed at IOTA Solutions, LLC in 2012, where I am developing the next generation of MyClassEvaluation (online course evaluation software).

I am also President and CEO of Overlord Industries LLC, an entertainment production startup (website coming soon).

These days, I use a lot of open source software to build applications and have been running Linux on my personal laptops since 2005. I still write apps in C#/ASP.NET and I think .NET is an excellent platform, but the past few years of working with FOSS have really been a pleasant experience and have informed my worldview. I now believe that open source software is a viable and exciting business model for the future, for reasons which I'll detail in a future article.

My free software kick really began years ago I decided to install an inbound SMTP gateway to take load (traffic, spam scanning, etc.) off of Expression Networks' struggling Windows-based POP3/IMAP mail servers. These servers hosted about 25000 users on many domains and the volume of spam was an effective DoS at certain times. I settled on Exim for an MTA and FreeBSD for the OS. I soon discovered that the industrial-strength configurability of every aspect of Exim makes an incredibly powerful gateway, and I was hooked. Nothing other than open source software gives the user such complete control over configuration and execution.