The very first obstacle that any project can face is most certainly compiling on any platform other than the “primary” operating system.  Putting developers outside their development comfort zone can breed resentment for the new platform.  This resentment manifests itself into very sub-par code for the platform in question and only breeds more resentment as the project progresses and developers start complaining about how the other platform “just is not working.”  I see this all the time when developers start using the Linux tool chain when used to Visual Studio, and when a Linux guru tries to use platforms like Windows.  What eventually ends up happening is a bunch of smelly code gets written for the platform no one likes and is put together using a terrible build system that only further breeds discomfort and anger against the offending OS.  This reflects in the final product where users of the accursed OS are shunned for their complaints, new feature requests are not taken seriously, and one by one new developers that were brought in to work on the platform leave the company because even they get shot down when offering advice to the “project gurus” who hate the operating system they do not understand.

Fortunately scenarios such as this can be quickly remedied before they even start.  As a general rule, never put someone on a project unless they understand all the pieces involved.  When a Linux developer is put in charge of a Windows build, their first instinct is going to want to build a set of recursive nmake files.  Nmake is sort of like a command line make tool for Windows for those unaware.  Development of the tool was canceled after Visual Studio 2005, but it still works and some Linux developers still try and use the woefully inadequate tool as a replacement to gnu make.  As the Linux developer learns about the limitations of nmake he starts building up his resentment for the platform in general.  The final product being a nmake build system that is full of quirky “hacks” to work around nmakes limitations and emulate some of the functionality of gnu make.  For example, with gnu make you can setup automatic dependency scanning so if a developer modifies a header file all .c and .cpp files that depend on it are recompiled.  If the Linux developer does not find similar functionality with nmake, he might just decide to setup nmake  to delete all object files every run and recompile the whole project each build.  This in turn causes other developers to not want to use the Windows compiler because Linux compiles in half the time and they can make quick changes without waiting hours for a new build.  This in turn causes development on Windows to slow to a trickle and the platform falls behind on enhancement requests as Windows developers start leaving for better prospects.  And thus the downward spiral continues.

In a different scenario lets put a Windows developer in charge of the Windows build.  He is most likely fluent in the best tool for compiling on Windows, Visual Studio.  He knows that nmake is a disaster and instead builds easy to maintain Visual Studio solutions which allows other developers to open the project and compile effortlessly.  He then utilizes Microsoft’s MSBuild tool to setup automated build and packaging processes and the project continues moving forward drawing in the best Windows development talent.

Sometimes due to lack of budget or development talent it is not always possible to put the best talent on the right job.  In my recent project I had to build both a Linux and Windows build system.  At the time I knew about Linux make and even maintained a couple make files, but other than that I had no experience writing one.  At these times its important to stick to the core principles of software development.  KISS ( Keep It Simple and Stupid ) and DRY ( Don’t Repeat Yourself ).  Using these two techniques developers on an unfamiliar system can sacrifice time for quality.  Building the gnu make system took me longer than someone who knew Linux make backwards and forwards, but the end result is about the same.  As an added benefit, the developer gains insight into how the new system works and in the future will not take so long to create new make files.

Learning how to effectively apply KISS and DRY is a skill worth developing as it takes quite a few mistakes and failures to get right.  The important questions to ask yourself while working is “Is this as simple and concise as it could be?” and “Is this same concept used more than once in my project?”  Google is most definitely your friend as you struggle with new software or design.  Basically, how I go about using a new system is imagine what I want it to do, and Google for others who got it to work that way.  In some cases people will instead tell you that your idea is dumb and is not what the software was designed to do.  Which may make poorly trained developers insert a hack or two into the system to make it work like he wants.  But this is the important point!  If you are using KISS and DRY you should never allow any hacks of any kind into your work.  Work with the software, do not make the software work for you.  The world is a much nicer place when software is doing the job it was designed to do as it was designed to do it.  Do not make software work how your warped perspective says it should work.  If you take nothing else from this article take that bit of advice.

