first off, i am an evangelist, as opposed to taral =).
but i feel it's us against them and i include freebsd in the us of free unix.
i don't advocate irix or solaris x86 over NT, i advocate free unix.
altho i'd probably prefer solaris x86 to any kind of windows...
but basically, i have no problem with people using what works for them...
if linux isn't working for you, try something else. if you're trying to
live up to someone else's hype, you have other problems you should deal
with first =)
> 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 isn't in the kernel. an extensible binary loader is in the kernel--
i don't know the full details of this, but basically you can (on a running
kernel) echo some bits including an exe's magic number to a file in /proc
and all of a sudden you can run (say) .exe files...(using dosemu as the
binary loader).
java was put in to be buzzword compliant, specifically, linus admitted
at some point. if you don't like the 4k of kernel overhead therein
attached, don't compile it in. use the generic binary-loader functionality
instead =) (it has the a superset of the java binary loading capability)
> o svr4? bsd? make up your mind?
personally i like the mixture. it's like aix and to a lesser extent
solaris...ps auxw and ps -ef both work (well not with redhat's default
ps...). if he has a problem with this, it's a matter of opinion to
which he is entitled. hardly worth a bitch tho
> o Lame NFS & dd
nfs has improved approximately ten-fold with the 2.2 kernels.
> o /bin/sh != sh; /bin/sh == bash. Lame. Nonstandard. Result: broken shell
> scripts and nonportable code.
you can start bash up in posix compatibility mode. (bash --posix even).
where's the beef?
> o /usr/bin/make != make; /usr/bin/make == gmake. Lame. Nonstandard. Same
> result as above: nonportable code.
>
>Um, no it isn't symlinked to /usr/bin/gmake. And, I don't think I've
>ever had compatibility problems. Doesn't BSD use a different make? If
>so, I don't think I've ever seen any programs which use it. Should I
>be bold and declare that BSD make is nonstandard? Hmm . . . No, I
>don't know enough about the situation to instantly brand programs as
>non-standard, and I'll admit that I may very well be wrong in my
>assertians. They're based on several years of downloading and
>compiling GNU software, as well as source which was built to compile
>on multiple unix variants. How can the make I'm using be non-standard
>if I haven't had any problems with it?
gnu make is generally more featureful than system makes on most commercial
unices. it is incompatible in some details with bsd make. whose fault is
that? dunnao.
> o ext2fs
> o can't handle partitions > 2GB
old news, misquoted. files larger than 2Gb weren't in the past supported
on x86/linux. if theyre not now, they will be RSN.
they've just about always been supported on 64bit capable platforms.
> o it swap likes swap to swap swap too swap often swap
>
>It likes to swap too often. ? I haven't noticed this, if so. At least,
>it hasn't caused any adverse effects on my system.
MM is different in every OS out there. c'est la vie.
> o only allows 128M of swap at a time; for a 1G of swap, you need 8 swap
> partitions
>
>No clue, anyone want to comment? Wondering why you'd want 1 gig of
>swap anyway, unless you've got gigs of RAM and need lots of memory.
i've got 1G of swap on a few machines. folks who are lazy programmers
(including myself) will allocate all the memory they need, load their
entire problem set into it, and then proceed to work on pieces of it.
so, it could be done so as not to soak up swap, at the cost of increased
programmer effort (load the thing in a chunk at a time).
at any rate, this is old news. linux now supports swapfiles/partitions
of >1G in size.
> 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. :)
(see above. linux does handle large files, altho possibly not in the
std kernel as yet for x86. there is a working implementation of this
functionality tho, as of 2 months ago)
just my $.02. i don't know *bsd well enough to say where it kicks linux'
ass at anything anymore...used to be no question that freebsd's network
layer was speedier than linux'--so we improved ours =)
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
