The laptop on which this is being typed is an Acer Aspire One (D270) running Debian in 64-bit mode which has been the mainstay for my computer usage since the first week of July 2012. It has worked brilliantly from day one, except for graphics as explained below, and this post outlines how I fixed the last remaining hole. The AO is ideal for my kind of use --- all major applications run full-screen under xmonad and with one major application as a terminal window running screen.

Coming to graphics, the root problem was that I had (as usual) not done a proper survey --- which would have told me that this machine used the infamous GMA3600 graphic chipset from Intel/PowerVR which has been the source of a headache for many. The first boot left me with an 800x600 screen which was clearly not as advertised. So quacking left me with the suggestion that a 1024x600 framebuffer (as advertised) was possible via grub and the VESA framebuffer. The ``fbdev'' driver for X completed the picture ... with the small catch that external VGA was not be available unless it was connected at boot time!

This small hole has bothered me off and on over the last 6-7 months, till finally, over the last one or two days, the problem has been fixed as explained below. So now this netbook is really perfect.

The kernel driver for this was developed by Alan Cox starting as far back as July 2011; it was then considered buggy and was in the staging area. In November 2011 it became a "regular" driver with kernel 3.2. However, it was still too buggy to be built for stock Debian kernels. In fact, up until linux-source-3.2 (version 3.2.35-2) for Debian wheezy, the driver continued to crash with a "kernel oops" whenever it was loaded on my machine. Recently, I downloaded linux-source-3.2 (version 3.2.39-2) from Debian sid to see if it could solve my problem. (Note that the Debian kernel team only started building the relevant kernel module since version 3.5.5~experimental.1.)

Update: The latest (as of 26/03/2013) the stock kernel package (version 3.2.41-2) for Debian wheezy has the module! So all I had to do was to install this kernel.

Having access to a really fast machine, I built the kernel on that using the usual method (INSTALL_MOD_STRIP=1 make -j20 deb-pkg) and installed it. In a wonderful moment, the screen flashed (to indicate the loading of the framebuffer module) and did not crash. However, that was not quite the end of the story.

It turns out out that one needs a more recent version (0.5.0) of the xerver-xorg-video-modesetting module than that which is provided under Debian wheezy (0.3.0). Luckily, building this was quite easy by just using the same "debian/rules" etc. as work with (0.3.0). So I have created a version 0.5.0-1~local1 which installs this X window driver.

This brings up X with a simple /etc/X11/xorg.conf which ensures that the modesetting driver is used. Everything else works as before except hibernation which results in a garbled screen!

To solve that one has to disable the video quirks and add a simple one of one's own /etc/pm/sleep.d/99redraw_on_resume. One also needs to add "gma500_gfx" to the list of modules loaded at boot time to ensure that the vesafb module does not load while resuming from hibernate.

In summary:

1. Configure, build and installInstall the kernel from Debian sid (3.2.39) using the GAM500 drm module sample config.
2. Build and install the xserver-xorg-video-modesetting driver (0.5.0) by using the same source packaging as for Debian wheezy (0.3.0)
3. Tweak the directory /etc/pm/sleep.d to prevent any video quirks from running except a new quirk to setup X using xrandr.
4. Ensure that "gma500_gfx" is loaded at boot time instead of the "vesafb" module

After the Edge went over the edge, it was replaced by an Acer Aspire One (AOD270). (Price: INR 16000)

I had experimented earlier (for a full year) with an Acer Aspire One until it was time to return it to the IMSc computer center (since I had moved to IISER Mohali). Apart from having to deal with comments like ``How can you work with such a small computer'', my earlier experiences with it had been good. The new one hasn't disappointed at all.

First of all, it was amazing how quickly it got up and running to my regular working environment (Debian "testing", currently "wheezy"). All I had to do was to transfer the disk image from the Edge to the Aspire One and tweak the boot command line a bit to accomodate the annoying N2600 Cedar Trail graphics.

