Linux-Advocacy Digest #186, Volume #26 Thu, 20 Apr 00 06:14:04 EDT
Contents:
Re: Penfield Jackson bitch-slaps Bill Gates ("John W. Stevens")
Re: Introduction to Linux article for commentary (John Hasler)
Re: DCOM versus CORBA, some history ("Mike Palmer")
Re: How does WINE work? ("Rich C")
Re: What else is hidden in MS code??? (Rob S. Wolfram)
Re: What else is hidden in MS code??? (Rob S. Wolfram)
Re: What else is hidden in MS code??? (Rob S. Wolfram)
Re: What else is hidden in MS code??? (Rob S. Wolfram)
----------------------------------------------------------------------------
From: "John W. Stevens" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Penfield Jackson bitch-slaps Bill Gates
Date: Tue, 18 Apr 2000 17:42:14 -0600
Paul 'Z' Ewande� wrote:
>
> "John W. Stevens" <[EMAIL PROTECTED]> a �crit dans le message news:
> [EMAIL PROTECTED]
> >
> > Nope. MacOS X is just Rhapsody (already released) and MacOS Server
> > (already released) with a few cosmetic changes. Right now pretty much
> > works as "at the moment", don't you think?
>
> MacOS Server ? What is that ? An UNIX ?
MacOS Server is: The Mach MicroKernel, hosting both a BSD Unix
personality and the MacOS personality, with a set of reusable component
libraries on top, in combination with a few of the nicer services out of
OpenStep.
In short, MacOS Server (and, the soon to be released MacOS X) is a type
of Unix.
> > No, I didn't. Linux has a lower hassle to productive work ratio than
> > Windows does.
>
> The fact that Linux isn't totally mainstream, yet, is high hassle generator.
No, the fact that certain ignorant users insist on allowing a single
company to encrypt their data in secret formats, and trust that single
company to manage and control their communications and security using
secret protocols and formats is the hassle generator.
The faster the user base gets educated as to the benefits of open,
standard interfaces, the better for everybody. Consider the impact of
allowing MS to implement MS specific capabilities into the IE browser .
. . would you really like to *HAVE* to buy MS Windows and MS IE and hook
up to the internet through MSN to view Web content?
The power of the Web is based in it's open, standard interfaces (HTTP
and HTML).
> > Seeing as how I spend a fair amount of time using computers, and seeing
> > as how I haven't used Windows in many years, it seems clear that the set
> > of "must-use" Windows users is a sub-set of "home computer users".
>
> Agreed. But, suppose some are not part of the "must-use" and yet sitill feel
> that Windows works to their satisfation, why should they change ?
They should change because in using Windows, they are allowing a single
vendor/company to control their work flow, and to encrypt and control
their data.
If MS used and conformed to open, public standards, then there is
absolutely no reason to change . . . but they don't. The sooner a user
switches to systems based on open, public standards, the better for
them, and everybody else they work with.
> > But that wasn't the discussion. What intrinsic limitation does Linux
> > have that keeps it from performing the above task?
>
> None AFAICT. But I evaluate an OS by the stuff it does that I need/want it
> to do, not by what it might be able to do.
How do you deal with change, then?
> It's as valid a criterion as any
> other, and I'm sure i'm not the only one thinking that way. After all,
> AFAICT, the reason of existance of an OS is to allow you to do your stuff on
> the hardware you own.
In most cases, people focus on the short term (saving pennies), and
entirely miss the long term (thereby wasting dollars).
Moving from a closed, proprietary platform to an open one may cost a
little now, but the long term cost savings far out weighs the short term
costs.
I must admit, I am constantly amazed by the simple fact that the
industry, as a whole, has allowed MS to waste billions of dollars for
them. . .
> > In short, once again, the lack of an application says nothing about the
> > OS, unless you can point to some reason why the OS makes it impossible
>
> It says that it doesn't allow you to do Foo.
Ummm . . . no. It's Foo that doesn't run on that OS, which is Foo's
fault (or, more realistically, the fault of the org that created Foo).
What you are illustrating is how MS gained and maintained their
monopoly. . . the totally unneccessary relationship between application
and OS costs *YOU* money, time and freedom. Instead of blaming an OS
for not running application Foo, you should blame Foo for not being
written to work with an open, public standard.
> > to create such an application to run on it.
>
> Sure, you tell that to the guy who needs Foo application.
The guy who needs Foo, should find an instance of Foo that conforms to
open, public standards. That way, he can run Foo on what ever OS (so
long as it implements those open, public standards) he wants.
Would you buy a car that used non-standard nuts, screws, bolts, tires,
lights and gasoline? Furthermore, would you buy a car that uses
non-standard parts that can only be purchased from the manufacturer of
the car, and that can only be removed, maintained and installed by tools
that only the company who sold you the car sells? Even more so, would
you buy a car that only ran on the roads built and owned by the same
company that manufactures your car, gasoline and parts?
MS uses proprietary, secret interfaces then regularly churns those
interfaces in order to make sure that the above scenario holds true.
Users must start demanding that unnecessary relationships are reduced in
strength, or eliminated entirely.
> > What good is it? Simple. A fast, good, ultra stable OS is the perfect
> > platform for running the encoding software on.
>
> Okay, you take your fast, good, utras stable OS and encode the *.mov hand
> manually. I prefer to let the computer do that for me wether it is on the
> MacOS or Windows.
You don't need to encode manually. If the movie is stored in an open,
public format, then anybody can write a program that can do the
encoding, then somebody can and will write that program.
If, on the other hand, you choose to give control over your data to the
company that wrote the encoder, then you deserve to be owned by that
company.
Demand that companies give *YOU* control over *YOUR* data!
> > The fact that for what ever reason such software doesn't exist, says
> > nothing about the OS. It is a comment on the existing business model
>
> It says that for the moment, it doesn't allow me what i want to do.
Ummm . . . no. It says that the APPLICATION writer won't let you do
what you want to do. My suggestion to you is that you need to send a
very loud, clear message to that application writer: "USE OPEN, PUBLIC
STANDARDS AND WRITE TO OPEN, PUBLIC INTERFACES OR I WON'T BUY YOUR
JUNK!"
> The OS
> is not bad per se, because of it, it's just not practical/useful.
Ummm. . . no, it's the *APPLICATION* that is not practical or useful.
Would you really buy a TV that can only work with power supplied by the
same company as made the TV, and that can only show shows produced by
the company that made the TV, and those shows can only be produced,
stored and broadcast by equipment made and sold by the same company that
made your TV . . . or do you *LIKE* being able to choose different,
independent manufacturers for your VCR, your TV, your DVD player, your
cable box, your Video Camera . . . this mix and match capability is made
possible completely and entirely by the use and adherence to open,
public standards.
Do you blame the standards compliant VHS VCR when it won't play the XYZ
format tape you just bought, or do you blame the company who uses the
XYZ format to force you to buy their XYZ VCR's, XYZ TV's and XYZ power?
> > (maybe the hardware manufacturer will not release the informatio
> > necessary to write a driver for the card, maybe the Sorenson encoding is
> > secret, and proprietary . . . ), and it simply illustrates the
> > effectiveness of MS's monopoly garnering and protecting tactics.
>
> In fact, I think that it's an Apple stuff. But we all know that Microsoft is
> the source of all evil.
Oh, any company that uses secret, proprietary interfaces is at least
somewhat evil. . .
> > I don't disagree, what I claim, instead, is that open, public interface
> > standards are an absolute requirement in a modern, mature information
> > processing business. Using Windows in any shape or form, or for that
> > matter, any OS which doesn't have at least one plug-in replacement, is a
> > very poor business choice.
>
> Maybe.
Hey, if you *LIKE* giving complete and absolute control over your eLife
to a single company, go for it.
But the history of other industries makes this issue very, very clear.
Where neither the industry nor the customers have the will and intent to
create and conform to open, public standards, the government must and
will step in.
The FCC is the best example of where the government stepped in to ensure
an open and competitive market through the use of open, public
interfaces.
> > Excuse, but that was always my point: MS sucks 'cause it is a monopoly.
>
> MS may suck or not, I really don't care. But MS sucks is different from
> Windows9x sucks.
Windows 9x sucks 'cause to write for it is to create an unnecessary
relationship between an application and the OS.
Had Windows 9x conformed to an open, public standard, it might still
suck, but that's a different discussion.
> > Java was "embraced and extended" by MS *PRECISELY* because it threatened
> > to break this unnecessary relationship.
> >
> > Unix is the *ONLY* OS that provided a broad range of open, public
> > standards that have been implemented on multiple platforms by multiple,
> > independent hardware/software vendors. As such, it is the heir apparent
> > to the next generation in business computing.
>
> We should all be using UNIX ?
No. We should all use whatever OS we prefer, so long as it conforms to
a open, public standards.
> Hmmm. I'm more of a use what works for you
> guy.
I usually try to take some responsibilty for the effects of my actions .
. . if I buy MS products, I end up, in effect, *PAYING* for MS to take
control over my eLife. I prefer to maintain control over my own life.
Using LaTeX, for instance, as my primary word processing/type setting
system allows me to choose my OS independently of my word
processing/type setting system ('cause LaTeX runs on OpenStep, FreeBSD,
Linux, HPUX, Solaris, SunOS, MacOS, VMS, MacOS Server, Windows 9x,
Windows NT and Windows 2000 . . . and probably some OS'en I've never
even heard of), and since the LaTeX source and DVI file formats are
open, public standards, I can use what ever tools I wish to, to process
my word processing files.
If I chose to run MS Word . . . I'd be letting MS choose my hardware, OS
and what other applications I can and cannot use to process my data.
> > Yep. You are aware, are you not, that there are more GUI's for Linux
> > than just X?
>
> I heard about that. But would they boot with 4 megs and still have some
> functionality ?
Yes.
The world decided that X was the open, public standard of choice, so
other systems were abandoned.
> > UberControlMechanism (the steering wheel) and other "standard" things .
>
> For a car, maybe. You are aware than an OS is way more complex
Oh, I hope I'm aware of that. . . considering what my current job is!
:-)
> and be used
> in many, many different scenarios. You believe that it will be possible to
> adopt a one size fits all stance on this ?
On OS'en? No. I believe that it is possible to adopt a set of open,
public interfaces that describe a hierachically dependent group of
functional sets that, in short, can do most everything you choose an OS
to do.
Note that Linux already covers a very, very broad range of hardware and
scenarios through the simple fact that you don't actually end up using
Linux everywhere . . . you end up, in all cases, starting with a very
small, but very generic set of functionality (memory and processor
management is pretty much the base set of functionality for any OS),
then aggregating what you need for a particular environment. That's how
Linux can run on everything from a Nintendo 64 or Palm Pilot, on up to a
multi-way SMP based server . . .
Linux/Unix has a much better shot at being the UberOS than Windows does,
*PRECISELY* because it isn't a monolithic whole but, instead, it is like
a lego creation: a finished system is the aggregation/composition of a
number of independent parts.
Since Windows (for example) cannot be separated from it's GUI, then
there are many situations where Windows cannot be used at all. But
since the GUI for Unix is a neatly and cleanly separable piece, you can
easily use Unix where you cannot, must not have a GUI.
The Linux kernel can be configured to be an amazingly tiny, very simple
thing . . . or as an enourmously large and complex thing. Add on top of
that the fact that nearly everything else about "Unix" is a separable
piece, and you can go right on clicking things together until you get
what you need for a particular scenario/environment or task.
> > If designed properly, then an UberOS is perfectly possible, and
> > eminently reasonable . . . the only real reason that you must consider
>
> IMO, it's way more easily said than done.
Which is why it's taken thirty years to get the first reasonable
candidate. . . Linux.
> > different OS'en for different jobs, is that you are victimized by the
> > use of proprietary, secret information that has been used to tie you to
> > a particular OS. If all applications ran on any OS . . . then what
> > would differentiate the different OS'en enough to justify different
> > OS'en?
>
> Different UI and systems paradigms, availability, hardware
> support/platforms...
Exactly . . . and if the UI also conformed to an open, standard
interface as well as the hardware . . .
The power to make choices is irrelevant without having real choices to
make.
Note that the open, public standards used in/on the original PC is what
allowed MS to become a Monopoly in the first place . . . and that is
what *PREVENTED* IBM from becoming a monopoly in the PC space.
--
If I spoke for HP --- there probably wouldn't BE an HP!
John Stevens
[EMAIL PROTECTED]
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: alt.linux,alt.os.linux,uk.comp.os.linux
Subject: Re: Introduction to Linux article for commentary
Date: Tue, 18 Apr 2000 20:17:13 GMT
Vlad writes:
> Private comnpanies are probably among the worlds most tyrannical and
> undemocratic organizations.
I've been in private companies and I've been in the Army. Private
companies don't shoot you for trying to quit.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
From: "Mike Palmer" <[EMAIL PROTECTED]>
Subject: Re: DCOM versus CORBA, some history
Date: Tue, 18 Apr 2000 16:56:13 -0700
Reply-To: "Mike Palmer" <[EMAIL PROTECTED]>
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8di30q$175c$[EMAIL PROTECTED]...
> In article <PCSK4.2636$[EMAIL PROTECTED]>,
> Erik Funkenbusch <[EMAIL PROTECTED]> wrote:
>
> >Microsoft had been promising DCOM since COM was officially launched in a
> >product in 1992. CORBA had very little to do with it, since it was an
> >extension of the existing COM architecture, not a perversion of CORBA.
It
> >didn't introduce incompatibilities or hassles for most customers, since
it
> >was designed to help them leverege their existing COM code, making it
easier
> >to do distributed processing if they were already heavily invested in
COM.
>
> So one way of looking at it is that it is designed to make it
> easy to make Microsoft products work together. Another way of
> saying the same thing is that by ignoring standards they make
> it difficult to interoperate with any other vendor's products.
That's not correct.
I think a better way to put it is that it is designed to make Windows
products work well together. My code certainly doesn't say Microsoft on it,
yet it works with software from other vendors - Microsoft included.
Microsoft makes it easy to build and include COM objects - to the point that
including COM objects in an application is not a significant development
issue.
COM/DCOM objects are not designed to be vendor specific. On the other hand,
CORBA objects were, although that is changing.
There's a very nice paper called "DCOM and CORBA Side by Side, Step by Step,
and Layer by Layer," which you can find at
http://www.cs.wustl.edu/~schmidt/submit/Paper.html . The authors compare
DCOM and CORBA. In their summary, the authors conclude that the
architectures of DCOM and CORBA/Orbix are basically similar, and that they
both provide the distributed objects infrastructure for transparent
activations and accessing of remote objects. They also point out the
differences between the two, and point out that DCOM specification contains
many details that are considered as implementation issues and not specified
by CORBA. Some of those implementation issues were included in CORBA 2.2.
But let's face it: the biggest problem is that after seven or eight years of
OLE and COM, I have yet to cut and paste anything more complex that simple
text between applications from different vendors on my Unix box. OLE and COM
may be poor implementations, as someone suggested here a few weeks ago, but
they are here today, and huge numbers of Windows applications support them,
and it's really cool to be able to stick drawings and spreadsheets and plots
and data into my documents as objects.
Linux needs the same thing.
-- Mike --
------------------------------
From: "Rich C" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,alt.destroy.microsoft
Subject: Re: How does WINE work?
Date: Tue, 18 Apr 2000 20:01:20 -0400
"Ulrich Weigand" <[EMAIL PROTECTED]> wrote
> - On top of DOS, a 32-bit 'DOS-extender', the Virtual Machine Manager
> (VMM) is running. This allows to run several virtual DOS sessions
> at the same time. Furthermore, it enhances the facilities provided
> within each of the VMs considerably, e.g. it supports multiple
> threads runing in each VM, and it allows 32-bit device drivers (VxDs)
> to be installed, which partially -or completely- replace the device
> handling by the original DOS kernel itself. (In fact, typically
> hardly any of the original DOS code is used after the VMM / VxDs
> initalization is over.)
>
> The VMM and a whole bunch of standard VxDs are packaged together
> in a compressed archive file called VMM32.VXD. In a sense, this is
> the real 'core' of Win95. In addition, there can be some other .VXD
> files involved.
>
The "Virtual Machine Mangler!!!" That's what's been crashing in my system!!!
Thanks for the info, I always thought VMM32.VXD was just a memory manager
(it probably does that, among other things.) Of course this knowledge won't
help me to fix it, but it's interesting to know anyway. Thanks!
-- Rich C.
"Great minds discuss ideas.
Average minds discuss events.
Small minds discuss people."
------------------------------
From: [EMAIL PROTECTED] (Rob S. Wolfram)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: What else is hidden in MS code???
Date: 18 Apr 2000 22:30:49 GMT
Reply-To: [EMAIL PROTECTED]
[added COLA]
Erik Funkenbusch <[EMAIL PROTECTED]> wrote:
>Rob S. Wolfram <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> There's enough independent peer review of the Linux source code by many
>> independent individuals to *GUARANTEE* that there is no backdoor in
>> Linux and all it's commonly used open source applications. There is no
>> way you will ever be able to give an equal guarantee for any closed
>> source application.
>
>Then how come nobody DOES guarantee it? Are you willing to put up say, your
>yearly salary that no backdoors have ever or will never be in any Linux
>distribution?
OK, I'll bite. Let me give you a couple of streets headstart. I am
willing to put up my yearly salary that not a single program of the main
stable Debian distribution (v 2.1 aka "slink") contains an exploitable
backdoor (backdoor meaning an *intensional* security breach to gain
unlawful access to remote data), if and only if you are willing to put
up your yearly salary that there is no exploitable backdoor (see meaning
above) in only IIS and Exchange Server (current NT4/W2K versions,
standard installs).
"Main" means everything that resides in the slink/main directory (this
is the DFSG free software in Debian. Slink has 2250 such packages).
Caveat: I am not talking about unintentional programming errors (like
buffer overflows, symlink traps or race conditions.
>Also, if the peer review process is so good, why are new buffer overrun
>errors found so often in this peer reviewed code? It should be bug-free,
>right?
I never said that. Buffer overflows are unintentional programming
errors. With a backdoor, you need to add several lines of code to be
able to just check the constrains for enabling the backdoor. A buffer
overflow generally means that the programmer *forgot* to either check or
initialize the data that's being placed in an array.
Cheers,
Rob
--
Rob S. Wolfram <[EMAIL PROTECTED]> PGP 0x07606049 GPG 0xD61A655D
"I imagine that playing with one's genital piercings
while waiting for a client's disk to fsck or something
would probably not be appropriate." -- 'Skud' in a.s.r.
------------------------------
From: [EMAIL PROTECTED] (Rob S. Wolfram)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: What else is hidden in MS code???
Date: 18 Apr 2000 23:15:38 GMT
Reply-To: [EMAIL PROTECTED]
Drestin Black <[EMAIL PROTECTED]> wrote:
>"Rob S. Wolfram" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Drestin Black <[EMAIL PROTECTED]> wrote:
>> >what else is stuffed in linux source code that non-programmers cannot
>> >decipher? do you trust programmers you never met to check for bugs and
>> >backdoors for you? Who do you think would put them in there?
>>
>> There's enough independent peer review of the Linux source code by many
>> independent individuals to *GUARANTEE* that there is no backdoor in
>> Linux and all it's commonly used open source applications. There is no
>> way you will ever be able to give an equal guarantee for any closed
>> source application.
>
>*GUARANTEE* eh? Would you like to put your money on that? Could you please
>have RedHat and other big IPO money companies swear on cold cash that there
>are NO backdoors in Linux and ALL it's commonly used open source
>applications.
Let me back out a tiny bit here. Even though Redhat, Caldera, Corel et
al use open source products, they are still a single source in the
verification of what they let out (just like any company). I am willing
though, to put my money on Debian, which is not a company but a
volunteer organisation that spreads worldwide. See my reply to Erik for
more gory details.
> I would like a in writing guarantee from all the people you've
>listed below that they have personally read every single line of code,
>understand the full implication of every single function, sub routine,
>object and module, understand how every single byte of code will interact
>with every other byte of coce in every concievable configuration or
>interoperation and under any type of abuse they can imagine (and many they
>cannot) and then guarantee it for me. IF you can do that I will become the
>holy crusader of Linux as the ultimate OS in the universe.
First of all, there isn't a single person alive that has read all source
code that constitutes a GNU/Linux system, so the people below cannot
possibly state anything like that. That's why things are broken up into
pieces, just like there's no microsoft employee alive (I'm sure) that
has read and understood all lines of source code that constitute
Win2000. The overlap of peer review, however, is still enough that I am
confident that any intentional backdoor in a commonly used DFSG-free
application will be spotted within days at most. Even so, I consider it
next to impossible that an exploitable backdoor exists in the current
stable version on Debian. I repeat, *next to impossible*. Can you say
the same of any version of Windows 9x, NT or 2K?
Secondly, given your track record, I would rather not see it happen that
you become a "Linux crusader". It wouldn't do us much good.
>Till then you are an idiot to suggest such a thing and actually put it in
>writing.
I honestly do not consider your namecalling of any value. I dont
consider this comment positivr nor negative. I consider it of no value.
>> BTW, I've met quite a few Linux / GNU coders (Richard Stallman, Alan
>> Cox, Dave Miller, Stephen van de Berg, Rik van Riel, Werner Almesberger,
>> ...) I also met quite a view Debian developers, who *are* people that
>> review and bugfix other people's code for inclusion in the Debian
>> distribution (Wichert Akkerman, Ray Dassen, Bruce Perens, Richard
>> Braakman, Martin Schulze, Kai Henningsen, James Troup and many others).
>
>Hmm... I mean Arnold Swarzennegger once, does that make me a body builder?
>I meant Bill Gates, does that make me a billionare?
And what is this supposed to mean? I just demonstrated that the
communication lines between developers and users is *magnitudes* shorter
than in the average company/CSS situation. I just refuted the fact that
*YOU* stated "review by people you've never met".
>> How many Windows Kernel coders have you met?
>
>4 actually...
>
>when did you talk to Linus last?
I never did. When did you?
Cheers,
Rob
--
Rob S. Wolfram <[EMAIL PROTECTED]> PGP 0x07606049 GPG 0xD61A655D
... then you wish to copulate?
-- Seven of Nine, stardate 51186.2
------------------------------
From: [EMAIL PROTECTED] (Rob S. Wolfram)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: What else is hidden in MS code???
Date: 18 Apr 2000 23:36:28 GMT
Reply-To: [EMAIL PROTECTED]
[cola added]
Erik Funkenbusch <[EMAIL PROTECTED]> wrote:
>Having source does not guarantee the abscence of a back door. Back doors
>can be quite obfuscated and hidden in otherwise legitimate code. They can
>also be in things you can't see. For instance, the legendary compiler
>back-door, which inserted a back door when a source file called login.c was
>compiled.
Yes, that's a nice case, and I've mentioned it in quite a few posts
already. Do take note, however, of the fact that this was true only for
the C compiler and login.c as delivered with the AT&T Unix OS back in
the 70's. There was only a single "vendor" for the OS which included
both programs, so it was possible. Thompson's cc was not capable of
adding the trojan to gcc, because that was built from scratch could
therefor not confirm to the constrains that would recognize a recompile
of cc.
>The source was clean, but a back door would still exist. Also,
>since most linux distributions are distributed in binary form (with source)
>there is no guarantee that the binary is the same as the source that's
>shipped with it. Yes, you could recompile everything, but how many people
>do that?
At least the debian developers do.
> I seem to recall hearing about some compromised binaries that made
>it into some linux distrubtion sites about 18 months ago or so.
I didn't hear that, but it is very possible when the control of the
distribution is limited to a small centralized group, like a company
(think Redhat, Caldera, TurboLinux). I don't consider that possible with
a decentralized organisation like Debian.
I do recall that trojaned (source) tarballs for the tcp wrappers were
placed on the FTP site. This was discovered within hours, and I haven't
heard of anyone who accidentally used the trojaned version. This might
gave been around that timeframe.
Cheers,
Rob
--
Rob S. Wolfram <[EMAIL PROTECTED]> PGP 0x07606049 GPG 0xD61A655D
The number of UNIX installations has grown to 10, with more
expected.
-- The Unix Programmer's Manual, 2nd Edition, June 1972
------------------------------
From: [EMAIL PROTECTED] (Rob S. Wolfram)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: What else is hidden in MS code???
Date: 18 Apr 2000 23:41:18 GMT
Reply-To: [EMAIL PROTECTED]
[cola added]
Christopher Smith <[EMAIL PROTECTED]> wrote:
>"Rob S. Wolfram" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> #1 - The probability that there's a backdoor in any Microsoft OS or
>> application is about equal to the probability that there's a flight
>> simulator hidden in a spreadsheet program.
>
>Proof for this conclusion ?
It's not a conclusion, it's a statement. It's not even my statement, but
I wholeheartly agree. Read between the lines.
>> #2 - There's no way you can proof the absence of a backdoor in FP98
>> short of examining the source, which can only be consisdered possible
>> if you have a source license.
>
>Which, I'm usre, is possible if you want to pay for it.
Of course it is. <Hey Drestin, do you have the source to FP98?>
>> #3 - Using open source software does guarantee you the absence of back
>> doors. It also guarantees that security algorithms are properly
>> implemented and does not rely on STO.
>
>How does it guarantee this ? Where is the guarantee there's no conspiracy
>by all the people who can actually understand the code ? How are the people
>who *can't* do the code review themselves (ie the vast majority) supposed to
>be reassured ?
Were you by any chance the writer of the plot for "The Matrix"?
Cheers,
Rob
--
Rob S. Wolfram <[EMAIL PROTECTED]> PGP 0x07606049 GPG 0xD61A655D
The Wright Bothers weren't the first to fly. They were just the
first not to crash.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
