In comp.os.linux.advocacy, [H]omer
<spam@xxxxxxx>
wrote
on Thu, 20 Sep 2007 23:57:54 +0100
<igabs4-3jn.ln1@xxxxxxxxxx>:
> Verily I say unto thee, that Roy Schestowitz spake thusly:
>
>> <snip garbage>
>>
>> Keep your paid-for Microsoft PR tosh out of Digg and USENET.
>
> His arguments are old, unsubstantiated FUD.
>
>
> "Linux needs 'big name' commercial apps"
>
> Part of the reason I no longer use Windows, is because the so-called
> "big name apps" are grossly overpriced, overhyped, Crapware. There is
> nothing of any significance that I could do with "big name apps" on
> Windows that I can't do on GNU/Linux. This misguided "need" for such
> apps is nothing more than bullshit indoctrination, which easily
> influences the archetypal feeble-minded Windows users.
>
It's going to be a long process to filter out the big
name commercial apps which are any good from the big
name commercial apps which are pure crap -- but one name
(Microsoft) will probably be filtered out rather early. ;-)
>
> "Advocates inhibit adoption"
>
> GNU/Linux advocates (here and elsewhere) are one of the main sources of
> marketing for Free Software (non-commercial software typically doesn't
> advertise through standard channels). Every voice praising GNU/Linux is
> a thorn in Microsoft's side, so it isn't very surprising that their
> Shills should denounce them. The idea that a /supporter/ can inhibit
> adoption is pure unqualified bullshit.
>
Depends on the context. I think the Wintrools are of
the opinion that overarrogance on our part might turn off
prospective adoptees. There might be some truth to this
here in COLA, but really, COLA isn't for the total n00bs
anyway (despite the occasional one who wanders in here
asking interesting if misdirected questions).
>
> "Linux doesn't pay"
>
> Yeah, right. Take a look at the job market. It's overflowing with demand
> for *nix professionals.
>
Well, on a technical front Linux doesn't pay, but that's
on a technical front (only managers pay :-) ). But yeah,
for those who know Linux, they can probably command quite
a bit in the job market.
>
> "Windows just works"
>
> More utter bullshit. For every error (serious or otherwise) that I've
> ever encountered under GNU/Linux, I've witnessed hundreds under Windows
> - it's an utter disaster of an OS. I also have had considerably more
> problems /installing/ Windows than I ever had installing GNU/Linux,
> especially WRT SCSI/RAID/SATA disk controllers (please insert disk into
> non-existent floppy drive, anyone?).
Windows has a fair number of fundamental flaws. Working
may be in the eye of the beholder, and in any event these
flaws preclude some actions which could otherwise be
allowed in Windows.
- File naming. Part of this is DOS's fault, but Windows
has done some interesting botches here. Briefly put,
Unix went the uniform route: every absolute pathname shalt
start with '/', and that's it; if one wants to add
additional storage, the kernel recognized a 'mount',
which associated one pathname with the root of another disk.
'..' is also fairly uniform in Unix, and reasonably easy to parse.
Later on, hard links and symbolic links were added.
In DOS, one gets single letter codes, which have never
been fixed (the Amiga at least had volume names, as did
the Mac before it, so one wonders why); pathnames such
as C:\WINDOWS are routinely seen even today. Too bad
if one has more than about 23 locations one wants to
play with. To be fair, Win2k did try to fix some of this
with the Logical Volume Manager, and NTFS5 -- finally --
has something resembling symlinks instead of .LNK files
interpreted by IE.
But that's not so bad compared to the screwing up
of shares. In a way, one is reminded of Apollo DOMAIN
systems: \\name\share is easy -- until one tries to CD
to it in a COMMAND.COM/CMD.EXE shell. Botch!
Did I mention Unix automounters yet?
- FCBs. No doubt part of Windows' headaches is because
MS-DOS 1.x used FCBs everywhere. I'm not sure how
big a part, but one suspects no one ever got around
to touching the CD builtin within COMMAND.COM or even
CMD.EXE, at least before Vista. For its part Unix uses
abstract tiny integers -- file descriptors -- and has
never seen fit to change them, though it's encapsulated
them at least twice (FILE * and std::[io]stream).
Therefore most ancient Unix code has a fighting chance
of working!
- File locking. Linux went the cheap route, as did Unix
before it: lock it quick, unlock it quicker. The inode
system allows for a user to create a file, drop it in,
and make use of it immediately during installation;
simple, and reasonably efficient (if one can overlook
the extra layer of indirection with the inode involved;
most don't care). Windows is good-intentioned; they
implemented the idea that "thou shalt not attempt to
modify an opened file" -- and botched it. Now installers
have to do some nasty tricks to get their changes in,
and one false move by the system integrator and things
get....interesting. Good intentions, horrible execution.
- Email handling. Strictly speaking, this is an Outlook
problem, but basically it's far too easy to do a
single-click on a script and execute it. The user may
not even be aware that it's a script!
- The registry. Presumably another good intention, to
unify the .INI file mess, but the registry was not
partitioned properly (in Linux, it's not partitioned
quite properly either, but at least in Linux it evolved
into a split system where configuration files handle
the slow-changing issues, and in-memory stuff or hidden
temporary files handle the run-time ones.) Lose the
registry, one loses the runtime work areas (no big loss)
and the settings (great big huge dangerous crazy loss).
In Linux, deleting /var/run/* will cause some headaches,
but those can be fixed by simply rebooting, or restarting
services. Deleting things in /etc/ is very problematic,
but that's why they're in /etc/.
- Autoextending swapfiles. Another idea gone badly awry.
In Linux, it's hard to extend a swapfile -- not sure how
deliberate it is, but the flip side means that swapfiles
are at least somewhat contiguous, and stay that way.
(The proper way to do it is even harder, namely, use
a swap partition.) If one needs extra swap space, one
can of course add another swapfile at need, but it's a
little harder (deliberately? just happened that way?
we were thinking?) than Windows' extensible swapfile,
which is switched on *by default*. Locking it down,
in fact, might keep the system from being affected by
the dreaded "bit rot", and one has to wonder why Windows
was designed to fail.
- The Windows\System32 pile. This is probably just
historical crappiness, but for awhile programs would
simply dump their DLLs and what not into this directory.
I'm not sure that this has been properly fixed even now.
I'm also not sure Linux is all that much better, but
at least Unix before it separated /usr/bin, /usr/lib,
and /etc, with /usr/lib being a bit of a catch-all for
all of the non-program, non-config stuff, which for
most programs/utilities turns out to be very small.
Also, PATH in Linux is far more usable than PATH in
Windows (which at one point had a 128-char limitation!),
though Windows does try. Unix and Linux also implement
chroot(), which might help to keep programs in check,
though it's very limiting (by design).
- X versus Win32. I'm frankly not sure how equal these
are, but it's clear that at a low level X is more
solidly designed. Perhaps it's because X's developers
long ago thought about the then-unrealized need for
remoteability, and decided that X should have it.
Perhaps it's simply because they were from MIT, not
from a commercial enterprise, and therefore were under
professors who could critique their work in what was
then an open-source fashion. Perhaps it's dumb luck.
Nevertheless, X, while a year later than Windows, is
far less subject to the casual virus. Fortunately for
Windows, there are easier venues such as email to infect
systems -- unfortunately for the owners thereof.
- bash vs. CMD.EXE/COMMAND.COM . I'm not entirely sure
why COMMAND.COM ended up so braindead, but it's clear
that its substitution facilities are far more limited:
for starters, no equivalent to the backtick or the here
document. COMMAND.COM did implement a pipe facility,
by using temporary files (.$$$), but it's not quite
the same. Possibly part of this is the inherent
monotasking of DOS, crippling the command processor.
Windows did later on implement VBScript and JScript,
and now is offering PowerShell, plus they got around
to implementing command history (DOSKEY equivalent) --
a little too late, though.
- File names. For some reason, SHELL.EXE and/or
IEXPLORE.EXE are far too trusting, simply assuming that
the extension of the file name is sufficient to identify
its format. This may be an artifact of old linkers,
which generated files ending in .EXE. Early Unix linkers
default to 'a.out', a convention that is still with us
today; a '.out' file, however, means 'output' to most
people, and presumably executables quickly get renamed to
something more meaningful (or one used -o something).
Somewhere along the line in UnixLand, the .exe got
dropped -- if it ever was even used; Unix long ago had
a limitation of 14 characters in its filenames, which
may mean .exe was dropped out of necessity. Then again,
DOS had 8.3, which lead to some rather creative naming
strategies...so I don't know.
- DLL caching. For awhile, Win3.1 or maybe Win95 had the
rather awful idea (in retrospect, admittedly) of caching
DLLs at the loader level. (For its part Linux caches them
at the file/page level -- which can easily be done by
tracking inodes.) I would hope XP has abandoned this
idea, and in any event the locking foulups may have
masked it, but at one point one could have two versions
of a file named e.g. 'MYDLL.DLL' or some such, and the
OS would get very confused. This apparently led to a
"MSVB32.DLL" type naming convention, which didn't help.
- IE. Granted, I'm a little fuzzy on all the things IE
can do, but anyone who's looked at the IE4 installation
kit (which replaced a fair number of system files) has
to wonder. Even today IE7 still doesn't get things quite
right, though it's a bit better than IE6. Innovations
that would be relatively simple in Mozilla, especially
using SVG, get bogged down in IE's technical details.
And then there's IE's sandboxing for ActiveX controls.
Briefly put, I'm not sure there is any.
- Multiuser protections. Unix started out as an inherently
multiuser system, and got permissions sorted
out relatively early. While not perfect,
the user/group/other system is now traditional.
Windows started out on top of DOS, which had no idea of
permissions beyond HIDDEN, SYSTEM, and READONLY flags,
and this may have stunted its growth. NT tried to do
something with ACLS, but the XP merger probably had to
compromise for expediency. In any event, protections
in NT are now reasonably good but still show the usual
Windows complicatedness.
(Gad, that got long quick, didn't it? :-) )
>
>
> The entire article is just one of those "Big Lie" posts, based on the
> principle that if you keep repeating the same old bullshit often enough,
> then eventually the feeble-minded readers will start to believe you.
>
Gotta sell those surplus Vista boxes somehow...
--
#191, ewill3@xxxxxxxxxxxxx
/dev/signature: Not a text file
--
Posted via a free Usenet account from http://www.teranews.com
|
|
