UpFront

1. Percent of US smartphone Web traffic from iPhones: 55

2. Percent of US smartphone Web traffic from Android phones: 20

3: Percent of US smartphone Web traffic from Research In Motion (RIM) OS phones: 12

4: Percent of US smartphone Web traffic from webOS (Palm) phones: 5

5: Percent of US smartphone Web traffic from Windows Mobile OS phones: 4

6: Percent of US smartphone Web traffic from Palm OS phones: 1

7: Percent of worldwide smartphone Web traffic from iPhones: 50

8: Percent of worldwide smartphone Web traffic from Symbian OS phones: 15

9: Percent of worldwide smartphone Web traffic from Android phones: 11

10: Percent of worldwide smartphone Web traffic from RIM OS phones: 7

11: Percent of worldwide smartphone Web traffic from Windows Mobile OS phones: 3

12: Percent of worldwide smartphone Web traffic from webOS (Palm) phones: 2

13: Percent of worldwide smartphone Web traffic from Palm OS phones: 1

14: Percent of worldwide smartphones sold by Nokia: 45

15: Percent of worldwide smartphones sold by RIM: 13

16: Percent of worldwide smartphones sold by Apple: 5

17: Percent of worldwide smartphones sold by HTC: 4

18: Percent of worldwide smartphones sold by Fujitsu: 4

19: Millions of smartphones sold per year worldwide: 145.6

20: Millions of cell phones sold per year worldwide (including smartphones): 1,076.5

1–13: October 2009 Mobile Metrics Report

14–20: Gartner Research

I've already covered tar and all the wonderful ways to use it, but it's not the only tool at your disposal. Another popular backup tool is afio. Depending on your distribution, it already may be installed. On Ubuntu, for example, run the following to install it:

sudo apt-get install afio

Now you have a fairly powerful tool at your disposal for archiving files and making backups.

By default, afio reads and writes the files being archived on standard input and standard output. This means you can create a list of files to archive with another program, like find, and pipe it to afio to do the actual archive. Once you have your list of files, you can apply five basic commands to those files:

If you want to create a simple archive of all of your C source code files, execute:

find . -name *.c -print | afio -o -Z source_code

When you want to extract these files again, execute:

afio -i -Z source_code

When you run afio as a regular user, all file paths are stored with no leading /. This means when you unpack an archive, it unpacks in the current directory. The idea is to avoid overwriting system files accidentally. To keep the leading /, use the command-line option -x. Running afio as the superuser reverses this behavior—any leading / is maintained, and you need to use the command-line option -X to get the usual behavior of stripping the leading /.

If space is at a premium, afio also can compress your archive, just like tar, with the -Z command-line option. There is one very big difference, however. When you compress a tar archive, the entire archive file is compressed. This means if one part of the file is corrupted, you potentially could lose all the files in the archive. When you compress an afio archive, the archived files actually are compressed individually. So if one file becomes corrupted, by whatever means, you won't lose any of the other files in the archive.

When you compress an archive, afio uses gzip by default. You can tell gzip what compression factor to use with the -G num command-line option, where num is the amount of compression gzip will apply to the archived files. This is a number between 0 (for no compression) and 9 (for maximum compression), with a default of 6.

You may need to balance how much CPU and how much IO time is being used during the compression phase. If so, you can limit when compression is to be used. The command-line option -T threshold tells afio not to try compressing a file unless it is at least threshold bytes in size. The default setting is -T 0k, so afio tries to compress all files, no matter how small. At the other end of the spectrum, you may want to limit how large a file can be before afio tries to compress it. You can do that with the command-line option -2 max, where max is the maximum file size. The default in this case is -2 200m, so afio won't try to compress files larger than 200MB.

What if you don't want to use gzip as your compression method? You can change this by using the command-line option -P progname, where progname is the name of the executable to use to do the compression.

If you need to hand options in to this alternate program, use the -Q opt option. You need to use separate -Q options for each option you want to hand in to the alternate program. Because afio simply executes this alternate program, you can run anything at this stage, such as an encryption program, allowing you to encrypt your archive. To encrypt your archive using PGP, execute:

export PGPPASSFD=3
find . -name *.c -print | afio -ovz -Z -U -P 
 ↪pgp -Q -fc -Q +verbose=0 -3 3 archive 3<passphrasefile

This runs PGP on all files in the archive as they are added.

The last afio trick is having the ability to interact with archives on external systems in a similar manner as you would with tar. The format looks like this:

[user@]host[%rsh][=afio]:file

The option user@ is the user name you would use to access the external system. The default communications mechanism is rsh, but you can change that to ssh with the option %ssh. You can define the command to use on the external system with the option =afio. You can use this if the executable is named something else or in an odd location. So, if you want to archive all your source code files onto an external server over ssh, you could execute:

