Pages

September 10, 2007

(Intermisssion)

I am going to take a short break from posting because:
  1. I need to concentrate on preparing course material for the new semester, and
  2. I think I’ve amassed enough stuff here now that I need to convert the site to a more browseable interface.
There’s lots more to come. Be back soon.

September 09, 2007

*nix and GUI

When you install a Windows or OS X system, you get a big, integrated package that gives you a graphical user interface, a desktop with a trashcan, a system of standard windows, etc. All the bits that make this happen seem to magically work together to give you the OS's experience, and it all happens without the user having any idea exactly what's going on.

This is so not the *nix way. Part of the *nix philosophy is to write something that does one thing, but does it well. Then that one thing gets used in a bigger thing that does one (bigger) thing well, and that thing used in another, etc. This is a fairly common development methodology, but the difference when it comes to *nix is that all the little bits that make up a Big Thing are released as independent entities, very frequently with access to the underlying source code.

This has a few interesting ramifications. The biggest is that it facilitates iterative refinement of sub-modules. Since a sub-module is a distinct entity from the higher-level entity that uses it, someone can refine the sub-module without having to keep things in sync with people maintaining the higher-level entity. Another is that it minimizes the need to duplicate effort. If you (as a programmer) have access to a widget that, say, lets you do all sorts of neat networking things, then you don't have to develop the code that does that yourself.

This is all very interesting if you are a programmer, but if you have no interest in developing *nix programs then why should you care? Well, if your interest is only in using your computer, then it will still have impact your life. The biggest of these is that you will need get used to the idea that things you used to think of as monolithic entities are actually made up of smaller bits that you will have to deal with independently.

The most important example of the above is the way *nix systems set up graphical user interface environments. In a Windows or OS X install, you get a massive package that delivers a complete graphical user experience. However, in the case of *nix, it's all broken into its various little bits, the most important of which are listed below.

Most *nix GUI-based systems have the following components:

A window system. A window system provides your computer and OS a bare-bones way of making graphics go. It gives other programs a standard way of interfacing with a system's graphical abilities. The most common *nix window system specification is the X Window System, and the most recent version of this protocol is called X11. The two most popular open source implementations of X11 are X.Org and XFree86.

A window manager. A window system provides only a very basic way of communicating with a computer's graphics system. A window manager builds on this by providing the kinds of window features we are all used to now: windows with title bars that have "close", "minimize", and similar buttons, etc. You only need to install one window manager to make the system go; in spite of this, there are billions and billions of different *nix window managers, each trying to address some niche scenario and/or let a programmer prove his/her mettle. Some popular window managers for the X Window System are Blackbox, Fluxbox, FVWM, IceWM, Openbox, and Sawfish.

File managers. A file manager lets you browse and (typically) open files installed on your system. Popular *nix file explorers include PCMan File Manager, ROX-filer, Thunar, XFE, Konquerer, and Nautilus.

Taskbars and pagers. Windows users are used to having a taskbar at the bottom of the screen to help with launching programs and keeping track of what's open. OS X users have a menu bar at the top of the screen and a Dock at the bottom that serve a similar purpose. These kinds of things are independent entities in the *nix world. Popular *nix taskbars and pagers include bbpager, fbpanel, F***inf Small Panel, PyPanel, GNOME Panel, PerlPanel, and Xfce4 Panel.

Display managers. Do you want to be able to login to your computer using a graphical user interface? Then you will need a display manager: GDM, KDM, and XDM are popular examples.

Misc. Do you want to put icons on your desktop? Then you will need a program that makes that happen. Do you want a trashcan? Then you will need a program that implements that as well. Do you want a screensaver? I think you are beginning to get the idea.

Integration
Many popular window managers break with the strict *nix tradition of compartmentalizing functionality and instead integrate some of the above functions. For example, Fluxbox and IceWM have their own built-in taskbars. Going even beyond this, there are packages that incorporate most of the above functionality into a complete comprehensive desktop environment, which is what Windows and Macintosh have been doing all along. The most popular *nix desktop environments are GNOME, KDE, and Xfce.