When developing large systems it sometimes becomes apparent that some changes require large amounts of copy and pasting.  In my project I had 20-30 individual build projects with 20-30 individual makefiles and visual studio projects.  At one point each makefile held a lot of duplicate information.  If I wanted to add a CFLAG to the whole project I would have to edit each makefile or if I was lucky, have sed do it for me.  The whole system was one big violation of the DRY principle, and I was wasting valuable time writing sed scripts rather than doing real work.  Recognizing the problem I quickly redesigned the system to correctly leverage the capabilities of the makefile include directive.  Ideally when working on a project that contains many individual builds its advantageous to keep the actual build logic out of the makefiles.  The only thing needed for an individual build should be a list of source files and any extra flags the build might need.  By using the include directive you can separate the build and link implicit rules into different makefiles that your project makefiles include and use.  Changes to the global project are then applied to a single makefile and are included by all projects.

Same goes for Visual Studio projects.  In a solution containing 20-30 project files, changing something as simple as the release flags takes a long time.  Thankfully Visual Studio allows you to use property sheets which are basically a collection of properties that can be applied to many projects.  I use them for specifying all properties in the project except build type and source files.

I have uploaded the current version of my makefiles and property sheet to bitbucket, feel free to check them out.

Moving on to compilers and source files.  I think it is more important to pay attention to KISS and DRY when writing code then when writing a build system.  Build systems can be changed, code changes can get complicated, especially if you care about backwards compatibility.  When writing code start simple and get more complex.  Think of an easy representation to shoot for and adjust your expectations as the requirements get more specific.  Pay attention to things like namespaces, type names, capitalization, and other minor style issues.  Do not throw all your types into a single namespace as that gets confusing when you start dealing with fields of 30 or more types.  Pick a standard coding style and stick to it.  New users may have to get used to it, but the last thing you want is a code base covered in five different standards.  This obviously breaks programmer flow and causes severe loss of likability as users cannot adapt to your project and code based on their expectations rather then reading straight from the doc.

My next post will contain tips specifically for coding.  Related to GCC, Pimpls, smart pointers, and unit testing.

First off let me say that I use debain as the main operating system for ALL my servers.  My asterisk, data, and web servers all run debian and I love the stability and flexibility that comes with debian and apt.  I have spent at least 4 years working with debian casually and through all the problems, ideas, and solutions that are typical in my line of work have presented me plenty of opportunities to exercise and expand my knowledge of linux.

It was just over a year ago that I tried moving to a linux environment on my laptop.  Since my laptop was custom built all the parts worked well with ubuntu and I had very little configuration troubles.  Unfortunately after a couple months I encountered problems caused by my tinkering that made me have to reformat.  I believe at the time I was trying to get Compiz or Beryl to work with my ATI card, something I think caused a lot of people some hair.  At the time I decided to reinstall Windows XP because I could no longer justify the inconvenience of playing around with linux when I could not make it do what I wanted.  This I will admit was because at the time I had very little experience with linux desktops, and my number one gripe was network configuration, which does not seem to have improved but more on that later.

This is a post about why I believe linux is not ready, nor should it try to compete in the PC desktop market.  Linux is an excellent server environment make no mistake, I would choose linux over Windows Server any day of the week.  I find the code for critical applications to be very well maintained, optimized, and in general very clean.  On the other hand, I find the code for desktop environments and ‘configuration GUIs’ to be a joke and buggiest pieces of software I have had the misfortune to work with.

For further reference, 4 days ago I decided to reformat my Vista desktop to Kubuntu, an operating system I had worked with in vm’s and had pleasant experiences with.  I chose to leave Vista because of a bug with USB hand off to my virtual machines, which is a crucial element of programming a Nokia 810.  This inconvenience was the last straw for me and I made the decision to reformat to an operating system I felt would work better for control freaks like myself.