find . -name *.c -print | afio -o -Z user@server%ssh:archive

Using afio, go forth and ensure that you have proper backups of all of your important information.

If you're unfamiliar with the Chumby, you might want to go back to the May 2008 issue of Linux Journal. Daniel Bartholomew showed us all about the cuddly little gadget and explained why we might want one of our very own. The folks over at www.chumby.com still sell the original Chumby device, but they've come out with a new model, the Chumby One. I'm rather fond of the numbering scheme they chose, because that would mean the original Chumby is number zero. If the next model is the Chumby 10, they will get extra geek points!

How does the new revision stack up? Quite frankly, it's great. Although it may have lost the rounded edges and squishy case, the Chumby One adds some welcome features:

I'll admit I always thought a Chumby would be more of a novelty than a useful gadget; however, I was pleasantly surprised to see its rotating “widget” display happily keeps me informed and entertained during my workday. It can stream Pandora (and other) music in the background, display LOLcats and show you the weather. At night, it makes an extremely useful clock radio. Because it has a rechargeable battery, toting it around isn't a problem. If you've been tempted to pick up a Chumby, but were concerned it would just collect dust, you might be pleasantly surprised!

Like many families, the Powers' house has a “family plan” for our cell service. A year ago, when we estimated the minutes we'd need on a shared plan, 1,400 per month seemed like a good amount. Six months into our contract, we had more than 6,000 rollover minutes (yes, we use AT&T). To compensate, and save some money, we lowered our plan to 700 shared minutes. This Christmas, when our oldest daughter got a cell phone, we discovered we had several thousand new rollover minutes, even with the reduced plan!

Perhaps data-only cell phones will be here sooner than later. Certainly with things like Google Voice, Skype, Gizmo5 and any number of other VoIP services, seamless transition from Wi-Fi to 3G makes sense. As long as we can send text messages, pictures of cats and answer the occasional phone call via VoIP, why do we need traditional voice services? As someone who works in a building with no cell-phone coverage, but plenty of Wi-Fi bandwidth, I certainly would welcome accessibility from indoors. How about you? Would you take a cell phone with a zero-minute plan?

Rafal Milecki is reworking the backlight device class. Apparently, tons of strange configurations are cropping up, where laptops have multiple monitors attached in different ways, and the current code is just not cutting it anymore. He's been considering how best to rewrite the whole thing. Henrique de Moraes Holschuh also is very interested in the idea of doing this, and the two of them seem to be getting into it together. Richard Purdie, the current backlight code maintainer, so far is not involved, but it's clear that some changes are coming soon to the whole backlight device class.

GPL violations can be difficult to track down, because the violators often release only binary versions of the software. But, Gerhard Wiesinger felt he'd uncovered a violation in VMware's ESX server. VMware's own documentation apparently reported that some of its drivers had been based on versions of Linux drivers that had to have been under the GPL at the time VMware based its work on them. And, because the drivers were statically linked with the ESX server, Gerhard felt that this meant the entire ESX server was bound to the GPL and had to be released under its provisions. The truth of the matter isn't yet known, and accusations aren't proof. But, it's good to take note of these potential issues as they come up.

Sam Ravnborg no longer is maintaining kbuild. He handed maintainership off to Michal Marek, who seems very excited to get started with it. One of the first things to happen after the announcement was that Arkadiusz Miskiewicz reported a problem with color no longer being displayed in the kbuild menus. Under Michal's new leadership, Nir Tzachar tackled the problem and uncovered its vile roots. Best of luck to Michal and the rest of them on advancing kbuild.

