>> That would require GPL incompatible extensions to the kernel
Sorry, but I doubt that. MS could GPL any extensions to the kernel that
would allow them to interface anything they wanted, and offer a second CD or
download for closed extensions.
>>The problem with drivers is that they must be GPL.
I think they really don't have to be GPL. There's plenty of options for
distribution of closed drivers. Nvidia is a good example, as you point out.
>>Microsoft can't remove binary and API compatibility.
Won't have to. I'd expect them to limit it to x86, and it doesn't have to
be 'real compatible'. MS wins if Windows users try it and prefer Windows.
If it comes across as a poor substitute for Windows, consumers would assume
all the buzz about Linux is hype. You seem to be assuming they want a
proper implementation of Linux. I assume they do NOT - it's an embrace,
extend, and wreck it strategy.
>>It's is technically infeasible for them to develop an NT release with full
dual-32 and 64-bit libraries like Linux.
I guess I'm confused. NT was first developed on 64-bit Mips processors, and
I had a DEC Alpha with 64-bit NT years ago, and the Autodesk programmers I
worked with certainly thought it was the bomb (AutoCAD uses 64-bit floating
point values for it's vectors). So, at one time, NT _was_ 64-bit, but I've
never had a chance to look at the source, so I can't comment with certainty.
I suspect you know more than I about the what's really under the hood, or at
least what appears to be there. And I think we are in agreement about most
of these issues. Where we differ is what MS's business intent is, and how
they can go about it. Remember, HP once had written a custom HAL that
allowed them to run NT Server on top of their mainframe OS. This would
suggest MS could take an older version of NT and stick it on top of Linux
and call it MS Linux. And I don't believe they would be shy about doing
things that might cause some of the GPL copyright holders to get involved in
a long, drawn out, expensive lawsuits, even if MS expected to lose. Look at
their SCO settlement as an example.
Thanks for the interesting and detailed comments.
Ken Elliott
=====================
-----Original Message-----
From: slug@nks.net [mailto:slug@nks.net] On Behalf Of Bryan J. Smith
Sent: Friday, September 10, 2004 5:26 PM
To: slug@nks.net
Subject: [SLUG] RE: OT: M$ deals the final blow
From: slug@nks.net [mailto:slug@nks.net] On Behalf Of Pete Theisen
> Hi Ken!
> What will you bet we see a Linux distro from the Great Satan in the
> next
> 5 years? Yes, they will charge for it as do a number of others, but
> dammit, your printer, sound card and modem will work.
That would require GPL incompatible extensions to the kernel, and open
Microsoft up to a lawsuit by all copyright holders on the kernel.
Understand that Linux developers ship 100x as many drivers as Microsoft
itself does. Microsoft merely includes drivers from OEMs that release them.
It has a formal signature process now, but the OEM still does "all the
work." OEMs can released binary-only drivers in NT.
The problem with drivers is that they must be GPL. As such, the source code
must be published. Publishing the source code of software-only drivers is
largely impossible. Not because of the OEMs, but because the OEMs typically
license from a 3rd party. Since that source code is the "crown jewels" of
that 3rd party, they are not about to see it disclosed.
Ironically, with all these OEMs licensing the same 2-4 3rd party source
code, if they'd only switch to the full Linux model, they wouldn't have to
license. Thus far, only HP and a few others have signed up -- not even IBM
ironically, except where it sells their big items, because even IBM
outsources much of its system development.
The only way "around" the GPL is to have the end-user build the driver.
If the end-user builds the driver, and only uses its internally, that abides
by the terms of the GPL. So an end-user can built a non-GPL driver -- which
is how some of these approaches work (e.g., nVidia, Intel, etc...).
On Fri, 2004-09-10 at 16:16, Ken Elliott wrote:
> Under SuSE, they already do...<grin>
Just remember, any Microsoft port of MS Office to Linux will have as many
document porting issues as MS Office for MacOS does as well. The problem
isn't so much sending to Mac, but sending back. Most MS App for Windows
software developers don't concern themselves with data alignment, whereas
MacOSX developers have to.
> I used to think of Novell and IBM and the greedy, controlling players.
> Microsoft (at that time) was open and friendly. They gave their user
> interface to OSF for use on Unix, and NT Server 3.5 was for
> _unlimited_ users. Sadly, that has all changed as the more
> profit-minded guys took over.
Or as I said earlier, "NT became DOS' bitch" about 10 years ago. The same
has yet again happened with Longhorn. ".NET has become [bastard] Win32's
bitch."
> I have no doubt you'll see a new and improved Linux from Microsoft,
> featuring .NET, and Windows-look-alike GUI, ability to run MS apps (at
> least
> .NET) and the ability to connect to NTLM shares. All for the low low
> price of .... About the same as Windows....
Not unless Microsoft just repackages what people already do. Mono works
quite well right now. They'd just leverage Novell's work. Heck, they'd
probably license it just like they re-licensed Java.
Microsoft can't remove binary and API compatibility. They also don't have
the manpower/capability (yes, this is _very_true_) to re-invent everything
atop of GNU/POSIX. They could only use what others have created.
So I consider the effort impossible.
> I suspect the .NET framework and NTLM access
The two are distinctly different.
CIFS/SMB (NTLM is only considered the technical term for authentication) is
still very much "Chicago bastardized" Win32.
The .NET framework has been reduced in Longhorn to what Microsoft is now
calling WinFX. Namely, the Avalon desktop and Indigo Internet Services over
Win32, the GDI and IIS-IE respectively.
Avalon will bring about the same requirements of Win32 that caused NT 4.0 to
be "cracked." Indigo will suffer the same fate of a Java sandbox atop of
Win32 -- it just can't be done securely.
Win32 is here to stay. Microsoft cannot even attempt to change. If they
tried to ship a "pure .NET" OS like they tried to with NT for Win32 prior,
it would only suffer the same fate and cost to develop without return.
> will become the new MS-Tax that can be applied to any OS, not just
> Windows.
The only way Microsoft will try to tax people is with patents. They have
been hijacking patents in their licensing agreements. That's probably the
scariest issue right now.
The overwhelming majority of Microsoft's Win32 codebase only runs on
Win32 -- IA-32 (x86). Even the XP 64-bit Edition is completely 32-bit,
except it puts the x86-64 processor into "Long" mode. Nearly all the
libraries and subsystems are 32-bit, and use Win32-on-Win64 (WoW) at a
performance hit. It's is technically infeasible for them to develop an NT
release with full dual-32 and 64-bit libraries like Linux.
That exercise is left to programs who want to ship their own 64-bit support.
Otherwise, even if they are 64-bit, they utilize almost entirely 32-bit
libraries.
Microsoft Win32, by its very nature, is not 64-bit clean -- let alone it is
data-alignment ignorant and stuck at x86. That is a continual problem.
Visual Studio through version 6, still accounting for some 90% of the
vertical app development on Windows, uses DOS Int20-3Fh, Win16 and direct
Win32 calls that bypass the NT model.
Apple maintains a full port of MacOS X in-house to x86 and x86-64 to avoid
any future porting issues. Sun has also done the same with Solaris, and
will likely be thanking itself very soon. GNU by its very nature is very
portable -- and anyone who writes GNU software learns who it is important to
do so very quickly once someone ports it to non-x86.
> And it seems to make good business sense to me - any MS.NET app will
> run on any OS with the proper MS.NET framework installed.
The problem is that Microsoft has basically "given up" on .NET other than a
basic application technology. It still requires massive amounts of Win32
underneath. Even supposed "pure .NET apps" still have Win32 VM/scheduler
tie-ins and x86 requirements -- so much so that WINE/WINELIB is used in Mono
to emulate these portions.
> Why not let all the open-source guys develop their next OS for them?
That's exactly what Novell is doing. After 10 years of screwing around with
UNIX, they finally got it.
I'm sure Ray Noorda fired off an e-mail, "I told you so 10 years ago."
There's nothing wrong with value-added atop of Linux. Most commercial Linux
distributors do this. Leverage commodity, building a specialized solution
atop. It's a very smart business model.
The only major commercial Linux distributor I know of that does not is Red
Hat. Red Hat not only releases all source code of anything it writes, even
original or bought out products, but it almost always does it GPL. With the
development revenues from their former Cygnus division, maintainer of the
GNU Compiler Collection (GCC) which they offer dual-GPL/commercial licenses
and support, and newer revenues from their re-structured commercial
offerings, they don't have to value-add in their view.
--
Linux Enthusiasts call me anti-Linux.
Windows Enthusisats call me anti-Microsoft.
They both must be correct because I have over a decade of experience with
both in mission critical environments, resulting in a bigotry dedicated to
mitigating risk and focusing on technologies ...
not products or vendors
--------------------------------------------------
Bryan J. Smith, E.I. b.j.smith at ieee.org
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages posted
are those of the author and do not necessarily reflect the official policy
or position of NKS or any of its employees.
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:19:55 EDT