My first impressions of kubuntu, was the very excessive amount of useless garbage programs sitting in my application menu.  My second problem was with the desktop widget system which would seem like a good idea but is executed very poorly and is not very user friendly to say the least.  After removing as many of the useless programs I could and installing some other better programs I opened firefox and was greeted by the ugliest looking interface I have ever seen.  I will admit, I have never been a fan of the GTK interface.  Even on windows I found the layouts and graphics to be messy, unappealing, and bland.  So when I came to realization that my entire desktop would look this way I was a little put off right off the bat.

However I was determined to give this a chance since indeed I needed to be able to program my new Nokia 810 and linux was the only solution.  I visited the Ubuntu forums, a place which actually deserves the praise it gets, and found various things to do ‘Right after installing ubuntu.’

I installed more programs, added sources for my media and graphics, updated openoffice, speed tweaked the file system and boot process, and was fairly happy with the end result.  Firefox looked half decent, my programs had neat little effects like wiggle, darken, etc, and most of all it was running on par with my windows system.  So I began to seriously exercise the system and bring it up to my standards.  I installed dmraid to manage my nvidia raid array, I got my other disks provisioned in fstab for automatic mounting, configured all my programs to work exactly as I wanted them to, and in general personalized the system to my liking.

It was during this time that I started to notice the little problems and glitches.  Firstly, I was not happy to see that the network manager was still the worst configuration app in the entire system.  I ended up uninstalling it and setting a static ip in network/interfaces.  Then came the problem of getting my dual monitors to work, and in turn, get nvidia drivers installed.  The automatic ‘Install restricted drivers’ wizard failed to produce any results, so I turned once again to the ubuntu forums and a script called Envy which did the job very well.  Configuring TwinView was then just a simply xorg.conf edit.

This brings me to point number one.

Linux is not ready because to much configuration is left to the command line

The gui configuration utilities simply do not work.  Those that do work have limited functionality and you end up configuring it yourself in the command line.  When was the last time you saw a standard user open ms dos to configure his network settings?

So as I finished configuring various systems and building the system as I saw fit I decided to try to actually use the os.  Opening firefox still left me with flash backs from 10 years ago, but it worked fine, so all was good.  I then downloaded and installed pidgin, as I could not live without a constant line to any of the people on my buddy list and was once again greeted with those flashy windows 95 graphics.  At this point I was getting pretty frustrated.  Sure, my windows swayed, they faded, I could alt-tab like a pro but my applications looked like they were resurrected from my old DOS laptop.  Something had to be done, so I immediately went online searching for solutions.

I found that you have the option to install custom themes for things like text layouts, colors, window styles, etc.  Something that I have never really used on Windows but I went ahead and dived into the top rated everything to bring my operating system into the year 2008.  I found that these layouts helped a little bit, but the real problem, boxy art, out of date pictures, remained.  It was at this point that I decided to look for different GTK themes and customizations, hoping to fix the problem at the source.  However I soon found out that GTK artwork is non-existent, very hidden, or just not possible.  Tell me what is the point of a centralized graphics framework when you cannot change themes?  This definitely deserves a check-minus in my book, and introduces point number two.

Linux is not ready because the system looks like crap

While the underlying framework and core operating code is fantastic, the GUI’s and desktops need work.  KDE4 from my understanding is an attempt to mimic some of Vista’s features and has been touted as the better desktop.  I could not disagree more.  The system was buggy, slow, and definitely not user friendly at all.  As a side note, in the little time I spent analyzing and poking at KDE4 I could never figure out why we needed a separate desktop ‘Widget’ to display files that are in the desktop folder.  The widgets sit on the desktop, but the widgets display the desktop files…

As an additional side note I have only had the pleasure of using Gnome, KDE and a splash of X during my brief forays into the linux desktop world, if there is a better desktop out there please feel free to post.

At this point I was pretty frustrated with the whole mess so I went to sleep and decided to work on it more in the morning.

After a good night sleep I was back on my computer and ready to tackle the operating system once more and amidst the endless forum searches, configuration tweaks, Dolphin crashes, I realized something.  This something is my third and final point and probably the one that will get the most flames.

Linux is not ready because linux does not work for the user, the user works for linux

