Getting users to try Linux is only half the battle. The other half is showing them what they can achieve when using it. Linux Made Easy by Rickford Grant uses a task based approach to show how you can use Linux to perform your daily tasks; email, browsing, letter writing, even scanning and printing are covered in detail. I spoke to Rickford Grant about the book, why he chose Xandros and how the look and feel of the computing environment are more important to acceptance than the name on the box.

The book highlights how easy it is to do your everyday tasks - email, writing letters, scanning documents - using Linux. How key do you think this is to the wider adoption of Linux?

I can’t help but think that it is extremely important. Until now, the image of Linux has been of a system for people on the geekier side of the compu-user spectrum, and I’d say the majority of books out there on the subject bear this out with their focus on networks, commands, and so on.

One of the reasons I wrote my first book, ‘Linux for Non-Geeks,’ and now ‘Linux Made Easy,’ was that most of the Linux books out there are so focused on that more geekish facet of Linux that it was hard to imagine a mere mortal having any reason to use Linux, let alone being able to do so. They certainly had that effect on me when I first got started.

As it stands now, the people who use Linux for its usefulness in specific applications, or who are in fact geeks, are, for the most part, already in the Linux fray. That being the case, if you are talking abut expanding the user base, then you are talking about business folks and your typical average Windows or Mac home users. If you want to attract those people, especially the latter group, then it is going to have to be clear to them that Linux is just as point-and-click sweet as whichever system it is they are considering abandoning in its favor.

This is where I see books, such as mine, focusing on those ‘everyday tasks’ you mention, as being of great benefit in expanding the Linux user base, or at least that segment of it.

Why Xandros? Are any of the other distributions you would recommend?

I picked Xandros because it seemed so very simple to deal with from installation of the system itself to installing additional applications. If someone wanted to keep their Windows system and create a dual boot setup, that was easy too. It also seems to handle odd hardware configurations pretty well.

Of course, there are some other good distros out there, but each of them has a limitation or two that I see as potentially problematic for a true newbie who, while interested in getting out of the Windows world, is not particularly interested enough in Linux per se to start geeking around in order to use it. Fedora Core and Mandrake/Mandriva, for example, are fine distros in their own right, but they have a few points that the target audience for my book might not care to bother with.

I hear good things about Ubuntu too, but I haven’t tried it myself yet, and I am sure that the non-graphical installer I hear it has will scare some folks away. After all, one of the big shocks to Windows users the first time they actually install Windows themselves (since most people get it pre-installed when the buy their computers) is that the installation process isn’t a completely graphical experience, nor is it an exceptionally easy one. I’d actually go so far as to say that most of the good Linux installers are far easier to deal with than that for Windows, and I have to say that the Xandros installer is about as easy as they come.

Do you think the wide range of distributions is a limitation of wider adoption, because it confuses new users, or they make the wrong decision and get scared off?

It’s hard to say, as it can actually work both ways. I know when I started out with Linux, I tried a few distros without any success. That acted to turn me off the idea of trying any further - for a while, anyway.

Part of the problem might just have been in the timing, in that Linux was not really all that non-geek friendly in the old days. After some time, when I finally did get my first distro up and running off one of those live CDs (Knoppix was the one, to be exact), I was then delighted that there were so many other varieties out there for me to move on to. I could just keep plugging away until I found one or two that I thought did the trick for me – sort of looking for the perfect pair of shoes for a person with big feet (size 13, if you’re interested).

The fact that there are so many distros out there allows users to escape the one-size-fits-all world that exists for other operating systems. Users can pick a distro that fits their needs best according to whatever criteria they may have. Of course, not everyone is interested in going through that diddle-and-dump process, which could be viewed as a negative. Fortunately, however, these days there are a lot of distros available that are pretty easy to deal with and can thus be recommended to those with less of an experimental bent.

Where do you think CD solutions, such as Knoppix fit into the role of encouraging more Linux users?

Well, as I just mentioned, Knoppix certainly did the trick for me. Unfortunately, not all of these CD solutions are created equal, and I had quite a few that refused to cooperate. They also run a bit slower than the real thing, and that can act to turn some folks off no matter how many times you tell them that it’s slow because it’s being run from CD. First impressions and all, you know.

Still, I think that the pros win out over the cons in terms of turning people on to Linux, as these live-CD distros allow people to get a feel for how normal and absolutely graphical Linux is without their having to fear ruining their Windows system – a sort of safe-and-sane way to give it all a try.

