Sun has put a tremendous amount of effort into its operating system, with the intention of rebuilding both its Unix market share and its relationship with free software developers. This article looks at the impressive new features that make Solaris 10 an amazing operating system and also some flaws that prevent it from being perfect.
Solaris is both the oldest and most modern extant Unix operating environment, but the previous few releases have been somewhat lacking in innovation. Solaris 10 makes up for that by introducing a wealth of new and innovative features that catapult it out of the traditional proprietary Unix market — where HP, IBM, and SGI live — and into the mainstream server and workstation market — the realm of Microsoft, Novell, and Red Hat.
While I was talking to him about some historical Solaris bugs and if they’ve been fixed in version 10 or before (see below), Bryan Cantrill, one of the engineers responsible for the much acclaimed but seldom properly explained DTrace technology, happened to see a question I had written in my notebook: “Why is Solaris 10 ‘the most advanced operating system ever built’ as claimed by various Sun representatives?”
Upon seeing that, Bryan started talking about DTrace and ZFS, and before he got to Containers, I stopped him. “A couple of good features don’t make a whole OS. What’s the big picture with Solaris 10?” I asked.
“Solaris 10 isn’t just a couple of new things, it’s a collection of great, new, unique features,” he began. Jared Jenson, a consultant who works with Sun products, was also participating in the conversation and took over for Bryan. “For me, as a system administrator, Solaris 10 gives me a lot of what I call ‘quality of life features.’ By that I mean that Solaris makes life a lot better for the guys who have to wear the pagers — you do your work more quickly, more efficiently, you find problems and fix them faster, and then you can go home to your family.”
Here are some of the “quality of life features” in Solaris 10:
- Dynamic Tracing (DTrace), a program and framework with an Awk-like command syntax that allows a sysadmin to quickly examine the behavior of the software environment from userland applications down to the most basic level
- ZFS (formerly known as the Zettabyte File System; the term “zettabyte” has nothing to do with this file system, so its official yet meaningless name is now simply ZFS), which was written from the ground up to accommodate modern storage devices and redundancy solutions
- Solaris Fault Management (also called Predictive Self-Healing), which is an integrated framework and analysis system that monitors data for abnormalities, then can isolate the malfunctioning device that is causing the corrupted data and route around it if possible. Since hardware failures are rarely instantaneous, Solaris Fault Management can detect failing hardware before the results become apparent to users.
- Upgraded security: Instead of offering a separate distribution of Solaris for the Trusted Solaris product, Sun has added 80% of the integrated security features of Trusted Solaris to Solaris 10. Trusted Solaris 10 will still be available as a group of add-on packages to the standard Solaris operating environment.
- Vendor-neutral support offerings: This means that, on the high end of its service plans, Sun will support Solaris, all software written for Solaris natively, and all LSB-compliant Linux binaries that users might run on Solaris 10 through the Linux Application Environment (formerly known as Project Janus).
- Process Rights Management: This is a revised and updated permissions structure that allows specific users to have specific root permissions, so if several admins are controlling individual services on the same server, they can be given complete control over their processes and programs without having full root access to the system.
Let’s look at some of the above features in more detail.
DTrace: More valuable than it may seem
I spoke with the core DTrace developers — Bryan Cantrill, Adam Leventhal, and Mike Shapiro — for about an hour at the Sun launch event, and they gave me a personal demonstration.
Cantrill had given a presentation in which the example situation was a serious network performance problem caused by a couple of users that were running inefficiently written stock ticker programs — which were installed with GNOME by default. While this was an actual real-world example of how DTrace tracked down the problem, a top-notch sysadmin would never allow superfluous and potentially insecure programs in a critical production environment. So how would DTrace help on a more tightly controlled network?
Cantrill opened up his laptop computer, booted a recent development build of the AMD64 edition of Solaris Express, and proceeded with a high-energy demonstration of DTrace. First he showed me some broad DTrace output from the command line; it printed output from the more than 32,000 points of instrumentation (also called probes) that give feedback useful for tracking down problems. A traditional ps -a command would have shown only userland processes, which were related to the terminal.
“D, the language that DTrace uses, is a lot like Awk,” he said as he opened up vi and created a short script to execute more complex DTrace commands. He then started the FVWM window manager and showed me everything the system does to open an instance of Xterm by adding a few lines to the aforementioned shell script to give DTrace the proper parameters and switches related to finding only Xterm-related activities. Cantrill noticed from the list of processes that data was being written to the disk upon starting Xterm. “That’s unusual,” he said, noting that there should be no reason to write to the disk at all. So he opened up the shell script again and modified it to find out why Xterm was behaving that way and what files it was writing to. The list that DTrace produced showed that the Bash history file was being written to upon launching Xterm — so it turned out to be something perfectly normal. There were a few things that could have caused the disk write operation, and I’m sure if we’d had time to think about it we could have investigated it in the traditional way and found the answer, but DTrace produced specific results in seconds. This was a rather innocuous example because there was no problem to solve, but with some kind of mysterious performance-related problem, someone who knows DTrace could walk into a strange Solaris 10-based environment with machines and configurations he had never seen before and use it to track the problem down.
Granted, if you have to stop and read the manual and learn how to use D first, you’re not going to track anything down quickly. If you already know Awk and are familiar with Solaris, DTrace shouldn’t be very difficult to learn. Once you have even a moderate understanding of DTrace, on a large network with a lot of machines filled with various programs for various purposes, even if nothing seems wrong, you can fine-tune your Solaris environment by identifying inefficiencies.
More information about DTrace can be found at these addresses:
Some visualization tools are also in development that use DTrace as a foundation.
ZFS
Previously, SunOS employed the traditional and reliable but not quite top-performing Unix File System (UFS) as its one and only file system. Every Unix vendor and BSD variant has its own unique implementation of UFS, and few of them are fully compatible with one another. The trouble with UFS is that it is not terribly scalable; you can’t add a hard drive to a RAID array and expect to easily expand your file system’s capacity without losing data.
Rather than attempt to rework UFS to update it (as FreeBSD has, with UFS2), Sun’s engineers designed a completely new file system technology that took into account modern computer hardware.
ZFS combines the functionality of a file system and a volume manager into one package, so it can control multiple disks without any additional software. It can also do more than just read and write blocks, which is the limit of a traditional file system’s control. ZFS creates a “pool” of storage — disks, presumably — and then that storage is used for a dynamic file system when needed. So there is the underlying pool of storage, then on top of that are as many dynamic file systems as you want to create. If you need more space, just add a disk to the pool and you can grow the file system — safely, with only a few commands in the terminal.
ZFS is also 128-bit, which is exponentially more spacious than most modern file systems, which are 64-bit. While it may seem unlikely that your storage needs will exceed the 64-bit limit of 16 exabytes, computer history is replete with examples of people underestimating growth.
The third primary feature of ZFS is its error-correction capabilities. Each write operation writes to a new block before changing the pointers to commit the write, making it possible to “roll back” data to a previous state. ZFS integrates checksums into the file system structure, which means that data corruption is detected immediately. If the file system is mirrored, ZFS can repair the corrupted data by using the mirrored copy without any user intervention.
Solaris Containers
While not specifically mentioned as a “quality of life feature” in Solaris 10, Containers are still an impressive and useful addition. Like ZFS, Solaris Containers have undergone a name revision; previously they were known alternately as “Zones” and “N1 Grid Containers,” but due to changes in marketing strategy, the feature has been renamed Solaris Containers.
Like BSD jails, Solaris Containers isolate applications and processes from the rest of the system. You can do this for a number of reasons, including security, convenience, and server consolidation. Containers also have superior performance and resource efficiency over a more common alternative, virtual machines, which require an entirely separate instance of the operating system for each virtual unit. Containers use the same kernel and memory that the underlying OS does, and do not reserve any part of these resources. This means that every Container on a system has a single point of failure because they are all using the same kernel. Sun claims that a system can have more than 8,000 Containers, but it’s hard to imagine a scenario in which a number that high would be useful, or a system on which they could run without a significant loss in performance.
Realistically, Solaris Containers are most useful for creating virtual hosts and servers that can perform a variety of separate network tasks in one machine instead of several. You could have your DNS, LDAP, and DHCP servers running in separate Containers, all acting as independent systems. Since each Container can have its own IP address, you could also use Containers for separate hosting accounts on a shared Web server.
New and improved?
Prior to the launch event I got some suggestions from Solaris sysadmins who had specific problems with previous versions of Solaris and had switched to other operating systems where they could. I took the issues mentioned in this SysAdmin to SysAdmin column and the comment attached to it, plus some other notes, and compiled the following list of issues, which several Solaris engineers addressed point by point:
- Solaris is too complex. This was described by the Solaris hackers as being an engineering problem that has been solved by introducing better technology — namely, DTrace to replace other less specific command-line tools, X.org to replace the aging Xsun server, a more streamlined installation procedure, and better documentation. “Documentation is never an afterthought for us,” Cantrill told me.
- If a user belongs to more than 15 groups, the system dies. Cantrill told me that this has long been a tunable parameter in Solaris. “Such that it exists at all, the limitation is due to a protocol restriction in NFS. By default, Solaris is configured to cooperate with other vendors’ NFS implementations — which means setting the number of supplementary groups to 15.”
- NIS netgroups have a size limitation; this forces messy netgroups. This is due to an underlying DBM database issue; the database has a size limit of 1,024 bytes. The best solution is to use LDAP instead.
- If one machine is in two netgroups and both groups have mount privileges, the NFS server crashes. The Solaris engineers tested this and didn’t find the problem; furthermore they had no record of this ever being a bug or problem with any previous editions of Solaris.
- GNOME is poorly implemented. GNOME support has been greatly improved in Solaris 10. The version that ships with the initial release is 2.6.1, and it now uses the Java Desktop System theme by default.
- The version of Netscape included with Solaris is old. Sun has abandoned Netscape in favor of Mozilla.
- Solaris has a poor LDAP implementation. A great deal of work has gone into improving LDAP in Solaris 10. The new implementation is of a much higher quality and has expanded features over previous Solaris implementations.
- If you set up the system to authenticate to NIS, then start LDAP, the system crashes. This bug has been fixed in Solaris 10.
- Solaris is slow. Solaris 10 includes an optimized TCP/IP stack, which now scales much better on multi-CPU systems. Additionally, Solaris 10 has specific performance enhancements for UltraSPARC IIIi and IV systems that can increase performance by as much as 20%.
The catches
Solaris 10’s unique features are only useful if the operating system will install and run on your computer. Sun is not known for supporting a lot of x86 hardware, and Solaris 10 does not alter that reputation. You’re pretty much limited to the hardware in the hardware compatibility list; I’ve tried to get several different custom-built systems to work with Solaris Express over the past few months, and none of them has functioned fully, with the usual suspects being ATI video cards and integrated LAN chips. Unlike previous releases, Solaris 10 supports a fairly wide range of UltraSPARC hardware — especially systems that use the newer IIIi and IV processors. The 64-bit AMD64 edition of Solaris 10 will not be available for another few months.
Solaris 10 will not tolerate Linux partitions on the same drive, so if you want to dual boot, you’ll need a separate hard drive. Speaking of hard drives, I was not able to get an SATA hard drive to be recognized by Solaris Express 10/04 on any of my test systems. Sun told me that Solaris 10 would eventually have SATA support, but didn’t have specific dates or details on which SATA controllers would be supported.
While Solaris 10’s official release is January 2005, it will not initially ship with ZFS functionality. ZFS instead will be included in the first update.
Conclusions
If you’re using a previous edition of Solaris — especially if you’re using a SPARC-based infrastructure — it makes a lot of sense to upgrade to Solaris 10 if your hardware supports it. To begin with, it’s free of charge to download and use it, so the initial cost is nothing. Considering the potential performance increase and such advanced features as ZFS and DTrace, your benefits could include better data reliability and storage scalability, and the ability to track down and eliminate software problems immediately.
If you’re considering a new operating system for your business, Solaris is definitely a candidate. I’d recommend sticking to the hardware compatibility list, and specifically buying only systems that have been certified to work with Solaris 10.
Many people will wonder, “Is Solaris 10 better than Red Hat Enterprise Server 3, Windows Server 2003, and SUSE Linux Enterprise Server 9?” Under most conditions the answer is yes, thanks to the above-mentioned features that are unique to Solaris 10. While SLES9 has Usermode Linux to do operating system virtualization, it requires assigned system resources and doesn’t offer optimal performance. Solaris Containers require only storage (hard drive) space to work and don’t suck up as much system resources, making this feature more efficient while providing similar functionality. ReiserFS v4 may be a significant step forward for Linux file systems, but looking through the feature list on its Web site, I don’t see anything like the ability to add storage space dynamically or integrated checksums to protect against data corruption. ReiserFS v4 is also not 128-bit, so its ceiling is much lower than that of ZFS. DTrace has no equivalent anywhere, as far as I can tell.
It seems that Solaris 10 is a superior operating environment for servers and some kinds of workstations, and Sun’s support options for it are quite ambitious. The only things that hold it back are restrictive licensing and horrible hardware support, but the licensing will soon change as Solaris goes open source, and hardware support is bound to increase as time goes on.
Copyright 2005 Jem Matzan.
I decided to use OpenBSD 3.5 on
my Dell Inspiron 3800 latptop for this exercise instead of Debian,
Slackware, or Gentoo Linux because, in addition to knowing that OpenBSD
worked perfectly on the laptop’s hardware, I wanted to use this
opportunity to get to know OpenBSD a little better. Also, OpenBSD has a
feature that I thought would make my week easier: the
href="http://www.openbsd.org/ports.html">Ports software database.
Ports makes it easy to find and install programs from the command line
– easier for me than Debian’s APT or Gentoo’s Portage systems. I didn’t
know what programs I’d be using, so it was important to have a decent
selection of mail, IRC, and other programs to choose from. OpenBSD’s
Ports tree, while nowhere near as extensive as FreeBSD’s, was more than
adequate; one could even say that it was designed with CLI use in
mind.
I had the advantage of working with people who primarily use the CLI
for everything they do. I asked them for some recommendations and
occasionally for some help, but I didn’t ask to be walked through the
whole experience — that would invalidate the exercise.
Software
The one program that I needed right off the bat was a competent FTP
client. I was used to using the graphical
href="http://gftp.seul.org/">gFTP, which is about as good as they
come in the world of X11, so whatever I ended up with in the CLI had a
lot to live up to. The standard BSD FTP program that’s included in
nearly every operating system is great for transferring single files,
but it’s horrible for uploading or downloading large groups of files.
Brian Jones, author of Linux.com’s SysAdmin to SysAdmin column,
turned me on to NcFTP, which I found
to be an excellent alternative to the old BSD FTP. Configuration was
pretty simple, and I was able to upload and download multiple files in a
queue and save bookmarks to oft-used FTP sites.
Much like the FTP situation, I knew I could use the standard
interface to ircii if
absolutely necessary, but I’d prefer something more like the excellent
XChat2 graphical IRC client. I tried
Epic, but found it to be rather
unremarkable. Digging deeper into Epic’s configuration docs, I
discovered that there are many pre-made configuration scripts for it.
After looking at several of them, I settled on
href="http://darkstar.prbh.org/">DarkStar; while it wasn’t
everything that I wanted, it worked better than what I’d had previously.
I used Epic and DarkStar for the first two work days of my week in the
CLI.
The biggest challenge I had was with email. I was used to Evolution,
which runs my personal and business contacts, calendar, and email. I
didn’t mess with calendar or contacts programs because I didn’t think
I’d need them for the week, but I did explore text-based email
programs.
BSD Mail comes standard with OpenBSD, but its operation and
configuration were a mystery. I could read local email, but I ran into
difficulty trying to configure it to receive POP3 mail. Even if I’d
gotten it to work perfectly I’d have to take notes on all of the
shortcut keys because there are no on-screen helper menus; you’re left
at a prompt with a list of messages. I wasn’t against learning how to
use it, but with so many other programs to have to remember key commands
for, it seemed like a better idea to simply try a different email
client.
I set up Mutt to receive POP3
email from one of my accounts; I have eight POP3 email accounts that I
need to collect all in one inbox. The Mutt configuration file is
gigantic; there are so many settings that it took an hour just to read
through each option and its description. The manual page is equally
gargantuan. It’s nice to have a lot of features, but if I have to crawl
through pages and pages of options that I’ll never use just so I can
learn how to do the simplest of tasks, I can safely declare the program
useless to me.
I tried Pine, but that
was just the opposite of Mutt — the interface was so simple that I
couldn’t figure out how to get multiple accounts into it. I could hardly
configure it for one account, even after reading the
instructions.
The trouble with the email programs that I tried is that they are
designed primarily for two kinds of people: those with one email account
who need a bonanza of options that deal with mailing lists, and those
who are concerned only with local system or LAN mail. In other words,
they were made for developers and sysadmins.
I was considering giving up, but a friend suggested that I install
href="http://catb.org/~esr/fetchmail/">Fetchmail and use it to send
all of my POP3 email to my local username. That’s exactly what I did,
and it was a lot easier than I thought it would be. Reading the
Fetchmail manual page was less daunting a task than I’d anticipated, and
I had Fetchmail retrieving all of my POP3 mail inside of an hour. I
created a config file that would regularly retrieve mail from all eight
accounts and then pass it all on to my local user account. This cut out
all configuration difficulties that I’d had with my email programs
because all three could receive local mail by default. Mutt didn’t seem
so useless to me after that. My only complaints about Fetchmail are that
I never figured out how to set it to leave all mail on the server unless
it had already been downloaded, and I couldn’t get it to delete mail
from the server that I deleted locally. I like to save all non-spam
email as a reference.
The vi editor comes standard with pretty much every Unix, BSD, and
GNU/Linux operating system. If you know how to use it, it’s a powerful
and convenient editor to have; if you don’t know how to use it, it’s an
archaic, non-intuitive piece of garbage. My previous opinion of vi
tended toward the latter, but I figured that now was the time to learn
how to use it properly. Instead of vi, I installed vim from Ports
because I wanted to take advantage of its syntax highlighting and
automatic indent features, among other various improvements. The first
thing I did was to run the vim tutorial to learn vim’s finer points. I
got most of the way through it before I learned everything I needed to
know to work on HTML documents and configuration files. Since I already
know how to insert, delete, save, and quit, the supplementary commands
that I learned were easy to remember. Of all of the programs I used in
my week in the CLI, I spent the most effort learning to better use vim.
I considered using Emacs — in fact it was my first choice, because I
knew slightly more about it than I did about vi, but I couldn’t get a
non-X version installed through Ports. Emacs is also not quite as
universal as vi is, and I wanted my learning to apply to as many systems
as possible.
I’d heard of GNU
Screen, but I didn’t think I’d ever need to use it. I couldn’t
imagine needing more virtual terminals than what were provided by
default. On the other hand, I didn’t anticipate working from the command
line full-time, and it didn’t take me long to figure out that it was
worth the effort to install and learn Screen. I was amazed at how easy
it was — all I needed to know was how to start Screen, how to open new
terminals within it, and how to switch between them. It took five
minutes to read through the help file, and soon afterward I had my IRC
client and Mutt running in TTY1, two instances of vim open in TTY2, and
four or five instances of Lynx open in TTY3. TTY4 was for other command
line tasks, should they become necessary. This remained my preferred
configuration for the rest of the week.
I used Lynx as my browser; I
don’t really like Lynx, but what else is there? By the time I got to
learning Lynx, I was struggling to remember all of the command keys for
all of the programs I’d installed. I was so disgusted by the fact that
the Web was no longer graphical that I avoided Web activities as much as
possible.
Lastly, I used cplay
to play Ogg and MP3 files while I worked. It’s the one program that I
didn’t need to read the documentation for, and it didn’t need a
mile-long config file either.
Putting it all into production
I spent the weekend setting all of this up, experimenting with
alternative programs, and messing with config files. I didn’t make a
whole lot of progress before Monday, and needless to say I didn’t get
much work done at first. Well, actually, I didn’t get much work done all
week because of the snags I ran into.
The most difficult part about using the CLI for production desktop
work is using the Web. To me, the World Wide Web was made to be
a graphical experience, and it should always be that way. Once you’ve
gotten used to Mozilla, you can’t really switch to Lynx and enjoy it.
Lynx is purely for the retrieval of necessary information — you use it
when you really need to read something (like documentation) on the Web
and you can’t get to X. My colleague
href="http://www.railfan.ca/">David “cdlu” Graham tipped me off to a
console graphics display package called
href="http://www.svgalib.org/rus/zgv/">zgv which would allow Lynx to
show pictures in Web pages. Unfortunately it doesn’t seem to be in
OpenBSD’s Ports tree, so even if I’d known about it, it would have been
difficult or impossible to install.
One trouble I ran into with IRC was the inability to scroll up
through a conversation, something that I rely on in XChat2 to get me up
to speed. The best I could do is look through the log with the
/lastlog command and hope that my search string didn’t
match more lines than I had screen space. When I mentioned the problem,
David Graham gently chastised me for not increasing my screen size from
the default (VT100 emulation, which also didn’t support color) to
something higher. I hadn’t even thought about changing the resolution;
ever since the dark days before Linux (and Windows) I was used to the
standard DOS 80×24 screen and figured that it was just the way things
were outside of the GUI.
About the only program I never had any problems with was vim. It
always did what I needed it to do, from writing articles (the first half
of this article was written in vim from my OpenBSD machine) to creating
and editing configuration files. It won’t replace Bluefish for my Web
work, but it was certainly one of the most important programs for me to
have. Sure, vi or the BSD ee editor could have done some or all of the
same work, but they wouldn’t have been as nice to use. Syntax
highlighting is practically a necessity once you’re used to using
it.
At some point I switched from DarkStar/Epic to
href="http://irssi.org/">irssi, a Perl-based IRC client. while it
didn’t have the nice auto-notification of incoming email that Epic had,
it was easier to use and configure, and it had a number of other
features (such as timestamping by default) that I enjoyed. It’s not that
I couldn’t eventually program Epic to do what I wanted it to do; the
issue was that I couldn’t do it inside of an hour. I don’t want to read
a 50-page manual and Google my questions for hours just to do a few
simple tasks. I’d rather have a program that simply works the way I want
it to.
Of all the things I’ve lost, I miss my mouse the
most
It didn’t occur to me to use the mouse in the CLI — as far as I was
concerned, the mouse was a tool meant for graphical environments. I
didn’t use a mouse until Windows 3.0 (except in some DOS games) and I
didn’t anticipate needing one in a BSD terminal. Since I couldn’t scroll
any windows with it and couldn’t use it to switch between programs, I
didn’t notice its absence at first.
The trouble was, I needed to copy and paste URLs from Lynx to vim,
and there seemed to be no way to do it without highlighting the address
with a mouse and then pasting it into another terminal by clicking both
mouse buttons. A laptop’s built-in touchpad or directional button is not
well-suited to this task. I didn’t realize how often I used the mouse
until it was gone.
Without being able to easily add links to articles, I was unable to
complete any of my work. I did write the text portions, adding in href
tags where the links would need to go. I then emailed the articles to
myself and when I got home, I added the appropriate links in Bluefish. I
guess you could say that I cheated, but I had to get some work done.
Keyboard navigation wasn’t all that difficult to get used to,
especially after I had my GNU Screen setup properly organized. I could
switch back and forth between different terminals rapidly, and scroll up
and down documents in vim without forgetting to leave or enter insert
mode. Although I reached a certain level of proficiency, I don’t think
that any amount of experience in the CLI could have replaced the
convenience of mouse navigation in GNOME.
Home sweet GUI home
While I had fun learning new programs and new tricks, I missed all of
the functionality and finesse of GNOME. I don’t know whether it’s just
that the programs I can use in X are easier to configure, use, and
multitask, or whether I’ve lost my love for the command line.
I started out my computing life in the CP/M and MS-DOS command line
interfaces, and was dragged kicking and screaming into Windows 95 some
years later. At the time I thought of the GUI as a memory-hogging,
inconvenient, impossible to configure, buggy, and in general useless
layer on top of a simple CLI environment that I knew and enjoyed.
Somehow I thought that going back to a more powerful and flexible
command line years later would rekindle my desire for a return to the
DOS days.
My DOS machine did everything I needed it to do. If I had a new
program or game, I knew how to install it and run it, and all
configuration was usually done either from within the program itself, or
from an external configuration program. There were no config files to
hack, and I never once had to read the documentation to figure out how
to use a DOS program. In other words, they were designed sensibly, with
the user in mind.
Many of the BSD and GNU programs that I used during my week in the
CLI, especially all of the mail and IRC programs, almost seemed designed
to be archaic and difficult to use by default. I would have found my
week more enjoyable with programs that were easier to configure, or at
least easier to find relevant information in the manual pages or help
files. I have no problem with reading documentation, except when it’s
dozens of pages long and hides the most critical and basic options and
information amid a big steaming pile of superfluities.
Program design — and of course my own ignorance of such advantages
as Linux terminal emulation, higher terminal resolutions, and the zgv
terminal graphics viewer — aside, there’s also an underlying roadblock
to get past when switching to the CLI: it’s a whole different way of
thinking. Using a GUI makes you think in a broader, more synthetic, and
object-oriented way. It’s not just that the programs look prettier and
have more convenient mouse-driven features — it’s that you
think of your programs and data in terms of how they look on
the screen. In the command line you’re forced to think in a more
analytical way; you have to picture where your data is, where you want
it to go, and how you want to view or manipulate it. The GUI tends to
make you think in terms of programs and what they can enable you to do
with your data; the CLI tends to make you think in terms of data and
what you need to do with it. The GUI causes you to ask yourself how
something looks, whereas you’re using a more kinesthetic sense
when working in the CLI. I’ve come to believe that it is not just a
terminal interface, it’s a whole different kind of user environment, and
it’s not for everyone.
Using the CLI for a week seemed to me like a survival retreat in the
remote wilderness. It was fun and challenging, but I’m glad to be back
home where I can go back to what works best for me. I’ll definitely
revisit the command line as a user environment, but only at my leisure
– not while I’m supposed to be getting work done. I encourage readers
to try this out on their home machine — if not for a week, then at
least for a few days. Hopefully you’ll find my experiences and advice to
be a good starting point in your own CLI adventures.
Discuss this article or get technical support on our forum.
Copyright 2004 Jem Matzan. Verbatim copying and redistribution of this entire article are permitted without royalty in any medium provided this notice is preserved.
