October 29, 2007
Fluxbuntu--login manager followup
I just did some poking around and discovered that Fluxbuntu uses SLiM for login management. I don't know much about SLiM, but knowing this much is a good thing.
Fluxbuntu--first impressions
I downloaded the latest Fluxbuntu over the weekend and gave it a very quick spin. Here are some very hasty first impressions.
The worst news is that I could not get this "Gutsy Gibbon" Fluxbuntu release candidate to install on my old laptop. I haven't been able to get the "Gutsy Gibbon" release of Xubuntu to install on that laptop either. In both cases the problem is the same: the installer (after booting from the CD and prompting me for a bunch of info) cannot find a valid CD drive when it comes to doing the actual install work. I guess this is a typical example of Linux's hardware temperamentalness. The weird thing is that I have no problem installing older versions of Xubuntu on the same machine. Gnarly.
Anyhoo, I instead installed Fluxbuntu using Qemu (via Qemu Manager) on my workhorse laptop (1.7 GHz Intel Centrino with 1.5 GB RAM). The emulation was set up to use 128MB RAM, so this should give a reasonable idea of what would happen in a slim system. Doing some very rough benchmarking suggests that the effective clock rate of this setup is around 800 MHz. If I turn off all acceleration, then it drops down to something like 300 MHz.
Anyhoo, anyhoo, the installation went fairly smoothly--except for it asking me to install native language files for an English language install. Now for the report card.
First, the worst part. Startup is slower than expected. A lot slower. Like, "Is it working?" slower. But in the end it does start up. I wasn't able to tell what DM they are using yet, but it has been Fluxbuntu branded and it looks pretty nice. Still, the slowness may be due to a DM that's more bloated than it really needs to be. Or it may be because there's a lot of daemons, etc. starting up. The weird thing is that Xubuntu doesn't take as long to get going.
Once inside, you are presented with a very attractive desktop. I noticed some sluggishness, so I disabled the soothing wallpaper in favor of a solid backdrop. That seemed to help a bit.
I set up the emulated screen with 800x600 resolution, and sure enough one of the problems that I have seen with a lot of distributions manifested itself here as well: DPI ambiguity. Almost all 800x600 screens are physically 75 dots-per-inch screens, but they are treated as 100 DPI by some applications in many Linux installations. I solved this problem on the system(s) I have been developing by adding explicit DPI configuration information to the files that affect X-server startup (I am using XDM). This seems to solve the problem for all but the oldest or worst designed programs. In theory this should be possible with whatever DM Fluxbuntu uses as well, but it require some more research to find out 1. what DM they are using and 2. how to change the config stuff. (In fact, given the slow startup that I have already mentioned, it may make sense to just replace it with XDM because it is leaner than anything else I know.)
I found it interesting that the Fluxbuntu people opted to use ROX-filer for file management and managing desktop icons; they are also using Leafpad as the default text editor and settled on Abiword and GnuMeric. It's interesting because I have settled on exactly the same applications for the same, er, applications.
However, for web browsing Fluxbuntu uses Kazehakase rather than Firefox or Iceweasel. I will need to use it a bunch more to see what it's like. Fluxbuntu uses a similarly obscure email client, Claws, rather than the now-classic Thunderbird.
One thing that I will need to test is what happens to the non Debian-menu menu items in the Fluxbox menu after installing new apps.
My impression so far is that Fluxbuntu looks promising, but it will need some tweaking if it's going to work on PII-era machines.
The worst news is that I could not get this "Gutsy Gibbon" Fluxbuntu release candidate to install on my old laptop. I haven't been able to get the "Gutsy Gibbon" release of Xubuntu to install on that laptop either. In both cases the problem is the same: the installer (after booting from the CD and prompting me for a bunch of info) cannot find a valid CD drive when it comes to doing the actual install work. I guess this is a typical example of Linux's hardware temperamentalness. The weird thing is that I have no problem installing older versions of Xubuntu on the same machine. Gnarly.
Anyhoo, I instead installed Fluxbuntu using Qemu (via Qemu Manager) on my workhorse laptop (1.7 GHz Intel Centrino with 1.5 GB RAM). The emulation was set up to use 128MB RAM, so this should give a reasonable idea of what would happen in a slim system. Doing some very rough benchmarking suggests that the effective clock rate of this setup is around 800 MHz. If I turn off all acceleration, then it drops down to something like 300 MHz.
Anyhoo, anyhoo, the installation went fairly smoothly--except for it asking me to install native language files for an English language install. Now for the report card.
First, the worst part. Startup is slower than expected. A lot slower. Like, "Is it working?" slower. But in the end it does start up. I wasn't able to tell what DM they are using yet, but it has been Fluxbuntu branded and it looks pretty nice. Still, the slowness may be due to a DM that's more bloated than it really needs to be. Or it may be because there's a lot of daemons, etc. starting up. The weird thing is that Xubuntu doesn't take as long to get going.
Once inside, you are presented with a very attractive desktop. I noticed some sluggishness, so I disabled the soothing wallpaper in favor of a solid backdrop. That seemed to help a bit.
I set up the emulated screen with 800x600 resolution, and sure enough one of the problems that I have seen with a lot of distributions manifested itself here as well: DPI ambiguity. Almost all 800x600 screens are physically 75 dots-per-inch screens, but they are treated as 100 DPI by some applications in many Linux installations. I solved this problem on the system(s) I have been developing by adding explicit DPI configuration information to the files that affect X-server startup (I am using XDM). This seems to solve the problem for all but the oldest or worst designed programs. In theory this should be possible with whatever DM Fluxbuntu uses as well, but it require some more research to find out 1. what DM they are using and 2. how to change the config stuff. (In fact, given the slow startup that I have already mentioned, it may make sense to just replace it with XDM because it is leaner than anything else I know.)
I found it interesting that the Fluxbuntu people opted to use ROX-filer for file management and managing desktop icons; they are also using Leafpad as the default text editor and settled on Abiword and GnuMeric. It's interesting because I have settled on exactly the same applications for the same, er, applications.
However, for web browsing Fluxbuntu uses Kazehakase rather than Firefox or Iceweasel. I will need to use it a bunch more to see what it's like. Fluxbuntu uses a similarly obscure email client, Claws, rather than the now-classic Thunderbird.
One thing that I will need to test is what happens to the non Debian-menu menu items in the Fluxbox menu after installing new apps.
My impression so far is that Fluxbuntu looks promising, but it will need some tweaking if it's going to work on PII-era machines.
October 27, 2007
Fluxbuntu
The Fluxbuntu project has released a candidate "Gutsy Gibbon" (7.10) version of their Ubuntu-based "lightweight, productive, agile, and efficient" distribution. If they've done their homework, they may have made my little odyssey moot. You will recall that I started this whole adventure because I wasn't able to find a light-and-lean Linux distribution that floated my boat. I will download the ISO over the next few days and let you if Homer is headed back to Ithica.
Diverge, diverge
I'm noticing some strange behavior with my Openbox+ROX+fbpanel setup. In particular, when you restore windows after hiding them with fpanel's "show desktop" button, they come up in a strange way. It's pretty much not acceptable behavior ... So I am back to considering IceWM+ROX and Fluxbox+ROX.
There are a few more things that need to be ironed out with the Fluxbox setup (e.g., getting CPU and net transfer metering setup ... using Conky? Slit-widgets?). I like Fluxbox's aesthetics and aesthetic opportunities better than anything I've seen with IceWM, but I am not convinced as to its usability. I think ultimately some user testing will be needed to determine whether an IceWM or a Fluxbox-based solution will be best.
There are a few more things that need to be ironed out with the Fluxbox setup (e.g., getting CPU and net transfer metering setup ... using Conky? Slit-widgets?). I like Fluxbox's aesthetics and aesthetic opportunities better than anything I've seen with IceWM, but I am not convinced as to its usability. I think ultimately some user testing will be needed to determine whether an IceWM or a Fluxbox-based solution will be best.
October 25, 2007
Converge, diverge
Things were beginning to converge and congeal up until last week, but now they have begun to diverge again.
First, I was settling on a solution using an Ubuntu/Xubuntu command-line system as the base. But I am running into some difficulties with some of the non-standard ways that Ubuntu/Xubuntu handles some things--having no real "root" for starters. This is making it harder to get e.g. sound going in this context.
So... now I am working with a minimal Debian install in the hopes that it will be less irregular and more completely documented. (Ubuntu/Xubuntu doesn't need to document a lot its inner workings because they wrap those workings in GUI goodness. It's only to people with geek interests like me that it matters.)
Another alternative I am considering is starting with a full Xubuntu install and then stripping away the heavy bits and replacing them with lighter ones. But I think I am going to try working with building up a command-line based Debian install first. If I can get this to go without too much pain, I think it will make future maintenance a lot easier.
Second, I was settling on IceWM as a window manager/desktop environment solution because it does both in one swoop, integrates some widgets as well (CPU load, etc.), and does it at a very low cost. But I am having a hard time accepting the way it structures its program launching menu. The default setup is kind of klunky and modifying it involves hacking a text file. Also, even though the whole package is theme-able, I have yet to see a theme for the taskbar that makes me really love the visuals. It's a good solution for sure, but I am wondering if there is better.
One option I have considered on-and-off is Fluxbox. It's configuration isn't that awful mostly because there are nice GUI tools available to help you. But the WM's behavior doesn't feel 'right' to me. For example, the right-click nested menu options are tweaky to navigate no matter what theme you use. I have yet to figure out exactly why this is so, but I suspect the nested menus are a bit too eager to let go of their states. Also, while I think Fluxbox's panel looks really neat, I don't like the way open windows are dynamically sized on it starting from 100% for one window and then shrinking linearly. Finally, to make it work with ROX-filer (the leading contender for file management) you have to use ROX's "Blackbox hack." And even then I've seen one or two weird things happen. Still, it's worth keeping an eye on.
The option I am currently most seriously considering is a combination of Openbox and fbpanel. Openbox is fast and lean; fbpanel can be made to look good fairly easily, isn't a total pain to configure, and handles default menus in its program launcher better than IceWM. fbpanel isn't as lean or as widget-full as IceWM's taskbar, and I don't completely love Openbox's context menus or the poor frame grab hints, but the combination is a credible alternative to IceWM and is worthy of further exploration.
I looked at PerlPanel and PyPanel as alternatives to fbpanel. PerlPanel is awesome in the configurability department, but it's quite a memory monster and it no longer seems to be actively maintained. PyPanel was just weird. Maybe I need to spend more time with it, but its default setup was nearly unusable with Openbox+ROX.
I also made an Openbox+ROX-desktop detour (using ROX-Session) but had setup issues that no end-user would want to have to deal with. I love the ideas behind a lot of what the ROX project is trying to do, but I am not sure they've got the implementation quite right yet. So unless ROX's desktop setup gets better organized, I am not going to further investigate that route right now.
First, I was settling on a solution using an Ubuntu/Xubuntu command-line system as the base. But I am running into some difficulties with some of the non-standard ways that Ubuntu/Xubuntu handles some things--having no real "root" for starters. This is making it harder to get e.g. sound going in this context.
So... now I am working with a minimal Debian install in the hopes that it will be less irregular and more completely documented. (Ubuntu/Xubuntu doesn't need to document a lot its inner workings because they wrap those workings in GUI goodness. It's only to people with geek interests like me that it matters.)
Another alternative I am considering is starting with a full Xubuntu install and then stripping away the heavy bits and replacing them with lighter ones. But I think I am going to try working with building up a command-line based Debian install first. If I can get this to go without too much pain, I think it will make future maintenance a lot easier.
Second, I was settling on IceWM as a window manager/desktop environment solution because it does both in one swoop, integrates some widgets as well (CPU load, etc.), and does it at a very low cost. But I am having a hard time accepting the way it structures its program launching menu. The default setup is kind of klunky and modifying it involves hacking a text file. Also, even though the whole package is theme-able, I have yet to see a theme for the taskbar that makes me really love the visuals. It's a good solution for sure, but I am wondering if there is better.
One option I have considered on-and-off is Fluxbox. It's configuration isn't that awful mostly because there are nice GUI tools available to help you. But the WM's behavior doesn't feel 'right' to me. For example, the right-click nested menu options are tweaky to navigate no matter what theme you use. I have yet to figure out exactly why this is so, but I suspect the nested menus are a bit too eager to let go of their states. Also, while I think Fluxbox's panel looks really neat, I don't like the way open windows are dynamically sized on it starting from 100% for one window and then shrinking linearly. Finally, to make it work with ROX-filer (the leading contender for file management) you have to use ROX's "Blackbox hack." And even then I've seen one or two weird things happen. Still, it's worth keeping an eye on.
The option I am currently most seriously considering is a combination of Openbox and fbpanel. Openbox is fast and lean; fbpanel can be made to look good fairly easily, isn't a total pain to configure, and handles default menus in its program launcher better than IceWM. fbpanel isn't as lean or as widget-full as IceWM's taskbar, and I don't completely love Openbox's context menus or the poor frame grab hints, but the combination is a credible alternative to IceWM and is worthy of further exploration.
I looked at PerlPanel and PyPanel as alternatives to fbpanel. PerlPanel is awesome in the configurability department, but it's quite a memory monster and it no longer seems to be actively maintained. PyPanel was just weird. Maybe I need to spend more time with it, but its default setup was nearly unusable with Openbox+ROX.
I also made an Openbox+ROX-desktop detour (using ROX-Session) but had setup issues that no end-user would want to have to deal with. I love the ideas behind a lot of what the ROX project is trying to do, but I am not sure they've got the implementation quite right yet. So unless ROX's desktop setup gets better organized, I am not going to further investigate that route right now.
October 09, 2007
Hammered
My "short break" from making entries is going to be longer than I expected. I've been hammered with an especially demanding course load this term and so I won't have much time at all for anything else!
I will try to add what wisdom I have collected so far when I can, but I think it will take a while before I have the mental space to collect additional thoughts.
I will try to add what wisdom I have collected so far when I can, but I think it will take a while before I have the mental space to collect additional thoughts.
September 10, 2007
(Intermisssion)
I am going to take a short break from posting because:
- I need to concentrate on preparing course material for the new semester, and
- I think I’ve amassed enough stuff here now that I need to convert the site to a more browseable interface.
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.
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.
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?
Why Ubuntu?
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…
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.
*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.
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.
Subscribe to:
Posts (Atom)