There’s been a lot of discussion about the usability of Linux on the desktop in comparison to Windows. Do you feel that the major hurdles to making Linux easier to use have been overcome?

I really do think so. I don’t see how Linux is any more difficult than Windows in terms of typical home or office tasks. In fact, in many ways, especially in terms of settings and such, I think it is definitely easier. Same with the actual installation process with most distros. Oh, but I’ve already mentioned that.

Are there any gaps in the Linux sphere for desktop users? For example, does Linux work as an effective replacement for mobile as well as desktop users?

There are a few gaps, but for the most part, they don’t have a major effect on most users. One of these gaps, of course, would be a lack of easy support for certain MS specific formats, such as streaming media designed for Windows Media Player. Users cannot, for example, go to MSNBC, click one of the video links there, and watch it. At least, they can’t do it without some tinkering.

There is also the problem of peripherals. Linux has to play a game of catch up when it comes to drivers for new devices, and thus it takes a while before support for such devices makes it to Linux. While this isn’t a problem for most people, it can be for those folks who like to go to the computer store, buy whatever odd device they happen to see on the shelf, and then use it. Users have to be a bit more concerned with hardware support than they do with Windows. Mac users might be a bit more familiar with the problem.

There is also the desire by the entities behind many distros to keep things as Open Source as possible, and to avoid any possible licensing violations, which is all quite reasonable. Unfortunately, the reason for all this is lost on end users. All they can see is that things such as MP3 support and encrypted DVD playback support are lacking in many distros, which can act as a turn off for some.

One of the key points about the book for me was that you spend all but one of the chapters working in KDE and GUI apps, rather than dropping to the ‘complex’ command line. Was this a key target of the book - showing just how use friendly Linux could be at all levels?

Yes. Those moving into Linux from Windows or Mac OS… or complete compu-newbies, for that matter, are sure to see commands as offputting and archaic. In fact, I was considering excluding that chapter altogether, but then I figured it had its uses in regard to JAVA apps and installing support for encrypted DVDs. Commands also give some folks the feeling that they are really ‘using’ a computer. Other than that, however, there isn’t really much call to resort to the command line, at least not in Xandros – or at least for the targeted audience of the book.

I have nothing against using commands personally, but they can really act to scare newbies away. And, after all, if you don’t really need them, why bother. That said, I thought it best to keep my discussion of the command line limited and to keep it last.

I get the feeling that you were scratching a particular itch with this book. Did you have a specific person in mind when writing it?

Yes, my long-time friend Steve in Los Angeles. He read my first book, was definitely interested, but ultimately not all that interested in going through the motions required to set up his own Linux system. I realized that while Linux for Non-Geeks was really a book for people interested in getting into Linux easily, there were still others who didn’t care all that much about Linux per se, and instead just wanted a really easy way out of the costlier Windows world. Xandros struck me as an ideal candidate for such people, and thus that is the audience towards whom I targeted Linux Made Easy.

I also tried to address some of his specific concerns, as well as others voiced in Amazon.com reader reviews and other such venues for my first book. The result is more coverage of how to do things with the various applications available in Xandros (and most other distros, for that matter).

It also seemed that a lot of people, once they have all these great pieces of software on their machine, have no idea of what they might use them for. I thus included some projects that readers can work through, which, in addition to showing them how to use the various apps, also serve to give people some idea of what they might consider doing with them. OpenOffice Draw is a good example. Lot’s of people can’t see any particular need for it, but I try to show them how to use it as a simple page layout application. I also try to provide greater coverage on how to deal with the more common varieties of peripheral devices.

Linux Made Easy strikes me as the sort of book that IT pros should keep on a shelf for distribution at will to users asking ‘do you think I should switch to Linux?’ Is that an example of where you’d like to see the book being used?

Well, as the author of the book, I’d like to see it on every shelf from Scunthorpe to Singapore, but, yes, that would be a good example of where it would be very useful. A pro could just hand it to an interested party to let them see that Linux needn’t be some mysterious freakish system out of the reach of the common man. I think it would work well as a text for workshops and the like too. And of course, I would hope that it would be something that would appeal to someone browsing the shelves at the bookstore.

Are you an exclusive Linux user?

Yes - well, almost. I do have one machine set up as a Windows/Linux dual-booter. I use the Windows side of that for basically two things: 1. to check things I need to refer to when writing these Linux how-to books, and 2. to play my favorite game – the Austrian card game, Schnapsen, which has yet to be ported over to Linux. I’m still crossing my fingers on that one.