Most Linux distributions include a default desktop environment, usually GNOME or KDE. For example, Ubuntu is based on GNOME and Kubuntu is based on KDE. This approach simplifies things for the end-user by delivering in one integrated package the basic GUI features that many users have come to expect. The downside to GNOME and KDE is that, like Windows XP/Vista and Mac OS X, they are resource intensive. On a low-end machine, these environments will deliver very slow performance. Xfce (used in Xubuntu) is less resource hungry than GNOME or KDE, but even it is a bit too heavy for many older machines.

Why-oh-why?
The conventional way of installing a GUI system on *nix is a tweaky process. That is a big turn-off for many users, your grandmother in particular. However, it does let you create a custom mix of all the various bits and pieces that make up the desktop experience using only the most efficient but still usable alternatives. And that will let us build a modern, solid and usable system that runs on obsolete hardware.

September 07, 2007

Ground rules

I was having a really tough time getting things going until I found an article on adapting Ubuntu to low memory situations at Ubuntu’s community documentation site. The basic idea outlined there is to install a text-based system and then manually add lightweight GUI stuff and other applications. One cool thing about this is that we don’t need to limit ourselves to an Ubuntu based install: since Ubuntu is itself based on Debian, it should be possible to do with Debian what the article suggests doing with Ubuntu. The article also mentions the possibility of installing Xubuntu and then replacing the heavier items with lighter alternatives.

So, overall this gives us three different promising paths to follow:
1. A text-based Ubuntu install plus a manually installed GUI environment.
2. A text-based Debian install plus a manually installed GUI environment.
3. A full Xubuntu install with unnecessary stuff removed and heavier items replaced with lighter alternatives.

Approaches similar to the above should also be possible using any other major distribution. However, at this point I want to limit myself to Ubuntu and Debian. These are two very well-supported distributions, and I don't see what will be gained by considering other distributions. Of the major Linux distributions, Ubuntu is the most consumer-oriented. Debian is an attractive alternative to Ubuntu because Ubuntu has a reputation for doing some things in a slightly non-standard way; Debian is an accepted, established, and carefully maintained standard that may overcome some problems presented by using Ubuntu.

I have been working mostly with parallel installs based on 1. and 2. I will postpone working along path 3. until after I have a better understanding of what’s going on. An additive approach to functionality lets you learn what each package, etc. does and gives you a more fully integrated idea of what’s happening. A subtractive approach only tells you what’s not needed—and it doesn’t guarantee that you have a minimal set of what is required. However, I will probably play around coarsely with an Xubuntu install before I have a really good idea what's what to see what might be possible along that path.

September 05, 2007

Why Debian?

At the moment, I am working exclusively with Ubuntu and Debian as bases. Why Debian?
  • Because Ubuntu is based on Debian.
  • Because Debian is solid.
  • Because Debian isn’t in a big hurry to offer bleeding-edge (and therefore slightly rough) packages.

Why Ubuntu?

At the moment, I am working exclusively with Ubuntu and Debian as bases. Why Ubuntu? Because of the major distributions I have investigated, Ubuntu is the most consumer-oriented.

Why Linux?

There are quite a few gratis operating systems. Given the wide range of options, why settle on Linux?

It’s an obvious question. Here are some obvious answers:

1. It’s free. For the present purposes, gratis is more important than libre.
2. It’s active. There are millions of monkeys pounding out millions of lines of Linux-compatible code.
3. It’s supported. In particular, precompiled binaries of *nix programs are widely available for Linux. (Compile-it-yourself may be a good option for compugeeks, but it is not a solution for a consumer-oriented system.) Also, there are lots of community-based forums (fora?), wikis (wikia?), and the like (lika?) offering technical assistance.

Good reasons for not using Linux are discussed at the swax project website. In spite of these reasons, I feel Linux holds the best potential for the present purposes. Time will tell…

September 03, 2007

