Billy Brown writes:
> *All* respects? Not quite. There is nothing in Unix-land (or anywhere
> else, AFAIK) that even begins to compare with the capabilities of COM+ for
> writing distributed applications.
So tell us, why and how is COM+ better than MPI or PVM, or any of the
newer funky userland active-messages efforts. Stability? Availability?
Throughput? Latency? (of what sense is this if task response time
itself sucks due all the massive OS code bloat). Excellent support?
Because there is so much already written well debugged code for COM+,
since it has been with us since time immemorial? Because COM+ is an
open (comes with source), uncorruptible standard, not linked to a
single OS, with well-documented track of absolutely corrupt (let's
call it outright evil) business practises?
> Now, I thought it was supposed to be the evil Micro$ofties that tried to
> treat vaporware like a current feature. :-) I could say the same thing
> about Windows with equal accuracy (after all, it runs POSIX applications,
> DOS programs, and all the major Unix shells, and Microsoft could easily slap
> other interfaces on top if they wanted to). The questions are:
The POSIX compliancy thing is a joke, as you well know. According to
the test suite, my CP/M system as well as my pet rat are fully POSIX
compliant. I'm not particularly interested in DOS programs, because
they typically do not come with source, and are built to fit into DOS'
limitations. There is little point in looking for bash for Win98 on
OpenSource software depository for Windows (which hasn't any
OpenSource followship worth speaking of, and no central
depository). And we all know what we can expect Microsoft to do:
largely nothing (with the exception of profit maximisation), as is
Finally, I can't afford to run M$ OS due to their notoriously lousy
securety and stability problems. As an illustration, I could have made
this (plain text) mail invisible to M$ Outlook users, by using a
pretty innocuous phrase like begin followed by two blanks (and maybe a
comma) at the beginning of this message. Or crashed anybody's M$ box
who still thinks that running M$ OS and using browser in HTML
rendering mode for reading mail is a smart idea, by embedding a
file:// URL referring to local driver combination. Hahah. How funny.
> 1) Is there anything decent you can use now (and if you have to compile it
> yourself, you've completely missed the point as far as the mass market is
I could hardly care less about mass market (I make no illusions about
me being an average user). God, if Linux is one day truly successfull
one has to create protection mechanism against damage done by
stampeding masses of well-meaning, but clueless idiots, and aggressive
commercial efforts to usurp development, including such universally
well-liked practices like silently sneaking user web behaviour
tracking trojans into your streaming multimedia player, and
government-mandated remotely exploitable back doors (thanks for that
go to that J. Reno bitch). One would have to use cryptographic
authentication linked to authorities and massive code reviews against
evermounting attempts to corrupt code. What a fucking nightmare. We
need a crisis management group against OpenSource corruption, asap. It
probably has already begun.
> 2) Is there reason to think that X years of improvement in Linux UIs will
> yield better results than X years of improvement in Microsoft UIs? (And it
You think you can improve a text console?
> would be nice if the reason amounted to more than 'oh, open source will
> automatically make everything wonderful'.)
X-Windows is not an UI. Why must I resort to third party products like
BackOrifice 2k or PcAnywhere to do anything remotely over the network?
God, if I start to enumerate what is right with Linux and wrong with
Microsoft this would take me the whole week. My god, recently these
jokers thought putting executable code into the friggin' _file system_
was a monstrously smart idea, in M$'s attempt to reinvent symbolic
links. </throwing hands up in exasperation>.
> > I don't see this changing anytime soon. I expect that the vast
> > majority new applications rolled out in the near future will reuse
> > parts of the existing XML/HTTP infrastructure and be platform neutral.
> > Some will even be truly innovative.
> For the client, probably. But for apps that interact with a database you
> can get about a factor of five cost savings by writing the server app on top
> of COM+ and running it across clusters of cheap boxes, as opposed to going
Oh, yes, M$ has now invented the Beowulf.
> with the one-big-box approach or trying to hand-code a distributed app on
Er, you should have noticed that the one-big-box is profoundly
obsolete, at least outside the M$'s technology circle.
You have always hand-code a distributed app, because there is no magic
which makes a monolithic application distributed.
Don't get me wrong, there's plenty wrong with Unix. I don't like its
monolithic, increasingly subject to code-bloat approach. Much would be
gained if a tiny-memory-footprint realtime nanokernel with excellent
message passing support would surpass Linux (QNX, L4 would seem to
move in the right direction). Why can't a 2-8 kByte core image
nanokernel be handcoded in assembly? I would like to see hardware
threaded code support for steeper abstraction gradients, including
languages supporting it, stack processors, reconfigurable processors
and eventually totally dynamically reconfigurable hardware a la CA
machines. Emulating Linux on such architectures is certainly
unbearable cruft, so it has to die on the way there.
Trying to discuss M$ offerings in the context of OpenSource is
ridiculous. It's a totally different league.
This archive was generated by hypermail 2b29 : Thu Jul 27 2000 - 14:04:48 MDT