Linux-Misc Digest #593, Volume #24 Thu, 25 May 00 04:13:02 EDT
Contents:
FWD: Open DVD, EFF.ORG, DeCSS. (blackbird rises at sun rise)
Re: Print in Landscape orientation (Anthony Campbell)
Re: how to enter a bug report against linux? ("Peter T. Breuer")
Re: Multi swap partition ??? ("Lonni J. Friedman")
Re: how to enter a bug report against linux? (s@-)
Re: how to enter a bug report against linux? (Mark Wilden)
rtsp (Wei Lu)
Re: Configuring SIS 6326 in Linux !! (Joel Barrios)
Sendmail access very slow (chris)
May I use your Real Server? ([EMAIL PROTECTED])
Re: how to enter a bug report against linux? (Jhair Triana (Praktikant Atkinson))
----------------------------------------------------------------------------
From: blackbird rises at sun rise <[EMAIL PROTECTED]>
Crossposted-To: rec.video.dvd.misc,alt.binaries.sounds.mp3.d
Subject: FWD: Open DVD, EFF.ORG, DeCSS.
Date: Thu, 25 May 2000 06:10:21 GMT
OpenDVD group announces affiliate
program with Reel.com
===============FWD========================
May 25th, 05:07 UTC
OpenDVD.org serves as an online resource for people wishing to learn
more about implementing and extending DVD technology.
The OpenDVD Group (http://opendvd.org) has established as an affiliate
with reel.com (http://www.reel.com), an online movie retailer, to donate
the proceeds from DVD movies bought through the OpenDVD.org website to
the Electronic Frontier Foundation (http://www.eff.org), the
organization that is funding the costs for the defense in the DeCSS/DVD
lawsuits.
Full Story: http://linuxpr.com/releases/1894.html
==============================================
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Anthony Campbell)
Subject: Re: Print in Landscape orientation
Date: 25 May 2000 06:39:33 GMT
Reply-To: [EMAIL PROTECTED]
On 24 May 2000 14:51:26 GMT, Stearns25 <[EMAIL PROTECTED]> wrote:
>hello,
>
>Our platform is RH 6.0/
>
>We have several text-based spreadsheets that needed to be printed in Landscape
>orientation. However, I went thru 'man lpr' but could not find the switch
>for doing so. Does that mean I need to pass the file thru yet another
>filter? Or, is there a simpler way to print in Landscape?
>
>Thanks for any info and suggestions.
>
>
>-Stearns
>
In Latex:
1. You can use \usepackage{lscape}
and then the environment \begin{landscape} ... \end{landscape}
2. Or, you can use the command:
dvips [options] -t landscape dvifile.dvi
where options = XOFF, YOFF (values = 1.in, 2.in etc)
You can also have -t a4, etc in addition to above.
For plain text files, use enscript -r
Anthony
--
Anthony Campbell - running Linux Debian 2.1 (Windows-free zone)
Book Reviews: http://www.pentelikon.freeserve.co.uk/bookreviews/
Skeptical articles: http://www.freethinker/uklinux.net/
"To be forced by desire into any unwarrantable belief is a calamity."
I.A. Richards
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 25 May 2000 06:39:05 GMT
In comp.os.linux.misc Leslie Mikesell <[EMAIL PROTECTED]> wrote:
: In article <8ghmmi$ncg$[EMAIL PROTECTED]>,
: Peter T. Breuer <[EMAIL PROTECTED]> wrote:
:>They would have cared if they had known what they were seeing or
:>even if they had seen it. Did any distro ship with 2.2.7? (I waited
:>till 2.2.10 before judging 2.2. was safe). If so, there's the distros
:>frontlining job ready and waiting to be done. If not, it's the experts
:>job, and they'll mail a bug report to the kernel list.
: I've forgotten which versions shipped with which kernel, but
: there were a lot of cases of lost data reported. Many people
: just assumed that was the nature of Linux filesystems. There
THey should have assumed it was in the nature of linux distros. It was
the distros decision to ship an untested kernel. I didn't even
consider the idea.
: open file descriptor limits. The 2.2.x series is supposed
: to be stable according to the numbering scheme - why should you
: expect it to be broken?
(a) it's not broken, (b) it's not bugfree. Stable means not subject
to wilful new brokenness every day, like devel kernels.
:>Note that "caring" is an idea introduced by you. I was talking
:>about noticing.
: Caring is is the issue when it comes to using Linux at all. Can
: someone intelligently make a decision to store files they
: care about on a Linux box? What basis do you have for the
: answer without someone tracking real problems?
SOmeone who cares will care to check the answer. Look at the driver
changelist. I do it by counting bug report frequencies on the kernel
list and seeing when they flatten. In the case of the 2.2.* series,
I actually made heavy use of the debian bug report logs .
Also with respect to glibc. (about 1 year ago the bug rate was
still increasing, and had tripled since deployment)
:>Why? How does having a central repository increase the number of bug
:>reports received by maintainers? I'd be interested to know, since
:>part of your argument seemed to be that it would reduce the number.
:>Are you shifting your accounting methods? That's OK, but make it plain.
: Having a central repository would make it possible to see if
: a bug had already been reported. If it hasn't, it would encourage
: people to take the trouble to report the new ones and they
: would be able to report any new unreported details about existing
: ones without a lot of duplication.
Kernel bugs are not of that kind. Bugs that can be replicated are
fixed.
Bugs that can be identified are fixed. Fixed bugs show up in the kernel
change logs.
That leaves all the generic bugs. E.g. "ntfs doesn't work on write".
Nobody will do anything about that. It's documented.
:>You are saying that no distro comes with NFS ready to go?
: VALinux is the only one I know of that interoperates more or
: less correctly with non-Linux systems, because they include
: H.J. Lu's patches in the kernel as shipped.
Are you talking about nfs v3? (userspace) nfs v2 has been OK for years.
: It has mostly worked OK with itself except for all_squash being
root_squash? Yes, that's standard.
: the default for at least several versions. The problem is with
: other systems. I had a disk go out on a Sun box holding a
: cvs repository and replaced it with an NFS mount from an
: early 2.2.x kernel. Cvs locking is about as conservative as
Sun's expect nfsv3 with statd and lockd and so on. Those
are now present in linux, but I wouldn't trust them. Tell
the sun it has a v2 server.
: you can get, using the creation of a directory as the lock.
Well, dot-locking is the standard "conservative" method.
: I ended up with frequent lock contention where the directory
: was actually gone, but still appeared in the client's view.
This is an nfs design bug. Directory handling is strange. You know
about the mkdir; cd, rmdir; trick, and the time-to-believe timeouts for
executable files (which a directory is).
: I fixed this by switching to cvs's client/server model, but
: then found that doing a 'cp -R' to copy a directory tree from
: a freebsd machine to a Linux-served NFS mount ended up with
: mostly 0-length files.
If they were read-only files, quite possibly. The order of transfer
of data and meta-data has to be carefully controlled!
:>: The usual practice is to build regression tests for as much as
:>: possible so you actually have an answer for this. The people
:>
:>Unfortunately that does not tell you anything. Change is often
:>what was intended. The previous behaviour of the kernel is not
:>the standard for the future behaviour. The kernel has started
:>downing the whole interface when you down an alias of a net
:>interface, for example. Is this a bug? (I have been dealing with
:>this heavily today). Not according to most people on the kernel
:>lists.
: Of course it is a bug - even NT can do better than that. If you
: change the behaviour you should change the test and document
: the difference.
It's sort of documented in the ifconfig specs. But I assure you
that it is not a bug but an intended feature according to the
authors of the kernel code concerned. In the last few days it
has been discovered that the new behaviour is dependent on
IPV6 in the kernel, which makes it more obviously a bug. But
until then most of the network code authors were saying it is
not a bug.
Try it on any 2.2. kernel with an ifconfig more recent than 1.35
while the IPV6 module is loaded. ifconfig lo:0 127.0.0.2 ; ifconfig
lo:0 down. You should find that your lo interface has disappeared.
Moreover, you can't get rid of the alias. ifconfig lo up will
bring back lo:0 too.
This is not a bug. And some of the upstream maintainers of nettools
say it is not a bug either. (most now say it is a bug, but the real bug
is a kernel bug, but the kernel authors don't agree, though alan has
agreed to take a patch, since the IPV6 thing is clearly out of line).
How is an end-user going to spot a kernel bug? In the case above
he will be told that ifconfig is deprecated in such situations.
A kernel bug is often a matter of opinion.
:>: I think you underestimate the number of people who need this kind
:>: of answer or the time it would take to supply the correct ones.
:>
:>I don't. I answer about 100 mails a day. Probably half of those dealing
:>directly with codes I maintain. Most of the rest are dealing with
:>conversations over other codes, other peoples bugs, projects past
:>and present, articles, etc. etc.
: How far can you scale this up? Can you double it every 6 months?
I don't have to. My share of the total burden halves every 6 months.
I'm not at the apex of the pyramid.
:>As you know, it's a very heavily supported system.
: In its own quirky way. What the developers accomplish is
: great, of course, but they have their limits. I just don't
: think the support system can sustain growth. Even without
: a flurry of new bugs (which we may get with 2.4) the number
: of new people hitting old bugs is bound to grow, and these
: people don't need developer attention at all.
Old bugs are either fixed or "not a bug but a feature". Stable
means you get what you got last time, just a bit better.
: Yes, this is nice sometimes, but generally not. Suppose the
: question was needing files bigger than 2 gigs on pentium
: machines. How much developer time does each end user need
: to burn on that question?
Very few people need 2GB files on ia32. The ones who do are
savvy enough to kow they need them ad savvy eough to figure that
2GB is 2^31.
:>It became known to those of us on the lists that the eepro100 has a
:>limit of three hardware-serviced addresses. Anything more needs
:>a firmware trick and there are firmware bugs connected with it.
:>I.e. you should limit the hardware filters to three by telling the
:>driver so. It took a looong time to discover the bug. And whose bug is
:>it? Intel's? Donald's?
: That's exactly my point. There were people who knew about it
: but going through all the channels I could find turned up
: nothing.
Why didn't you just post to the eepro100 list? It's low traffic. A
bug report would have been welcome. Clicking on the drivers web page
shows the list link (and archive!).
:>Sure, start one up, but don't expect it to be used exclusively. I don't
:>kow what the effect would be. I think it wouldn't catch on.
: The effect would be that people would know what to expect from
: a Linux machine. That's mostly the point of bug tracking systems
No .. they'd see the bugs on the tracking system. That's all. My
contention is that that would be about 1% of the real situation
kown to developers.
: although getting the bugs fixed eventually is sometimes a side
: effect. However, it would have to be used heavily enough to
: accumulate at least the mainstream bugs.
Mainstream bugs (interesting bugs) are fixed at once, if fixable.
"NFS doesn't work right" is a bug, but not a very interesting one.
It works well enough.
: I've only used solaris and freebsd against it, and both failed
: in various ways. I've seen reports of aix/hpux having
I've been using solaris and irix against linux NFS (in both directions)
for years with no identifiable unsolved problems.
: similar problems. H. J. Lu found enough wrong that he has
: gone to the trouble of assembling patches to the kernel
: and tools after about every release. Has it been tested at all
: in cross-platform situations - where would I find the results?
: It is hard to use the excuse of not knowing expected behaviour
: for nfs as a reason for not testing.
I have a huge book on NFS semantics and design open on my desk at the
moment. It makes it very plain that NFS canot be expected to work the
way you wish under countless circumstances. That said, protocol
mismatches have existed from time to time, and been corrected.
Whose bug it was is moot.
:>But these are not kernel "problems". They are simply characteristics of
:>the present linux behaviour. They have to be learned in the same way as
:>always.
: The way things stand, every user has to experience every problem.
Distros are expected to solve that.
: That is even worse than commercial systems where they may not
: let you see the real bug reports but will at least try to steer
: you away from them.
Distros are commercial systems.
:>Are you saying that the raw admin has no way of finding out that
:>the rest of the world doesn't trust knfsd?
: Yes, and when he loses data and tries to find the solution it still
: is not easy. And it isn't much consolation to see that all of
: the other admins who tried something similar have been having
: the same thing happen for a year now. Why was knfsd blessed
: into an even-number stable release if it isn't trusted anyway?
You're not obliged to use it. And frankly, anyone using NFS is
in the < 1% category. Also it had to be put in so linux could compete
on speed. That was important.
: Try it. If you do a search you'll find my questions and a bunch
: of others with a lot of wrong answers and no system to tie them
: to the right answer if there ever is one.
"as you know", there are no absolute answers in this world. There
are an awful lot of variable parameters.
:>Ask yourself "bugs known by WHOM"?
: That's the problem. If anyone knows, why doesn't everyone?
Because it makes not one bit of difference to fixing bugs. Millions of
people can know that netscape can run wild when detached from the
console or when deprived of DNS, and that the 2.2.* OOM system can then
take out your X server (wrongly). It won't change it. Bugs are fixed
by communication and contribution among the many many developers
involved. The kernel is too complex for most anyone to be able to
work on in isolation. It's an interacting system. It needs an
interacting medium as the conduit for work on it. A bugtrack system
is not that.
Sure, set up a bugtrack, scan the kernel digests for the reports and
solutions, and keep it up to date. Every one will thank you. But it's
a deadweight in a moving world: the internet.
Peter
------------------------------
From: "Lonni J. Friedman" <[EMAIL PROTECTED]>
Subject: Re: Multi swap partition ???
Date: Thu, 25 May 2000 02:19:07 -0400
Benson Lei wrote:
> I know, up to now, RH Linux can only uses in maximum up to 128 Swap
> partition for one time,
> so I partition 3 partions for being used, but how can I use them together
> ???
That is completely untrue. The 128MB swap partition limitation was
removed with the advent of the 2.2.x kernel tree, well over a year ago.
------------------------------
From: s@-
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 24 May 2000 23:27:02 -0700
What I find the most amazing thing in this, is that we are aactually
arguing if a bug-tracking system is usefull or not.
This by itself just shows how far behind the linux developers
are compared to main stream software engineers when it comes
to modern software processes.
It is really is amazing.
How do we not know that with proper processes in place, that Linux
could have been ahead of where it is today by 5 years? People say
Linux is doing great the way it is. I say, it could be a much much better
system with better software engineering processes in place.
No Regression test suite per subssytem, no bug tracking system, no
proper software design processes, etc... Just becuase it "works"
in the current sloppy ad-hoc fashion, does not mean anything to me.
The fact that we have 500,000 lines of code, being worked on
by hundreds of programmers, and with not a proper way for users
to report bugs against it, is just a pathetic if you ask me.
Imagine Solaris or VMS or OS390 or AIX being build without having
a bug-tracking system. Tell the programmers working on any one of
the above OS's that no bug-tracking system is needed and see
what response you will get.
btw, this is not just against linux, it is against any software
project of large size that behaves the same way. Show me any such
project, and I will say the same thing about it. This is just not a linux
problem, it is a software engineering problem.
/s
------------------------------
From: Mark Wilden <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: Thu, 25 May 2000 08:29:38 +0100
s@- wrote:
>
> A regression test suite is of utomost importance. Can someone
> tell me where is one to test the ethernet driver for linux? I just
> made changes in one and I want to make sure I did not break
> something, how do I know?
Do you mean to say that there is no standard test suite to run Linux
code changes against? That each developer either writes his own, or
trusts to 'many eyes' to do his testing for him?
Good god.
------------------------------
From: Wei Lu <[EMAIL PROTECTED]>
Subject: rtsp
Date: Thu, 25 May 2000 07:30:01 GMT
where can i found a RTSP (Real Time Stream Protocol) Client?
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: Joel Barrios <[EMAIL PROTECTED]>
Subject: Re: Configuring SIS 6326 in Linux !!
Date: Thu, 25 May 2000 07:30:03 GMT
> Is there any special settings reqd.!! A detailed step by step
instructions
> will be highly appreciated.
Hope you may understad spanish, because I have a mini-manual for
configuring Sis 6326. Check
http://jjnet.prohosting.com/linux/como-sis6326.html . Now,
don't fear if you don't undestand spanish, the important part is that you
understad that it is needed to add three extra options in the Section
"Device" of /etc/X11/XF86Config:
Option "no_accel"
Option "sw_cursor"
Option "no_imageblt"
And one more that is optional: Option "fast_vram"
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: chris <[EMAIL PROTECTED]>
Subject: Sendmail access very slow
Date: Thu, 25 May 2000 08:44:42 +0100
Hi everyone,
I've just installed a Red Hat Linux 6.1 server on a small closed network
running Sendmail, Apache, FTP, DHCP and DNS. All works fine from any of
the connected machines - approx 10 PC's running a mixture of W95, W98
and WNT4.
However, when I connect to this network via a router, FTP access times
out, and times for sendmail range from 45sec to send new mail, and upto
75sec to check for new mail.
I think it may be a DNS problem, but as everything works OK directly
connected this may not be the case!
I'm fairly new to networks and also Linux, so any help would be
appreciated.
Chris
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.unix.bsd.freebsd.misc,alt.os.linux
Subject: May I use your Real Server?
Date: Thu, 25 May 2000 07:45:08 GMT
Hi everyone,
I would like to know if anyone here has installed a Real audio server on
their system and if they would let me test it for a couple of weeks.
I just need to know if this is going to work before I go off and install
Linux on my PC.
- I have a night shift at work (9:30pm to 6am) with nothing much to do
and I want to be able to to a live real g2 broadcast of the TV tuner
card I have at home.
For that I require a Real Server, but I can't find a public one
anywhere.
Please let me know if you are interested.
Thanks!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jhair Triana (Praktikant Atkinson))
Crossposted-To: comp.os.linux.advocacy
Subject: Re: how to enter a bug report against linux?
Date: 25 May 2000 08:02:02 GMT
In article <8gfnc4$[EMAIL PROTECTED]>,
s@- writes:
> In article <8gfhoj$3dt$[EMAIL PROTECTED]>, "Peter says...
>
>>
>>In comp.os.linux.misc John Hasler <[EMAIL PROTECTED]> wrote:
>
>>: How much sooner might those bugs have been fixed given a decent bug
>>: tracking system?
>
>>
>>None for the interesting bugs. Report an interesting bug,
>
> report? report?? How ?? That is the whole point of a bug tracking
> system you moron, it is to HELP people know how to report bugs.
>
> Not only that, there should be a defined way of what information
> to report to help the developer. The bug tracking system
> can ask for the correct information that might help the developer,
> instead of sending email saying 'hello, kernel just hanged, why??'
>
>>Boring bugs indeed will be forgotten.
>
> The will be forgetten becuase there is no bug tracking system.
> and no bug is boring. a bug is a bug. and how is to judge a
> bug is 'boring' ?
>
>>
>>: I'm running 2.3.99 on dual PIII's with an Adaptec 7896 and having trouble
>>: with sound: sending anything to /dev/dsp hangs the SCSI driver. If there
>
>>
>>I believe that's known.
>
> If there is a bug tracking system you do not have to guess. A user
> can simply check, and find out right away.
>
>>I've seen several threads go past on the scsi
>>problem in 2.3.99 and above. Doug's working on it. Ask him!
>
> who is Doug?? why would I care as user who is working on what? I simply
> found a problem in Linux and I want to report it.
>
>>
>>EH? Why don't you mail the maintainer? That's debian practice too!
>>
>
> A bug tracking system will automatically do that for you. send automated
> email to the developer(s) working on that part of the kernel.
>
> >
>>As you know, you might get Alan's interest on that one too. But 2.3.99
>>has hundreds of bugs like that
>
> Where is the list? without an official bug tracking system, this is
> a very sloppy way of developing software.
>
>> so it's not high priority yet. Make sure at least Doug knows about it.
>
> Doug who?
>
> /s
>
>
------------------------------
** 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.misc) 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-Misc Digest
******************************
