On Tuesday 13 March 2007 14:19, Paul Abrahams wrote: > On Tuesday 13 March 2007 9:37 am, Dan Winship wrote: > > The distinction you *can* make is between "smbfs", which is an old, > > unmaintained and partly-broken SMB/CIFS client kernel module for Linux, > > and "cifs", which is a newer, actively-developed SMB/CIFS client kernel > > module for Linux. The fact that one has "smb" in its name and the other > > has "cifs" in its name isn't really all that relevant. The point is just > > that they're two separate codebases, and SUSE used to ship smbfs, but > > doesn't any more (because cifs is maintained and smbfs isn't, so bugs > > reported against smbfs will never get fixed, while bugs against cifs > > will). > > So the choice is between an older, unmaintained client kernel that will > continue to work in contexts where it worked previously and a newer client > kernel that is not completely developed but is being actively maintained > and improved. > > If that's the case, then the sensible path is to use smbfs for now and > switch to cifs whenever it becomes interchangeable with smbfs for whatever > one is doing. > > Paul
Someone at novel must have been able to predict or even after the fact see that removing smbfs AND usbfs support from the kernel is bound to lead into at least some 10.2 sales losses. The fact that a recompile is required is guarranteed to turn some customers away and both file systems are needed for basic functionality in some major applications. imo both file systems should at the very minimum have been basic installation options, perhaps they should even added to an updated kernel. something might get done for usbfs because of vmware, but smbfs should be reconsidered as well. is there a serious lack of bean counters at the home office or is this the forerunner of the ms "take it or take it" attitude? d. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
