Book Review: Beginning Ubuntu Linux Third Edition

Ubuntu and desktop Linux have come a long way in the past few years. Ubuntu is currently one of the most popular, if not the most popular distro for desktop linux users. It was my first distro and though I no longer use it, I’ve always acknowledged to be a well-polished piece of work and I always recommend it to people who are just starting on their personal Linux journey. Like most other things in computers, getting used to a new operating system is made easier if there is a good source of documentation available. Beginning Ubuntu Linux, published by Apress is a particularly good example of documentation geared towards to the new user. I’ve reviewed the previous versions of the book and I find that the books have kept improving just Ubuntu itself.

One of the things that makes this book particularly appealing for me is that it starts out with a brief but informative review of the philosophy and history surrounding Linux and Ubuntu. I personally believe (and I think that many other Linux users share this) that there is much more to Linux and open source software than simple technical excellence. It is a way of thinking and acting that I find very appealing and which I wish others to understand. This book does its part in helping new users understand the culture that gave rise to the software that they will soon be using.

The book continues the practice of understanding that most of the people reading it will be Windows users. As a result the chapters dealing with installation also tell users how to properly back up their data and how to smoothen the transition. The guide through the actual installation process is also very in-depth and well written. Partitioning is often the most confusing part of the installation for a new user. I’m glad to see that partitioning has been dealt with very well with all the options in the install process carefully explained and the pros and cons weighed carefully. The chapter dealing with common installation problems is as good as before but now includes information on more than just installation problems. I particularly liked the section on how to deal with resolution and other common graphics problems since these can be very frustrating if not dealt with properly.

Once installation is complete the book goes on to describe with an equal amount of care how to perform various day to day tasks and how to customize your system. The section that deals with Linux equivalents is also comes in very handy for new users who just want to be pointed quickly in the right direction. The book geos beyond describing simply the core operating system and the user interfaces. Of particular note are the sections devoted to how to use multimedia systems. You’d be hard-pressed to find a computer user who doesn’t have a substantial collection of various music and video files and this book helps newbies get up and running with minimal effort. This new edition keeps the sections on using OpenOffice and the BASH shell but adds substantial material regarding the new automatic multimedia setup, the 3D graphics effects that have the Ubuntu desktop much more visually appealing and also on security and encryption. There is also a mini-tutorial on using the GIMP for basic image manipulation which I think shutterbugs will find handy.

The last part of the book is devoted to slightly more advanced topics such as package management, backups and automation and remote access. Personally I feel that package management deserves a more central place, right alongside installation, but the book’s modular structure means that this isn’t much of a problem. Overall the last few chapters act as a springboard from where newbies can start another journey to the level of power user and beyond.

The book as a whole is well laid out and material is clearly separated. The use of sidebars and small tips and warning sections means that a good amount of extra information is presented without interrupting the main flow of the text. There are also lots of links to other information sources where the interested reader can go to for more in-depth information. Most of these are freely available online sources and the full URL is often provided resulting in minimum effort for the reader. For Windows and Mac OS X users there are also pointers to third party tools that might make migration easier. The book is replete with high-quality black-and-white screenshots which add to the complete guide experience that the book provides. The third edition updates everything to be in sync with Ubuntu 8.04 and comes with a double-sided DVD containing a ready-to-install image on one side and various ISO images of the Ubuntu derivatives on the other. In essence the book has everything that a user would need to get up and running with Ubuntu.

The book is at a reasonable price of $39.99 and I think it’s a good investment for anyone looking to jump into the world of Linux. Even though you’ll get the most from this book in the first few weeks after installing Ubuntu for the first time, the later parts of the book will serve as a handy quick reference for those types you find yourself needing to dig under the hood. There is certainly a large amount of information online which means that books of this type are not strictly necessary, but at the same time it can make things a lot easier to have a quick reference close at hand. My litmus test for this sort of this sort of product is generally: would I give it to my mom? This time the answer is yes.

Things to do on a 16-hour flight

By the time you read this, I will probably on my 16-hour flight from Newark, USA to Mumbai, India. Though I rather like flying (I like machines in general). I don’t really fancy being stuck in a small cramped space with lots of other people for long periods of time. Why can’t the laws of physics just be simple and allow cheap instantaneous teleportation between arbitrary points? Anyway, enough bitching and complaining on my end, I’ll save it till after the flight. Even though I’ll be stuck on a plane for 16 hours, I do not intend to waste all that time simply getting bored. So here is a list of things (in no particular order) that I might try to do during the flight.

1. Sleep

Come on, you don’t seriously expect me to be at my productive programmer best on a plane do you? A nice airport waiting room, maybe, but not on the plane. Let’s face, despite my love of flying after an hour or two I will want nothing more than to land. So I will try my best to sleep through as much of the flight as possible. Unfortunately, I’m not much of a sit-up sleeper so I don’t know how much of my time will actually be spent sleeping liking a baby. Speaking of babies, I sincerely hope there aren’t any babies near my seat. I like babies, but not near me on a plane.

