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."
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.
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.
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.