Open Source and the frustrations at end-of-life, and beyond

Over the years, I have turned to Linux and the Open Source community for a number of solutions to obscure and difficult problems. And, rarely, has the community let me down. But the community, like software development in general, has limited resources and sometimes limited interest.

Which is where I find myself today. Now, do not mistake this for a rant or use it to justify your position that Open Source software is not cut out for the job. But occasionally the frustration of trying to find the answer is enough to make you scream.

Here is my problem. I have a piece of software, an obscure piece of software that shows the power of the community and the rapid development model. It should probably also be considered well past its end of life, but that is a different issue. The software is for use in Amateur Radio packet operations but it has not been updated since 2003 and ideally runs on a kernel version of 2.4. I have a distribution of RedHat v9 (yes, I really mean version 9 – prior to Red Hat moving to their split personality of Fedora and RHEL, they got up to version 9 before spinning off Fedora Core 1 and RHEL v3) that I believe is the 2.4 kernel. But I thought I would try first with Fedora Core 3. This was after being unsuccessful at trying to compile the software in question under Core 7.

It was during the installation of support libraries for Core 3 that I discovered a problem. The repositories for Core 3 and the libraries that are non-standard like the AX.25 libraries I need, simply do not exist. I am sure with enough searching I could find what I need and maybe compile it up from scratch, but I am not sure I want to work that hard at it. And I expect that even if I can get the libraries, it might still not work because of changes that have been made in the kernel and associated core libraries between 2.4 and 2.6, which means that I would have to search even harder for the files I need. I should point out that finding even good information about the program is hard to find and the few sites that have information have either invalid files or corrupt archives or dead links.

So, I am left with few options. There is no replacement for the software. Few people are knowledgeable enough to reverse engineer, or forward engineer the libraries or the software, and I am not enough of a programmer to start a new project.

The community is a wonderful thing, but occasionally even the resources of the community are not enough. And that is sometimes very frustrating. By the way, if you have any experience with xFBB or a copy of the libraries to make it work, I would love to hear from you!


David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

End-of-Life Software...

kb9aln's picture

I wonder if maybe the wrong question is being asked here?

You are trying to make something really old in concept work in a modern world. Which is a ham radio problem. The hobby is aging in a not-so-graceful manner, and it is showing in the kinds of software that are being used. Perhaps it is time to move on?

Others have given very good suggestions on a way to do what you are trying to do. But is that what we really want or need in the ham radio hobby? Perhaps there are good reasons for software reaching the end of it's life. After all, nobody uses Netscape 1.0 anymore. There are many more browsers that are much more capable nowadays.

There are precious few people who are doing some great work in trying to bring some newer stuff into ham radio. The reasons for it being "a precious few" are many, and are way off-topic from the subject of this article.

The point is that maybe it is time to push forward rather than trying to bandage some old stuff together and make it work in today's world. The AX.25 packet radio world is fading away, perhaps this is an opportunity to move to something newer?