It was good that I had not done my research well, else, hearing all the complaints about the N2600, I may have skipped this machine altogether. However, if one uses Grub to boot Linux with a 1024x600 framebuffer, then X takes care of the rest. (It is nonetheless preferable to tune X to use the "fbdev" driver rather than "vesa" which it picks by default). Other people may be upset by the inability to run a full-featured Gnome Shell, but XMonad+LXDE works fine for me. The only remaining annoyance is that one needs to reboot into an 800x600 framebuffer to connect this to an external VGA. I tried (and failed) to fix this by installing a kernel from "experimental" (3.4.4-1~experimental); so currently no luck with "xrandr" based switching on/off the external VGA/HDMI.

Summary: This is a great netbook for people like me who are text and command-line folk. Moreover, graphics and video is "fast enough" for casual use.

With the "cheap tablet" revolution coming to town, I thought it should be explored. So I got a BSNL Penta IS801c as a gift for Sudeshna on the occasion of Dussehra. The comments below should be qualified by the fact that this is my first experience with a tablet. Some things about it are very pleasing --- a nice interface, root access to Android 4.0 by default and no bloatware! The Pantel guys seem to know what they are doing. The price (INR 10000) is also quite low for an 8 inch 4:3 screen.

Again, it was good that I had not done my research well, else, hearing all the complaints about the Penta tablet being unable to interfac with the Tata Photon+ USB dongle, I may have skipped this machine too. Luckily, it works just fine with the PPP Widget (freely installable via Google Play). Given that this tablet has a cheaper version (INR 6500) for a 7 inch 16:9 screen, I wonder what all the fuss around Aakash is about. (Pantel is NOIDA based and in that sense even more "Indian" than Datawind.) Root access means that it will be possible to run a Debian chroot in it some day!

Summary: This is a nice tablet for those (like me) who are using tablets for the first time.

Bottom Line: Do not do too much research while buying your computers. The fora are largely full of novices who are incapable of minor tweaks and only want "bright and shiny".

The use of graphical utilities is limited to situations where text-based alternatives were unavailable/impossible:

1. A conky/xmobar line which shows me some current info.

2. Accessing certain commercial websites needs Iceweasel/Firefox

3. Editing/Annotating PDF files and forms needs flpsed, xournal

4. Some people send me word/excel/ppt files which can only be edited using OpenOffice/LibreOffice

5. Viewing PDF files, DJVU files and pictures required Evince. (Though it has recently stoppped supporting PNG/JPEG files to my annoyance!). Occasional rare uses of video using vlc.

and (of course!) the time-sink called sgt-puzzles.

Network connections are handled through a number of scripts that handle wireless (using wpa_supplicant), ppp, openvpn, ssh, socks etc.

In fact, even other hardware related issues such as volume control, multiple displays (for presentations), suspend, etc. are all handled through such scripts and keyboard controls.

A colleague who works at MicroSoft Research looked at my laptop and declared me "masochistic", little realising that using the touchpad and dragging things around (especially text!) is what I really find painful/pointless. My personal computer (to paraphrase the advertisement of a big computer firm) is "truly personal again".

However, there is one major drawback of not being "mainstream". The configuration that one uses is not checked sufficiently. There are not enough "eyes" to "make all bugs shallow". When I had the time to be more active with Debian development, this was a good thing as it meant that I would find, report and (occasionally) fix bugs in the packages that I use.

So in the interests of laziness on the computer front, it would be nice to have a more "modern" GUI, which:

1. Is "mainstream" enough that common features for configuration and mobility would be ensured by in-built functions provided by upstream authors.

2. Is customisable through text-based editing if required. A reasonable programming language for customisation would be a "plus".

3. Will not interfere a full-screen "screen" session when instructed to stay out of the way!

It may seem strange, given the outpouring of web pages that decry the low customisability of Gnome 3, that I find that it seems to fit the bill after a first look. The network manager suite has grown to a stage where it can (almost!) replace all my custom scripts. The gnome shell is almost like Fvwm or xmonad in allowing me to programme it using Javascript (in place of perl or haskell). My way of using the system is already based on "activities" rather than "workspaces".

