Software Development with Linux

Meet the Linux Family David Wuertele

TUE, 01 JUN 2010

Meet the Linux Family is a series of interviews with various software developers, managers, and users, who all have a point in common : they use Linux.  They will bring different point of views on various Linux related topics and share their Linux experience with you.

It's been a while since the last interview.  But this isn't finished yet.  This time, I've discussed with David Wuertele, who is a Linux System Architect at Motorola.

Laurent : For how long have you been using Linux?

David : I have been a Linux user since late 1993.  I wanted to run the Emacs editor and I was not satisfied with the DOS ports I've tried.  Linux allowed me to run a fully functional Emacs.

Laurent : For how long have you been doing software development using Linux?

David : I started creating Linux servers and writing code to run on them in early 1994.  I started using Linux as my primary desktop in 1995.  Before that, I had been using Solaris to do ASIC design.  When I discovered I could build and own a workstation based on Linux, I switched.  I still executed the ASIC design tools (which were X clients) on the Solaris workstations, but I used my Linux box as the X server on my desktop.  When the other engineers in my group saw what I was doing, they started doing it too.  It was much easier to customize the Linux desktop than the Solaris one, and since we owned our boxes we had more control over it.

Laurent : Do you think that it's a good idea for Linux software developers to keep an eye on what's happing in the larger UNIX/BSD world?

David : Absolutely.  Many, perhaps most, of the great features of the Linux kernel were developed as a result of external inspiration or pressure.  Linux itself started from just such an inspiration.  But more importantly, one of the main reasons that Linux has been so successful is that the pace of integrating ideas from the broader Unix/BSD world has been so high.  There is a big world out there, and it would be naive to assume that all the best brains work only on Linux.

Laurent : What are your day-to-day use of Linux?

David : Linux is my main desktop OS.  It is my development system for work.  It powers my web server, my mail server, my DNS server, my DHCP server, my router, my file server, and several media clients.

Laurent : Why do you prefer using Linux?

David : It started out as a Unix that I could access myself.  Now that I have built so much experience with Linux in all aspects of work, I would be seriously handicapping myself were I to not use it.

Laurent : What are the advantages of developing for/with Linux?

David : Linux is like a golden hammer.  You can hit anything with Linux and it becomes more powerful.  If you want your application to run on as many devices as possible, you should choose Linux, because even if your device is not supported yet, it will be.  And if you are in a hurry, you can port Linux yourself, and you don't have to get anyone's permission.  Since Linux has grown up in the public sphere, there is a volume of support for developers that dwarfs what is available for any other platform.

Laurent : What are the disadvantages of developing for/with Linux?

David : Linux-based desktop operating systems do not have the uniformity of interface that Windows has.  When a windows user sits down at another windows user's machine, they can work in a manner that they are used to sooner than a Linux user would be able to had they sat down at another Linux user's machine.  Obviously a Windows user sitting down at a Linux desktop would be very confused.  This situation is getting better, but there is still a long way to go.  For example, I know that my friend, who is not a Linux user, would be able to afford a better machine and be more effective with a Linux computer, but I'm not going to recommend that he gets one, because the interface would just frustrate him.

Laurent : What's your "pet peeve" about Linux software development?

David : There is still no successor to the "make" program.  I am an expert at writing makefiles and I love the concept of make, but I think the language is very very poor.  There have been many attempts to write a better make (ant, scons, etc) but none of them are really satisfying.

Laurent : Why do you still prefer make over ant or scons or ... ?

David : Ant and Scons have certain unique advantages, such as richer programming syntax and more automatic dependency checking.  But these programs also have their unique drawbacks, such as poor support for parallelism and small user base.  I am not satisfied with make, and I wish there was an unquestioned alternative to replace it, but I do not believe Ant or Scons are the answer.  Meanwhile, embedded chip vendors release their BSPs based on make, which ends up being the default build system used by most embedded system developers.  There are many people out there using make for their products that can't afford to invest in learning its arcane macro quirkiness.

Laurent : Which software development tools do you used the most?

David : Emacs.

Laurent : Any recommendations/hints/wisdom for people new to Linux software development?

David : Linux is super accessible, and there are so many places that you can dive in.  Don't be afraid of something that looks complex or unintelligible, just go through the tutorials and write stupid tests.  Use printf and printk to validate your understanding.  Don't expect to be an expert in less than ten years.  But remember that the investment you put into Linux will reap guaranteed rewards, because Linux is free.  Linux is not going anywhere.  Even if all of the companies in your country outsource all their engineering to another country, you can still make money working on Linux because the only limit is your own creativity.  One thing to be careful about is to maintain perspective.  It is easy to dive into some niche project on Linux only to find that your skills are invested in that one project's success.  If you do this, make sure you are strategic about it.  A safer alternative is to invest your skills in non-niche aspects of Linux.  For example, writing drivers and new board support packages is experience that can be easily translated to other aspects of Linux kernel development.

Laurent : Anything to add?

David : Although I have been writing GPL software since 1998, I only just released my first open source project this year : Crossplex.

Laurent : That's interesting.  What is it?

David : It's a library of make macros that help people support development of tool chains, kernels, and root file systems for embedded Linux products.

Laurent : I've already used crosstool and buildroot, how crossplex is different from them?  What are its advantages?

David : As mentioned above, Crossplex can be used from existing make-based build systems.  What I mean is that  Crossplex is a library of make macros that you can call from any makefile to instantiate rules for building various components of embedded systems.  You don't even need to be building an embedded system in order to benefit from Crossplex; you can simply use its third-party source unpack and build macros for any part of a software project.  You can use it to just build a tool chain, or you can use to to just build an application or a library.  But it also scales up to being the primary framework of an enterprise-level build system.  Crosstool is a closed system that does not build root file systems.  Buildroot is a makefile system that can build root file systems, but it is difficult to integrate into an existing build.

Laurent : Ah yes, I see the difference.

David : Crossplex is designed to be maximally integrated into an existing make-based build.  Crossplex also has more sophisticated parallelization support and rebuild support than either Crosstool or Buildroot.  The tool chain and root file system build macros have been designed from the ground up to enable maximum parallelism, limited only by the logical needs of the software.  The last difference I'll mention is Crossplex's directory structure.  Crossplex can simultaneously build many different target configurations, and to the extent that the target configurations could validly share intermediate objects, those objects are shared.  If the target configurations can not validly share intermediate objects, those objects are kept separate.  Therefore the need to clean the build of intermediate objects is drastically reduced, even when you have many different similar target configurations.  This is especially valuable to a developer who must make sure that multiple similar software configurations run on multiple hardware revisions.

Laurent : Thanks for sharing this with us.  I'll keep an eye on Crossplex, and will give it a try in my next embedded project.  Anything else to add?

David : Thanks for the interview.  And if anyone is starting an embedded Linux project, I hope they will consider Crossplex.  Anyone who uses make to build free software for embedded systems can benefit from the macros in the Crossplex library!