You may want to take a look at this:

  • This blog has info on some newer technologies related to ham radio and might give the community some ideas on how to push forward.

    Thanks for the article. It got me to thinking about this issue.

    I am offended ;-)

    David Lane's picture

    There is no doubt that what I am trying to do is probably the most backassward way out there to do things, and certainly the Amateur Radio community is very hidebound. You will get no arguments from me on that and more of us need to be bringing about change, even when the old dinosaurs are fighting it tooth and nail.

    Thanks for bringing the blog to my attention, I will take a look at it.

    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

    Free Software is about freedom!

    Diogo's picture

    Free Software is about freedom, not community!

    Don't get me rong. Community projects are a wonderfull thing, but they're not the answer to every problem.

    Free Software & Open Source Software, enable communitys with legal tools that in turn enable their community work on fair stances. And gives freedom to individuals to use the solution that best suits them. But Freedom is not everything that is needed to use any solution is just one of the requirements.

    That's why Free Software is just the minimal that we should require for ouselves, and should not be considered an extreme requirement.

    fbb package

    Anonymous's picture

    There is a fbb package listed on synaptic running on debian testing, debian sid, and ubuntu 8.04 on my systems. You could try running a live CD and installing it to see if it does what you want. If you want to stay with a redhat version, you might try converting to RPM with the alien program. The sid fbb is built against a current version of the libraries.

    That is news!

    David Lane's picture

    Excellent! That gives me something to investigate this weekend...Hopefully it is the same FBB program (as compared to some other use for the acronym). I will look into it.

    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

    Additional links

    Anonymous's picture

    You may already have these, but just in case.

    FBB homepage: has links for Mailing Lists, Up/Download area (current and prior source), Useful Links, and others.

    AX.25 home page:

    Try Slackware instead of FC,

    ischi's picture

    Try Slackware instead of FC, I was able to compile everything in Slackware since it is as close as can be to a vanilla distro. The switch to 2.6 happend not that long ago and a Version with Kernel 2.4 is still supported also.


    David Lane's picture

    OK, I will bite - you could compile xFBB 4.07j and find the libax25 and associated libraries (which has been my problem). I will give it a shot.


    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


    tim's picture

    Is this an option?

    Valid, but not in this case

    David Lane's picture

    A good suggestion, but no, not in this case. The problem is not with the program but with the secondary libraries that are not available. I was actually working in a virtual environment and the code spits the same errors. It isn't a hardware issue unfortunately, but thanks.

    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


    W. Craig Trader's picture

    David ...

    Let me see if I understand the problem. Someone took the time and energy to write some useful software, but hasn't had the time/energy to maintain it and upgrade it for the last five years. You implied that the software works on Red Hat 9, but that you have had problems getting it to work on more modern distributions. You don't have the time or knowledge to update the software yourself. You claim that the problem isn't hardware related.

    If this is the case, then Open Source Software and Virtualization would seem to be the correct solution to your problem. Pick your favorite virtualization platform, create a new VM, install Red Hat 9 and your software, and go. Don't try to port it -- just use it as it was written. If anything, the fact that it was written for an open platform means that older versions are still available for use, even if they aren't currently supported. Try and get a license to install and use Windows XP (or any other earlier version of Windows).

    If the original author had chosen to sell his software with a commercial license, the odds are no better that there would be a functional software package today, simply because the size of the audience is too small to support commercial development. I know this because if the audience for the software had been larger, someone would have picked up the project and kept it going.

    You can download Red Hat versions 1.0-9 here:


    David Lane's picture

    The problem is NOT with the least I don't think it is. According to the errors I am getting, it is with the secondary libraries which are throwing pointer errors.

    Let me be clear here. I have a copy of RH9 and it installs just fine. What I cannot find is the secondary libraries that are also required and are no longer available. It isn't an issue of virtualization - it is an issue of the libraries that are needed and are no longer available. It was written and designed for Linux.

    This is clearly a case of a small market piece of software. It clearly had a small developer base and it is a testament to the community that it was kept alive as long as it was. In fact, it is a testament to the community that the software was ever created in the first place. No where else would we have found the software but in the community. That being said, it is frustrating when a key component to keep the software going is no longer available in the community because it is "past the end of life" of the current distributions, minus one or two.

    But that, as they say, is life.

    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

    Just a comment...

    El Perro Loco's picture

    This is not a reply "per se"; I just used the "reply" link to... well, link this comment to the post it refers to.

    In my perception, the title of the article gives the bad impression that Open Source is *not* doing something *good* that commercial software *does*.

    I am not one to criticize and nitpick on titles, and in the past have complained when others did so. However, I think in this instance the title does FOSS a disservice.

    So, to the point: I like Craig Trader's paragraph that starts "If the original author had chosen to sell his software with a commercial license, the odds are no better that there would be a functional software package today...", and I agree with it.

    David (the blogger), that title was a poor choice of words.

    If the original author had

    Anonymous's picture

    If the original author had chosen to sell his software with a commercial license, the odds are no better that there would be a functional software package

    Depends. I can still run some DOS games in XP & Vista. Windows has an awesome record of backwards compatibility so if it was a windows app, I would probably find it working in Vista, or if not in vista in XP atleast. Note that I'm talking about applications and not drivers, which are obviously specific to a particular OS version.

    Yes, but...

    El Perro Loco's picture

    I really don't have the means to discuss, quantify or prove the backwards compatibility issue.

    I do think you (Anonymous) have a point. However, the opposite has already occurred to me with games and Windows 3.1 apps - they would refuse to run under NT, W2K and XP. (And *I* refuse to run under Vista.)

    So, it just a matter of collecting particular cases in particular environments. Linux, Windows and other OSs and environments all have their shortcomings - but this is too short a comment to exhaust the subject.

    I'll just finalize by saying that, when the entire story is told, I don't believe FOSS is at any kind of disadvantage in relation to non-FOSS software. (My apologies for the redundant "FOSS software".)

    Again: to me, the title of this blog entry is a tad bitter, and can cause a bad impression.

    To infinity and beyond...or not

    Anonymous's picture

    Perhaps the author was paraphrasing Buzz infinity...and beyond...and sometimes beyond is closer than we would care to have it be.


    El Perro Loco's picture


    Even so...

    On the title

    David Lane's picture

    As anyone who has worked with software, FOSS or not, will tell you, when you find a product you like, you tend to stick with it, especially if it does what you want it to do.

    As I said in my opening paragraph, the post was not a dig against the community, but it does reflect both my and other admins at large's frustrations with software at (and beyond) end of life and work required to keep it alive (so to speak) as well as the task to implement it with a new OS (or kernel version) that might not support it or have the necessary features to support it.

    What I have experienced is that "good" software (and here I mean software that lives a long after life) is tightly written, includes all the libraries that are not "stock" and does not have a lot of interdependency. It also tends to be "old style" design, in that it is monolithic.

    Now we can argue back and forth about the pros and cons of software design. In the end however, we must, at some point, throw up our hands and say...OK, time to find something else. What gets frustrating is when you discover that there is no "something else" and have to either find another approach (which in my case is increasingly limited) or build a completely different mouse trap (which is what we are looking at doing).

    The key difference here is that without the community, I would not even have encountered this issue because NO ONE would have built the framework for the first mouse trap in the first place, but as someone above commented, the depth of the resources (in terms of old repositories and other sources of stuff) that USED to be available seems to be shallowing rather than growing, and that, I would argue is not a good thing.

    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


    Anonymous's picture

    I did some searching of xFBB and found this mailing list archive site at

    In the 200808 folder there is a thread about using ubuntu 804.

    That post (or some other) might be of help.


    David Lane's picture

    I didn't find that one in my hunting but I will look!


    David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

    One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

    As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

    Learn More

    Sponsored by Bit9

    Linux Backup and Recovery Webinar

    Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

    In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

    Learn More

    Sponsored by Storix