I just upgraded BitterSweet to Debian pre1.3, over the modem. It took all night at 33.6, to ftp the files I selected. Everything I'd carefully chosen, a 1 hour job, with `dselect` transfered without a single glitch, from <URL:ftp://ftp.debian.org/debian>. I selected files from bo, contrib, and non-free. (It said 'unstable', later... I thought I typed 'bo'...? Hm.) There was only about 4 installation errors, I think... (They scroll away too fast, and there is no log kept, AFACT.) Wow! Pretty good, considering I got over a hundred new and upgraded packages! Much easier than compilityouseff.
There have been quite a number of improvements since the version I first installed, which was 1.1.n from the InfoMagic set, from which I also demo'd RedHat 3.0.3. In particular, I like the new `bug` program, which lets you easily file a bug report against a software package. You type `bug packagename` at a shell prompt, and edit the report template in your $VISUAL editor (I prefer `gnuclient`.), it gets mailed off to the bug tracking system, which autoresponds with your bug number. I think that `bug` will help to improve the quality of the Debian GNU/Linux distribution and the software that comprises it, since by making it simpler and more efficient to report bugs, people are more likely to, and the maintainers will become aware of problems sooner. I was very impressed by the expediency with which the recently announced `amd` (Auto-Mounter Daemon) security bug was fixed! There have been other cases where We have had bug fixes before the other distributions have had them. Some RedHat people from PLUG (Portland Linux User's Group) seemed very amazed when I talked about running the Corel WordPerfect Java applets inside Linux NetXcrape. "Mine always crashes! I have to keep Java disabled!". To have a one or zero floppy CDROM install sounds like a worthy goal! Six floppies to do a base install isn't too awful bad though, and my test the other day showed me that it provides everything needed to ftp, nfs, or plip the rest of the system, if a CDROM, or Zip disk isn't available. There should be a dialog for configuring pppd though; that was lacking. The 56Kbps modems are going to make the ftp installation and upgrade option very viable. (Internet Arena has them now; I'm waiting for a response about an upgrade to my modem from Cardinal. There must be thousands of others like me at both ends of the link.). It is pretty amazing to have things being installed into the machine, while it is up and running, without having to do much of anything to make it happen. (I ran with slackware for 12 months.) To test this a little, I goofed around on another console and in X windows with logging in and out, telnetting to Internet Arena, and running commands (`mc`) that had just been unpacked by `dselect`. I ran `top` for a bit to watch what `dselect` was doing, and then used `gitps -wauxf` to get momentary snapshots of it. Now THAT's a great tool! I like how I can flick over to another console and use XEmacs' ediff to compare two configuration files, merging my local edits into the new package's .dpkg-inst version. I was able to add the transnames fixups back to BitterSweet's "/etc/init.d/boot" like that, while other packages were still being installed by `dselect` on the foist console. I think that to perform an upgrade on an ISP server would be very doable. I wouldn't even hesitate to upgrade `sendmail`, `qpopper`, `cron`, `innd`, `apache`, `RADIUS`, `majordomo`, `perl`, `libc`, or any other mission critical package, without even changing runlevel, or forcing people to log out first. (I guess I'd tell them, in case there's a goof, so they aren't running anything critical when it happens.) Dpkg works very well! I glanced over the new 'dwww' documantation interface, and its really looking good! I hadn't had the menu package installed previously. The documents under that hierarchy look really nice! Is that the debiandoc DTD that the doc people have been talking about? Great! I would like to see http://localhost/cgi-bin/dwww?type=dir&location=/usr/doc done as a multi-column table; it would look better and be easier to search with the eyes. You could add tags conditional on $ENV{'USER_AGENT'} being a table aware browser, and use <pre> with added spaces and a hard formatted table for non-tableing ones. It will take some codeing for sure. `dpkg-repack` sounds very promising. I will try it when I get my second box up and running. I want to find out how easy that make it to klone web servers and X-swerver confounderations. (I will also do further experiments with the transnames kernel patch, while I simutaniously teach myself scheme.) Everything restarts again without too much trouble, right after configuration, incluging X-Windows. The irritating minor (really...) bugs are: * that my locally compiled 3-d XDM login (that I found on the net from rastasia), got overwritten, and the installed one does not have shadow password compiled in. I should have had it in "/usr/local/bin", rather than "/usr/X11R6/bin". Duh. * for some reason I have yet to divine, the tkdesk toolbar was default grey agian, not the colors I had set for it. So was tkps and tclhelp. * the upgraded xbase replaced my "/etc/X11/xdm/Xservers" file without asking, and when X restarted, it was in 8bpp, rather than 16bpp. I had fixed the commandline in there to run X at 16bpp. I realize I could configure it to default to 16bpp, but I leave the default at 8bpp and small sized for running XQuake. (something to keep in mind for the Debian-wide defaults maybe???) * The non-presence (or is it merely non-prominence?) of the shadow suite was slightly irritating as well. The upgrade left my previous installation, which I'd grabbed out of 'project/experimental' several months ago, intact, so nothing got broken besides XDM and xlock, AFAIK. 'Luckily', I answered 'no' to replacing the passwd and group files during the upgrade. <critical><clatter> RedHat does not even HAVE a `sendmailconfig`, a `bindconfig`, or an `apacheconfig` script. They try to pretend that the control panel thing is real; it sells, I guess. But it's lame. Full page glossy $40.00 'commercial product' necktie lame. (IMHO and all that...) I did not like having to 'offix my-computer' around Startwimp95 and click christmas presents. It's nothing but a 'my busy box'. I like to think of them as SoreThumb Linux.... never mind. They can afford lawyers now; I'd better can it.</clatter></critical> While the packages.deb were coming in, I spent the time patching my kernel up to 2.0.30, applying the parport patch for parallel-port sharing, and patching in the improved Zip drive [Curtin-1-08-STABLE] ppa.c driver that has EPP (Extended Parallel Port) support in it. (I hope it's fast! I want to keep Lectern books on Zip disks. I plan to buy a Samizdat scanner soon... now that I know how to plug in a book.) I'm not done resolving the CVS conflicts yet; when I merged the vendor branch back into my 'toy' working tree, it created a few overlap conflicts. So now, I'm going through the files with conflict sections in them, (with the aid of tkcvs; I've not learned pcl-cvs yet.) and fixing them by comparing the parport patch and the patch-2.0.30 to determine how the code should look now... as though the 2.0.30 patch got applied first, and then the parport patch after it. /usr/src/linux/drivers/char/lp.c wasn't to bad; I hope the others are as simple. I don't understand how any of it functions yet, of course, so if it gets too real, I won't be able to make it work. I barely know any C yet; I'm about a freshman at it, with limited vocabulary and no knowledge of algorithms, data structures, or C idioms yet. I understand most syntax though, I think. The lp.c fix was easy because 2.0.30 added only one statement to the top of a function that had also been altered by the parport patch. CVS didn't know what to do, but when I looked, it was obvious how to make it look. I'm sure of that one. I will try `kernel-package` when I'm done.
Karl M. Hegbloom <[EMAIL PROTECTED]> http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.0.29t You tell me and we'll both know.