Adam Tauno Williams wrote:
Anton Aylward
wrote: Compared to Windows, Linux is a liberal democracy. Our democracies may be imperfect (See Churchill on that) but if you don't like it you can join or set up a political part and get your own platform. At various stages in the process you can submit proposals and issues to be voted on, pressure your politicians.
NO. This indicates an incorrect and ideological understanding of Open Source. Open Source is in no way like 'democracy'. in democracy every coach potato with an axe to grind or imagined grievance gets to vote. it does not work that way in Open Source.
Open Source is a tyranny of the contributor. Plain and simple. You write code - you win. You whine - nobody cares.
Yup... I think that's what some of us have been saying. But it's not quite that simple ― as with larger projects, it is also about who is *ALLOWED* to contribute (or in what way). Too many times I've been brushed off with "patches or source code gladly accepted", to come back with a patch that they refused to allow in to mainline on political ― not engineering grounds. Such projects wear the label of "open" only in so much as you are free to go off and do your own thing in a "hole", but don't expect them to be open to changes. They have an established political power base that they want to keep. If they allowed anyone to contribute, it would dilute their power. Perl is a prime example. The one contribution to samba I made was labeled, falsely, as insecure ― as part of the accepted command to enable the feature! (i.e. if you have unix-extensions enabled on a samba server and allowed "wide links" (ones that would span given shares), it meant that client systems could point those wide links anywhere. IF your security policy used samba/winbind for unix access as well as windows (same accounts on both) and you allowed users to login to the local server, this was NOT a security issue, as they would be able to create such symlinks while logged in locally ― so turning off unix-extensions a ridiculous response to the issue. I added an extension to reallow it: "allow client managed wide links = [yes/no]" which says what it did ― allowed client machines to manage wide links directly ― and the decision to allow that could be made based on local security practice/policy. The samba team changed that to "allow insecure wide links = [yes/no]" ― and their manpage says: It is not recommended to enable this option unless you fully understand the implications of allowing the server to follow symbolic links created by UNIX clients. For most normal Samba configurations this would be considered a security hole and setting this parameter is not recommended. -- Which is misleading and on the face of it, inaccurate, unless you consider windows clients to be UNIX clients (?). Having the samba team promote the idea that turning that off makes things more secure in ANY way, while you have setup samba to provide unix-login credentials to windows users (something touted as a samba feature ― single signon access), is misleading, at best. It offers security advice knowing nothing about the clients security setup or their needs when samba sells their single-signon feature as a desireable feature (it is, but it can open the same security holes). Vs. my labeling which I felt added no "spin" to the feature ― but DID say what it did, without having to consult a manpage. So, opensource isn't only about who does the work ― but it's about control of who is allowed to submit and how it is filtered after submission. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org