Let me explain what I mean.  While I was wondering around the settings screens (the few that there are) I found myself continually frustrated at the limit of what I could change, configure, optimize, or just in general, ‘do.’  Linux is very much a arrogant bastard who would much rather give you a new world and say have fun then give you the tools to operate in its world.  When using windows, all the tools you need to change the system are given to you, right out of the box.  If you want to do something incredibly difficult, like add a 3d desktop or program your own file explorer, you are pretty screwed, but for most situations windows gives you the tools to handle the problem yourself in its world, not your own.  Linux on the other hand, even though its open source, is ruled by obscurity.  There is no consistency between the network configuration and the display configuration.  There is no intermingling of different programs, as was painfully pointed out to me when I tried to burn an iso image from a windows machine across the network.  All and all, linux is very introverted and unlikeable.  Now I must make a small note here, the ubuntu community needs to be given a handshake for their excellent effort on compiling useful guides and providing help to any strangers who grace their doorstep.  Unfortunately, all the smiles and friendly hand shakes do not detract from the serious design flaws inherent in any operating system in the hands of anyone who uses it.  And even though I hate to say this, I much prefer my operating system built by a money corporation where strict testing, quality assurance, and optimizations are kept at the forefront, not for the customers, but to make themselves competitive with other corporations.  On that note I would like to say that I might actually prefer to try a Mac OS next time I feel pined down by the Microsoft money machine.

So there in lies linux’s biggest problem.  It is not competing.  Not that it does not want to, it just can’t.  It can not compete with the multimillion dollar budgets of Apple and Microsoft dev teams, and it certainly cannot get any decent project management system in order to organize the thousands of varying and unique programs built for it since release. But this is OKAY.

Its OK that linux can not compete, its OK that the programs are different.  What is not ok is trying to convince people to install linux on a desktop or laptop pc where hardware is never consistent, drivers are always needed, and just getting the thing to recognize and deal with the thousands of different environments is itself a full time job.  No this is not where linux’s strength truly lies.  To find where the future of linux lies I took a look back at the device that started all of this.  The small, sexy, and very much in control Nokia 810.  This little device is run by a special operating system built off of debian called Maemo.  You will find no better example of synchronous design and program execution then here.  Why?  Because its not a pc, its not a computer that needs a new video card every two years, it does not need to know about any other devices outside of its own perfect little world.  That is what makes it the best version of linux I have used.  The system is still open, but users do not have to draw cards to tell whether they will spend 5 hours getting running or 5 days.  With this increase in freedom comes standardized programs and configuration GUIs, systems that actually WORK.  The Nokia works so flawlessly that it inspired me to first install Kubuntu, then write this article because I feel that the future of linux does not lie with the desktop pc, but with these small devices.  These devices, that have a set of unchanging hardware, guarantee that no network manager will crash when detecting your Broadcom modem model number x15220 from 1997.  It guarantees that when you run network configuration your settings will take effect on your true device, instead of usb0 or visa versa.  I am currently reinstalling Windows Vista on my computer and with that I will reinstall VMWare and find a solution to my original bug so I can setup the maemo sdk and start programming applications for this device.  Yet in order to do this I am ditching my linux desktop solely because I just could not stand it compared to Vista.  Vista is by no means perfect, and in some ways it can make me just as frustrated as Kubuntu did, but I can accomplish a hell of a lot more in a windows operating system at this time.

Maybe this will change, maybe there is some other desktop environment that people like me use and I am unaware of it.  Certainly if you the reader have any suggestions I would welcome them and maybe even consider reformating again to try them, but at this moment I stand by what I have said in this article and hope that those who read it can offer constructive feedback, good or bad.

I also created a second project of a more work related function. This project deals with reading and parsing Bellcore BAF files created by various soft switches in use around the world. These records contain call records in a highly coded and formated to Telcordia specifications in their GR-1100 document. This document is not very cheap to come by so I have started work on improving one of the best free parser’s available today, bafview. You can find this project here http://code.google.com/p/bafprp/