What's the consensus? Should winbind even be considered for production use? Looking back through the archives of the Samba lists, there's a lot of doubt about it. Where people have had problems, there are more often than not no solutions given. When I look at the man page in 3.0.28, there are litterally blank spots awaiting completion, and lack of documentation of sometimes-essential switches explicitly and obscurely referred to in the email lists. The "official" manual sections that cover it are tangential and incomplete. The third-party howtos, when they go farther than the man page, are sketchy and often just wrong. Should it have even been released in anything other than a beta package? I was assuming that anything in the official Samba releases was reasonably solid - like the core Samba functionality, or the excellent rsync, or the components of other major OSS packages of similar stature to Samba. I've seen a claim that Samba 4 may handle this stuff much better. But if there are any more releases in the 3 line, should there be prominent warnings that, due to either flawed design or bad documentation, winbind should not be counted on for production? In 14 years of administering Linux systems, I've never seen anything that, given a few days to troubleshoot and some advice from the lists, I couldn't get humming sweetly. Not winbind. Either I'm getting too old for this work, or it uniquely fails the usability test. Best regards, Whit
On Sun, Feb 17, 2008 at 11:15:32AM -0500, Whit Blauvelt wrote:> Either I'm getting too old for this work, or it uniquely fails the usability > test.You're getting too old for this work.... Jeremy.
Whit Blauvelt wrote:> Jeremy, > > I think I can see the blind spot at play here: The signal genius of the core > members of the Samba project is in being able to take a poorly-documented, > haphazardly-designed interface - Microsoft's - and nonetheless make > something that works with it. Samba's developers, of all the open-source > project engineers, have that special sort of keen intuition which renders > poor documentation almost superfluous. Like most human beings, you can't see > why what's obvious enough for you shouldn't come as easily to other "normal" > people. >I'm probably in the target demographic for most companies trying to make a profit from Linux; I decide whether to recommend Windows or Linux architectures for my employers' business needs. I'm running a small home network around Linux/Samba servers so that I can get a feel for when I'll be able to recommend it for business-critical applications. Documentation is one of the things that I base my decisions on. I want software that's sufficiently intuitive that the manuals can be left gathering dust in a corner somewhere, but I need to see that documentation because it gives me an assurance that the people writing the software know enough about it to be able to document precisely what they expect it to do in any given scenario. One of the weaknesses of the open-source model is that "release early, release often" makes maintaining documentation a nightmare. That's a problem that anyone who wants to sell me Linux software is going to have to solve. I sympathise with their problem, but without losing sight of the fact that it's their problem not mine.> Meanwhile the rest of the open source world, not being so perfectly > practiced at the arcane art of deciphering opaque APIs, more naturally > appreciates the importance of clear, complete documentation, and generally > gets on with producing it.Some open-source projects have good documentation and some don't. In voluntary projects it's the people who show up and do the work that decide what work gets done. (I speak from experience here and wouldn't have it any other way.) A chain is only as strong as its weakest link. Open-source software has significant strengths, but commercial open-source companies need to manage its weaknesses every bit as well as its strengths. Just how that affects development teams like the Samba project is up to those developers to decide. -- bap@shrdlu.com