Welcome to the Event Horizon

I had wanted to run audacity on Solaris for quite some time. The first time I tried to compile it was at least 18 months ago. It was a painful process that I quickly gave up.

Fortunately, things have come a long way since then. Getting audacity to compile and run on Solaris isn't a trivial process, but to be realistic, it's hardly trivial on any operating system. There are a lot of dependencies, and the size of that list depends on how much functionality you want. I will attempt to outline the path of least resistance.

First off, I do not work in the open source group here at Sun. I got peripherally involved in helping make audacity work on Solaris based on my personal interest. There are other folks that have done most of the heavy lifting in this area, and I'd like to thank them for doing so. I did, however, help tweak some of the patches as required to allow audacity to be compiled with SunStudio 11 and 12.

While I'm on the subject, you can build all of the required packages using either gcc or SunStudio 11 or 12. The trick is to make sure that all of the packages are built with the same compiler. If you wish to use gcc, be sure the env.[c]sh script in the CBE is setting all the environment variables correctly. In addition, I'd recommend building SFEgcc.spec and using that version of gcc for building any of the SFE packages.

In order to build audacity, you'll need the following:

• A system running opensolaris
• Either SunStudio 11 or 12 or gcc
• The JDS CBE (Common Build Environment)
• SFE (spec-files-extra)
• OSS (Open Sound System)

Opensolaris

I will assume you already have a system running opensolaris, so let's move on.

JDS CBE

You'll want to install the CBE first, since you can use that to build and install gawk, which you'll need to build OSS. Pick up the latest tarball here. The instructions for building and installing the CBE can be found here.

One thing to note if you're running a recent opensolaris build. For example, in build 86 many packages were moved, renamed, or removed. I had to change the following in the cbe-install script in order for it to grab the right packages. Of course, I think they're right, but honestly I did this in a hurry and didn't try very hard to validate the changes.

OLD:

JDS_DEPENDENCIES="SUNWgpch SUNWi2cs SUNWi1cs SUNWi15cs SUNWceuos
    SUNWcleu SUNWeuluf SUNWdeiso1 SUNWi5cs SUNWi13cs
    SUNWi9cs SUNWeeuos SUNWi7cs SUNWesiso1 SUNWcleu2
    SUNWeu8os SUNWfriso1 SUNWale SUNWhkleu SUNWhleu
    SUNWinleu SUNWitiso1 SUNWjfpu SUNWkleu SUNWmeaos
    SUNWsmbaS SUNWnafos SUNWnamos SUNWneuos SUNWsamos
    SUNWseuos SUNWsviso1 SUNWtleu SUNWweuos SUNWgtar
    SUNWwgetr SUNWwgetu SUNWhea SUNWsfwhea
    SUNWsprot SUNWxcu4"

NEW:

JDS_DEPENDENCIES="SUNWgpch SUNWi2cs SUNWxwplt SUNWi15cs SUNWlang-cs
    SUNWcleu SUNWlang-en SUNWlang-de SUNWlang-fr SUNWlang-hu SUNWlang-pl
    SUNWlang-sk SUNWlang-common-extra SUNWlang-cs-extra SUNWlang-de-extra
    SUNWlang-fr-extra SUNWlang-hu-extra SUNWlang-pl-extra SUNWlang-sk-extra
    SUNWceuow SUNWi5cs SUNWi13cs SUNWi9cs SUNWlang-bg SUNWlang-bg-extra
    SUNWi7cs SUNWlang-es SUNWlang-es-extra SUNWcleu2 SUNWale SUNWhkleu
    SUNWhleu SUNWinleu SUNWlang-it SUNWlang-it-extra SUNWjfpu SUNWkleu
    SUNWlang-ar SUNWlang-es SUNWlang-da SUNWlang-sv SUNWlang-sv-extra
    SUNWtleu SUNWgtar SUNWwgetr SUNWwgetu SUNWhea SUNWsfwhea
    SUNWsprot SUNWxcu4"

Once the installation completes, be sure to modify your .profile, .cshrc, or whatever script you need to update to grab the environment from /opt/jdsbld/bin/env.[c]sh. You'll either need to do that or source the appropriate file prior to building anything with the CBE.

SFE

The next step is to checkout the latest files from the spec-files-extra repository at sourceforge. This can be done by running the following command:

svn co https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk SFE

from the directory in which you wish to put these files. You'll end up with a subdirectory called SFE inside of which will be various .spec files, patches, etc.

Once the checkout is complete, cd into the SFE directory and run the following command to build and install gawk:

pkgtool build --download SFEgawk.spec

Once gawk is installed, the next step is OSS.

OSS

Download the latest OSS tarball from here. As of this writing, the latest build was 1015. Follow the instructions on the RELNOTES.txt file for compiling and building the package. Once the package is installed, you may need to reboot in order to allow the OSS drivers to bind to your soundcard. If you're not sure whether you need to reboot, try running "osstest" after installing the package.

The first time I tried to install and use OSS, it was very difficult to install properly. I've found, though, that both builds 1014 and 1015 work quite well. My only real complaint is that the ossmixer application opens a window that doesn't even fit on my screen due to all the controls for the multi-channel soundcard. I also wish the volume control in xmms would control the mixer volume, but I admit I haven't bothered to see if there's a way to make that work.

Audacity

Last, and certainly not least, it's finally time to build and install audacity. You can do this one of two ways. You could just build and install every .spec file:

pkgtool build --download *.spec

in which case you might as well get yourself a mondo cup of coffee or go take a nap. Alternatively, you can build and install those packages that are necessary for audacity. If you ran "pkgtool build --download SFEaudacity.spec", you'd find it would fail indicating several dependent packages that had not yet been installed. To save you the trouble, at least with the current .spec files, this command line should suffice:

pkgtool build --download SFEogg-vorbis.spec SFElibsndfile.spec SFElibsamplerate.spec SFEportaudio.spec SFEfftw.spec SFEladspa.spec SFEladspa-swh-plugins.spec SFEsoundtouch.spec SFEwxwidgets.spec SFEaudacity.spec

If that's the case, you should see a message indicating that the build/install of all these packages was successful. Hopefully that's the case. If it isn't, fortunately pkgtool leaves detailed log files that should help you determine what went wrong during the build.

If all went well, fire up audacity and twiddle some bits.

Cheers.

Hello again. Long time, no blog.

It has been a busy couple of months in HBA engineering land as we approach a nexus on several projects. In the mean time, I've given a great deal of thought to what it means to me to be a software engineer. With a nod to Robert Hunter's first album in the title of this entry, I figured now was a good time to take a few minutes to wax on about software engineering and grinding code.

I've been writing kernel/driver software for about twelve years now. It's what I've wanted to do since the first time I poked around on a TRS-80 Model 1 back around 1981. I've been fortunate enough to be able to do just that to my heart's content until I took this role in HBA engineering in September, 2006. Without going into the gory details of just how I ended up in a position with essentially no code development, suffice it to say that I've been pining away since then in an attempt to get back to doing what I love. As the months have passed, though, I've come to a couple of conclusions.

1. Software engineering != grinding code

Yes, duh. I don't claim that this is some major revelation, but bear with me here.

There is a big difference between being a programmer and being a software engineer. I doubt any professional software engineer would dispute this, but I suspect there are plenty of software engineers that would be rather disheartened to have to give up writing code. It's always possible to remain a software engineer who writes code day in and day out if that is what gives your job meaning. Unfortunately, it's entirely possible, especially at Sun, that regularly writing code can be in direct conflict to my second conclusion.

2. I'm not sure what I want to do when I grow up

For the past 25 years, I've never once had a question in my mind about what it was I wanted to do when I grew up. Write code. I love code. I love diagnosing problems, analyzing core dumps, and fixing bugs in kernel code. That hasn't changed. What has changed, however, is that I've come to a point in my career where I now need to answer the question of whether I want to be a "programmer" or a "software engineer." At some point in any lengthy software engineering career, this question is likely to present itself. Do I want to write code forever, or do I want to eventually get to the level where I can get involved in more interesting, architectural-type work and solve larger problems?

I'm fairly certain that the answer to that question is that I want to advance my career and work with the minds that are solving the architectural issues that not only face the industry today, but will be facing the industry in the future. With that said, I need to resolve the issue of regularly writing code. I'm not sure if I'm ready to give up writing code. Perhaps I don't have to altogether, but it's not clear to me whether I'm reluctant to give up coding because I've done it for so long and I'm comfortable with it or if it's simply that I am worried about not being able to advance my career without giving it up.

It is obvious that these are questions I need to answer for myself, although I suspect there are plenty of engineers out there that have faced the same dilemma. I would love to read comments from anybody that has faced this or is facing this. Chime in. Give me your thoughts.

Until next time,

David

Greetings,