Anything else emanating from your keyboard that we should know about?

I have all sorts of projects started, but I’m not sure which I will follow through with straight off. I suppose it depends on what publishers are willing to print. I am currently working on a newbie-friendly command book and thinking of an update to Linux for Non-Geeks, to name a couple of things. It’s hard to say what those will actually end up as though, in that things sometimes morph into totally different end products. I am also always working on a Japan experience book, but that is another ball of wax altogether.

Do you have a favourite author?

Wolfgang Hildesheimer has been a long-time fave, but then I suppose you’re talking about computer book authors, aren’t you? In terms of computer books, I don’t have a particular author that I would call a fave, but there are a lot of books that I think are rather good. As far as Linux books go, I think ‘Linux in a Nutshell’ and ‘How Linux Works’ are well worth having, though I wouldn’t necessarily recommend them for newbies.

Author Bio

Rickford Grant, author of Linux for Non-Geeks, has been a computer operating system maniac for more than 20 years, from his early days with an Atari XL600 to his current Linux machines. Grant spent the past seven years as an Associate Professor at Toyama University of International Studies in Japan before relocating to Wilmington, North Carolina

Linux Made Easy by Rickford Grant is a companion to his original Linux for Non-geeks. Where the two differ is that this book is about how easy Linux can be for performing a myriad of tasks using a simple, skill-based approach. In this book, Rickford describes how to use Linux to do what you need to do: web browsing, sending email, basic document creation and using external peripherals like your printer, USB flash drive and scanner. In short, this book is about using Linux, from the perspective of ‘Your Average Joe’.

The book covers, and indeed includes, Xandros Open Circulation Edition, a Debian based distribution that just happens to include a number of key components for the target market, including OpenOffice, a key part of the toolkit required by many users to provide word processing and spreadsheet facilities.

The contents

In consideration of the target audience the book is a meaty, but not imposing, 450 pages making it look both substantial enough to keep potential readers interested and yet not so large as to make them think twice about buying a ‘professional’ book.

The book starts off with the usual background to Linux and some considerations before moving straight on to the installation of Linux on your machine. Individual steps are split into ‘projects’, so in the installation chapter we have projects for booting your machine, creating a boot disk and the actual installation. Consideration is even giving for retaining your Windows partition in the process. Each project is a combination of discussion of what you are about to do, followed by a very detailed step-by-step account of the process, and then some follow up notes and information. To round off the first part, we get a quick introduction to the main parts of your new operating system.

By Part II we start getting in to the meat of the operating system, first looking at how to connect to the Internet (a required step in the modern computing world) before moving on to basic file management, removable media and finally the control and customization options available through the Xandros Command Center and finally how to keep your machine up to date through the Xandros network.

The next section concentrates more on using your machine for those day to day tasks, including printing, scanning, and connecting your digital camera and PDA. There’s lots of information here, from getting the equipment talking (including what to do when it doesn’t want to), through to actually scanning images, exchanging photos and PDA data. By the end of this section you should be up to speed in terms of duplicating the basic set up of a Windows environment and ready to start working and using your Xandros installation.

Part IV is all about typical applications and projects; listening to CDs, browsing the Internet and sending email, using OpenOffice and other day-to-day tasks. As with the rest of the book, there’s more here than you will find through a casual glance. The chapter on OpenOffice for example doesn’t just tell you how to open the various applications; you also get information on using them. Basic spreadsheet mechanics, including formulas and referencing cells make up one of the projects. Although switchers may already know, it’s nice to see that the book covers more than just the ‘’use this application for that task’ approach.

By the end of the book, and Part V, we are into the material which the book itself acknowledges is geeky: the command line. Although it contains the usual range of command line utilities and handy hints for making the best of a shell, it’s interesting to note that the previous 19 chapters have been entirely based on using the X Windows interface and KDE. Again, this simply helps to show that Linux is a credible alternative to Windows and that you don’t have to be a geek to use it.

Pros

Throughout, Rickford’s writing style is free and easy flowing. Despite the heavy step-by-step approach, you never feel like you are being treated like an idiot. Rickford assumes readers are going to be proficient in using a computer, just not proficient in Linux. To add to the lighter feel, chapters have interesting titles and subtitles and there’s a lot of humor in the book. This in turn makes the book incredibly easy to read while containing a lot of information. Even for a long-time Linux user there’s a lot that can be learned from the book.

