3 ms·

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

by codex 16y ago

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 16y ago
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 16y ago
  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.

by codex 16y ago

Stormbringer 16y ago

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 16y ago
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.