However, to truly "go GUI" it should become possible to do replace mutt for mail, newsbeuter for newsfeeds, w3m for browsing, wyrd for the calendar and the usual shell by the gnome shell (perhaps via its drop down javascript interpreter). It would also be necessary to configure these to drive them via the keyboard and it should be possible to access the data stored/used by the replacing application from scripts as well.

One task was to get Fedora Core running under this Debian Etch machine. Since the information required for this task was rather difficult to find (rant later!), here is a quick 2-paise tip (to borrow a phrase from the linux gazette) on how to get Fedora Core running under a Debian Xen machine.

The helpful packages under Debian are xen-tools and rinse.¹ Since the latter is only available with "lenny", this requires an schroot installation about which I have written elsewhere. So let me assume that we have a lenny chroot inside the dom0 in which xen-tools and rinse have been installed.

One can either bind mount /etc/xen from the dom0 into the lenny chroot or one can just create this directory to hold the configuration file for the domU to be created. Creating the domU is as simple as:

xen-create-image --ip=192.168.17.71 --hostname=fedora \
  	--arch=amd64 --lvm vg0 --install-method rinse \
  	--dist fedora-core-8

   

with ip address, hostname, lvm volume group and arch chosen appropriately. (Be careful and choose a hostname that does not match a hostname that you have already used in the same Xen system). This will create the logical volumes /dev/vg0/fedora-disk and /dev/vg0/fedora-swap containing the appropriate images for use with the Fedora domU. Before you can boot into this domU there are some minor issues you need to fix; see #499476.

The fixes are to create /etc/shadow and /etc/gshadow and set a usable password as follows. Mount /dev/vg0/fedora-disk somewhere and chroot to it. Then run the following commands:

  pwconv
  grpconv
  passwd root

   

Then exit the chroot and unmount /dev/vg0/fedora-disk and then exit the lenny chroot. If necessary, copy the file etc/xen/fedora.cfg from within the lenny chroot to /etc/xen/ in the dom0. You should now be ready to boot your Fedora Core 8 domU with

  xm create fedora.cfg

   

It would be nice if one could install Fedora Core 9 the same way; see #499477.

The following assumes that you have a backup.img which contains bootable Debian firmware for the slug but has the wrong kernel and initrd. One can probably use the Debian firmware that is the Debian Installer image otherwise --- but I have not tested this!

Moreover, I also assume that you have the full system installed on a USB disk which you have mounted on your regular desktop at /mnt.

Copy the kernel and initrd

We just create an new "recovery" directory and copy boot/ over from the mounted USB disk.

mkdir recover; cd recover
cp -a /mnt/boot .

At this point you can un-mount the USB disk and keep it ready to connect it to the slug.

Extract the files from the slug image

Next we extract the files from the slug backup image into another directory.

mkdir files; cd files
slugimage -u -i ../../backup.img

(Here you must use the actual path to the backup image file)

Replace initrd and vmlinuz by new ones

We first pad the initrd

dd if=../boot/initrd.img of=new-ramdisk ibs=4M conv=sync

(here you must you the actual file name of the initrd.img that you want to use to boot the slug) ... and then swap bytes

devio '<< new-ramdisk; xp $ 4' > ramdisk.gz 
rm new-ramdisk 

Next we swap bytes for the kernel as well

devio '<< ../boot/vmlinuz; xp $4' > vmlinuz 

(again you must use the actual file name of the kernel image in place of ../boot/vmlinuz above).

Actually build the image

This is just a single command

slugimage -L apex.bin -r ramdisk.gz -k vmlinuz -p -o ../../new.img

Put the slug in "firmware upload mode"

1. Put the slug off and disconnect everything from it.

2. Connect an ethernet cable ¹ between your desktop and the slug. Connect the power plug for the slug but do not switch it on yet.

3. Push a pin into the hole marked RESET at the back of the slub. Keep the pin pressed, while pressing and releasing the power button on the slug. Wait with the pin pressed until the top light on the slug turns red and the instantly release the pin.

You slug is now reset and waiting for a firmware upload.

Upload the firmware

On your desktop run the command

sudo upslug2 -i ../../new.img -d eth0