Joe Moo (his real name's Paul) has started a new SourceForge project to help users test the latest Linux kernel patches. The SourceForge page is sourceforge.net/projects/thelinuxtesters. The kernels that get the most testing, of course, are the official releases—those 2.6.36, 2.6.37 and other kernels that Linus Torvalds puts out once in a while. Even more valuable to Linux kernel stability, however, would be for more people to test the current working version of Linus' tree—the code at the very tip of the git repository at any given time. Joe's project tries to make it easier for people in general to do that.

The ReiserFS code has been so filled with the big kernel lock, that Frédéric Weisbecker had to create his own git repository just to deal with rooting out all occurrences of the BKL in ReiserFS and destroying them. Linus Torvalds recently asked about the status of that, and Ingo Molnar said Frédéric had been creating a huge dust vortex around his workstation, yanking BKL after BKL out of the code with his bare hands! Thomas Gleixner also had been monitoring and reviewing Frédéric's work, and Frédéric also announced that very, very soon Linus would get a pull request that would carry all the BKL-yanking into the official tree.

Windows users expect an installer program when they get new software. But, creating a full-featured installer could end up taking more time than your application did. Fortunately though, creating installers is largely an automated task on Windows these days, as there are numerous tools to assist you in creating a GUI installer for your application. One of them is the Nullsoft Scriptable Install System (NSIS). NSIS was developed by Nullsoft, the developers of the Winamp media player. NSIS is free and open-source software.

NSIS installers are built from installer scripts. These scripts control the actions of the installer when it is run. The scripts allow the developer to create sophisticated installers that can deal with complex installation tasks, such as handling upgrades differently based on the already-installed version. NSIS includes a plugin system that allows the installer to be customized to include custom steps and interfaces. Plugins can be written in languages that can produce a Windows DLL.

Once the installer scripts are ready, they are compiled with the NSIS compiler, and an installation program is created. One of the nice features of NSIS is that the script compiler can be built and run on any POSIX-compliant platform (such as Linux, BSD and UNIX), allowing you to build your installer on a system you actually like using.

NSIS is actively maintained, well documented, and it runs on all modern versions of Windows (from Windows 95 on). The latest release at the time of this writing is NSIS version 2.46.

NSIS Installer for Winamp

Although my intent is not to start the next GNOME/KDE-level war, it seems there must be a happy medium between total desktop insecurity and total desktop unusability. Linux offers so many ways to secure data that it's important to realize it's okay for folks to have different needs and desires. Sure, there are some basic security measures we all should take—things like:

Apart from that, and I'm sure a few other common-sense practices, security is different for different users and different situations. Take the password scenario—it's very good to have a complex password. But, if your screensaver kicks on every three minutes of inactivity and requires you to type that complex password, your security measures have taken you hostage.

Now before I get hate mail (you know who you are, you've likely already started an e-mail to me), let me assure you, I'm not advocating insecure computer practices. What I am advocating is freedom. If I want my laptop to auto-log in, and not lock the screen with the screensaver, as long as it's only my data being exposed, it should be okay. Sadly, when it comes to freedom, we need to let people have the freedom to do dumb things too. And now if you'll excuse me, I need to try to remember my luggage combination, “1, 2, 3, 4, 5...”.

The nice thing about standards is that there are so many to choose from.

—Andrew S. Tanenbaum

Where is all the knowledge we lost with information?

—T.S. Elliot

For years there has been a theory that millions of monkeys typing at random on millions of typewriters would reproduce the entire works of Shakespeare. The Internet has proven this theory to be untrue.

—Anonymous

Computers make it easier to do a lot of things, but most of the things they make it easier to do don't need to be done.

—Andy Rooney

In the old days, people robbed stagecoaches and knocked off armored trucks. Now they're knocking off servers.

—Richard Power

If you have any trouble sounding condescending, find a UNIX user to show you how it's done.

—Scott Adams

You may have noticed something a little different about your favorite on-line destination. We've made a major overhaul and invite you to make yourself at home and try out the new features. We encourage you to create a user account if you haven't already. Logged-in users can keep track of all their favorite articles, connect with other readers and editors, and participate in our growing on-line community.

You'll find all the same great articles, blogs and videos, and we hope you enjoy the new look and layout. Additionally, look for new features to be added throughout the year. If you use Linux, LinuxJournal.com should be your home page.

See you on the interwebs!

Software development, and particularly open-source software development, attracts men more often than women. The FLOSS Project has conducted some interesting studies related to gender and open-source software:

Here, my goal is not to explain or solve the problem, but instead to talk with three women who are active in open-source development.

AB: Could you please introduce yourselves?

SS: I'm Sarah Sharp, the maintainer for the Linux kernel driver for USB 3.0 host controllers. I work with the Linux USB kernel developers and other Linux developers in Intel's Open Source Technology Center.

SP: I'm Stormy Peters, the Executive Director of the GNOME Foundation. The GNOME Foundation exists to help the GNOME Project fulfill its mission of a free desktop accessible to everyone.

VA: I'm Valerie Aurora, the filesystems developer at Red Hat, consultant and sometimes a writer.

AB: Do you remember the very first time when you heard about Linux and your first experience with it?

SP: I don't remember when I first heard about Linux. I think it was probably around 1996. I do remember when I first heard about Web browsers—I said it sounded like a waste of time. I said the same thing about Twitter. Now I use them both every day and find them very useful.

I actually was more interested in GNOME than Linux. I worked in the HP-UX lab and was looking at seeing whether we could put GNOME on HP-UX. This was an intentional move from CDE to a more-featured GNOME. Later, I helped start the Linux lab at HP.

SS: My boyfriend Jamey was the first one to introduce me to Linux. We were both university students at the time. I was taking a C programming class, and we had to compile our work with gcc on a Linux system. There were Linux computers on campus, but I wanted to work on my projects from home. I tried using the instructor's directions for SSHing into a box, but the SSH client I was using didn't handle scroll back properly. My boyfriend told me I could install Cygwin on Windows and walked me though installing it. I finally got tired of Cygwin, and he convinced me to dual-boot my computer with Debian Linux.

I do remember asking Jamey a lot of questions and eventually trying to Google for answers in order to learn things independently.

VA: My first experience with Linux was a long time ago! Around 1996, my university started installing Slackware on most of the fast new i386 PCs in the computer lab. I really liked Linux, in part because our previous UNIX machines were Sun pizza boxes running SunOS 4.1.4, and the i386 blew them out of the water. They also didn't have that distinctive annoying hard-disk whine that the Sun boxes had. I used Linux to read e-mail, write programs and browse the Web. I spent a lot of time customizing my window manager.

Valerie Aurora

Sarah Sharp

Stormy Peters

AB: Do you agree with the statement that universities (scientific institutions) are the best places to be a cradle for technology, like Linux, and eventually promoters of it?

SP: I do remember being very jealous of today's college students who can carry Linux on a laptop back to their dorm rooms. I had to walk across campus to use the Solaris systems we learned on, and nobody could afford one of their own.

I do think universities are a good place to promote and encourage free software, including Linux. Students look for low cost and good solutions. They then take what they learn to their workplaces.

SS: I believe that universities and colleges are a good place to introduce people to Linux development, but you have to start much younger to introduce people to using Linux. I would love to see programs to get middle-school-aged girls into using Linux and programming small projects or even just installing Linux on older boxes. See creativity-online.com/news/little-girls-get-their-hands-on-arduino/136751 and www.gnomejournal.org/article/88/the-un-scary-screwdriver.

VA: What I do think is that having universities involved in open-source development is excellent for their computer science students' job prospects, and it increases open-source development significantly. In my case, I learned how to develop Linux and open source at my university, New Mexico Tech. I graduated from the university already knowing how to download open-source code, compile it and modify it. Our computer science department as a whole developed some significant portions of the Linux kernel. Working with open source was a key part of my class work every semester, and I can't think of any other way than university support for open source to get four years of experience working on open source before graduating.

What is shocking to me is how seldom university computer science programs take advantage of this opportunity to teach and train students at the same time. I can't believe how often professors teach operating systems with a “teaching OS” instead of Linux or use some proprietary IDE that abstracts away the practical side of programming. As far as I can tell, it is all about the personal preferences of individual professors, and it is a matter of luck whether you get a professor who uses open source.

AB: Can women bring an inspiring atmosphere that positively influences productivity in the workplace?

SP: I think where you work and the atmosphere around you contributes greatly to how happy you are and then to how productive you are. I wouldn't say that only women bring this atmosphere, but rather they bring that diversity in general.

AB: How often do you hear men saying something like: “Wow, you're familiar with Linux! That's great!”?

SS: Are you asking me if males find it surprising that I use Linux? I think males are more surprised when I'm not in a techie group.

SP: Hmm. I'm much more likely to get “GNOME, Linux, what's that?” I used to get “you don't look like a computer person!” I hated that one—especially when they told me that was a compliment.

AB: Do you think this reaction was caused by a computer industry stereotype—only by men and for men?

SP: Absolutely it was caused by a stereotype. And, instead of feeling like a compliment it felt like they were limiting me.

AB: In your opinion, does the Linux community suffer from a lack of women-contributors?

VA: I have been involved in the Linux community at one level or another for about ten years now and have thought a lot about why women stay away from and/or leave Linux development. One thing I am sure about is that the Linux community suffers from a leak of people who don't want to work in an incredibly hostile environment. Leaving aside arguments about genetically based differences in male and female personalities, men are trained and encouraged to hold their own in aggressive, adversarial and argumentative situations, and women are discouraged from the same. (I was personally trained to be more assertive and challenging than most women, but it's still not a pleasant experience, to say the least.)

In the end, the Linux development culture is heavily biased toward people who thrive on conflict. A widely held belief is that the adversarial culture results in higher-quality software, but that sounds a little bit like rationalization to me.

AB: How do we attract more women to contribute?

SS: So many people have opinions on this. Most of them boil down to this: don't be a jerk. Stop allowing sexist/racist comments on IRC, e-mail or in conference presentations. Criticize the code, not the person. Women really want to get their first submissions “right” the first time, and are discouraged when they don't know everything. I've found it was really good to have a mentor I could trust with my emotions to review code before sending it to a public mailing list. Perhaps a group of women could step up to review code or be mentors for new developers. It's a difficult problem to solve, and I don't think there is one big solution to this.

SP: I think it's best solved by encouraging more women to join through mentors, programs directed at women and general awareness and encouragement in the forums where the community congregates. I think the Free and Open Source community would benefit from women in the community—not only would it add diversity but also twice as many developers! Women would benefit from having more career options—a really fun and rewarding one.

Image credits: Jiang Jiang (BeiJing).