The choice and range of topics is also a massive bonus. This book is aimed entirely, and squarely, at those people who want to try Linux, not with the aim of simply toying with it, but with the specific aim of actually using it to do your day-to-day tasks.

There’s a surprising chapter on Linux gaming which only covers the standard games provided as part of Xandros, but it helps to show to people that Linux is more than just an Internet and business application machine and really can be used as a full time replacement for Windows.

Cons

To be honest, there really isn’t a great deal to work on when it comes to problems with the book. There are a few formatting and stylistic issues, but nothing major. Just occasionally there are just a few too many screenshots and those provided seem superfluous, but for a user new to Linux these additional screens would be reassuring, rather than annoying.

Recommendation

This book is not for people already familiar with Linux, but it is a book that could easily be distributed to new users. Overall, the book would be an ideal item to keep on the shelf and hand over to the next person who asks you what to do when they get fed up of Windows. In fact, I’m tempted to keep piles of the book for just this purpose.

Apache has been a stalwart of the Internet for some time. Not only is it well known as a web serving platform, but it also forms a key part of the LAMP (Linux-Apache-MySQL-Perl/Python/PHP) and is one of the best known open source projects. Getting an Apache installation right though can be tricky. In Pro Apache, Peter Wainwright hopes to help readers by using a task, rather than feature based, approach. I spoke to Peter about Apache, its supported platforms, the competition from IIS and his approach to writing such a mammoth tome.

Inflammatory questions first – Unix or Windows for Apache?

Unix. To be more precise, BSD, then Linux, then almost anything else (e.g., commercial Unixes), then Windows — if you must.

The usual technical arguments and security statistics against using Windows are readily available from a number of sources, so let me give a rather different perspective: it seems Microsoft was in discussion to buy Claria, creators of Gator (one of the more annoying strains of adware that infest Windows desktops). Coincidentally, Microsoft’s beta ‘AntiSpyware’ tool recently downgraded Claria’s products from quarantine to ignore. It seems that the deal fell through, but for reasons of bad PR rather than any concern for the customer. Call me cynical if you like, but I see little reason to place my faith in a closed-source operating system when the vendor is apparently willing to compromise the security of its customers for its own business purposes. Yes, plenty of us already knew that, but this is an example even non-technical business managers can grasp.

Having said that, yes, there are reasons why you might be required or find it otherwise preferable to run Apache on a Windows server. For example, you might need make use of a Windows-specific module or extension. Apache on Windows is perfectly viable – but given a free choice, go the open source route.

Do you prefer the text-based configuration, or the GUI based configuration tools?

Text-based every time. I don’t object to the use of a GUI outright, but if I can’t easily understand the generated configuration files by direct inspection afterwards, or can’t modify the configuration without upsetting the tool, I’ve just built a needless dependency on a tool when I would have been better off maintaining the text-based configuration directly. Using a tool not a substitute for understanding the underlying configuration.

Too many administrators, I think, use the default configuration file without considering whether it might be better to create a much simpler and more maintainable configuration from scratch. I find an effective strategy for maintaining an Apache configuration is to divide it into several simple configuration files according to function – virtual hosting, access control, SSL, proxies, and so on – and then include them into one master configuration file. If you know what your website (or websites) will be doing, you can configure only those features. A simpler configuration, in turn, generally means fewer security issues to deal with.

The default configuration file, if I make use of it at all, becomes just one of the files included into the master configuration file that takes its place. Customisations go into go into their own or files and override the defaults as necessary. This makes it very easy to see what configuration came pre-supplied and what was applied locally. It also it easy to update the default configuration as new releases of Apache come out, because there are no modifications in the file to carry across.

Can you suggest any quick ways to improve performance for a static site?

There are two main strategies for performance-tuning a server for the delivery of static content: finding ways to deliver the content as efficiently as possible, and not delivering the content at all, where possible. But before embarking on a long session of tweaking, first determine whether the load on the server or the available bandwidth is the bottleneck. There’s no point tuning the server if it’s the volume of data traffic that’s limiting performance.

Simple static content performance can be improved in Apache by employing tricks like memory-mapping static files or by caching file handles and employing the operating system’s sendfile mechanism (the same trick employed by kernel HTTP servers) to efficiently transfer static data to the client. Modules like Apache 1.3’s mod_mmap_static and Apache 2’s mod_file_cache make this easy to configure.

At the platform level, many operating systems provide features and defaults out of the box that are not useful for a dedicated webserver. Removing these can benefit performance at no cost and often improve security at the same time. For instance, always shut down the mail service if the server handles no mail. Other server performance improvements can be gained by reducing the amount of information written to log files, or disabling them entirely, or disabling last access-time updates (the noatime mount option for most Unix filesystems).

If the limiting factor is bandwidth, look to trade machine resources to reduce throughput with strategies like compressing server responses with mod_gzip. Also consider the simple but often-overlooked trick of reducing the bytesize of images (which compression generally won’t help with) that Apache is serving.

Arranging not to deliver the content can actually be easier, and this reduces both server loading and bandwidth usage. Decide how often the static content will change over time, then set configure caching and expiration headers with mod_cache (mod_proxy for Apache 1.3) and mod_expires, so that downstream proxies will deliver content instead of the server as often as possible.

To really understand how to do this well, there is no substitute for an understanding HTTP and the features that it provides. RFC2616, which defines HTTP 1.1, is concise and actually quite readable as RFCs go, so I recommend that all web server administrators have a copy on hand (get it from www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf). That said, it is easy to set expiry criteria for different classes of data and different parts of a site even without a firm understanding of the machinery that makes it work. Doing so will enable the site to offload content delivery to proxies wherever possible. For example, tell proxies that all (or most) of the site’s images are static and can be cached, but the text can change and should never be cached. It may happen that most of the text is also static, but since images are generally far larger, marking them as static provides immediate benefits with a very small amount of configuration.

Security is a key issue. What are the main issues to consider with Apache?

Effective security starts with describing the desired services and behaviour of the server (which means both Apache and the hardware it is running on). Once you know that, it is much easier to control what you don’t want the server to do. It’s hard to protect a server from unwanted attention when you don’t have a clear idea of what kinds of attention is wanted.

I find it useful to consider security from two standpoints, which are also reflected in the book by having separate chapters. First is securing Apache itself. This includes not only the security-specific modules that implement the desired security policies of the server, but also the various Apache features and directives that have (sometimes non-intuitive) security implications. By knowing what features are required, you can remove the modules you don’t need.

Second, but no less important, is securing the server that Apache is running on. The security checklist in Pro Apache attempts to address the main issues with server security in a reasonably concise way, to give administrators something to start from and get them thinking in the right direction. One that’s worth highlighting is ‘Have an Effective Backup and Restore Process’ — it’s vital to know how to get your server back to a known state after a break-in, and being able to do so quickly will also stand you in good stead if a calamity entirely unrelated to security occurs, like a hard disc failure or the server catching fire (this actually happened to me). The ssh and rsync tools are very effective for making secure network backups and restores. They are readily available and already installed on most Unixes, so there’s no reason not to have this angle covered.

With the increased use of dynamic sites using PHP and Perl, how important and useful are functions like SSIs and rewriting which is built into Apache?

When designing a web application, use the right tool for each part of the job. Apache is good at handling connectivity and HTTP-level operations, so abstract these details from the application as far as possible. Rewriting URLs, which are simply one kind of many kinds of request mapping, are just an aspect of this. Similarly, don’t make a web application handle all its own security. Use Apache to handle security up front as much as possible, because it is expert at that, and if used properly will prevent insecure or malicious requests from reaching the application. Unfortunately, rather too many web application developers don’t really understand web protocols like HTTP and so build logic into the application that properly belongs in the server. That makes it more likely that a malicious request can find a weakness in the application and exploit it. It also means the application designers are not making use of Apache to its fullest potential.

Bear in mind that it is possible, with scripting modules like mod_perl, to plug handlers into different parts of the request-response cycle. Clever use of this ability allows a flexible modular design that is easier to adapt and less likely to create hidden security issues. Apache 2 also provides new and interesting ways to construct web applications in a modular fashion using filters. These features are very powerful, so don’t be afraid to exploit them.

I’ll admit to a fondness for Server Side Includes (SSIs). Even though they have been largely superseded by more advanced technologies, they are easy to use and allow for simple templating of static and dynamic content. Apache’s mod_include also knows how to intelligently cache static includes, so SSI-based pages are a lot faster than their basic mechanic would suggest, and without requiring any complex configuration. They’re a good choice for sites that have a lot of static content and need to incorporate a few dynamic elements.

Apache is facing an increasing amount of competition from Microsoft’s IIS, especially with the improvements in IIS 6.0. Ignoring the cost implications, what are the main benefits of Apache over IIS?

Trust. One of the reasons that Apache is a reliable, secure, and high-performance web server is because the Apache developers have them as end objectives. They’re not trying to sell you something. Having total flexibility to add or remove features, or inspect and modify the code if necessary, are almost bonuses by comparison.

