The information is often out-of-date. My navi computer does the same, but when there's a new construction area (or one goes away), the limit is completely wrong.

Yes, that does solve the particular problem I described, and I've already used that trick. But it's not a general solution to the "independent virtual desktop switching" problem. Very old Linux installations had no Xinerama option, so the concept of having a single desktop that spreads over several monitors was introduced after I became used to dealing with things separately on each monitor. What I prefer (the non-Xinerama mode) has the disadvantage that you cannot move windows to the other monitor; I guess that is why so many people (seem to) prefer the Xinerama way. But I found that my workflows work better in non-Xinerama mode.

Also, sometimes dialogs belonging to a program on one monitor will pop-up on the other one in Xinerama mode -- that does not happen when the displays are logically seperate.

The article says: "This is one thing that's certainly gotten much better in recent years for Linux GUI users in general..." -- I cannot agree. While connecting a beamer to a notebook is simpler today, support for multiple monitors (of a desktop machine) is far from where it was some years ago. For years I had been able to disable the (default) Xinerama options, so I could have two separate instances of (e.g. KDE 3) running on both screens. That allowed me for example to stay on virtual desktop 1 on the left monitor and cycle through my virtual desktops on the right monitor. (Imagine lots of data sources on the right screen and some application I use to combine stuff on the left monitor; I want to switch desktops without the left monitor changing its content). This is still possible today, but it's a lot harder and depends on what kind of graphics card you use. Granted, my old way required knowledge of the xorg.conf syntax, but once it was finished it gave me maximum configurability. Last time I checked, KDE 4 wasn't able to start two instances on :0.0 and :0.1 properly which is why I'm still using KDE 3 (a.k.a. "Trinity" today).
Hans-Georg

Well, guess what most schools still use in the class rooms, at least in Germany... If there was a trend away from chalkboards/blackboards, it would be towards those newish electronic boards running interactive learning/teaching software. But those are expensive so you won't see them too often.

Funny argument. In Word the default font (Times New Roman) is 1) not truly a good option for printing documents and 2) always the same. With LaTeX you can change the standard fonts as easily as you change them in Word, plus with many fonts you get modified math fonts so your math equations fit the normal text.

You can easily tell someone's thesis was done in Word, because the typesetting is broken and formulas look disgusting, unless the author spent hours changing things like the size of exponents. Also, when writing for a journal/conference proceedings etc., articles are meant to look the same (since they'll appear in the same book). With LaTeX you get that for free, with Word, even when using the official publisher's stylesheet, there are always minor errors in the layout.

This post was rather short, but I think it is one of the best suggestions. I played a bit with SILC some years ago: From a user's view it looks a lot like an IRC client, so users can talk to one another privately or join a channel to meet with several other users. What's most important is: It meets all the criteria,
- it encrypts all communication
- it is no multi-protocol thing, i.e. you cannot connect to other services.
I can't remember whether you can run connections to several silc servers at the same time, but if so, that's at least better than having to restrict a program that can connect everywhere. Even though I haven't heard much of silc lately, the software is still actively developed. The last release is from March 19, 2009.

Nope, not like KDE. I haven't seen KDE asking for the user password when starting any programs, plus sudo typically isn't configured on a Linux system. KDE password dialogs request the root password.

So it's different. Macs do sudo, KDE does su.