(Here ../../new.img should be replaced by the path for the image created above and eth0 should be the name of the ethernet interface on the desktop to which you connected the other end of your lan cable.)

This step takes a short while but shows you some progress information.

All systems "Go!"

If all went well you have rejuvenated your slug. You can now reconnect your USB disk to your slug and the system should boot as usual.

All the same, there are situations when one is faced with a Mac¹ with strict instructions not to reboot or otherwise "disturb" the existing system.

The news in brief is:

Debian Etch runs with Xorg (vesa driver) under Parallels.
It installs using "mini.iso" for network based install.

Using this one can run all the GNU/Linux programs one needs. It "disturbs" the existing system less than things like "fink" or "MacPorts".

Another alternative is "VirtualBox" from Sun which is free for educational use (and has an "Open Source Edition" too!).

QEMU offers yet another alternative. Since it emulates all the hardware it is significantly slower. However, on current hardware, the speed will be more than adequate if you just want to use standard desktop tools from GNU/Linux.

Pros

1. Applications run in the environment they were designed for.
2. Speed is "native" for running computational code as there
   is no emulation going on for this part.
3. X applications work in full screen mode.
4. Full networking support.

Cons

1. Can only run in 32-bit mode.
2. Currently runs X in "vesa" modes so you don't have
   accelerated graphics.
3. Some keys like F10 and Ctrl+Alt Alt+Enter are trapped by
   MacOS so you may have to remap these keys if your application
   uses them. (For example, Ctrl+T instead of F10 for aptitude).
4. Possible delay in disk access since parallels provides an
   "emulated disk".

Not yet tried

1. Sharing files (Samba/NFS/SSHfs?)

Later, I read some letters to Linux Weekly News where people said that Debian was hindering those who want to run flash and other 32-bit programs on a 64-bit system. I couldn't let that pass unchallenged!

Here then is another write-up explaining how one can use schroot to solve the above problems (and perhaps a number of others). The Linux Gazette has also published this in Issue 150 --- thanks Ben!

Sometimes this is necessiated by the hardware being "latesht" as well, but more often then not it is out of a fear of being labelled "obsolete".

Here is one way to use newer software if any of the following applies to you:

1. You do not have root access.
2. You do not want your changes to tamper with system files.
3. You want to ensure that you can recover your system exactly as it was before --- just in case.
4. You are too busy^Wlazy to compile everything for yourself.
5. You want software to run at "real" speeds, not slow^Wemulator speeds.

The following conditions apply to the solution presented:

