Very Computer

http://www.theregister.co.uk/content/8/19526.html

Now how many companies use this to allow their employees to
access their email while offsite? How many of these companies
will hear about the patch far less install it. It doesn't
matter what SW MS develop they are full of security bugs.
Even their ISA firewall has had 2 security bugs found already
the last of which was a total denial of service (a polite
way of saying it crashed :-)

--
Over 100 security bugs in Microsoft SW last year. An infamous
record. The worst offending piece of SW, by far, IIS. 2001 isn't
looking any better.

...but Microsoft is a **marketing** company....they know
nothing about software.

Maybe they know a bit about illegal monopolies, but asking
them to produce high quality, secure, user-friendly software
simply ignores twenty years of terrific marketing and twenty
years of lousy software.

Sean
====

In comp.os.linux.advocacy, Sean

 wrote
on Fri, 08 Jun 2001 02:04:42 GMT

Quote:>...but Microsoft is a **marketing** company....they know
>nothing about software.

I'd quibble about that; it's clear that Microsoft knows quite
a bit about software; one doesn't maintain NT without at least
a working knowledge of how to code in C, C++, Visual Basic,
or what not.

Of course, it's not all that *good*, and Microsoft may have
been trapped by their own success.  One issue is that they
have to make sure that their next release of Windows Whatever
supports their applications, developed on the previous
release of Windows Whatever, and DOS.

This is a thankless task, made worse by their dependence on the
286 at the time (there was no elegant method by which to go from
protected back to real mode on that chip; Windows selected an ugly
hack but may have had no choice in the matter), and it was only
when the 386 came out that a relatively flat address space
became available -- and Linus created Linux on that chip.
(Xenix ran on the 286, and ran reasonably well, athough I'm
not sure if it could allocate more than 64k in a contiguous block.)
I forget whether the 386 or 486 introduces the V86 concept --
I suspect the 386 did.

In short, Windows required binary-code upward-compatibility.

Linux isn't quite that restrictive, although ideally it
would have upward-compatibility, as well.  However, since the
source code is usually available, one can "roll their own",
in many cases.  (Of course, this requires a certain mindset;
"./configure && make depend && make" is a little harder --
although not that much harder -- than "double-click on SETUP.EXE".)
Some of the savvier individuals can also make modifications.

There's also the 16-vs-32-vs-64 issue; Microsoft decided to
go with fixed message sizes, for whatever reason -- a bad
decision in retrospect.  But it's not clear the other decision --
using "X *" pointers, basically -- might have fared better, or not.
Linux is far cleaner in pointer-handling, internally,
although the kernel might be a smaller space (a similar compilation
space in NT might include most of the GDI).  Note also that
the PDP 11/70's pointers could fit in a short.

And then there's the wildcard: Java.  Were everyone to immediately
adopt Java, it may no longer matter what's underneath -- this must
scare Microsoft, judging from their response (.NET and C# et al).

Quote:

>Maybe they know a bit about illegal monopolies, but asking
>them to produce high quality, secure, user-friendly software
>simply ignores twenty years of terrific marketing and twenty
>years of lousy software.

Lousy, virus-vulnerable, slow (relative to other solutions),
but convenient to use (if one doesn't stray too far),
pretty (in a rather kitschy sort of way) and profitable.

I'm not sure what that tells us about ourselves.

[rest snipped]

--

EAC code #191       39d:12h:53m actually running Linux.
                    Be paranoid.  Everyone else is.

Quote:> In comp.os.linux.advocacy, Sean
> Linux isn't quite that restrictive, although ideally it
> would have upward-compatibility, as well.  However, since the
> source code is usually available, one can "roll their own",
> in many cases.  (Of course, this requires a certain mindset;
> "./configure && make depend && make" is a little harder --
> although not that much harder -- than "double-click on SETUP.EXE".)
> Some of the savvier individuals can also make modifications.

What is so frigging hard in putting this
./configure && make depend && make in a script and calling it setup.script,
and making the UI run it on dbclick?

Quote:> And then there's the wildcard: Java.  Were everyone to immediately
> adopt Java, it may no longer matter what's underneath -- this must
> scare Microsoft, judging from their response (.NET and C# et al).

I think that .NET is like Java should've been. (Not dvelling on the
techincaleties here, I'm talking about general attidue)
It provide an easy way to port existing applications to the new platform, it
provide number of languages, and allows you to interact with the underlaying
OS. (IIRC, Java didn't have JNI in its first incarnation)

I've a friend that does Java programming. (I know Java enough to recognize
the syntax, and maybe do some simple apps, so I don't have 1st hand
experiance here)
He says that C# (personal experiance here is like my Java's.) is like a
better Java.

I must say that the most glaring defect I've found in Java is the case -
break statement. Why *allow* this error-prone process?
Java eliminate many of the C/C++ defects (usually by saying "this cause
bugs, it wouldn't be on Java"), why not take this out as well?

Said Sean in alt.destroy.microsoft on Fri, 08 Jun 2001 02:04:42 GMT;

Quote:>...but Microsoft is a **marketing** company....they know
>nothing about software.

>Maybe they know a bit about illegal monopolies, but asking
>them to produce high quality, secure, user-friendly software
>simply ignores twenty years of terrific marketing and twenty
>years of lousy software.

How exactly do you tell the difference between marketing and
monopolizing, Sean?

--
T. Max Devlin
  *** The best way to convince another is
          to state your case moderately and
             accurately.   - Benjamin Franklin ***

In comp.os.linux.advocacy, Ayende Rahien

 wrote
on Fri, 8 Jun 2001 20:59:26 +0200

[1] That would be up to the package author.
[2] Different file managers have different methods of indicating
    a script -- although most likely the only thing looked for is
    the presence of the appropriate 'x' bit.
[3] The icon for "setup.sh" is similarly constrained; there's no elegant
    method by which to show that it's different than, say,
    "fubar.sh" or "a_tool" (which is an executable file).

Quote:

>> And then there's the wildcard: Java.  Were everyone to immediately
>> adopt Java, it may no longer matter what's underneath -- this must
>> scare Microsoft, judging from their response (.NET and C# et al).

>I think that .NET is like Java should've been. (Not dvelling on the
>techincaleties here, I'm talking about general attidue)
>It provide an easy way to port existing applications to the new platform, it
>provide number of languages, and allows you to interact with the underlaying
>OS. (IIRC, Java didn't have JNI in its first incarnation)

It's worse than that; Java has no elegant method of calling arbitrary C++
code.  It has to do the following.

[1] Construct -- interpretively! -- the argument list to the JNI code,
    which must have a special signature.  For example, strings are
    'jstring *', objects are 'jobject *',  etc.  This is a slow process,
    apparently.
[2] Call the JNI stub routine.
[3] The JNI stub routine code now has to do certain things, in order
    to create strings, manipulate objects, arrays of bytes, etc.
    These are documented fairly well, but are still slightly painful;
    what's worse is that these are all C-oriented.  (There are some
    good reasons for this; C++ is still not all that standard in certain
    endeavors.)

C#/.NET will -- apparently -- be far more straightforward, at least
in terms of existing models such as DCOM+.  On the other hand, DCOM+
isn't all that straightforward to me personally.

And C#/.NET will be faster; there will be no interpreted code
anywhere in the system.  (Ultimately, Java won't have interpreted
code either, but Hotspot does optimizations on the fly only, and
it's not clear whether Sun has standardized on a compiler switch
for storing precompiled JIT-compatible code, or not.)

One advantage Java has: it is multi-platform, unlike the CLR
of C#/.NET.  This may be fixed in time as creative hackers implement
various CLR's for non-Microsoft platforms.  It's even possible
Microsoft will release CLR source code -- after a few years.
(Note that C#/.NET will only be multiplatform in the sense that
C++ is: one can call arbitrary components on arbitrary machines, but
unlike Java one cannot transplant binary code without
special considerations.  Source code can be easily transported,
of course.)

Quote:

>I've a friend that does Java programming. (I know Java enough to recognize
>the syntax, and maybe do some simple apps, so I don't have 1st hand
>experiance here)
>He says that C# (personal experiance here is like my Java's.) is like a
>better Java.

It's a faster system, perhaps.  Better is in the eye of the beholder;
Java in particular is better if only because it's out and being used.
C#/.Net, by contrast, is at best in beta.

Quote:

>I must say that the most glaring defect I've found in Java is the case -
>break statement. Why *allow* this error-prone process?
>Java eliminate many of the C/C++ defects (usually by saying "this cause
>bugs, it wouldn't be on Java"), why not take this out as well?

Indeed; they could have gone with the Pascal model, which requires
a single statement after each label (there are some minor syntactic
differences:  case X in '1': begin ... end ... end; as opposed to
switch(X) { case '1': { ... } break; ... } ).  It may be because they
wanted the 'case' keyword and the lack of a break statement may
have proved confusing when moving from Java to C++ -- if one
were to use Java as a * prototyping tool.

On the other hand -- it does introduce that rather * bug you
speak of, the "oops, I did another clause".

--

EAC code #191       40d:10h:43m actually running Linux.
                    This is a .sig.

Quote:> In comp.os.linux.advocacy, Ayende Rahien
> >> And then there's the wildcard: Java.  Were everyone to immediately
> >> adopt Java, it may no longer matter what's underneath -- this must
> >> scare Microsoft, judging from their response (.NET and C# et al).

> >I think that .NET is like Java should've been. (Not dvelling on the
> >techincaleties here, I'm talking about general attidue)
> >It provide an easy way to port existing applications to the new platform,
it
> >provide number of languages, and allows you to interact with the
underlaying
> >OS. (IIRC, Java didn't have JNI in its first incarnation)

> It's worse than that; Java has no elegant method of calling arbitrary C++
> code.  It has to do the following.

> [1] Construct -- interpretively! -- the argument list to the JNI code,
>     which must have a special signature.  For example, strings are
>     'jstring *', objects are 'jobject *',  etc.  This is a slow process,
>     apparently.
> [2] Call the JNI stub routine.
> [3] The JNI stub routine code now has to do certain things, in order
>     to create strings, manipulate objects, arrays of bytes, etc.
>     These are documented fairly well, but are still slightly painful;
>     what's worse is that these are all C-oriented.  (There are some
>     good reasons for this; C++ is still not all that standard in certain
>     endeavors.)

There is another reason for this, I think.
If you can use C, you can do anything you want, all the language I'm
familiar with has hooks to integrate with C code.

Quote:> And C#/.NET will be faster; there will be no interpreted code
> anywhere in the system.  (Ultimately, Java won't have interpreted
> code either, but Hotspot does optimizations on the fly only, and
> it's not clear whether Sun has standardized on a compiler switch
> for storing precompiled JIT-compatible code, or not.)

This is another thing I don't understand, having binary compatability is
nice, but why not do one of the following:
A> Encourage compiling to binary. (Mere source code portability is a great
thing)
B> Keep the .class files, but create a native executable when first run,
next time the class is being run, use the executable, don't interrupt the
code.

I understand that .NET works as B suggests, IIUC.

Quote:> One advantage Java has: it is multi-platform, unlike the CLR
> of C#/.NET.  This may be fixed in time as creative hackers implement
> various CLR's for non-Microsoft platforms.  It's even possible
> Microsoft will release CLR source code -- after a few years.
> (Note that C#/.NET will only be multiplatform in the sense that
> C++ is: one can call arbitrary components on arbitrary machines, but
> unlike Java one cannot transplant binary code without
> special considerations.  Source code can be easily transported,
> of course.)

I think that it will be cross platform, the ECMA demand it for it to be
standartize, and MS apperantly really wants that.
I'm a little surprised that they announced that they will have a Linux
implementation, I expected a Mac implementation first.

Quote:> >I must say that the most glaring defect I've found in Java is the case -
> >break statement. Why *allow* this error-prone process?
> >Java eliminate many of the C/C++ defects (usually by saying "this cause
> >bugs, it wouldn't be on Java"), why not take this out as well?

> Indeed; they could have gone with the Pascal model, which requires
> a single statement after each label (there are some minor syntactic
> differences:  case X in '1': begin ... end ... end; as opposed to
> switch(X) { case '1': { ... } break; ... } ).  It may be because they
> wanted the 'case' keyword and the lack of a break statement may
> have proved confusing when moving from Java to C++ -- if one
> were to use Java as a * prototyping tool.

Actually, I think that they should've kept the switch(X) { case... version,
but allow ranges, which is the reason this was allowed in the first place.

Quote:> On the other hand -- it does introduce that rather * bug you
> speak of, the "oops, I did another clause".

I had that about three weeks ago, *.

Said Ayende Rahien in alt.destroy.microsoft on Sun, 10 Jun 2001 03:00:24
in
   [...]

Quote:>I think that it will be cross platform, the ECMA demand it for it to be
>standartize, and MS apperantly really wants that.

Well, MS apparently intends to use .NET to monopolize all platforms, not
just the PC, so it certainly seems likely they'll try for enough limited
cross-platform support to either embrace or destroy any alternative
platform.  And rather certain they will fail.

Quote:>I'm a little surprised that they announced that they will have a Linux
>implementation, I expected a Mac implementation first.

Just goes to show how little you actually understand about .NET.  It
ain't technology, Ayende; it is a strategy to monopolize.  It doesn't
even have a real business case.

--
T. Max Devlin
  *** The best way to convince another is
          to state your case moderately and
             accurately.   - Benjamin Franklin ***

In comp.os.linux.advocacy, T. Max Devlin

 wrote
on Sun, 10 Jun 2001 06:11:20 GMT

The profit's in the server side; if MS can establish a monopoly
there, they've got it made.  :-)

At least, until someone gets annoyed enough to write something that
will allow for Linux (and Microsoft) users to connect to Linux servers
and sell it to service providers for a fee lower than .NET's
going rate -- whatever it is.

(Apache may very well be one vehicle for that.)

[.sigsnip]

--

EAC code #191       42d:06h:10m actually running Linux.
                    It's a * of one.