On 3/12/07, John Andersen wrote:

Samba is a service that allows you to PUBLISH shares for other computers to mount.

smbfs and cifs are file systems that allow your Linux box to MOUNT a share published by a samab server or a windows box. (perhaps to do a backup or some such)

ahh .. ok, perfect. So the appropriate comparison is NOT samba vs cifs, but rather smbfs vs cifs. Both are client protocols/virtual file system implementations. So, from google reading, cifs was apparently microsofts addition to the original SMB file system spec ... and now, it is a somewhat newer vfs that can exist along side of or instead of smbfs. Theoretically it offers, newer/better/fancier services/access to remote SAMBA provided storage. About right? Thanx John! Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, 2007-03-13 at 00:01 -0500, Peter Van Lone wrote:

On 3/12/07, John Andersen wrote:

...

smbfs and cifs are file systems that allow your Linux box to MOUNT a share published by a samab server or a windows box. (perhaps to do a backup or some such)

ahh .. ok, perfect.

So the appropriate comparison is NOT samba vs cifs, but rather smbfs vs cifs. Both are client protocols/virtual file system implementations.

So, from google reading, cifs was apparently microsofts addition to the original SMB file system spec ... and now, it is a somewhat newer vfs that can exist along side of or instead of smbfs. Theoretically it offers, newer/better/fancier services/access to remote SAMBA provided storage.

About right?

Yes and no. "SMB" was the original name, "CIFS" is Microsoft's later re-branding of it, but MS was extending SMB long before they renamed it, and there isn't really any useful distinction you can make between the two names. 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). -- Dan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 14 March 2007 01:05:26 am Marcus Meissner wrote:

...

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.

"sales losses" are quite difficult for a product that is mostly downloaded.

The next 10.2 kernel update will include USBFS again btw.

Just out of curiosity - why are some items called "kernel modules" and others not? For example, I often use the Cisco VPN client to telecommute. It seems that every few weeks - I guess when kernel update happens - the client fails. I'm then forced to recompile. Wouldn't developers want to put these things outside of the kernel so they are independent of such? -- kai Free Compean and Ramos http://www.grassfire.org/142/petition.asp http://www.perfectreign.com/?q=node/46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 14 March 2007 01:21:03 pm Anders Johansson wrote:

On Wednesday 14 March 2007 14:45, Kai Ponte wrote:

...

On Wednesday 14 March 2007 01:05:26 am Marcus Meissner wrote:

...

...

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.

"sales losses" are quite difficult for a product that is mostly downloaded.

The next 10.2 kernel update will include USBFS again btw.

Just out of curiosity - why are some items called "kernel modules" and others not?

Because some items are modules that plug into the kernel and some aren't?

The kernel runs with complete access to hardware, it can (with some limitations) address memory that user space applications can't. Some things need that while others don't. In the case of samba, there are user space versions. You really only need the kernel support when you want to "mount" a samba share and make it part of the linux virtual file system

Oh, okay. So those modules which want (or need) access to the hardware need to be compiled into the kernel? Now, wouldn't they use the HAL to get at the hardware? Just curious.

...

For example, I often use the Cisco VPN client to telecommute. It seems that every few weeks - I guess when kernel update happens - the client fails. I'm then forced to recompile.

In the case of a vpn client I would tend to agree, I see very little reason for placing that inside the kernel

Incidentally (but I guess you know this) there is an ancient debate over the relative merits of monolithic (i.e. do everything in kernel space) vs. micro-kernels (kernels that do as little as possible in kernel space)

Yep! In fact there's a beauty of a post with Mr. Torvalds arguing about it with Andy Tannenbaum back in '91. I remember reading it in the late '90s when I first switched to Linux on a few desktops and then my P133 laptop. http://groups.google.com/group/comp.os.minix/browse_frm/thread/c25870d7a41696d2/3f6b594a5b4eccb4?lnk=st&q=&rnum=1#3f6b594a5b4eccb4 http://tinyurl.com/34ojmg

It usually ends up being a question of performance. For design, micro kernels usually win hands down, while for performance, the micro kernels haven't even reached the starting line when the monolithic kernels drink the victory champagne

Yeah, it kind of reminds me of the old relational vs. hierarchical debate in DBM systems. -- k -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 14 March 2007, Marcus Meissner wrote:

"sales losses" are quite difficult for a product that is mostly downloaded.

The next 10.2 kernel update will include USBFS again btw.

Cool, use support returns for Vmware. How soon? -- _____________________________________ John Andersen

On Wednesday 14 March 2007, kanenas wrote:

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.

Of course this leads to a discussion of the more generic problem. Namely, that essential software simply disappears in the Linux world. Often for no reason at all, often with no warning. What is all this singing the praises of open source good for if we are dependent on Hans Reiser to stay out of jail or an entire file system goes tumbling down. Its open source for pete sake! Suse made it a mainstay, why can't they maintain it? Now smbfs, (which I admit is non-essential for (guessing) 80% of linux users simply is yanked because there were no maintainers. The source is available, it had no show-stopping bugs, and the replacement wasn't ready. Suse isn't alone in this problem, I've seen it in other distros, and even on rare occasion in windows products that Microsoft simply drops. But Open Source should not have these problems. That's why its open. Anybody can pick it up and maintain it. -- _____________________________________ John Andersen