[ale] Various Rambling Linux Thoughts/Difficulties

[Eric Z. Ayers]

Hi Fulton,

I've been working with the redhat installer program, and I just
thought you'd like to know that all the upgrade process does is
exactly what you spent hours doing by hand.  I would think it would
work better because it is running from a different set of binaries. Of
course, I don't doubt you had that bad experience in the past, I'm
just saying that the automatic upgrade should work pretty much the
same way. 

-Eric.

Fulton Green writes:
 > WARNING: this is long. But some of you might appreciate this ...
 > 
 > Coincidentally, I was debating whether or not to post my recent experiences
 > regarding actions most here would equate with suicidal tendencies: upgrading
 > to RH 7.0 (manually, natch) and THEN compiling the latest 2.4-test kernel
 > using the now-infamous 2.96 "release" of GCC.
 > 
 > Believe it or not, I made it through all that (mostly) unscarred. Not that
 > I'm ready to start pressing any "Upgrade now! Ask me how!" bumper stickers
 > or anything, but here's what I went through:
 > 
 > I took the freebie distro that Red Hat was handing out at the Interop trade
 > show. FWIW, this version appears to be "Red Hat lite": several packages that
 > are included in the online FTP version of the distro were missing from this
 > CD set. This is a 2 CD set, but unlike the CDs that Red Hat is selling, where
 > binary RPMs are distributed throughout more than one CD, the second CD in
 > this set had no binary RPMs, just the source RPMs. I think most of the
 > missing packages are incidentiary development libs, docs and data files,
 > though.
 > 
 > So like I said before, I upgraded the RPMs manually. That's as in running
 > "rpm -Uvh file1.rpm file2.rpm ..." several times over. That was a pain, and
 > certainly don't try this at home. I didn't do the upgrade option from the 
 > install program, because:
 > 
 > 1) I tried that with RH 6.0 and 6.2 only to get nice "install failed" msgs
 > 
 > 2) My fears of bad reactions to the way I've config'd the 2.4 test kernel.
 > 
 > Since I'm a bit of a stickler for trying not to clobber stuff unnecessarily,
 > I did everything possible to avoid having to use the "--force" option of RPM.
 > Which meant that I had to discover and follow a pretty meticulous path for
 > upgrading.
 > 
 > The biggest headache was in trying to upgrade RPM itself. This meant upgrading
 > the GNU database library and GLibC. At first, this seemed to break nearly
 > all dependencies on my system. Fortunately, I discovered that the distro
 > also provided backwards-compatible libraries (which in some cases, are still
 > used by some of the packages). Once I got over that hump, manual upgrading
 > became easier.
 > 
 > Another big headache was trying to get the new version (4.0.1) of XFree to
 > work w/my chipset (CT65555). After hours of thrashing with XFree's official
 > new config app (xf86cfg) and Red Hat's console-based hack (Xconfigurator), I
 > finally came up with an XF86Config (which, BTW, is syntactically different
 > from XFree 3.3.6) that would let me run 1024x768. Unfortunately, I lost 24-bit
 > color capability (which I had previously with 3.3.6) and settled for 16-bit.
 > FWIW, RH also provides 3.3.6 versions of various X display servers. Being
 > that this is on my laptop, modelines are moot.
 > 
 > Once I got that going, I tried running with the new GNOME stuff. Some of my
 > previous settings didn't seem to translate well, so I nuked my .sawmill and
 > .gnome* directories and started over. Much better results. I did notice that
 > xscreensaver wasn't able to initialize itself if I started X using "startx"
 > from a command line. That problem went away after I switched to the GNOME
 > display manager (gdm). FWIW, some of the GNOME office apps (AbiWord and Dia,
 > in particular) now show up (old news for you Helix freaks).
 > 
 > Is apmd strictly battery monitoring, or does it handle EnergyStar features
 > in general? If it's the latter case, I can see a justification for including
 > it in a regular or development desktop install. Or maybe it's there in the
 > event that a UPS is attached. I don't know, since it doesn't seem to speak
 > to my laptop's BIOS very well anyway.
 > 
 > No comment on linuxconf - I tend to do that stuff by hand anyway (as if I
 > knew what I was doing). The doc locs are a result of LSB-related activity,
 > as another poster has pointed out.
 > 
 > IIRC, the boot-time graphic is an XBM format file that actually gets compiled
 > into the kernel code (an XBM file is basically source code for a
 > pre-initialized C struct). Sure, it'd be nice to have that be a
 > "plug-and-play" file, but that would probably assume that the kernel actually
 > had knowledge of a disk filesystem at that point. Since that typically
 > doesn't occur until roughly midway in the boot process, that would seem to
 > defeat the purpose of having a boot-time graphic in the first place.
 > 
 > This is a perfect segue into my experiences with compiling the 2.4-test
 > kernel (feel free to skip the rest of this if you're not the "roll-your-own"
 > sort).
 > 
 > A quick intro: I've been running the 2.4-test series since around test3,
 > when I was finally able to compile a kernel that didn't lock up or panic.
 > 
 > One feature of it that's pretty neat is the new devfs mechanism, which
 > provides a mechanism for creating block, character and other special devices
 > in the /dev hierarchy on the fly, in memory (as opposed to the current /dev
 > hiearchy, which is relatively static and takes up a little bit of disk
 > space). Watch out, though, because unless you can grab the devfsd package
 > (which did not appear on my CD), you'll break several packages that are
 > expecting old device names (most common example is /dev/mouse, which in my
 > case is now /dev/misc/psaux). Since I'm using the new /dev scheme, I chose
 > not to upgrade to the dev or MAKEDEV packages. The only major consequence of
 > this is that I can't install mod_ssl since it requires the dev RPM.
 > 
 > 2.4 also includes support for USB hubs (either OHCI or UHCI) and even for
 > a few devices. Unfortunately, I can't get the stock kernel to allocate an
 > IRQ for my UHCI hub (though hardcoding one at least gets it recognized), and
 > I have no luck getting it to recognize my USB scanner (the QuickCam VC is
 > another issue entirely, thanks to Logitech's closed-source policy).
 > 
 > All you /.ers out there have probably seen the flamewar erupting over RH's
 > decision to include a not-intended-for-public-consumption version (2.96.3 ?)
 > of the GCC distro. The GCC steering committee is lamenting the potential for
 > ABI breakage, particularly w/r/t C++ bindings. RH's response boils down to
 > having been caught between a rock (previous versions that were supposedly
 > even flakier) and a hard place (the GCC 3.0 waiting game).
 > 
 > Just in case, RH provided an earlier version (2.91 ?) of the GNU C compiler
 > and specifically renamed that version kgcc, with the intent that kernel
 > source code should be compiled specifically with that binary.
 > 
 > So just for kicks, I went ahead and compiled the latest dev source
 > (2.4.0-test9, to be exact) using the OTHER compiler (yeah, the not-public-yet
 > version). I did see quite a few warning messages that I had not seen before,
 > but other than those (and an unrelated dependency bug), I was able to
 > successfully compile a bzImage and corresponding modules. Amazingly enough,
 > I was also able to boot the new kernel.
 > 
 > OK, that's all. Hope you had as much fun reading this as I had going through
 > all this. Alright, I hope you had more fun. :)
 > 
 > -------------
 > Fulton Green
 > http://www.FultonGreen.com/
 > 
 > 
 > On Mon, Oct 09, 2000 at 03:21:18PM -0400, Thompson Freeman wrote:
 > > 
 > > While I've been on various RedHat distributions for years (since 4.0), I'd
 > > like to give Debian a try. I can burn the CD, so I'd like to just download
 > > an iso image and have at it. Is there an image file out there that I don't
 > > recognize, or do I pull things together myself and have at?  Some fairly
 > > specific pointers at this time (about locations and getting everything
 > > needed) will be appreciated.
 > > 
 > > Related to above, has anybody else tried the RH7.0 release? I'm finding
 > > myself somewhat disappointed with my efforts here, although I suspect
 > > eventually things will fall together again.
 > > 
 > > Specifically:
 > > 
 > > Gnome & X - under 6.2 I had them working nicely, but I have yet to get 7.0
 > > to give me a usable display (either it's unreadable with transparent
 > > portions, or you cann't drag something across the screen without bits
 > > being dropped off, or both, or something else.) FWIW, I'm not getting X to
 > > work right yet either, something that happens to me everytime.
 > > 
 > > Why is it needed to install apmd on a desktop machine? OK, I could have
 > > found it and dropped it during install, but that takes significant time
 > > during install.
 > > 
 > > I happen to _loath_ linuxconf, which RH supports and loves. I forgot to
 > > drop that one also. 8-(.
 > > 
 > > A number of documentation files have changed locations (from /usr/doc to
 > > /usr/share/doc).
 > > 
 > > I'm finding other sharp edges, but I can at least point out some positive
 > > experiences also.
 > > 
 > > LILO has gotten some graphic capabilities, although I haven't find how to
 > > create my own splash screen. The display, however, is pretty enough to
 > > make it worth having. (Anybody know where the secrets of these file are
 > > documented?)
 > > 
 > > LPRng is part of the distribution. I haven't gotten to it, but I've heard
 > > good things and look forward to trying.
 > > 
 > > And the continuing nonissue: the traditional Unix stuff went in and came
 > > up slick as a whistle without hassle with respect to configuration.
 > > 
 > > Since I'm running this strictly on a test bed basis, and expect to fool
 > > with it several more times from installation, I'm not ready to shoot down
 > > RH's efforts. I would like to look at Debian more closely tho, as I'm not
 > > quite as happy with RH as I have been in the past. 
 > --
 > To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.