Jeremy Allison Calls Microsoft Dangerous Elephant 306
oranghutan writes "At the annual Linux.conf.au event being held in Wellington, NZ, one of the lead developers for the Samba Team (and Google employee) Jeremy Allison described Microsoft as 'an elephant that needs to be turned to stop it trampling the open source community.' Allison has been an outspoken critic of the vendor since he quit Novell over a deal it did with Microsoft that he saw as dangerous to open source intentions. And now he has evolved his argument to incorporate new case studies to explain why Microsoft's use of patents and its general tactics on free software are harmful.
Linux taking on Microsoft :) (Score:1, Informative)
'Linux' isn't trying to take on Microsoft, it's the other way around. A company with a long time enmity towards anything open source and not adverse to using any dirty trick to get its own way.
Comes v. Microsoft [groklaw.net]
Microsoft EDGI: How It Works [boycottnovell.com]
Re:It wouldn't be a problem (Score:5, Informative)
Um...
SAMBA wasn't developed as a clone or a replacement for anything Microsoft produced. In fact, SAMBA (then known as server, or nbserver) predated Windows NT release.
Microsoft themselves offered patches early on (1993), even before the product was named SAMBA. Probably because it was advantageous to Microsoft. Simply, the idea was to have Unix boxes act as file servers for Windows. Windows didn't support NFS (directly - SMB is the native protocol - Beame and Whiteside supported NFS on NT in 1994, but this would be an extra-cost client expense).
Of course, eventually NT "grew up" and began to support more infrastructure operation, but, even today, SAMBA is a vital part of the "Windows Enterprise". If you are running Power or Sparc on servers and want to share to Windows, it's really the way to go.
AT&T offered a licensed Microsoft SMB implementation (Advanced Server for Unix), which was sub-licensed by some Unix vendors (SUN, HP, SCO, and possibly others). Unfortunately the quality of the implementation was questionable. SUN spent two years cleaning up the code before releasing it as PC-Netlink (HP and SCO may have offered it earlier). Microsoft didn't release the NT SMB code to AT&T until 1994. SUN released PC Netlink on Feb 1, 1999.
Which meant that from 1992/3 to 1999, the only way to run an SMB native file server on SUN was to use SAMBA. (You could have run NFS using Beame & Whiteside/Hummingbird).
How is SAMBA copying anybody here? (if we assume that a Windows NFS client had been made available by Microsoft, SAMBA would never have been popular).
Re:Flamebait of a story (Score:3, Informative)
How do you moderate a story Flamebait?
You vote it down in the firehose.
Re:It wouldn't be a problem (Score:3, Informative)
Maybe he is (gasp!) in the industry in which this takes place? Rumors of this occuring are not exactly new.
Re:It wouldn't be a problem (Score:3, Informative)
Of course Microsoft had an SMB implementation! That's (partly) the point.
SMB (Lan Manager) was the native file sharing for Windows (Windows 3.11 for Workgroups and DOS). Would you want to run a company using Windows 3.11 for Workgroups or DOS as your server? Go ahead. SAMBA simply acknowledges that people want to use DOS and Windows on the client.
The competition would have been Netware, and its client side interface.
LAN Manager on OS/2 was probably the direction seen by most as the "future" of SMB. Some wanted Unix servers, instead. As an aside, rank DOS, Windows 16 bit, OS/2 1.x, OS/2 2.x, Windows 9x, and Windows NT (XP, Vista, 7) and Unix as server level OSs. Which would you have preferred back in '94? "LAN Manager" code didn't exist for anything less that OS/2 1.x; the file sharing code in DOS and Windows 16 bit was probably quite a kludge (both DOS and Windows 16 bit use pre-emptive multi-tasking, and the networking was based on the IBM PCNet code). LAN Manager was released in 1987 to compete with Netware. Note that OS/2 Lan Manager was updated when Windows NT 1.0 was released to remain compatible (in 1993).
So, the importance of NT was that it provided a jump-off point for Microsoft and AT&T to produce a Unix SMB server. Note that most consider this to be of poor quality (I referenced the SUN PC Netlink experience in support of this assertion). It is not clear to me if an Enterprise quality server implementation of SMB existed before NT; at least, not one from Microsoft (unless you are going to count OS/2 1.x Lan Manager). The entire point I was driving at was that SAMBA grew into that implementation (and, note that SMB was originally not even a Microsoft thing -- it was developed at IBM).
SAMBA has simply been as implementation of SMB for Unix, supporting Microsoft client OSs. I know you referenced AD in your other post -- simply not relevant in this discussion. How else do you accomplish this task? Here are some possibilities:
- Use Windows (Vista, 7) exclusively as your file servers.
- Use Windows (Vista, 7) as "shim servers" against a back-end server.
- Use SAMBA.
- Use PC Netlink (or another AS/U implementation).
Of these solutions, SAMBA looks pretty good. Personally I don't care what you use (and this really doesn't for most home users either; after all, SAMBA pretty much implies that you are using Unix somewhere).
So, technically (in a VERY narrow sense), you are correct. LAN Manager predated SAMBA (1987 vs 1992 or so, make it by 5 years). On the other hand, were you using OS/2 back then? It would have forced you to use a 286 processor, and commodity hard drivers in a server. The drive to SAMBA adoption was that this could be replaced by a Unix box. My way of looking at it was that SAMBA, in allowing Unix boxes to be used as servers for Windows/DOS, allowed the growth of SMB as a protocol in the Enterprise. If SAMBA hadn't existed, I doubt that SMB/CIFS would have been anywhere near as popular (we probably would be having this discussion about the Netware client now).
SAMBA having to clone the AD stuff? Think about that a bit. Yes, it's targeted as a compliant implementation. On the whole, it is a win for Microsoft, though, because it lets "big iron" support the Microsoft infrastructure. From your tag-name "Lunix Nutcase", I presume that you have some interest in Linux and Unix. I imagine that Microsoft wasn't that interested in Linux implementations of SAMBA, but is (likely) very supportive of Solaris and AIX implementations (just my guess). Linux would be of most interest (again, a guess) to Microsoft with the Z-Series implementation running SAMBA.
Given that Windows won't (likely ever) run on Power, Sparc or Z-Series, being able to directly mesh these systems into a Windows ecosystem just benefits Microsoft.
What I don't understand is why Microsoft isn't more supportive of SAMBA. Maybe the SAMBA developers pissed them off (which brings us back to this story). Remember: as long as SMB is the default file shar
Re:Flamebait of a story (Score:3, Informative)
Most formal standards have some sort of reference implementation somewhere, but Microsoft doesn't even implement the OOXML standard as written.