Linux-Development-Sys Digest #696, Volume #6 Mon, 10 May 99 06:14:23 EDT
Contents:
Re: Reliable (!) nic for 2.2 kernel? (Greg White)
Re: Reliable (!) nic for 2.2 kernel? (Don Baccus)
Re: Reliable (!) nic for 2.2 kernel? (Don Baccus)
Re: Glibc rant (Theodore Y. Ts'o)
Re: Destructive Erase? (Glen Turner)
Re: Mount multi-track CD ROMs? (Keith Wright)
Re: Kernel panic with 2.2.7 and MO devices (Kent Robotti)
Re: Compatibility with AT&T Unix (Terence Cheng)
Re: Glibc rant (Paul D. Smith)
3D Graphics Speed in Linux (Mike Harrison)
Re: 3D Graphics Speed in Linux (Daniel Robert Franklin)
Re: glibc-2.1 and incompatible apps (Sid Boyce)
Re: Any program can generate Gif or Jpg chart? (dovelet2) (Mihaly Gyulai)
Re: Reliable (!) nic for 2.2 kernel? (Roope Anttinen)
SCHED_OTHER ("Vladimir G. Stanishev")
Re: Glibc rant (Mark Shinwell)
----------------------------------------------------------------------------
From: Greg White <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Date: Sun, 09 May 1999 22:47:39 GMT
Don Baccus wrote:
>
> In article <[EMAIL PROTECTED]>,
> Greg White <[EMAIL PROTECTED]> wrote:
> >Don Baccus wrote:
>
> >> ?? 3c509b comes in PCI as well as ISA flavor
>
> >I'll take that a step further:
>
> >I know it is not so.
>
> >3C509 ISA 10 only
>
> At the risk of being impolite: bullshit.
>
> I have a box with an unused NIC in it sitting in front
> of me as I type this:
>
> Model: 3c509b-tx, Fast ethernet 10/100, PCI
>
> Who should I believe? You, or the unboxed NIC
> sitting on my lap? And, yes, I've checked the
> number, and it is 3c509, not 3c590. There's a
> picture on the box of the NIC, it's clearly PCI.
>
> I'll be stunned if it transmorgifies itself into
> an ISA card when I open the box when I build my
> next system.
>
> >3C59x PCI(some PCMCIA) some 10 only, some 10/100
> >3C90X PCI(some PCMCIA?) 10/100
>
> --
>
> - Don Baccus, Portland OR <[EMAIL PROTECTED]>
> Nature photos, on-line guides, at http://donb.photo.net
Gonna have to agree with Leslie on this one. Could you please, if it is
not too much of a pain, scan the aforementioned box's cover and mail the
resulting image to me? Even 3COM doesn't seem to know about that card. A
listing of all their fast-ethernet product shows no such model, and a
search of their knowledge base based on that model returns no hits. (A
search on 3c905b-tx, however, returns many hits.)
This is not an attempt to start a flame war, or meant to be rude or
insulting in any way. I have no problem believing that they may have
screwed up the box. I'd love to see that scanned image.
------------------------------
Subject: Re: Reliable (!) nic for 2.2 kernel?
From: [EMAIL PROTECTED] (Don Baccus)
Date: 9 May 1999 15:54:29 PST
In article <[EMAIL PROTECTED]>,
Greg White <[EMAIL PROTECTED]> wrote:
>Gonna have to agree with Leslie on this one. Could you please, if it is
>not too much of a pain, scan the aforementioned box's cover and mail the
>resulting image to me?
Actually, despite my recent note swearing it said 3c509,
I looked at it again and it DOES say 3c905 on the outside.
After opening the box and seeing it was a 3c905, I checked
the box again and I was transposing after all.
To my knowledge, I'm not dyslexic.
The rest of you probably suspect I am, though. Maybe I'd
do better if I were.
Sorry about misleading folks, I swear I looked at it twice.
I better go look at my camera system, to make sure it's
really Canon, not Nikon, I may've just misread the label :)
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
Subject: Re: Reliable (!) nic for 2.2 kernel?
From: [EMAIL PROTECTED] (Don Baccus)
Date: 9 May 1999 15:55:07 PST
In article <[EMAIL PROTECTED]>,
Don Baccus <[EMAIL PROTECTED]> wrote:
>Well, you got me curious enough to actually open the
>box, and ... the floppy inside says it's the software
>for the 3c905b.
>So, I guess they DID transpose the numbers on the box!
It me doing the transposing, ignore me. Good grief.
--
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, at http://donb.photo.net
------------------------------
From: [EMAIL PROTECTED] (Theodore Y. Ts'o)
Subject: Re: Glibc rant
Date: 09 May 1999 21:19:29 -0400
[EMAIL PROTECTED] (David T. Blake) writes:
>
> Making accomodations for closed source software in the development
> of open source software is a bad idea. The kernel, for example,
> absolutely does not do it - a good example being AFS, which has been
> broken in 2.2 development. The kernel developers basically told
> the people who had AFS problems to go see their vendors. The kernel
> source is available, and the vendors can easily make their product
> compatible. Tying the hands of the open source developers to preserve
> compatibility with people who will not share their source is a one way
> street - all give from the open source developers and all take from the
> closed source vendors.
It's not just about open source versus closed source. Even if all the
software involved was pure open source, users aren't necessarily going
to want to compile everything themselves, nor will they necessarily want
to get all of their software from their distribution.
Think about the power that would give Red Hat, or any other
distribution, if the only place where a naive user could get a binary
which could work on their system was from their distribution. I
therefore don't think it's a good idea to be continuously making
incompatible changes and not worrying about backwards compatibility.
The argument that "oh, everyone will just recompile from sources", and
"oh, everyone who can't recompile from sources will just get their
software from their distribution" is ultimately not very satisfying.
If we want Linux to be able to go beyond geeks and nerds, random
grandmother-types who don't know how to type "make" need to be able to
install binary packages that work on their system. It's immaterial
whether these binary packages are open-source or closed-source. The
fact of the matter is that binary compatibility is very important if
Linux is to ever advance beyond the "cute toy" stage for the vast
majority of the users out there.
Remember, our job as developers is to make life easy for the users.
It's not just to make life easy for ourselves. That is lazy and
selfish, and will simply cause our potential user base to keep buying
software from people who understand their needs --- even if that is
Microsoft. Maybe that's OK for you, but it's not OK for me.
Personally, I have higher aspirations for Linux.
- Ted
------------------------------
Date: Mon, 10 May 1999 12:06:15 +0930
From: Glen Turner <[EMAIL PROTECTED]>
Subject: Re: Destructive Erase?
Stefan Monnier wrote:
> Why bother ?
I second this. Destructive erase is a big ask.
It is doubtful that it can even be reliably done.
If you are serious about it, then physical is your
best bet: put the computer in a safe and when the
disk dies disassemble it and use an electric belt
and to remove the magnetic material from each disk
platter surface.
------------------------------
From: Keith Wright <[EMAIL PROTECTED]>
Subject: Re: Mount multi-track CD ROMs?
Date: 09 May 1999 22:03:01 -0400
Igor Zlatkovic <[EMAIL PROTECTED]> writes:
> Hello. Sorry, I was wrong.
So was I.
> I have looked at it again. The configuration help mentioned sessions, not
> tracks.
I took these to be synonyms.
> I understand that if you burn your own multisession CD and see only
> one session, you should enable this option. Some CDROM drives require this
> option in order to be able to handle multisession CDs. Mine does not, I can
> always see all sessions without this option (Plextor 32x SCSI drive).
Is this 2.0.36 or 2.2 you are talking about. And _how_ do you see the
other session? When I mount the CD it gets the first session, is there
an option to get the others?
> You were talking about tracks. Tracks are different thing.
A mistake. It is the second session I want.
> If you have a CD that has more than one data track, then the CD was not made
> according to the standard and other tracks are unusable.
I make them by running 'cdrecord' twice. More details are mysterious to me.
--
-- Keith Wright <[EMAIL PROTECTED]>
Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
--- Food, Shelter, Source code. ---
------------------------------
From: Kent Robotti <[EMAIL PROTECTED]>
Subject: Re: Kernel panic with 2.2.7 and MO devices
Date: 5 May 1999 15:21:53 GMT
Reply-To: [EMAIL PROTECTED]
Mike Dowling <[EMAIL PROTECTED]> wrote:
> I tried to create a filesystem on an MO device using
> % e2fsck -b 2048 /dev/sdc1
> and got zillions of errors. Since I could not interrupt the command, I
> simply turned off the MO device, and the kernel paniced. Admittedly, my
> action was drastic, but I would have thought that the kernel still should
> not have paniced.
> The bigger problem is how to create a filesystem on an MO device.
Use mke2fs to create a ext2 filesystem, e2fsck is for checking
and repairing a ext2 filesystem.
mke2fs /dev/sdc1
------------------------------
From: Terence Cheng <[EMAIL PROTECTED]>
Subject: Re: Compatibility with AT&T Unix
Date: Mon, 10 May 1999 09:55:05 +0800
Which Kernel are you using? Is it a Caldera modified kernel?
Villy Kruse wrote:
> In article <[EMAIL PROTECTED]>,
> Terence Cheng <[EMAIL PROTECTED]> wrote:
> >I have the following statement already working in AT&T SVR4
> >
> >ioctl(fid, I_SETSIG, S_INPUT | S_RDNORM | S_HANGUP)
> >
> >but I can't got the file to resolve the above macro. Is anyone know how
> >to resolve above problem ?
>
> That would require STREAMS support in your kernel. Caldera for example
> modifies the kernel to include STREAMS support.
>
> Villy
--
Best Regards,
Terence Cheng
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Glibc rant
Date: 10 May 1999 01:19:34 -0400
Reply-To: [EMAIL PROTECTED]
%% Peter Mutsaers <[EMAIL PROTECTED]> writes:
>>> "PDS" == Paul D Smith <[EMAIL PROTECTED]> writes:
PDS> I fully expect that when a .deb for glibc 2.1 is available,
PDS> it will also install just fine and everything will continue
PDS> to work as before.
pm> Alas, probably not 100%. Since glibc 2.0 and 2.1 have the same major
pm> shlib version number (6) in theory you cannot install both, and 2.1
pm> should be strictly upwards compatible with 2.0.
pm> However this is not the case (in incredible stupid thing IMO; at
pm> least they should have bumped the major revison number again to 7
pm> for glibc2.1)
Yes, but I'm not anticipating that being a problem for me. Why?
Because the good folks at Debian will have already figured out what
doesn't work and the new glibc package will handle that in some way.
At the very least it will warn me, and there may even be some kind of
builtin dependency, etc. so the updates happen automatically.
That is one of the main reasons we use package systems, right?
pm> making some tricks necessary, that may not always work (the
pm> relinking process in the Oracle 8 installation being an example).
I can see where proprietary apps have an issue. Luckily I don't need
any of those myself.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Mike Harrison)
Subject: 3D Graphics Speed in Linux
Date: 9 May 1999 05:16:35 GMT
I am no hardware genius, but I have been using Linux for
developping software engineering applications for about 3 years. Best
damn development platform out there I think. I've converted my whole
research group in fact. Well, I have been taking a ribbing from coworkers
about graphics(specifically gaming with quake II). Why is it that Win9x
is so much faster than Linux on the exact same hardware? Is the kernel
getting in the way? Bad drivers? Can someone explain this to me? I can
see why under X it would be slow with that data pipe set up, but why in
console? What could be done to speed up real time 3D rendering.
michael harrison
------------------------------
From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Subject: Re: 3D Graphics Speed in Linux
Date: 10 May 99 03:33:39 GMT
[EMAIL PROTECTED] (Mike Harrison) writes:
> I am no hardware genius, but I have been using Linux for
>developping software engineering applications for about 3 years. Best
>damn development platform out there I think. I've converted my whole
>research group in fact. Well, I have been taking a ribbing from coworkers
>about graphics(specifically gaming with quake II). Why is it that Win9x
>is so much faster than Linux on the exact same hardware? Is the kernel
>getting in the way? Bad drivers? Can someone explain this to me? I can
>see why under X it would be slow with that data pipe set up, but why in
>console? What could be done to speed up real time 3D rendering.
Unaccelerated speed should be better under Linux. The 3DFX
hardware-accelerated driver should be fairly good too, some machines
report better framerates than Win95, others worse. If its set up right
there shouldn't be much difference, if you have a supported card (3DFX
Voodoo I/II/Rush at present, hopefully soon Voodoo III and Voodoo
Banshee, maybe Riva TNT2).
- Daniel
--
******************************************************************************
* Daniel Franklin - Postgraduate student in Electrical Engineering
* [EMAIL PROTECTED]
******************************************************************************
------------------------------
From: Sid Boyce <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 and incompatible apps
Date: Wed, 05 May 1999 15:37:19 -0400
Nix wrote:
>
> It looks like you built or acquired a version of glibc-2.1 without
> symbol version information.
>
> If
>
> nm /lib/libc-2.1.so | grep '@@GLIBC_2\.0'
>
> yields no output, you have a glibc without symbol versioning.
>
> Solution: Build glibc-2.1 without the --disable-versioning flag.
>
> IMHO no versions should be built with this flag anyway,
> unless they have a set of binutils that do not understand
> versioning.
>
> --
> /* I hate C so much... */ --- jwz, in driver/xscreensaver.c
OK, glibc-2.1.1 was downloaded from redhat for 6.0. I also compiled
from sources, but haven't tried it, so I'll have another go as
suggested.
Thanks and Regards
--
... Sid Boyce...Amdahl(Europe)...44-121 422 0375
Any opinions expressed above are mine and do not necessarily represent
the opinions or policies of Amdahl Corporation.
------------------------------
From: Mihaly Gyulai <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Any program can generate Gif or Jpg chart? (dovelet2)
Date: Mon, 10 May 1999 09:24:03 GMT
In article <[EMAIL PROTECTED]>,
Dove <[EMAIL PROTECTED]> wrote:
> In Linux, is there any program or script can generate a Gif ...
> according to some ASCII data?
If you want something simple, try FLY. It gives Gif output from
ASCII data. Requires Perl to run.
--
Mihaly Gyulai
http://www.freeyellow.com/members5/gyulai/
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: Roope Anttinen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Reliable (!) nic for 2.2 kernel?
Date: 10 May 1999 09:50:56 GMT
Reply-To: [EMAIL PROTECTED]
In comp.os.linux.development.system bryan <[EMAIL PROTECTED]> wrote:
> my tulip card is totally unreliable. I can bring it down with an ftp
> xfer (local lan) at 10 or 100, in a minute or less. network hangs and
> will NOT be reset by software.
That's weird. One of the servers I administer has a tulip card and the
server has been up now for 178 days without any problems. Here's some
numbers:
RX packets:104749300 errors:0 dropped:13 overruns:0
TX packets:71530160 errors:4 dropped:0 overruns:4
cat /proc/pci reports the card as DEC DC21140 (rev 32).
Roope
--
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
[EMAIL PROTECTED] / [EMAIL PROTECTED]
+358 9 812 7567 / +358 500 445 565 / +358 49 445 565
http://myy.helia.fi/~anttiner/index.html
===========================================================================
Helsinki Business Polytechnic - Institute of information technology
------------------------------
From: "Vladimir G. Stanishev" <[EMAIL PROTECTED]>
Subject: SCHED_OTHER
Date: Mon, 10 May 1999 06:17:18 +0100
I am trying to understand how SCHED_OTHER works and how priorities are
assigned in general. I've been looking at sched.c for too long already
and I hope someone can confirm this. the way I understand it is that if
there are any processes that belong to SCHED_FIFO or SCHED_RR they are
scheduled as would be expected for fifo or rr based on rt_priority and
any processes in SCHED_OTHER are ignored. if all processes in the queue
are SCHED_OTHER, then SCHED_OTHER acts as a round robin based on the
normal priority. Is this right? in either case, can anyone also explain
the meaning of that 1000 that's added to rt_priority in goodness(). Does
it mean that the maximum "normal" priority that can be assigned is a
1000 (what's the range for priorities anyway)? and what's the reasoning
behind setting the range for rt_priority at 1 to 99 in sys.c? Thanx for
helping.
------------------------------
From: Mark Shinwell <[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: Mon, 10 May 1999 11:12:10 +0100
"G. Sumner Hayes" wrote:
>
> Of course. That's why I presented three different scenarios for
> people who build things themselves, people who run open-source
> distributions, and people who run closed-source binaries.
The trouble is that many people do all three.
> Because they're trying out APIs to find one that works. That's the
> whole point of development releases. Those internal calls aren't
> visible in the final release. They were visible in a development
> version -- that's a bug, but THE WHOLE POINT OF A DEVELOPMENT VERSION
> IS TO FIND THESE PROBLEMS!!!
I think we are confusing terms here; I was thinking of the development
release as one which has actually been packaged up nicely, and released
as if it were a release version (up to delving in the readme, or
whatever). If code which was not backwards-compatible was kept in CVS,
and only snapshots of it which preserved compatibility released as a tar
file or whatever, then it would help.
If something then needs changing it can be changed in CVS safely. In
order to make the next development "release" compatible with the
previous one it may well be necessary to provide a layer of fixes in the
library. Yes, this leads to "cruft build-up", but it is better than
breaking binary compatibility. And it would encourage more rigorous
specification in the first place to try to avoid some of the problems.
Forgive me for quoting a passage from earlier in this thread:
> > >My point is that when you're talking about a system library,
> > >a change should NEVER be the proximal cause of apps breaking.
> > >It's not a matter of whose fault it is, or who did what with
> > >the library that they weren't supposed to, etc.
> > >
> > >Does this cause cruft build up? Absolutely, and I'm as
> > >militantly anti-cruft as programmers get. But it's still
> > >better than breaking apps, because cruft costs less in
> > >the short and long run than alienating users and programmers
> > >with this sort of compatibility problem.
> >
> > This is really not a serious consideration in an open
> > source system. Everything can be recompiled. A distribution
> > upgrade was all that I required to be fully functional
> > again. If I didn't want newer versions of everything, I
> > could keep what I had. Anything that didn't work, I could
> > recompile.
>
> As long as the Linux community takes this view--problems can
> be solved by recompiling, that's the benefit of getting the
> source, etc., the mainstream user community will forever be
> a mirage on the horizon.
(end)
>
> > And if something _really_ needs to be changed, and the library has
> > already been adopted by a major distribution packager, then the
> > authors of the library ought to observe this and take appropriate
> > action to ensure that the mess we have at the moment doesn't arise in
> > the first place.
>
> Now that's just foolish. If Slackware* used linux kernel 2.1.57 for a
> stable release you're seriously suggesting that Linus then has an
> obligation to maintain 100% binary compatibility with that kernel
> throughout the life of the 2.2 kernel series? That's exactly
> equivalent, and so ridiculous to me that I can't even think of a
> rational argument for it (let alone one that I would agree with).
>
Of course not, what I was suggesting is that perhaps someone should have
spotted that Red Hat (and others - I notice Debian has 2.0.7) were using
development versions at the testing stage of the distribution (sorry, I
didn't imply that before) and brought it to their attention. Although
it escapes me why such versions were ever shipped with distributions in
the first place.
> You seem to think that binary compatibility is the sina quo non of system
> development
No, it may be ideal but it obviously can't always be achieved. However,
unless a really major change is planned, and people have been warned
that there will be problems - such as Solaris from SunOS - then I think
it should be strived for. In particular I agree entirely with
Theodore's posting elsewhere in this thread:
"If we want Linux to be able to go beyond geeks and nerds, random
grandmother-types who don't know how to type "make" need to be able to
install binary packages that work on their system. It's immaterial
whether these binary packages are open-source or closed-source. The
fact of the matter is that binary compatibility is very important if
Linux is to ever advance beyond the "cute toy" stage for the vast
majority of the users out there."
--
==================================================================
Mark Shinwell Queens' College, Cambridge University, UK
Mail: [EMAIL PROTECTED] WWW: http://mrs30.quns.cam.ac.uk
==================================================================
------------------------------
** 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.development.system) 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-Development-System Digest
******************************
