- LJ Index, March 2007
- diff -u: What's New in Kernel Development
- Top Ten Reasons We're Changing LJ Back to Its Original, Smaller Size
- They Said It
- Cast Freely
- Tales of an Asterisk Addict
- A New Province of Open Source
LJ Index, March 2007
1. Number of journalists in prison, worldwide, on December 7, 2006: 134
2. Increase in jailed journalists over one year earlier: 9
3. Number of nations with jailed journalists: 24
4. Number of jailed journalists that are Internet-based: 67
5. Position of China among the world's leader in jailed journalists: 1
6. Number of jailed journalists in China: 31
7. Firefox's market share percentage in Slovenia: 39
8. Firefox's market share percentage in Finland: 35.4
9. Firefox's market share percentage in Slovakia: 34.3
10. Firefox's market share percentage in Poland: 32.3
11. Firefox's market share percentage in the Czech Republic: 31.3
12. Firefox's market share growth rate percentage in France: 19.5
13. Firefox's market share percentage in North America: 13.5
14. Firefox's market share percentage in Oceania: 21.4
15. Average minutes and seconds spent on a Web site over mobile phone: 2:53
16. Average minutes and seconds spent on a Web site over other connections, including PCs: 5:03
17. Linux server revenue in billions of dollars for the last measured quarter: 1.5
18. Linux year-over-year revenue growth percentage: 5.4
19. Linux share percentage of all server revenue: 11.8
20. Reliability rank of Linux-based Tiscali: 1
1–6: Committee to Protect Journalists
7–16, XiTi Monitor
diff -u: What's New in Kernel Development
Promise has released hardware specifications for the full line of chipsets supported by the sata_promise.c driver. This is excellent news, especially considering that Promise has been reluctant to release any specs until now. Jeff Garzik has been negotiating with them on this issue for a while now, and as this news shows, he has made significant headway. It's great to see Promise begin to turn around on this issue.
Karel Zak is working toward forking the util-linux project or taking it over from Adrian Bunk. Karel maintains the Red Hat package, and Adrian has not been as active as Karel would like on the project lately. Karel posted to the linux-kernel mailing list recently, explaining his plans to create a git repository and home page for the project and to start merging known bug fixes into the code base. His intention is to make the transition as peaceful as possible and have a good handoff from Adrian. As H. Peter Anvin points out, an outright forking of the code could be the best way toward that peaceful transition. As he says, once Adrian sees that Karel is able to do a good job, he might feel less reluctant to let go of the project.
Mikulas Patocka has released an initial version of SpadFS, a new filesystem he created as part of his PhD thesis. It attempts to solve the problem of sudden reboots in a simpler way than journalled filesystems. Mikulas finds journalling too complex and bug-prone, preferring a method that he calls crash counting. In this technique, the filesystem keeps track of whether it has been mounted or unmounted; it also tags fresh data with this information, until the data can be written properly into a consistent state. If the computer crashes and comes back up, the filesystem will notice that its saved mount state doesn't match its current mount state, and it can then revert to the most recent consistent state of its data. SpadFS seems to be on the fast track to kernel inclusion, with support from Linus Torvalds, who has gone so far as to say that it “doesn't look horrible” to him.
The brand-new ext4 filesystem has been accepted into the official kernel. Actually, at its current state of development, it's more just ext3 with some additional patches, making acceptance a much less difficult prospect than other filesystems, notably ReiserFS. But unlike ext3, the ext4 code will continue to accrue new features and undergo other large changes. These large changes were one of the primary reasons why Linus Torvalds insisted that the developers give the project a new name. The filesystem, he said, should be completely trustworthy. Once stabilization occurs in a filesystem, he believes that should be the end of it. Little enhancements and bug fixes might still be okay, but for larger changes involving greater risk of data corruption and other problems, a stable filesystem just should not have to go through that. This was the motivation behind forking ext2 into ext3, and probably will be the motivation behind forking ext4 to ext5 in a few years.
Presenting a system's power source to the user via a consistent interface has not been a high priority in kernel development until recently. Each different type of battery has had its own interface into the kernel, creating a generally hard-to-use mess. But David Woodhouse recently announced a generic battery class driver, regularizing the entire interface. He is even considering adding an AC power interface to this driver, though there have been some voices of dissent. Richard Hughes, for instance, feels that batteries and AC power are sufficiently different to warrant a separate driver for each. But as David currently sees it, the two interfaces will be so similar that there's no point in duplicating a driver for each. So far, the debate has not been decided. Having at least one generic power driver, however, does seem to have a lot of support among the kernel hackers.
Top Ten Reasons We're Changing LJ Back to Its Original, Smaller Size
10. The old /var/opinion used to fit perfectly in my birdcage.
9. The edges stick out when I'm pretending to read Playboy.
8. My vintage Logitech hand scanner needs three passes per page.
7. It doesn't fit in my hand.
6. It slides off the toilet lid.
5. Saves trees.
4. It doesn't fit in my magazine holder.
3. Wired did it.
2. The extra white space caused too much glare.
1. Number one is irrelevant—you don't need LJ when doing number one.
They Said It
Just because it's hard doesn't make it worth doing.
It's often assumed that putting secret codes in music files to protect them from being copied is a way to prevent copyright infringement. But it's not really about that at all. At heart, digital rights management (DRM) is a business strategy, not a police action. And that strategy may be reaching the end of its natural life.
We are moving to a world in the 21st century in which the most important activities that produce occur not in factories and not by individual initiative but in communities held together by software. It is the infrastructural importance of software which is of primary importance in the move to the post industrial economy....Software provides alternative modes of infrastructure and transportation that is crucial in economic terms because the driving force in economic development is always improvement in transportation....Software is creating roadways that bring people who have been far from the center of human social life to the center of that social life....Software can be used to keep software from being owned.
Now we live in a different world for the first time, all the physics, all the mathematics, everything of beauty in music and the visual arts, all of literature can be given to everybody everywhere at essentially zero marginal cost beyond the cost of making the first copy.
—Eben Moglen, keynote at Plone, www.youtube.com/watch?v=NorfgQlEJv8
Campware has released Campcaster 1.1, an open-source radio broadcasting system that runs on Linux (Debian and Ubuntu, so far) and is made to scale from individuals to staffed stations to multiple stations in a network. Features include:
Live, in-studio playout
Web-based remote station management
Centralized program material archives
Fast playback (using GStreamer)
Open, extensible architecture (including extensive use of XML-RPC APIs)
Campcaster is the latest open-source product from Campware, an initiative that supports independent news and media organizations in emerging democracies. Other products are Campsite (multilingual news publishing), Cream (customer relationship management or CRM) and Dream (newspaper distribution management). Find links to all and more at campware.org.
If you're interested in Campcaster, you also may want to look at Rivendell, a heavy-duty radio broadcast automation system developed by Salem Radio Labs, a division of Salem Communications, which owns one of the largest chains of radio stations in the US. In addition to Rivendell, Salem Radio Labs has a pile of Linux-based open-source products. Many are in use outside the US as well. Find them at salemradiolabs.com.
Although Campware is focused on emerging democracies and Salem Radio Labs is focused on the Christian broadcasting community, goods produced by both are wide open for anybody to use.
Tales of an Asterisk Addict
I've been building my Asterisk phone system at home for about a year and a half now. I hope that by reading this article, you get an idea of some of the configurations that can be built with Asterisk and how each configuration functions, as well as each configuration's drawbacks. Asterisk has given me the flexibility to handle incoming calls in ways that you'd never think possible and to make outgoing calls more convenient. For those of you who don't know what Asterisk is, Asterisk is a software program that can interface with the Public Switched Telephone Network, PSTN, and provides voice mail, conferencing and other sophisticated call-handling features, all under your control.
I first got started with Asterisk when I was searching the Web trying to learn what I could about VoIP. When I happened upon the Asterisk program, I couldn't believe it could be everything it was hyped up to be. Once I got it installed and configured, I was able to download software that I could use like a regular telephone, but I could call only other users on my server. This was a fun toy, and my young son got a kick out of hearing his dad's voice on the computer.
As fun as this standalone system was to play with, it wasn't very useful, so I decided to add an inexpensive interface card to the system that would allow it to make and receive phone calls over our regular PSTN phone line. With this interface card in place, my wife and I were able to use our computers just like regular telephones. The computers even rang when someone called us. By this time, I was hooked; VoIP was fun!
It was about this time that my wife and I had grown dissatisfied with our current answering machine, so I configured Asterisk to function in its place. As an answering machine, it worked quite well. My wife and I were able to put messages into folders, forward them to each other, and receive our voice-mail messages as e-mail attachments. As we both read our e-mail regularly, having our voice mail available from our e-mail client was very convenient.
People like to have fun with their answering machine greeting messages, and I'm no different. Because of Asterisk's flexibility, I was able to do something that couldn't be done with a conventional answering machine. My answering machine greeted people by name! When a call came in, the Asterisk system would answer and play a recording of me saying “Hello”. Then it would use the caller's caller ID to find a .wav file, 555-1234.wav for example, that contained a recording of me saying the caller's name. Then, finally, it would play our standard greeting. The result was something like “Hello, Tyra Banks, you have reached my super smart answering machine. Please leave a message.” Tyra never actually called me, but I'm sure she's just busy.
It also was nice not to have to get up to see who was calling. The Asterisk system was able to send caller-ID information to my MythTV, which displayed who was calling on our television. Sending caller-ID information as a pop-up to my wife's laptop as well as my workstation was pretty simple. But what was really nice was having incoming calls announced over the server's speakers. We actually were able to hear who was calling without having to run over to a phone or caller-ID box. In hindsight, it sounds rather lazy not wanting to be bothered to get to a phone to see who's calling. On the other hand, there are times when we simply don't want to be bothered. Why should I get up from the dinner table to find out who's calling, only to find it's a telemarketer that I don't want to speak with anyway?
The main problem with the Asterisk system at this point was that there was a definite disconnect between the Asterisk system and the “real” phones in the house. For example, we weren't able to use our real phones to check voice mail. The solution to this problem was the addition of an Analog Telephony Adapter (ATA). I chose to buy a Sipura SPA2002. The SPA2002 has one Ethernet port, two telephone ports and speaks the SIP VoIP protocol. The SPA product line is easy to configure with a Web browser. Once the SPA and Asterisk were configured, I could plug two phones in to the system and dial in and out with them.
Of course, I wanted to make the system as transparent as possible, so I had to do something a bit different. I bought a two-line telephone splitter and plugged both “telephone” lines from the SPA into the line one and line two receptacles on the splitter. Then, I plugged the line one and two receptacle into the wall, essentially using the splitter as a joiner. Now I could use any phone jack in the house, either line one or line two. I chose to use line two in the office and line one everywhere else. In most houses, if someone is on the phone, no one else can use the phone. With this setup, if someone is on the phone on line one, we simply go to the office and pick up line two to make our call. This has proven to be very convenient.
The analog telephones have one minor deficiency. The only way to know if you have voice mail waiting for you is to pick up the receiver and listen for the stutter dial tone. Of course, being able to receive voice mail as e-mail attachments is nice, but this situation is only slightly better than having Qwest's voice-mail service. Alas, this minor annoyance didn't improve until I started using standalone IP telephones, which I describe later.
Once I had gotten the home VoIP system working to our satisfaction, I decided to make the big jump by cutting our ties to Qwest and subscribing to a VoIP service instead. Choosing a provider turned out to be more difficult than I had expected. Because I still wanted to use my Asterisk system for call processing, I was able to eliminate several providers right away. Many providers either don't allow you to use Asterisk or don't support the use of Asterisk with their service. With something as complex as VoIP, and as important as my home phone, I really wanted to have support available. As I researched the remaining options, I discovered that many VoIP providers won't allow you to use the service for any commercial calls, including telecommuting and charitable activities. These companies don't publicize this type of policy, but if you read the fine print, you often find that the penalty for getting busted can be steep. At this point, I was down to the wholesale VoIP providers, but this came with the added bonus of being able to get ridiculously low rates, because the provider isn't providing any call features and isn't having to manage a voice-mail system.
Finally, I chose to go with a company called Terravon Communications, although other companies support the use of Asterisk with their service. Now that I was essentially my own phone company, this was when the schooling began. The first thing to note is that most wholesale VoIP providers are on a prepaid basis, so if you forget to pay for next month's service, you get shut off pretty quickly. The symptoms of failing to prepay are difficult to diagnose, because you still have a dial tone, but you can't call anywhere! I also learned, the hard way, that even seemingly innocuous changes to the Asterisk dial plan can cause major problems. I wish I had a dollar for every time I made a late-night tweak to the dial plan only to wake up the next morning to discover that the phones didn't work. Eventually, I learned to test, test, test.
Then there are those rare times that the phones don't work, and you know you didn't change anything. After working through the problem, you decide that the problem must be on the provider's side. So now who are you going to call? Well, nobody, because your phones don't work! Most of your support issues will be handled via e-mail. This is a mixed blessing. On the one hand, it means that you don't get the immediate satisfaction of talking to a warm body. On the other hand, it gives you the opportunity, or obligation, to provide the support staff with all of the information they need to diagnose the problem. I actually have a trouble report template I use on those rare occasions when I encounter problems on the provider's side. I first describe what the problem is. I confirm that I've made no changes to my Asterisk, server or firewall configuration since the last time it worked. I give a specific example of what I am trying to do that isn't working, such as providing a phone number or area code that I can't reach. Finally, I give them the relevant timestamped log entries from /var/log/asterisk/messages. I usually start by truncating the log file and telling Asterisk to start logging either IAX or SIP debug messages. Then, I do whatever it takes to repeat the symptoms. All of the messages that the servers exchanged, as well as the steps that my Asterisk server executed are now in the log file, which I send as an attachment to the tech support staff. You can save a lot of time by making sure that the engineers have all of the information they need—the first time.
One day, I got a call from a coworker who had heard that I had my own VoIP server. One of his friends was going to be in Europe for about three weeks and they wanted to know if I could set him up. He had a wireless PDA that ran Windows CE and wanted to know if he could connect it to my server and use it like a phone to call his friends and family in the United States, from Italy. Because this sounded interesting, I agreed to give it a try. He installed a copy of SJphone, and I configured it to talk to my Asterisk server. Then he went to Europe. Amazingly, it worked pretty well! I talked to him for several minutes, and it sounded fine, though I was a bit jealous to hear that he was sitting in a wireless cafe in Venice, Italy, while I was sitting in my office. The whole experiment cost me only $6 US in line charges, so it was worth it just for the nerdiness of it. I shudder to think what it would have cost him to call home from Europe with a land line, much less what it would cost if he had tried to use his cell phone.
I was already able to use any phone or computer in the house to make and receive phone calls, but I wasn't done exploring. I managed to borrow a Cisco 7960 IP telephone. This was a substantial, though temporary, improvement to our telephone system. The 7960 is a very attractive, business-looking phone. It also features a sharp LCD display that it uses to display context-sensitive menus as well as caller-ID information. But most important for me, it has a bright-red message-waiting indicator that we can see from across the house. However, at $300 US, the 7960 isn't in my budget.
Because the 7960 I had borrowed didn't allow Web-based configuration, it was a little bit more difficult to configure than the SPA2002. I had to create a configuration file that the 7960 downloaded from a TFTP server, which I also had to install. Fortunately, example configuration files are available on the Internet.
Finally, I decided to buy my own IP telephone and chose the Polycom Soundstream IP501, which I bought at VoipSupply.com for about $180 US. This positions the IP501 as a midrange telephone, suitable for either the office or home. The IP501 is a nice-looking device, though perhaps not as attractive as the Cisco device. It also has a red, blinking, message-waiting light. The LCD display seems smaller, but it's functional. The big plus with the IP501 is the way it sounds. Going from the Cisco phone to the Polycom phone is like going from AM radio to FM; it just sounds better.
The IP501 has a rudimentary Web-based configuration capability, though the real meat of the device's capability is exposed only via a configuration file that the device downloads via FTP or HTTP. Fortunately, the Polycom Web site contains complete examples of these configuration files as well as a 166-page Administrator's Guide.
Both the Cisco and Polycom phones feature a two-port switch that allows you to plug your PC workstation in to the phone, and then plug the phone in to the network. In this configuration, the phone will prioritize the real-time voice traffic over the rest of the network traffic, thus ensuring that voice quality is as good as it can be. Also, both devices are capable of negotiating separate VLANs for both the phone and the attached PC. This allows your voice traffic to travel over a separate, perhaps more secure, network. The network infrastructure has to support VLAN negotiation for this to work.
In the year or so that I've been using Asterisk, I've learned a lot and had a lot of fun. Starting from a standalone “toy” system, I added PC-based softphones. Later, the system was connected to the PSTN. Then, the system was connected to the house phone wiring. Finally, I added dedicated IP telephones. I ended up with a phone system that rivals those of many large offices. Each configuration, as well as each device, has its benefits as well as drawbacks. They all have their own unique quirks. Learning about these quirks is what makes VoIP so much fun.
A New Province of Open Source
Manitoba is going open source. And vice versa.
The Manitoba Media Centre is a new “Open Source Entertainment Engineering, Innovation, and Production Research Facility” in Winnipeg, capitalized by a $20 million investment from the Provincial Government of Manitoba and Linux Media Arts—a Los Angeles-based media production company. The Centre grows out of a trade mission effort between Manitoba and California.
The Manitoba Media Centre will work on development of multimedia applications for film, television and the Internet. It also will concentrate on the needs of educational institutions and developing economies.
Michael Collins, CEO of Linux Media Arts, says, “Our goal is to leverage the $20 million into at least a $100 million endowment within 18 months to two years through consulting, product development contracts and sponsorships.” For Linux specifically, he intends to approach development “ from the perspective of what is important to multimedia users. In other words, tool and applications and kernel changes that will improve the media experience. The various distros and the companies who support them do not have this market specifically in mind. It's mainly a support issue. How best can we support the multitudes of users worldwide building systems and products for this $1 trillion market? We think there is room for more.”
Find out more at manitobamediacentre.org.
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!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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