2. Read

The all time classic timepass activity. Now the question is, what? I don’t have many fiction titles at hand and the ones I do I’m not inclined to read on a plane. I would consider taking something I’ve already read before and know I like, but from past experience I know that’s not a good idea. My choices right now are between a number of really good popular-science type books that I’ve been wanting to read, but haven’t gotten around to, or one of the equally well written computer/science engineering books that I need to take along. I was seriously considering taking SICP, but I’ve found that the best place to read that book is in front of a computer with a Scheme interpeter open so that I can work through the examples as they come. I could do some paper programming, but the tray holders aren’t very conducive to having a book and a large-ish notepad open at the same time. And it is simply an exercise in frustration to paper program on small paper. I’ll probably take up Roger Penrose’s The Emperor’s New Mind and something else a bit lighter.

3. Design

My research project is somewhat stagnated at the moment and it’s fairly obvious (to me at least) that we need a new design to control all the things that are going on and are likely to happen soon. I think some time of my flight at least will be spent thinking about this design. If I have space left over I’ll take the Design Patterns book because I think I’ll be using some of those patterns to come up with a working design. And it’ll be nice to be able to think without being near a computer for a change. The control language we’ve been using will also need some fairly heavy changes, so that’ll be something else (which I am more familiar with) that I’ll have to think about.

4. Plan

I’ll be starting sophomore year at college soon. This year is going to be interesting. Not only am I mostly done with all my mundane requirements, I’ll be involved in some research throughout the year and I plan to take a self-designed independent study. I need to do some thinking about the study and also about what new languages/technologies I want to learn. I read Steve Yegge’s 10 predictions today and I think I’ll also try to make some sort of predictions regarding the state of the computer world for the sole purpose of seeing how much I understand the things going on around me.

5. Draw

Like many children, once upon a time coloring used to be my favorite sport. As a programmer I’m often doodling design diagrams and pseudo-flow-charts and other random interaction stuff. I might just feel inclined to try and turn on the creative juices a little. I’ll probably be doing a fair amount of doodling as part of my designs, but I don’t have to stop there.

6. Music and Podcasts

I’ll make sure that my iPod has a full charge which will easily last it the whole flight and more. I have a good 10 gigs of music and 10 episodes of the Stack Overflow podcast to listen to and I hope all that, if nothing else, will keep me partially alive. I might even look around and see if I can find some more interesting Podcasts and audiobooks. No, I won’t consider movies, because I can see absolutely no point in watching a movie on such a small screen.

7. Sit and stare

Yes I’ve done this on my last flight and it’s actually quite easy. You sit and you stare, that’s it. You don’t have to look at anything particular and you don’t have to react to anything either. Of course if you’re doing this, you’re probably in the last stages of boredom before it becomes terminal and chances are you’ll need rehab once you land (lugging heavy luggage sometimes helps). I’m certainly hoping I don’t get to this stage, at least not until I get to the part where we have to buckle down for landing and there is really nothing else to do.

Once I’ve landed and have sufficiently recovered thanks to my mother’s cooking, I’ll list all the things I actually did, that is, unless I’m in boredom rehab. I do hope it won’t come to that.

Should we make heavy software

When I showed off Firefox 3’s smart address bar to a friend of mine a few days ago, his first reaction was: “Wow, that’s cool” and half a smile. A second later the smile was gone and he let out a disappointed “Oh but that’s going to take up so many resources”. Let’s leave for the moment that my friend was not the tech-savviest person in the world and that he would probably not be able to list exactly what those “resources” were supposed to be. What his remark got me thinking was simply: “Is it really a bad thing if my software takes up many resources?”

I suppose the core issue here is that computer users don’t really care about resources. Most of my friends wouldn’t be able to tell me the specs of their computers and much less what those specs meant. What they are interested in is quite simply, speed. They want their software to be zippy and fast, so do I, so does everyone (I hope). When my friend said that Firefox 3 would take up more resources, what he really meant was “My computer will run slower.” He quite innocently equated less features to mean lightweight and hence faster. It’s an honest mistake, but that doesn’t change the fact that it is not really correct. Tweaks and customizations to programs can often increase actual program size and complexity but give better performance. Apple has been doing with OS X for years now. Many users and benchmarks will vouch for the fact that though OS X has been gaining features, it’s also utilizing computer resources more efficiently.

Of course, it’s undeniable that the general trend is towards programs that use more resources. After all, more resources does mean more maneuvering room, more stuff to build with. And resources to keep increasing. Our computers today are vastly more powerful than those available at even the start of the decade. And we’ve been reaping the benefits with more sophisticated software: better visuals, increasingly powerful desktop search and increasing higher resolution data formats.

At the same time, many people both programmers and not, are becoming increasingly worried that modern software is bloated an unwieldy. Just as Moore’s Law has been giving us faster processor, our software acts as a Moore’s Law Compensator. Our computers still take a long time to boot up and become usable, most programs don’t start in the blink of an eye, in essence, somehow the user doesn’t really see all the power that’s tucked under the hood. This has led to a growing trend in lightweight software, especially in the more tech-savvy community.

