Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Networking Open Source

Samba 4 Enters Beta 170

Posted by Soulskill
from the progress-is-made dept.
rayk_sland writes "Progress is being made on the long awaited Samba 4 release. On Tuesday the Samba 4 team announced their first beta. Those of us who refuse to have a closed-source server at the core of our networks will be encouraged to see this milestone. Here are a few of the new features: 'Samba 4.0 beta supports the server-side of the Active Directory logon environment used by Windows 2000 and later, so we can do full domain join and domain logon operations with these clients. ... Samba 4.0 beta ships with two distinct file servers. We now use the file server from the Samba 3.x series 'smbd' for all file serving by default. For pure file server work, the binaries users would expect from that series (nmbd, winbindd, smbpasswd) continue to be available. Samba 4.0 also ships with the 'NTVFS' file server. This file server is what was used in all previous alpha releases of Samba 4.0, and is tuned to match the requirements of an AD domain controller. We continue to support this, not only to provide continuity to installations that have deployed it as part of an AD DC, but also as a running example of the NT-FSA architecture we expect to move smbd to in the longer term. ... Finally, a new scripting interface has been added to Samba 4, allowing Python programs to interface to Samba's internals, and many tools and internal workings of the DC code is now implemented in python.'"
This discussion has been archived. No new comments can be posted.

Samba 4 Enters Beta

