On 27 Apr 1999, Nolan Darilek wrote:
> o Too many things in the kernel that belong in user space (java)
>
> I don't necessarily think this is a bad thing in java's case. Plus,
> since these can all be built as modules, I don't see why it matters
> that much. Would anyone else care to comment?
Java is not in the kernel. SUPPORT for launching the java VM when you try
to exec() a java application was put in, but that's tiny. It's also been
superceded by MISC support, which allows this kind of functionality for
any kind of file format. (a la /etc/magic)
> o svr4? bsd? make up your mind?
Linux supports SVR4 and BSD semantics to make programs easier to port. I
don't see how this is a bad thing!
> o New kernel every week that breaks half your applications
>
> Huh? Maybe if you're running unstable, but damn, that's why they're
> classified as unstable kernels, not for production use. :)
Exactly.
> o Security flaw/Root compromise of the week (see below)
This occurs with FreeBSD too.. This is the belief perseverance phenomenon
of memory, right out of my psych book.
> o glibc? libc? libc5? libc6? glibc2?
>
> Hmm, why bother with the details if you don't have to? Why not let the
> distribution handle that if you're unwilling?
Indeed. Those who don't run glibc2/libc6 (which are the same think,
afaik), are just asking for problems now. 90% of linux users use libc6 and
are quite happy.
> o /bin/sh != sh; /bin/sh == bash. Lame. Nonstandard. Result: broken shell
> scripts and nonportable code.
>
> I'll grant him this point, my /bin/sh does link to bash. I don't think
> I've ever had a shell script fail on me because of this,
> though. Non-issue?
bash has 100% compatability old sh when invoked as 'sh'. This is just
wrong.
> o /usr/bin/make != make; /usr/bin/make == gmake. Lame. Nonstandard. Same
> result as above: nonportable code.
This is wrong too. gmake has 100% compatability with old make, with the
exception of one or two features no-one used. And almost everything *I*
see now _requires_ gmake, especially if it's autoconf based.
> o ext2fs
ext2fs is great. This guy is talking out of his hat. He doesn't even try
to compare it, as if just mentioning it on its own was "'nuff said"
> o e2fsck deliberatly leaves/creates corrupt files (if there is a block that
> it duplicate between two files, e2fsck will clone the duplicate (while
> fsck will remove both files))
This is a GOOD thing! fsck removes both files, even though one (or both)
of them may be salvageable! e2fsck duplicates the block, and tells you to
go look at them. I'm sorry, this guy has no idea what he's talking about.
If corruption like cross-linked files occurs, user intervention is
*mandatory*.
> o it swap likes swap to swap swap too swap often swap
Plain bullshit. It rarely ever swaps on me unless I screw up and run an
app that tries to use >90MB of memory or something.
> o only allows 128M of swap at a time; for a 1G of swap, you need 8 swap
> partitions
Not anymore. This problem was fixed in 2.2.x. Most people don't need more
than 128MB of swap anyway, since swap is so slow.
> o To install Joe's program, you need Bob's kernel hack, but for Bob's
> kernel hack, you've got to have Suzy's patches, but Suzy's patches only
> work with a year-old kernel, unless you get Mike's patches to Suzy's
> patches, but even then, those conflict with Jeff's drivers, which can be
> resolved only by installing Nancy's patches...
>
> Has anyone experienced this? My only experience with this was with the
> e2compr patches I applied, but I think the author is exaggerating a
> tiny bit.
Grossly exaggerated. This rarely happens unless you're dealing with
fringe patches, which are rare now with 2.2.x.
>
> o Can't handle the same IP on more than one interface
More BS. This guy needs to update his page for 2.2.x. IP aliasing is
supported now.
> o Can't handle large files
>
> I'd like to reiterate my above point, that the author's arguments
> consist primarily of one-liners. In this case, the author fails to
> define 'large files'. Sorry if I seem like a clintonist, but I can't
> stand incomplete and unsupported arguments. :)
Large files = >2GB files. This is supported too, although I can't remember
where. It may require patches to the kernel, but if so then they're
definitely available. Most people don't have files that large anyway.
> o lilo! any boot loader that needs to have magic block numbers is wrong
I'll give him this one. LILO has problems. Try GRUB instead... it actually
understands enough of the filesystem to find the kernel itself.
> o linux icmp.h is *NOT* unix icmp.h - they're totally incompatible.
Say WHAT? I never saw this.
>
> o flatfile password files make listing large ftp directories impossible due
> to huge numbers of flatfile searchces.
Not true. glibc2 caches password lookups, and I think there's a way to use
password databases (gdbm, I think) to fix it. Most people don't enough
users to make this a problem.
> The author's apparent approval of the Mindcraft study, which ESR found
> had (6?) fatal flaws, also supports my suspitions that some of the
> points which I don't understand could be misinformed. I encourage all
> of you to correct any errors in judgment which I've made, since I'd
> realy like to know if I'm wrong.
You're right. This guy obviously doesn't know what he's talking about.
There _ARE_ problems with Linux, but none of these qualify (with the
possible exception of the LILO remark).
> DISCLAIMER: The above ramblings are not intended to knock FreeBSD,
> NetBSD, OpenBSD or any of its dirivatives. I have great respect for
> anyone who produces free software, and I don't believe in attacking
> them for their efforts. I'm merely concerned about the lack of
> accuracy and supporting evidence for many of these claims. Yes, it is
> good to evaluate what you do before doing it, but it is also important
> that you consider all information thoroughly before forming
> conclusions.
Same disclaimer here.
Taral
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