On a more technical note, an Apache-based solution is of course readily portable to other platforms, which ties into the choice of platform we started out with. Although there are always exceptions, if you think there’s a feature that IIS provides that Apache cannot — bearing in mind you can always run Apache on Windows — chances are you haven’t looked hard enough.

Pro Apache is a mammoth title — where do you start with something as complex with Apache?

Too many books on computing subjects tend to orient themselves around the features of a language or application, rather than the problems that people actually face, which is not much help if you don’t already have some idea what the answer is in order to look it up. I try hard in Pro Apache to start with the problems, and then illustrate the various directives and configuration possibilities in terms of different solutions to those problems.

Even though there are a bewildering number of directives available, many of them are complimentary, or alternatives to each other, or are different implementations of the same basic idea. For example, take the various aliasing and redirection directives, all of which are essentially variations on the same basic theme even if they come from different modules (chiefly, but not exclusively, mod_alias and mod_rewrite). Understanding how different configuration choices relate to each other makes it easier to understand how to actually use them to solve problems in general terms. A list of recipes doesn’t provide the reader with the ability to adapt solutions to fit their own particular circumstances.

I also try to present several different solutions to the same problem in the same place, or where that wasn’t practical, provide pointers to alternative or complimentary approaches in other chapters. There’s usually more than one way to achieve a given result, and it is pretty unlikely, for example, that an administrator trying to control access through directives like BrowserMatch and RewriteRule will discover that the SSLRequire is actually a general-purpose access control directive that could be the perfect solution to their problem. (SSLRequire is my favourite ’secret’ directive, because no one thinks to find a directive for arbitrary access control in an SSL module.)

Since many administrators are still happily using Apache 1.3, or have yet to migrate, the updates made to the first edition of Pro Apache (then called Professional Apache and published by Wrox) to cover Apache 2.0 do not separate coverage of the 1.3 and 2.X releases except where they genuinely diverge. The two versions are vastly more similar than they are different — at least from the point of view of an administrator — and in order to be able to migrate a configuration or understand the impact of attempting to do so, it was important to keep descriptions of the differences between the two servers tightly focused. To do this, coverage of the same feature under 1.3 way and 2.X are presented on the same page wherever possible.

It seems unlikely considering the quality of the content, but was there anything you would have liked to include in the book but couldn’t squeeze in?

With a tool as flexible as Apache, there are always more problems to solve and ways to solve them than there is space to cover, but for the most part I am very happy with the coverage the book provides. Judging by the emails I have received, many people seem to agree. If there’s anything that would have been nice to cover, it would probably be some of the more useful and inventive of the many third-party modules. A few of the more important, like mod_perl, are covered by the last chapter, but there are many so many creative uses to which Apache has been put that there will always be something there wasn’t the space or time to include.

What do you do to relax?

Strangely enough, even though I spend most of my working time at a computer, I’ve found that playing the odd computer game helps me wind down after a long day. I think it helps shut down the parts of my brain that are still trying to work by making them do something creative, but deliberately non-constructive. I recommend this strategy to others too, by the way; board games, or anything similar, work too.

To truly relax, I’ve found that the only truly effective technique is to go somewhere where I don’t have access to email, and determinedly avoid networks of any kind. I suspect this will cease to work as soon as mesh networks truly take hold, but for now it’s still the best option. It also helps that I have a wonderful, supportive wife.

What are you working on next?

Right now I’m gainfully employed and wielding a great deal of Perl at some interesting problems to do with software construction in the C and C++ arena. There’s been some suggestion that a book might be popular in this area, so I’m toying with that idea. I also maintain an involvement in commercial space activities, specifically space tourism, which has recently got a lot more popular in the public imagination (and about time too, some of us would say). That keeps me busy in several ways, the most obvious of which is the ongoing maintenance the Space Future website at www.spacefuture.com.

Author Bio

Peter Wainwright is a developer and software engineer specializing in Perl, Apache, and other open-source projects. He got his first taste of programming on a BBC Micro and gained most of his early programming experience writing applications in C on Solaris. He then discovered Linux, shortly followed by Perl and Apache, and has been happily programming there ever since.

When he is not engaged in development or writing books, Wainwright spends much of his free time maintaining the Space Future website at www.spacefuture.com. He is an active proponent of commercial passenger space travel and cofounded Space Future Consulting, an international space tourism consultancy firm.