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.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?