rick at linuxmafia.com
Sun Dec 10 22:40:51 PST 2000
begin Mark Handley quotation:
> I agree the security difference is small. But the userspace daemons
> are not identical - for example the recent statd vulnerability
> is specific to Linux:
Does not seem to demonstrate what you claim. This appears to be a case
of a *ix-standard standard RPC daemon, which I would guess to be common
to various Unixes, happening to pass dangerous information to syslog
daemons. Systems with the right sort of syslog weakness are thus
affected. (This is based on a quick reading, so I might have missed
We could waste a lot of time studying case-citations. The userspace
daemons are largely if not entirely identical for an obvious reason:
economy of effort. The CVS-committers of various *ix codebases may get
slightly ahead of one another on bugfixes of upstream packages,
particularly security-sensitive ones, but those get reflected upstream
because that is obviously in everyone's interest.
> But I think that the popularity of Linux with crackers (as an
> operating system they're familiar with) does have an effect.
As I said, competent system administration makes the effect nugatory.
I administer FreeBSD, and NetBSD, and Linux: The way one keeps each of
them relatively secure is basically the same, of necessity.
> Agreed. If security is your top concern above all others, then
> OpenBSD is definitely the one for you. However, FreeBSD also has had
> a large code audit that's still underway, and also often benefits from
> it's kinship with OpenBSD.
Yes, yes. And there are numerous important kernel-space codebases
maintained in common between the BSDs and Linux, such as the AIC-7xxx
and some of the NCR/Symbios SCSI drivers.
> FreeBSD is better if you want support for a particular piece of
Yes, yes. And NetBSD is better if you want ports to every conceivable
chip architecture. We know all that.
You may not be aware that I was called in as a guest at a BAFUG meeting,
earlier this year, to help them do a BSD - Linux comparison. I _wanted_
to argue the pro-BSD position for a change, but they needed a Linux guy.
So, I settled for wearing the Chuck the Daemon shirt I bought from Kirk
McKusick and trying to be as informative and dispassionate as possible.
> Agreed, but that wasn't my point. There's more heterogeneity in
> Linux, and this leads to faster development at the occasional expense
> of rock-solid reliability. Witness all the recent argument over
> Redhat 7 shipping with an experimental compiler.
But that's really a change of subject: Some crazy vendor's mutant
non-gcc compiler should not be confused with Linux. (Don't let me get
started on my Red Hat 7 rant.)
> Linux userspace truely is a bazaar - this has both its good points and
> its bad points.
But that gets back to my point about the requirements of competent
system administration on _any_ Unix. E.g., if someone held a gun to my
head and made me install Red Hat 7, practically the first thing I would
do would be to replace _both_ of the provided versions of gcc with a
decent one. And I do think that practically all Linux distributions
need a great deal more paranoia. For example, wu-ftp? No thanks. It
gets ripped out and replaced with something less porous, on anything I
> Again this isn't completely true. For example Linux 2.4...
...is still pre-release. Like, for example, FreeBSD-current.
It might be interesting to examine the Linux beta kernel 2.4.x's coding
practices -- even before it's production code. But we should be clear
on what it is, and not compare things that are in fundamentally
different categories. However:
> But the very rate of change of Linux does make it harder to be really
> really stable.
_That_, you realise, is not an assessment of code quality. It's kind of
an abstract hand-wave. Reality is a bit more complex and varied.
> Actually you missed my point. Soft updates, good though they are, are
> not a true journalling filesystem.
And I didn't think they were. But, yes, it seems I did somewhat miss
your point, as follows:
> I was saying that once a true journalling filesystem is in Linux, and
> once it's really solid, then for applications that really want such a
> function, Linux will have a definite advantage because there's no true
> journalling filesystem for FreeBSD.
The _usual_ reason why the issue of journaling FSes for Linux gets
raised is to assert that it's required for metadata consistency, on
grounds of ext2's alleged excessively risky treatment of writes.
So, that's what I thought you were driving at. My apologies for missing
your point. (I've been on the fringes of too many OS-advocacy debates.)
But, since you mention it, the BSD community can, if it wishes, benefit
from Linux journaling-FS work. The authors might be willing to
dual-license, as many other driver authors do, or BSD coders can study
the exposed interfaces and code to write their own implementations. In
particular, since the BSD ext2 code is already excellent, adding some
version of Stephen Tweedie's (?) ext3 extensions shouldn't be difficult.
The ReiserFS might be closer to production quality, but Linux sysadmins
have come to be wary of it because of Hans Reiser's habit of changing
the structures at the drop of a hat. IBM's JFS is really good, but the
porting effort from AIX and OS/2 has barely begun.
> I just happen to believe that properly configured, FreeBSD has a
> fractional edge for the task he's trying to solve.
I might agree. I have a very healthy respect for FreeBSD's performance
under load, in particular (e.g., at wcarchive.cdrom.com) -- and its SCSI
subsystem performance (where I figure the advantage must lie somewhere
in the layers above the SCSI drivers).
> But Linux is a little better supported than FreeBSD for some
> tasks/hardware, and so this may tip the decision in favour of Linux.
I happen to be a big fan of FreeBSD's Linux emulation, which is often
faster than native. ;->
> I think mostly we're in agreement.
Yep. Consider a case of virtual beer shipped to you. ;->
Cheers, "Reality is not optional."
Rick Moen -- Thomas Sowell
rick at linuxmafia.com
More information about the buug