A. The software you want has been packaged for your hardware. B. You are not afraid that this software will damage files owned by you (as user). Alternatively, you do have root access to create a different user to run this software as. C. The software you want to use/test is not something "core" like the "kernel" and does not depend on a new feature of the kernel. D. You are using Debian or a derivative. (Similar solutions are available for Fedora etc. but I haven't worked them out) C. You have enough disk space (at least 1GB or so depending on the size of the package you want).

By hook or by crook, you need to ensure that your system has the following (rather small) packages installed: fakeroot, fakechroot, debootstrap.

In the following, I will assume that the software you want to use is "iceweasel" with the "gcjwebplugin" from the "sid" distribution because that is what I needed!

Step 0: Decide on some locations.

TOP=$HOME/testing2
STATE=$TOP/files.state
ROOT=$TOP/testing
mkdir $TOP

Step 1: Install the system.

PATH=/sbin:/usr/sbin:/bin:/usr/bin; export PATH
fakeroot -s $STATE fakechroot \ 
    debootstrap --variant=fakechroot lenny $ROOT 

Step 2: Perform some fixes inside ROOTmyid=UID

fakeroot -i $STATE -s $STATE fakechroot chroot $ROOT /bin/bash

This will give you a "root" prompt which is not "real".

We first setup to install some packages from sid.

    echo deb http://your.debian.mirror/debian testing main > /etc/apt/sources.list
    echo deb http://your.debian.mirror/debian unstable main >> /etc/apt/sources.list
    echo 'APT::Default-Release "testing";' >> /etc/apt/apt.conf

Install the packages we want.

    apt-get -y install iceweasel gcjwebplugin

Create a user account to use these packages.

    adduser --uid=$myid $LOGNAME

Exit from this prompt

    exit

Back at the original prompt. We need to give X access to the sub-user.

rm $ROOT/tmp/.X11-unix
ln -s /tmp/.X11-unix $ROOT/tmp/
ln -s $HOME/.Xauthority $ROOT/$HOME/

Step 3: Use the program!

fakechroot chroot $ROOT iceweasel

Step 4: Update your software (required as soon as you hear of exploits!)

fakeroot -i $STATE -s $STATE fakechroot chroot $ROOT /bin/bash

    apt-get update
    apt-get upgrade
    exit

1. The USB cable. This works with the recent(?) cdc-acm driver as a serial device (/dev/ttyACM0 for me). It cannot be used as a USB-storage device and mounted---worse luck.

   1. It doesn't work too well with "gammu". It seems that Motorola changed the AT+Cxxx command sequence "a bit". What you *can* do is download the phonebook with "--backup" but this is only for local storage since re-upload fails.

   2. "moto4lin" is a Qt-based program that works fine for editing the filesystem (up/down loading photos/music etc but not the phonebook!). It can also edit the "SEEM" which looks dangerous so I haven't tried it yet. You can also upload Java applications but I haven't done that either.

2. Bluetooth. This need a firmware upgrade (I was within the warranty period when I asked for one so it was free) to R374_G_0E.42.10R_A (at least; I noticed somewhere that _B,_C, etc are available). Even after this it was not entirely smooth sailing.

   1. Bluetooth connects with bluez-utils. It was a bit tricky for me (=command-line-type!). This needed a file /var/lib/bluetooth/<local_address>/pincodes containing entries like

                	<phone_address> 12345678
      	  

      The 12345678 is the "initial shared secret" used between your phone and the computer. The file can be deleted after establishing a connection the first time.

   2. "obexftp" and "obexfs" can be used to access all the audio/pictures/video that you create (but not the others; you need "moto4lin" for that). However, this leads to corrupt {down,up}loads. The situation was worse with a Mac that Sudeshna uses.

   3. "obexpushd" and "ussp-push" are inherently less secure programs and are difficult to "batchify" but those are the ones that currently work for me to download and upload files without corruption.

   4. "gammu" with "bluerfat" (which is AT commands over RFCOMM) work fine for the phonebook. This is because the phone seems to use standard AT+Cxxx commands over this interface---wierd that it doesn't over the cable! I am able to edit the phone book and even use my computer keyboard as a remote keyboard instead of the phone keyboard. Can't access multimedia data over this interface though.

3. Still to try (but will not try soon since I've already wasted two weeks on this!).

   1. Haven't yet tried to connect to the net using the phone. In principle, the difficulty here is not with the phone but with the service providers instructions---I still haven't managed to decode them---Indlish anyone?

   2. Haven't yet tried to unlock the pre-installed "Web sessions". This can be done by editing the SEEM according to various web sites. It doesn't have to be done yet since I am able to edit everything except the name of these sessions. That is enough to use the phone browser to "browse the web".

   3. Install Java applications and get them to work. I created some room by deleted all those keyboard damaging games that were installed but haven't got further than that.

   4. Re-write "moto4lin" as a command-line program. Why should one need to use Qt for a task like this?

The question arises: How will people learn about GNU and Linux once everything starts working smoothly?

I can certainly vouch for the fact that many of the things I learnt about computers, I learnt because the computer was not doing things the way I wanted it to.

From Personal Experience

There are two types of mathematics books.

There are those where the author has taken great pains to construct the most illuminating exercises for the student to solve at the end of each chapter.

And then there are the books where there are mistakes in the text. The exercise is to find the mistakes and correct them.

I have learnt more from the latter than the former

The Long of it

1. There is a way in which optical disks can be written in "packets" which can have variable lengths. This method, called Mt. Rainier and invented by Philips, is supported natively in Linux by a module written by Jens Axboe called "pktcdvd".

2. There is a file system called "UDF" which was created as an ISO standard format in which data can be stored on optical media and is used by most DVD's. The UDF file system is supported by Linux by a module called "udf" which is currently maintained by Ben Fennema. (Was it written by him too?)

3. The udftools contains tools (what else!) that setup a drive and a disk for using Mt. Rainier and UDF in conjunction.

The Short of it

So what does all this mean for us?

A. If you just want to read a UDF formatted CD/DVD, you put it in the drive and go

mount -t udf -o ro /dev/cdrom /mnt

(mutatis mutandi) and you can read the data. There may be a slight complication about "closure" (see below) for disks written on other drives.

B. If you want to use a CDRW (CDR may work I haven't tried it) as a "large" floppy, then you run as root (if you have installed "pktsetup")

modprobe pktcdvd
pktsetup /dev/pktcdvd/0 /dev/cdrom

(Note that udftools comes with a start script which does this providing you edit /etc/default/udftools appropriately).

You then "format" your media with the command

cdrwtool -d /dev/cdrom -q

This takes a while so you may want to have that cuppa-cha now.

Now this is ready for use. Whenever you need to read/write from this "floppy" you go

mount -t udf /dev/pktcdvd/0 /mnt

You can then read/write files from/to /mnt.

Of course, like a floppy you need to remember to (sync;umount /mnt) before removing the CD from the drive.

C. On the same drive as the one you used to do (B) you should be able to manage (A) with your CD but if you want to make your UDF written CD truly "universal" you may need to run:

cdrwtool -d /dev/cdrom -c

This will "close" the track ("fixate" the media). But you will not be able to write to the same track any more without blanking the disk. I haven't needed to use this but I have only checked things on a couple of machines.

I am a mathematician by training and have been employed by the Institute of Mathematical Sciences, Chennai, India as a professor of mathematics since September 1996. More details about me can be found at my web page http://www.imsc.res.in/~kapil.

A brief history of my involvement with Linux (pre-Debian)

I began using GNU software while I was at the University of Chicago in the academic year 1990-91. At that time I started using the DOS ports of various GNU packages until I found out about Minix. In bought and installed Minix in Jan-Feb 1991 on a PC-XT that I had then (and so I was not interested much in 386 Minix).

On my return to India and TIFR September 1991, Mumbai I found that our department had acquired a 386 and so I installed 386 Minix on it --- to work on at night as it was used as a DOS machine by day! At that point I began getting interested in the ports of "gcc", "emacs" and "TeX". I also set up a UUCP client service to receive mail directly on the Minix partition.

We wanted to switch all the users to full-time use of Minix on this machine but were stuck because along with DOS there was a preview utility for TeX but on Minix there was only MGR. We hacked on MGR to get it working for the EGA card this machine had and so we had a workable DOS alternative. We thought it was only a matter of time before people saw that Minix (with mostly GNU tools by now) was a better than DOS but had mis-calculated "user inertia" and the charm of "solutions developed by specialists instead of hobbyists (sic)".

It was only a matter of time before we realised that 386 Minix had other problems --- no proper networking, no X and the difficulty of porting software that depended on a proper Posix-ish environment. So in August 1992 we installed Linux using the two/three diskette GCC-kit that was available from Sunsite. Porting (except networking) was no longer an issue. When networking came to Linux we still didn't have ethernet and so we hacked a bit on the "PPP" that was developed in a separate mailing list starting with Fred van Kampen's Minix code base.

In 1993 I moved to Bangalore set up some basic networking at the TIFR centre there; it was again based on GNU/Linux. In March 1994 I acquired my own 386 and installed some non-distro form on GNU/Linux on it (or perhaps it was SLS or Slackware; I don't really remember). On this PC I developed an "Xterm-on-a-floppy" that was installed for a while on the desktop machines at the Statistics and Mathematics Unit, ISI Bangalore. These were clients for a "server" that had TeX and e-mail services in addition to some X clients.

In September 1996 I moved to Chennai and the IMSc and better network speeds. I could finally download Debian 0.93r6 (or so I remember) for my 386 which I had heard of through the "grapevine". The machines at the IMSc were a combination of Sun/Solaris and SGI/Irix. After struggling with porting GNU and other Free (as in Mukta) software installed and working on them, I finally convinced the local Computer Committee to buy some Pentium machines in early 1997.

Member of the Debian User community

Thus I have been a member of the Debian User community since around 1996. Locally I have also advocated that our Computer Centre run Debian-based servers for the reasons given below. We currently run mail exchangers, DNS servers, a web server, squid cache, a remote access machine and a firewall; all are Debian machines. In fact, except for a brief period when our firewall machine was based on LFS, all the newer servers at IMSc have run Debian. Since the release of "sarge" we are also migrating most desktops to Debian as well (they used to run various versions of RedHat or Mandrake or Debian until now).

For a brief while, I installed Debian on an old SPARC machine which ran our web-mail service (this has been moved to a Pentium machine now). I also worked with the Debian Hurd port for a while. Thus, you could say I have (just a little) experience with no ix86 ports of Debian.

An itemised list of why I have advocated Debian for our machines

In no particular order:

1. We can file bug reports --- and have done so. One can track the progress of one's bugs.

2. Documentation is more detailed than for any other distribution.

3. It is policy-driven. This means that if a file is found in a particular place there is a reason for it. If the system administrator wants to over-ride it it can be done systematically.

4. We can participate in the development process. Sad to say we have not done much so far.

5. Stability. Since IMSc was a priori a Solaris/Irix place, it was important to ensure that "PC's crash frequently" and "things often don't work" do not take hold as reasons to continue buying expensive hardware.

6. Takes its DFSG seriously. In particular, this ensures that any work put into the systems remains available to everyone everywhere.

Why I would like to be a Debian Developer

Again in no particular order:

1. To live up to (4) above. More specifically, if there are packages that we use here regularly that are in need of help we should provide it.

2. There are very few DD's sitting out here in India. On the other hand (when I taught an O/S course for example) I find a number of young students who could easily contribute if ... I have in mind some form of an infrastructure to get them involved.

3. To simplify the upload of the package (tex4ht) that I maintain and others (elvis, mancala) that I am thinking of adopting.

4. To formalise my involvement with Debian so I can justify spending more time developing it.

This is ancient -- year 2000 -- lot of things have changed now in all the distributions (he quotes an example from RedHat 5.0 -- when was that - 1970? ) whereas ncm seems to have heard only of Debian (or at least sounds like it).

The article is ancient but the points it makes, regarding the importance of appropriate packaging & system tools, are still valid. Good packaging helps the packagers and system-administrators to "speak" to each other.

This may explain the popularity of Debian with system administrators. A Debian-based installation is easier to administer than most other installations---especially if you have a number of local customisations.

The whole Debian infrastructure---bugs.debian.org, archive.debian.org, security.debian.org and qa.debian.org---have unfortunately no counterpart in the RPM-based distributions. You either buy support or interact through the various on-line forums.

For example, in Debian, reporting a bug is as easy as sending a mail. The mail is automatically assigned a number and forwarded to the maintainer. You receive a mail when a new package fixing the bug is available.

Even if the maintainer goes "missing", the QA team at Debian takes over maintainance of the package. The security team applies patches if security related bugs are found.

Even when a new "stable" release is made, the old one continues to be available as "oldstable" and even older distributions continue to be available in the archive.

I have no idea whether one can obtain such support for the RPM-based distributions and if one can then how one can obtain it (by paying or otherwise).

However, for a number of years the other distributions had newer graphical user interfaces (like KDE/Gnome) which many users wanted. Configuring the default X11/fvwm/twm GUI to user specifications was too much effort for sysadmins so they preferred to install RedHat/Mandrake/SUSE for desktop usage. (The older Gnome and KDE that came with "woody" was not a fully integrated GUI in the sense that you still needed the command-line interface to do various basic things.)

With "sarge" and "hoary" (or with Knoppix and klones earlier), the user interface on Debian-based distributions is also up-to-date as with other distributions.

It is now possible to use only the GUI for basic system and user configuration. Whether this is desirable is not clear to me---but it seems to be what a number of users want!