Linux-Hardware Digest #34, Volume #10 Thu, 15 Apr 99 13:13:54 EDT
Contents:
Re: need help with modem setup in Redhat 5.2 (Jarkko K Karhunen)
Re: USR Modem ("R.Bertrand")
Re: All the current OSes are idiotic (was Re: Is Windows for idiots?) (Ed Falis)
Re: All the current OSes are idiotic (was Re: Is Windows for idiots?) (westprog)
Re: Adaptec AHA-1542 SCSI problem (Stephen Bodnar)
FREE Computer Documentation ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jarkko K Karhunen)
Crossposted-To: comp.os.linux.networking,alt.os.linux.dial-up,alt.os.linux
Subject: Re: need help with modem setup in Redhat 5.2
Date: Thu, 15 Apr 1999 16:22:41 GMT
On Thu, 15 Apr 1999 00:58:03 -0700, "Bill Spargur"
<[EMAIL PROTECTED]> wrote:
>hello..
>
>i am relatively new to the Linux environment and am having trouble
>setting up my modem configuration. In Win 98, the modem is set
>for COM4, IRQ 11 (it is a Creative Labs Modem Blaster 56k v.90 KFlex).
>However, when my Linux OS boots up (Redhat 5.2), it
>doesn't detect the modem and I can't seem to configure anything
>to match it, even using symbolic links. Can anyone please help?
>
>
>
>
Check your IRQ's. My modem was com2 irq 7. It worked fine in my 95 but
went autistic in DOS and Linux. Moved it to irq 3 (had disabled the
original com2 at the very beginning) and it worked fine. (wvdial is
massive cool)
JK
------------------------------
Date: Thu, 15 Apr 1999 15:09:20 +0200
Reply-To: "R.Bertrand" <nospam_please@nowhere>
From: "R.Bertrand" <bertrand@bearbull>
Subject: Re: USR Modem
Ollie a �crit dans le message <[EMAIL PROTECTED]>...
>Hi,
>did anyone write a program, module or driver for using a USR Sportster
>Winmodem 33.6 with Linux?
>I don't have money to buy a new modem (but it would solve my Problem
>;-)).
WinModem's don't work with Linux, nor with anything else than Windows.
------------------------------
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy
From: [EMAIL PROTECTED] (Ed Falis)
Subject: Re: All the current OSes are idiotic (was Re: Is Windows for idiots?)
Date: Thu, 15 Apr 1999 15:55:40 GMT
On 15 Apr 1999 09:21:59 -0600, Craig Kelley <[EMAIL PROTECTED]> wrote:
stem.
>
> # uname -a
> Linux bleep.isu.edu 2.0.36 #1 Sun Nov 29 14:42:08 MST 1998 i586 unknown
> # find / | egrep [A-Z] | wc -l
> 65732
>
> Of course, that's our main fileserver box -- but anyway.
>
> Now, how do I find all the mixed-case files under NT again? :>
Why would I want to, if it's a meaningless distinction?
- Ed
------------------------------
From: westprog <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy
Subject: Re: All the current OSes are idiotic (was Re: Is Windows for idiots?)
Date: Thu, 15 Apr 1999 13:29:50 GMT
Firstly, GAZZA, thank you for remaining polite and debating the issues (e.g.
not accusing me of inane rants, etc.); it seems that case sensitivity is a
sensitive issue for some people. Your tabloid image seems to be a gross
misrepresentation.
In article <[EMAIL PROTECTED]>,
GAZZA <[EMAIL PROTECTED]> wrote:
> westprog wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > GAZZA <[EMAIL PROTECTED]> wrote:
> > >
> > > To say nothing of the fact that it prohibits useful mnemonics.
> > > For example, a coding standard that states all class names should
> > > have an initial uppercase letter, and all variable identifiers
> > > should have an initial lowercase letter. This means I can do:
> >
> > > Object object
> >
> > > and instantly create a nice hint to the reader about exactly
> > > what class object is, and so forth.
> >
> > This could be useful, indeed. The trouble is that now you have
> > "Object" and "object", which mean different things - if you fail to
> > press the shift key at the right time, you get a valid symbol in the
> > wrong place.
>
> No, you don't. You get an INvalid symbol in the wrong place. This
> distinction is very important; the compiler (or a good GUI) will
> spot this INSTANTLY.
I was trying to think of an instance where a class definition and
instantiation could be confused by the compiler, but I couldn't think of it.
> > This leads to confusion if you are discussing the code with
> > someone - "Object" sounds quite similar to "object", and it looks
> > very alike when written on a whiteboard.
>
> I don't tend to write up code on whiteboards, just designs. When I
> want to discuss code, I get a printout. Is my methodolody in this
> respect so very unusual?
Not unusual, but not universal. I often find myself discussing class
definitions with colleagues, or writing brief code fragments on a whiteboard,
where my handwriting makes Object and object very easy to confuse.
[snip, Snip, SNIP]
> > > In a case sensitive language, such sloppiness is prevented. Isn't
> > > this a good thing? Doesn't it mean that the compiler is able to
> > > force more "natural looking" code?
> > I don't think that it is up to the compiler to force "natural
> > looking" code; that is appropriate for an editor.
>
> Well, we disagree. Fair enough.
The C standard enforces on very limited instance of coding standards; i.e. not
having the same variable written in two different ways; it prevents a lot of
other standards. For example, it isn't possible to write your keywords in
uppercase, or with an initial uppercase letter.
> > > Probably my_filename, actually, from most C coding standards I've
> > > seen. That's more of a cultural thing than a limitation of case
> > > sensitivity, though. The Java coding standard uses case effectively,
> > > and so do (eg) most C++ programs.
> > The problem I have is that case is used, as it should be, to make
> > the text representation of a program more readable. This has, in
> > case-sensitive languages (which AFAIK are only the C family, in the
> > broad sense) a semantic effect.
> Saying that the case-sensitive languages are "only the C family" is
> like saying influenza only infects humans with "2 arms and 2 legs".
> It's true, more or less, but since the C family comprises the
> majority of programs, it's also misleading.
The majority? I think that Basic, Fortran and Cobol still outnumber C/C++,
Perl, Java, but I can't say for sure. I agree that there is an awful lot of C
family code around, but that isn't the point I was making - it is that
thousands of people have set about designing programming languages and user
interfaces and file systems, and only those that descend from the original
BCPL source are case sensitive (AFAIK - I couldn't find the 100 bottles of
beer site to verify). You could, of course, argue that this proves what a
good thing case sensitivity is, since it allowed C to prevail over everything
else by Darwinian competition.
> Here's my basic issue: I think it's wrong to call something
> "var1" in one place and refer to it as "VAR1" in another. Most
> coding standards I've seen - for case insenstive languages such
> as Ada - agree with me in this respect. They all enforce some
> rule about what case to use for variables, class names, and so
> forth.
> If you're going to enforce such things ANYWAY, why not let the
> compiler check it for you? Why not make it an error to NOT do
> it, since (by the coding standard) it SHOULD be an error.
I would love to have such an option in my Delphi compiler - "Ensure all tokens
use same case Y/N", with an option to auto-convert.
I don't think this should be enforced at the cost of limiting the coding
standards to lower case only keywords, though.
> > > It doesn't, automatically. Chris was wondering - as I am - if your
> > > problem is with filenames specifically, or case sensitivity in
> > > general. It seems - from your above comments on Pascal, and below
> > > on passwords - that it is indeed case sensitivity that you object
> > > to rather than only case sensitive file names.
> > I believe that case should not have semantic significance, because
> > that is not its use in normal text.
> So what?
> Programs are not normal text. It is difficult to see why they should
> therefore be judged by such a standard.
They are made up from text, and
> > I believe that case-sensitive systems - generally - reflect
> > engineering concerns and the internal representation of symbols
> > rather than their appropriate representation.
> Considering that programs are written to address engineering
> concerns, I think that using case sensitivity is NOT an inappropriate
> representation.
> If one is enamoured of the Natural Language paradigm, one can always
> use some automatic converter. But when it comes to debugging source
> code, I for one prefer the semantics that can be embedded into a
> case sensitive language.
> If Roedy ever gets his SCIDs, perhaps my concerns will be mute - but
> at that point, so will yours.
> > > A matter of opinion. It's a tautology that the more different
> > > possible characters there are for passwords, the more difficult
> > > they are to crack. Making passwords case-insensitive reduces the
> > > number of different characters for passwords. Ergo, they are
> > > less safe. Yes, you can have longer passwords, but (speaking
> > > personally) I'd rather type in mYpAssw0rD than
> > > mynoncasesensitive33pass9word simply because typing in passwords
> > > is a common thing to do and its a PITA to have to type in a long
> > > one. The shorter the better, as long as it's still reasonably safe.
> > Here is a little test. Look quickly - about five seconds - at the
> > above passwords. Then turn away and write them both down. I suspect
> > that the longer password is more likely to be remembered correctly,
> > and that you can write it quicker as well.
> You were wrong, actually. I remembered both, but I had more trouble
> with the latter than the former because there are more numbers in it.
> Here was my mnemonic: "Look for exceptions". That is, I remember that
> the basic phrase is "mypassword", and that it's mostly lowercase.
> Then I remember that the Y, A, and D are uppercase, and that the o
> is a zero. So I have 6 things to remember including each word of the
> phrase.
I just verbalised. Apart from the question as to whether numbers should be
written "nine" or 9, I didn't have to make any great effort at all once I had
muttered the non-case sensitive password under my breath.
> With the longer one, I have 5 words to start with. I then have to
> remember that there's a 33 between sensitive and password, and that
> there's a 9 in the middle of password. Which is 7 things to remember.
I just remembered it as a little sentence. Adding the rule that there are no
spaces and that the numbers are written as numbers, it was easier for me.
> In all fairness, though, you chose a particularly bad example. This
> doesn't really say much one way or the other in terms of whether
> mixed case passwords are better.
> > The reasons for this are fundamental to human being's use of
> > written language - we learn words in a case-insensitive way.
> > Elephant, elephant - we don't learn the spelling seperately for the
> > start of a sentence, we apply the case according to context.
> > It is the job of a programming language or operating sytem to take
> > human-readable text and graphics and hand movements and to
> > translate them into a machine-comprehensible format.
> Maybe in the far future this will be possible. Maybe in the 24th
> century we'll be walking along the corridors of the Enterprise and
> say, "Computer, where is Commander Riker?"
> At which point case will indeed be irrelevant, but only because
> text itself will be.
> For the moment, it is the job of the programming language to express
> to the computer in a non-ambiguous fashion what actions to perform.
> As an analogy of the differences between your position and mine,
> let us pretend that instead of a computer we have someone who
> speaks only Russian, and we speak only English. Your approach is
> to teach him English. My approach is to learn Russian.
> Now, let's say that this person wasn't playing with a full deck,
> if one forgives the euphemism. Computers, as a rule, are not
> particularly bright. It's a lot easier for us to learn their
> language than for them to learn ours.
I would agree with this as a general rule. Case conversion, however, is
something that the dumbest computer can do efficiently and easily. There are
plenty of both types of system out there; I don't think that computers run
faster for being case sensitive. It is a matter of whether case sensitive
systems are more appropriate for us.
> > Computer engineers tend, all to frequently, to assume that a person
> > can easily learn to think in computer terms.
> This is because it's empirically true. The same way people can learn
> to think in different languages.
> > The assumption that 'A' is different to 'a' because the ASCII
> > codes are different is just another example.
> To a computer, these symbols ARE different. We're talking to a
> computer. Ergo, it makes sense (IMHO) to express ourselves in
> terms that the computer will understand.
> In fact, though, your entire argument is a little shaky. 'A' IS
> different to 'a'; it's just that the context in which this is the
> case is way too difficult for us to express to the computer.
> No matter which way you look at it, we HAVE to "dumb it down" to
> some degree.
> > > This says more about your imagination than anything else. ;-)
> > I am quite prepared to be enlightened as to why somebody would want
> > precisely what is described above.
> What about the several examples I and others have given you about
> computer generated filenames?
> > > Then open up a GUI FileManager, and use it to do your file creation,
> > > editing, and removal. I'd say that a significant percentage of the
> > > files I create (as opposed to those that I have automatically
> > > created) are done via some form of GUI interface, whether it's on
> > > Unix OR Windows.
> > What if I am doing a File..Save As into another directory, say?
> What's the problem? You're talking about possible spelling errors
> to retrieve files, not create them.
I am giving an example that I have experienced with Xemacs - if you do a Save
As into another directory, you have to re-enter the name. If you want to find
the file, you have to give a portion of the name. Even the most graphical of
interfaces to a file system requires some typing at some stage.
> > Just saying "use a GUI" hides the problem. Suppose you are opening a
> > file in a directory with hundreds of different files? You remember
> > that it has a name like myFilesomething - in a case sensitive
> > system that is no help.
> And what if all I remembered was that it was called "Filesomething"?
> I forgot about the "my" part?
Well, you're screwed. I am working on the basis that you can usually remember
the start of a filename.
> > I don't believe that shells or GUI's should lie to me.
> ??? What are you talking about? They DON'T lie to you. Nobody was
> suggesting that they did.
If a GUI implemented a case-insensitive interface to a case-sensitive
file-system, it would be a lie, and it would catch you out sooner or later.
> > I would much rather have a case-sensitive system that is honest
> > about it than one that says "you're a foolish GUI person, and
> >we will conceal the gory innards of the file system from you".
> You've completely misunderstood me here.
> I understood you to be complaining that you often mistyped
> "myFilename" when you meant "MyFilename". My reply was that, if
> you use a GUI (and therefore aren't typing EITHER) this mistake
> doesn't happen. You seem to have construed this as me implying
> that the GUI would misrepresent the case of the files; that wasn't
> my point at all.
My point is that even with a GUI, you need to type the names sometimes, or
portions of them.
What I would _really_ like is a more sophisticated approach to data retrieval,
where the nested directory/file/data is no longer relevant.
> > > I mean, why stop there? Even with case insensitivity, you might
> > > accidentally create MyFileName.txt and MyFileName.text, or
> > > MiFilename.txt. Getting rid of case sensitivity isn't going to
> > > stop many typo problems.
I don't think it will solve everything - I do think it is better than the
alternative.
> > The .txt/.text problem is easily dealt with by explicit file typing.
> > When you save your file, it knows that it is a text file, or a C++
> > program, or whatever, and the .txt suffix is unnecessary. (Yet
> > another break with Unix tradition, of course). Mifilename is an
> > obvious misspelling of MyFileName - MyFilename is obviously the same
> > name.
> So you're saying that if I want to create files with arbitrary
> extensions, I have to create them with some editor that will name
> them ".txt" and then later manually remain the files? Or am I not
> supposed to be able to think of any extensions that weren't "in
> the box"? Even DOS based systems don't "know" the extension of your
> file; at best, they have a default.
I think that file typing should be user definable, and it should be an actual
file attribute. I haven't solved this particular problem totally, but
designing the best ever computer system from scratch is a big job. I think
that file extensions, on UNIX and DOS, were an attempt to define file type -
now I think that these types should be an inherent property of the file
itself, not its name.
> And how is "Mifilename" an "obvious" misspelling of "MyFileName"?
> What if MI were my initials, for example?
I just mean that you can easily see that it isn't the same name. It isn't easy
to see what it should be called. The equivalence between MyFileName and
myfilename is obvious, as is the difference between MiFileName and MyFileName.
> There will always be cases where users misspell file names. If they
> do it frequently - as I do! - then they should avoid having to type
> them at all, rather than trying to "second guess". I use File
> Manager tools for most of my opening and editing files. I doubt that
> I'm unique or even unusual in this respect - among Unixphiles also.
Funnily enough, I find the Unix/Xemacs dialogs so cumbersome that I normally
use the command line.
> > > I challenge you to find a Java programmer who fits that profile.
> > > Or most Perl programmers. Or a lot of Smalltalk programmers.
> > I just looked at my big fat Perl book, and I didn't see a single
> > example of mixed case, except, funnily enough, in the Win32 modules.
> Then you aren't looking very hard. What do you have, Programming Perl?
> I just flicked mine open at random; try page 514. Better yet,
> perldoc perlstyle.
> In general:
> - File handles are all uppercase by convention
> - Package names have their first letter uppercase by convention
> - Local variables are all lower case by convention
> Frankly, if you're actually being honest here, you have a pretty
> bad Perl book.
I will accept that restrained rebuke. I note that if all local variables are
lower case by default, and all the language keywords and built-in functions
are lower case, you end up with mostly lower case.
> > Java does seem to use it rather more. Smalltalk I don't know.
> > Funnily enough, the SQL book I am looking at switches from all
> > upper to all lower case halfway through the book.
> Which is confusing, and shouldn't be permitted. IMHO.
I have seen worse than that in computer books.
> > "Software Tools In Pascal" uses all lower case - who wrote that -
> > my goodness, it's Kernighan! "Oh! Pascal" uses all lower case, but
> > uses bold and italic text to make the programs exceptionally
> > readable.
> So what you're saying is that even case-insensitive language tend
> to use a single kind of case? I don't see how this supports your
> argument.
It doesn't, but give me credit for intellectual honesty. It would be trivial
to print keywords in lower case, but a different font, even when they are
entered in upper case or mixed case. I will check some of the more esoteric
languages when I can find the books.
> > > Free us from the chains of insensitive case, and we will use our
> > > freedom to create more readable programs. ;-)
> > I've read a few C/C++ programs. Also some Pascal.
> And?
> I hope you weren't intending that statement to be self evident in
> meaning. I've personally seen readable programs in all three
> languages, but I've never seen mixing case irresponsibly to be a
> particularly valuable feature in this respect. If I name an
> identifier "bar", then I expect a reference to "Bar" to be rejected.
Just that I have found that the comparitive verbosity of Pascal tends to
encourage more readable code. YMMV.
> If I'm reading a program and I see:
> var bar:integer;
> Bar := 54;
> then my immediate impulse is to start looking for where Bar was
> defined. Which is why that sort of thing is discouraged even where
> it is syntactically legal.
It should deserve a smack on the wrist, at least. I would not object to
Var bar: Integer;
or
VAR bar: Integer
which I think is more readable.
Perhaps the ideal would be for the compiler to prohibit defining different
variables purely by case differences, but to also demand that the same case be
used throughout. Is this an original concept?
I am generally in favour of languages being as strict as possible - for
example, I think that the Occam use of indentation to indicate scope is an
excellent idea.
> > > About the only language that fits your viewpoint is C - and even
> > > then, all uppercase is standard for constants. The point is that
> > > WITH case sensitivity, we can be guaranteed of these "special
> > > cases" and they leap out at us while we're parsing a file. Pascal
> > > gives me no guarantees that A_SPECIALLY_CASED_IDENTIFIER wasn't
> > > declared as a_specially_cased_identifier somewhere earlier, so I
> > > don't have these sorts of visual clues UNLESS the programmer is
> > > careful to use different cased identifiers and avoid "clashes".
> > > If they're going to that much trouble, why not take the next
> > > logical step and make it case sensitive?
> > A_SPECIALLY_CASED_IDENTIFIER makes it a lot more readable if you
> > are using a 1980's style editor. Modern programming editors should
> > make keywords, constants, strings etc. visible without the
> > programmer having to use his own typographic tricks.
> Err... what about languages where the difference between a constant
> and a variable is one that is not intuitively obvious to the editor?
> Not all languages have a "const" keyword; and besides, you can never
> have too many visual clues.
Why do you need to know that something is constant? Seriously - one of the
nice things in Pascal is that you can substitute a function for a variable
and just not care about it. (Yes, this can be abused horrifically).
> And what if we have to print our sourcecode on a black & white
> printer?
If you really need to know, use the typographic convention.
..
> > > If you're REALLY pedantic, just create a hard link to
> > > MyFirstProgram.java called myfirstprogram.java and be done with it.
> > > They're now the same file. ;-)
> > The horrifying thing is that Unix encourages this kind of
> > "solution" to the problem.
> You've missed the point. The point is - I don't consider that it IS
> a problem.
> "That's the way (uh huh uh huh) I like it (uh huh uh huh)".
> And since you can have it the way YOU want it as well in Unix, why
> would you try to stop me having it the way I want it?
I don't think that Unix really lets you operate in a case-insensitive fashion,
GUI or not.
> > My Unix shell does exactly that. It's horrible. My point is that
> > words in English have a correct spelling.
> Debatable. How does one spell "gaol"? "Colour"? "Theatre"?
> To any American reader, the above line contains 3 spelling errors.
Only if they are keywords (predefined perts of the language). User defined
names (like GAZZA) are only required to be consistent for all usages - you
could say Gazza and that would be OK, but Gaza would be a mistake.
> > They do not have an associated correct case, any more than they have
> > a correct font. It is perfectly legitimate to reject a misspelled
> > word - it is wrong to reject a word for incorrect case.
> Excepting of course that filenames need not be and frequently are
> not English words - so "correct" spelling is somewhat moot.
> > > You could even write a shell that did this, should you so desire.
> > > The shell could try first for an exact match, and then a case
> > > insensitive match, and translate myfi[TAB] to MyFilename.txt;
> > > there's absolutely no reason this couldn't be done. Go for it, if
> > > that's what you really want!
> > What I want (and I have said this many times) is, I believe,
> > impossible with any form of Unix.
> And I believe you're incorrect. It's certainly possible to have a
> shell that ignores case sensitivity.
But then if you have two files whose names differ only in case - which can
happen - your GUI is in a pickle.
> Unless, of course, you are DEFINING what you want as being "that
> which is impossible with any form of Unix", which is a little
> unsporting. ;-)
Life is too short to be fair to Unix. It has friends enough.
> Cheers,
> GAZZA
Keep 'em coming.
J.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Stephen Bodnar)
Crossposted-To: comp.os.linux.setup
Subject: Re: Adaptec AHA-1542 SCSI problem
Date: Thu, 15 Apr 1999 07:07:27 -0900
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Alan
Jones) wrote:
> Hi Peter Ludwig, et. al.,
>
> I'm writing to you because you seem knowlegable about 1542 SCSI
> problems from a message you had in the Linux Hardware newsgroup. I
> need to get an Adaptec 1542B SCSI card working so that I can install
> and use Linux.
...............................%>
> >Also which sort of 1542 do you have? Is it the AHA1542, the AHA1542C, or
> >the AHA1542CF? As I said I have the manuals, so I can check them for extra
> >info on your particular card.
I've successfully used Adaptec 1542cf cards with Linux. Once they are installed,
they are bomber. But it is has been a bit of a challenge to get them up and
running. The 4 biggest snafus that I ran into:
1) interrupt conflict - for some reason, scsi cards and video cards often
try to use the same interrupt. 10 for video and 11 for scsi or verse visa
has worked the best. On a 1542cf, this can be set either by dip switches
on the card or by the adaptec bios setup on boot (if you don't see the
adaptec bios screen at boot, then the card is probably dead, or not seated
fully in the slot)
2) memory address conflict - the older 3com 509C cards would default to 300H
which is what adaptecs would sometimes try to use. I set the adaptecs at
350H or 360H if nothing else was using it
3) problems with the boot floppy drive - the 1542cf has an oboard floppy
controller. this tries to take control, so I let it...I disable any
other floppy controller in the machine, and use the one on the adaptec.
dip switches is the best way to set this
4) if you got this far, watch out for termination. I disable the onboard
termination and do it manually - both ends of the scsi cable or a
terminated drive at the very end.
One other snafu that sounds like it doesn't apply here, on PnP motherboards,
I disable PnP for the slot that the 1542 is in and use LegacyISA.
Good luck!
Stephen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux,comp.os.linux.misc,comp.os.linux.networking
Subject: FREE Computer Documentation
Date: Thu, 15 Apr 1999 15:39:18 GMT
FREE Computer Documentation
books, standards, specifications, source code, and more
200+ megabyte archive online!
- graphics (quicktime, gif, jpeg, pcx, png, targa, tiff ...)
- emedia (cd-rom, dvd ...)
- internet (cgi, freebsd, html, http, javascript, rfc, tcp-ip)
- publishing (pcl, pcl4, pcl5, pdf, truetype, postscript ...)
<a href="http://doc.thesa.ru">http://doc.thesa.ru</a>
Welcome there.
--
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