Comments Filter:
  • by Martz (861209) on Wednesday June 06, 2012 @03:36AM (#40229979)

    Why not? It's a new major version which provides new functionality, and is written in python to make it easier for people to contribute.

    Memory and CPU have never been cheaper, if you're still running your samba box on a PIII 450MHz then you'll probably want to stay on Samba 3.

    Otherwise upgrade your hardware and move to Samba 4 when it becomes stable.

    It *WILL* be slower and it *WILL* use more memory, since it's not stable and it's a major new version with new features.

    Sheesh.

  • by Anonymous Coward on Wednesday June 06, 2012 @03:52AM (#40230039)

    It is much more likely that these are the fruits of long years of dedicated and hard work. In my books, the collaboration you mentioned is just the icing of the cake that is samba. When you have a look at, for instance, .Net/Mono you can easilly see how one-sided that collaboration is.

  • by TheRaven64 (641858) on Wednesday June 06, 2012 @05:00AM (#40230273) Journal
    While I'm certainly not a fan of Python, it's clear that they are leaving the high performance parts in C, and just using Python for scripting. Samba comes with a lot of tools that are not performance critical. For example, the smbtree utility needs to print a pretty tree of the current network from the results of a scan. If the scan is done by the core C code, there's no reason why you can't write the part that parses command-line options, prompts for passwords, and displays the output in an interpreted scripting language: even if it runs at 1% of the speed of C code, users won't notice the difference because almost all of the time will be spent in the code doing the I/O.
  • by Tough Love (215404) on Wednesday June 06, 2012 @05:11AM (#40230321)

    Microsoft fought interoperability in every way they could using fair means or foul, legal or illegal. And still it did not stop the Samba team. The fact that Microsoft managed to slow them down for years is a testament to... something. Not anything nice.

    Domain controllers are really the last bastion of Microsoft's illegal barriers to interoperability. This is a big deal.

  • by Anonymous Coward on Wednesday June 06, 2012 @05:17AM (#40230335)

    Uhh nope. More like the fruits of the Samba team sticking to their guns in the EU and microsoft being forced to open up their protocols.

  • by TheRaven64 (641858) on Wednesday June 06, 2012 @05:22AM (#40230359) Journal
    Programming is about picking the right tool for the job (which is never Python, but I digress). There are not going to be 100 users running an admin tool at once. Even that tool is not going to be loading the CPU, because it is going to be spending almost all of its time calling into C libraries. If the choice is writing it in a language that makes it easy to get bug-free and which does not impose any user-visible cost, or writing it in a language that makes what you want to do (e.g. string processing) error prone, likely to be buggy, and does not run detectably faster, then you are an idiot if you pick option 2.
  • by Anonymous Coward on Wednesday June 06, 2012 @05:38AM (#40230421)

    Intentional (or even incidental) inefficiency is never a positive thing when it comes to computing.

    You seem to be under the impression that the most valuable resource in computing is clock cycles.

    It's not, not even close.

    The most valuable resource in computing is developer time. If writing in Python makes it quicker to develop code (it does, by orders of magnitude), then that is "efficient". I've been writing C programs since the late 80's and even I can see that Python is a productivity win.

    I get sick of people that rant about "inefficiency" in clock cycles when here, in the real world, the inefficiencies with the greatest business impact are the ones that cost dev time. Devs are freaking expensive. A dev spending 2 weeks squeezing an extra 0.1% of performance out of a non-critical part of an app is a complete waste of time and money.

    By all means, don't make a slow heap of crap (I don't think Samba is). And by all means, for code which is profiling very poorly, impacting the users and hurting the business, look for lower level optimisations.

    But please, for everybody's sake, get some perspective on this issue. Just because parts of it are not written in C doesn't mean it's not efficient, because "efficient" covers a heck of a lot more than clock cycles, at least to people who actually have to run a business.

  • by adolf (21054) <flodadolf@gmail.com> on Wednesday June 06, 2012 @05:47AM (#40230453) Journal

    You're right: There won't be 100 users running an admin tool (though I view smbtree, in particular, as more of a user tool...at least on the networks I've been paid to use). But there could easily be 100 users running 100 different Python apps which could be more-efficiently coded in...almost anything else.

    The problem I see (and I see it more and more, and not just with Python) is that things are becoming more runtime-interpreted and less efficient. Going back some decades, it is often explained that it doesn't matter "these days", but I submit that it does matter -- and always has.

    Instead of battling execution time (the CPU in my cell phone is ridiculously faster than my first half-dozen computers even if they're all combined and quadrupled), we're now battling energy efficiency. But other than terminology it's exactly the same game: Interpreted languages may be fast to develop, but cost more for people to use.

    Case in point: I, a single user, notice when I'm running inefficient programs on my phone. Things generally happen very fast, but they also cause the hardware to get (sometimes uncomfortably) hot and the battery voltage starts to dive.

    smbtree in particular is such a light-duty single-shot thing that it really won't ever matter to me, by itself, but the confluence of that and every other inefficient program makes a real dent in my ability to use my pocket computer and stay away from a charger, which has a real and tabulable cost in terms human time.

    And not to be too pessimistic, but to extrapolate: It ought to be possible for a sufficiently-motivated person to ascertain the cost of such inefficient programming techniques in terms of human lives lost.

    (Ugh.)

  • Re:2002 (Score:5, Insightful)

    by Sycraft-fu (314770) on Wednesday June 06, 2012 @06:59AM (#40230761)

    "You're a fool if you're telling the truth"

    I'm sure he's not. He probably isn't outright lying, as in just making something up from scratch, but rather just suffering from Smartest Motherfucker in the Universe Syndrome, as many programmers do.

    I see it all too often, programmers who seem to think they are god's gift to programming. They think they are WAY better than all the stupid "normal" programmers. They can't see why people have so many bugs, can't understand why development takes so long, can't understand why programmers don't "just make this happen," and so on.

    Hence he probably did look at this and say "That'll be easy," not understanding the full complexity of implementing a really good AD server. The Samba team perhaps does understand and wasn't interested in playing around with someone who doesn't.

  • by geekopus (130194) <geekopus&yahoo,com> on Wednesday June 06, 2012 @07:12AM (#40230827)

    This is about much more than just the filesystem. You can run a full-on AD controller now, complete with group policies, etc. It really is a drop-in replacement for most of Active Directory does.

  • by Dr.Dubious DDQ (11968) on Wednesday June 06, 2012 @08:55AM (#40231693) Homepage

    The decade-long focus on playing nice with Microsoft Windows seems to be getting somewhere, but I haven't seen much about letting Linux play too.

    Does CIFS implement SMB2 yet (or is there an "SMB2FS" module that I missed), or is Linux still excluded outside of "smbclient"?

    Can SAMBA4's LDAP server also be used for standard basic LDAP authentication as well "e.g. for web servers, minimalistic *nix boxen, etc) or does it still only permit authentication by clients implementing a full "ActiveDirectory®" stack?

Science and religion are in full accord but science and faith are in complete discord.

Working...