[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Journalling: Upgrades, Kernel patching, ...



 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 <karlheg@inetarena.com>
http://www.inetarena.com/~karlheg
Portland, OR  USA
Debian GNU 1.2  Linux 2.0.29t
You tell me and we'll both know.



 

Reply to: