Thanks go to Tom Davey and John Brajkovic for finding some typos in last week's issue. Many thanks, folks!
Daniel Ginsberg disagreed with my stance last week in
Dunno about your take on Linda Walsh's posts regarding CAPP conformance. This, in particular, strikes me as unwarranted:
"I suspect that she puts more weight on its status as an "official" standard than other folks on the list, who are concerned primarily with its technical merits."
There really do seem to be two threads to her position. First, that linux will be defacto ruled out as an option by one of its largest possible (and interested) adopters failing certification. But, also, that even given the very real limitations of CAPP, it is a tremendously useful and important part of the security arsenal. Seems to me that on this second point many of LW's detractors have voiced a magic-bullet take on security ("if it won't do all, then why bother"), and she has gone to great lengths to position CAPP correctly in the overall scheme of security, freely granting what CAPP fails to do, but showing the cases in which it would be useful and would contribute significantly to security. Which is to say that I think that she has voiced a pretty honest understanding of the technical merits of CAPP.
Might just be me, but you might want to cruise that thread again.
Daniel, you make a good point. This is the kind of criticism I'd like to see more of from KT readers. It helps expose the real issues underlying the discussion. Thanks for sending it in!
I agree that Linda Walsh is not blindly pushing CAPP just because it's an "official" standard. I didn't mean to give that impression. She obviously cares about the technical aspects, and is not trying to claim that CAPP does everything. On the other hand, I don't think we can say that the folks disagreeing with her are simply looking for some impossible "magic bullet" security solution. Many of them are also qualified, and have legitimate objections. The question of whether it's worth conforming to CAPP is still open.
At the same time, I was trying to draw attention to the fact that at least part of Linda's argument in favor of CAPP is that it's a US government security standard, and would go a long way towards getting Linux accepted in security-conscious environments. Many developers, on the other hand, seem to believe that no matter how much a given feature would help get Linux accepted in a particular environment, that feature should be implemented or not, based solely on its technical merits. These people seem to say that any discussion of CAPP's 'political' value is superfluous, and should be completely ignored.
The quote you took from last week's article, was simply my pointing out that Linda was making such a political case as part of her argument, and that not everyone would like that.
Alan Cox gave a link and announced:
I've had a pile of old stuff from 1993->1995 that escaped due to freak chance and non reuse of an old disk. I've now rescued the data and finally had time to strip the original Linux lists out of it. I dont have 1991/1992 alas but hopefully someone else does. Ted used to have them on tsx-11 I believe /
Anyway if you want to know what DaveM's first post looked like, read the very first Linux code freeze announcement or just wondered what a 5 mail a day kernel list was like..
Theodore Y. Ts'o added:
I have archives from 1991-1994 at:
ftp://tsx-11.mit.edu/pub/linux/mail-archive
Any budding historian/archivist want to try to merge the two archives together? :-)
Chris Wedgwood replied:
Since I have my own archives for the last few years (nowhere as extensive as others out there) I have a script to do just such a thing.
I'll snarf down all the archives next week I can get and run it -- it should weed out any duplicates. I might make it a little smarter to record things like origin (which archive source it came from) and also to detect broken messages caused by the horrible unix mailbox format getting truncated in the wrong places.
Something that has occurred to me, some of my archives I deleted the spam from, so they are probably not what you would call 'pristine' condition. I also have a couple of holes 30 messages or so wide form the last couple of years because I've done dumb things like remove and old libc without recompiling my local delivery agent. Doh.
At some point, Michal Jaegermann said:
I found two old CDs which contents is partially Linux. :-)
In particular they contain what seems like a complete archive of linux-activists list starting from November 1991 up to digest 988, Volume #4 from "Wed, 28 Apr 93".
In an off-list email exchange (and many thanks for the quick replies!), Michal also told me:
all this stuff (i.e. everything Linux which was on these two CDs I mentioned) is still available from
ftp://ftp.harddata.com/pub/Linux-history/
But both Andries and Alan have linux-activists archives which go for at least two volumes more than what I found. Some of library sources were missing from Andries collection. :-)
In a later email to me, he added, the stuff
on ftp.harddata.com
will be not permanently there, a bandwidth to the site is rather limited, it
appears that there is not that much in this collection which was not
available somewhere else already (some bits and pieces are "new", or rather
"sufficiently old" :-) and more complete linux-archivists archives do exist
elsewhere.
George Anzinger needed to run Linux on a multiprocessor MIPS machine, but
Alan Cox replied discouragingly, The MIPS tree was
never merged for 2.2.x as the changes needed to do all of it never got
totally approved/agreed etc.
In the course of discussion, Stephen C. Tweedie said, we are working on async raw I/O APIs --- that way you can submit
multiple writes at once, allowing the driver to coalesce them and pipeline
them, while maintaining all of the cache and synchronisation guarantees of
raw I/O.
Dan Kegel strummed a happy chord, and asked if the API
would be the standard aio_write() function, and Stephen replied, No, it's far, *far* more powerful than aio_write.
The normal posix aio functions like aio_write will be achievable through it,
but it will support a lot more (such as things like allowing arbitrary copy
of data without it ever having to reach user space at all).
And Jeff
V. Merkey sung out, Bless you Stephen! Let me
know when this interface will put rolled into the flat area for 2.4 so I can
switch over and start using it. Killer -- a real AIO layer in Linux.
Peripheral to the CAPP Debate covered in
Some people expressed uncertainty about the value of 'paper' certifications that provide no increase in the security of the product in the real world.
I read an article (http://www.fcw.com/fcw/articles/2000/0508/web-fips-05-11-00.asp) that talked about a "smart card" that was the first to be certified to a particular standard (FIPS 140-1). Having the features of the card vs. being certified is worth an estimated $1 billion dollar contract to this company. These Smart Cards could be used, as I understand them, as the "authenticate user" part of the CAPP or LSPP requirements.
I dunno about anyone else...but that's the type of marketshare and money that gets my attention. Having Linux compete in the billion $$ contract space is...well, somewhat "seductive" (not that I'm at all affected by base considerations of such a sum of money, of course, purely from a marketshare POV :-) ). Having that type of money trickle into the Linux space seems like a good thing for all Linux developers (higher demand for services, engineers, Linux software, etc). Tres cool!
Later, she continued:
a product can have the functionality and no cert or the product can meet an insufficiently stringent cert. In either case, the quality of the card may be orthogonal (depends on certification requirements) to the certification. The point here was that the certification itself, not the features, are worth 1 billion. If that was a cert of Linux Based product, for example, say of some particular Red Hat distribution on a VALinux Box with support provided by Linuxcare, and an optional office suite provided by Corel that would mean large amounts of revenues into those companies or those company's Linux operations.
Now other companies may take Linux more seriously and put similar configurations into use in their own infrastructure. Other companies are going to want specific add-ons. The companies who got direct income would likely need more Linux people -> more demand for Linux expertise (Linux Certified Engineers? -- injection of money into LSB?). The point is that a given product (like the smart card company, or Linux companies) meeting a cert send capital into the sector. Even competing smart card vendors are likely to step up their efforts to also get certified -- just as more Linux systems vendors and distro companies would be stepping up efforts to get their respective products on the certified list -> again, more demand for all things Linux. More 'well known' Linux contributors find that demand for their project yields them equipment dumped on their doorstep to bring their product up to release (from beta) quality.
All of this stimulates the Linux 'economy'.
Obviously our goal should be two-fold. A) ensure Linux survival and profitability in the marketplace and B) ensure it is the best there is. Meeting the goals of "A" allow further work on the things we are (I am) interested in long term, which is "B". Doing "A" may not be important for any single one of us, but the fact that it is important enough to pay large some of money for means it is important to someone. Doing "A" *can* allow many of us to work on "B". Hopefully we can finagle many of the "1" goals to contain "2", and for those "2" that don't fall directly into "1"...well who needs nights and weekends anyway? ;-)
When I first got out of school, I was so much the perfectionist / idealist. Now I realize that pragmatism is also useful as it allows expression of my 'art' (yes, I feel for some of us computer science is an 'art' that allows us to express our creativity).
Bernd Eckenfels objected:
Certification will kill the development, once certified this means u have to freze, or get the money for the expensive certifications over and over again... this will force the free software into the commercial hands of companies like SGI.
Don't get me wrong, i personally find it very cool what SGI or IBM is doing for Linux... but I dont want them to gain power on the OS (as SuSE, RedHat or so on).
Alexander S A Kjeldaas and Alan Cox disagreed that certification was
necessarily a bad thing. Alan put it, Certification
means SGI and others have to go certify specific versions. THe rest of
us will carry on regardless, its their problem. As it stands now Red Hat
typically put out 1 or 2 kernels per release so change them very slowly.
That doesnt impact Linus's ability to put out 3 a week.
And David
Woodhouse added, The certification for ISDN
seems to work quite nicely. I don't know exactly what the arrangements
are.
To which Bernd qualified, it is
only for a hand full of cards, only or selected Revisions of the active
cards bios and affects only the isdn subsystem... security cewrtification
on the other side affect the whole kernel and a lot of user mode.
Gregory Zornetzer asked if Alan Cox would include Doug Ledford's latest
aic7xxx driver in the 2.2.16pre series, and gave a link to the
patch, but Alan replied simply, Doug's stuff goes
in when he asks.
That was it.
A similar discussion was covered a couple weeks ago, in
Reports of this problem were first covered in
This week, Matthew Vanecek complained that although plenty of folks were
talking about how 'kswapd' was broken, he couldn't find any patches to fix
it. He asked if a fix was available, and Rik van Riel replied, People on the linux-mm mailing list are fixing things as
we speak... http://www.linux.eu.org/Linux-MM/
Elsewhere, under the Subject: PATCH: Possible solution to VM problems, Juan J. Quintela posted a few iterations of a patch to improve the poor performance of recent development kernels, in particular the problem with 'kswapd' using up 100% of the CPU. Eventually, Rik van Riel replied:
I am now testing the patch on my small test machine and must say that things look just *great*. I can start up a gimp while bonnie is running without having much impact on the speed of either.
Interactive performance is nice and stability seems to be great as well.
I'll test it on my 512MB test machine as well and will have more test results tomorrow. This patch is most likely good enough to include in the kernel this night ;)
(and even if it isn't, it's a hell of a lot better than anything we had before)
End of thread.
Adam Fritzler bought a VAIO PCG-F450, but (among other things) he asked,
Is anyone working on an OSS driver for the
YMF744? ALSA says "mid-May" but thats about it. They have the docs from
yamaha on their site as well.
Joel Jaeggli replied, the commercial oss driver (4-front tech) supports it, and they've
fixed their "apm calls with the sound driver loaded cause the machine to
hang" bug.
But Adam didn't want to bother trying to run binary
drivers on development kernels. He had no problem running binary user-space
software, but binary drivers, no. He said he'd rather write his own Open
Source driver instead. Joel replied, I actually
agree with you there. I just tested the oss because I was setting up a
laptop (z-505hs)for someone else. the apm bug was really a show stopper in
terms of making the laptop useful and of course cements your and my position
of binary only drivers
Rick van Rein's original BadRAM announcement was covered in
Lawrence Manning reported that 2.3.99pre9-3 had terrible interactive performance, as compared to pre9-2. Linus Torvalds explained:
What happened was really that I did a partial integration just to make it easier to synchronize. I wanted to basically have pre9-2 + quintela's patch, but I had too many emails to go through and too many changes of my own in this area, so I made pre9-3 available so that others could help me synchronize.
So don't despair, pre9-3 is definitely just a temporary mix of patches, and is lacking the balancing that Quintela did.
Juan J. Quintela gave his status, which did not look good:
I am working in introducing my balancing changes in pre9-3, but I am having problems with it. Now my machines get deadlocked and I get a lot of Oopses. I am investigating on that. I get Oops indeed in the pre9-3 vanilla kernel. I am studying it to write a report of the situation.
My SMP machine is new, It has passed 6 hours of memtest86 memory checker, but I don't know what to blame at the moment. I am compiling for my old UP machines to test the differences.
No reply.