Linux as Desktop OS

I suspect one of the biggest problems with Linux for personal computing* is that *nix operating systems were never designed for this application. *nixes have their roots in large-scale Systems managed by officially sanctioned System Administrators. This has produced a *nix way of doing things, at heart of which is “Thou Shall Let Only Thy SysAdmin Manage Thy Resources.” And just to the right of that is, “Text, man… it’s all in the text.” The *nix way of configuring things is through text files. Lots and lots of text files, in lots and lots of different places, many of them controlled by the God SysAdmin.

*nix’s infatuation with texfiles is both good and bad. It’s good because it’s easy to open/edit/fix/replace plain text files. You don’t need a special configuration editor or “regedit”-like program to maintain your system. It's bad because hacking text is usually not the most intuitive way to configure something and it makes it easy to introduce syntax errors. It's even more bad because if you wanna change something, you need to start looking for the right text file to tweak, and then hope to God you don’t need to be God to change it or that you can convince the master gatekeepers that God sent you. This is the spirit of *nix.

I wonder if the *nix take on system management was a major reason that Apple decided to forego the X Window System in OS X (ironic, really, given the name) and write their own window system. By writing their own window system, maybe Apple was able to bypass a lot of the user and developer *nix inconveniences while still retaining a BSD core. Or not.

In any case, the *nix way of doing things (including the X Windows System) doesn’t mean that Linux can’t form the core of a consumer-oriented PC operating system. Canonical’s Ubuntu proves this. Ubuntu does a very good job of wrapping the *nix way of doing things in user-friendly, user-managed interfaces. But in spite of these wrappers, you can still sense residue in the form of a bit of klunkiness and hoop-jumping-ness. Given the amount of work Canonical have put into their effort, I think it’s fair to expect that any other approach, and especially a home-brewed one, will be much more klunky. So if you are planning to install a conventional Linux system (as am I), don’t expect as smooth sailing as provided by Windows or OS X or even Ubuntu. Be prepared to jump through hoops on a semi-regular basis and try to learn and even love the process. Once you get a feel for how *nix works, it’s not nearly as sucky as it seems at the start.

*By this I mean a desktop or laptop computer used by at most a family-size group of people, networked to at most a family-sized network, and administered by one or more of the users themselves.

September 02, 2007

Goals

It would probably be a good idea at this point to outline in greater detail what the goals of this little undertaking are. In no particular order:

A Windows 98 alternative. As mentioned on the About page, the primary goal here is to find or develop an operating system for Intel-based machines that are too limited in resources to support Windows XP (or, by extension, Vista) or Canonical’s Xubuntu (or, by extension, Ubuntu).

Windows 98 UI reproduction not a goal. While the goal is to find an OS that is an alternative to Windows 98, reproducing the Windows 98 user interface is not a criterion. I consider it acceptable for the user to have to change the way he or she is used to doing things, in much the same way one would need to adapt to OS X from Windows or vice-versa. By the same token, a solution that resembles Windows 98 or XP (or Mac OS X or OS 9 or any other system for that matter) is fine as well.

Usability. The fact that reproducing the Windows way of doing things is not a goal does not mean that usability is not a goal. Quite the opposite: while the ultimate solution does not need to resemble any popular OS, it must be easy to use by typical computer users. Pushing the envelope to include your grandmother would be great, but I have something closer to my cousins in mind instead as target users.

End-user management. The system needs to be manageable by end-users, not system administrators. It shouldn’t be assumed that the end-user will be satisfied with the applications and configurations that are included in the default distribution/installation. Indeed, this is where a lot of Linux distributions fall short. Many of them essentially place the distribution packager in the role of System Administrator, and that’s not gonna cut it for my purposes.

Stability. It’s gotta be stable enough for everyday use.

At this stage, I don’t want to get into specifics about what particular activities and services the system needs to support. I will merely say that the system should support the kinds of activities and services that are expected from a modern consumer-oriented OS. In reality, it’s going to come down to what I can get away with on the limited hardware.