Slashdot Mirror
Samba Beats Windows IT Week Labs Test Results
jmhowitt writes "Tests by IT Week Labs
show the latest version of the open-source Samba file and print server software is 2.5 times faster than Windows Server 2003 in the same role.
The news comes as many firms are grappling with the consequences of Microsoft ending support for NT4, coupled with uncertainty about when Microsoft will next update Windows. The performance difference between Windows Server 2003 and Samba 3 has increased dramatically compared with Samba 2 and Windows 2000 Server."
they've got the ideas, but they don't have a clue how to apply'em in a working enviroment.
I get 10%-20% of the transfer with SMB as I do with NFS.
You are kidding, aren't you? Did you mean 10-20% LESS THEN NFS? (e.g. 10 MB/s NFS vs 9 MB/s SMB)
NFS lives in the kernel, Samba in user space. So you're right but remember NFS is utterly insecurable, Samba not. For home NFS is the system of choice but in a larger environment... you want to run Samba (at least until NFSv4 becomes available)
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
Where are the numbers?
Where are the graphs?
The article basically quotes some guy (who is actually selling Samba and thus has a vested interest) saying that Samba is 2.5 times faster than Windows 2003.
Now I have no reason not to believe him, but I was expecting a little more. And I'd wager the suits considering switching to Samba also expect more.
Read the original poster's text again. Amazing how if this text were written comparing MS to Samba in the *other* direction everyone would be up in arms about the FUD value!
We need to be careful that we don't end up tarred with our own brush!
A little planning goes a long way...
I appreciate Samba, especially with the PDC stuff that obviates the need for costly NT server licenses here at the $workplace. Great to see that a hack that was born out of need is running circles around the cream of the Borg's crop.
Also, I agree with the rest that I'd love to see the numbers to back up the claims. Not that it really matters though. With samba you get a real good solution for an infintessimal fraction of the price of the Microsoft malware :)
We all know anytime someone publishes a benchmark favouring Windows (and there have been quite a few - tpc.org being a great example), it is instantly ripped to shreds, so why is this different?
We all know that it's impossible to do a benchmark that all parties think is fair and accurate.
Read reviews of shopping cart software
Finally I have some hard evidence for clients who keep wasting my time asking me to support SMB on my network
/.'er who makes a statement without any data to back it up. I'd print that post out and hand it to everyone who asks you to support SMB. With proof like that they won't ever think of questioning you again.
Wow, that's certainly damning evidence. A post from some random
What are the differences between Samba and NFS security-wise? I need one more argument to my arsenal.
Ok. If you like having a largely insecure network that is extremely difficult to administer and has questionable reliability then your best bet is NFS.
On the other hand, if you'd like a wide selection of permissions on directories, users, and files, along with relatively easy and logical administration as well as high reliability (at least as far as networked file systems are concerned) then you should go with SMB.
Frankly, if I was a "client" and had to deal with you I'd either go to your boss to have your ass canned (if your "clients" are in fact coworkers) or simply move by business to someone who actually wanted to give me service for my money (if your clients are actually clients).
Oh, and before you even think of saying how I'm a MS lackey, I'm a Unix coder. There's SMB running around our network at work, but I pretty much never use it.
Good points. Here's an additional one: the Samba team doesn't have PHBs to get in the way. In my limited experience, if you're given an existing codebase and told to improve on it, that's exactly what you're expected to do - and it's all you're expected to do. You can't discover that "wow, this legacy code is crap," throw the offending chunks away and write something that works correctly and is more stable and/or secure.
The Samba team has complete freedom with their code, while the Microsoft developers do not.
[b.belong('us') for b in bases if b.owner() == 'you']
Samba 3 is a very different beast from 2.2, your remark is equivalent to basing an opinion of Windows 2K on your experiences with DOS 5.0.
The numbers are in the dead-tree edition, I'm told. I don't know if they actually show any real information, because I haven't seen them.
Samba had a 2x speed advantage over Windows NT 3.51 when that was the current MS offering, though, so I don't find this completely unbelievable.
You can't discover that "wow, this legacy code is crap," throw the offending chunks away and write something that works correctly and is more stable and/or secure.
That's because there are tradeoffs in everything... if you've been told to "clean up the codebase", take a bit to look at the codebase, and tell your manager that it's going to take X amount of time to do that the manager has to decide whether or not it's worth the time to do so -- since otherwise your time could be spent doing other things. And odds are the cleaning up isn't going to show an immediate return to the company. Of course, there are other plusses to cleaning up code -- like doing it right may mean that you can implement future features in less time -- but those are harder to quantify.
Any large project -- be it OSS or closed source -- has to deal with these issues in one way or another. Sure... in OSS anyone (in theory) can decide to go off and clean up the code base. But unless it's done with the input from the team then that effort may be for naught -- unless you're communicating structural changes then merging the two code bases may prove impossible (since new features/bugfixes will have diverged the codebase), the rest of the team may not feel comfortable with the new structure as they are with the old (which is part of a larger issue -- if anyone feels like they "own" parts of the code then they may get offended if you say it's crap and rewrite it entirely -- which is one reason why code ownership is bad), or other issues. If you do do it with the blessing of the team, it still has to be done in a reasonable amount of time for it to be worthwhile -- otherwise the code will either diverge too far or the project will stagnate while waiting on the rewrite.
And, of course, any time you rewrite you run the risk (read: certainty) that you'll introduce new bugs in known, working code.
Open source projects are freed from the time == money constraint if they have no commercial interests whatsoever, but that isn't to say that time becomes free. It's just that it's not necessarily an overriding factor. (Oh, and it's not one at all companies either -- that's entirely up to your manager and the structure of project management; but the more rigorous the framework of management the more likely it is be one).
MicroSoft has a history of maintaining its monopoly by breaking compatibility with competitor's products by subtily changing (or they claim its extending and enhancing) the protocol. The most famous example were DrDOS and Java. If Samba gets too close, I wouldn't be suprised if MS didn't come up with an "enchancement" to Active Directory or SMB/CIFS or the NT-authentication protocols that will break Samba. The up-coming service pack will be the perfect oportunity for a "security fix" that will wall out Samba for a while.
(Related but slightly off-topic) A few days ago, there was an article about IE having broken support for standards, especailly CSS. I don't think that is an acident. I strongly suspect that MS won't fix IE because the "problem" helps them maintain a monopoly in browsers. If you want to get your stuff to render properly in 95% of people's browsers, you have to code to IE, not the "standard". This means your stuff won't render properly in the other 5% of browsers unless you go through lots of trouble to do browser dectection, alternate pages, or take lots of care for cross-browser compatibility.
IMHO, web-based applications suck.
Yes, they do. By their very nature (at this time, anyway), the web user interface can never nearly be as potentially rich as a native client. Consider heavy-duty data collection applications as an example. And you're right that the performance is an issue as well.
However, managers all over (from what I can tell) are clamoring for getting their apps to be web-based. Why? Less administration (esp. at the client workstations), or at least the perception of this. This is what they see.
Meanwhile, "weblication" development technologies are moving forward. While they may never really catch up to what's possible with native clients, it will increasingly make sense to consider such technologies for more and more projects.
Steve Magruder, Metro Foodist
SFTP is a different matter however, but it's less an extension of FTP as an add-on to SSH to implement similar functionality in a completly different way. Not bad as a protocol, but it suffers from the lack of a robust SSH implementation.
Programming can be fun again. Film at 11.
...benchmark[s] favouring Windows [...] [are] instantly ripped to shreads, so why is this different?
It's not different: the thread is FULL of people (including you) asking "where's the numbers" and calling this study FUD. Some of the highest moderated comments, in fact.
Unfortunately, the response seems to be: MS doesn't allow anyone to publish their numbers. IIRC, they added this clause to their licenses after Oracle published some unfavorable-to-MS benchmarks.
The real difference is that when OSS loses a benchmark test, the general reaction* is that the results are studied, and if they're legitimate (which they often are), then work begins trying to fix the problem, and the eventual result is (usually) a better system. When MS loses a benchmark test, they react by forbidding any more benchmark tests, and nothing else (usually) ever changes.
* At least, the reaction amongst people who count, which is to say, the developers, not the pro-linux trolls on slashdot.