The post was full of your self criticism about not being able to learn about processes in spite of growing up with engineers, and this imaginative defence of your inability to read. What was there to counter?
which the legitimate lemonade is made is open and trusted, the compiled product is automatically trusted not to have been tampered with?
Not tampering is part of the process. Your fallacy is to think Open Source is mainly about the source being visible - actually it is about the process. Visible source is just the final step without which the whole process loses all value.
That fallacy is why you point to Microsoft "suddenly" open-sourcing its products, and talk about liquids without talking about context or the purpose of the liquid. It was fun to see you tripped up when your non-specification of the purpose was caught.
So my hope was in vain, you never understood processes. It is a difficult to study in isolation, being multi-disciplinary but read "Distillation Design", by Kister to get started.
Ok, probably you don't understand processes. Let me try my reply, in the hope that you once understood some of that, and only recently stopped understanding. Because it is difficult to teach in a post:
See, if I take the source code for Firefox and change every instance of "Firefox" to "Firefix", that is no longer the source code for Firefox; it will never be the source code for Firefox unless I commit that code back to the project and one of the project's maintainers accepts my code. If I compile a binary from that code, it is not a Firefox binary, it is a closed source binary based on Firefox. "Firefox" to "Firefix" is an obvious change, but you also don't know what other changes I may have made to that code before compiling it; let's assume I made a handful of other less obvious changes, perhaps of a malicious nature. You would never see them; they're not in the code for Firefox. Now, let's assume I only make those non-obvious changes and still call it Firefox. Well, it's still not Firefox, because my changes don't exist in the Firefox codebase; and you still don't know I made those changes because all you have is a binary, and that binary is not Firefox. Firefox's "distribution methodology" means nothing to that binary. It means just as much to any other binary that you did not compile yourself; you have absolutely no way of knowing what source it was compiled from.
Absolutely correct. And completely irrelevant to my original question.
To illustrate this another way, let's examine two bottles of liquid. Both liquids have an identical appearance, taste, smell, and feel, and both have similar labeling; the only apparent difference is that one has ingredients (source code) listed on the bottle and the other does not. The ingredients listed are water, sugar, and lemon juice. Which bottle do you trust?
Isolated pieces of liquids? To be used as pesticide? The limbic (and more primitive parts of ) brain takes over, and the prettier salesgirl wins. Every single time. By prettier salesgirl I mean it literally, as well as the looks of the packaging, supermarket positioning, looks of the fluid itself if the packaging is transparent etc.
As a process, you mean to say one company refuses to list ingredients, refuses to let health inspectors evaluate their processes, restricts independent labs from publishing findings of testing the pesticidal qualities of the liquid.
Another encourages you to walk into their factories, listen to your inputs about its processes - though it may not act on them, though the inputs it does act on were also publicly given, teaches you to make your own lime flavoured pesticide etc. Yes, I choose the open source one.
Now, given our conversation thus far, I'm going to assume you'll trust the open source bottle. After all, it tells you, right there in plain text, what's in it, and you know there's nothing unsafe about water, sugar, or lemon juice, they just mix to make lemonade.
So attracts ants and other pests in addition to being maybe useless as a pesticide. Even if you meant the liquid as a drink all along - no, only the process matters. Isolated drink/pesticide decisions cannot be taken by the neo-mammalian cortex as there isn't enough information. Though the neo-mammalian cortex will do its damnedest to justify (rationalize) the decision taken by the brain stem and neighbours.
So you are trying to climb out of the ditch you dug for yourself. Do you take back the admission you made about differences in distribution methodologies of open source vs closed source software? If not, where is the evidence that in spite of heavy differences in distribution methodologies - trust levels can be identical? I love non-trivial proofs - I will settle for evidence here.
I typed the rest of the reply, but I will save it for later.
Yes - you agree that the distribution mehodology and hence the risks are different between open source and closed source software. Now having dug a nice ditch for yourself, how do you go about proving the trust levels EQUAL ?
You litter your post with this meaningless qualifier - I didn't care initially because it doesn't add any value to the discussion. But since most of the post is now full of this making it difficult to read - let me state that this is meaningless. Like adding "unless false" to any proposition.
Why? Because no one has built anything of the level of typical modern software system from the ground up. Ever. So, unless false, if true, and whenever 1 ==1 , this is a meaningless qualifer.
Because, and I repeat myself, it is self-evident: you must trust whoever builds your binaries. They could very well have slipped any code into what they compiled, not just what you see when you review the project's source.
Which is why in a typical open source software usage scenario - multiple entities down the distribution build the binaries - often with different toochains, small modifications to code as per their (different) understanding. Remember, these are multiple entities/people/groups/organizations who have no conflict of interest, don't have a single "management hierarchy", not even live in the same legal jurisdiction.
Are you telling me that the trust level of the entire world conspiring against you is the same as one company preferring its interest over yours?
you DO NOT know what source a binary you did not compile yourself was compiled from.
Which has zero to do with my question - why is the TRUST LEVEL EQUAL between 2 completely different software development methodologies? Where the motivation of developers, distributers, testers, users, reviewers are COMPLETELY DIFFERENT.
you have just as much access to the actual source your binaries
Yes, but why is trust directly proportional to just "access to actual source your binaries are... " ? Or, in general, an increasing function thereof? Why doesn't a publicly discussed developmental model have a role in determining the level of trust? Awareness of bug database, bug fix policy, open bugs (except the details of some security sensitive bugs) doesn't have a role? Code review reports from qualified, non-NDA-bound and non-conflict-of-interest people doesn't have a role?
I don't see you produce any evidence of that.
Yes, you have access to the source the package maintainer claims
Which is why some definitions of Open Source Software contain conditions about "easy" compilability of the source distributed. By the users.
just as much as you're trusting Microsoft when you use Windows
Why just as much as? Why is the trust level equal?
To phrase it in a way you'll understand: Microsoft could open source Windows tomorrow, that source could be completely clean and devoid of any "evil", and you'd still not trust their binaries any more than you do today.
Not the first day. But if progressively development discussions/decisions happen in public, bug database is public, source code is reviewed over time by more and more people who don't have a conflict of interest with Microsoft, are more and more qualified to do the review, and get more and more time to review - why shouldn't the trust levels decrease over time as some of the trust has been replaced with verification?
Then, as a corollary, why should the level of trust in software that has been Open Source from very early on, be considered the same as the level of trust in as yet closed source software ?
No, I'm well aware of the paper for a long time. All it proves (relevant to this discussion) is that there is some positive level of trust when using open source software. You are just repeating that in a million ways. I know that.
I also know that there is some positive level of trust when using closed source software.
What you haven't even started giving any evidence for, is that these levels of trust are equal. Unless your axiom is that any 2 positive numbers are equal to each other, I don't see a way of deriving this evidence from your endless steam of evidence that both levels of trust are positive.
Still no evidence of "just as much" trust. You've already given evidence of both being non-zero trust scenarios, but never any evidence of both being equal levels of trust.
Do you think all non-zero numbers are equal to one another?
Run Windows Update before you leave the office. I do. I never take my laptop anywhere new without making sure it is all up to date, just one of those things you have to do.
In other words, Windows is not ready for prime time, since people "have" to do things to be able to work with it.
My story is purely anecdotal and definitely not scientific. But when I see apparently knowledgeable people saying they can't keep 10 off their machines whatever they do, it makes me wonder if they have an agenda with what they're saying.
If you (or lots of other non-NDA-bound people) had the source code for windows update , you wouldn't have to wonder. You could have found out yourself, or the other people who hadn't signed NDAs would have made it public knowledge why it happens in some systems and not in others.
"Stable" is the assumption here. If applications are 10 times as expensive as compared to other more popular platforms, why wouldn't users move to those platforms at the next chance?
developer struggled on and therefore are more likely to have bugs
Not really. More likely that the developer thinks there might be bugs here, and might consider this part of code to be treated with care from now on. But more likely to have bugs? I think there is an equal, if not bigger, contributor of bugs from developer thinking something to be very simple whereas it turns out to be not-so-simple. This comes from lack of domain knowledge, lack of imagination/knowledge of all usage scenarios, unawareness of industry standards in this type of code etc.
Though it might work well as a lie detector - if asked about his confidence in this piece of code and developers answers positively, he is more likely to be telling a lie.
You are mistaken. Computers have already created more than their programmers could - at times the programmers knew nothing about a field except Deep Learning (TM) and their programs created better ideas than trained humans in the field.
So computers can expand the way we listen to music - in fact humans do it by trial and error - computers might do it by analyzing human brain, reactions to music listening etc.
In fact not looking for some kind of answers is a weakness - still getting that answer is only a partial compensatory strength.
You are mistaken. Computers have already learnt more than their programmers - at times the programmers knew nothing about a field except deep learning, and their programs beat trained humans in the field.
So computers can expand the way we listen to music - in fact humans do it by trial and error - computers might do it by analyzing human brain, reactions to music listening etc.
Slashdot Mirror
You are imagining.
Well, you can't look beyond the end of a process. Hire an old AI to parse language, and you might be able to make sense.
The hypothesis is neither here not there.
Not implied, but you imagined to save your face.
The post was full of your self criticism about not being able to learn about processes in spite of growing up with engineers, and this imaginative defence of your inability to read. What was there to counter?
If I had said "a step". I didn't, so you need to imagine creatively to feel better. And you need to run to daddy too. Impressive.
What do you think visible source is the final step of? When just preceded by "it's all about the process" ?
AI of 1970 has surpassed your language processing abilities of today.
If the process doesn't include visible source, all value of the process is lost. Again, your brain works in silos, so you may not understand.
What did you understand from Distillation Design?
which the legitimate lemonade is made is open and trusted, the compiled product is automatically trusted not to have been tampered with?
Not tampering is part of the process. Your fallacy is to think Open Source is mainly about the source being visible - actually it is about the process. Visible source is just the final step without which the whole process loses all value.
That fallacy is why you point to Microsoft "suddenly" open-sourcing its products, and talk about liquids without talking about context or the purpose of the liquid. It was fun to see you tripped up when your non-specification of the purpose was caught.
So my hope was in vain, you never understood processes. It is a difficult to study in isolation, being multi-disciplinary but read "Distillation Design", by Kister to get started.
Ok, probably you don't understand processes. Let me try my reply, in the hope that you once understood some of that, and only recently stopped understanding. Because it is difficult to teach in a post :
See, if I take the source code for Firefox and change every instance of "Firefox" to "Firefix", that is no longer the source code for Firefox; it will never be the source code for Firefox unless I commit that code back to the project and one of the project's maintainers accepts my code. If I compile a binary from that code, it is not a Firefox binary, it is a closed source binary based on Firefox. "Firefox" to "Firefix" is an obvious change, but you also don't know what other changes I may have made to that code before compiling it; let's assume I made a handful of other less obvious changes, perhaps of a malicious nature. You would never see them; they're not in the code for Firefox. Now, let's assume I only make those non-obvious changes and still call it Firefox. Well, it's still not Firefox, because my changes don't exist in the Firefox codebase; and you still don't know I made those changes because all you have is a binary, and that binary is not Firefox. Firefox's "distribution methodology" means nothing to that binary. It means just as much to any other binary that you did not compile yourself; you have absolutely no way of knowing what source it was compiled from.
Absolutely correct. And completely irrelevant to my original question.
To illustrate this another way, let's examine two bottles of liquid. Both liquids have an identical appearance, taste, smell, and feel, and both have similar labeling; the only apparent difference is that one has ingredients (source code) listed on the bottle and the other does not. The ingredients listed are water, sugar, and lemon juice. Which bottle do you trust?
Isolated pieces of liquids? To be used as pesticide? The limbic (and more primitive parts of ) brain takes over, and the prettier salesgirl wins. Every single time. By prettier salesgirl I mean it literally, as well as the looks of the packaging, supermarket positioning, looks of the fluid itself if the packaging is transparent etc.
As a process, you mean to say one company refuses to list ingredients, refuses to let health inspectors evaluate their processes, restricts independent labs from publishing findings of testing the pesticidal qualities of the liquid.
Another encourages you to walk into their factories, listen to your inputs about its processes - though it may not act on them, though the inputs it does act on were also publicly given, teaches you to make your own lime flavoured pesticide etc. Yes, I choose the open source one.
Now, given our conversation thus far, I'm going to assume you'll trust the open source bottle. After all, it tells you, right there in plain text, what's in it, and you know there's nothing unsafe about water, sugar, or lemon juice, they just mix to make lemonade.
So attracts ants and other pests in addition to being maybe useless as a pesticide. Even if you meant the liquid as a drink all along - no, only the process matters. Isolated drink/pesticide decisions cannot be taken by the neo-mammalian cortex as there isn't enough information. Though the neo-mammalian cortex will do its damnedest to justify (rationalize) the decision taken by the brain stem and neighbours.
So you are trying to climb out of the ditch you dug for yourself. Do you take back the admission you made about differences in distribution methodologies of open source vs closed source software? If not, where is the evidence that in spite of heavy differences in distribution methodologies - trust levels can be identical? I love non-trivial proofs - I will settle for evidence here.
I typed the rest of the reply, but I will save it for later.
Yes - you agree that the distribution mehodology and hence the risks are different between open source and closed source software. Now having dug a nice ditch for yourself, how do you go about proving the trust levels EQUAL ?
I repeat : EQUAL .
If you're building from source yourself, it does.
You litter your post with this meaningless qualifier - I didn't care initially because it doesn't add any value to the discussion. But since most of the post is now full of this making it difficult to read - let me state that this is meaningless. Like adding "unless false" to any proposition.
Why? Because no one has built anything of the level of typical modern software system from the ground up. Ever. So, unless false, if true, and whenever 1 ==1 , this is a meaningless qualifer.
Because, and I repeat myself, it is self-evident: you must trust whoever builds your binaries. They could very well have slipped any code into what they compiled, not just what you see when you review the project's source.
Which is why in a typical open source software usage scenario - multiple entities down the distribution build the binaries - often with different toochains, small modifications to code as per their (different) understanding. Remember, these are multiple entities/people/groups/organizations who have no conflict of interest, don't have a single "management hierarchy", not even live in the same legal jurisdiction.
Are you telling me that the trust level of the entire world conspiring against you is the same as one company preferring its interest over yours?
you DO NOT know what source a binary you did not compile yourself was compiled from.
Which has zero to do with my question - why is the TRUST LEVEL EQUAL between 2 completely different software development methodologies? Where the motivation of developers, distributers, testers, users, reviewers are COMPLETELY DIFFERENT.
you have just as much access to the actual source your binaries
Yes, but why is trust directly proportional to just "access to actual source your binaries are ... " ? Or, in general, an increasing function thereof? Why doesn't a publicly discussed developmental model have a role in determining the level of trust? Awareness of bug database, bug fix policy, open bugs (except the details of some security sensitive bugs) doesn't have a role? Code review reports from qualified, non-NDA-bound and non-conflict-of-interest people doesn't have a role?
I don't see you produce any evidence of that.
Yes, you have access to the source the package maintainer claims
Which is why some definitions of Open Source Software contain conditions about "easy" compilability of the source distributed. By the users.
just as much as you're trusting Microsoft when you use Windows
Why just as much as? Why is the trust level equal?
To phrase it in a way you'll understand: Microsoft could open source Windows tomorrow, that source could be completely clean and devoid of any "evil", and you'd still not trust their binaries any more than you do today.
Not the first day. But if progressively development discussions/decisions happen in public, bug database is public, source code is reviewed over time by more and more people who don't have a conflict of interest with Microsoft, are more and more qualified to do the review, and get more and more time to review - why shouldn't the trust levels decrease over time as some of the trust has been replaced with verification?
Then, as a corollary, why should the level of trust in software that has been Open Source from very early on, be considered the same as the level of trust in as yet closed source software ?
No, I'm well aware of the paper for a long time. All it proves (relevant to this discussion) is that there is some positive level of trust when using open source software. You are just repeating that in a million ways. I know that.
I also know that there is some positive level of trust when using closed source software.
What you haven't even started giving any evidence for, is that these levels of trust are equal. Unless your axiom is that any 2 positive numbers are equal to each other, I don't see a way of deriving this evidence from your endless steam of evidence that both levels of trust are positive.
Still no evidence of "just as much" trust. You've already given evidence of both being non-zero trust scenarios, but never any evidence of both being equal levels of trust.
Do you think all non-zero numbers are equal to one another?
Is speech really speech if no one hears it?
FOSS relies just as much on trust as closed-source
You give no evidence of "just as much".
The more varied code review and more accessible bug trackers clearly point to less trust and more verification.
Run Windows Update before you leave the office. I do. I never take my laptop anywhere new without making sure it is all up to date, just one of those things you have to do.
In other words, Windows is not ready for prime time, since people "have" to do things to be able to work with it.
My story is purely anecdotal and definitely not scientific. But when I see apparently knowledgeable people saying they can't keep 10 off their machines whatever they do, it makes me wonder if they have an agenda with what they're saying.
If you (or lots of other non-NDA-bound people) had the source code for windows update , you wouldn't have to wonder. You could have found out yourself, or the other people who hadn't signed NDAs would have made it public knowledge why it happens in some systems and not in others.
Finally a story telling us that Americans are not as stupid as generally believed.
Because these methods will result in 404 Not Found?
You answered your own question you asked here : https://tech.slashdot.org/comm...
They use shit marketing because idiots like you will do Microsoft's marketing for them.
"Stable" is the assumption here. If applications are 10 times as expensive as compared to other more popular platforms, why wouldn't users move to those platforms at the next chance?
So your plan kills itself pretty soon.
developer struggled on and therefore are more likely to have bugs
Not really. More likely that the developer thinks there might be bugs here, and might consider this part of code to be treated with care from now on. But more likely to have bugs? I think there is an equal, if not bigger, contributor of bugs from developer thinking something to be very simple whereas it turns out to be not-so-simple. This comes from lack of domain knowledge, lack of imagination/knowledge of all usage scenarios, unawareness of industry standards in this type of code etc.
Though it might work well as a lie detector - if asked about his confidence in this piece of code and developers answers positively, he is more likely to be telling a lie.
OK, if you insist.
You are mistaken. Computers have already created more than their programmers could - at times the programmers knew nothing about a field except Deep Learning (TM) and their programs created better ideas than trained humans in the field.
See https://www.ted.com/talks/jere...
So computers can expand the way we listen to music - in fact humans do it by trial and error - computers might do it by analyzing human brain, reactions to music listening etc.
In fact not looking for some kind of answers is a weakness - still getting that answer is only a partial compensatory strength.
You are mistaken. Computers have already learnt more than their programmers - at times the programmers knew nothing about a field except deep learning, and their programs beat trained humans in the field.
See https://www.ted.com/talks/jere....
So computers can expand the way we listen to music - in fact humans do it by trial and error - computers might do it by analyzing human brain, reactions to music listening etc.