Eckhard Jokisch had some problems using an Onstream drive, and in the course of discussion, Rogier Wolff said:
Stay away from onstream is my advice nowadays.
We've been trying to get the stupid thing to work since july 8th, and onstream technical support has been very helpful by telling us what to do and such. Like downgrading to a kernel version that has known remote attacks. However doing that does not solve the problems we report. After much ado, they promise to "escalate" the problem to people in the states, and then this does not lead to results in the month we've given them.
In short: in the simplest case, just writing a stream of bytes to the drive, it works. But the drive then doesn't nearly have the "raw error rate" that they claim.
If you start using a backup program that needs to seek back and forth a few times, the drive loses track where it is, and doesn't recover from this situation.
I've returned mine to my vendor, and I hope that Onstream gets the message in the end: They do NOT support Linux.
But Kurt Garloff dissented, I've been using
the USB and the SCSI versions of OnStream tapes with good success!
He added, If you want a really helpful advice:
Use the osst driver and the use it with ide-scsi. Report problems to the
osst mailing list. So far, I'm not aware of anybody we failed to help. http://linux1.onstream.nl/test/
Eckhard replied, This was really really
helpfull :-) It just works fine now. Wouldn't it be good to put a slight
hint somewhere in the kernel configuration?
End of thread.
Matti Aarnio announced that he'd removed all the mail-to-news feeds from
Innominate. These included feeds from linux-alpha, linux-doc, linux-fsdevel,
linux-kernel, linux-raid, linux-scsi, linux-smp, sparclinux, and ultralinux. He
said, Officially we don't approve bidirectional
news<->list feeds, as those are prone to this type of blunders of
looping messages back to the list.
Juri Haberland from Innominate explained:
We know that this is a difficult setup and we tested it thoroughly before using it, and it worked for a long time now. Unfortunately one of our admins updated the news server today without thinking of the implications :-(
We deeply regret this and apologize honestly, but also would like to resubscribe...
Rik van Riel suggested making the feeds one-way this time, as the bi-directional feeds always tended to give problems, in his opinion. Juri replied that they'd do this, since there didn't seem to be much choice. But Miquel van Smoorenburg offered:
At ftp://ftp.cistron.nl/pub/people/miquels/software/cistron-m2n-1.36.tar.gz you'll find some gatewaying software that is unidirectional, yet bidirectional ;)
It works by marking the groups as moderated. A posting to the group will be sent by mail to the moderator, which is a script that checks and rewrites the news message, and sends it to the list.
That way it's almost impossible for loops to get created.
Elsewhere, Marco d'Itri announced, If vger
postmasters do not mind, next week I'm going to unidirectinally gate
linux-kernel (and maybe other high traffic vger lists, any suggestions?) to
a group in the linux.* hierarchy.
Matti replied, You are welcome to do that. It is just the BI-directional gatewaying
we are opposing for well observed reasons... (People are doing bidirectional
gateways regardless of our opposition -- "we are good, we won't do it wrong",
but when things irregardless do go wrong, we have to do some drastic measures
to cut the loops.)
Georg Nikodym reported that sysklogd 1.3-31 no longer compiled using
the headers from 2.4.0-test11, because linux/module.h had changed in an
incompatible way. He added, Strictly speaking
this isn't a kernel bug
[...] It's not
clear to me who's code needs changing so I'm sending both to linux-kernel
and to some of the people that have the misfortune of being listed on the
sysklogd man page.
Keith Owens replied:
Speaking as the modutils maintainer and the person who added list.h to module.h, sysklogd should *not* be including linux/module.h. Linus has spoken, it is an error for user space applications to include kernel headers. Even modutils does not include linux/module.h, instead it has a portable (2.0 through 2.4) local definition of struct module.
ksym_mod.c is only present to try to decode oops reports in klogd. klogd only handles some architectures, it often gets the oops decode wrong and it destroys the log information that is needed by other oops decoders. IMNSHO ksymoops does a much better job of decoding the oops, but I maintain ksymoops so I am just a little biased ;)
I would prefer to see the oops decoding completely removed from klogd. The only justification for klogd converting the oops is to save users from running ksymoops by hand. I would not mind klogd capturing the oops text, forking to run ksymoops then logging the ksymoops output. Just as along as the original text was left alone and the ksymoops output was obviously distinguished from real kernel output.
Georg implemented this suggestion and posted a patch, but Keith
replied, You only removed the module symbol
handling. The problem is that the entire klogd oops handling is out of
date and broken. I recommend removing all oops processing from klogd,
which means that klogd does not need any symbols nor System.map.
Georg replied that he'd look into that, and added, while we're doing extreme surgery, why have klogd at all?
Every other unix, kernel messages are handled by the syslog system. What
problem did klogd solve and does that problem still exist today?
He suggested that Keith's proposal would be the functional equivalent of
'cat < /proc/kmsg > /dev/log &'. Keith
explained, klogd maps the kernel messages from
<n>text to syslog levels and does some fiddling with kernel log levels
at start up. It needs to be more than a simple 'cat'. When symbol handling
was added to klogd, ksymoops was built into the kernel and very unreliable.
Since then ksymoops has been moved to a separate package and is now reliable.
Alas oops handling in sysklogd has not kept up to date and is now the problem
area.
Georg performed an appendectomy, taking all symbol processing
code out of sysklogd, and suggesting removing several files from that
package as well. But now Keith objected, Looks good,
except that you need to keep the option flags for backwards compatibility.
There are a *lot* of scripts out there which invoke klogd with various options
and they will fail with this change. It is OK to issue a warning message
"klogd options -[iIpkx] are no longer supported" as long as klogd continues
to run. Otherwise you will get a lot of irate users complaining that klogd
is failing at boot time.
George posted a new patch to list various
command-line options as obsolete, and the thread petered out.
Mike A. Harris asked which ethernet module to use with his D-LINK
DFE-530-TX card. Peter Horton replied, If
the PCI device ID is 3065 then it's via-rhine, but not supported by the
driver in the kernel. Get updated via-rhine from Donald Becker's site http://www.scyld.com/network.
But Jeff Garzik pointed out, 2.4.x-test has some
fixes for via-rhine which don't appear to have made it into the Becker
driver yet...
Simon Huggins asked if either of those would make it into the stock 2.2
via-rhine, and Jeff said, Becker never replies to
patches and changes I send him, so who knows. Ask Becker...
Alan Cox
also said he'd include a port into 2.2.19pre if someone would write it. Urban
Widmark posted a lengthy patch and explained:
Below a patch that updates the 2.2 via-rhine driver from Becker's 1.08b, except for the pci probing that is unchanged, compatibility macros and dead code that are not needed in 2.2 removed (removing ifdef CARDBUS is from 1.08b) and "clear_tally_counters" from 2.4.
It would be nice if people using 2.2 and one of these cards could test this too.
Patch includes:
- new VT6102 pci id & supporting non-aligned data buffers for that chip
- completely untested (by me, that is) big<->little endian stuff
- free allocated memory on driver unload
- no more writel to 0x7c.
- 2 16bit values accessed as one 32bit (why? not sure, pci optimization?)
- change transmit ring size
and some other more or less minor changes/cleanups.
This is mostly a copy&paste operation. If you'd rather get a smaller change for just supporting the VT6102 that is easy to do.
However, this is very similar to the 2.4 driver (locking is a major diff) so I hope it is ok. Also, if I don't include most of the 1.08b driver I'm not sure what version name to give it ... :)
There was no reply.
Jeff V. Merkey pointed out that he'd already sent out thousands of his NTFS
repair tools, to folks contacting him after corrupting their filesystems with
the badly broken read/write NTFS filesystem support under Linux. He added,
I will keep providing this service, but I am only
treating the symptons of the illness and not curing the patient. Based upon
the level of contamination of TRG with Microsoft IP, I have been advised if
I post an NTFS replacement before the 18 month doctrine of inevitability
"window" is past, Microsoft will most certainly sue us, and win.
He suggested alerting users that the feature was dangerous and unstable,
and that they shouldn't use it. Peter Samuelson replied:
Here's an idea: let's make r/w support a separate CONFIG option, and label it "DANGEROUS".
Oh wait, we already do that.
Perhaps we should warn users to back up their NTFS partitions before trying this option. Put that warning in the help text for CONFIG_NTFS_RW.
Oh wait, we already do that too.
How stupid does one have to be in order to enable an option labeled "DANGEROUS" for a non-experimental system?
Later, Michael H. Warfield also added, It
can't even be enabled unless you enabled experimental code options. Then, it's
disabled by default and you first have to enable the R/O NTFS. Then you have
to explicitly select the option to enable RW access that is clearly labeled
DANGEROUS. This thing is not armed and dangerous due to an act of ommision.
It's live and active only through three acts of commision. About the only thing
left, short of removing it from the kernel entirely, is to make the option
a hidden control option, like some of the debugging options, that requires
editing a header file or a Makefile to enable.
Further along in the
thread, Peter also suggested, comment out the
CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good idea.
Anyone who has any business messing with NTFS_RW is more than capable of
editing Config.in.
Jeff Garzik agreed, and added, I would prefer that filesystems with known broken write support
depend on CONFIG_BROKEN (which would be always defined to 'n')
Elsewhere, Jeff V. M. added, I've got even
more bad news -- because it's in Linux, Microsoft is already altering the
on-disk structures again, so it's about to be broken in R/O mode as well
when Whistler comes out.
In response to the idea that no additional
warnings or preventative steps needed to be taken to keep people from trashing
their systems, he added, You guys make the call.
I will be here to catch the 100+ messages that would normally be posting to the
kernel list with "Linux destroyed my data", and I have been handling them.
I am just alerting you guys that the numbers of people needing this are
increasing, which is an indication more and more people are using Linux to
migrate NT to Linux, and vice-versa, and getting themselves into trouble.
We need to brainstorm a more long term solution for this problem. I suspect
if I post these tools on our FTP server for free download, MS will promptly
show up with attorneys. Normally, this is what I would do, but these tools
were developed via access to MS IP, and so long as I am helping MS customers
recover data in a "consulting" capacity, I do not believe they will interfere,
particularly since everytime this happens, Linux gets a great big black
eye with the affected customer. But very soon (like after 2.4 ships) the
numbers of folks needing this may increase to a capacity I cannot support
properly without dumping these tools into general distribution -- then the
shit will hit the fan with MS if I do this.
Eric W. Biederman said that if Microsoft were deliberately preventing interpoerability between Windows NT and Linux, that Jeff V. M. should alert the antitrust lawers. But Jeff V. M. replied:
I think the anitrust issues are moot -- they have had their way already with Microsoft. They've been left beaten and crippled in the eyes of the general public. Large Customers seem to not be swallowing .NET.
Their behavior is inconsistent with the Trial Judge's ruling. Technically, by pursuing .NET, they are not observing the spirit of the ruling. If you get a ruling put on you by a court, you are supposed to observe what it says and correct your behavior, even if the execution order was stayed by the court pending appeal. The Judge did not set aside the ruling -- it's still there.
Because of this, any investment in Microsoft strategies by large enterprise customers are an unknown until the appeals court makes a determination. Microsoft is also setting itself up for a contempt order by doing this. The trial court told them to stay out of the internet business with their operating systems business unit. Their compliance has been illusionary with the court's ruling, and unless the appeals court vacates the ruling, they could be in big trouble.
If I were the DOJ, I would already be putting together an OFC for filing with the trial court. They are also doing the worst possible thing you can do while a case is on appeal, which is to ignore the trial court's rulings, and resorting to character assisination of the trial judge.
Elsewhere, approaching the entire problem from a different angle,
Ren Haddock said, I think part of the problem is
that there are other things labeled DANGEROUS that actually do work fairly
reliably (offhand, I'm thinking off the IDE config stuff..). Perhaps it
needs to explicitely say 'This is broken and is gauranteed to destroy your
data. Do not use it'. The 'DANGEROUS' label seems to suggest that it -may-
destroy data, which leads to the 'it won't happen to me' mentality.
Andre Hedrick replied historically:
DANGEROUS == GO_FOR_IT_DUMB_ARSE_SCREW_YOURSELF_WILDLY
This is the intent, when I put and started the DANGEROUS settings. Because the volitale nature of extreme alpha code in the beginning. However as time passed, people did not think it had meaning, but that is what it orginally was defined by me.
David Feuer agreed with Ren, the "Dangerous" label did not seem to be an
absolute warning not to enable a given feature. Daryll Strauss suggested
relabeling those features as "Broken", but Jes Sorensen replied, I doubt it will make any difference whatever we write. I
have seen several times how users enable every single option because 'they
don't want to miss out on anything'.
At one point, John Alvord remarked:
If this was a business, and we were knowingly distributing software that was known to be dangerous, we would probably be risking legal action.
Why are we distributing such severely broken software? Heck, we seem reluctant to include reiserfs, a pretty high quality, supported file system. And we continue to distribute this !@#$%... There must be some strange agenda going on to limit the use of Linux.
But Horst von Brand replied that it wouldn't be legal, since there are
prominent warnings displayed. He added, It is
just that NTFS has been in the kernel for ages, and rotted. Nobody has taken
the time to remove it (would be a lot less than what has been wasted up to
now discussing the matter here...).
Neale Banks reported:
I compiled the Debian distribution of 2.2.18pre21 source on and for a AcerNote-950, with APM enabled.
All is fine except that I can reliably "oops" it simply by trying to read from /proc/apm (e.g. cat /proc/apm).
oops output and ksymoops-2.3.4 output is attached.
Is there anything else I can contribute?
Alan Cox replied:
The latitude and longtitude of the bios writers current position, and a ballistic missile.
Please boot 2.2.18pre24 (not pre25) on the machine and send me its DMI strings printed at boot time. I'll add it to the 'stupid morons who cant program and wouldnt know QA if it hit them on the head with a mallet' list
Neale did this, but couldn't see anything resembling a "DMI string",
and Alan replied, Ok your machine probably doesnt
have DMI then. That unfortunately means its hard to identify the specific
machine.
After walking a brief staircase together, Neale came up
with a patch to work around his buggy BIOS.
Fabien Ribes noticed that information on the status of Linux with regards
to RFC 1122 (Requirements for
Internet Hosts -- Communication Layers) was scattered throughout numerous
files. He asked, Is there a complete document showing
RFC1122 status as a whole for a given kernel version ?
David S.
Miller replied shortly, No, unfortunately
nobody has the time to do this.
Andi Kleen added, The RFC evaluation is also out of date and should be either redone or
removed.
David agreed, and said he'd remove all the "RFC1122 Status"
comments from net/ipv4/*.c unless Andi wanted to fix it up. Andi replied,
Kill it ;)
David replied, Done. Seriously, if someone wants to do this work please contact
Andi or myself, we are willing to give some assistance.
Fabien said he
might have time to do some work on it; but there was no more discussion.
Steven Cole used kernel compilation time as a benchmark, and concluded that
on uni-processor systems, 2.2.18pre26 was 3% faster than 2.4.0-test12-pre7 at
building kernels. But he remarked with tongue in cheek, However, the margin of victory is small enough that a recount may be
necessary.
He also added that he'd used gcc 2.91.66 (kgcc) to compile
the 2.2.18 kernel used as the OS in the test, and gcc 2.95.3 for the 2.4.0
one used as the OS in the test. Several folks objected that kgcc would make
a faster kernel than gcc, and that to be fair, the systems hosting the tests
should be compiled with the same kernel. Steven replied with some new results,
in which he showed that kgcc did indeed create slightly faster kernels than
gcc. But rerunning one of his tests showed only a few second's improvement over
the earlier one. He added consistently, but I think
we're getting into the pregnant or dimpled chad thing at this point.
So his initial report seemed to stand, and there was a brief discussion
of why 2.2.18 might be faster than 2.4.0. At one point Alan Cox remarked,
Its an interesting demo that 2.4 has some performance
problems since 2.2 is slower than 2.0 although nowdays not much.
Later, Steven ran a similar set of benchmarks on SMP systems, and reported that for those systems, 2.4.0 was 2% faster than 2.2.18; Linus Torvalds replied:
Note that kernel compilation really isn't a very relevant benchmark, because percentage differences in this range can be basically just noise: things like driver version differences that show up, but impact different machines different ways (maybe one driver is better for certain machines, and worse on others. Things like that).
The setup you descibe is just too CPU-intensive, with little potential for truly interesting differences.
Steven had mentioned that in the SMP test, he'd ran
X and KDE 2.0 during the tests to provide a greater though reproducable load
on the tested kernel.
Linus suggested, in his same reply:
You might want to do the same in 32-64MB of RAM. And actually move your mouse around a bit to keep KDE/X from just being paged out, at which point it turns un-interesting again. I don't know how to do that repeatably, though, but one thing I occasionally do is to read my email (which is not very CPU-intensive, but it does keep the desktop active and also gives me a feel for interactive behaviour).
At that point the numbers are probably going to show more difference (and the variation is probably going to be much bigger).
Steven tried the same test again, doing a 'make -j3', moving the mouse
around, and switching desktops a few times; and reported, These results are even closer. The differences are so slight, that
they are not statistically significant. Hmmm, maybe no news is good news in
this case.
Linus suggested:
Actually, do it with
make -j3 'MAKE=make -j3' bzImage
A single "-j3" won't do much. It will only build three directories at a time, and you'll never see much load. But doing it recursively means that you'll build three at a time all the way out to the leaf directories, and you should see loads up to 20+, and much more memory pressure too.
Steven tried this, and reported that 2.4.0 still finished 1.3 seconds faster than 2.2.18, and the system load stayed lower as well. There was no more discussion.
In the course of discussion, Alan Cox gave his expected timeline for
2.2.19. Regarding some possible changes, he said, That
wont be happening in 2.2 until 2.2.19 which probably means 6 months.
Horst von Brand requested a quick 2.2.19, to include just the particular
bug fixes under discussion, but Alan replied, Shall
I do a 2.2 release for every trivia. I think not. There is plenty to get
into 2.2.19 already.
End of thread.
Mark Symonds reported locked boxes with many "VM: do_try_to_free_pages
failed" errors scrolling down the screen on 2.2.18; he added, Something else I noticed is that the Load average is usually around
0.08, but when I let it idle for a few mins, just tapping the spacebar in a
terminal will cause it to stop responding for 10 or so seconds with the load
average skyrocketing to over 6. After that the system sometimes recovers
and starts responding normally, other times it will die.
Alan Cox
replied, Andrea's VM-global patch seems to be a wonder
cure for those who have tried it. Give it a shot and let folks know.
Mark and someone tried the patch and reported complete success, at which
point Alan remarked, I think Andrea just earned his
official God status ;)
Another person asked if Andrea's patch would make
it into 2.2.19, and Alan replied:
The question is merely 'in what form' . I wanted to keep them seperate from the other large changes in 2.2.18 for obvious reasons.
Andrea - can we have the core VM changes you did without adopting the change in semaphore semantics for file system locking which will give third party fs maintainers headaches and doesnt match 2.4 behaviour either ?
Andrea Arcangeli replied with some technical comments, and he and Alan went back-and-forth for awhile.
Rob Landley gave a pointer to a LinuxToday
news article, and explained, Scott McNealy has
apparently been calling Solaris Sun's implementation of Linux. Trademark
violation time.
He quoted the article, which quoted Scott (Sun's
CEO) as saying, You people just don't get it, do
you? All Linux applications run on Solaris, which is our implementation of
Linux.
Rob admitted that the source of the quote was questionable,
but that assuming the accuracy of the quote, this
strikes me as a mondo trademark violation, and exactly the sort of thing
the Linux trademark was designed to prevent. Solaris is NOT Linux.
There were several different takes on this. Rik van Riel said, I wouldn't worry about this. It's only a question of time
before people will start to ask him why Sun isn't shipping the "original Linux"
but has their own, strange, version ;)
This sent Igmar Palsenberg into
peals of laughter, but Rob replied, Sure. But why
HAVE a trademark if we don't enforce it? Grassroots support is always a
wondeful thing, and educating the public is extremely important. Then again,
what McNealy's trying to confuse his customers. Enforcing the trademark
would therefore serve an educational purpose, wouldn't it? :)
Elsewhere, Kevin A. Burton felt the Scott's remarks, even if accurate, looked like just an "off the cuff" remark, and were no cause for concern; but Rob replied:
Law isn't an all-or-nothing thing. Obviously this isn't worth a lawsuit. By itself it's not even close.
But sending an official letter asking them to respect the trademark counts as "defending the trademark" if it's abused in the future and we DO want to get serious about it. (Neutralizes this as a precedent slimy lawyers can point to of "Linux" being undefendable as a trademark and instead being a generic term.)
And if the pattern of behavior WERE to continue/get worse, having gone through the appropriate steps way back when (measured, proprotionate response to earlier incidents) makes a much firmer foundation for a lawsuit later.
And, because Sun's lawyers know that last point, they're fairly likely to take it seriously enough to let McNealy know that his course of action carries certain risks. (Remember that Meme Hacking talk, at the Fortune 500 it's all about reducing and managing risk.)
It's a bit like saying your cat's name when you see them up on the coffee table where they're not supposed to be. It's not the same as actually punishing them, just letting them know you're aware that they're doing it.
Elsewhere, Jon 'maddog' Hall commented on the entire situation:
This does bring up an interesting situation.
The Linux community keeps saying that "Linux is a re-implementation of Unix."
This gets X/Open all pissed off at us, because Linux has not passed the qualification test suites which they use for branding. So we get around that by saying "Unix is a lot like Linux, except it costs a lot of money, comes in binary form, etc. etc."
Yet there is no real definition for "Linux".
Some people (the FSF for instance) say that Linux is just the kernel, but there are different kernels, with different patches.
There was even a Microkernel version of Linux called "MKLinux".
Others say that Linux is the whole distribution, but there are lots of distributions, all different (Red Hat, SuSE, etc.) There are different placements of files in the file tree.
I know from conversations with Linus that he anticipates having (perhaps) radically different kernels on top of "BIG IRON" machines, where the kernels (and the distributions) come from the "BIG IRON" makers.
The licensing of the Linux trademark has basically allowed someone to use the term "Linux" in their own trademark, but has done nothing to prevent someone from comparing their accumulation of code with "Linux", and nothing to define what Linux actually is.
If it is true that "all Linux applications work on top of Solaris", what standard prevents them from calling Solaris just another implementation of Linux? And should it?
From an ISV perspective, the more distributions of software that run their products binary compatible, the better off we are against Microsoft. If Linux does not handle the very high-end machines (yet), then why not let those applications run on Solaris? If people want to pay for Solaris, take the binary-only distribution from Sun and run it on that large iron, why not?
On the other hand, I think we need some type of definition to what is called "Linux". Perhaps this is where the Linux Standard Base might be appropriate.
Rob agreed with many of Jon's points, but still felt that
Sun is free to put out a version of Linux.
But to call Solaris Linux is, in my opinion, going over the edge
here and diluting the trademark.
He gave a link to a post
from Linus Torvalds explaining Linus' general stance on the trademark
issue. He added, If we said Linux was actually
Solaris, Sun would be all over us with Lawyers. They'd have to protect their
trademark. If Red Hat called its next release of Linux
[...] "Red Hat Solaris", they'd get sued.