Among Linux users this dual nature of modern software is very evident. On the one hand Linux systems can now sport powerful 3D window managers and task switchers good enough to rival Vista or Leopard. On the other hand, there have been a wave of new minimalistic window managers lacking ant graphic splendor whatsoever.

I feel myself personally affected by this double trend: I myself use a tiling window manager called Awesome. I shun IDEs, preferring to use the very lightweight Vim from a simple terminal. Firefox is just about the only graphical program that I run. At the same time, I love OS X Leopard. I think the UI is quite beautiful and I’ve become an avid user of both Expose and Spaces. Not to mention the fact that somehow fonts seem to look much better on OS X than on any other operating system I’ve ever used. Performance-wise OS X is much better than Vista which takes much longer to start up and respond on a far superior system.

Being a programmer myself, this issue is particularly important because I think about performance almost all the time. Whether it’s deciding whether to use a high-level language like Python, or lug it out with something closer to the metal like C, or which graphics toolkit to use, I have to factor in resource-use. I’m still not sure about which way is better. Software bloat is bad. Very bad. At the same it doesn’t make much sense to let all that computing power sit there unused and the benefits very often outweigh the price to be paid. For the time being, I’m calling it a truce and letting the decider be something less tangible than performance benchmarks: user experience. If you can use heavy resources but deliver a solid user experience, then go for it. An incomplete user experience for the sake of a lighter program might be occasionally justified, but not all the time. However a bad user experience along with heavier system requirements is definitely a bad thing, to be avoided at all costs. After the best software is not the one that uses least RAM or has the prettiest interface, it’s the one that gets the job done without getting in the users way.

Write a manual for your software

If you’re a computer science student like me, then you probably write a fair amount of code. Depending on your coding style you probably write a fair amount of comments too. But do you write about your software or do you just write your software? Chances are you don’t. College computer science courses aren’t exactly writing courses (no matter how much typing you do). While part of a project may involve documenting the concepts behind your program, or why you made a particular design decision, you hardly ever write something like a manual for your software. However, if you’re planning to write production software at some point, especially if you’re thinking about creating something independently or as part of an open source project, then writing a manual might be more helpful than you think.

Writing a manual is more about than just putting together instructions on how to use your software. It’s important to put yourself in the place of someone who will be using your software (and is probably not a programmer). For you your program logic makes perfect sense (if it doesn’t, why is it even there?) but sometimes what makes sense from a programming point of view isn’t quite so simple from a user point of view. Looking at your program from a user’s point of view let’s you think in terms of what’s really useful and necessary rather than what’s easiest to program. Writing a manual is a good way to put yourself in the user’s seat.

The first things that come to mind whiel writing manual is the user interface. How is easy is it to do simple tasks? Where are the most important parts of your UI located? Is their a general cohesiveness in the way things are put together? Are there some things that you know your program is capable of, but are almost impossible to do due to the UI? Theses are all questions that directly affect how your users’ experience. And so they are top priority. If you find yourself taking up two pages describing something that the user will be doing dozens of time each day, then something needs to be changed.

A critical review of the interface will lead to deeper program logic. Are things which appear close together and related in the UI similarly close together in the program? Are the UI and the program logic equally clear and intuitive? Are you unintentionally exposing internal structure to your user? While writing the manual you should keep an eye out for any bad designs, you should also be thinking about missing or broken features. While that doesn’t mean you should implement everything that comes to your mind, sometimes some features are useless without supporting features. After all, your clients aren’t interested in the features themselves, they want to get their work done. If you find yourself writing about how not to do things or what can’t be done in your manual, rather than how to do them, then your program probably needs more work.

Having a written manual for a small art program, I’ve realized that there’s a fairly direct correlation between ease of use and ease of description. If you can explain a function and how to use it in a few lines, it’s probably mcuh better implemented than a description that takes up half a page. The first version of my program was a fairly tedious text-based program which went out of style around the same time as Apple BASIC stopped shipping. The descriptions for each option and how to get to them were equally complicated. Putting together a simple GUI not only made interaction easier, it also choppped down the interaction part of the manual to a few bullet points.

However, when you’re writing a manual it’s fairly easy to write from a developer’s perspective. After all, you have the guts of your program in your head, and you probably already know half a dozen unobvious little tricks and workarounds. You’ll either forget to put them in the manual or you’ll remember and think that they’ll make as much sense to others as they do to you. Chances are they don’t and you really don’t want to be putting workarounds in your manual if they’re hiding a bug. Fix the bug and then write the rest of the manual.

I’m starting to think that all students should at least once have a project that requires writing a user manual for non-programmers. Years of writing code and tearing through algorithms can make you think very differently from the average office worker using your program. It’s necessary to get in touch with your users and how they’ll be using what you give them. So the next time you write your great new world changing program, take a few hours off and write a manual for it.