LWN.net Logo

Book review: Linux In The Workplace

[Book cover] We have not managed to write a great many book reviews over the last couple years - they take a lot of time, and were never our most popular feature. Linux In The Workplace, however, is sufficiently interesting that we took the time to read it through. Read on for our impressions and thoughts on why this book is worth noting.

Linux In The Workplace is published by the Linux Journal Press. Interestingly, no authors are named on the cover; instead, it is credited to "SSC, publishers of the Linux Journal." It is, in fact, the result of the Linux Journal's staff's experience with running a Linux-based office over the last few years. As a result, it is well grounded in a lot of real-world, Linux-based office work; it is also deeply tied into the Journal's way of doing things.

The cover does not go out of its way to make it clear, but this book is mostly about KDE. GNOME-based applications are mentioned in spots, but anybody wanting to set up an office around the GNOME desktop will not get what they need from Linux In The Workplace. There is no problem with this - trying to cover both desktops would likely turn the book into a confusing mess - but it's a good thing to be aware of.

Actually, anybody wanting to "set up" an office around any desktop will need to look elsewhere. Linux In The Workplace is very much a user's manual; it expects that somebody else has already gone through the trouble of installing Linux and making it work:

This book is different in that we assume you don't want to install Linux, don't want to learn how to be a system administrator, and aren't concerned with doing some of the more complicated tasks. We assume you already have a working Linux system on your desk and need to use it to get your work done.

Again, that is appropriate; serious use of Linux in offices is only feasible if most users do not have to deal with the administrative issues - something which is also true of Windows in the office.

So, what's covered in this book? After a quick "what is Linux" chapter, we learn how to log into a KDE-based system, deal with user accounts ("A good password combines upper- and lowercase letters with nonalphanumeric keys. Passwords such as *nCk&Ve or *nG]y$Uds- are good examples."), and deal with the basics of the KDE desktop. The approach is low-level and detailed - we learn about what most of the icons and menus do. Anybody who is used to working with a Linux desktop at all may find the "now click here" pace a bit tiresome, but readers who are entirely new to Linux will likely welcome the detail.

In subsequent chapters, the reader will encounter:

  • Chapter 3: a description of Konqueror, but only in its role as a local file manager.

  • Chapter 4: "getting organized." Topics like KOrganizer, KPilot, KArm, and KNotes.

  • Chapter 5: OpenOffice. OpenOffice is the preeminent free office suite for Linux, and this book recognizes that fact. This chapter provides a whirlwind tour of the OpenOffice applications; it (like much of the book) is more useful for getting an idea of what the application can do than really getting an in-depth understanding. If you want an overview of how the spreadsheet works, this book will help; if you need to learn how to write formulas, you'll need to look somewhere else. (This chapter is available on the net in PDF form).

  • Chapter 6: alternative office software. This chapter is a quick overview of KOffice and AbiWord; one gets the sense that the authors expect few readers to go beyond OpenOffice, however.

  • Chapter 7: graphics. A quick look at KPaint, Kontour, KView, and the xscanimage tool.

  • Chapter 8: the Gimp. There is, of course, no way to do justice to the Gimp in a single chapter; this attempt reads mostly like a quick demo given to somebody who had never seen a serious image editor before.

  • Chapter 9: email, netnews, and faxes. KMail is covered in fair detail, though important points are missing. For example, the KMail interface to GNUpg is covered, but GNUpg itself is passed over. There is also an overly scary warning about reading attachments: "Attachments are often the vehicle for transmitting computer viruses that can do great damage to both your computer and any computer to which you are connected. A virus can even attack your address book and send replications of itself to everyone listed." That is a bit strong, given that this scenario has never, to your reviewer's knowledge, happened to a KMail user.

    If you were going to cover a second mail user agent in a book like this, what would it be? The authors chose Netscape mail. Pine, mutt, and elm get passing mentions; evolution does not, for the purposes of this book, seem to exist.

    Quick mention is made of KNode for reading Usenet news and "K Send a Fax" for dealing with faxes. One could certainly imagine other, better established applications in these categories that would have been worth a mention.

  • Chapter 10: Konqueror as a web browser. Quite a bit of detail on bookmark management and such. There are passing mentions of Netscape and Opera; nothing about Mozilla or Galeon.

  • Chapter 11: customizing the desktop. This chapter will certainly be useful to anybody wanting to tweak how the KDE desktop works.

  • Chapter 12: making backups. A quick look at "Ark" and KOnCD.

  • Chapter 13: the command line. Only in the very last chapter does this book get around to discussing terminal emulators, shells, and the Linux command line. A quick overview of a number of basic commands is provided. Emacs is covered in three sentences.

