To view parent comment, click here.
To read all comments associated with this story, please click here.
You're ignoring the previously made statements, there are reasons to ignore the previous implementation, but only one need be said. Samba's code is not usable.
Why? You're not answering the counter arguments. Saying it doesn't justify it in any way - it doesn't get clearer than that.
1. There are no licensing concerns at all with respect to the kernel. This is why kernel/user space separation works, and Samba/Linux have done it. Most existing Solaris customers use Samba, with or without Sun's help, and have done for years. SMB and CIFS on non-Windows platforms is nothing new.
2. The kernel arguments don't stand up. Linux has managed to come up with many kernel extensions that Samba uses very successfully today. Sun have never managed to do that, even after all these years.
3. Putting CIFS, and not only that, but the entire stack of interoperability stuff such as NTLM, Kerberos and Active Directory support into your kernel is pretty unwise. Sun will simply be dragged into doing this, because one thing leads on to another - and Samba is already doing it. It's an awful and sometimes dangerous protocol stack, and the only reason we have anything to do with it is because of Windows interoperability. There's an awful lot more to it than CIFS. In fact, adding this lot to a kernel is downright insane.
The code Samba has cannot be used for what Sun wants
Why? Folding your arms and sulking and saying "Sun's doing this regardless" does not justify saying that Samba cannot be used.
Must I add, "doy," in this post to attempt a strong suggestion that this should be obvious?
Because it isn't obvious, and saying that it is doesn't make it true without some justification.
I mean, I have absolutely no problem at all with Sun going off, doing their own thing and making their own choices and implementation. None whatsoever. That's their choice.
However, let's not pretend for a second that there are any real, legitimate reasons whatsoever for doing this. It's just a pointless waste of effort to come up with yet another implementation of, not a standard, but a reverse engineered proprietary set of protocols that sets the open source world back in terms of interoperability.
Sun are doing this because it's all about control. That's why.
I mean, I have absolutely no problem at all with Sun going off, doing their own thing and making their own choices and implementation. None whatsoever. That's their choice.
However, let's not pretend for a second that there are any real, legitimate reasons whatsoever for doing this. It's just a pointless waste of effort to come up with yet another implementation of, not a standard, but a reverse engineered proprietary set of protocols that sets the open source world back in terms of interoperability.
Sun are doing this because it's all about control. That's why.
Reverse engineered--do you know this for a fact, or are you just speculating? Sun does have the luxury of licensing agreements that Samba does not, and there are non-MS written but MS licensed implementations out there (NetApp, one that ships--or used to--with HP-UX, etc).
Also, why is control not a legitimate reason? From a certain point of view, the Allison "protest" departure from Novell, the Tridgell BitKeeper fiasco, the quick GPL3 turnaround, etc might make one wonder if "control" by cooler heads wouldn't be desirable, after all.







Member since:
2006-03-12
You're ignoring the previously made statements, there are reasons to ignore the previous implementation, but only one need be said. Samba's code is not usable. It doesn't get any clearer. The code Samba has cannot be used for what Sun wants, so Sun isn't using it. Must I add, "doy," in this post to attempt a strong suggestion that this should be obvious?