KT got a lot more traffic last week because the editorial on the "Linux" vs. "GNU/Linux" debate was mentioned on Slashdot. If you're interested, check out the slashdot discussion. I'd like to thank all the people who emailed me personally about it as well.
There was some feedback on the layout change. A number of folks pointed out that there should be a permanent link for the latest page. So that's up in the links section, and the URL is http://kt.zork.net/latest.html
I mentioned Loren Osborn last week in
Apparently linux-kernel was accidentally receiving bounces from a Japanese
Linux list, resulting in a lot of Japanese-encoded text showing up as
garbage ascii on linux-kernel. Matti Aarnio said, ... well, I hope I got them all before more arrived to the lists.
Because it looked like a loop at somebody's mailbox retrieval software, I
have blocked that particular source address from sending to VGER for a while
-- say for next few days. I will try to remember to remove the block latter
this week.
Elsewhere Aaron T Porter, one of the maintainers of linux-kernel, said he had sent nasty letters around. Matti replied:
I really wish you folks had better sense than sending any nasty letters, or for that matter, REACTING AT ALL, when somebody does loop messages from their mailbox-client to unintended destinations. Especially you, Aaron.. (Well, *you* can react by doing filtering at linux-kernel, but that is an off-line discussion topic between you and me.)
Due to the "little" burst of "junk", and "reactions", VGER had a queue of several *thousand* messages to handle, and it took a while to process them -- even with me manually scrubbing several of the messages, and heaps of reactions... Now the queue is back to zero.
I bet you sent the nastygrams to linux-users@linux.or.jp, which list has NOTHING to do with this case (aside of being place where the messages were sent 4 months ago.) The little I know of Japanese culture, I do suggest you send an apology letter to those innocent addresses you likely have offended.
I do know the real culprit source address, but these reactions you people have shown, does suggest to me that I should not reveal it aside of very few selected people..
This was an amazing thread. Paul Sargent was trying to understand the address spaces used in various circumstances in the kernel. He went over his basic understanding and described what parts didn't make sense to him. A big pile of top developers dove on top of him with a lot of absolutely incredible explanations. I didn't know what they were talking about, but they were having fun!
At a certain point, under the Subject: Address
spaces on i386 - Some clarity is forming, Paul said, First of all thanks to those who have come
to my aid. It's now about 3 hours on from my initial cry for help and I
think I understand.
Whew!
Peter-Paul Witta asked about the possibility of a file server that would never go down, i.e. if one node died the others would immediately compensate. Some speculation followed from various folks, and Stephen C. Tweedie gave a pointer to the Global File System homepage.
Nuno Carvalho's PC-Bit card wouldn't work under kernels >=2.2.4; he tried a number of things, including the bleeding edge of the isdn4linux package. But Nuno Ferreira replied that this was an egcs problem (and he'd already posted to their list as well as linux-kernel about it), and would go away under gcc. An overjoyed Nuno Carvalho replied that installing gcc 2.7.2.3 solved the problem.
Kernel Traffic first discussed the egcs vs. gcc situation in
It will probably be a long time (if ever) before the last lingering egcs doubt is extinguished, but it's fascinating to watch it gradually happen.
Another ISDN problem came up this week. Mikko Hyvarinen found that between 2.2.5 and 2.2.5ac1 something broke ISDN syncPPP connections. He didn't get an answer on the list (though it might have gone to private mail), but in the course of the discussion it came out that the isdn4linux code in 2.2 kernels was old. David Woodhouse explained:
The ISDN code from the CVS tree contains support for more cards, support for compression, including LZS compression, and Telco approval for the HiSax driver on certain cards. And last time I compared them, the 2.2.x code would last about 30 seconds before crashing the machine, while the CVS code didn't crash.
Linus didn't want to accept the CVS code immediately before releasing 2.2.0, and the only thing that went in to 2.2.x was a patch containing the most important bug fixes.
Even the ISDN code in 2.0.37 is newer than the code in 2.2.x, and contains (IIRC) a some of the newer drivers, and the HiSax certification.
Alan Cox said, It needs people
to take a stable cut from the isdn cvs tree and integrate it back into the
tree. I've seen no evidence of the ISDN people doing that.
Paul Slootman replied:
Henner Eisen had taken it upon himself to feed the cvs version in (incremental but working) parts, as apparently Linus' biggest complaint was that he would never accept the large patch necessary for getting the 2.2.x isdn stuff up to the (stable) cvs version in one go (hence the parts).
He sent you (Alan) a patch for the link level in the first week of February, for inclusion in your 2.2.2ac series (at that time). It was basically the cvs link level with the TIMRU and BUDGET extensions taken out, as those aren't "clean" enough. I assume he's waiting to see that appear before he's able to send the next patch.
So, Alan, have you lost / rejected / ignored that patch? I'm curious as to the status...
The thread ended here, but presumably the latest ISDN code may start to be included in Alan's ac series, to the great jubilation of many.
Steven N. Hirsch found that exiting his newsreader when his home directory was NFS mounted would delete his .newsrc file! Trond Myklebust posted a small patch to linux/fs/nfs/dir.c and asked Steven to try it in conjunction with anything newer than 2.2.4ac1. A happy Steven replied that it worked like a charm.
End Of Thread (tm).
Jussi Hämäläinen had an interesting problem: his machine wouldn't boot without a monitor attached. Lilo would load the kernel and then hang until he plugged in the monitor. This didn't make any sense to him, so he posted to the list.
Meelis Roos and Neil Cherry confirmed they had experienced similar things.
Riley Williams suggested changing video cards, explaining, some PnP motherboards ask a PnP video
subsystem to check what type of monitor is connected as part of their PCI
initialisation, and some video cards hang when asked to do so if no monitor
is connected.
Richard B. Johnson posted a little code from syslogd which would segfault
under certain conditions. An irate Chris Wedgwood said, What the hell is this doing here? _You_ should know by now this
doesn't belong here,
to which Richard replied, Well it _does_ belong here because changes in the _kernel_
headers make the source generate bad code (without directly including kernel
headers, BTW).
He went on, so I
suggest that you quiet down a bit and appreciate the debugging that I did so
that utilities that work with the kernel can be updated to continue to
work.
Chris said, oops... I wasn't
paying attention and my brain was in auto-disengage mode.
Doug Ledford announced:
I've released the 5.1.14 version of the aic7xxx driver. This driver should fix the outstanding problems that I know of on all of the PCI class adaptec controllers. There may be some outstanding issues on EISA controllers. I will be verifying the EISA controllers later this week. There are several sections of code that underwent heavy modifications though. The most heavily modified is the device speed negotiation code. It's hoped that this code will be better than the previous code was, but it is in need of testing. Specifically, there are drives out there that will initiate negotiation with the controller isntead of waiting for the controller to start the negotiation process. That has traditionally been a spot of problems in the aic7xxx driver. If some of the people that have drives that initiate negotiation on their own could try out this code and report back to me, I would greatly appreciate it.
The update can be found at ftp://ftp.redhat.com/aic/5.1.14 and there are patches against a clean 2.0.36 or a clean 2.2.5 kernel.
Riley Williams' email was being blocked as an anti-spam measure by someone on linux-kernel, and he posted his feelings to the list as the only way to express them to that person. Matti Aarnio replied:
Yeah, that is a (misguided) case of "ban that domain because its used in so many spams.."
I have contemplated doing exactly that for AOL at VGER, but VGER does have a few lists where AOL users are in great abundance... Can't do it :-/
Oh yes, often when list-owners get that type of rejections, our reaction is simple: Remove the recipient which yields the rejection report. (in fact, remove any recipient which yields any rejection, including any recipient which yields delivery timeout...)
Sure that reaction may sound stupid to you at first, but consider that each of us must somehow process something like 200 to 2000 rejection reports every day thru all the year, and we do all that at our spare time.
Unfortunately we postmasters/list-owners don't have the luxury of time to educate people of the nyances of email systems; when to blame some system, and when *not* to blame. That last one can be a difficult question to answer without 5+ years of email systems and protocols experience...
So, if you folks want to filter incoming email against some source addresses carrying SPAM, be damn carefull that you don't filter too much. Letting *some* spam thru is way better than killing all your incoming email.
Filtering the email by delivering it to /dev/null is also better approach, than rejecting it at the input phase. Sure the byte- counters spin, but that isn't so bad as becoming removed because of over-eager pre-reception blocking based on false rules.
Meanwhile, Bob Lorenzini (from a netcom.com address) replied to Riley's
original post with, I
respectfully dissagree on this Riley. I realise you have been inconvienced
by this policy but think about the rest of us. You could help by refusing to
patronise a provider who caters to net abusers.
Riley replied in turn, I
was also 'inconvenienced', along with a lot of other people, when
microsoft.com blacklisted the .ac.uk 'domain' and thus denied access to
their site from every university in the UK. The problem with that is that
the .ac.uk 'domain' is NOT a single domain, but a super-domain like .net or
.org with many separate subdomains that are administered
separately...
Bruce Korb also replied to Bob, with, Um, so why are
you_ using netcom? Try posting to a distribution list on egcs.cygnus.com.
You cannot do it.
Bob replied, Well if
netcom is still relaying spam they should be cut off. I thought they had
stopped under threat of being shut off usenet. Their acceptable use policy
does not allow posting of spam and will terminate accounts upon
complaint.
Alan Cox announced his latest ac patch, and Gregoire Favre said it gave
linker errors with undefined references to rd_doload and rd_load_secondary.
Alan replied, Yep. My fault.
If you have floppy=y and ram disk=n it burps. I'll stick an ac6 up
shortly.
End Of Thread.
Martijn van Oosterhout had the interesting idea of using the i386 debug
registers to trap kernel stack overflows. He said, Obviously you'd have to block the ptrace GET/SETREGS,
and, Any process that is that deep
probably has a lot of locks. Just dying would probably kill everything
anyway. AFAIK the linux kernel has no machanism for undoing locks held by a
faulting process. If it did you'd be able to use the floppy drive after the
fat module had segfaulted on a bad floppy.
Alexander Viro replied, Yes, it's the common
problem with all kernel-mode faults. The problem being: you don't know *who*
had set the lock/spinlock/semaphore, increased the usage counter, etc. and
which resources were held by dying process. Any attempt to store this
information (i.e. do equivalent of destructors) will have a nasty
side-effect - we'll slow down a lot of stuff on nearly every time-critical
path ;-/ So the current behaviour is least of two evils - after all, it
doesn't punish correct code.
This was enough for Martijn. He said, You are right. It could be done by attaching the locks as a
linked list to the current process, which would allow you to track them all
down, but it would penelize all the times where nothing goes wrong. After
all, it won't be needed when the kernel is bug free :)