uCommon Telephony Libraries
A number of years ago I wrote an article [see our publication Linux Journal, November 1997, ``Linux as a Telephony Platform''] about the use of GNU/Linux for telephony applications. At the time I introduced the DBS_Server, a freely licensed telephony server I wrote that integrates with the Panasonic DBS telephone system. I speculated that the future would be very bright for the use of GNU/Linux solutions in the telecommunications industry.
While the DBS Server had itself languished in obscurity for a long time since then, in fact, much has happened to promote free solutions for telecommunications in general and GNU/Linux-powered solutions in particular. Certainly the adoption of my Bayonne package, the first freely available telephony voice response server, as the official free telephony server of the GNU Project earlier last year, and the recent introduction of many other freely licensed telephony projects and packages of various kinds since then, has greatly pleased me.
However, I have also always been interested in smaller solutions--especially the use of free software for embedded applications. While Bayonne can be deployed on small systems, including 486-class machines with as little as 12MB of RAM, it hardly qualifies as a true ``embedded package''. I had thought of several different things I had worked on in the past when I started thinking about doing a free embedded package.
While the original DBS Server continued to provide reliable service for my home since it was first introduced, I had already started thinking about doing something with the DBS Server and the still somewhat new ``µCsimm'' (a microcontroller module built for Lineo's uClinux OS) when I unexpectedly heard from Peter Courtney who runs a company in the UK that was trying to introduce a general-purpose embedded ``PBX integration'' solution. From Peter, I learned about the Axis ETRAX product, which they use. Since it seemed their company was in part inspired by the ideas presented in my original Linux Journal article [see the November 1997 issue], and their product FAQ even quotes a few parts of it, I saw this as a good opportunity and platform to build a new and more modern version of my original DBS Server that could be deployed as an embedded Linux solution.
When one considers an embedded solution, one has to think about new tools and methods. Certainly C++, with the stdlibc++, would overwhelm the memory of a highly embedded system--even before the application was built. While I had spent much of the past few years working on C++ class libraries and servers like Bayonne, all these design approaches were inappropriate for the realm that this project would operate in. Finally, Axis, like the µCsimm people at Lineo and many other highly embedded vendors that support free software, had turned to uClinux methods and tools like the small uClibc replacement for glibc, to shoehorn a complete application, Linux kernel and supporting library that can run in 2MBs of system memory.
To start with, many of these highly embedded systems do not use traditional x86-based microprocessors and often do use specialized versions of gcc-based toolchains. The Axis toolchain is called cris and offers a gcc that supports their target CPU that can build tiny statically linked images. I was able to download and compile cris as a cross-compiler without any great difficulty.
One nice thing about the Axis toolchain and build environment is that they have set up some simple makefile rules that make it possible to compile both to the target device and on the host machine itself. The latter is useful for testing. With this in mind, I immediately went to work on a new DBS Server.
In the old DBS Server, I created a ``portable'' C-interface library that simplified many chores by offering convenience functions that I liked and bridged differences between systems. This was found in the sdk directory of the old DBS Server and proved useful in many other C-based projects that I was doing at the time. When I migrated to doing primarily C++ development, I created a class library with a similar purpose initially, which was called APE. This later became Common C++ and is now part of the GNU Project.
Similarly, I felt a need to create a common-embedded library, not just for writing this newer DBS Server, but for use in other embedded projects as well. Certainly it needed to be very small and yet prove able to contain measurably useful functions. Static linking would certainly help cut down in runtime size because only those functions actually needed by a given application would get linked in. Also, it had to be generic and not tied to a specific embedded environment and certainly also must compile under, and be usable with, a standard GNU/Linux host so that one could build and test embedded applications conveniently. Finally, it would have to be freely licensed. The result was uCommon.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide