Re: [OT] Free software vs non-free, here we go again (was: Deleting i386 packages)
Hi.
On Sun, 27 Sep 2015 10:06:37 +0300
Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
> Hey Reco,
>
> I must admit that this is not the first time I was confused as a
> trolling creature.
For the record - I did not 'confuse' you as a troll and did not call
you one. I could not care less about it, actually.
> And responding to the above mentioned arguments\ideas\thoughts.
> I know some might disagree with me about my point of view and I do not
> have any obligations to change my mind but I can clarify my thoughts.
>
> You have asked if I am a windows user and the answer is that I do use
> windows and I find it a very nice piece of software.
Dear Eliezer. I don't *need* to ask you whenever you're using Windows
or not. E-mail headers 'User-Agent' and 'Content-Type' from your e-mails
leave me absolutely no doubt about you use Windows.
Also I must apologize in advance if I mistook your last name for the
first one. No offense meant.
> But I will need to clarify couple things since I am almost sure you
> misinterpreted what I was writing.
>
> There are couple things to consider with software.
> Like any other job the programmers need money and software authors are
> not obligated to publish their work to be available to all humanity(or
> at-least these parts of humanity that are connected to the WWW).
True. To reduce free software concept to the availability of the source
code is gross oversimplification (and misses the point almost
completely btw), but we'll leave it here for a moment.
> The above is something I think is right and it is right especially for
> security and health related software.
False. Please take your time to research 'Bugtraq' and
'Full-Disclosure' maillists to observe the falsehood of this statement.
Security by obscurity never works, and to promote such point of view
means to deny the truth.
> As opposed to what some think that software should be available for all
> I am on the side which thinks that secrecy or confidentiality is a value
> which is either required or wanted by people.
Here you've got it all wrong. You do not attach 'confidentiality' (let
along 'secrecy') labels to the software itself. You need to attach said
labels to the data which the software in question deals with.
> So the above doesn't implies that anyone should use any software. And
> also in any case of software usage there is a great need to consider the
> pros and cos and to see if it matches the requirements and needs.
> I am not writing and talking about debian specifically since this is not
> the question(at-least from my side of the glass).
>
> If some vendors supply compiled software that was audited by their
> programmers, QA team and security personnel it is OK for me.
... And in real life that's not enough at all. Internal security audit
is a must, I agree. But unless the software in question is only used
internally by completely trusted personel - good, secure software
should be audited externally.
Inability to access the source code of said software is a serious
disadvantage in such a case.
Inability to *change* the source of said software equals inability to
use security-fixed software for large amounts of time (can be
sometimes remedied with assorted klugdes, true).
Inability to *deploy* the changed software (aka tivoized software) means
the same.
> If I pay for the software then it's fine from my side to get a packaged
> product.
Ok. No arguments here. Note that free software does not equals zero
cost or lack of said 'packaged product'. Case study - Red Hat.
> I had a talk with a friend about the dangerous things on the Internet
> and the conclusion was that some might not understand that the Internet
> is just a "reflection" of the real world and there is no magic there.
> The same crooks can be found both in the real world and the Internet.
Ok. No arguments here too.
> In a case that a software vendor is suspected to be violating basic
> security requirements intentionally it would black list the name brand
> and the software.
False. There are numerous examples of the contrary. Starting with the
Microsoft, but not ending here.
> If we are talking about a complex piece of software then it is possible
> that flaws do exist and it is also applies to any Linux and open source
> software the same way(statistically) as non open source.
Oh, do I see 'They are bad too' argument here, right?
> Since I do have some experience with health care related programming
> subjects and I do also have couple medical facilities that runs a
> software with critical code I wrote and designed I can give a scenario.
> When a sysadmin decides on what software to use for these mission
> critical human life related systems he needs to fully understand the
> weight of using software(open source and non open source, free or non-free).
> He needs to be able to run a command such as "apt-get install squid"
> without any fear that human life's would be affected by it.
> It means that he will have someone that he can trust to test it
> externally and verify it fits the purpose or that the software was
> tested enough by the developers and by the distribution team.
> Free and non Free, open source or non open source is not the question at
> all in this case.
False. See above.
> For some, when looking at a non-free software in banking or health care
> the question is not if it is more dangerous since the main question and
> almost only question is "is this piece of software fit for this role I
> requrie?" and it contains kind of "recursively" security and operations
> sides.
That only means that said 'some' are unfit to do their role.
> The only dangerous software is a "dangerous" software!
> The definition of dangerous is not by free or non free, open source or
> none open source.
> It's a subject by itself that requires a new definition in any software
> adoption steps.
> Would a bug in exim, a fatal one, makes exim a dangerous piece of
> software? The answer is that in some cases it would indeed do that but
> in other cases it would be dangerous the same way as postfix or MS exchange.
By itself - no, such bug does not make exim bad or good.
The amount of such bugs for period of time, the amount of time which
took fix said bugs, and last, but not least - the ability to check
software for a similar bugs, and correctness of the fix - these things
do make the software good or bad.
And (see above) - free software clearly wins here. With some inevitable
exceptions sadly (PHP anyone?).
As for that parody for MTA called Exchange - no sane human being should
use that human-powered blackbox. As a side note - you clearly did the
right thing by choosing Postfix :)
> You can have arguments about a specific vendor\provider\programmer
> software or a repository based on it's characteristics and statistically
> it might fit debian non-free repo but it cannot make all non-free
> software out-there to be dangerous and it's not an argument from debian
> non-free to other software or from other software to debian non-free.
On the contrary - it can. Every time a person installs (or gets
installed, it's no different here) a non-free software - a person
inevitably lowers overall security of installation. And it brings a
certain amount of suffering, the way it should.
> A part of the health care facility sysadmin duties is to make sure that
> he can maintain the software or at-least to make sure that there are
> out-there developers, testers and others who can answer the facility
> requirements.
Hint one. Here it's considered *very rude* to imply that all sysadmins
are male only. Political correctness and stuff ;)
Hint two. By such statement you imply that sysadmin in question should
willingly give up the control of administered software, just because. A
controversial point of view, to say the least.
> The above is one of the main reasons that many sysadmins prefer to use
> RedHat and Windows despite the fact that both companies cannot always be
> aware of very critical bugs.
Oh. Now you put the Red Hat Enterprise Linux in the non-free category.
May I ask why you did so?
> This is not what makes these companies and their software dangerous.
>
> If you do feel that this is what makes software dangerous indeed it's an
> argument but it might not meet reality or reality requirements in many
> facilities.
>
> Then, what do you mean by dangerous? it was not really clear from your
> words.
Lack of control is dangerous.
Undeclared capabilities of the software are dangerous.
Unknown quality of code (without the ability to evaluate it at least)
is dangerous.
Reco
Reply to: