
Apple replaces Samba for Windows networking services - evo_9
http://www.appleinsider.com/articles/11/03/23/inside_mac_os_x_10_7_lion_server_apple_replaces_samba_for_windows_networking_services.html
======
thwarted
If they can make it work and well integrated, that would be great. The Samba
integration on OSX Server is, IMHO, extremely subpar. I had problems with file
permissions and ownership getting set correctly. And that's _just for
fileserving_ , which samba has had downpat for years, not things like having
it be a DC in a AD setup. I know what the options are to have samba do what I
want, but there is no place in the lowest-common-denominator-of-file-sharing-
service-configuration GUI to set them. And you really want to avoid hand
editing the GUI maintained configuration files because they get overwritten.

~~~
lukeschlather
"Extremely subpar" may be overly charitable from my experience. We had
constant problems that have pretty much disappeared since we replaced it with
a machine running Windows Server 2008 R2.

My biggest gripe was discovering that for a user foo, you can't just give the
user permission to access a file on a network share through the GUI, you must
also make sure that foo can access the file at the Unix level. Potentially I
guess if they're building from the ground up they can get better integration,
though I'm skeptical of their ability to do better than Samba.

~~~
thwarted
_"Extremely subpar" may be overly charitable from my experience._

I like to say that anyone who thinks all Apple products are designed well and
work as you expect means that person has never used OSX Server.

 _My biggest gripe was discovering that for a user foo, you can't just give
the user permission to access a file on a network share through the GUI, you
must also make sure that foo can access the file at the Unix level._

In some sense, this is the way samba works (it uses file system permissions
for user share mode, once they've been authenticated, unless you override it
with things like the _force user_ , _force group_ , or _force mode_ parameters
-- which you can't effectively set on OSX). Unfortunately, since the GUI hides
actual samba configuration from you, you never find this out.

------
codex
To this I say, "good riddance." Samba is a pretty horrible implementation of a
pretty horrible protocol. It was originally built by systems administrators,
so I'd say that the system is more "accreted" (like a stalactite) rather than
really designed. Samba is incredibly hard to extend and maintain and the
primary developers are more wankerish and ideologically motivated than
commercial vendors would like. Primarily for these reasons, but also for
licensing reasons, EMC, NetApp, other storage vendors, Oracle, and now Apple
have all switched over to private implementations. I believe Sun's effort
started long before protocol documentation was available from Microsoft, but
the Samba developers do deserve credit for doing some incredibly painful
reverse engineering, even if that reverse engineering is sometimes incomplete.

~~~
Stormbringer
That's an interesting perspective.

I had been under the impression that the concept/implementation was fine,
until Microsoft started diddling with the system in order to mess them around.

Specifically: wasn't Samba based on a 'clean room' implementation of some
Microsoft protocol or something like that? And when it took off Microsoft were
in the middle of their 'kill Linux in the enterprise at all costs' jihad and
so they kept changing the protocol that the Samba guys were trying to
interface/interact with?

~~~
codex
In a word, no. Microsoft could not change the protocol because it still had to
support the hundreds of millions of Microsoft Windows clients out in the
field. With Vista, Microsoft cleaned up the protocol a bit (SMB2), but it was
the Samba team's paranoid fantasy that this somehow applied to them. Really,
it was a long-overdue revision which helped performance tremendously.

While the Samba team had a huge task, this does not excuse the extremely
crappy implementation over the years: corrupt TDBs, lack of change notify, no
native ACL support, oplock crashes due to the non-asynchronous, single
threaded nature of each smbd, horrible Winbind scalability problems, domain
join bugs, no real named pipe abstraction layer, no alternate data stream
support, etc. And the code is just horrible to look at.

------
wmf
Solaris also replaced Samba with in-house code:
<http://blogs.sun.com/amw/entry/cifs_in_solaris>

IIRC this is a lot easier than it used to be now that MS has to publish
protocol specs.

~~~
barrkel
Cifs is implemented at a lower level in the stack than Samba; the primary
upshot of this from my perspective is that you can only export a files in a
single file system using cifs. If you have one file system mounted on a path
within another, or symlinks that cross file systems, they will appear as empty
directories or broken files, respectively. Given that a major reason for using
ZFS is the ease with which you can use multiple file systems with different
configurations all drawing from the same storage pool, this is a pretty severe
drawback.

~~~
codex
The flipside is that you get coherent oplock and sharemode locking with NFS
and local accesses, reasonable ACL/identity management solution across all
protocols, efficient support for file change notifications, etc. For these
reasons I consider the in-kernel solution to be far superior feature wise as
well as performance wise.

~~~
barrkel
Oplocks are an optimization I'm not in much need of; 100MB/sec transfers do
just fine. That sharemode locking is by and large ignored I consider an
advantage of Samba, as in my personal environment, I do not care if some
program wants to exclude readers or writers, I prefer to make those choices. I
don't have any applications that treat files on a file share as a multi-user
database like the era of Paradox etc.; those days are long gone.

I think ACLs are a bug, not a feature. They are too complex to administer both
correctly and efficiently; a capability-oriented approach would be better, but
that's fantasy, alas. Again, POSIX permission bits do just fine for my use
cases.

Reliable FCNs would be nice though.

------
38leinad
i have lately been writing a simple "samba" client for iOS
(<https://github.com/38leinaD/tango>) and after that experience i must say to
the developer doing the samba replacement at apple: poor bastard; you are in
for a world of pain!

It is really a horrible protocol where you can see how it evolved and was
extended from windows version to version...

~~~
ch0wn
Setting up a working file server with basic authentication is almost enough to
confirm this. There might be valid reasons for all of the configuration
options, but the avarage user will never need more than 10% of them.

------
Stormbringer
The GPL has done a lot of good, but I think it is rather hobbled by being tied
so intimately to the concept of 'linking', which has a very clear technical
meaning when talking about C/C++, but becomes a lot fuzzier when applied to
other languages.

This was fine back when all software was written in C/C++... except that was
of course _never_ the case.

------
__david__
I'm confused, which part of the GPL v3 makes it impossible for Apple to
distribute?

~~~
pedrocr
Nothing prevents redistribution, v3 seems to be equal to v2 in all the code
sharing requirements. The two big-ticket additions seem to be the prevention
of "tivoization" by having to distribute the keys to sign software to run on
the device you distribute with GPLv3 software in it, and the requirement that
if you grant some users a license to one of your patents you're granting that
to every user of the GPLv3 software you distribute.

One reason Apple would care is it is now shipping a bunch of locked down
hardware (the iDevices). Although those probably don't run Samba right now
they may have set up a general policy to not have that risk.

[http://en.wikipedia.org/wiki/GNU_General_Public_License#Vers...](http://en.wikipedia.org/wiki/GNU_General_Public_License#Version_3)

~~~
tzs
A bigger problem may be licenses to other people's patents. Suppose Apple
distributes Samba, and suppose someone _NOT_ Apple owns a patent that Samba
infringers. That party sues Apple, and it becomes clear to Apple that they are
going to lose. Let's also assume Apple's Samba has some changes, so it is not
100% identical to the upstream.

It looks like GPLv3 only gives Apple the option of stopping distributing
Samba, or of finding a way to get a patent license that covers everyone who
obtains a copy of Samba that can be traced back to Apple. The latter could get
very expensive.

------
robin_bb
I consider this to be a failure of a GPL-licensed open source software
project. Samba is not being used by Solaris, nor by Mac OS X.

~~~
wmf
Developers who use the GPL don't want as many users as possible; they want
freedom and users can take it or leave it.

~~~
JoeAltmaier
...and they have mostly left it in this case. Fine; but lets not pretend open-
source GPL projects are significant to the world at large; they are backroom
projects with no future.

~~~
jscott1290
are you kidding me? gcc?

~~~
JoeAltmaier
I use gcc. Its a constant struggle compared to commercial, supported
compilers.

------
viraptor
What are the chances that the new service is actually samba-tng
(<http://wiki.samba-tng.org/doku.php/start>) ? That would be at least
interesting. Otherwise - good luck to them replicating what samba project
learned over the last 20 years. A new implementation has slim chances of being
compatible with systems in the wild.

------
icarus_drowning
Won't this be easy to get from MacPorts soon enough anyway?

~~~
bcrescimanno
The obvious question is: why would anyone want to? Presumably, Apple will
replace Samba with something that works well for the vast majority of cases.

To me, this echoes my problems with the GPLv3: how can software be truly free
(as in freedom) if it's not free to be used commercially?

~~~
tptacek
It is free to be used commercially, if you write it, pay for it, or keep its
derived works open source. The only thing GPLv3 keeps you from doing is
closed-source commercialization against the wishes of the author.

This seems eminently reasonable to me. If you want to allow people to do
closed-source commercial projects with your code, BSD license it.

~~~
chc
It feels kind of like a semantic game to call free software "commercial." Do
you really believe that, in general, consumer software that you essentially
have to surrender the copyright to is commercially viable? Are many people
actually going to pay for something that's available for free with literally
no added benefit _?

(_I am, of course, ignoring support here, because support is really a separate
product that could even be provided by a third party.)

~~~
tptacek
GPL does nothing to prevent you from selling software. Look what Sleepycat
did. Just GPL your code, and put an enterprise-grade price tag on a non-GPL
commercial license.

The only people affected by the GPL are people who want to sell software they
didn't write. It's hard for me to get worked up about that: the overwhelming
majority of all commercial software is _more_ restrictive.

~~~
chc
I don't think it's fair to call a program that links against a library for
some subset of its functionality "selling software they didn't write." I
believe Firefox uses zlib and libpng, but I don't think most people would call
Firefox a _version_ of zlib or libpng.

Anyway, I'm not saying that people shouldn't be able to license their software
under the GPL. If you don't want me using your code, that's your right. But if
they do GPL it, from my POV as a potential user of the code, it might as well
be closed-source. Thus I object to the statement "It is free to be used
commercially," when it is actually free for any other use but impractical for
commercial use. (Even in your Sleepycat example, it was the non-GPL version
that they used in their commercial pursuits.)

~~~
tptacek
Help me understand what you're saying. If I write a library, you are free not
to use it. My code, my terms, right? That's how commercial licensing works.
How does GPL harm that dynamic? Or, should the party with more source code
lines dictate terms to the party with fewer?

~~~
chc
I think I must be saying this very clumsily. I'll try to sum it up explicitly.

I'm OK with the existence of GPL software. I like it when people use a more
permissive license, but your code is yours to do with what you will. What
bothers me is what people _say about_ the GPL, because I think it's
misleading.

There is this common idea in the free software community that it is not
hostile to commercial software. That's what I don't like. If people came out
and said, "Yeah, my GPL source code has very severe restrictions that make it
unsuitable for integration in commercial software," I would agree and wish
them happy coding. But they don't say that. They use the misleading banner of
"free," and even try to deny that it's incompatible with commercial software.

Based on all the evidence I've seen, I believe commercial software pretty much
has to be offered under a proprietary license in 99% of cases. The GPL says I
can't do that if I use so much as one line of GPL code written by somebody
else. That means that using GPL code in my software renders it unsaleable.

So, when you said, "It is free to be used commercially … if you keep its
derived works open source," I objected to that. If you can only release your
software under the GPL, you're probably not going to make a lot of money
selling it — it strains the definition of "commercial." You can't even use the
Sleepycat model, where there's a GPL version and a commercial one.

It's your right to put your software under that license. But I think it's
important for people to understand that it completely shuts out commercial
use, even if the commercial use is largely original. We shouldn't downplay
that.

~~~
ZeroGravitas
The GPL is clearly _designed_ to be hostile to a certain type of software
deployment strategy.

But not because that software is being sold, or because it is profitable, or
corporate, or big-business, or commercial or any of those things. It is
hostile because it is "proprietary" and that (in the FSF's opinion) tilts the
power balance too far towards the vendor, allowing all sorts of abuses.

Where I think you are getting confused is that some of those abuses are highly
profitable and so those are the most visible successes to you.

But people like to sum this complicated area up as the GPL being "anti-
business" or not "business-friendly", which is highly misleading. You'll note
that quite a lot of non-software businesses are quite happy to use GPL code
since a) they are not in the business of selling proprietary code and b)
proprietary code gives too much power to the vendor. There's plenty of room
for businesses to supply GPL software to these companies.

~~~
chc
I think that you are misrepresenting what I've said. Businesses using GPL
software are irrelevant to what I was talking about. My comments have been
about selling software for a living, and only about that. (Just to clarify, I
am also not talking about providing support for software or making
customizations to software. Those are separate kinds of businesses from
software products.)

On that topic: Whether or not the GPL was designed to be hostile to commercial
software, it _is hostile_ to commercial software in the real world. I don't
know of a single piece of GPL software that makes decent revenue on its own.

~~~
tptacek
SourceFire IPO'd on GPL software. There are other examples. I feel like this
has more to do with ideology than truth-seeking for you.

~~~
chc
For me, this question is mainly practical. If indie developers could put out
GPL software and make good money from it without requiring the support
infrastructure of a megacorp, I would think that was the bee's knees and I
would promote that business model like crazy. I just don't think it's
generally possible. I'm not familiar with SourceFire's story, but a look at
their site seems to suggest the "Enterprise tech support company" model. I'll
have to look closer.

~~~
tptacek
How could it possibly benefit indie developers to give up more of their
rights? The rights held back by the GPL --- _for the developer_ \--- are
almost exactly those those required by companies to commercialize software.
I'm vociferous about the GPL entirely because it _enables_ developers to
profit from their labor. The GPL is anathema to megacorps. That's why you
dual-license, and charge out the wazoo for the corp-friendly license.

You really, really, really need re-evaluate your take on this. GPL is the most
indie-friendly of the licenses. There's a valid gripe against it: it fractures
the open source community into "people who can use GPL code" and "people who
can't use GPL code". But that has nothing to do with commercialization. Once
you BSD license something, it is extraordinarily difficult to commercialize
the code itself.

------
dave1010uk
Will Samba loose out from this? Are Apple an active developer of Samba?