During my recent five month stint at another company, I got into a debate with one of the long-time software engineers about code style. I was in the midst of working on a Linux video driver and had made some changes that I wanted him to have a look at. He made an off-hand comment about how I could feel free to change anything I wanted (he had written the driver I was working on). I responded that, while I'd like to change the way the code is formatted, I didn't see any point in doing so. It was just that the code was difficult to read.

One could hear the proverbial gloved hand smacking the face.

Alright, so it wasn't a knock-down, drag-out WWF style discussion, but I remembered the conversation yesterday while I was doing something I haven't done at Sun for quite some time; looking at code.

This is a great illustration of the topic we discussed (this code is freely available if you know where to look):

   int ret, field, size, count, nbfrs;
   VidDevice *vid;
   VbiDevice *vbi;
   V4LDevice *pp;
   printk(KERN_INFO AMD_VERSION "\n");
   pp = kmalloc(sizeof(*pp),GFP_KERNEL);
   if( pp == NULL ) return -ENOMEM;
   memset(pp,0,sizeof(*pp));
   strncpy(&pp->name[0],DRVNAME,sizeof(pp->name));
   pp->name[sizeof(pp->name)-1] = 0;
   pp->debug_level = debug;
   pp->irq = irq;
   lx_dev = pp;
   DMSG(1,"\n");
   vid = &pp->vid;
#ifdef CONFIG_PROC_FS
   lx_dev->proc = proc_mkdir(PROC_PATH,0);
   if( lx_dev->proc != NULL )
      create_proc_read_entry("video",0,lx_dev->proc,proc_lxv4l2_vid_read,vid);
#endif
   if( (ret=lx_init(pp)) != 0 ) return ret;
   if( (ret=vid_mem_init()) != 0 ) return ret;
   vbi = &pp->vbi;
   spin_lock_init(&vbi->lock);
   spin_lock_init(&vid->lock);
   vid->std_index = STD_SD_NTSC;
   vid->std_num = v4l_std_data[vid->std_index].num;
   vid->std_denom = v4l_std_data[vid->std_index].denom;
   v4l_default_capt_format(vid,&vid->capt);
   vid->capt_state = capt_state_idle;
   size = phys_bfrsz(vid->capt.sizeimage);
   count = v4l_max_buffers(size,vid);
   nbfrs = count - V4L_MIN_BFRS;
   if( nbfrs < V4L_MIN_BFRS ) nbfrs = V4L_MIN_BFRS;


There is nothing functionally wrong with the above code.  (Well, maybe there is, but that's neither here nor there).  In fact, the engineer who wrote the code was highly respected, even by me.  However, just because a piece of code is functional doesn't mean it's "good".  I mentioned that the code was difficult to follow.  Said engineer responded that code shouldn't read like poetry.

The glove was now on the other hand.

I didn't come right out and disagree, but in my opinion that could not have been more wrong.  It goes back to the "functional code != good code" argument.  The fact that it took me significantly more time to understand the code due to the formatting was my reason for why it was not good code.

If you had a close enough look at the code above, you undoubtedly noticed many statements written in one line that would traditionally comprise multiple lines (look for the if statements).  The other notable "feature" is the utter lack of whitespace.  The engineer's rationalization for this type of code "style" (or lack thereof) was that "real estate is king".  The more code that can fit on the screen at a time, the better.

I find it difficult to argue with that type of logic.  Fundamentally, he and I are on different planes of reality.  Anybody that writes code for a living must eventually come to understand that nobody owns a piece of code forever.  Somebody else will no doubt be responsible for maintaining or extending your code at some point in the future.  Personally, I'd rather not have a curse on my house for generations to come because I wanted to be able to see an extra five lines of code without having to  scroll down.  It seems to me this argument becomes even more salient when the code you write is visible by the entire world.  The number of folks who would love to run into you in a dark alley late at night has now increased by several orders of magnitude.

What is it that makes poetry inherently interesting?  It's a combination of the words that are chosen, the way those words are put together, and the underlying message being conveyed.  In fact, even the way those words are presented on paper lends itself to the enjoyment of the work.

With all this in mind, how is software different from poetry?  Good code is a combination of the same factors.  An appropriate choice of constructs, the method used to compile the constructs into something cohesive, and how the way the code is presented allows for a rapid understanding of the problem being solved are higher contributing factors to successful software than how many characters you can squeeze into a window.

Suffice it to say the denouement was less than satisfactory.  I am no more likely to convince someone that software is very much like poetry than I am to swim the English Channel.  I take solace in the hope that I am not the only one that believes in software as poetry.

Cheers,

David