I recently found an article describing the argument between console and window managers. I didn't even realize this argument existed though. How much can you really do on just a console? I mean, you can easily navigate and do fundamental computer functions, but there's almost no programs that work without a window. Could you be able to do things like do internet searches and such without X?

Also, it said that window managers proposed a security risk; how dose it do that?

Yeah, actually you can. There are console based browsers like links, lynx or w3m that actually work reasonably well. Obviously you're not getting a lot of the GUI based goodies, but for basic searching and reading, they are definitely functional. Really, when you seriously dig into it, most X programs have at least some console alternatives. During my daily work in bioinformatics, I probably spend about half my time in the console, so you can definitely get serious work done without X.

As for the security risk, all programs have some level of security risk. I'm not sure that window managers are any more prone to them than any other program.

There is a browser, lynx, that is "a general purpose distributed information browser for the World Wide Web" (from the manual page). You can run it in console (or, for that matter, in a terminal window). There are text-based e-mail programs (can't think of the name of any right now), including mail and mailx which work fine when you configure the mail server (no graphics, of course, but who really wants to see advertising anyway, eh?). lynx is standard equipment in Slackware.

Running X doesn't necessarily mean that you have to use, say, KDE (which gets larger and larger and bigger with every release); you can use Xfce (smaller, tighter, quicker, less overhead), you can use others -- look in /etc/X11 plus take a glance through the manual pages for them (there are a bunch that come with Slackware).

I'm not aware of any security risks inherent in window managers (perhaps a link to the article you were reading?).

The article didn't say anything specific. It was mostly just a compare and contrast of the arguments. But thanks for explaining that all to me.

It all depends on what you use Linux and its host for. There are many many applications that are text-mode only. There are many programs that do not not require even a text-mode console and are quite happy to run on a completely headless host. It is all a matter of matching the configuration to the needs.

There are text-mode HTTP browsers and other WWW-related tools. Often these are much easier and more appropriate to use than their pointy-clicky counterparts. The pointy-clicky versions of most classes of tools are rarely capable of running in a scripted mode, thereby dis-allowing any form of automation or non-human-controlled use. For instance, given a long list of URLS (say, a million or ten) referring to some files or other data to download, I think it is quite likely that I could be done quite a bit sooner by putting wget in a looping script than I could by typing the URLs into a web browser and selecting the steps to download and save the data to files. OTOH, I would't be exposed to the pretty pictures, either. If that is important, then the graphical browser wins. It is all a matter of matching the configuration to the needs.

Personally, a great deal of my work is done using text-mode shells for system administration and software development. For that, I use a graphical desktop as a way to concurrently and conveniently run a large number of text-mode consoles in graphics-mode windows on multiple virtual desktops. I also need to use some graphical applications, like the browser I'm using as I write this, some CAD tools, and a GUI front-end to the text-mode debugger gdb. It is all a matter of matching the configuration to the needs.

If your view of Linux is simply a Windows work-alike, then the debate is probably moot. The fundamental basis of Windows is that it is a GUI, so the notion of functionality not involving a GUI is almost nonsensical. Do not forget, however, that Linux itself does not include any GUI or graphical concept. Graphics, whether done with X or other graphics platform are actually just applications run in userspace by a user. Moreover, it is quite possible, and I would say ordinary, for a GUI-using host to also support concurrent logins by other users logging in remotely, using just commandline shells. Many Linux hosts have no capability whatsoever to drive any graphical hardware. They can be running on tiny embedded systems that control machinery, large or small, or they can be in the server rooms of organisations shipping data, or perhaps clusters of number-crunching machines performing data analysis. It is all a matter of matching the configuration to the needs.

Finally, the old 'security risk' argument. I give these arguments little credence, as it is a standard argument used to support almost every religious-style debate ever waged in the computing field. Sometimes it is true, often it isn't, but someone will invariably play the card at some point. The reality is, the more different application software that is used, the greater the risk of introducing a vulnerability, and whether it is a GUI tool or not doesn't contribute much to the statistical basis for the argument.

--- rod.

1 members found this post helpful.

Perhaps the risk it is talking about is related to running an X server and things like having port 111 open?
As to the console with framebuffer you can watch video with mplayer and see images in a text-mode web browser (I forget which one).

While there is the potential to introduce vulnerabilities from any application, mature applications such as X do not add an appreciable risk. Just because an application is listening on some IP port, does not make it inherently risky. BTW, port 111 is the standard port used by RPC, which as far as I know, has no particular relationship to X. X does use an IP port, iff it is configured to accept connections from remote hosts, and this is rarely done; most distros use the '-nolisten tcp' configuration for X. One has to work somewhat hard to overcome this, and it is generally not too useful anyway. The port used by X servers depends on the server number (multiple instances of X can run concurrently on one host under Linux), with the usual port numbering being calculated as '6000 + portNumber'.
--- rod.

Oh my! Compiling source code! You can use a graphical program, an IDE, to compile, but it just adds eye candy to the task of compiling. (Many would say it adds convenience, but that's in the eye of the user.)

The program I use most is Emacs, the editor. It works equally well as a graphics window and in a shell, and I use it in both. The only real advantage the graphical window adds is clipboard integration.

Also scripting! Someone else already made an excellent case for downloading files with wget (or curl), but that's only one of the many, many common tasks that can be handed off to a script if you do it more than very occasionally.

As for surfing the web, you're right. Nothing beats a good browser. I use lynx and links occasionally, but they're no substitute.

And if I did any serious drawing, graphical drawing apps would be more plausible than a command-line equivalent. Though I do occasionally clip parts of images and convert formats with ImageMagick's convert command from the command-line. It's just the easiest way for me. And I've actually converted small images to the textual XPM format, edited them with emacs and converted them back. That was quicker than learning to use the gimp.

As for email, there are people who thoroughly love and swear by mutt, an email client that runs in a shell. I bounce back and forth between it and the graphical Thunderbird.