Samba *is* a business success, as there are many companies successfully depending on it to not only ship business product based upon it, but also many businesses using it internally for their own purposes. Just because there's no "SambaCorp (tm:-)" doesn't mean it's not a business success.
Programmers working on Samba can leverage this knowledge into high consulting rates and employee wages (trust me on this one:-). We even run a "consultants" site off samba.org that advertises consultants and companies who will support Samba for a fee. This is exactly what the FreeBSD site does b.t.w.....:-). That's why the GPL is programmer and business friendly (IMHO). Most of the people advertising on that site work with us and provide a worldwide support service that *depends* on financial compensation. All for GPL code you claim is a "business destroyer".
I do agree with you about the insecure proprietary protocol however. But whilst people keep buying Microsoft based desktop systems, what're you gonna do.... ?:-):-). At least their servers can run on Linux or FreeBSD:-).
Regards,
Jeremy Allison,
Samba Team.
Re:Will the same thing happen to BSD
on
Mandrake Shakeup
·
· Score: 2
Yes I was being rude, please accept my apology. That comment was uncalled for and I regret it.
I don't think I was misrepresenting you though. You believe that the GPL destroys legitimate business. HP, IBM, SGI, Sun, Veritas and *hundreds* of other companies don't. Where there are that many MBA's telling you you're wrong, don't you question what you're saying ?:-):-).
Well at least you're not denying we're a business success. And of course we're entirely GPL.
You're making progress..... Now you've got to make the mental leap that Samba, like most GPL software is a *solution* to someone's problem. One that they're willing to pay for. The fact that it implements a crap protocol (with which I heartily agre b.t.w.:-) is irrelevent.
I'm sure you can get there in the end. In the meantime, people keep paying us to develop and service Samba, so the GPL is a wonderful business plan for us (as it is for RedHat also).
Explain the business success of Samba please ? I can and will dog your efforts to paint the GPL as anti-business until you can explain our success and all the companies who co-operate and donate code to us.
You know, little companies like IBM, Sun, HP.....
I'm still waiting.....:-). Rhetoric is all well and good, but working code speaks louder....
Regards,
Jeremy Allison,
Samba Team.
Re:Will the same thing happen to BSD
on
Mandrake Shakeup
·
· Score: 4
Hey Brett, I'm still here, and I'd still like to point out that Veritas, Sun, IBM, HP, SGI and other businesses willing to face the "overwhelming" hurdle of the GPL are *still* helping us develop Samba......
Got an answer to our business success yet ?
Thought not... (after all, you've only been repeating this troll for as long as I can remember, from your infoworld days).
Readers who want a laugh can look up the old infoworld forums where Brett, a "journalist" at the time, had neglected to do his research and discover that Novell had in fact shipped a GPL version of Samba several years previously before Brett was claiming that the GPL was preventing them from doing so....:-):-).
The problem with the NetApp implementation is that if you change the unix perms it blows away the set NT perms. The solution I coded for Samba maps the NT perms into POSIX ACLs so the two co-exist.
Of course the NetApp solution gives full NT ACL semantics, whereas the Samba solution doesn't, but I think the Samba solution gives better UNIX/NT integration.
Also I don't know any NT admins who understand the full NT ACL semantics:-):-).
A "braindamage implementation issue" is a printer driver server design that expects to be able to run printer driver binaries *ON THE SERVER THAT IS SERVING THEM OUT TO CLIENTS*. If you think back to the dim and distant past, when NT ran on other things than an Intel CPU then you'll realize how broken this is.....
Of course that's been fixed by that "portable" OS, Windows 2000:-).
As Samba runs on other things than x86 boxes this is braindamage for us...
to get *really* medieval on the code... (with apologies to "Pulp Fiction":-):-). Plus we run Samba though the IRIX compiler (which is also very, very picky....).
But that's not the point of Samba. Want directory services ? Use OpenLDAP. Want Kerberos ? Use MIT Kerb5 or Heimdal. Want DNS ? Use bind. Want DHCP ? Use a dhcp daemon (University of Washington I think). Want Terminal Services ? Use X, or vnc.
Are you getting the picture ?:-).
You're comparing Samba, which is just the Windows file/print/authentication service for Windows clients on UNIX, with an entire Win2k/NT load.
You should be comparing a full UNIX/Linux distro. containing Samba to do a fair comparison.
9x clients were already supported by the 2.0.x codebase. They're also supported in the same way that W2k/NT servers do it in this new release.
I didn't mention it 'cos we already had that functionality - so it wasn't news:-).
We've now got a *complete* (modulo bugs and one braindamage implementation issue, hang out on samba-technical@samba.org for details) implementation of W2k/NT point and print. That *includes* W9x driver download.
It means it's not completely a PDC, 'cos it doesn't do replication or BDC Stuff yet - but it works well enough to put Windows 2000 or Windows NT clients into a Samba hosted domain, and have people log in and authenticate against it, and download profiles from it.
For many small sites this is all they need - not the full PDC stuff.
That's why I didn't say PDC, but used the phrase "authentication source".
I don't want to talk too much about this as I'm
sure HP have lots of marketing they want to do
around this.
But the deal is that *yes* this box uses Samba.
*YES* - HP have donated a *lot* of time, effort,
*CODE* (note that - it's important !) and money
in helping Samba support the new WinNT print
subsystem.
They have also helped us push the development on
authentigration and user enumeration between Samba
and WinNT, (check out the winbind project being
done on the Samba lists).
All of these goodies will appear in Samba 2.2.x,
due... well.... when it's *ready* (soon I hope) !
HP are *massively* contributing to Samba, and
the Open Source efforts. Just as much as other
vendors (SGI, Veritas) and other official Samba
supporters do !
Don't knock them just because their marketing
people sometimes are a bit clueless, and only
mention Windows in a product sheet.
They don't mention Samba either (I'm going to
be having a word with them about that....:-).
The current plan is that 2.0.8 will be the answer to your prayers:-). This functionality is being added for ACL support, but I'll test it works for Win9x as well.
His post was one of the most accurate I have seen on slashdot for a while.
What you are conveniently editing out of things John, is the *history*. Yes, I'm sure Netscape can implement NTLM over raw sockets *now*, but not back in the NT3.5 timeframe that they needed to in order to compete with MS.
The SSPI functions *WERE NOT DOCUMENTED* until NT4.x or so. Delay in documentation whilst your own internal teams have full access is usually enough to ensure dominance of your application over the competitors.
This is a completely obvious truth that cannot be denied. I've been up to Redmond, I *know* how this works. You may be able to fool non-programmers John, but not those of us who have to deal with MS documentation (and lack thereof) on a daily basis.
Case in point, the password verification API called on change password on domain controllers. This was only *finally* documented after I revealed it's existance on the 'Net and posted sample code for it.
The Novell integration group at MS had been using that API for *years*.
There are too many of these inconvenient peices of historical evidence for you to keep denying them. Of course you can claim "it's documented now" and I fully expect you to. That's not the point. How many years did MS developers have access *before* it was documented ?
> You may not value intelletual property but MS, > Xerox, and many other companies do.
This isn't intellectual property, it's a land grab on a previously open spec.
> Don't force your Open Source Religion on > everybody else
But I don't want your code ! I want *OPEN* specs, implementable by anyone. That's how the internet got built.
> Where's the problem?
The problem is you are using your client desktop monopoly to attempt to gain a server monopoly. This is why you're being broken up. This is why you're being taken to court in the EU, this is *NOT LEGAL*. That's the problem.
> I think is that in order for their SMB client > (ie, microsoft networking) to use Kerberos > authentication when connecting to an SMB file > server, it requires the use > of their proprietary extension to kerberos, the > priveledge attribute certificate - PAC. > Apparently the Samba developers ran into this > problem while trying to add kerberos support to > samba and make it work with windows 2000
No, this is not true at all. Samba doesn't *need* this PAC format except as an optimization. See my posting below in this.
The MIT kerberos and Heimdal developers need to implement this PAC format, something explicitly denied to them in this license.
> Of course the/. folks go silly over a > boilerplate licensing agreement
Come now, this is hardly a "boilerplate licensing agreement". This is a deliberate attempt to keep control of the spec. and make it unimplementable in open code.
This is not what *anyone* in the Open Source community or at MIT had in mind when they asked Microsoft for the spec, something I have personally been doing for 2+ years.
> I don't want to say who I am but I'm "in the > know"
Yeah, yeah, easy to say anonymously. I'd feel happier seeing a statement from folks I actually *know* and trust at Microsoft that this was a licensing screwup that will get fixed soon, but I'm not holding my breath.
> So why do we need this information? Simple: > without this information it's impossible to > modify Samba to allow Kerberos authentication > (and encryption?) of remote shares.
Actually this is not correct at all. Samba really doesn't need this information to do authentication or encryption from a Win2k client, as the Win2k client is kerb5 standards complient enough to allow this to work perfectly (once the code is added to Samba).
It *would be* needed, however, to create a Win2k client compatible PDC, and it would also help if Samba used the extra SID information to do access control (map these SIDs into UNIX groups and do a setgroups() call from the smbd) if the Samba server were a member of a Win2k domain and was getting the user/group information from the Win2k PDC (either via LDAP or the new winbind daemon code). It's not even completely neccessary for the latter case, as we can get the same information by doing MS-RPC queries to a DC, it's just more efficient to pull the info out of the PAC.
This spec is needed to add the PAC format to MIT kerb5 kdc's and heimdal kdc's, not for Samba.
Slashdot Mirror
Samba *is* a business success, as there are many companies successfully depending on it to not only ship business product based upon it, but also many businesses using it internally for their own purposes. Just because there's no "SambaCorp (tm:-)" doesn't mean it's not a business success.
:-). We even run a "consultants" site off samba.org that advertises consultants and companies who will support Samba for a fee. This is exactly what the FreeBSD site does b.t.w..... :-). That's why the GPL is programmer and business friendly (IMHO). Most of the people advertising on that site work with us and provide a worldwide support service that *depends* on financial compensation. All for GPL code you claim is a "business destroyer".
:-) :-). At least their servers can run on Linux or FreeBSD :-).
Programmers working on Samba can leverage this knowledge into high consulting rates and employee wages (trust me on this one
I do agree with you about the insecure proprietary protocol however. But whilst people keep buying Microsoft based desktop systems, what're you gonna do.... ?
Regards,
Jeremy Allison,
Samba Team.
Yes I was being rude, please accept my apology. That comment was uncalled for and I regret it.
:-) :-).
I don't think I was misrepresenting you though. You believe that the GPL destroys legitimate business. HP, IBM, SGI, Sun, Veritas and *hundreds* of other companies don't. Where there are that many MBA's telling you you're wrong, don't you question what you're saying ?
Regards,
Jeremy Allison,
Samba Team.
Well at least you're not denying we're a business success. And of course we're entirely GPL.
:-) is irrelevent.
You're making progress..... Now you've got to make the mental leap that Samba, like most GPL software is a *solution* to someone's problem. One that they're willing to pay for. The fact that it implements a crap protocol (with which I heartily agre b.t.w.
I'm sure you can get there in the end. In the meantime, people keep paying us to develop and service Samba, so the GPL is a wonderful business plan for us (as it is for RedHat also).
Regards,
Jeremy Allison,
Samba Team.
Brett,
:-). Rhetoric is all well and good, but working code speaks louder....
Explain the business success of Samba please ? I can and will dog your efforts to paint the GPL as anti-business until you can explain our success and all the companies who co-operate and donate code to us.
You know, little companies like IBM, Sun, HP.....
I'm still waiting.....
Regards,
Jeremy Allison,
Samba Team.
Hey Brett, I'm still here, and I'd still like to point out that Veritas, Sun, IBM, HP, SGI and other businesses willing to face the "overwhelming" hurdle of the GPL are *still* helping us develop Samba......
:-) :-).
Got an answer to our business success yet ?
Thought not... (after all, you've only been repeating this troll for as long as I can remember, from your infoworld days).
Readers who want a laugh can look up the old infoworld forums where Brett, a "journalist" at the time, had neglected to do his research and discover that Novell had in fact shipped a GPL version of Samba several years previously before Brett was claiming that the GPL was preventing them from doing so....
Regards,
Jeremy Allison,
Samba Team.
The problem with the NetApp implementation is that if you change the unix perms it blows away the set NT perms. The solution I coded for Samba maps the NT perms into POSIX ACLs so the two co-exist.
:-) :-).
Of course the NetApp solution gives full NT ACL semantics, whereas the Samba solution doesn't, but I think the Samba solution gives better UNIX/NT integration.
Also I don't know any NT admins who understand the full NT ACL semantics
Cheers,
Jeremy Allison,
Samba Team.
A "braindamage implementation issue" is a printer driver server design that expects to be able to run printer driver binaries *ON THE SERVER THAT IS SERVING THEM OUT TO CLIENTS*. If you think back to the dim and distant past, when NT ran on other things than an Intel CPU then you'll realize how broken this is.....
:-).
Of course that's been fixed by that "portable" OS, Windows 2000
As Samba runs on other things than x86 boxes this is braindamage for us...
Regards,
Jeremy Allison,
Samba Team.
Oh - a black pudding muncher..... :-). We'll, we all have our crosses to bear... :-).
Jeremy.
Actually, the line I use when developing Samba is :
:-) :-). Plus we run Samba though the IRIX compiler (which is also very, very picky....).
-Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual
to get *really* medieval on the code... (with apologies to "Pulp Fiction"
Cheers,
Jeremy Allison,
Samba Team.
This is why winbind is so useful for creating Samba appliances. No more local users or groups, just drop the thing into the NT domain and go....
Cheers,
Jeremy Allison,
Samba Team.
Already included in the 2.2.0 Samba. Look for the nsswitch "wins" module. I forgot to mention it (we've addeda *lot* of stuff :-).
Cheers,
Jeremy Allison,
Samba Team.
BTW: I just uploaded the Red Hat rpms for 2.2.0 for Red Hat 6.2 and 7.0 intel onto samba.org.
Ah. You must be a southern git then :-).
Jeremy.
I remember aquaplaning on that bloody thing. Nearly killed me :-). God I *hate* driving on the M1....
Have they knocked down the cooling towers yet ?
:-).
Jeremy.
Check out sybase tools. MS-SQL server is wire compatible with Sybase (it uses TDS - Tabular Data Stream protocol. Proprietary though :-( ).
:-).
Standard Linux sybase tools should talk to SQL server no problem (at least they used to). I depended on this in a previous life
Regards,
Jeremy Allison,
Samba Team.
But that's not the point of Samba. Want directory services ? Use OpenLDAP. Want Kerberos ? Use MIT Kerb5 or Heimdal. Want DNS ? Use bind. Want DHCP ? Use a dhcp daemon (University of Washington I think). Want Terminal Services ? Use X, or vnc.
:-).
Are you getting the picture ?
You're comparing Samba, which is just the Windows file/print/authentication service for Windows clients on UNIX, with an entire Win2k/NT load.
You should be comparing a full UNIX/Linux distro. containing Samba to do a fair comparison.
Regards,
Jeremy Allison,
Samba Team.
9x clients were already supported by the 2.0.x codebase. They're also supported in the same way that W2k/NT servers do it in this new release.
:-).
I didn't mention it 'cos we already had that functionality - so it wasn't news
We've now got a *complete* (modulo bugs and one braindamage implementation issue, hang out on samba-technical@samba.org for details) implementation of W2k/NT point and print. That *includes* W9x driver download.
Cheers,
Jeremy Allison,
Samba Team.
I'm not a bloody Aussie, I've never even *been* to bloody Australia :-). I'm from *Sheffield* (where they do "the Full Monty" :-) :-).
You're thinking of *Andrew*. He's a bloody Aussie !
Bloody foreigners, not knowing the difference between Australia and the UK, I dunno... mumble, grumble....
:-).
Cheers,
Jeremy Allison,
Samba Team.
It means it's not completely a PDC, 'cos it doesn't do replication or BDC Stuff yet - but it works well enough to put Windows 2000 or Windows NT clients into a Samba hosted domain, and have people log in and authenticate against it, and download profiles from it.
For many small sites this is all they need - not the full PDC stuff.
That's why I didn't say PDC, but used the phrase "authentication source".
Cheers,
Jeremy Allison,
Samba Team.
Q) .What has the open source movement gained?
:-).
ans: nuffin.
Bzzzzt : WRONG ANSWER - thanks for playing.
I don't want to talk too much about this as I'm
sure HP have lots of marketing they want to do
around this.
But the deal is that *yes* this box uses Samba.
*YES* - HP have donated a *lot* of time, effort,
*CODE* (note that - it's important !) and money
in helping Samba support the new WinNT print
subsystem.
They have also helped us push the development on
authentigration and user enumeration between Samba
and WinNT, (check out the winbind project being
done on the Samba lists).
All of these goodies will appear in Samba 2.2.x,
due... well.... when it's *ready* (soon I hope) !
HP are *massively* contributing to Samba, and
the Open Source efforts. Just as much as other
vendors (SGI, Veritas) and other official Samba
supporters do !
Don't knock them just because their marketing
people sometimes are a bit clueless, and only
mention Windows in a product sheet.
They don't mention Samba either (I'm going to
be having a word with them about that....
Regards,
Jeremy Allison,
Samba Team.
The current plan is that 2.0.8 will be the answer to your prayers :-). This functionality is being added for ACL support, but I'll test it works for Win9x as well.
Regards,
Jeremy Allison,
Samba Team.
His post was one of the most accurate I have seen on slashdot for a while.
What you are conveniently editing out of things John, is the *history*. Yes, I'm sure Netscape can implement NTLM over raw sockets *now*, but not back in the NT3.5 timeframe that they needed to in order to compete with MS.
The SSPI functions *WERE NOT DOCUMENTED* until NT4.x or so. Delay in documentation whilst your own internal teams have full access is usually enough to ensure dominance of your application over the competitors.
This is a completely obvious truth that cannot be denied. I've been up to Redmond, I *know* how this works. You may be able to fool non-programmers John, but not those of us who have to deal with MS documentation (and lack thereof) on a daily basis.
Case in point, the password verification API called on change password on domain controllers. This was only *finally* documented after I revealed it's existance on the 'Net and posted sample code for it.
The Novell integration group at MS had been using that API for *years*.
There are too many of these inconvenient peices of historical evidence for you to keep denying them. Of course you can claim "it's documented now" and I fully expect you to. That's not the point. How many years did MS developers have access *before* it was documented ?
Regards,
Jeremy Allison,
Samba Team.
> You may not value intelletual property but MS,
> Xerox, and many other companies do.
This isn't intellectual property, it's a land grab on a previously open spec.
> Don't force your Open Source Religion on
> everybody else
But I don't want your code ! I want *OPEN* specs, implementable by anyone. That's how the internet got built.
> Where's the problem?
The problem is you are using your client desktop monopoly to attempt to gain a server monopoly. This is why you're being broken up. This is why you're being taken to court in the EU, this is *NOT LEGAL*. That's the problem.
Regards,
Jeremy Allison,
Samba Team.
> I think is that in order for their SMB client
> (ie, microsoft networking) to use Kerberos
> authentication when connecting to an SMB file
> server, it requires the use
> of their proprietary extension to kerberos, the
> priveledge attribute certificate - PAC.
> Apparently the Samba developers ran into this
> problem while trying to add kerberos support to
> samba and make it work with windows 2000
No, this is not true at all. Samba doesn't *need* this PAC format except as an optimization. See my posting below in this.
The MIT kerberos and Heimdal developers need to implement this PAC format, something explicitly denied to them in this license.
Regards,
Jeremy Allison,
Samba Team.
> Of course the /. folks go silly over a
> boilerplate licensing agreement
Come now, this is hardly a "boilerplate licensing agreement". This is a deliberate attempt to keep control of the spec. and make it unimplementable in open code.
This is not what *anyone* in the Open Source community or at MIT had in mind when they asked Microsoft for the spec, something I have personally been doing for 2+ years.
> I don't want to say who I am but I'm "in the
> know"
Yeah, yeah, easy to say anonymously. I'd feel happier seeing a statement from folks I actually *know* and trust at Microsoft that this was a licensing screwup that will get fixed soon, but I'm not holding my breath.
Regards,
Jeremy Allison,
Samba Team.
> So why do we need this information? Simple:
> without this information it's impossible to
> modify Samba to allow Kerberos authentication
> (and encryption?) of remote shares.
Actually this is not correct at all. Samba really doesn't need this information to do authentication or encryption from a Win2k client, as the Win2k client is kerb5 standards complient enough to allow this to work perfectly (once the code is added to Samba).
It *would be* needed, however, to create a Win2k client compatible PDC, and it would also help if Samba used the extra SID information to do access control (map these SIDs into UNIX groups and do a setgroups() call from the smbd) if the Samba server were a member of a Win2k domain and was getting the user/group information from the Win2k PDC (either via LDAP or the new winbind daemon code). It's not even completely neccessary for the latter case, as we can get the same information by doing MS-RPC queries to a DC, it's just more efficient to pull the info out of the PAC.
This spec is needed to add the PAC format to MIT kerb5 kdc's and heimdal kdc's, not for Samba.
Hope that clears things up.
Regards,
Jeremy Allison,
Samba Team.