This puzzled me
STD DIALUP
: Depends on the god being defined. The gods of Norse and Indian mythology
: have all kinds of picadillos. Even a quick reading of the OT will
: confirm that the god of the Bible is pretty damn far from perfect.
A quick install of windoze NT will confirm that microsoft is also far
from perfect.
Jerry O'Quinn
"STD DIALUP" <disk...@shell2.fdn.com> wrote in message
news:wI_q5.693$bf....@news1.fdn.com...
ec...@primrose.csv.warwick.ac.uk
: Or a quick install of Linux! ;)
:
Yeah! But your idea of perfect is something with 63000 bugs, crashes
constantly needs a minimum PIII and 128 Meg Ram to run as a Linux with
P100 and 32 Megs of Ram.
Keith T. Williams
<ec...@primrose.csv.warwick.ac.uk> wrote in message
news:8old95$ibo$1...@wisteria.csv.warwick.ac.uk...
I put that 850MB p-o-s on a 233MMX w/32MB. it crawled. and I didn't
actually do anything other than email, newsgroups & games.
Keith.
Dore's Favourite Demon
Which p-o-s?
Erikc (alt.atheist #002) | "An Fhirinne in aghaidh an tSaoil."
BAAWA Knight | "The Truth against the World."
ICQ 78676616 | -- Bardic Motto
"Today on Jerry Springer: Religious whack jobs melt down before your
very eyes..."
======
Biblical inspiration for the frustrated Christian woman:
"There she lusted after her lovers, whose genitals were like those of
donkeys and whose emission was like that of horses." - Ezekiel 23:20
====
Comparing religion to science is like comparing bullshit to horsepower.
====
Real addy is firewevr @ insync dot net.
Ketil Z Malde
> Did it ever occur to anyone that saying an OS is superior because it runs on
> older hardware is like saying new cars suck because they use fuel injection
> and not carburetors?
No, because it is a totally irrelevant analogy. Fuel injection
doesn't make the difference between throwing away an old, but
otherwise perfectly good car, and keeping it. Fuel injection isn't
something you install at your leisure. That carburettors work with
older cars, doesn't mean newer cars would be faster with them. And so
on.
I don't understand why people seem to have this compulsion to compare
computers and cars all the time.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Giuliano Colla
>
> Did it ever occur to anyone that saying an OS is superior because it runs on
> older hardware is like saying new cars suck because they use fuel injection
> and not carburetors?
>
Did it ever occur to anyone else that an OS that requires a
supercomputer in order to give just ordinary performance is
like a car requiring race grade fuel in order to achieve
what other cars do with plain gas station gasoline?
IOW the capability of running in older hardware is a measure
of how well an OS exploits the hardware. As the very purpose
of an OS is exactly that of exploiting hardware at best (*),
if an OS does it better it's better, if it doesn't it sucks.
Period.
(*) Just for the record. The french for Operating System is
"Système d'exploitation".
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
Bologna (Zona Industriale Roveri)
Tel. 051 53.46.92 - 0335 610.43.35
Fax 051 53.49.89
Bob Lyday
>
> David Sidlinger wrote:
> >
> > Did it ever occur to anyone that saying an OS is superior because it runs on
> > older hardware is like saying new cars suck because they use fuel injection
> > and not carburetors?
> >
>
> Did it ever occur to anyone else that an OS that requires a
> supercomputer in order to give just ordinary performance is
> like a car requiring race grade fuel in order to achieve
> what other cars do with plain gas station gasoline?
> IOW the capability of running in older hardware is a measure
> of how well an OS exploits the hardware. As the very purpose
> of an OS is exactly that of exploiting hardware at best (*),
> if an OS does it better it's better, if it doesn't it sucks.
> Period.
Hmmm, then that makes OS/2, including OS/2 Server, the Amiga and QNX
the best OS's of all?
--
Bob
Microsoft.com corrupt! Boot Chairman Bill? (Y/Y)
Remove "diespammersdie" to reply.
Giuliano Colla
Can't tell from direct experience, but all those I know which have
either been using or writing software for OS/2 claim that it's great. If
you go into subtleties then not all OS's exploit all hardware features
the same way, so it also becomes a matter of fitness for your
applications, but in that case we are speaking of real OS's, not toys
like Windozes.
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
David Sidlinger
there are different problems that require different tools. I just get tired
of hearing that one OS is superior to another. There's no way that argument
can be settled.
- David
"Ketil Z Malde" <ke...@ii.uib.no> wrote in message
news:KETIL-vk1n...@eris.bgo.nera.no...
Giuliano Colla
>
> Personally, I don't think you can say that one OS is the best. Obviously,
> there are different problems that require different tools. I just get tired
> of hearing that one OS is superior to another. There's no way that argument
> can be settled.
>
> - David
In principle I agree with you. There is just one point to mention. If an
OS doesn't meet any minimal quality standard, makes an horrible mess
between system and user areas, gives no protection watsoever against
errors, misuse or malicious attacks, etc. etc. then it is indisputably
worse than any other honest to God OS's.
T. Max Devlin
[...]
>I don't understand why people seem to have this compulsion to compare
>computers and cars all the time.
As someone who particularly hates car analogies, but even so has used
them on rare occasion, and has studied the matter professionally
(really), I might have a few brief (?) comments on the matter.
Car analogies are compulsively used by almost everyone to describe
computers for three basic reasons:
1) Cars, and driving, are among the most complex things in normal use,
so comparisons are inevitable as there's scarcely much else to compare
them to. GUIs, particularly, are open to car analogies because of the
physical manipulation control paradigm, even though computers are not
operated like cars, even metaphorically. But overall, the complexity of
the devices in terms of user concern are roughly analogous. While cars
are 'simpler' to drive because of the massive amount of inherent
knowledge of physics which intuitively informs our actions, the computer
itself, from the user perspective, is much simpler than the mechanics of
an automobile, so in many cases the 'operator experience' is comparable.
2) Cars are large non-domicile expenses, as are computers (though much
smaller) which require some routine attention and, particularly since
the advent of the Internet, are used for a form of 'transportation'.
They break down, and repairs could be performed by a serviceman or the
owner (see point 3). They have windows, and 'under the hood' is a
self-evident expression. Just about everyone knows what one looks like
and kind of how it 'works', even if they don't know how to use it
themselves. In short, computers *are* a lot like cars.
3) You're sitting down with the controls of a system/machine at your
fingertips (see point 2). Independent of the physical control paradigm
(see point 1) the question becomes "what do you do?" Regardless of the
amount of intuitive ability the user may have to work the controls
(again, see point 1) and the potentially analogous, if not similar, end
results (see point 2) the control of the device while its being used
requires some combination of a) knowledge, and b) skill. This issue
most often results in the operator/mechanic metaphor, rather than the
operator/driver, because the computer user requires a much higher level
of knowledge and skill than the driver, except for the simplest cases.
(See also, again, point 1; a driver needs only a smidgen of knowledge
<signs, destination>, while an operator is faced with a great deal of
less intuitive, if not entirely non-intuitive, knowledge which must be
known to even know why they're using the computer.)
By 'knowledge', I mean facts, information, book-learning. By 'skill' I
mean working knowledge, familiarity with a complex series of actions.
When contemplating the learning of computers versus the learning of
automobile mechanics, a similar situation arises. Both knowledge and
skill must be learned. Obviously almost all learning involves *some*
mixture of the two, but with a subject such as, say, history, or math,
it seems clear that the ratios can be quite disparate. History is
almost zero skill, and all knowledge. Math, conversely, is all skill
little knowledge. You'll note that the more advanced the education, the
more even the balance becomes in almost any field, as well. But when
considering how to approach teaching people computers at the more
fundamental levels which operators will require, we would examine the
optimum combination for that task without requiring advanced knowledge
*or* skill as a prerequisite. Auto mechanics, we'll find, is primarily
skill, as is using a computer (programming a computer is another level
entirely). Isolated bits of fact which are necessary in a particular
case are reference to the shop manual or the docs, ideally, and how to
access these efficiently without having to memorize everything in them
is a skill, as well.
But in teaching either auto mechanics or computer operation, there is
still a fundamental level of knowledge which is necessary. The basic
components of an internal combustion engine do not radically change,
though they will potentially vary or change a great deal within each
component. The same can be said for a computer; processor, memory, and
storage are all working concepts that don't go away, even when we
virtualize them so we can substitute one for the other, when efficient.
Likewise, even the common details of most engines are similar, and
computer interfaces, both CLI and 'WIMP'/GUI, are essentially the same
across systems. You can't necessarily use every kind of spark plug in
every engine, nor can you use the same syntax at every prompt (you see
how easily even really horrible analogies become between cars and
computers?), but part of the reason all engines use spark plugs of
basically similar design is because its good to replicate the basic
form, rather than coming up with a whole new way of sparking combustion
for every engine. Likewise, CLIs aren't generally similar because
that's *always* the most efficient way to do everything, its just more
efficient to do them all the same because its rather efficient across
all implementations.
So, anyway, the third reason people use car analogies is because both
computers and cars are information intensive *skills*, rather than more
rudimentary skills with less knowledge requirements like playing sports
or being sociable at a party or building furniture or going camping, any
of which might abstractly make potential analogies, at least, though
admittedly none are as familiar to the largest number of people as cars
are (see point 2, again). But it isn't just plain old knowledge; you
have to do something, not just know something.
--
T. Max Devlin
-- Such is my recollection of my reconstruction
of events at the time, as I recall. Consider it.
Research assistance gladly accepted. --
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Elf Sternberg
"David Sidlinger" <sidl...@mindspring.com> writes:
>Did it ever occur to anyone that saying an OS is superior because it runs on
>older hardware is like saying new cars suck because they use fuel injection
>and not carburetors?
Actually, it's a bit like saying that a *driver* is superior
because he can get performance out of POS hardware whereas your
typically granny cannot.
Elf
--
Elf M. Sternberg, rational romantic mystical cynical idealist
http://www.halcyon.com/elf/
"The purpose of writing is to inflate weak ideas, obscure pure
reasoning, and inhibit clarity. With a little pratice, writing can
be an intimidating and impenetrable fog!" - Bill Watterson's Calvin.
Nigel Feltham
David Sidlinger wrote in message <8p1lpr$ci3$1...@slb0.atl.mindspring.net>...
>Did it ever occur to anyone that saying an OS is superior because it runs
on
>older hardware is like saying new cars suck because they use fuel injection
>and not carburetors?
>
No but any car which crashes at lease once per day and the engine takes up
so much space there is hardly any room for passengers (and needs replacing
every 2 or 3 years to drive on the latest roads) does suck.
Keith T. Williams
should read "Bugs" by Christopher Anvil, Analog Science Fiction/Science
Fact, June 1986
Nigel Feltham <nigel....@libertysurf.co.uk> wrote in message
news:8p6ac5$c3rmb$1...@ID-35459.news.cis.dfn.de...
Alan
stock radio to keep aftermarket radios out.
T. Max Devlin
>stock radio to keep aftermarket radios out.
Ouch. That's a *good* one.
Keith T. Williams
Alan <surf_r...@yahoo.com> wrote in message
news:39b6f88e...@news.earthlink.net...
> My favorite analogy is the moving of the distributer function into the
> stock radio to keep aftermarket radios out.
>
player? Better mileage
perhaps? ;-))
David Sidlinger
a reboot in 6 months, and, with 75 GB IDE drives available now, a 1.4 GB
full install of 2000 Advanced Server (with all options selected) doesn't
seem that big after all. Like I said in an earlier post, I don't think that
any one OS is superior, I just hate the fact that some people feel the need
to wage some kind of war against another OS. Windows has its place, just
like Linux, FreeBSD, True64, MacOS, etc. In all reality, what crashes
Windows is not the OS, it's low quality software from a third party.
Regards,
David
"Nigel Feltham" <nigel....@libertysurf.co.uk> wrote in message
news:8p6ac5$c3rmb$1...@ID-35459.news.cis.dfn.de...
>
Giuliano Colla
>
> That's interesting, because I have a Windows 2000 server that hasn't needed
> a reboot in 6 months, and, with 75 GB IDE drives available now, a 1.4 GB
> full install of 2000 Advanced Server (with all options selected) doesn't
> seem that big after all. Like I said in an earlier post, I don't think that
> any one OS is superior, I just hate the fact that some people feel the need
> to wage some kind of war against another OS. Windows has its place, just
> like Linux, FreeBSD, True64, MacOS, etc. In all reality, what crashes
> Windows is not the OS, it's low quality software from a third party.
>
I have a Windows NT4 server which in the last two years has
only been rebooted twice a year (for summer and winter
holidays), and for setup changes, but whenever I give a look
to how things are implemented with respect to other OS's
(which for example don't require reboot for setup change) I
realize that it's just crap.
If you only scan the postings in this NG you'll find out
that those asserting that Windows is crap are those which
have some first hand experience on other OS's. That's why
it's good exercise comparing different OS's merits. You
don't just settle for something which works. You choose what
work best. Which never happens to be Windows.
When I say this NG I mean alt.destroy.microsoft, not
alt.atheism! How on earth this thread happens to be also
there?
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
Johan Kullstam
> That's interesting, because I have a Windows 2000 server that hasn't needed
> a reboot in 6 months, and, with 75 GB IDE drives available now, a 1.4 GB
> full install of 2000 Advanced Server (with all options selected) doesn't
> seem that big after all. Like I said in an earlier post, I don't think that
> any one OS is superior, I just hate the fact that some people feel the need
> to wage some kind of war against another OS. Windows has its place, just
> like Linux, FreeBSD, True64, MacOS, etc. In all reality, what crashes
> Windows is not the OS, it's low quality software from a third party.
i have an NT box at work where matlab managed to create a directory
entry called "lpt1:" on an NTFS partition. this is one of NT's
"magic" filenames.
i couldn't delete it, but the system calls
would find the magic filename and refuse to go further. i finally
resorted to killing the parent directory with explorer. after
rebooting from the blue screen, the file was apparently gone.
however, i was left with an undeletable crud called "dds:" in my trash
bucket. for over a year, it caused no problem except for the
annoyance of getting a popup saying that "dds:" could not be removed.
two weeks ago, this changed. emptying the bucket would cause the
whole thing to go unstable and lockup or bluescreen within a couple of
mouse clicks.
it was NT's fault to create this bogus directory entry in the first
place (NT does do the filesystem). it's NT's fault for hiding
everything so you cannot actually fix the problem. i blame the low
quality of the OS. in *reality* -- since this just happened to me --
what crashes windows *is* the OS.
furthermore, no OS worth its salt would *let* a userland program crash
it. if it does, it is, again, the *OS's fault*.
> Regards,
> David
>
> "Nigel Feltham" <nigel....@libertysurf.co.uk> wrote in message
> news:8p6ac5$c3rmb$1...@ID-35459.news.cis.dfn.de...
> >
> > David Sidlinger wrote in message <8p1lpr$ci3$1...@slb0.atl.mindspring.net>...
> > >Did it ever occur to anyone that saying an OS is superior because it runs
> > on
> > >older hardware is like saying new cars suck because they use fuel
> injection
> > >and not carburetors?
> > >
> >
> >
> > No but any car which crashes at lease once per day and the engine takes up
> > so much space there is hardly any room for passengers (and needs replacing
> > every 2 or 3 years to drive on the latest roads) does suck.
> >
> >
> >
> >
> >
> >
>
>
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Alan
classical. Of course the automatic door lock and power window
functions that were bundled into the radio/Distributer/ECU/microwave
oven version 4.0 would trap me in the car for days. Of course, if I
could only upgrade the speakers and lousy floormats without having to
install radio/Distributer/ECU/microwave oven version 5.0.
Can you imagine if MS owned Firestone?
At the risk of sick humor at the expense of victims, their familes and
loved ones, Someone could come up with some zinger MS tire licenses.
Alan
Giuliano Colla
[snip]
>
> i have an NT box at work where matlab managed to create a directory
> entry called "lpt1:" on an NTFS partition. this is one of NT's
> "magic" filenames.
>
> i couldn't delete it, but the system calls
> would find the magic filename and refuse to go further. i finally
> resorted to killing the parent directory with explorer. after
> rebooting from the blue screen, the file was apparently gone.
I understand that the idea of your posting was to give
another evidence of how crappy even the "professional" NT
is. But just for the record, did you try DOS commands to fix
that problem?
Johan Kullstam
> Johan Kullstam wrote:
> [snip]
> >
> > i have an NT box at work where matlab managed to create a directory
> > entry called "lpt1:" on an NTFS partition. this is one of NT's
> > "magic" filenames.
> >
> > i couldn't delete it, but the system calls
> > would find the magic filename and refuse to go further. i finally
> > resorted to killing the parent directory with explorer. after
> > rebooting from the blue screen, the file was apparently gone.
> [snip]
>
> I understand that the idea of your posting was to give
> another evidence of how crappy even the "professional" NT
> is. But just for the record, did you try DOS commands to fix
> that problem?
DOS can't read NTFS. i could bring up command prompts, cmd.exe,
4nt, bash, but to no avail. i even tried emacs and dired mode.
Giuliano Colla
OK. I understand. I had a box set-up for testing purposes
with Win95 FAT32, NT4 with NTFS and Linux, and I could
access everything only from Linux, because Win95 couldn't
read NTFS and NT couldn't read FAT32! If you had a small
Linux partition you could have solved your problem maybe.
NTFS R/W is not yet considered stable from Linux world, but
usually unstable Linux things are one order of magnitude
more reliable than stable M$ crapware...
Johan Kullstam
> Johan Kullstam wrote:
> >
> > Giuliano Colla <cop...@copeca.dsnet.it> writes:
> >
> > > Johan Kullstam wrote:
> > > [snip]
> > > >
> > > > i have an NT box at work where matlab managed to create a directory
> > > > entry called "lpt1:" on an NTFS partition. this is one of NT's
> > > > "magic" filenames.
> > > >
> > > > i couldn't delete it, but the system calls
> > > > would find the magic filename and refuse to go further. i finally
> > > > resorted to killing the parent directory with explorer. after
> > > > rebooting from the blue screen, the file was apparently gone.
> > > [snip]
> > >
> > > I understand that the idea of your posting was to give
> > > another evidence of how crappy even the "professional" NT
> > > is. But just for the record, did you try DOS commands to fix
> > > that problem?
> >
> > DOS can't read NTFS. i could bring up command prompts, cmd.exe,
> > 4nt, bash, but to no avail. i even tried emacs and dired mode.
>
> OK. I understand. I had a box set-up for testing purposes
> with Win95 FAT32, NT4 with NTFS and Linux, and I could
> access everything only from Linux, because Win95 couldn't
> read NTFS and NT couldn't read FAT32!
this always stunned me. why can't MS release a FAT32 update for NT?
> If you had a small
> Linux partition you could have solved your problem maybe.
next time something like this happens, i'll give it a whirl. i had to
reinstall NT to fix anyhow so it's not like i'd have lost much.
> NTFS R/W is not yet considered stable from Linux world, but
> usually unstable Linux things are one order of magnitude
> more reliable than stable M$ crapware...
yes, but the NTFS write feature of linux is known to be very buggy.
unfortunately microsoft hasn't been exactly eager to release
specifications on the guts of the filesystem.
Giuliano Colla
>
[snip]
>
> this always stunned me. why can't MS release a FAT32 update for NT?
So that you'll buy an update for NT (called W2k) which supports FAT32, a
malicious mind might think!
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
Damien
Johan Kullstam <kull...@ne.mediaone.net> wrote:
| Giuliano Colla <cop...@copeca.dsnet.it> writes:
| > NTFS R/W is not yet considered stable from Linux world, but
| > usually unstable Linux things are one order of magnitude
| > more reliable than stable M$ crapware...
Be careful. A buggy application may crash, causing you to lose the
data you hadn't saved yet. But a buggy filesystem module could very
likely corrupt your partition and panic your kernel.
| yes, but the NTFS write feature of linux is known to be very buggy.
| unfortunately microsoft hasn't been exactly eager to release
| specifications on the guts of the filesystem.
And don't forget the filesystem has changed with NT5/W2k. NTFS5
supports links now!
Giuliano Colla
>
> On Fri, 08 Sep 2000 21:07:35 GMT, in alt.destroy.microsoft
> Johan Kullstam <kull...@ne.mediaone.net> wrote:
> | Giuliano Colla <cop...@copeca.dsnet.it> writes:
>
> | > NTFS R/W is not yet considered stable from Linux world, but
> | > usually unstable Linux things are one order of magnitude
> | > more reliable than stable M$ crapware...
>
> Be careful. A buggy application may crash, causing you to lose the
> data you hadn't saved yet. But a buggy filesystem module could very
> likely corrupt your partition and panic your kernel.
In general you're right. But in this particular case we were discussing
a situation which led poor Johan to reinstall his system. Just before
resorting to FORMAT C:, you may risk.
>
> | yes, but the NTFS write feature of linux is known to be very buggy.
> | unfortunately microsoft hasn't been exactly eager to release
> | specifications on the guts of the filesystem.
>
> And don't forget the filesystem has changed with NT5/W2k. NTFS5
> supports links now!
And some people don't believe that M$ is innovating!
Some day they'll even introduce the concept of filename parsing and will
solve the problem of forbidden filenames!
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
T. Max Devlin
>>
>[snip]
>>
>> this always stunned me. why can't MS release a FAT32 update for NT?
>
>So that you'll buy an update for NT (called W2k) which supports FAT32, a
>malicious mind might think!
Still, it took them that long. I guess they were saving it to force
people from Win98 to 'the next thing', once they got it. They probably
hoped to continue NT in parallel, so didn't need to force the
intermediate step from Win98-NT-W2K.
Anyway, the reason I'm posting is I wanted to mention that if you *had*
used Linux to kill the 'phantom file' that you described, it may well
have caused Windows to completely crap out and require a re-install.
I've seen similar 'phantoms' in the 'Recycle bin' and such since Win95
first came out. I did 'rip one out', once, through a 'back door' type
trick like this, and while it didn't immediately destroy the system, I
did have to re-install within a few weeks after that. Just anecdotal
advice, mind you. I was also having trouble with the CPU hardware, and
while I know this was unrelated to the trashcan problem, (as its
appeared on other systems), it might have been the reason for some of
the failures.
It seems that such a mirage can appear when, for instance, you delete
the contents of the hidden 'Recycle Bin' directory directly, or do other
things like unhide it or remove the trashcan from the desktop. It
becomes much more common when you have multiple drives, too.
T. Max Devlin
Symbolic, hard, or both?
Giuliano Colla
>
[snip]
>
> Anyway, the reason I'm posting is I wanted to mention that if you *had*
> used Linux to kill the 'phantom file' that you described, it may well
> have caused Windows to completely crap out and require a re-install.
> I've seen similar 'phantoms' in the 'Recycle bin' and such since Win95
> first came out. I did 'rip one out', once, through a 'back door' type
> trick like this, and while it didn't immediately destroy the system, I
> did have to re-install within a few weeks after that. Just anecdotal
> advice, mind you. I was also having trouble with the CPU hardware, and
> while I know this was unrelated to the trashcan problem, (as its
> appeared on other systems), it might have been the reason for some of
> the failures.
Yes, you're right, of course. It can be very dangerous. It
is typical of M$ to resort to "unclean" solutions, so that a
particular file in a particular directory can only be
deleted by a particular program because of hidden
interactions. This leads to a more general item which I'd
like to discuss.
It is my opinion that incompetence is the basis of M$
behavior.
The technical background of top management (starting from
BG) must be really poor. The approach is that of an amateur
which tries to "make it work " one way or another, but
doesn't know what analysis is and just starts writing lines
of code. If you have a minimal competence, when you design
something you can't help considering "what if..?" and you
avoid crappy solutions.
Their greatest asset is that they have learned how to
exploit their incompetence for an anti-competitive policy.
Which is not so hard, because competitors can figure out how
a clean solution is implemented, even if it's not well
documented, but it's almost impossible to figure out a
crappy solution. You may reconstruct a logical reasoning
even if some parts are missing. You cannot reconstruct an
illogical reasoning by partial knowledge.
Just looking at the incredible mess M$ API's are, can prove
my point, but I think that a couple of examples, from far
away past history and from recent history can be
enlightening.
Unix filesystem has provided a mechanism so that the first
two entries of a directory point to the directory
hierarchical father and to the directory itself. This helps
traveling the directory tree and it's quite useful. Not to
have this information cluttering directory listing, they've
decided to name those two entries as a single and a double
dot and not to show filenames beginning with a dot. With a
simple design choice they've provided both an useful
mechanism for traveling directory trees and to provide
"hidden files".
MSDOS filesystem has provided the same mechanism, only the
two entries are shown, and a different mechanism is used for
hidden files. This has nothing to do with anti-competitive
policies. They simply failed to understand the "clean" Unix
solution and they adopted an unnecessarily different one
which is less efficient and more error prone.
The other case is the W2k AD implementation (see the "ZDNet
reviews W2K server; I think you'll be surprised.." thread).
I'm pretty sure that the interoperability problems which are
bound to result from fooling with DNS mechanism will not
only affect Unix servers/clients, but also MS
servers/clients and it will badly backfire. Only, to
implement such a feature in a "clean" way you should perform
a lot of analysis, create a "service" in your server which
will create and manage a virtual directory (or a set of
them) manage the client connections and connect them to the
appropriate servers (acting like a proxy) using the standard
DNS features whenever a name needs to be resolved into a
physical address. In my scant knowledge of how those things
work it looks like a reasonable approach. But M$ CAN'T DO
IT. Because you need a well partitioned system where you
have different processes working simultaneously with a good
IPC mechanism, which M$ doesn't have. The OS can't tell
whether a client connected has simply an open connection or
has some file open for writing, and lets the user figure
out!
Network mechanisms have been so fouled up that they're used
to connect CD drives! So they've resorted to the "simplest"
solution: let DNS service (which must be used because you
start with a name which has to be somehow resolved) handle
to whole thing, because they had no means to partition it in
a reasonable way. As this also helps to push competitors
out, it's a "good" solution. But I have the strong belief
that incompetence and poor design are the basis of
everything. Then they can't help being anti-competitive,
because they can't afford to compete.
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
Johan Kullstam
the common theme of microsoft programs is the dearth of nested
structure. billg is an old basic hack. basic, back in the '70s, had
no subroutines worth the name (well, there was gosub but you couldn't
pass arguments nor hide local variables &c). look at, e.g., ms-word.
you can't be doing a list. push the state, start up a new
environment and then pop back out to the list environment. there's no
nesting; it's all flat. much of microsoft is like this.
it's like basic. basic is a fantastic language for writing 10-20 line
programs. it's *horrible* at anything over 100. thus microsoft
suckers you with "ease of novice" and then makes you suffer eternally
with "pain of usage".
> Their greatest asset is that they have learned how to
> exploit their incompetence for an anti-competitive policy.
> Which is not so hard, because competitors can figure out how
> a clean solution is implemented, even if it's not well
> documented, but it's almost impossible to figure out a
> crappy solution. You may reconstruct a logical reasoning
> even if some parts are missing. You cannot reconstruct an
> illogical reasoning by partial knowledge.
>
> Just looking at the incredible mess M$ API's are, can prove
> my point, but I think that a couple of examples, from far
> away past history and from recent history can be
> enlightening.
i think it all comes down to MS running scared when digital-research
reverse engineered DOS. they realized DOS was too simple and GUI and
now with C++ gives a perfect oportunity to create a totally inscutible
interface. windows is fairly reverse proof, look how long the WINE
program has been trying to do that.
> Unix filesystem has provided a mechanism so that the first
> two entries of a directory point to the directory
> hierarchical father and to the directory itself. This helps
> traveling the directory tree and it's quite useful.
the unix filesystem gave us the whole concept of a directory tree.
other operating systems like CP/M, MS-DOS v1, VMS or TOPS-20 work
rather differently.
> Not to
> have this information cluttering directory listing, they've
> decided to name those two entries as a single and a double
> dot and not to show filenames beginning with a dot. With a
> simple design choice they've provided both an useful
> mechanism for traveling directory trees and to provide
> "hidden files".
this is just a policy of ls and your shell expaning *. you could hack
ls and shell to make the former show all files and the latter have *
match everything.
> MSDOS filesystem has provided the same mechanism, only the
> two entries are shown, and a different mechanism is used for
> hidden files. This has nothing to do with anti-competitive
> policies. They simply failed to understand the "clean" Unix
> solution and they adopted an unnecessarily different one
> which is less efficient and more error prone.
i don't think the hidden flag is good or bad.
in unix the hidden policy is set by using a certain naming
convention. in ms-dos you can "hide" an arbitrary file using a bit.
this particular point isn't an advantage of unix. imho ms-dos does
the hidden file better.
on the other hand, a minor unix annoyance of mine is the profusion of
dot-files in my home directory. i'd prefer to have an ~/etc directory
(in my home) and have the config file names not begin with a dot.
> The other case is the W2k AD implementation (see the "ZDNet
> reviews W2K server; I think you'll be surprised.." thread).
> I'm pretty sure that the interoperability problems which are
> bound to result from fooling with DNS mechanism will not
> only affect Unix servers/clients, but also MS
> servers/clients and it will badly backfire. Only, to
> implement such a feature in a "clean" way you should perform
> a lot of analysis, create a "service" in your server which
> will create and manage a virtual directory (or a set of
> them) manage the client connections and connect them to the
> appropriate servers (acting like a proxy) using the standard
> DNS features whenever a name needs to be resolved into a
> physical address. In my scant knowledge of how those things
> work it looks like a reasonable approach. But M$ CAN'T DO
> IT. Because you need a well partitioned system where you
> have different processes working simultaneously with a good
> IPC mechanism, which M$ doesn't have. The OS can't tell
> whether a client connected has simply an open connection or
> has some file open for writing, and lets the user figure
> out!
unix doesn't do a particular good job at network file systems either.
the unix API assumes that the kernel is in complete control and hence
some awful kludges are used to make stuff like NFS work. i'm not sure
MS systems are any better off though.
> Network mechanisms have been so fouled up that they're used
> to connect CD drives! So they've resorted to the "simplest"
> solution: let DNS service (which must be used because you
> start with a name which has to be somehow resolved) handle
> to whole thing, because they had no means to partition it in
> a reasonable way. As this also helps to push competitors
> out, it's a "good" solution. But I have the strong belief
> that incompetence and poor design are the basis of
> everything. Then they can't help being anti-competitive,
> because they can't afford to compete.
--
Damien
T. Max Devlin <tm...@nbn.net> wrote:
| Said Damien in alt.destroy.microsoft;
| >On Fri, 08 Sep 2000 21:07:35 GMT, in alt.destroy.microsoft
| > Johan Kullstam <kull...@ne.mediaone.net> wrote:
| >| yes, but the NTFS write feature of linux is known to be very buggy.
| >| unfortunately microsoft hasn't been exactly eager to release
| >| specifications on the guts of the filesystem.
| >
| >And don't forget the filesystem has changed with NT5/W2k. NTFS5
| >supports links now!
|
| Symbolic, hard, or both?
Not really either as I understand it. If I remember correctly, it
works like this: If you have two identical files on the system,
instead of storing them in two different places, you can have one be a
link to the other. But then, if you change one of them, they revert
to being two separate files. Someone correct me if I FUBAR'd that
description. I can only hope I'm wrong because I can't imagine that
having any sort of utility.
Ville Niemi
Alan <surf_r...@yahoo.com> kirjoitti
viestissä:39b85fe2...@news.earthlink.net...
1) for using Microsoft products in a manner not covered by the license
2) for using Microsoft products to cause damage (forbidden by license)
3) for failing to return products intact when the license expired
4) for disassembling the product (also forbidden)
5) for trying to guess what failed (reverse engineering)
6) there is no number six
7) for blaming Microsoft despite accepting Microsoft's liabilities statement
In addition,b Microsoft would sue the television channels for using
Microsoft trademarks without proper license. (Footage from accident scenes
showing the Microsoft logo.)
Also, Microsoft wouldn't replace the products. They would SELL upgrades,
that keep the product working, but would have to be replaced at regular
intervals, thus generating stable revenue. I can see the Ads:
'Microsoft Transport 2000 - the new age of transportation - safer, cheaper,
faster.'
Turning substandard manufacturing into a marketing asset other manufacturers
can't reproduce. They did it on software, why not on hardware.
Ville
Ville Niemi
> But I have the strong belief that incompetence and poor design are
> the basis of everything.
Actually, much of Win problems are due to fact that in Microsoft marketing
is more important than development. They believe: 'If it doesn't get sold
its useless, if it gets sold its a good product.'
The design of Windows wasn't really planned either well or bad, it just
happened when Microsoft used crappy code they already had to exploit market
opportunities. Remember Windows 3.0? Sold zillions, killed OS\2 ( the only
potential competitor Microsoft had those days ), and was total crap.
What I think happened is that Microsoft had Win386 code and some GUI
prototypes, noticed a market gap between DOS and OS\2, developed a nice Ad
campaign and marketing strategy, bundled the code and projects together
without debugging or optimizing ('if it sells, it is working') and sold the
result as a finished product and a cheaper alternative to OS\2. It worked,
many people moved to Windows and had to buy 3.1 upgrade.
Windows 9x is a similar fill the gap solution, developed for the MARKET, not
the users. There is a difference, market is the people likely to buy, users
the people who already bought. The secret of Microsoft's success is their
ability to show the versions of Windows as separate generations, so that
people believe that the next upgrade will change everything. This allows
Microsoft to pretty much ignore stuff like customer satisfaction. In fact,
they use customer dissatisfaction to market their upgrades.
As long as Microsoft can convince majority of people that they have the
solutions people are looking for, the minor annoyances of people who already
bought are meaningless.
Ville
Keith T. Williams
Ville Niemi <ville...@pp4.inet.fi> wrote in message
news:o4uu5.515$Ku1....@read2.inet.fi...
Keith T. Williams
Giuliano Colla <cop...@copeca.dsnet.it> wrote in message
news:39B7B8D4...@copeca.dsnet.it...
That's easy... considering the quality of MS Software, there
is no way that there is a God.
Or
Anyone who uses it spends so much time praying.. without
results...
Keith.
T. Max Devlin
[...]
>It is my opinion that incompetence is the basis of M$
>behavior.
>The technical background of top management (starting from
>BG) must be really poor. The approach is that of an amateur
>which tries to "make it work " one way or another, but
>doesn't know what analysis is and just starts writing lines
>of code. If you have a minimal competence, when you design
>something you can't help considering "what if..?" and you
>avoid crappy solutions.
>
>Their greatest asset is that they have learned how to
I don't see it that way, but just the opposite. It isn't that technical
incompetence leads to anti-competitive policy as the only way to get it
to sell. It is more that anti-competitive intent leads to crap
software.
The 'guiding wisdom' of Microsoft's software is very competently
implemented. The only reason it looks like technical competence is that
you misread the goal. The goal is honestly not to produce good
software; its to monopolize through every means available. Even a
perfectly working system will degenerate into crap, when the decisions
on how to 'improve' it are based on the consideration of 'well, what
would make it hardest for anyone else to compete?', rather than "what
will benefit the consumer the most without increasing the cost?"
This is the basis for my rant on the prevalence and all-engrossing
idealogy of 'winning' competition, and consideration of market share as
a legal strategy. Even a company with more than 99% market share is
still *legally required* to consider "but if we do that, it will prevent
anyone else from being able to...", and reject any strategy or
development which makes it harder for even an unheard-of potential
competitor to engage in free trade.
Microsoft doesn't monopolize because there's no other way to sell their
crappy software. Microsoft has crappy software because that the
inevitable result of trying to monopolize, instead of develop software.
>Which is not so hard, because competitors can figure out how
>a clean solution is implemented, even if it's not well
>documented, but it's almost impossible to figure out a
>crappy solution.
Precisely.
[...]
>Just looking at the incredible mess M$ API's are, can prove
>my point, but I think that a couple of examples, from far
>away past history and from recent history can be
>enlightening.
>
>Unix filesystem has provided a mechanism so that the first
>two entries of a directory point to the directory
>hierarchical father and to the directory itself. This helps
>traveling the directory tree and it's quite useful. Not to
>have this information cluttering directory listing, they've
>decided to name those two entries as a single and a double
>dot and not to show filenames beginning with a dot. With a
>simple design choice they've provided both an useful
>mechanism for traveling directory trees and to provide
>"hidden files".
>MSDOS filesystem has provided the same mechanism, only the
>two entries are shown, and a different mechanism is used for
>hidden files. This has nothing to do with anti-competitive
>policies. They simply failed to understand the "clean" Unix
>solution and they adopted an unnecessarily different one
>which is less efficient and more error prone.
Personally, I always thought of the 'hidden file' mechanism in Unix was
a kludge. It makes sense the way you explain it, but hinging two things
together like that seems more opportunism than careful design. Then
again, the appropriate alternative, I guess, would be to have whether
the file is hidden (to non-root) in the permissions, and that would be
much less efficient.
I guess in the end, since hidden files aren't really a good idea anyway,
it works well the way its done now. How does OS/2 do it?
>The other case is the W2k AD implementation (see the "ZDNet
>reviews W2K server; I think you'll be surprised.." thread).
>I'm pretty sure that the interoperability problems which are
>bound to result from fooling with DNS mechanism will not
>only affect Unix servers/clients, but also MS
>servers/clients and it will badly backfire. [...]
Well, that's a crucial point. Because being an anti-competitive action,
which under market conditions would 'backfire' and reduce the
acceptability of the product, the same action merely *helps* the
monopoly. In this case, it will drive people to buy the newer 'fixes'
to all the interoperability problems within MS products, thus driving up
sales for them and reducing the competition in the market by disabling
non-MS systems in a way that only MS can fix (by selling the new
version). W2K would find an installed base in both those
implementations which don't have these problems, and those that do. The
'success' of those that don't will be leveraged to make those that do a
hand-waving activity; "Oh, its your fault (lousy developers, crabby Unix
admins, you didn't do it right...) but the next version will fix *your*
problem..."
You see how that works? I'd like to say it will never work, because W2K
doesn't really have enough 'market power', but if that were so, nobody
would be trying to use it to begin with, because its a really crappy
software package.
T. Max Devlin
>Giuliano Colla <cop...@copeca.dsnet.it> writes:
[...]
>in unix the hidden policy is set by using a certain naming
>convention. in ms-dos you can "hide" an arbitrary file using a bit.
>this particular point isn't an advantage of unix. imho ms-dos does
>the hidden file better.
I thought the same thing, at first glance; I was even ready to respond
to Giuliano saying so. Then I realized the efficiencies of the Unix
method, and remembered the problems of having hidden files at all (as
opposed to a 'filename filter', possibly default). I've changed my
opinion; imho Unix does hidden files *slightly* better. The best
approach, unavailable in the Unix philosophy and possibly ineffective
elsewhere, is to not have the things be files at all; that would "hide"
them without causing confusion. Better still to recognize that hidden
files are a convenience so that you can easily exclude files from lists
and searches, and just use the elegantly simple Unix way.
[...]
>unix doesn't do a particular good job at network file systems either.
>the unix API assumes that the kernel is in complete control and hence
>some awful kludges are used to make stuff like NFS work. i'm not sure
>MS systems are any better off though.
I think "awful kludges" might well characterize SMB. Particularly in
recent MS implementations. But that's just based on observation; I
don't know what the guts look like in either.
T. Max Devlin
Holy christ. In reference to Guiliano's recent posts, it sure does seem
you'd have to be purposefully misdesigning stuff to come up with such a
stupid idea. It boggles the mind, honestly. You *must* be mistaken. I
hope.
Giuliano Colla
>
> Giuliano Colla <cop...@copeca.dsnet.it> wrote in message
> news:39B7B8D4...@copeca.dsnet.it...
> >
> > When I say this NG I mean alt.destroy.microsoft, not
> > alt.atheism! How on earth this thread happens to be also
> > there?
>
> That's easy... considering the quality of MS Software, there
> is no way that there is a God.
>
> Or
>
> Anyone who uses it spends so much time praying.. without
> results...
>
Good points!
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
Giuliano Colla
>
> Said Giuliano Colla in alt.destroy.microsoft;
> >"T. Max Devlin" wrote:
> [...]
> >It is my opinion that incompetence is the basis of M$
> >behavior.
> >The technical background of top management (starting from
> >BG) must be really poor. The approach is that of an amateur
> >which tries to "make it work " one way or another, but
> >doesn't know what analysis is and just starts writing lines
> >of code. If you have a minimal competence, when you design
> >something you can't help considering "what if..?" and you
> >avoid crappy solutions.
> >
> >Their greatest asset is that they have learned how to
> >exploit their incompetence for an anti-competitive policy.[...]
>
> I don't see it that way, but just the opposite. It isn't that technical
> incompetence leads to anti-competitive policy as the only way to get it
> to sell. It is more that anti-competitive intent leads to crap
> software.
I believe that we may start an endless debate on this subject, as it is
basically an "egg and chicken" problem. Today incompetence and
anti-competitiveness are so strongly established that it's almost
impossible to determine what came first.
It is my opinion that incompetence came first, because in order to start
anti-competitive policies you must have established a minimum base. So
if you start with good software which becomes crappy as time goes by you
may think that anti-competitiveness is taking over competence. If
software is crappy from the very beginning (take the first BIOS) you're
led to conclude that incompetence is the starting point. However, to
avoid the endless debate I propose you a contest: each time we find
something which can prove my point (i.e. useless crappyness) it's one
point for me. Each time we find something which may prove your point
(i.e. crappyness coming from anti-competitive goals only) it's one point
for you. If at the end of the contest MS is reduced to an also run in
the software arena we both win. If not we both loose!
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
Giuliano Colla
[snip]
>
>
> Personally, I always thought of the 'hidden file' mechanism in Unix was
> a kludge. It makes sense the way you explain it, but hinging two things
> together like that seems more opportunism than careful design. Then
> again, the appropriate alternative, I guess, would be to have whether
> the file is hidden (to non-root) in the permissions, and that would be
> much less efficient.
>
> I guess in the end, since hidden files aren't really a good idea anyway,
> it works well the way its done now. How does OS/2 do it?
>
[snip]
I don't know about OS/2. The Intel RMX filesystem (which owes a lot to
Unix, but came around 1984) considered hidden the files whose name began
with R?. They didn't need the dot and double dot entries because the
informations were stored in the directory inode (which they called
fnode, to differentiate from Unix).
However, as the purpose of a hidden file is not to clutter directory
listing with filenames of little concern to normal user, using a naming
convention seems to me a reasonable idea because you don't need to
access extra information in order to decide wether to show a name or
not.
The choice of MS clutters in any case a directory listing with two
useless entries (one point for me in the contest), but makes it harder
for users to gain a better knowledge of what is in a directory (one
point for you).
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
David Sidlinger
lets DOS work with NTFS partitions.
- David
"Johan Kullstam" <kull...@ne.mediaone.net> wrote in message
news:m27l8ni...@euler.axel.nom...
Giuliano Colla
>
> Said Damien in alt.destroy.microsoft;
> >On Sat, 09 Sep 2000 00:01:03 -0400, in alt.destroy.microsoft
> > T. Max Devlin <tm...@nbn.net> wrote:
> >| Said Damien in alt.destroy.microsoft;
> >| >On Fri, 08 Sep 2000 21:07:35 GMT, in alt.destroy.microsoft
> >| > Johan Kullstam <kull...@ne.mediaone.net> wrote:
> >
> >| >| yes, but the NTFS write feature of linux is known to be very buggy.
> >| >| unfortunately microsoft hasn't been exactly eager to release
> >| >| specifications on the guts of the filesystem.
> >| >
> >| >And don't forget the filesystem has changed with NT5/W2k. NTFS5
> >| >supports links now!
> >|
> >| Symbolic, hard, or both?
> >
> >Not really either as I understand it. If I remember correctly, it
> >works like this: If you have two identical files on the system,
> >instead of storing them in two different places, you can have one be a
> >link to the other. But then, if you change one of them, they revert
> >to being two separate files. Someone correct me if I FUBAR'd that
> >description. I can only hope I'm wrong because I can't imagine that
> >having any sort of utility.
>
> Holy christ. In reference to Guiliano's recent posts, it sure does seem
> you'd have to be purposefully misdesigning stuff to come up with such a
> stupid idea. It boggles the mind, honestly. You *must* be mistaken. I
> hope.
I had your same reaction, but then I remembered the "Synchronize Files"
(is it called that way in the english version?) folder on Windows
Desktop, and I realized that Damien could be right. This would make a
good point for me in the contest!
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
T. Max Devlin
>> But I have the strong belief that incompetence and poor design are
>> the basis of everything.
>
>Actually, much of Win problems are due to fact that in Microsoft marketing
>is more important than development. They believe: 'If it doesn't get sold
>its useless, if it gets sold its a good product.'
Its worse than that (since, by itself, this statement is a perfect
implementation of market theory.) 'If it doesn't stop other people from
selling things, its useless, if it prevents others from selling things,
its a good product' would probably be more accurate in Microsoft's case.
>The design of Windows wasn't really planned either well or bad, it just
>happened when Microsoft used crappy code they already had to exploit market
>opportunities.
Again, I think its worse than that. Microsoft does, in fact, make
crappy code on purpose, because the crappier it gets (once you're a
monopoly), the more people will buy the next version, and the less
chance anyone else has of being able to interoperate with it.
>Remember Windows 3.0? Sold zillions, killed OS\2 ( the only
>potential competitor Microsoft had those days ), and was total crap.
Actually, it was Win3.1, and it was Microsoft's machinations, not
Windows, that killed OS/2.
[...]
>As long as Microsoft can convince majority of people that they have the
>solutions people are looking for, the minor annoyances of people who already
>bought are meaningless.
I don't think its a matter of 'convincing' anyone, but merely making the
entire question academic by making it the only choice available. Sure,
they use hype, guile, and lies to 'convince' people it is the solution
they're looking for, but that's just covering their tracks, not
influencing the decision.
Johan Kullstam
> Said Damien in alt.destroy.microsoft;
> >On Sat, 09 Sep 2000 00:01:03 -0400, in alt.destroy.microsoft
> > T. Max Devlin <tm...@nbn.net> wrote:
> >| Said Damien in alt.destroy.microsoft;
> >| >On Fri, 08 Sep 2000 21:07:35 GMT, in alt.destroy.microsoft
> >| > Johan Kullstam <kull...@ne.mediaone.net> wrote:
> >
> >| >| yes, but the NTFS write feature of linux is known to be very buggy.
> >| >| unfortunately microsoft hasn't been exactly eager to release
> >| >| specifications on the guts of the filesystem.
> >| >
> >| >And don't forget the filesystem has changed with NT5/W2k. NTFS5
> >| >supports links now!
> >|
> >| Symbolic, hard, or both?
> >
> >Not really either as I understand it. If I remember correctly, it
> >works like this: If you have two identical files on the system,
> >instead of storing them in two different places, you can have one be a
> >link to the other. But then, if you change one of them, they revert
> >to being two separate files. Someone correct me if I FUBAR'd that
> >description. I can only hope I'm wrong because I can't imagine that
> >having any sort of utility.
>
> Holy christ. In reference to Guiliano's recent posts, it sure does seem
> you'd have to be purposefully misdesigning stuff to come up with such a
> stupid idea. It boggles the mind, honestly. You *must* be mistaken. I
> hope.
copy-on-write (COW) isn't all that bad. it's really pretty clever.
many operating systems use COW in other contexts, e.g., linux in
fork(2) does copy-on-write for memory pages.
as it is now, rename or move (within the parition) are cheap since the
file doesn't move about, just the directory entry is altered. with
COW, copies are just as cheap. when you copy a file, the actual
copying is merely delayed until you actually alter the data.
if statistics or planned filesystem usage indicate that many files are
copied but never changed, this makes good sense.
COW does have one side effect, since the data isn't copied until
later, you can 1) reserve space so that the delay copy will suceed or
2) don't reserve space so that you can superload your filesystem. in
case 2), weird things can happen since it's hard to know how much
diskspace you really have left.
Giuliano Colla
[snip]
>
> the common theme of microsoft programs is the dearth of nested
> structure. billg is an old basic hack. basic, back in the '70s, had
> no subroutines worth the name (well, there was gosub but you couldn't
> pass arguments nor hide local variables &c). look at, e.g., ms-word.
> you can't be doing a list. push the state, start up a new
> environment and then pop back out to the list environment. there's no
> nesting; it's all flat. much of microsoft is like this.
>
> it's like basic. basic is a fantastic language for writing 10-20 line
> programs. it's *horrible* at anything over 100. thus microsoft
> suckers you with "ease of novice" and then makes you suffer eternally
> with "pain of usage".
>
Well, this explains a lot. A basic hack can only turn out the crap M$
calls software.
Back in the 70's Klaus Wirth produced Pascal as a tool to teach
programming to his students. If you compare Basic with Pascal you have
the distance between M$ software and software.
[snip]
>
> i don't think the hidden flag is good or bad.
>
> in unix the hidden policy is set by using a certain naming
> convention. in ms-dos you can "hide" an arbitrary file using a bit.
> this particular point isn't an advantage of unix. imho ms-dos does
> the hidden file better.
The hidden file idea is not to clutter directory listing with entries
you seldom need to access directly. Using a naming convention allows ls
(or whatever) to decide whether to show or not a file name just from the
name itself. As hidden files are meant to be accessed only by other
programs, and not by the user, their names are "well known", and cannot
be arbitrary.
>
> on the other hand, a minor unix annoyance of mine is the profusion of
> dot-files in my home directory. i'd prefer to have an ~/etc directory
> (in my home) and have the config file names not begin with a dot.
The ~/etc directory seems to me a good idea. However I keep in my home
directory just directories for my different things, so I'm not really
annoyed by dot-files.
[snip]
>
> unix doesn't do a particular good job at network file systems either.
> the unix API assumes that the kernel is in complete control and hence
> some awful kludges are used to make stuff like NFS work. i'm not sure
> MS systems are any better off though.
I don't believe that Unix is perfect. Quite a number of things should be
reconsidered and improved. However just this morning I had the
opportunity to make a comparison. It is just an anecdote but may have
some value. On saturday morning we perform the backup on cartridge tapes
of our workstations, from the server. I have on my desk at the moment
two PC's. One of them is Windows 95, the other is Linux. Usually I don't
work on them during backup, to have a "clean" condition, but this
morning I really needed to do some work. Only I was badly synchronized
so I happened to need a box exactly when it was being backed up.
On the Linux box, I connected to Internet, and I got and sent some
urgent mail. On the Windows box I needed a Word document,
but I was unable to access it until the backup was over. Just opening
the folder required such a long time (some 15 seconds) that I didn't
dare to attempt opening the document. Apparently network services lock
almost completely a Windows box.
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
T. Max Devlin
>"T. Max Devlin" wrote:
[...]
Oh, good! ;-)
>as it is
>basically an "egg and chicken" problem. Today incompetence and
>anti-competitiveness are so strongly established that it's almost
>impossible to determine what came first.
Monopolization came first; that can be established pretty easily, since
'making bad technology' is hardly a reason for someone to start a
business.
>It is my opinion that incompetence came first, because in order to start
>anti-competitive policies you must have established a minimum base.
Yes, but that 'minimum base' that started monopolization was
anti-competitive practices in a *new market*, which barely even existed
before the monopoly. I'm referring to the MS-BASIC scenario, where MS
used many of the same tricks they pull today to 'convince' microcomputer
manufacturers to put a licensed copy of Microsoft software on (in) every
computer they sell. Microsoft bought the code from someone who still
did things 'the old way'; a company would *buy* the BASIC code, and then
own it and use it in all their computers. Billy Boy 'innovated' the
idea of forcing them to pay for every single copy, by preventing anyone
else, through threat of lawsuit for copyright infringement, producing
any other BASIC, once they'd bought their BASIC code, copyrighted it,
and wrapped it in a trade secret license.
>So
>if you start with good software which becomes crappy as time goes by you
>may think that anti-competitiveness is taking over competence. If
>software is crappy from the very beginning (take the first BIOS) you're
>led to conclude that incompetence is the starting point. However, to
>avoid the endless debate I propose you a contest: each time we find
>something which can prove my point (i.e. useless crappyness) it's one
>point for me. Each time we find something which may prove your point
>(i.e. crappyness coming from anti-competitive goals only) it's one point
>for you. If at the end of the contest MS is reduced to an also run in
>the software arena we both win. If not we both loose!
You forget; it is a chicken-and-egg problem (not the way you meant,
but...) Its not possible to distinguish objectively between 'useless
crappyiness' and 'anti-competitive crappiness'. The ability to identify
which is in effect is a condition of the observation, not an inherent
quality which can be detected in effect. Of course, there are always
easy calls, but none which are conclusive, even then. Besides which,
I've got eight years of practice on you, so I'm not sure if you want to
use a point system. ;-)
Its like the way Microsoft droids can always 'reverse engineer' why
there is no commercial alternative to Windows. Without a clear
specification of intent, it requires judgement as well as reason to
understand the issues.
T. Max Devlin
>The choice of MS clutters in any case a directory listing with two
>useless entries (one point for me in the contest), but makes it harder
>for users to gain a better knowledge of what is in a directory (one
>point for you).
Oh, so that's the way you plan to do it, eh? Let me try:
Putting the Control Panel in a sub-menu of the Start menu groups it with
some similar entries (point for you), but makes it invisible to the
novice and belies its importance (one point for me).
Is that it? Bear in mind, I'm not good at this type of thing, as I have
trouble limiting examination to just one aspect of something; to me, the
whole Start menu and everything about it is crap (one point for you)
that essentially destroys the paradigm of a desktop control mechanism
(one point for me). But maybe I'll get the hang of it.
T. Max Devlin
Oh, you mean that rather than actually being links, a powerful
capability of Unix that Windows doesn't have, this is actually a
redesign of the Briefcase function of Win95. That would be a point for
me, or maybe even two: Briefcase was used to kill LapLink's market, and
this new feature is a FUDish tactic to defuse the recognition of
Windows' lack of symbolic and hard links.
I got a twofer! You're behind, Guiliano! :-)
T. Max Devlin
>T. Max Devlin <tm...@nbn.net> writes:
[...]
>if statistics or planned filesystem usage indicate that many files are
>copied but never changed, this makes good sense.
Which is why it sucks, because neither of these are done or are
appropriate in a general purpose desktop system.
>COW does have one side effect, since the data isn't copied until
>later, you can 1) reserve space so that the delay copy will suceed or
>2) don't reserve space so that you can superload your filesystem. in
>case 2), weird things can happen since it's hard to know how much
>diskspace you really have left.
As long as its an invisible and infallible part of the filesystem, I
could care less. It was brought up under the guise of 'something like
links'; perhaps its merely being misconstrued (most probably because
Microsoft would like everyone to misconstrue it thusly.)
Maybe a point for G then, but definitely a point for me.
Peter Bertok
This whole thread seems just a tad off-topic, but anyway:
o Copy-on-write semantics are also used in the popular std::string and
CString data types used in most windows programming.
o AFAIK, Win2k supports a variety of link types. There are the "shortcuts",
which don't really match with anything used in the Unix world. There are
also hard links, like the Distributed File system, and you can also make
virtual directories/files which are generated by an EXE or DLL on demand,
which is how encryption and compression is done.
"Johan Kullstam" <kull...@ne.mediaone.net> wrote in message
news:m21yytv...@euler.axel.nom...
Johan Kullstam
> Johan Kullstam wrote:
>
> [snip]
>
> >
> > the common theme of microsoft programs is the dearth of nested
> > structure. billg is an old basic hack. basic, back in the '70s, had
> > no subroutines worth the name (well, there was gosub but you couldn't
> > pass arguments nor hide local variables &c). look at, e.g., ms-word.
> > you can't be doing a list. push the state, start up a new
> > environment and then pop back out to the list environment. there's no
> > nesting; it's all flat. much of microsoft is like this.
> >
> > it's like basic. basic is a fantastic language for writing 10-20 line
> > programs. it's *horrible* at anything over 100. thus microsoft
> > suckers you with "ease of novice" and then makes you suffer eternally
> > with "pain of usage".
> >
> Well, this explains a lot. A basic hack can only turn out the crap M$
> calls software.
> Back in the 70's Klaus Wirth produced Pascal as a tool to teach
> programming to his students. If you compare Basic with Pascal you have
> the distance between M$ software and software.
pascal is a demo/toy language. i like C and common-lisp.
> > i don't think the hidden flag is good or bad.
> >
> > in unix the hidden policy is set by using a certain naming
> > convention. in ms-dos you can "hide" an arbitrary file using a bit.
> > this particular point isn't an advantage of unix. imho ms-dos does
> > the hidden file better.
>
> The hidden file idea is not to clutter directory listing with entries
> you seldom need to access directly. Using a naming convention allows ls
> (or whatever) to decide whether to show or not a file name just from the
> name itself. As hidden files are meant to be accessed only by other
> programs, and not by the user, their names are "well known", and cannot
> be arbitrary.
yes, but to "hide" an arbitrary file, you have to name it according to
the convention. you can't "hide", e.g., "/tmp/foo.txt" -- its name is
wrong. thus, you as a user, can't mark stuff as uninteresting since
the application that wrote the file might not be able to find it again.
> > on the other hand, a minor unix annoyance of mine is the profusion of
> > dot-files in my home directory. i'd prefer to have an ~/etc directory
> > (in my home) and have the config file names not begin with a dot.
>
> The ~/etc directory seems to me a good idea. However I keep in my home
> directory just directories for my different things, so I'm not really
> annoyed by dot-files.
at first i thought hidden files were cool. now i think they just
suck. if you want to not see stuff, shove it into a directory. if it
weren't for every application dumping a ton of dot-file garbage in my
home, i'd have aliased ls to ls -a long ago.
> [snip]
> >
> > unix doesn't do a particular good job at network file systems either.
> > the unix API assumes that the kernel is in complete control and hence
> > some awful kludges are used to make stuff like NFS work. i'm not sure
> > MS systems are any better off though.
>
> I don't believe that Unix is perfect. Quite a number of things should be
> reconsidered and improved. However just this morning I had the
> opportunity to make a comparison.
sure!
> It is just an anecdote but may have
> some value. On saturday morning we perform the backup on cartridge tapes
> of our workstations, from the server. I have on my desk at the moment
> two PC's. One of them is Windows 95, the other is Linux.
argh. i was hoping for a comparison between a unix and a *good* OS
like, e.g., plan9. i hear plan9 is very good at networks and such.
Ville Niemi
have this underlying assumption that everybody else is as good at reading
between lines as I am...
I'll try to mend my writing style in the future.
Ville
Ville Niemi
> >copied but never changed, this makes good sense.
>
> Which is why it sucks, because neither of these are done or are
> appropriate in a general purpose desktop system.
>
Not approprate, but it is done. Many installers insist on cluttering your
harddrive with components you already have. Sometimes they just partially
overwrite your existing, propably more up-to date version. Sometimes they
install a duplicate in another directory. M$ calls these components
redistributables and for some reason the installers never seem to be able to
figure out whether you already have them or not.
Recap: Windows systems usually have multiple (unnecessary) copies of some
components on harddrive.
Ville
T. Max Devlin
All you've done, at best, is substantiate that, even when it is done, it
is still inappropriate, because it cannot be done correctly. What
you're talking about, though, has nothing to do with 'statistics or
planned filesystem usage', but simply a side-effect of 'DLL Hell'.
Installers aren't supposed to 'figure out whether you already have
them', at least they don't *have* to, because Windows lacks a usable
shared-library versioning function. It has a 'version function', but
its not practical or supported. The program developer can never be sure
if Microsoft changed a newer version of a 'redistributable' in some way
which would prevent their software from working correctly, so they have
to (or want to) ensure that the right version is available.
In some respects, the equivalent of symbolic links to various library
versions which Unix uses does have a ready equivalent in Windows; the
DLLs from the program working directory are used first, then the Windows
directory, and finally any PATH directory, in order. This alone is not
enough to save us from 'DLL Hell', but it does enable us to have
multiple copies of some components on harddrive, which is sometimes
necessary.
My point was that if you're going to make assumptions about how a
computer is going to be used, then it isn't very 'general purpose'.
Ville Niemi
> is still inappropriate, because it cannot be done correctly. What
> you're talking about, though, has nothing to do with 'statistics or
> planned filesystem usage', but simply a side-effect of 'DLL Hell'.
> Installers aren't supposed to 'figure out whether you already have
> them', at least they don't *have* to, because Windows lacks a usable
> shared-library versioning function. It has a 'version function', but
> its not practical or supported. The program developer can never be sure
> if Microsoft changed a newer version of a 'redistributable' in some way
> which would prevent their software from working correctly, so they have
> to (or want to) ensure that the right version is available.
Yes, that was what I was trying to 'substantiate'. I said it is
inappropriate. And I wasn't blaming the developers. And I have crashed
applications by updating something they rely on, so I know Microsoft sucks
by personal experience.
> In some respects, the equivalent of symbolic links to various library
> versions which Unix uses does have a ready equivalent in Windows; the
> DLLs from the program working directory are used first, then the Windows
> directory, and finally any PATH directory, in order. This alone is not
> enough to save us from 'DLL Hell', but it does enable us to have
> multiple copies of some components on harddrive, which is sometimes
> necessary.
Also knew that... I'd love to disagree, get an argument with you and watch
if my belief in efficient installation procedures would stop my Win98SE from
crashing predictably when you change screen mode... But I fixed it already.
Do you think blind belief would work in getting Win more stable? Seems to
work for some people who write here...
> My point was that if you're going to make assumptions about how a
> computer is going to be used, then it isn't very 'general purpose'.
True, but everybody makes those assumptions anyway. Unix has an edge an
Windows because over time it has been improved by many people with many
different assumptions. Mac is better than Windows because Apple had no
reason to break the assumptions made by developers in other companies. And
yes I know new OS versions break old applications on Mac too. But Apple
doesn't do it to monopolize the application market, Microsoft does.
What was I saying... Right... Good point, Max! Keep it up! Or Down...
Ville
T. Max Devlin
>Do you think blind belief would work in getting Win more stable? Seems to
>work for some people who write here...
As far as I can tell, its the only method that works at all to begin
with. Either blind faith or dumb luck; I'm actually at the point where
I don't think the 'but its been working fine here for...' have any real
value.
>> My point was that if you're going to make assumptions about how a
>> computer is going to be used, then it isn't very 'general purpose'.
>
>True, but everybody makes those assumptions anyway. Unix has an edge an
>Windows because over time it has been improved by many people with many
>different assumptions. Mac is better than Windows because Apple had no
>reason to break the assumptions made by developers in other companies. And
>yes I know new OS versions break old applications on Mac too. But Apple
>doesn't do it to monopolize the application market, Microsoft does.
Well, a presumption that a system will be used for the purpose for which
it is designed is not the same as an assumption that a system will only
be used a particular way.
Thanks for your time. Hope it helps.
Johan Kullstam
> Said Johan Kullstam in alt.destroy.microsoft;
> >T. Max Devlin <tm...@nbn.net> writes:
> [...]
> >if statistics or planned filesystem usage indicate that many files are
> >copied but never changed, this makes good sense.
>
> Which is why it sucks, because neither of these are done or are
> appropriate in a general purpose desktop system.
giving this a little more thought, here's an idea. say you are using
the explorer to look at files and decide to copy a directory tree.
without COW, it'd take a long time. with COW, it could be as fast as
you can create and populate the directory tree. in a smart system,
you could fire up a background task to handle copying the files. COW
would make sure that if your application accessed the file faster than
the background copier got around to it, your file would actually get
copied.
i admit that it's likely to be more trouble than its worth as the
system is complex and that gives bugs a lot of room within which to
hide. computationally it's not much of a punishment. the
math/bookkeeping is slight and the disk is *so* much slower than a
cpu.
> >COW does have one side effect, since the data isn't copied until
> >later, you can 1) reserve space so that the delay copy will suceed or
> >2) don't reserve space so that you can superload your filesystem. in
> >case 2), weird things can happen since it's hard to know how much
> >diskspace you really have left.
>
> As long as its an invisible and infallible part of the filesystem, I
> could care less.
that's a big if. microsoft's track record with making complex systems
infallible leaves something to be desired.
> It was brought up under the guise of 'something like
> links'; perhaps its merely being misconstrued (most probably because
> Microsoft would like everyone to misconstrue it thusly.)
>
> Maybe a point for G then, but definitely a point for me.
i am not sure it's a question of accumulating points.
Elf Sternberg
"Peter Bertok" <pe...@bertok.com> writes:
>o Copy-on-write semantics are also used in the popular std::string and
>CString data types used in most windows programming.
It has nothing to do with "Windows"; many C++ implementations of
std::string do a copy-on-write. One of the more bizarre
implementations, "sgi::rope," doesn't even do that; it breaks the string
into segments and on a write such as an insert inserts into a tree a
pointer to the new segment. It's a very fast string manipulation, but
it's not very elegant for things like regexps.
Elf
--
Elf M. Sternberg, rational romantic mystical cynical idealist
http://www.halcyon.com/elf/
"The purpose of writing is to inflate weak ideas, obscure pure
reasoning, and inhibit clarity. With a little pratice, writing can
be an intimidating and impenetrable fog!" - Bill Watterson's Calvin.
Ville Niemi
> As far as I can tell, its the only method that works at all to begin
> with. Either blind faith or dumb luck; I'm actually at the point where
> I don't think the 'but its been working fine here for...' have any real
> value.
You are getting bitter that's all. For them it has value.
> Well, a presumption that a system will be used for the purpose for which
> it is designed is not the same as an assumption that a system will only
> be used a particular way.
True, but sadly Microsoft doesn't seem to agree with us. For Microsoft it is
enough if system works in general and the users can work around the rest.
For some people it really seems to be enough. I suppose Microsoft's
assumption is not about use, but users.
'Our products will be used by people who either
1. Don't need anything solid (Most Win9x homeusers don't)
2. Don't know any better (seems to include some 'professionals')
3. Don't have any real choice (the monopolizing)
4. Find out too late to ask for refund'
You know, their assumptions seem to have worked pretty well (so far), I
suppose designing for general users instead of general purpose does give you
some benefits. What worries me is that some developers (or the management
types running the development companies), will copy this approach. Hasn't
software reliability been going down? Even not counting Microsoft products,
that is.
Ville
Damien
If the installers knew you had an identical copy of those components,
they wouldn't need to make another copy. Since they obviously don't
know that, how are they going to know to make their copy a link to the
original copy?
Damien
Johan Kullstam <kull...@ne.mediaone.net> wrote:
| T. Max Devlin <tm...@nbn.net> writes:
|
| > Said Johan Kullstam in alt.destroy.microsoft;
| > >T. Max Devlin <tm...@nbn.net> writes:
| > [...]
| > >if statistics or planned filesystem usage indicate that many files are
| > >copied but never changed, this makes good sense.
| >
| > Which is why it sucks, because neither of these are done or are
| > appropriate in a general purpose desktop system.
|
| giving this a little more thought, here's an idea. say you are using
| the explorer to look at files and decide to copy a directory tree.
| without COW, it'd take a long time. with COW, it could be as fast as
| you can create and populate the directory tree. in a smart system,
| you could fire up a background task to handle copying the files. COW
| would make sure that if your application accessed the file faster than
| the background copier got around to it, your file would actually get
| copied.
|
| i admit that it's likely to be more trouble than its worth as the
| system is complex and that gives bugs a lot of room within which to
| hide. computationally it's not much of a punishment. the
| math/bookkeeping is slight and the disk is *so* much slower than a
| cpu.
The same benifits could be better achieved by treating files as
streams. You could copy a 12 GB file from one file system to another,
and begin working on the copy right away. The only time this would be
a problem is if whatever you are doing begins to out run your file
system in throughput, but with both read ahead and write-behind
caching it normally isn't a problem.
A disadvantage of COW would be long write times.
cp /really/large/file /other/really/large/file
Would be instantaneous, but then
cat " " >> /other/really/large/file
would take an unreasonable amount of time.
--
cd /pub
more beer
Johan Kullstam
ok, now a background process automatically starts and begins copying
the file. note that you can read it immediately. you'd only need to
wait if you need to modify that file.
i guess this wouldn't be a pure COW. i have no idea if MS does it
this way (i'd guess not).
> Would be instantaneous, but then
>
> cat " " >> /other/really/large/file
>
> would take an unreasonable amount of time.
only if that background copier hasn't finished.
T. Max Devlin
Windows doesn't use 'a link', and the installers *can* know that there's
already an identical DLL. They *don't* need to make another copy
(according to the standard logic, anyway, though I've explained why its
often a good idea) but they still do. That's what he was complaining
about.
T. Max Devlin
>> with. Either blind faith or dumb luck; I'm actually at the point where
>> I don't think the 'but its been working fine here for...' have any real
>> value.
>
>You are getting bitter that's all. For them it has value.
I'm bitter because I know how much more value it would have if it wasn't
crap. Yes, even crappy software has some value, but only in comparison
to a lack of alternatives.
>> Well, a presumption that a system will be used for the purpose for which
>> it is designed is not the same as an assumption that a system will only
>> be used a particular way.
>
>True, but sadly Microsoft doesn't seem to agree with us. For Microsoft it is
>enough if system works in general and the users can work around the rest.
>For some people it really seems to be enough. I suppose Microsoft's
>assumption is not about use, but users.
That's the problem; for some people it really seems to be enough.
'Seems to' being the operative words; it isn't enough. They paid for
much much more, especially when you consider the cost of implementation,
which gets more outrageous with Microsoft every day.
>'Our products will be used by people who either
[...]
>3. Don't have any real choice (the monopolizing)
[...]
>You know, their assumptions seem to have worked pretty well (so far), I
>suppose designing for general users instead of general purpose does give you
>some benefits.
You underestimate the amount of anti-competitive activity that
Microsoft's had to do in order to make this seem attractive.
>What worries me is that some developers (or the management
>types running the development companies), will copy this approach. Hasn't
>software reliability been going down? Even not counting Microsoft products,
>that is.
Yes, that is what worries me, too. Since monopoly software is used by
'everybody', but is pure crap (by this point), then its OK to write
crappy software. A lot of people actually think that computers are
supposed to be unreliable, and just accept that as the way things work.
The apparent stupidity of many software products, some very far afield
from the monopoly, can only be explained, I think, by lack of
competition caused *by* the monopoly; people are just used to inferior
products. Nobody with an ounce of sense would do some of these things,
I swear.
Giuliano Colla
[snip]
>
> pascal is a demo/toy language. i like C and common-lisp.
>
Ever tried to develop a large application with object Pascal
(Borland's Delphi flavor), and compare development time,
robustness and efficiency with C++ implementation?
[snip]
>
> yes, but to "hide" an arbitrary file, you have to name it according to
> the convention. you can't "hide", e.g., "/tmp/foo.txt" -- its name is
> wrong. thus, you as a user, can't mark stuff as uninteresting since
> the application that wrote the file might not be able to find it again.
Why burden the whole system with a very particular need?
What do you gain by hiding an ordinary file? If it was meant
to be hidden then you name it accordingly, if it wasn't then
why take the trouble?
[snip]
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
Bologna (Zona Industriale Roveri)
Tel. 051 53.46.92 - 0335 610.43.35
Fax 051 53.49.89
Giuliano Colla
[snip]
>
> Yes, but that 'minimum base' that started monopolization was
> anti-competitive practices in a *new market*, which barely even existed
> before the monopoly. I'm referring to the MS-BASIC scenario, where MS
> used many of the same tricks they pull today to 'convince' microcomputer
> manufacturers to put a licensed copy of Microsoft software on (in) every
> computer they sell. Microsoft bought the code from someone who still
> did things 'the old way'; a company would *buy* the BASIC code, and then
> own it and use it in all their computers. Billy Boy 'innovated' the
> idea of forcing them to pay for every single copy, by preventing anyone
> else, through threat of lawsuit for copyright infringement, producing
> any other BASIC, once they'd bought their BASIC code, copyrighted it,
> and wrapped it in a trade secret license.
[snip]
FOUND! I knew that going on hammering I would have found the
missing link, the Rosetta stone, etc.
What I was missing is that MS started BUYING code from the
very beginning. At that time I couldn't care less where a
Basic interpreter was coming from.
This sheds a new light on the whole thing, and I must
painfully admit that it's possible that you're right and I'm
wrong. The starting point might have been monopolizing and
not incompetence.
As an afterthought: if they had to buy software they didn't
have the competence to write it!......
However, I arose the question for two reasons. The first one
was to understand why you so vehemently claimed that
monopolizing was the very origin of everything. As I had a
different notion I wanted to understand why.
The second was to understand what's going to happen.
Assuming that something will happen (split, court control
over activities, OEM pressure) that will force MS to
compete, do they have the technical skills to do it?
There is a subtle, impalpable thing which is "corporate
philosophy", permeating any company, and it's one of the
most difficult thing to change. Once a "corporate
philosophy" has been established it appears to die only when
the last stone of the last building has fallen. I read about
it on a english book which was very popular in the 60's,
whose title now escapes me. It was "Someone's" Law, and it
was about public and corporate bureaucracy. It claimed that
"corporate philosophy" is kept in the very walls of the
building, and if a company starts declining you can't start
a new company in the same building, because it will decline
the same way, and the only solution is to destroy the
building and lay salt over its ruins. It appears a bit
extreme, but I started keeping track, and I found that
there's more truth than one would say.
One blatant example I found is with Fairchild semiconductor.
They were a very brilliant company, they produced the first
Operational Amplifier IC, but they had a peculiarity: their
technical manuals were such a mess that if you didn't know
the exact part number of what you were looking for you'd
never find it. They opened a factory in Italy, which
published technical manuals in Italian, and which were, of
course organized the same way. Then the Italian factory was
dismissed, and was taken over by Italians and was called
SGS. It changed from the original production lines to
different, more profitable ones, in consumer and industrial
markets, originated a number of successful components, but
technical manuals were a terrible mess. A few years ago they
merged with french Thomson to make a new company called ST,
and they're now among the largest IC manufacturers in the
world. They're among the big manufacturers of IC for
cellular phones, they're growing and show high profits,
while Fairchild Semiconductors doesn't exist anymore since a
long time, but their technical manuals are always the same
old mess!
On the opposite side, the HP Vectra computer sitting on my
desk appears to follow the same lines of design and
engineering quality which I met the first time I saw an HP
oscilloscope some 35 years ago.
Sorry for the digression, but I wanted to make clear my
point. Now, given the current MS "corporate philosophy", how
can one foresee that they'll bee capable:
a) not to resort to anti-competitive policies
b) to turn out some decent product?
Johan Kullstam
> Johan Kullstam wrote:
> [snip]
>
> >
> > pascal is a demo/toy language. i like C and common-lisp.
> >
>
> Ever tried to develop a large application with object Pascal
that's not pascal! standard pascal is practically unusable. i do
like a lot of the ideas of pascal. i just apply them to my C coding.
> (Borland's Delphi flavor), and compare development time,
> robustness and efficiency with C++ implementation?
i said C. i purposely omitted C++. i hate C++.
ever tried to code up a big project and experience the quick coding,
robustness, and efficiency of a good common-lisp?
> [snip]
> >
> > yes, but to "hide" an arbitrary file, you have to name it according to
> > the convention. you can't "hide", e.g., "/tmp/foo.txt" -- its name is
> > wrong. thus, you as a user, can't mark stuff as uninteresting since
> > the application that wrote the file might not be able to find it again.
>
> Why burden the whole system with a very particular need?
> What do you gain by hiding an ordinary file? If it was meant
> to be hidden then you name it accordingly, if it wasn't then
> why take the trouble?
sometimes you don't do the naming. the application which expects it
to be there names it. i guess you can recompile *every* application.
imho no hidden files at all would be an even better solution! i'd
like to put stuff in a ~/etc with *no* hidden files anywhere instead
of littering your home with dot-files, but it isn't practical.
Ville Niemi
Thanks for the digression! a) That's why I believe they must be split to
several parts incapable of using traditional MS policies. b) GOOD point.
Ville
Bob Lyday
> >
> There is a subtle, impalpable thing which is "corporate
> philosophy", permeating any company, and it's one of the
> most difficult thing to change. Once a "corporate
> philosophy" has been established it appears to die only when
> the last stone of the last building has fallen.
I'm not so sure about that. For one, IBM's corporate philosophy has
dramatically changed. For decades, IBM was one of the most
anti-competitive companies out there. They have been sued 3 times for
antitrust violations, and the government won each time. And IBM paid
dearly for each one. The last time was in 1990. I think IBM's
corporate culture has changed so much that they no longer engage in
anti-competitive behavior. And IBM is one of the most successful
companies on Earth.
However, changing MS will not be so easy.
As a sidenote, I would like to point out that it is not necessary to
use anticompetitive tactics to gain or maintain a monopoly. As an
example, look at Palm. Palm definitely has a monopoly in the handheld
market (84%), yet they have never engaged in any anticompetitive
tactics. I would gladly buy and use a Palm but I do not enjoy being
forced to use MS stuff at all. If MS was a decent corporation like
Palm, I would happily use their products in a second.
--
Bob
Microsoft.com corrupt! Boot Chairman Bill? (Y/Y)
Remove "diespammersdie" to reply.
Giuliano Colla
>
> Giuliano Colla wrote:
> > >
> > There is a subtle, impalpable thing which is "corporate
> > philosophy", permeating any company, and it's one of the
> > most difficult thing to change. Once a "corporate
> > philosophy" has been established it appears to die only when
> > the last stone of the last building has fallen.
>
> I'm not so sure about that. For one, IBM's corporate philosophy has
> dramatically changed. For decades, IBM was one of the most
> anti-competitive companies out there. They have been sued 3 times for
> antitrust violations, and the government won each time. And IBM paid
> dearly for each one. The last time was in 1990. I think IBM's
> corporate culture has changed so much that they no longer engage in
> anti-competitive behavior. And IBM is one of the most successful
> companies on Earth.
You give me some hope...
>
> However, changing MS will not be so easy.
And you take it away with next line!
>
> As a sidenote, I would like to point out that it is not necessary to
> use anticompetitive tactics to gain or maintain a monopoly. As an
> example, look at Palm. Palm definitely has a monopoly in the handheld
> market (84%), yet they have never engaged in any anticompetitive
> tactics. I would gladly buy and use a Palm but I do not enjoy being
> forced to use MS stuff at all. If MS was a decent corporation like
> Palm, I would happily use their products in a second.
If you don't resort to anti competitive policies and conquer a large
share of the market, it only means that either you have an overwhelming
technical superiority, or an exceptionally good selling strategy. You're
not killing competition, you're winning it. If you win a 100 yd race
because you run faster, you get a gold medal, if you win it because you
shot your opponents you're handcuffed and taken to jail. The same should
apply to BG and his accompl.. sorry collaborators.
If MS was a decent corporation, they'd turn out decent products and I
too would be very glad to use them, provided they fitted my needs.
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
Giuliano Colla
>
> Giuliano Colla <cop...@copeca.dsnet.it> writes:
>
> > Johan Kullstam wrote:
> > [snip]
> >
> > >
> > > pascal is a demo/toy language. i like C and common-lisp.
> > >
> >
> > Ever tried to develop a large application with object Pascal
>
> that's not pascal! standard pascal is practically unusable. i do
> like a lot of the ideas of pascal. i just apply them to my C coding.
>
> > (Borland's Delphi flavor), and compare development time,
> > robustness and efficiency with C++ implementation?
>
> i said C. i purposely omitted C++. i hate C++.
Well, object pascal gives you all the good things of object programming
without all the stupid things of C++.
>
> ever tried to code up a big project and experience the quick coding,
> robustness, and efficiency of a good common-lisp?
No, but if you're so positive about it I promise that I'll look on it!
>
> > [snip]
> > >
> > > yes, but to "hide" an arbitrary file, you have to name it according to
> > > the convention. you can't "hide", e.g., "/tmp/foo.txt" -- its name is
> > > wrong. thus, you as a user, can't mark stuff as uninteresting since
> > > the application that wrote the file might not be able to find it again.
> >
> > Why burden the whole system with a very particular need?
> > What do you gain by hiding an ordinary file? If it was meant
> > to be hidden then you name it accordingly, if it wasn't then
> > why take the trouble?
>
> sometimes you don't do the naming. the application which expects it
> to be there names it. i guess you can recompile *every* application.
>
> imho no hidden files at all would be an even better solution! i'd
> like to put stuff in a ~/etc with *no* hidden files anywhere instead
> of littering your home with dot-files, but it isn't practical.
>
I don't follow you very well. On one side you want to hide something
which was not intended, on the other you prefer no hidden files at all.
Maybe your needs are too different from mine to make a coherent
discussion. However kde desktop is handled something like you propose:
all hidden stuff goes into a .kde directory, which is the only dot-file
cluttering your home directory, until you install non-kde apps!
--------
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
40139 Bologna (Italy)
Johan Kullstam
> Johan Kullstam wrote:
> > ever tried to code up a big project and experience the quick coding,
> > robustness, and efficiency of a good common-lisp?
>
> No, but if you're so positive about it I promise that I'll look on
> it!
give it a shot. lisp is very weird at first, but will grow on you.
> > sometimes you don't do the naming. the application which expects it
> > to be there names it. i guess you can recompile *every* application.
> >
> > imho no hidden files at all would be an even better solution! i'd
> > like to put stuff in a ~/etc with *no* hidden files anywhere instead
> > of littering your home with dot-files, but it isn't practical.
> >
>
> I don't follow you very well. On one side you want to hide something
> which was not intended, on the other you prefer no hidden files at
> all.
yes, sorry. i am saying two things.
1) i don't like hidden files at all. i'd rather everything be in the
open. if you want to hide some clutter, well, that's what
directories are for.
2) if you *have* to do the hidden file thing, then i prefer a bit in
the directory entry as opposed to a naming convention.
> Maybe your needs are too different from mine to make a coherent
> discussion. However kde desktop is handled something like you propose:
> all hidden stuff goes into a .kde directory, which is the only dot-file
> cluttering your home directory, until you install non-kde apps!
i still want an ~/etc directory. if KDE wants more than one file for
its config, then have it make a ~/etc/kde/... heiriarchy. this way
all config is nicely stuffed into a configuration directory and there
isn't the bother of hidden files. once i thought hiding files was
cool, but i've come to be less and less enamoured of the concept as
time goes on.
T. Max Devlin
>cool, but i've come to be less and less enamoured of the concept as
>time goes on.
I think that stands on its own. I share your sentiment, Johan, to say
the least.
Thanks for your time. Hope it helps.
T. Max Devlin
>> >
>> There is a subtle, impalpable thing which is "corporate
>> philosophy", permeating any company, and it's one of the
>> most difficult thing to change. Once a "corporate
>> philosophy" has been established it appears to die only when
>> the last stone of the last building has fallen.
>
>I'm not so sure about that. For one, IBM's corporate philosophy has
>dramatically changed. For decades, IBM was one of the most
>anti-competitive companies out there. They have been sued 3 times for
>antitrust violations, and the government won each time. And IBM paid
>dearly for each one. The last time was in 1990. I think IBM's
>corporate culture has changed so much that they no longer engage in
>anti-competitive behavior. And IBM is one of the most successful
>companies on Earth.
I'm not so sure of that. They may have just changed their pattern.
Recently, IBM made an 'implicit pact' with Cisco, in which they all but
withdrew from the 'internetworking equipment' market. They decided to
concentrate on the host business, which is there forte, but the whole
thing left a sour taste in my mouth. Especially considering all the
smaller vendors both have swallowed up in the last few years.
>However, changing MS will not be so easy.
Considering 'MS' seems to be little more than the megalomaniacal fantasy
of the world's most successful monopolist, in the end, I think its
really quiet possible that it will prove to be impossible to change MS.
Hence the name of the newsgroup. If Microsoft survives the loss of
their monopoly, I think it might well be in name only.
>As a sidenote, I would like to point out that it is not necessary to
>use anticompetitive tactics to gain or maintain a monopoly. As an
>example, look at Palm. Palm definitely has a monopoly in the handheld
>market (84%), yet they have never engaged in any anticompetitive
>tactics.
Palm has a substantial market share. Without a doubt, they hold a great
deal of market power; one might say they dominate the market.
But they do not monopolize, AFAIK. They do not have a 'monopoly' in the
handheld market; they merely have a superior product. My private
opinion is that they would not be so dominant, in fact, if Microsoft
weren't monopolizing in a related field. Microsoft's own attempts to
fend off any threat that Palm might present suppress and inhibit
competition in the handheld market. (As does the continuing attempts to
monopolize exhibited by actors in the cell phone market, which shows
obvious affinities with handhelds.)
It is possible to gain large market share through superior product,
business acumen, or accident of history, but to be a 'monopoly', a
company must have *monopoly power*. This can _only_ be gained,
according to the tenets of free markets, by anti-competitive actions.
>I would gladly buy and use a Palm but I do not enjoy being
>forced to use MS stuff at all. If MS was a decent corporation like
>Palm, I would happily use their products in a second.
Indeed; if Microsoft was not monopolizing, it is certainly possible that
their software wouldn't be crap.
T. Max Devlin
[...]
>If you don't resort to anti competitive policies and conquer a large
>share of the market, it only means that either you have an overwhelming
>technical superiority, or an exceptionally good selling strategy.
I have to ask, Giuliano; did you derive this from the oft-quoted US
Court decision in the Grinnell case?
""The offense of monopoly power under § 2 of the Sherman Act has two
elements: (1) the possession of monopoly power in the relevant market
and (2) the willful acquisition or maintenance that power as
distinguished from growth or development as a consequence of a superior
product, business acumen, or historic accident."
The parallel between your 'technical superiority, or... good selling
strategy' and "superior product, business acumen" seems obvious, and I
was wondering if it was convergent or merely derivative?
>You're
>not killing competition, you're winning it. If you win a 100 yd race
>because you run faster, you get a gold medal, if you win it because you
>shot your opponents you're handcuffed and taken to jail. The same should
>apply to BG and his accompl.. sorry collaborators.
>If MS was a decent corporation, they'd turn out decent products and I
>too would be very glad to use them, provided they fitted my needs.
Well said.
Giuliano Colla
>
> Said Giuliano Colla in alt.destroy.microsoft;
> [...]
> >If you don't resort to anti competitive policies and conquer a large
> >share of the market, it only means that either you have an overwhelming
> >technical superiority, or an exceptionally good selling strategy.
>
> I have to ask, Giuliano; did you derive this from the oft-quoted US
> Court decision in the Grinnell case?
>
> ""The offense of monopoly power under § 2 of the Sherman Act has two
> elements: (1) the possession of monopoly power in the relevant market
> and (2) the willful acquisition or maintenance that power as
> distinguished from growth or development as a consequence of a superior
> product, business acumen, or historic accident."
>
> The parallel between your 'technical superiority, or... good selling
> strategy' and "superior product, business acumen" seems obvious, and I
> was wondering if it was convergent or merely derivative?
Never heard about the Grinnel case, or maybe never noticed.
Just my brilliant mind and common sense.
However I'm happy to learn that my brilliant mind hasn't
produced a stupid result, as sometimes happens....
[snip]
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Via del Fonditore 3/E
Ville Niemi
> >use anticompetitive tactics to gain or maintain a monopoly. As an
> >example, look at Palm. Palm definitely has a monopoly in the handheld
> >market (84%), yet they have never engaged in any anticompetitive
> >tactics.
>
> Palm has a substantial market share. Without a doubt, they hold a great
> deal of market power; one might say they dominate the market.
>
> But they do not monopolize, AFAIK. They do not have a 'monopoly' in the
> handheld market; they merely have a superior product. My private
> opinion is that they would not be so dominant, in fact, if Microsoft
> weren't monopolizing in a related field. Microsoft's own attempts to
> fend off any threat that Palm might present suppress and inhibit
> competition in the handheld market. (As does the continuing attempts to
> monopolize exhibited by actors in the cell phone market, which shows
> obvious affinities with handhelds.)
Max is right, dominant market position doesn't mean you are monopolizing.
Just my vote...
Ville
Bob Lyday
>
> > >As a sidenote, I would like to point out that it is not necessary to
> > >use anticompetitive tactics to gain or maintain a monopoly. As an
> > >example, look at Palm. Palm definitely has a monopoly in the handheld
> > >market (84%), yet they have never engaged in any anticompetitive
> > >tactics.
> >
> > Palm has a substantial market share. Without a doubt, they hold a great
> > deal of market power; one might say they dominate the market.
> >
> > But they do not monopolize, AFAIK. They do not have a 'monopoly' in the
> > handheld market; they merely have a superior product.
Legal monopolies are legal; illegal monopolies are illegal. 70%
market share is usually enough to be considered a monopoly. "Monopoly
power" is another concept altogether; one which I am not too sure of.
T. Max Devlin
>>
>> > >As a sidenote, I would like to point out that it is not necessary to
>> > >use anticompetitive tactics to gain or maintain a monopoly. As an
>> > >example, look at Palm. Palm definitely has a monopoly in the handheld
>> > >market (84%), yet they have never engaged in any anticompetitive
>> > >tactics.
>> >
>> > Palm has a substantial market share. Without a doubt, they hold a great
>> > deal of market power; one might say they dominate the market.
>> >
>> > But they do not monopolize, AFAIK. They do not have a 'monopoly' in the
>> > handheld market; they merely have a superior product.
>
>Legal monopolies are legal; illegal monopolies are illegal. 70%
>market share is usually enough to be considered a monopoly. "Monopoly
>power" is another concept altogether; one which I am not too sure of.
Well, I am as sure of it as the courts are: there are no legal
monopolies; they are all illegal. The reason you say '70% is enough to
be considered a monopoly' is because large market share (sometimes, even
less than 50%!) is sufficient to provide evidence of anti-competitive
activity, depending on the market, according to the law. That doesn't
mean that any company that has more than 70% *is* a monopoly; it just
means the chances are good that they are, in fact, monopolizing, which
is illegal, regardless of how much market share you have.
"Monopoly power" is the only concept involved; market share is related,
but not the heart of the issue. What separates a monopoly from a
successful business is anti-competitive business practices, not market
share.
Bob Rudolph
> the best OS's of all?
Hell, I knew that! But I've been an OS/2 bigot since 1.3. Damn shame that
the ReXX never got ported....
Keith T. Williams
T. Max Devlin <tm...@nbn.net> wrote in message
news:27gtrsshpm42iqrnd...@4ax.com...
that do similar things.
Bob Lyday
Well, it runs on NT also. But not nearly as well as it runs on OS/2.
ReXX is easily worth the cost of an OS/2 license in and of itself.
I see you are posting from a police department. I have heard that a
majority of US police car computers run on OS/2, as do 1/2 of US
prisons.
OS/2, the invisible OS. It's everywhere but you can't see it.
--
Bob
[X] Check here to always trust content from Bob
[ ] Check here to always trust content from Microsoft
Remove "diespammersdie" to reply.
T. Max Devlin
>>
>> > Hmmm, then that makes OS/2, including OS/2 Server, the Amiga and QNX
>> > the best OS's of all?
>>
>> Hell, I knew that! But I've been an OS/2 bigot since 1.3. Damn shame that
>> the ReXX never got ported....
>
>Well, it runs on NT also. But not nearly as well as it runs on OS/2.
>ReXX is easily worth the cost of an OS/2 license in and of itself.
>
>I see you are posting from a police department. I have heard that a
>majority of US police car computers run on OS/2, as do 1/2 of US
>prisons.
>
>OS/2, the invisible OS. It's everywhere but you can't see it.
Isn't that the way its supposed to be? :-D
I've recently been thinking, as I've said, that it seems quite possible
that OS/2, being a *real* OS written from the ground up for
microcomputer work (and in the post Unix era) might well be a monumental
step forward in OSes. If it weren't proprietary, it would probably be
the best OS available.
You think there's any chance that IBM will open the source? :-)
The Proximate Cluebat
>
> I've recently been thinking, as I've said, that it seems quite
> possible that OS/2, being a *real* OS written from the ground up
> for microcomputer work (and in the post Unix era) might well be a
> monumental step forward in OSes. If it weren't proprietary, it
> would probably be the best OS available.
>
> You think there's any chance that IBM will open the source? :-)
They can't. OS/2 was a joint Microsoft/IBM project until Microsoft
betrayed IBM by releasing Windows. Microsoft still holds copyright
over vast tracts of the code, and the licensing terms almost
certainly forbid it, or penalize it at the least.
--
The Proximate Cluebat <clu...@earthlink.net>
T. Max Devlin
Guffaw.
Bob Lyday
>
> In article <r188sso0hcmgufcks...@4ax.com>,
> tm...@nbn.net wrote:
> >
> > I've recently been thinking, as I've said, that it seems quite
> > possible that OS/2, being a *real* OS written from the ground up
> > for microcomputer work (and in the post Unix era) might well be a
> > monumental step forward in OSes. If it weren't proprietary, it
> > would probably be the best OS available.
Proprietary or not, I think that OS/2 is indeed the best OS out there
for the x86 platform. On RISC chips, there are indeed better OS's.
But for personal computers, I would rank the Amiga OS #1 and then OS/2
and 3rd maybe Be. Linux is excellent but I give it #4. There is some
good to come out of OS/2's proprietary platform. Bugfixes are
lightning-fast. Bug testing is extensive and tests across many
platforms. OS/2 benefits by having a huge corporation behind it. IBM
has almost 300,000 employees, making it one of the biggest
corporations on Earth. MS only has about 30,000 employees. And IBM
sells more software than anyone on the planet. They sell way more
than MS. Few people know that.
--
Bob
[X] Check here to always trust content from Bob
[ ] Check here to always trust content from Microsoft
[ ] Check here to reboot now
Remove "diespammersdie" to reply.
Keith T. Williams
Bob Lyday <lydayfamilyd...@sierratel.com> wrote in message
news:39C4791B...@sierratel.com...
> The Proximate Cluebat wrote:
> >
> > In article <r188sso0hcmgufcks...@4ax.com>,
> > tm...@nbn.net wrote:
> > >
> > > I've recently been thinking, as I've said, that it seems quite
> > > possible that OS/2, being a *real* OS written from the ground up
> > > for microcomputer work (and in the post Unix era) might well be a
> > > monumental step forward in OSes. If it weren't proprietary, it
> > > would probably be the best OS available.
>
Bob Lyday
>
> Amiga runs on PCs? I thought it had proprietary hardware.
It runs on a personal computer but not an IBM PC, so to speak. I
think one of the great things about the Amiga was the hardware. The
chip was actually 4 different chips which balanced the processing load
brilliantly. And the speed and multitasking were out of this world.
The GUI was pretty awesome, too.
Dore's Favourite Demon
So that explains in part why IBM is jumping onto the Linux bandwagon?
>The Proximate Cluebat <clu...@earthlink.net>
Erikc (alt.atheist #002) | "An Fhirinne in aghaidh an tSaoil."
BAAWA Knight | "The Truth against the World."
ICQ 78676616 | -- Bardic Motto
"Today on Jerry Springer: Religious whack jobs melt down before your
very eyes..."
=======
You are right! I AM God, and all of His thoughts are MY thoughts,
and all of His creation is MY creation and all that is, is because
of me. How nice of you to notice.
From: "Dore Williamson" <spiri...@supernet.com>
Subject: Re: I was accused of bringing no new thought, here is
what I am being prepared for..
Message-ID: <pvQw5.7842$is5.3...@nntp1.onemain.com>
Date: Sat, 16 Sep 2000 15:49:03 -0400
======
Biblical inspiration for the frustrated Christian woman:
"There she lusted after her lovers, whose genitals were like those of
donkeys and whose emission was like that of horses." - Ezekiel 23:20
====
Comparing religion to science is like comparing bullshit to horsepower.
====
Real addy is firewevr @ insync dot net.
The Proximate Cluebat
> On Sun, 17 Sep 2000 03:47:14 GMT, The Proximate Cluebat
> <clu...@earthlink.net> wrote:
Maybe. Seems more likely to me they're doing it because their
customers started calling up IBM sales reps and asking when they'd
start supporting Linux. That the result screws Microsoft over is
just gravy. :)
Keith T. Williams
> "Keith T. Williams" wrote:
> >
> > Amiga runs on PCs? I thought it had proprietary hardware.
>
> It runs on a personal computer but not an IBM PC, so to speak. I
> think one of the great things about the Amiga was the hardware. The
> chip was actually 4 different chips which balanced the processing load
> brilliantly. And the speed and multitasking were out of this world.
> The GUI was pretty awesome, too.
> >--
Keith
Elf Sternberg
Bob Lyday <lydayfamilyd...@sierratel.com> writes:
>"Keith T. Williams" wrote:
>> Amiga runs on PCs? I thought it had proprietary hardware.
>It runs on a personal computer but not an IBM PC, so to speak. I
>think one of the great things about the Amiga was the hardware. The
>chip was actually 4 different chips which balanced the processing load
>brilliantly. And the speed and multitasking were out of this world.
>The GUI was pretty awesome, too.
There's currently an initiative from some of the original
Amiga developers to bring back the Amiga API and the attendent power
of the original Amiga to x86 hardware. The logic goes that what Amiga
was originally doing is now being done by everyone-- video and audio
processing, memory management, peripheral I/O and general processing
are all being done by seperate components in most Pentium systems.
And since perfectly functional multitasking cores exist in both Linux
and BSD, the notion of rebuilding the Amiga API on top of that doesn't
seem so farfetched.
Elf
--
Elf M. Sternberg, rational romantic mystical cynical idealist
http://www.halcyon.com/elf/
"Chaos rules the universe! Scientists call it entropy! Everything is
breaking down, tending towards greater and greater disorder!
It's great to be on the winning side!"
--- Grimmy
T. Max Devlin
[...]
>FOUND! I knew that going on hammering I would have found the
>missing link, the Rosetta stone, etc.
>What I was missing is that MS started BUYING code from the
>very beginning. At that time I couldn't care less where a
>Basic interpreter was coming from.
>This sheds a new light on the whole thing, and I must
>painfully admit that it's possible that you're right and I'm
>wrong. The starting point might have been monopolizing and
>not incompetence.
>
>As an afterthought: if they had to buy software they didn't
>have the competence to write it!......
Thank you for persevering, either way. And it is, indeed, a false
dichotomy. (You may heard me advance the foolish notion that you can
only know what's true when you understand how its false; this is the
kind of thing that makes me say that.)
Bill Gates is an incompetent programmer, from all observations. He may
very well have written the original MS-BASIC interpreter which they were
using to monopolize ROMs in microcomputers. I would say that the
chances are pretty good, given the circumstances, that he probably just
copied it from whatever other BASIC interpreters were around. It
certainly wasn't anything remarkable, and it showed much of the same
crappiness that would later infest all Microsoft products.
I think, ultimately, the reason I would say it is more that he is a
megalomaniac, rather than that he is incompetent and so need to
monopolize, because it is, indeed, much the same crappiness in the
*software*, and AFAIK, Bill has hardly written a line in the last twenty
years, at least.
>However, I arose the question for two reasons. The first one
>was to understand why you so vehemently claimed that
>monopolizing was the very origin of everything. As I had a
>different notion I wanted to understand why.
>
>The second was to understand what's going to happen.
>Assuming that something will happen (split, court control
>over activities, OEM pressure) that will force MS to
>compete, do they have the technical skills to do it?
Certainly; you can't hire hundreds of professional programmers and not
have technical skills. It is, as you've noticed, the *monopolization*
which actually makes the software bad. The *idea* of Win32 isn't even a
bad thing (hell, it's just middleware), though a rational implementation
might well be an unrecognizable thing in comparison to what Microsoft
has wrought today.
>There is a subtle, impalpable thing which is "corporate
>philosophy", permeating any company, and it's one of the
>most difficult thing to change. Once a "corporate
>philosophy" has been established it appears to die only when
>the last stone of the last building has fallen. I read about
>it on a english book which was very popular in the 60's,
>whose title now escapes me. It was "Someone's" Law, and it
>was about public and corporate bureaucracy.
The Peter Principle. Dr. Peter "Somebody" advanced the theory that in
any hierarchical administration, a manager rises to his level of
incompetency. You are rewarded for doing a good job by having your job
changed, until you can no longer do a good job, and there you stay.
>It claimed that
>"corporate philosophy" is kept in the very walls of the
>building, and if a company starts declining you can't start
>a new company in the same building, because it will decline
>the same way, and the only solution is to destroy the
>building and lay salt over its ruins. It appears a bit
>extreme, but I started keeping track, and I found that
>there's more truth than one would say.
Yes, indeed. I think it has to do with 'memes'; monopolization is a
mind-virus. Even other companies, which would otherwise be competitive,
are forced to 'anti-compete', thus drastically inhibiting their ability
to produce good products, even without direct influence by the monopoly.
Maybe its just wishful thinking, but I honestly think things are going
to change pretty damn drastically (which is to say, hardly at all, but
fundamentally) in the next five to ten years. Fifteen years from now,
at the outside, software will no longer be wrapped in a trade secret
license at all, aside from that stuff which is so closely tied to
still-proprietary hardware as to be part of the device. The ultimate
result of the PC revolution, will extend far beyond computers. Software
enables the adaptation of hardware to make *everything* *completely*
interoperable, with varying levels of compatibility which *matches* the
reality of the hardware. Hardware will become as cheap as dirt, and
software will become as cheap as water. The great amount of competition
that is actually untapped will force it to be.
>One blatant example I found is with Fairchild semiconductor.
>They were a very brilliant company, they produced the first
>Operational Amplifier IC, but they had a peculiarity: their
>technical manuals were such a mess that if you didn't know
>the exact part number of what you were looking for you'd
>never find it. They opened a factory in Italy, which
>published technical manuals in Italian, and which were, of
>course organized the same way. Then the Italian factory was
>dismissed, and was taken over by Italians and was called
>SGS. It changed from the original production lines to
>different, more profitable ones, in consumer and industrial
>markets, originated a number of successful components, but
>technical manuals were a terrible mess. A few years ago they
>merged with french Thomson to make a new company called ST,
>and they're now among the largest IC manufacturers in the
>world. They're among the big manufacturers of IC for
>cellular phones, they're growing and show high profits,
>while Fairchild Semiconductors doesn't exist anymore since a
>long time, but their technical manuals are always the same
>old mess!
And yet nobody seems to catch on that technical manuals for such
specialized products are simply inefficient. There comes a time when
you aren't dealing with anything but specialized production, and the
customer base has to be so knowledgable about the product to begin with
that while lack of tech manuals might be desirable, or even possible, it
simply would not be cost efficient for an IC manufacturer to do any
better than they are.
I have a similar situation with my business, which provides a
perspective, if not a solution. I write training materials for
enterprise-level and carrier-based network management software. I've
been working with a variety of products for almost a decade. I have a
great deal of knowledge about the products, and a great deal of
knowledge about the technical documentation for such products, and I
constantly deal with things that are literally on the edge of the
'proprietary knowledge' of a handful of programmers and the working
knowledge of the software necessary to get it to "work right".
Typically, though, I deal with the user/operator level, and I explain
how to implement the software in an operational environment. (Thus, my
focus on 'operational functionality'.) In all those years, teaching
dozens of 'standard implementations', each unique, across hundreds of
customers, large, medium, and mega-conglomerate, I have produced two
sets of course material that I would consider calling 'course books'
which teach the software product in a classic exercise-based approach.
The expectation of documentation in a training course is always quite a
bit higher than the results. Or at least the general results are, and
people who go to such classes routinely anticipate little more than a
printout of a Power Point presentation. This is even more useless than
whatever print-outs and white-board notes we can scrawl, but it
satisfies them. As I said, they've learned to expect no more. But when
it comes to the 'operational procedure' courses, there are no 'training
materials'. Obviously enough, it often is asked of me why. My canned
response, depending on the inquisitor, is either 'I have no budget', or
'I'll send you something on disk.' If given the time and opportunity, I
will explain further that either and both reasons are that it doesn't
pay. It is simply not efficient to try to maintain the kind of
structure course materials for these products that would work for the
implementations we're doing (which are all certified by the vendors, and
we're a premier provider of most of these very popular products).
Keeping up with the software revisions alone, with each of three to
seven products in a single system (element managers, platforms, event
management, performance reporting) getting revved up to twice a year,
and all adding massive amounts of 'new functionality' as they glom for
'market share', would require a staff eight times the size of the one I
have now (one: me). They don't ask about that stuff much these days, as
we've modified our implementation style to make it more approachable to
those problems, and found a really nice marketing opportunity for doing
so.
So the reason IC companies have crappy documentation is, I think,
*pro-competitive*. Its a marketing opportunity for someone. These
days, its those 'gurus' who know how to pick ICs by number. When I was
in the service repairing avionics equipment, we just looked up the IC in
the military references, and ordered the part. It was the engineers who
figured out which ones. Well, them, and the supply people who procure
spare parts. I have an interesting story to tell about that, too, if
you don't mind.
If you do mind, I'll at least keep it brief, as I really should be doing
other things right now.
One of the boxes I dealt with in the Calibration facility in San Diego
was a test box. The Cal lab takes the test equipment the other guys use
to repair stuff and verifies and repairs it. This test box detected
stray voltage and current on the fire control circuitry of fighter
planes. The bomb racks need to be dead, and careful handling does not
provide for inductive currents of minuscule amounts. So the tolerance
on this little gadget was extremely tight, I'm sure you would realize.
And the dozen or two of them that each crew checked out of the base
facility had to be verified every three months on rotation. (The
biggest pain was that they used special rechargeable batteries, Ni-Cads,
and they'd been around for years, so they were all developing horrible
'memory'.) When one of these boxes was out of tolerance to a third
order of precision, I generally did the soldering myself replacing ICs
and resistors. I wasn't necessarily very good, but I would at least
know how bad it might be. It wasn't tricky multi-layered boards, but
that just meant it was all by hand.
No matter what I did, I had three boxes that I couldn't get back into
tolerance. They just had a bit too much noise on one particular phase
of the tests. I repeatedly troubleshot it down to one IC, and no matter
how careful I was or how clean the job, the situation was never
corrected. In fact, in some cases, it got worse. I guess that was my
clue. It only took about twenty minutes of research and a couple hours
talking to supply people before I found out that there was simply no way
to get the IC that the original design specifications called for. I
couldn't even say whether it was still made, though I had a half dozen
civilian possibilities. But, the military specification replacement for
that IC was simply not capable of doing what was needed for the
particular box I was working on. I actually did procure one potential
successor to another alternative (from the commercial parts lists), but
it was not even close.
>On the opposite side, the HP Vectra computer sitting on my
>desk appears to follow the same lines of design and
>engineering quality which I met the first time I saw an HP
>oscilloscope some 35 years ago.
Having repaired and calibrated HP oscilloscopes that were twenty years
old fifteen years ago, I have to say that is a rather impressive
statement of engineering quality of modern HP Vectras. I wouldn't say
there wasn't some 'efficiencies' in there that might not seem valuable
if you knew about them.
>Sorry for the digression, but I wanted to make clear my
>point.
LOLROTFLMAO
LOL
>Now, given the current MS "corporate philosophy", how
>can one foresee that they'll bee capable:
>a) not to resort to anti-competitive policies
They might try; they cannot succeed. MS is having a bitch of a time,
you'll notice, just continuing the act. It would be hard to say that
anyone is concerned enough about .NET to mention that it will fail; the
only ones talking about it are those already making money on talking
about it. Whichever MS tries to claim .NET will find themselves with a
white elephant. The only way there is a market for it is to actually
*make* it something, and in the process provide a competitive service,
which can be emulated by anyone else who wants to and has a market on
the other MS.
>b) to turn out some decent product?
See above.
Keith T. Williams
direction?
Elf Sternberg <e...@halcyon.com> wrote in message
news:8q5ff4$i9q$1...@brokaw.wa.com...
Giuliano Colla
>
> Said Giuliano Colla in alt.destroy.microsoft;
> >"T. Max Devlin" wrote:
> [...]
>
> have technical skills.
In a large project, where many programmers must work
together, if you don't give them a high level framework to
work in, if you oblige them to code in a hurry, if you
hasten them to turn out the product before extensive
testing, then the best professional programmers will either
leave or produce crappy software, as if they had no
technical skills. If the company cannot exploit programmers
skills, then the company doesn't have technical skills. Of
course anti-competitive policies lead to the same result,
but they're not necessary, in principle, to explain crappy
results.
I'm still haunted by a software module I've written almost
ten years ago to operate a complex part of a machine. It was
written in hurry, just to test some mechanical parts. Then
other problems arose, there was no time to rewrite it, and
it was kept as it was, just fixing the bugs. Once in a while
it is re-used, and always in hurry, so it's basically as it
was. It's pure crap. So I can testify that a professional
programmer may produce crap, if conditions are appropriate.
> It is, as you've noticed, the *monopolization*
> which actually makes the software bad. The *idea* of Win32 isn't even a
> bad thing (hell, it's just middleware), though a rational implementation
> might well be an unrecognizable thing in comparison to what Microsoft
> has wrought today.
>
> >There is a subtle, impalpable thing which is "corporate
> >philosophy", permeating any company, and it's one of the
> >most difficult thing to change. Once a "corporate
> >philosophy" has been established it appears to die only when
> >the last stone of the last building has fallen. I read about
> >it on a english book which was very popular in the 60's,
> >whose title now escapes me. It was "Someone's" Law, and it
> >was about public and corporate bureaucracy.
>
> The Peter Principle. Dr. Peter "Somebody" advanced the theory that in
> any hierarchical administration, a manager rises to his level of
> incompetency. You are rewarded for doing a good job by having your job
> changed, until you can no longer do a good job, and there you stay.
Yes, it was about the same time, and on the same line. The
one I was trying to remember was "the Parkinson's law". The
law is about the growth of the number of employees both in
government offices and in companies.
There was a very interesting graph of the number of
employees of the british ministry of colonies, as compared
with the actual amount of british colonies in the last 100
years. You could see a continual growth in the number of
employees, with no relation at all with the actual colonies,
to reach the maximum around 1960 when no more colonies were
left....
[snip]
>
> And yet nobody seems to catch on that technical manuals for such
> specialized products are simply inefficient. There comes a time when
> you aren't dealing with anything but specialized production, and the
> customer base has to be so knowledgable about the product to begin with
> that while lack of tech manuals might be desirable, or even possible, it
> simply would not be cost efficient for an IC manufacturer to do any
> better than they are.
>
[snip]
I understand your point, and I was also interested by your
anecdote about IC specs. But in that case the problem is
just technical manual organization. If you locate the
product, then the information is quite good.
The only problem is that they persist to put all products
one after the other in order of part code, so that you find
a solenoid driver after an OP amp and before a line driver,
and you don't have any cross-reference in order to locate
the OP amp or the solenoid driver you are looking for. Even
the index only gives you part code and page, without a
description, so you're forced to read the whole manual to
locate a product!
[snip]
>
> >Sorry for the digression, but I wanted to make clear my
> >point.
>
> LOLROTFLMAO
>
Is it Thai language or an acronym?
Bob Lyday
>> >
> > LOLROTFLMAO
> >
> > Is it Thai language or an acronym?
>
;)