[ale] Various Rambling Linux Thoughts/Difficulties

[Frank Zamenski]

Thanks for sharing the experiences. I considered doing a fresh 7.0 install,
but I'm
getting the feeling that RH 7.0 is for the adventerous. My free time is at a
premium,
and I rather like the 'settled feel' of 6.2. Should I take the 'don't
upgrade until
necessary' path, and wait for 7.1? I'm not the type that enjoys fixing
'things that
once worked good but got broke bad' by pgm nor OS upgrades (with any OS,
for that matter).  ;-)

--fgz


> From: "Fulton Green" <ale at FultonGreen.com>
> To: "Thompson Freeman" <tfreeman at intel.digichem.net>
> Cc: <ale at ale.org>; <alseg-discuss at egroups.com>
> Sent: Monday, October 09, 2000 7:51 PM
> Subject: Re: [ale] Various Rambling Linux Thoughts/Difficulties
>

> 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.