Linux-Hardware Digest #70, Volume #10 Tue, 20 Apr 99 11:13:52 EDT
Contents:
Re: All the current OSes are idiotic (was Re: Is Windows for idiots?) (westprog)
V90 Modem Setup ("Ray A. Lopez")
Re: XF86 and ThinkPad 560 ("David T. McKEe")
Re: Trouble with SB128PCI kernel 2.2.5/2.0.36. Request help. (Gerry Singh)
Kingston ethernet card ("Gary Prince")
Re: IBM ISA Token Ring Failing ("Arne K. Haaje")
----------------------------------------------------------------------------
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: Mon, 19 Apr 1999 17:12:39 GMT
In article <[EMAIL PROTECTED]>,
GAZZA <[EMAIL PROTECTED]> wrote:
> westprog wrote:
> >
> > Firstly, GAZZA, thank you for remaining polite ... Your tabloid
> > image seems to be a gross misrepresentation.
>
> My "tabloid image"? Err...perhaps you mean that "Gazza" is the
> nickname of the soccer player Paul Gascoyne (sp?). ...
I admit that I didn't really think that you were Paul Gascoigne - it just
struck me as amusing that he would be engaged in an earnest debate about the
minutiae of programming. ...
> > 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.
> Actually, you've got me there. Even in Fortran, where (IIRC) you
> can happily use commands as variables (ie there are no "reserved
> words"), the compiler can't get confused.
> So case sensitivity doesn't really buy you anything here from a
> compiler perspective (although I maintain it is still a handy
> thing to be able to declare a variable object of type Object).
> I profess to a certain ignorance here - in a language like Delphi
> (which I don't know, but I've heard is basically OO Pascal and
> presumably has the same case insensitivity of Pascal), is it
> possible to "overload" on class names and variable identifiers?
> (It's certainly not possible in the "C family", but due to case
> sensitivity it's less necessary).
I had better get out some Delphi books and have a look.
...
> > > > 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.
> This would be a feature of any language, however, if we look
> outside the case for a moment. If you compare the way to write
> "Hello World" to the screen in various languages, you'll instantly
> note that there are always subtle differences in context. It's not
> unreasonable to want a language where YOU specify what the command
> to display "Hello World" looks like - and indeed you can, if you
> create a function that does that and encapsulates the details away.
> For example, you could create a standard include file with a bunch
> of #defines to use uppercase keywords.
> Although I must be honest - such a procedure is fraught with danger,
> and really cannot be advised. I accept that this is a limitation
> of case sensitive languages - albeit one that I don't find oppressive
> (I tend to write Pascal with all lower case keywords, too).
...
> > > 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.
> You may be correct. Would you accept, instead, that most NEW
> development is done in the "C-family"? One COULD argue (I'm not
> going to, though - see below) that this is a sign that case
> sensitivity is an "improvement" on the "old" languages that didn't
> have it.
This is broadly true, but look at the huge amount of code still being written
in the various dialects of Basic - especially VBA. Melissa was written in a
case insensitive language, for example.
> > 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.
> I don't think such an argument is particularly persuasive, though.
> Similar arguments could be used to "prove" that Windows technology
> is state of the art - popularity doesn't necessarily (or even
> often) indicate technical superiority.
There are many cases where technology follows a particular path for reasons
quite unrelated to some abstract measure of merit. (It is considered mandatory
at this stage to refer to Betamax vs VHS).
> I'm hardly a "C-family" zealot; I admit I use (and like) Java and
> Perl, and I'll use (and tolerate ;-) C or even C++. But they are
> just tools; if another tool (Ada, for example) proves more useful,
> I'll use that instead. Case sensitivity isn't really a religious
> issue for me - I find its use in languages appropriate mostly
> because it tends to be there "by default" in case insensitive
> languages anyway, and there is something to be said for the idea
> that ANYONE can pick up a C program, anywhere in the world, and
> at least the keywords will be written the same. There may not be
> MUCH to admire in such sentiment, of course...
> I find it a little strange to have to work on Ada code from
> someone who hasn't done it "my way" (for "my", read "my
> company") - which is basically all capitals. I'm constantly
> faced with a mad desire to "recasify" all the "wrong" code I'm
> inspecting. I've never had this problem in C or Java (although
> on occasion the variable identifiers people choose in C cause
> me comparable problems - Sun's "universal Java coding standard"
> has largely avoided this problem for Java).
Of course, my desire to write C keywords with capitalisation must remain
forever ungratified...
> > > 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.
> The issue here is "how much freedom should a
> programmer have?" Do we go the "Java" route ("Use Sun's coding
> standard; enforce universal look for Java programs all around the
> world") or the "Perl" route? (which is ironic, since Perl is
> certainly case sensitive, but in all other ways they have bent over
> backwards to allow a large amount of freedom; ...).
> My personal take here is to try for the best of both worlds (IMHO).
> The keywords and so forth of a language should have only one legal
> representation (including case), but the language should NOT try
> to enforce any other paradigms except where absolutely necessary.
Again, I am ambivalent myself. I think that coding standards should be
rigourously enforced - but on a limited basis; only among those people who
need to read and edit the code. In the Linux community, or at Microsoft, this
could be a lot of people! If a universal system is enforced from the start,
it prevents any better systems from emerging.
> It wouldn't be too difficult to write a Java preprocessor that
> could take "DelphiJava" code (that is, case insensitive Java) and
> spit out "Pure" Java to the compiler. So you could, if you wished,
> still have case insensitivity for development purposes. This is a
> (primitive) form of Roedy's SCID idea, where the representation of
> code for a programmer is tailored completely to that programmer's
> desires.
I like the idea of code being supplied in a semi-compiled virtual format,
which could easily be rendered in many different ways. Languages like Delphi
and Java, with simple syntax and very fast compilation, lend themselves to
this approach.
> But in such a case you still need an underlying "standard" for
> communicating ideas and printing code samples in magazines; I
> suggest that this "underlying" code should be in a case sensitive
> language and (ideally) even go so far as to enforce the "coding
> standards" by making other possibilities syntactically illegal.
> (I've never understood why, if Sun was prepared to say that all
> class identifiers should start with a capital letter, they didn't
> go right ahead and make class identifiers that started with a
> lower case letter or an underscore illegal. Sounds to me like
> they lacked the strength of their convictions, or perhaps that was
> just too "anti-C" for them).
This is something I have noticed about Java. It is such an excellent language
that I can't see why they failed to do the extra little bit. Once they had
abandoned C compatibility, they might have gone further in ignoring C
familiarity.
> > > 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
> Did your point get trimmed here?
I probably just had a half-baked thought and decided to go back and finish it
later.
> Programs do have a certain amount of text in them, but they
> also have a lot more of what closely resembles mathematical
> symbols. I don't really think they can be regarded as "human
> readable" unless the said human is an "expert" - ie, a programmer
> who understands the language or a similar language.
Indeed, but the programmer can still benefit from textual hints that are
analgous to normal written language.
> I don't
> believe that we've really got the "language for the masses" yet.
> If you look at a lot of personal Web pages, you'll see the same
> Javascript (right down to logic errors) appear over and over
> again - the cut-and-paste method of homepage creation is by far
> the dominant paradigm, even with a simple language like Javascript.
I mentioned the Programming language used for the new Lego robot system
elsewhere. This is a purely graphical language, aimed at children. I imagine
that the programming system for the masses will be something like this, rather
than HTML, Javascript, Java, or whatever.
However, whatever system is used, programming can be difficult.
> (snip!)
> > Case conversion, however,
> > is something that the dumbest computer can do efficiently and easily.
> True enough, I suppose. I do think that case-sensitivity does make
> programs easier to read for humans, too, though - although I'd
> have to confess that this may not be the case for a novice. Maybe
> you're just a lot better than me (or a lot more tolerant than me)
> at remembering "Bar is the same as bar" when reading Delphi or
> Pascal code. Perhaps it's my laziness we're seeing here. ;-)
I agree that "Bar is the same as bar" can be confusing - but then so is "Bar
is different from bar".
> > 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.
> I'd certainly agree that it's not a speed issue. It does seem to me,
> though, that given you find case insensitivity more appropriate and
> I find the reverse, that we have come up with more support for
> Roedy's SCID idea. We could both have what we want, in such a case.
> (snip!)
> > > > 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.
> Your point basically being that "something is better than nothing",
> right? Hmm. There's a certain amount of sense to that idea, I have
> to admit.
> > > > 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.
> It's possible. But I confidently state that I think it could be
> avoided. Mostly, all you have to do is default to the proper case
> if there is ever a "clash" (ie two or more files that differ only
> in case).
I don't mind the GUI/shell/whatever giving helpful hints, but I think that
giving the user the impression that case doesn't matter will cause problems.
What happens when he starts using Emacs file open, for example?
...
> > What I would _really_ like is a more sophisticated approach to data
> > retrieval, where the nested directory/file/data is no longer
> > relevant.
> An interesting idea. What sort of features would such an approach
> have?
That is a big, big question. I will just throw out a few random ideas, and
leave the development of the system as an exercise for the reader.
I would strictly segregate executeable code from data. If data were to be made
executeable - a script file, for example - this would be a specific operation.
(Like chmod, but more fundamental).
The file structure would have object database capability.
Data files would be characterised by the operations that could be performed
on them. A JPEG file could be passed to a graphics editor - a text file to a
text editor. An HTML file could be processed by a normal text editor, or be
passed a a stream of content text to a spell checker. These operations would
be defined as supported interfaces.
A file would not be resident in a tree structure - rather, it would be a
member of various data sets. The JPEG of your auntie would be in the data set
of graphical data, of my new digital camera, and family history.
Compound data structures would be supported (similar to web pages). Your
aunties picture could be part of a family tree structure.
All data would have versioning information built in. Most operations would be
required to have an undo facility.
The location of data on local discs would be handled entirely by the system.
The user would have no need to relocate applications or data at any time. The
system would use spare space automatically to its maximum extent for caching
and making redundant copies of vital data.
File management would be unnecessary.
Backup media would be supplied with a unique identifying name/number, which
was also accessible to the system. If the user wanted to retrieve his aunties
picture before he drew a moustache on it, the system would say "Insert zip
disc 1777822517A" and load it for him.
These are just a few random ideas, which may or may not be possible.
> (snip!)
> > > 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.
> Here I am in complete agreement. The name of the file should not
> have anything to do with its type (and the extension IS part of the
> name of the file, IMHO).
> But I could probably argue the reverse, too. Playing Devil's
> Advocate for a moment, I can make a pretty good guess by scanning
> the program directory for a newly installed DOS application as
> to which program I should try and execute by examing all the .EXE
> files; it's not as intuitively obvious in Unix (although it is
> rarely a problem; Unix programs generally come with reasonable
> documentation for this sort of thing).
In my wonderful new system, you wouldn't execute files (execute - what an
appropriate name). You would enter supported commands, which would call an
interface to a system object.
If you wanted to list all the text files, you would submit a query asking for
the files which supported the ascii text editing interface.
> > 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.
> I agree. I'd even go so far as to say that DOS had it slightly
> better, because at least some extensions were system defined
> (.COM, .EXE, .BAT) whereas with Unix everyone could have their
> own standards. On both DOS and UNIX systems, I've seen .dat files
> used for either binary or text data files, and there's no way without
> inspecting them that you can tell by looking.
> However, such a system as you propose would require file types to
> be user definable - there would need to be some sorts of guidelines,
> and I'm really not convinced that it would necessarily solve the
> problem. (You'd have the same people just make their files of type
> "data", which still doesn't tell me whether this is something I
> can read in vi or not).
Forcing the user to define what operations the files support would solve this
problem.
> (snip!)
> > 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.
> Sure. Which makes the uses of uppercase have more "jump out and
> bite you" significance, and such things (user defined functions,
> most commonly) are usually the parts that you will want to be
> made aware of.
> > > 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.
> Oh, certainly. With the exception of that Perl remark (which I'm
> prepared to accept might simply have been a bad Perl book - they're
> out there), you've been scruplously honest. Gives your points a lot
> more validity; a zealot would refuse to acknowledge ANY deficiencies
> in case insensitivity, whereas all you're doing is saying that, on
> balance, the advantages outweigh the disadvantages. I can certainly
> disagree with you, but your attitude does engender a lot of respect
> for your position. Note that I'm not advocating you shouldn't be
> able to have what you want; I am (at best) trying to see how we can
> BOTH have what we want. ;-)
> > 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.
> Certainly; if an IDE can instantly translate keywords to a different
> colour, it can certainly change their case.
I would like an environment which insists that you declare an variable as soon
as you use it. Whatever case scheme you use in the declaration would be
automatically used elsewhere.
...
> The biggest problem with Pascal is that ANSI Pascal can't really
> do very much (by all means correct me if this has changed; I haven't
> touched Pascal since Uni). IIRC, even:
> program test(input, output)
> is not legal in ANSI Pascal (or at least doesn't do what it does
> in Borland Pascal, which is to say you're using stdin and stdout).
> It's a great teaching language, but it needs extensions (such as
> Borland Pascal - oh, sorry, that would be Inprise now, wouldn't it?)
> to be really useful.
> I've heard great things about Delphi, though.
They are all true. (Except that you still need to manage your pointers).
Most of the usability issues from ANSI Pascal have been resolved for the
Object Pascal in Delphi.
> > > 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.
> I wouldn't mind any of the above, IF it HAD to be that way. I'm
> not enamoured of caseless reserved words - but I suppose that's
> a fundamental difference we have (I like "universal" coding
> standards, where as you seem to prefer to allow each individual -
> or company - to decide upon their own. And I would have to say
> that your position is probably going to be more popular than
> mine with certain groups - Perl programmers, for example).
> > 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?
> In what way is that not the same as making variables case sensitive?
> Or are you suggesting that the case sensitivity ought to be applied
> only to variables, and not to reserved words?
I would prohibit changing your mind about the case scheme you preferred (i.e.
if you start with VAR, you stick with it.) I would make it fairly painless by
automating it in the programming environment/editor. But I would also
prohibit distinguishing tokens solely by case - so no "Object object".
> > 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.
> I've not used Occam; that does sound like an interesting idea.
> I do not like the Python method of inferring block structure from
> indentation, though - I'm not sure if that's similar to what
> Occam does.
I don't know either language well enough to say.
...
> > 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).
> You'll find advocates on both sides for that one. And I couldn't
> honestly say what my preference is - on occasion, I think it's
> nice to know a function/method is being called. On other occasions
> (accessor methods are a case in point) I would agree that it's
> nice to have no distinction.
It is usually wise to avoid hiding the cost of an operation. (This is one of
the dangers in OO programming generally).
...
> > I don't think that Unix really lets you operate in a
> > case-insensitive fashion, GUI or not.
> I think (I'm no expert on Unix shells) that it would be possible
> to write a shell that gave you case insensitive access to files.
> I can't think of any reason it wouldn't be possible.
> It won't help you with C or Java, of course, but they aren't
> "problems" just for Unix.
> (Indeed, the question must arise as to why nobody has already
> written such a shell. Either nobody using Unix likes case
> insensitive file matching - unlikely - or that such a shell
> DOES already exist, and I'm just not aware of it).
My guess is that it is more trouble than it is worth.
> > > > 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.
> Well, yes.
> However (slight tangent) I hate the way Americans force their
> terrible version of English on the rest of us. Every time I have
> to type in java.awt.Color, it still looks like a mistake.
> Oh, you can fight it. I did, for a while. I called my variables
> things like:
> Color textColour, bgColour;
> But it's insidious. When you initialize them, you still have to
> go with:
> textColour = Color.white;
> bgColour = Color.black;
> Sooner or later, it starts to look as if textColour and bgColour
> are spelled wrongly, and the strongest of us eventually bites the
> bullet and changes them to textColor and bgColor. Horrible, the
> sacrifices demanded of us. ;-)
There is a case for saying that Color is a specific computer quality which is
used to produce a particular Colour. That makes it an advantage. I hear that
non-English speaker find that having keywords with no semantic connotations
makes life easier.
> (snip!)
Heavy snipping, to try to keep this to a reasonable size.
J.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Ray A. Lopez" <[EMAIL PROTECTED]>
Subject: V90 Modem Setup
Date: Mon, 19 Apr 1999 16:51:04 GMT
I am having some problems getting linux to recognize a Creative PCI V90
56k modem on Redhat 5.2. Mainly I can't get the system to recognize it
on any com port. I have tried setting it ttyS0, ttyS1, ttyS2, and ttyS3
then dialing up my ISP through minicom, but to no use. Has anyone had
any luck with this particular modem or can offer some advice?
tia,
Ray
------------------------------
From: "David T. McKEe" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.portable,comp.os.linux.x
Subject: Re: XF86 and ThinkPad 560
Date: Tue, 20 Apr 1999 10:08:33 -0400
David Gulbransen wrote:
> Hello...
>
> I'm trying to get XF86 3.3.3 up on my Thinkpad 560 (model 2640-20U)
> and I'm havine a hell of a time getting it working in 800x600. I know
> it uses the Trident Cyber 9382 chipset, which I can't find jack on...
>
> I am also using XF86 3.3.3.1 which (supposedly) doesn't require the
> cy9382 patch I've heard about. I got 640x480 up without much problem:
>
> -Dave!
I had the same types of problems on my IBM 760E thinkpad. I found that the
SVGA was actually working but got "stuck" and required an X event to sort of
"push" it a little. I am sure a more technical definition could be given,
but I don't
have the gumption to find out...
What you do is press the Fn and F7 together after startx. Usually you only
need to
do this once after initial log on.
--
There is nothing so profane as viewing nothing sacred,
and nothing so sacred as it cannot be looked into...
--David T. McKee
------------------------------
From: Gerry Singh <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Trouble with SB128PCI kernel 2.2.5/2.0.36. Request help.
Date: Mon, 19 Apr 1999 16:23:21 GMT
I've got **exactly** the same problem you do - with a different motherboard
though. Have you been able to resolve this?
In article <[EMAIL PROTECTED]>,
a <[EMAIL PROTECTED]> wrote:
> Hi everyone.
>
> I'm having trouble with my SB128PCI sound card in the 2.2.5 kernel (and
> 2.0.36 kernel).
>
> I have successfully compiled the 2.2.5 kernel with the Eqsonic ES1370
> Audio PCI support.(not a module)
> (sndconfig recognizes my card as Eqsonic for some reason)
> I can hear the gnome and enlightenment sounds. But, I can't play audio
> from my cd
> I start gtcd, which works ok upto the point where it gets the cd info
> from CDDB.
> The CDROM even flashes, assuring me that gtcd is reading from the drive.
> But I don't get the actual sound on my speakers. I've checked the
> hardware connections both internally (wire from cd player to sound card)
> and externally (speaker plug, etc.). I've made sure none of the
> inputs/outputs in the CD mixer are muted.
>
> I've also tried cat /dev/sndstat. I get the error:
> cat: /dev/sndstat: Operation not supported by device
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Gary Prince" <[EMAIL PROTECTED]>
Subject: Kingston ethernet card
Date: Sat, 17 Apr 1999 16:51:06 -0400
Where can I get a driver for my kingston network card? Is there another
driver that will work for a Kingston? I have tried NE2000 and several
others, to no avail. Please help. Thanks,
Gary
------------------------------
From: "Arne K. Haaje" <[EMAIL PROTECTED]>
Subject: Re: IBM ISA Token Ring Failing
Date: Tue, 20 Apr 1999 16:11:32 +0200
[EMAIL PROTECTED] wrote:
>
I use this card myself on a heavily loaded webserver/mailserver, and it
works fine. However, I seem to recall that I had to use the DOS
utilities (LANAID ?) to turn off Plug'n'Play.
Arne
--
================================
Arne K. Haaje |
Enebakkveien 2 | M: 92 88 44 66
N-1825 Tomter | [EMAIL PROTECTED]
================================
The system needed Windows 95
or better, so I installed Linux!
------------------------------
** 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
******************************
