Re: diald - we don't need no steenkin' diald!

["Adam Williams" <awilliam@xxxxxxxxxxxxx>]

>
> I used to use Dos/Windoze to verify hardware when I first stared with
> Linux.  Now that I'm more comfortable with Linux, I rarely do that.
>

Once one gets used to Linux/UNIX you discover it actually lets one do a LOT
more to probe and verify hardware than DOS/Windows does.  One problem with the
DOS disk (other than for simple hardware like a modem) is that most devices
selling now don't even ship with DOS drivers.  At least several of the things
I've purchased very recently don't.

> > after you prove that the hardware is working as you expect. THEN it makes
> > sense to run whatever configuration software the manual, FAQ, HOWTO or
> > whatever recommends to tell Linux what you have just verified.
> > In my case, that seems to be what it takes to get things working. (i also
> > lost a lot of sleep getting X configured and now it is running pretty
> > sweet.)
>
> It has made great strides in the "new user friendly" catagory lately.
> It's when you "get off the beaten path", with software that doesn't
> come pre-setup and pre-installed, or you want to do something "custom"
> is when the fun really begins!   :{)
>

One not about this.  XFree86 4.0 is in the development cycle now (with no
release date as of yet)  but it will have device drivers as runtime-loadable
modules instead of seperate binaries for each card and a better mechanism for
discovering hardware than the admittadly kludgy XFree86 3.x uses.  I don't know
when this will arrive but it looks very promising from the articles I've found
about it.

Also some XFree config resources don't get mentioned often enough.  Searching
Dejanews or USENET with the name of your video card + "XF86Config" will find a
config file more often than not (unless you have a really new/wierd card) and
the Linux Monitor Database lists the proper settings for hundreds if not
thousands of monitors (even my nasty one-piece Compaq Presarios).  I love that
page.  It is found at: http://www.netmaster.ca/LUG/monitor/search.html

> > another general principle that i am on the verge of believing is that one
> > ought to start out thinking about trouble shooting and gaining visibility
> > into the problem *before* one embarks on a Linux-install crusade. for
> > example, i'm about to rebuild the kernel. i've never done so before. how
> > will i prove its stable? how will i prove that my goal (getting
> > ip_masquerade working) has been achieved? the most valuable section of my
> > SAMBA book has been the section entitled "troubleshooting"
>

To test a new kernel I suggest firing up every piece of hardware at the same
time.  I've found mistakes I've made by doing this.  Play an audio file,
 download something from the internet,  view and .avi,  backup to take,  and
compile a kernel all at the same time.  If this doesn't break you machine than
it will probably be stable for a good long while.  To test new system libraries
I like to perform a regression test on PostgreSQL as that does some wierd
typecasting and math operations.

> IMHO, the only way to really learn about such things is by doing it.
> Follow the instructions, and do it yourself.  If you have problems,
> go to www.dejanews.com and see if anyone else has had the problem
> and how they fixed it.

THis is great advice,  although I think USENET search from ALTA vista finds
more stuff (and more irrelevent trash too).

> And I really mean "do it"!  Don't just read about it, don't watch
> someone else do it, but do it yourself.

Absolutely.  And I learned to program on a Commodore VIC-20,  the languages and
technology change but the basic understanding is the same,  so you can't really
loose out by learning something new.

> I'm curious, how far did you get?  Did you get demand dialing to work?
>

Same question?