A window manager is a program for Unix systems which, contrary to what its name implies, does not actually manage windows. What it does is create visual clutter and human-computer interface artifacts which "allow" the user to manage windows, never taking into consideration that users don't actually want to do this. Window managers give very limiting (how true) capabilities as GraphicalUserInterface
. Lately, they have been incorporated into more ambitious projects (though that's not saying anything) developing in the GnuLinux
community, like the KayDesktopEnvironment
, and GnomeDesktopEnvironment
Window Managers in the XwindowSystem
are just special clients which take advantage of some security holes in the XwindowProtocol
Do they take advantage of security holes? How? I just thought they were normal clients!
It's sort of a sarcastic-but-true comment. Window managers need no special privileges to take over your desktop and control what you see; a malicious program could control things completely with only base privileges to the X session. (With a sufficient degree of ArtificialIntelligence
or human monitoring, it could prevent you from seeing, say, web pages which explain how to remove it - but a more realistic threat is simply rendering your desktop unusable.) If either of those things happened, I could just switch vtty's and use Lynx. Cntr-Alt-F2 or something to the effect.
[No, it's a purely
sarcastic comment. The truth is merely that X11 has no attempts at security in the features that support window managers, meaning they are expected to be trusted programs. This is not a good approach to security - when is absence of security ever
a good approach to security? But that is completely different from the sarcastic comments above.]
That's probably because security at the HCI layer is the toughest nut of all to crack. And that
is because humans can't do cryptography! Designing a thoroughly secure HCI is still doable using some kind of PDA to provide human-mediated authority and tracking, but you have to really understand what you're doing. And needless to say, the creators of Unix didn't. Ahh, for the days when I can plug in a PDA into a computer and it will authenticate for me. No more stupid logins, no more stupid passwords!
Maybe this is a stupid question, but what stops me from stealing your PDA and thereby gaining access to the systems authenticated by your PDA? At least with a password or pass phrase, I can't gain access to your accounts unless I steal your brain and decode it.
- That's probably because security at the HCI layer is the toughest nut of all to crack. - Looking a great distance forward, I imagine that the sort of security desired here will come from making smarter HCIs. The computer will know who you are in the same way a child knows his mother - face, voice, the tread of your footsteps, microexpressions, preferences, habits, etc. The only limitations on what it can potentially learn are the inputs it has... but cameras, keyboard, and audio can go pretty far. It will be more a UserAgent?, even acting on behalf of the user for the user's anticipated actions where those actions are low-risk and high-reward. The UserAgent? will know how to keep secrets, too... and might even know to hide the porn when the boss walks in. However, for this to happen is going to require pushing the envelope on anticipatory, cooperative HCIs... ones that learn the individual human just as much as humans learn it.
If you really think passwords are so great then put one on the PDA. At least then you'd only need ONE password for your entire identity, instead of separate capabilities (ie, passwords or keys) for:
Single point authentication sacrifices security for convenience. There's a good reason folks don't have a single physical key for car, house, office, safety deposit box, and so on, and the same applies to digital keys. That's especially true when the authentication mechanism relies on a portable device that is difficult to physically secure, and is therefore vulnerable to attacks and compromises (such as subjecting encrypted identity data on disk or NVRAM to brute force methods) that a (presumably) physically secure on-line banking account is not. In short, I'm not sufficiently confident in the security of a PDA to consider using it is an authentication device. If you are, that's fine. It's all a matter of comfort level. For example, I know people who are not confident in the security of on-line banking
- more banking
- credit card
- internet account
- <add your own here>
at all, in any form, and categorically refuse to use it.
- Yeah, and you know what's the good reason folks don't have a single physical key for car, house, office, safety deposit box? Because it isn't physically possible. There is no other reason. You claim that people don't reuse logins and passwords whenever and wherever they can get away with it? What world are you living in?!
- Yes, I know some people use the same id and password for everything. Some people leave their cars running and unlocked while they pop into the 7-11, too. I don't re-use passwords, because I have a system for making them unique, memorable, and acceptably unguessable even if a given password is compromised. I know other folks do this too, because I've discussed it with them. As for having a single master key, actually it is physically possible. For obvious reasons, you're not likely to convince the bank to let you change the lock on your safety deposit box, and modern car ignition locks are a world unto themselves which would make the process expensive, but a good locksmith and a fat wallet can get you a single key for all your building locks. For obvious reasons, that would be a bad idea. Whether it's physically possible or not is immaterial - single point authentication, especially that based on a physical device or biometric data - is inherently riskier than multiple keys, especially those housed in what is currently the most secure storage possible, a human brain.
- Replace physically possible with economically possible then. I used to have multiple keys following a simple master pattern proof to dictionary attacks. I gave it up when I could no longer remember which of the dozen or so possible keys I could make I had actually used. Further, it is false that single point authentication is inherently riskier than multiple keys, you come to that conclusion only by a judicious filtering of the evidence. And it is complete nonsense to call the human brain a secure storage, let alone the most secure storage possible, since it is a piss-poor storage mechanism for arbitrary data and after factoring in the risk of loss, it is much less secure than writing passwords on a piece of paper taped to the underside of your desk. For the overwhelming majority of security applications, the only reason unauthorized access is a security risk is because it may lead to non-usability of the object (ie, theft) so minimizing the former at the expense of the latter (ie, locking yourself out) is the stupidest strategy imaginable. Disposing of your gold is a perfect way to prevent its theft, but that doesn't make the suggestion any less stupid. If memorizing multiple pieces of arbitrary data for 20 years on end works for you, great, but it assuredly doesn't work for 90% of the human population.
And with a PDA, you've got enough intelligence to do intelligent stuff. Like having a secondary password that works for exactly 24 hours and silently alerts the authorities with the PDA's GPS location. And a tertiary password that works for 7 days in case you're in a hostage situation and alerts your corporation's in-house SWAT team. They wouldn't even have to be completely different, they could differ in only two or three digits, so they wouldn't be difficult to remember at all.
You may be onto something here.
And you know what you could do? You could have a "physically secure" master capability computer in your house that renews the purely temporary capability in your PDA every 24 hours. So no matter what happened, the PDA could never be used for longer than 24 hours and you could easily use a new one if you ever lost it.
Perhaps this should be refactored into WindowManagersForXwindows? or something like that; most of this page is specific to X11. Indeed, as pointed out below, most of the other GUI environments out there (Windows, Mac, etc.) do not have the concept of a WindowManager as a separate component of the GUI. Window management, session management, and lowlevel toolkit stuff are just rolled up into one big ball of stuff.
Well, if Window Managers only really exist as a discrete component in XWindows terminology, tacking ForXwindows?
onto the label doesn't really add value to the title while making it harder to use in a sentence.
There's a plethora of X11 WindowManager
s out there, it seems like everyone wants to write one. Some of the more popular are listed here:
- The 'standard' window manager.
- Part of the CommonDesktopEnvironment?.
- The OpenLookWindowManager? from SunMicrosystems.
- Lightweight featureful WM, a popular replacement for Motif until KDE/Gnome came along.
- The Universal Window Manager, contributed to X11R3 by DEC. It's very outdated.
- Imitated the NeXT look. Based on fvwm, a separate codebase now.
- The standard window manager of the KayDesktopEnvironment.
- Lisp-scriptable, default window manager for the GnomeDesktopEnvironment 1.4.
- Keyboard-centric non-overlapping window manager.
- Minimalistic window manager, does the least necessary.
- (IonWindowManager) Relatively keyboard-oriented window manager based on a novel window arrangement concept (sounds like a buzzword :) ), somewhat like emacs' frames or screen (ScreenMultiplexor).
- A minimalist WindowManager relying largely on applets.
- The MotifWindowManager?.
- HewlettPackard's offering.
- Window manager on steroids. Once was part of GnomeDesktopEnvironment, now not. See http://www.enlightenment.org
- Another gnome-compatible window manager.
- Current default window manager of GnomeDesktopEnvironment (2.0 and later). (Can be replaced with other window managers; Gnome works with many different ones).
Window managers for other systems:
- A part of the SharpEnvironment for MicrosoftWindows.
- In PlanNineFromBellLabs.
- In the QnxOperatingSystem.
- Another mouseless WindowManager (see RatpoisonWindowManager), and more closely inspired by GNU screen (ScreenMultiplexor) than ion.
[prompted by MacOS and Windows formerly listed here]
The Mac OSes have nothing corresponding to an X11 window manager, just nameless subsets of the operating system that cannot be replaced by ordinary users. The old "classic" Mac OS had an API called the Window Manager, but the name was a coincidence and it actually referred to an API to do with application windows. (The file API was called the File Manager, the sound API the Sound Manager, and so on.) Aqua is (and here I am quoting Apple) the Mac OS user interface. This might include the elements corresponding to an X11 window manager, but also includes the rest of the user interface as well. In the same way, MicrosoftWindows
does InTheory have
a kind of window manager, but saying that it is
one is a mistake for similar reasons.
I thought WM's in X were supposed to implement large chunks of the ICCCM (drag and drop etc)? No; see XDnD comments below.
They certainly have a special status in that spec. You mean cut and paste.
ICCCM was popularly seen as being too complex/stupid/useless to implement, so most window managers didn't. False, unless you mean that most didn't implement ALL of it.
( a sample of the level of invective poured on this spec can be found here: http://lists.slug.org.au/archives/slug-chat/2001/July/msg00054.html
- That is a rant by someone new to ICCCM, and is about 85% content-free. ICCCM has problems, but he apparently hasn't run into the real ones yet (as of that posting); he's really just complaining that he has trouble understanding the documentation.
When writing an application, you could blithley ignore the ICCCM since you could avoid playing nicely with the other kids. Window managers can't avoid this - it's their job - and the ICCCM became the barrier to entry for window managers. -- BrianEwins
The ICCCM (Inter-Client Communication Conventions Manual) defines a number of protocols layered above the X protocol that clients use to cooperate. These protocols include managing the selection and clipboard and the protocol between applications and the window manager. The window manager is a client just like any other application. The ICCCM does not include drag and drop, and drag and drop protocols (XDnD for example) do not involve the window manager: clients pass data between themselves as peers. -- NatPryce
I use twm
because I find it the most commonly available and my .twmrc configures it to operate the way I want it without surprises across a wide variety of OperatingSystems
HP-UX Irix GnuLinux FreeBsd
Solaris MachTen? CygWin
. -- ChrisGarrod
or Enlightenment depending upon the mood I'm in. I think it's one of the great things about running Linux - the plethora of choices in choosing a desktop environment and/or window manager. -- NaumTrifanoff
I use fvwm because I can get rid of all those annoying icons and menus on the desktop. And I can configure a menu that contains all the running applications. Unfortunately, too many modern window manager designers seem to believe that Microsoft somehow got it right. -- HowardFear
I use SawFish
, because it's written in the same fantastic style as Emacs. Hurray for programs that you can comfortably and safely hack useful things into while you're running them! -- LukeGorrie
I use SawFish
, because I'm a Lisper, but it has a few fatal flaws which make me dislike it. I just don't dislike it as much as any other window manager I've tried. -- DanielKnapp
I use KDE because I have been using linux for all of 5 months now. What can I say? I got addicted to a bloated gui, hehehe. But for most useful work, I'll drop to a text-console anyways... -- BelTorak
I use BlackBoxWindowManager
(similar to FluxBox?
) with a lot of key bindings because it's minimal, yet still looks relatively good, and doesn't interfere with my mental flow. -- SckotVokes
See also: MinimalLinuxUserInterfaces
(which is mainly about lightweight X WindowManager