[ale] Various Rambling Linux Thoughts/Difficulties

[Fulton Green]

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.