Novell makes enemies, but then denies their existence or importance. Derstandar.at, a Web site which recently did an interview with Miguel de Icaza (further analysed in our Web site), has an new interview with Nat Friedman, whom we sometimes refer to as Novell's second Microsoft apologist. The interview touches on many technical things, but it also discusses the backlash. Below lies a small fragment.

derStandard.at: Given the strong negative reactions lot's of people in the community showed to the Microsoft deal, do you think it'll get more difficult for Novell to get their stuff upstream?

Nat Friedman: I haven't seen that until now, I mean there have always been flamewars in the Linux community, it's part of the community culture. Sure there are consequences for Novell in the community resulting from the deal, we have seen that, but not in the respect that someone says "Well, Novell as a business did this agreement with Microsoft, so we won't accept their patches". And most of that negative sentiments don't seem to come from the people who accept patches anyway, they come from people who have a sort of "professional commentator" role in the community.

It is easy to disregard critics and dismiss all the backlash. It is truly a convenient excuse. The only thing louder than words, however, is the effect on one's wallet. When/if Novell's sales sink, perhaps then the company will realise that its new strategy has not worked. In fact, it has also hurt other Linux companies, which Novell ought to have befriended, rather than provoke anger.

It is worth repeating the fact that Novell is dealing with a rival which has viciously attacked it for over a decade, sometimes through FUD and often through technical sabotage. It continues to this date. What would Ray Noorda, who passed away last year, say if he were still among us? The reality is shocking. Novell invites a fierce and aggressive rival to its own conference and the relationship is not reciprocal. From the thousands of court exhibits, for example, one would find E-mails such as this one [PDF], illustrating what the plaintiff described as "technical sabotage" and "hidden APIs":

From: Denns Foster [of Novell] To: Dave Wilkes; John Galley; John Robertson Date: Tue, Jun 9, 1998 3:46 PM Subject: GroupWise vs. Outlook 98

On 05-21-98, I called our Microsoft Premiere Support number to request help with the conflict between GW and Outlook 98. I spoke to Barbara Thomas who generated case SRX9805216011611.

My initial request was that MS consider it a bug that Outlook 98 by default installs using the "Internet Only" option for e-mail services. I told her that it was our opinion that the Outlook 98’s setup program should inspect the system it’s being installed on and choose the "Corporate or Workgroup E-mail" option by default if the Windows Messaging System (WMS i.e., MAPI) was installed and profiles have been defined and choose the "lnternet Only" option by default otherwise. This would probably eliminate 90% of the complaints we get as I’m sure most people when reading the screen containing these options don’t realize what’s being said and simply go with the default as being "safe".

On 05-28-98 I received a call and e-mail from Barbara telling me that my request had been investigated and Adam (I don’t recall having heard his last name) from Microsoft would be contacting me. On either the 28th or 29th, I got a call from Adam. He told me that MS views the way Outlook 98 was operating as a "Feature", not a bug. They would take my request and submit it as an "Enhancement" for future development. I discussed/argued the issue with Adam for several minutes, explaining how by defaulting to "lnternet Only", Outlook 98 ends up breaking a GroupWise installation that had up to the point Outlook 98 was installed, worked fine. I explained to him that the setup screen made no mention of MAPI services being changed and/or broken for applications that need them. His response was that the user is given an ample description of what was going to happen and that we should "educate" our users to make the correct selection during Outlook 98’s setup. All in all, I’d describe my conversation with Adam as equivalent to talking to a rock.

I believe that the changes I made to the address book’s initialization flow last week is probably the best that we can hope for without Outlook 98 changing. We may want to add something to our README about this. The check/change I put into Surge for Outlook 98 could easily be retrofitted into a Jolt CPR build as well, assuming we don’t mind the resource the changes.

FYI: Before I made the changes mentioned above, when installing Outlook 98 using the "lnternet Only" default option, the following problems were encountered:

- No Novell address book service providers are available;

- There is no way to add them to your profile (the old MAPI profile dialog has been replaced by something Outlook 98 specific).

- Sometimes (usually?), our call tologin to MAPl fails (I don’t fully understand why this happens).

- When we can login. Outlook 98’s LDAP service provider causes us grief because of its problems implementing the MAPI APIs we use. The problems here include:

Calls to IMAPlTable::Restrict GPF when passed NULL for the restriction. This is the only documented way in MAPI to delete a restriction.

The way we use MAPI for LDAP services for Boldon James and Nexor doesn’t work with the Outlook 98 provider. I’ve found two areas that we could/should change that should be compatible with the Boldon James and/or Nexor providers.

Dennis.

There are some better examples, but this requires a lot of digging. The amount of material is overwhelming and it's all there so that Novell, as well as others, can take a lesson from history.

Update: here is another exhibit, transcribed by 'Doug Mentohl'.

From: John Gailey [of Novell] To: Michael Buck; Rex Olpin Date: Wed, Jun 10, 1989 2:20 PM Subject: Win98 and Microsoft MAPI Service

In a clean install of Win98 (not over an existing Win95 installation), the Microsoft Windows Messaging System (MAPI) is not installed. Groupwise 5.2 will auto-detect this fact during install and will attempt to install the MAPI system by accessing the Win95 CD. However, the MAPI system has been moved to a different location on the Win98 CD, causing the GroupWise 5.2 install to fail in its attemt to install MAPI.

End-users can manually install the MAPI system from the Win98 CD. To do so, they must run: \tools\oldwin95\messages\us\wms.exe

This self extracting executable will install the MAPI subsystem (and unfortunatly, will also install MS exchange Inbox and MS Exchange Post Office.)

Rex, we need a TID written up for this for our current GroupWise 5.2 customers.

Michael, we need a fix for this for the next GroupWise 5.2 service pack.

this is anti-competitive

Aaarghh!!!

- John Galley CC: Bill Street; Craig Miller

From a different angle and a different problem, here is another exhibit [PDF].

From: Gary Hein [of Novell] Date: Sat, May 30, 1998 3:34 PM Subject." Fwd: ND$ for NT / LDS Church

Don’t know if you guys have seen this document yet, but it’s just another example of lies propagated by MS. There are some very disturbing remarks, including:

Although it is possible to establish bi-directional trust, the trust connection can not be used for administering remote, unmigrated domains. This means that centralizing management with NDS for NT requires a wholesale conversion of the entire enterprise

GH: False

Note that NT servers would need to run IPX/SPX to support NDS for NT as well as TCP/IP to access other network resources and to comply with current standards.

GH: False - NDS for NT works over IP - no need to add IPX. This is a scare tactic.

Service Pack updates are questionable at best. MCS has not yet released Service Pack 4.0, however we suspect it will replace the existing samsvr.dll. To protect against NT Service Packs replacing samsrv.dll, NDS for NT checks at shutdown time and replaces samsrv.dll with the Novell version. MCS believes potential for failure is very high, as soon as any rill starts depending on new exports from samsrv.dll. Replacing this one critical dll could case the system to fail to boot and recovery could be very difficult.

GH: Perhaps advance knowledge of SP4?

Microsoft has repeatedly stated that it will support their NT customers and NT’s basic functionality, but in areas that NDS touches, namely security and authentication, Microsoft will refer customers to Novell. This has the potential of creating some confusion in the resolution of issues revolving around security and authentication.

GH: Scare tactic

Also, comments from PeopleSoft should be solicited to see if PeopleSoft and Tuxedo are supported in environments where NDS for NT is in use as well as the IntranetWare client.

GH: Is it possible that MS is telling NT developer that they should not support their products with NDS for NT?

Windows NT has a feature where anonymous Iogon users can list domain user names and enumerate share names. Customers who wanted enhanced security requested the ability to optionally restrict this functionality. Windows NT 4.0 Service Pack 3 and a hotfix for Windows NT 3.51 provide a mechanism for administrators to restrict the ability for anonymous logon users from obtaining system information. These anonymous connections are also known as NULL session connections. During the installation of Novell’s NDS for NT, the samsrv.dll is replaced. Novell NDS for NT currently does not include support for restricting anonymous connections. MC€£ see this deficiency as a security weakness.

GH: This is the Red Button attack, which MS ’claims’ is fixed with SP3, but really isn’t. Again, this is completely incorrect - using NDS for NT will not impact the security flaw mentioned in this document.

Anyhow - I don’t know if this is of any use to you but I thought I’d forward it over anyway. Thanks,

Gary