There are a number of shortcomings and strange omissions. For example, office workers are likely to want to view PDF files, but there is no discussion of how to do that - even though gv, which reads (most) PDF files happily, is briefly covered. Printing is mostly passed over, as are multimedia applications. And (by design), there is almost no mention of proprietary software packages that can be useful in real office situations.

But, then, few books are perfect. This one is important as proof that you can get a lot of work done on a Linux system without ever having to mess with partitioning menus, shell prompts, mount commands, and so on. The existence of this sort of book is an important prerequisite for widespread adoption of Linux for desktop use. Desktop Linux is, increasingly, being taken seriously; Linux In The Workplace is full of good examples of why that is happening.


(Log in to post comments)

Book review: Linux In The Workplace

Posted Nov 20, 2002 23:17 UTC (Wed) by hazard (guest, #3695) [Link]

Regarding KMail and attachments. There actually was a story of a guy using KMail, who also had Wine installed. From what I remember he received an e-mail with Klez virus in attachment, double clicked on it, and since he had configured MIME bindings pointing to Wine, the virus got executed, found some e-mail addresses on his hard drive and sent them copies of itself via SMTP server running @ localhost. :-)

Book review: Linux In The Workplace

Posted Nov 21, 2002 0:02 UTC (Thu) by cyanide (guest, #2236) [Link]

The attachment conundrum is an interesting one... Would it be possible to set up a client to launch the executable, but as a process with limited system access - user "nobody" or something like that? Benign amusments have little need to access the file system, and if you really wanted to give access to the filesystem under your normal user account, you could be warned.

This would stop the spread of the vast majority of viruses.

Book review: Linux In The Workplace

Posted Nov 21, 2002 0:21 UTC (Thu) by coriordan (guest, #7544) [Link]

>Would it be possible to set up a client to launch the executable, but as a
>process with limited system access - user "nobody"

Under GNU/Linux, for a mail client to change the user id of a process it
requires root privilages.[1]

GNU(/Hurd) allows users to have multiple user ids so that the user (and
therefore the mail client) can choose which user to launch an executable
as. On the down side, KDE doesn't work under GNU yet ;)

Ciaran O'Riordan

[1] Maybe it could be done by leaving a setuid-"nobody" copy of Bash on the
system but for some reason *no one* has ever done this.

Book review: Linux In The Workplace

Posted Nov 21, 2002 9:54 UTC (Thu) by Dabuk (subscriber, #1507) [Link]

>Maybe it could be done by leaving a setuid-"nobody" copy of Bash on the
>system but for some reason *no one* has ever done this.

There have been several vulnerabilities which exploited temporary files in
/tmp. Even running as "nobody", malicious code could be used to attack
your computer.

Book review: Linux In The Workplace

Posted Nov 21, 2002 10:43 UTC (Thu) by coriordan (guest, #7544) [Link]

100% of viruses attack your computer when it is turn on. I recommend
never turning your computer on.

The person asked if there was a way to run attachments as an unprivilaged
user, my answer is correct. Specifically, the point was raised about
windows binary attachments, these target windows and so could not
exploit bugs in a setuid-nobody account on a GNU/Linux system.

An even more secure idea is to create a non-privilaged account for every
user on your system, this is practical for desktop machines where there
are only 10 or so users. Each account would contain a setuid copy of
Bash in ~/bin. Users could be given executable rights on their dummy
copy of Bash. This would stop a denial of service attacker from messing
up the setuid bash config for everyone on the system.

Ciaran O'Riordan

Book review: Linux In The Workplace

Posted Nov 21, 2002 7:44 UTC (Thu) by yodermk (subscriber, #3803) [Link]

> Quick mention is made of KNode for reading Usenet news [....] One could certainly imagine other, better established applications in these categories that would have been worth a mention.

Or perhaps someone could explain why an office worker should be reading Usenet news?

The person who set the thing up, maybe, but as mentioned previously, this book isn't for them!

Book review: Linux In The Workplace

Posted Nov 21, 2002 17:24 UTC (Thu) by Ross (subscriber, #4065) [Link]

I've worked at several companies which used newsgroups for internal
communications. They have all been internal groups, though, so I
don't think you could call them part of Usenet.

Book review: Linux In The Workplace

Posted Nov 21, 2002 9:58 UTC (Thu) by leandro (subscriber, #1460) [Link]

I wonder...

Is the naming of things considered irrelevant? If so, it's a sad commentary on our society.

We already know that the correct name of the OS from the users' perspective would be GNU, since they mostly don't interact with the kernel, but with programs compile against higher level libraries which were built or chosen by GNU.

But this is even worse. This is a course on KDE, which isn't even GNU/Linux specific. Rather, it is general for POSIX, being used too on the BSDs and other systems.

Just think; if people do this and get away with it, we could have a totally different book on Gnome, and other on CDE, and other on GNUStep and other on console interface and programs and have them all named the same.

Book review: Linux In The Workplace

Posted Nov 22, 2002 16:40 UTC (Fri) by Peter (guest, #1127) [Link]

Is the naming of things considered irrelevant? If so, it's a sad commentary on our society.

Mostly, yes. Why is that sad? I find it amusing.

We already know that the correct name of the OS from the users' perspective would be GNU

The correct name of the OS is whatever name it is given by its creator. Since it is a distributed effort and has no single creator, the correct name would be the name given by whoever collects all the bits and pieces and markets it as a complete work.

I.e. the company you bought it from.

Most such companies call it Linux, along with a brand identifier. The Debian Project calls it Debian GNU/Linux, for example, where Debian GNU/ is the brand identifier.

Since, as you later point out, KDE is not specific to any one Linux distributor, one should use a blanket term for the OS if possible. The one almost all distributors agree on is "Linux".

This is a course on KDE, which isn't even GNU/Linux specific. Rather, it is general for POSIX

Indeed. This was mentioned in the review, as I recall. Perhaps in your opinion the OS name should be KDE/GNU/Linux? Typical distributions of this OS probably have more lines of code from the K Desktop Environment than from the FSF.

Book review: Linux In The Workplace

Posted Nov 26, 2002 2:52 UTC (Tue) by coriordan (guest, #7544) [Link]

> Typical distributions of this OS probably have more lines of code from
> the K Desktop Environment than from the FSF

hahahahahahahahahahahahahaahhahahahahahahaahahahahahahahahaha

Yeah. Typical distributions that don't include GCC, GDB, BASH, Shellutils,
textutils, gawk, fileutils, findutils, diffutils, Emacs, autoconf, automake,
info, texinfo, grub, binutils, gzip, zlib, gettext, grep, aspell, make,
nano, m4, parted, sed and wget.

Oh, and don't forget all the distributions that don't contain GNU libc6.

But don't worry, you're not expected to appreciate all that Free Software,
why would you when you got it for *free*.

Ciaran O'Riordan


Book review: Linux In The Workplace

Posted Nov 27, 2002 8:10 UTC (Wed) by jwharmanny (guest, #971) [Link]

> Most such companies call it Linux, along with a brand identifier. The
> Debian Project calls it Debian GNU/Linux, for example, where Debian GNU/
> is the brand identifier.

I don't think "Debian GNU/" is the brand identifier. It is "Debian". The product is called "GNU/Linux" because it is a combination of both GNU and Linux in one product.

> This was mentioned in the review, as I recall. Perhaps in your
> opinion the OS name should be KDE/GNU/Linux? Typical distributions of
> this OS probably have more lines of code from the K Desktop Environment
> than from the FSF.

The name "KDE/GNU/Linux" is really being promoted as "KGX" but I personally don't like abbreviations that much, so I use the term "Linux" usually.
Maybe we should call it "KGLXMO" (KDE/GNU/Linux/X/Mozilla/OpenOffice) ?

And indeed, KDE probably has more lines of code than all base GNU tools together. But, on the other hand, it would have been impossible to create, compile or run KDE without GNU tools. And don't forget that GNOME, Gnumeric, GnuCash, etc, are also part of the GNU project.

Book review: Linux In The Workplace

Posted Nov 24, 2002 13:56 UTC (Sun) by stock (guest, #5849) [Link]

No matter how good or briljant a book is,
I'm rather reluctant to buy a book, where no author(s)
are mentioned. How can you give comments, if you don't
know who wrote it, and so is liable for the contents?

Book review: Linux In The Workplace

Posted Dec 5, 2002 19:48 UTC (Thu) by Rebecca (guest, #8397) [Link]

The complete list of authors is in the Introduction...13 names wouldn't quite fit on the cover.

Copyright © 2002, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds