Clearly, as I only have these "issues" with trolls like yourself, the problem lies with you. Fortunately, I feed your kind willingly, as a form of entertainment. I find it protects the weaker-minded who may internalize your idiocy.
My self criticism? Now who's imagining shit? You're still the one who can't recognize where a process starts and ends and you're trying to school me? Like I said, read Kister's book again, this time without shoving it up your ass first. You'll have to pull your head out of there, but I promise the experience will be life-changing.
If I had said "a step". I didn't, so you need to imagine creatively to feel better.
Hmm...
If the process doesn't include visible source, all value of the process is lost.
You're right, you didn't literally say "a step", it was implied. There's a huge difference between including and ending in. You made two distinctly different statements; it's not my fault you don't understand this.
And you need to run to daddy too.
It took you 7 hours to come up with that scathing insult? I was speaking to experience; spending weekends in an engineering workshop from age 4 through my teen years and actually getting to work with the equipment and pick the brains of the people who pioneered the modern incarnation manufacturing automation industry might have given me some insight. It is truly telling that, rather than continue attempting to counter my points, you've turned to insults.
One good turn...
Impressive.
What's truly impressive is that you manage to remember to breathe.
So, doing the wrong thing is better than doing nothing at all? Just because you don't know what the right thing to do is, you don't just go out and do any old thing just to look like you're doing something. I voted for Obama. Twice. His plan was good. What Congress passed back to him was shit. He still signed it, and for that I blame him and only him.
For the record, he only got my vote the second time because there was no good alternative. I doubt I'll even vote this year, given the choices; there isn't one I wouldn't complain about, so I'll retain my right to bitch about whoever's elected.
The only problem with Texas is that the blathering idiots are the vocal minority in the state, which makes everyone there look like blathering idiots. Contrast that with California, where the problem is that the blathering idiots don't just say stupid shit on national news, they lobby politicians and convince them to be blathering idiots. The problem is that the same people who aren't paying enough attention to see that most Texans aren't blathering idiots also pay little enough attention that they can say, in all seriousness, "at least California is doing something".
I say this as a California resident. Sometimes doing something is the wrong thing; especially when you know the thing you're doing isn't going to solve the problem you're facing. Like banning certain guns from legal purchase; how's that working out in Oakland and Vallejo, where literally every gun crime reported or investigated is committed with an illegally acquired firearm. Literally every one. None committed with legally purchased guns. Yet they're pushing more gun laws through the state legislature right now.
On the other hand, Texas politicians sound like complete doofuses in the press, which makes the entire state look like a bunch of bafoons. But, the reality is that a bunch of smart, freedom-loving (and freedom-protecting) people live there, and they prevent the doofuses in charge from doing too much damage.
And if you think that's an attack on Texas, you're one of the ones who's not paying attention.
My language processing skills? Really? You don't see how moving "visible source" from the "final step" to "a step" changes the meaning of the message? And you're questioning my language skills?
For the record, I was raised in an engineering household. My father is a robotics engineer, I grew up around electrical, mechanical, chemical, and software engineering, it has been an ingrained part of my personality since before I started kindergarten. You want to talk about being multi-disciplinary? Let's talk, I've got literally a lifetime of it under my belt.
With that out of the way, yes, it does matter where in the process the visible source is; the source is the product. Much like ginn or vodka are the product of their respective distillation methods, source code is the product of an open source project. The product is, by definition the last step of the process.
That you take that gin or vodka and turn it into a martini does not change the fact that the gin or vodka, and not the martini, was the product of the distillation process. Likewise, that you take that source code and compile it into a binary does not change the fact that the source code, and not the binary, was the product of the development process. When someone hands you a martini and you accept it, you are trusting that they did not roofie it; if they did, that is separate from the gin or vodka distillation process. When someone hands you a Firefox binary and you accept it, you are trusting that they did not compile malicious code into it; if they did, that is separate from the Firefox development process.
Perhaps the most important thing to understand about processes, which you appear to be missing, is where they start and stop. Perhaps, for you, another read-through of Kister's book is in order?
Thank you for pushing me to find a way to make Distillation Design relevant, though.
The best available in CA is a $4500 deductible and 20% copay for about $360/mo. Compare that to the $153/mo I was previously paying for no-deductible, no-copay. See here.
I live in Texas which is probably one of the worst states for healthcare
Against all probabilities, your rates in Texas are relatively cheap.
So, Mozilla's project maintainers influence Canonical's package maintainers? Canonical, not Mozilla, compiles the Firefox binaries in the Ubuntu repositories; Mozilla's process means nothing once the Firefox package maintainer at Canonical takes hold of that code. And you're still trusting that package maintainer not to slip his own malicious code into Firefox when he compiles it.
Visible source is just the final step without which the whole process loses all value.
Bingo! There we have it! And a compiled binary is one step beyond source code! You don't have visible source if you're using someone else's binary! And you just said it yourself: without visible source, the whole process loses all value.
read "Distillation Design", by Kister to get started
I'm familiar, actually; you're simply misinterpreting. See above.
You must be borrowing someone else's computer and internet connection, because the subsidies that allow that to happen don't apply to anyone who earns enough to afford their own.
But since the reform act it has risen at a slower pace than it did before the reform.
Only if you ignore the initial more-than-doubling in price and elimination of no-deductible and no-copay plans when the ACA first came into effect.
In fact, I'm now paying more than double what I paid in 2013 for a no-deductible, no-copay plan and paying even more toward a deductible ($4500 on $4300 in premiums), on top of a 20% copay. I don't benefit from that in any way. My wife does, because she is now able to get coverage; so I'm now actually paying more than 4x (nearly 5x) as much for coverage, essentially just to cover her because I'll never meet my deductible in a given year so I'm paying more to cover myself for nothing.
In detail, I was paying $153/mo for a no-deductible no-copay plan covering just myself. I now pay $717/mo for a plan with a $4500/person deductible and a 20% copay. I went from paying $1836/yr for health care to paying $8604 in premiums and at least a $4500 deductible before the insurance even kicks in. To be fair, only half of that $8604 covers me, so I'll do the right thing and cut that number in half: I'm not paying $4302 in premiums, with effectively no coverage until my medical expenses exceed $4500 in a calendar year. That means I effectively don't have insurance until I've spent $8802; then, I still pay 20%.
Yes, that's such a benefit over the $1836 and done I was paying before.
Now yes my wife does see some benefit from it... potentially. Let's analyze: It takes her 6mo to meet her $4500 deductible, and 20% of that (what the remainder of the year will cost out-of-pocket) is $900. $4302 (her half of the premiums) + $4500 (deductible) + $900 (copay) = $9702. That's $702 more than simply paying out of pocket. So, where's the benefit? She got treatment even without coverage and the cost was the same (actually it was a bit lower because costs have gone up since then, but I'm looking at today's cost for this comparison and out-of-pocket still wins).
And that's compounded by the fact that the insurance company (the only one our providers of choice accept, mind you) insists that, since we're married, if we're both covered we must both be on the same plan. If not for that, I could be on a much cheaper plan as I haven't seen a doctor for a non-emergency condition in over half my life and I'm perfectly healthy aside from a back injury (one of those emergency conditions) currently being treated by a chiropractor, as recommended by the doctor who carried out the initial treatment, which is not covered by my insurance. The cost of initial treatment of my back injury (last year, so it means nothing for this year's deductible) would have been about half what I paid for insurance, deductible, and copay last year, were I on the cheaper plan. But the insurance company refuses to allow that; my wife is on the better (for her specific case) plan, so I must also be on that plan or find a different insurer for myself (which means finding new care providers).
Absolutely correct. And completely irrelevant to my original question.
Your original question has already been answered. If you compile yourself, FOSS is more trustworthy. However, I was making a point before you came along; I set the topic and your question was not relevant to that topic.
To be used as pesticide?
Who said anything about pesticide?
you mean to say one company refuses to list ingredients
well, if we're talking about pesticide, they don't have to list ingredients, but who said pesticide?
refuses to let health inspectors evaluate their processes
health inspectors don't inspect pesticide... but, then... who said pesticide?
teaches you to make your own lime flavoured pesticide
If you trust someone to teach you how to make lime flavored anything from water, sugar, and lemons, then you're a bigger idiot than I had presumed. Also, who said anything about pesticide?
So attracts ants and other pests in addition to being maybe useless as a pesticide.
No, really, who mentioned pesticide?
only the process matters
So, then, it doesn't matter that someone could have poured out a bunch of bottles of that lemonade and replaced them with the otherwise identical poison, then put them back on the shelf? Because the process by which the legitimate lemonade is made is open and trusted, the compiled product is automatically trusted not to have been tampered with?
You still fail at logic. Perhaps it's because you're so caught up in process.
Though the neo-mammalian cortex will do its damnedest to justify (rationalize) the decision taken by the brain stem and neighbours.
To be fair, Congress gutted what was a good bill. Obama lacked the testicular fortitude to not sign what Congress handed back to him of his bill, so it's still his fault we're stuck with it; but the bill he handed Congress was good.
Population: It's larger. SIGNIFICANTLY larger. Of course there will be more deaths because of that.
It's measured in deaths per 100k. If you have 100k people and 300 die, that's 300/100k. If you have 200k people and 600 die, that's 300/100k. If you have 200k people and 700 die, that's 350/100k. That's what went up, not just the total number of deaths.
It's really simple if you follow simple logic. Answer the two questions at the bottom of my previous post, they're designed to lead you right to that logic.
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.
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?
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.
Now consider that the second bottle may contain a poison that will kill you immediately upon ingestion. Do you still trust the bottle with ingredients printed on it?
Why? You didn't mix and bottle those ingredients yourself, you're only trusting whoever did not to have, instead, filled the bottle with poison.
Why? Because no one has built anything of the level of typical modern software system from the ground up.
FYI: "build from source" refers to the binary in question, not the entire toolchain. There's a reason I mention the two concepts separately: because they're different.
in a typical open source software usage scenario - multiple entities down the distribution build the binaries
Right, so I have to trust multiple different entities not to have fucked with it
often with different toochains
Which will yield different and thus non-comparable binaries, leaving you no means to verify the code was unaltered by comparing multiple binaries
small modifications to code as per their (different) understanding...
and indistinguishable from a backdoored binary
Remember, these are multiple entities/people/groups/organizations who have no conflict of interest
You know that evidence you keep asking me for? While it's true that most may simply want to put out a good and useful binary, it only takes one bad actor and, as you said above, everyone's binaries are likely to be different for a multitude of reasons so you can't really catch it by comparing to your own compiled copy. At least we agree on that point.
don't have a single "management hierarchy"...
aside from the management structure of the project or distro, on behalf of whom they are compiling and providing the binary
not even live in the same legal jurisdiction
... making them harder to prosecute, should they turn a bad actor.
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?
It doesn't take the entire world cooperating to allow a bad binary into a repo, it takes the package maintainer of a single package in that repo deciding it would be nifty to slip a bit of malicious code into it, or having their credentials hijacked by someone who thinks so. In the case of the latter, it might (or might not) be reported in a timely manner and corrected before much damage is done, but in the case of the former, we've both already alluded to how difficult it would be to catch that, and why. Also, given that a package maintainer for a given distro has any number of people he can point the finger at to absolve himself of responsibility, while Microsoft has... well... Microsoft... in terms of raw accountability, I'd be more inclined to trust Microsoft.
Which has zero to do with my question - why is the TRUST LEVEL EQUAL between 2 completely different software development methodologies?
I answered that question, though it was orthogonal to the point being discussed. I'll repeat that answer yet again: If you're compiling your own binary from source you have reviewed, yes, that requires a lower level of trust than trusting a binary provided by someone else. I, however, am talking about the 99.95% of users who do not compile their own binaries and, therefore, must trust binaries provided by others. Those users, of which I'm nearly certain you are one, do not know what source the binaries they run were compiled from, because they did not compile those binaries themselves form known source. They have exactly as much insight into the actual source those binaries were compiled form as a user of closed source software has into the source those binaries were compiled from.
It doesn't matter how heavily reviewed, tested, vetted, and trusted the publicly available code of a project is if the person who supplied your binary skipped a bit of their own code in at compile time. The development methodology of the project has no effect on that. Period.
Not sure if incredibly dense or just trolling, but here goes...
Yes, but why is trust directly proportional to just "access to actual source your binaries are... " ? Or, in general, an increasing function thereof?
Your other questions lead quite well to the answer.
Why doesn't a publicly discussed developmental model have a role in determining the level of trust?
If you're building from source yourself, it does.
Awareness of bug database, bug fix policy, open bugs (except the details of some security sensitive bugs) doesn't have a role?
That's relevant for the functional usability of the software, but not so much for trust in its security. Visibility into the source code itself is useful for that but, again, only if you're compiling it yourself (and with a trusted toolchain).
Code review reports from qualified, non-NDA-bound and non-conflict-of-interest people doesn't have a role?
No, not at all if you're part of the 99.95% of FOSS users who don't compile themselves and, therefore, have to trust someone else not to have slipped a backdoor into the code they compiled.
I don't see you produce any evidence of that.
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 some definitions of Open Source Software contain conditions about "easy" compilability of the source distributed. By the users.
And, yet, users who compile everything on their system from scratch are exceedingly in the minority, with most relying on binary packages available in their distro's repositories, such that they must trust the individuals who compiled those binaries not to have altered the publicly available source prior to compilation. Have I repeated myself enough times yet?
Why just as much as? Why is the trust level equal?
Because you have just as much guarantee that the package maintainer didn't slip malicious code into the project before compiling it. You see the code available in the project's repository but, by necessity, the package maintainer compiles from their own local copy of that code; nothing stops them from slipping in whatever other code they want before they compile. Again, I repeat myself.
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?
Trust in the code provided by Microsoft, and the binaries resulting when you compile it yourself? Yes. Trust in the binaries provided by Microsoft? Why would you trust them any more than you do today, given that you have no guarantee they were compiled from the exact same code made publicly available?
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 ?
Again, you must separate binaries compiled yourself from binaries compiled by others. If you compiled it yourself from well-audited code, trust it. If someone else compiled it, well, you don't know that they didn't modify the code before they compiled it. I keep repeating this, hoping that it'll eventually sink in: you DO NOT know what source a binary you did not compile yourself was compiled from. Even if the project's sou
Again: If you're not one of the few who compiles everything yourself, you have just as much access to the actual source your binaries are compiled from as someone using closed source software. Yes, you have access to the source the package maintainer claims to have compiled from, but you're trusting them, just as much as you're trusting Microsoft when you use Windows, to not have slipped a back door or some other baddies in before compile time.
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.
You don't have to be an "idiot" (person with severe intellectual disability) to happen not to have learned about the finer points of long-haul Internet peering negotiation.
You are correct, sir, but it certainly does help enable one to speak with authority on subjects they do not understand.;)
Well there's the thing! Even with FOSS, most people do not compile their own binaries, and there's the trust issue again. And if your compiler is backdoored the same way as the package maintainer's compiler (which is perfectly possible if you both got your compilers from the same place), both will generate the same altered output. That is to say, the package maintainer may not even be the malicious party.
Check out Ken Thompson's Reflections on Trusting Trust. Yes, it's old, probably older than you if you haven't read it already, but it's still relevant, and will remain so for as long as we use computers.
Sure, you can review the source and fix security flaws that you find there; but, how can you know your compiler isn't replacing them or adding others? Read the paper.
Slashdot Mirror
Clearly, as I only have these "issues" with trolls like yourself, the problem lies with you. Fortunately, I feed your kind willingly, as a form of entertainment. I find it protects the weaker-minded who may internalize your idiocy.
My self criticism? Now who's imagining shit? You're still the one who can't recognize where a process starts and ends and you're trying to school me? Like I said, read Kister's book again, this time without shoving it up your ass first. You'll have to pull your head out of there, but I promise the experience will be life-changing.
the modern incarnation of the manufacturing automation industry
Typos. They happen.
If I had said "a step". I didn't, so you need to imagine creatively to feel better.
Hmm...
If the process doesn't include visible source, all value of the process is lost.
You're right, you didn't literally say "a step", it was implied. There's a huge difference between including and ending in. You made two distinctly different statements; it's not my fault you don't understand this.
And you need to run to daddy too.
It took you 7 hours to come up with that scathing insult? I was speaking to experience; spending weekends in an engineering workshop from age 4 through my teen years and actually getting to work with the equipment and pick the brains of the people who pioneered the modern incarnation manufacturing automation industry might have given me some insight. It is truly telling that, rather than continue attempting to counter my points, you've turned to insults.
One good turn...
Impressive.
What's truly impressive is that you manage to remember to breathe.
So, doing the wrong thing is better than doing nothing at all? Just because you don't know what the right thing to do is, you don't just go out and do any old thing just to look like you're doing something. I voted for Obama. Twice. His plan was good. What Congress passed back to him was shit. He still signed it, and for that I blame him and only him.
For the record, he only got my vote the second time because there was no good alternative. I doubt I'll even vote this year, given the choices; there isn't one I wouldn't complain about, so I'll retain my right to bitch about whoever's elected.
The only problem with Texas is that the blathering idiots are the vocal minority in the state, which makes everyone there look like blathering idiots. Contrast that with California, where the problem is that the blathering idiots don't just say stupid shit on national news, they lobby politicians and convince them to be blathering idiots. The problem is that the same people who aren't paying enough attention to see that most Texans aren't blathering idiots also pay little enough attention that they can say, in all seriousness, "at least California is doing something".
I say this as a California resident. Sometimes doing something is the wrong thing; especially when you know the thing you're doing isn't going to solve the problem you're facing. Like banning certain guns from legal purchase; how's that working out in Oakland and Vallejo, where literally every gun crime reported or investigated is committed with an illegally acquired firearm. Literally every one. None committed with legally purchased guns. Yet they're pushing more gun laws through the state legislature right now.
On the other hand, Texas politicians sound like complete doofuses in the press, which makes the entire state look like a bunch of bafoons. But, the reality is that a bunch of smart, freedom-loving (and freedom-protecting) people live there, and they prevent the doofuses in charge from doing too much damage.
And if you think that's an attack on Texas, you're one of the ones who's not paying attention.
My language processing skills? Really? You don't see how moving "visible source" from the "final step" to "a step" changes the meaning of the message? And you're questioning my language skills?
For the record, I was raised in an engineering household. My father is a robotics engineer, I grew up around electrical, mechanical, chemical, and software engineering, it has been an ingrained part of my personality since before I started kindergarten. You want to talk about being multi-disciplinary? Let's talk, I've got literally a lifetime of it under my belt.
With that out of the way, yes, it does matter where in the process the visible source is; the source is the product. Much like ginn or vodka are the product of their respective distillation methods, source code is the product of an open source project. The product is, by definition the last step of the process.
That you take that gin or vodka and turn it into a martini does not change the fact that the gin or vodka, and not the martini, was the product of the distillation process. Likewise, that you take that source code and compile it into a binary does not change the fact that the source code, and not the binary, was the product of the development process. When someone hands you a martini and you accept it, you are trusting that they did not roofie it; if they did, that is separate from the gin or vodka distillation process. When someone hands you a Firefox binary and you accept it, you are trusting that they did not compile malicious code into it; if they did, that is separate from the Firefox development process.
Perhaps the most important thing to understand about processes, which you appear to be missing, is where they start and stop. Perhaps, for you, another read-through of Kister's book is in order?
Thank you for pushing me to find a way to make Distillation Design relevant, though.
If the process doesn't include visible source, all value of the process is lost.
That's not what you just said. What you just said was:
Visible source is just the final step without which the whole process loses all value.
Those are two very different statements; nice backpedal attempt, though.
What did you understand from Distillation Design?
A number of things, none of which are relevant to this discussion.
I live in Texas which is probably one of the worst states for healthcare
Against all probabilities, your rates in Texas are relatively cheap.
Not tampering is part of the process.
So, Mozilla's project maintainers influence Canonical's package maintainers? Canonical, not Mozilla, compiles the Firefox binaries in the Ubuntu repositories; Mozilla's process means nothing once the Firefox package maintainer at Canonical takes hold of that code. And you're still trusting that package maintainer not to slip his own malicious code into Firefox when he compiles it.
Visible source is just the final step without which the whole process loses all value.
Bingo! There we have it! And a compiled binary is one step beyond source code! You don't have visible source if you're using someone else's binary! And you just said it yourself: without visible source, the whole process loses all value.
read "Distillation Design", by Kister to get started
I'm familiar, actually; you're simply misinterpreting. See above.
If that's true, it just needs to fucking happen already. I see no evidence of this.
You must be borrowing someone else's computer and internet connection, because the subsidies that allow that to happen don't apply to anyone who earns enough to afford their own.
But since the reform act it has risen at a slower pace than it did before the reform.
Only if you ignore the initial more-than-doubling in price and elimination of no-deductible and no-copay plans when the ACA first came into effect.
In fact, I'm now paying more than double what I paid in 2013 for a no-deductible, no-copay plan and paying even more toward a deductible ($4500 on $4300 in premiums), on top of a 20% copay. I don't benefit from that in any way. My wife does, because she is now able to get coverage; so I'm now actually paying more than 4x (nearly 5x) as much for coverage, essentially just to cover her because I'll never meet my deductible in a given year so I'm paying more to cover myself for nothing.
In detail, I was paying $153/mo for a no-deductible no-copay plan covering just myself. I now pay $717/mo for a plan with a $4500/person deductible and a 20% copay. I went from paying $1836/yr for health care to paying $8604 in premiums and at least a $4500 deductible before the insurance even kicks in. To be fair, only half of that $8604 covers me, so I'll do the right thing and cut that number in half: I'm not paying $4302 in premiums, with effectively no coverage until my medical expenses exceed $4500 in a calendar year. That means I effectively don't have insurance until I've spent $8802; then, I still pay 20%.
Yes, that's such a benefit over the $1836 and done I was paying before.
Now yes my wife does see some benefit from it... potentially. Let's analyze: It takes her 6mo to meet her $4500 deductible, and 20% of that (what the remainder of the year will cost out-of-pocket) is $900. $4302 (her half of the premiums) + $4500 (deductible) + $900 (copay) = $9702. That's $702 more than simply paying out of pocket. So, where's the benefit? She got treatment even without coverage and the cost was the same (actually it was a bit lower because costs have gone up since then, but I'm looking at today's cost for this comparison and out-of-pocket still wins).
And that's compounded by the fact that the insurance company (the only one our providers of choice accept, mind you) insists that, since we're married, if we're both covered we must both be on the same plan. If not for that, I could be on a much cheaper plan as I haven't seen a doctor for a non-emergency condition in over half my life and I'm perfectly healthy aside from a back injury (one of those emergency conditions) currently being treated by a chiropractor, as recommended by the doctor who carried out the initial treatment, which is not covered by my insurance. The cost of initial treatment of my back injury (last year, so it means nothing for this year's deductible) would have been about half what I paid for insurance, deductible, and copay last year, were I on the cheaper plan. But the insurance company refuses to allow that; my wife is on the better (for her specific case) plan, so I must also be on that plan or find a different insurer for myself (which means finding new care providers).
Again... where's the benefit?
Absolutely correct. And completely irrelevant to my original question.
Your original question has already been answered. If you compile yourself, FOSS is more trustworthy. However, I was making a point before you came along; I set the topic and your question was not relevant to that topic.
To be used as pesticide?
Who said anything about pesticide?
you mean to say one company refuses to list ingredients
well, if we're talking about pesticide, they don't have to list ingredients, but who said pesticide?
refuses to let health inspectors evaluate their processes
health inspectors don't inspect pesticide... but, then... who said pesticide?
teaches you to make your own lime flavoured pesticide
If you trust someone to teach you how to make lime flavored anything from water, sugar, and lemons, then you're a bigger idiot than I had presumed. Also, who said anything about pesticide?
So attracts ants and other pests in addition to being maybe useless as a pesticide.
No, really, who mentioned pesticide?
only the process matters
So, then, it doesn't matter that someone could have poured out a bunch of bottles of that lemonade and replaced them with the otherwise identical poison, then put them back on the shelf? Because the process by which the legitimate lemonade is made is open and trusted, the compiled product is automatically trusted not to have been tampered with?
You still fail at logic. Perhaps it's because you're so caught up in process.
Though the neo-mammalian cortex will do its damnedest to justify (rationalize) the decision taken by the brain stem and neighbours.
You're illustrating that quite aptly.
To be fair, Congress gutted what was a good bill. Obama lacked the testicular fortitude to not sign what Congress handed back to him of his bill, so it's still his fault we're stuck with it; but the bill he handed Congress was good.
I dug no ditch, you simply fail at logic, and I take back nothing.
Answer the simple questions I have posed and you will see the logic.
Population: It's larger. SIGNIFICANTLY larger. Of course there will be more deaths because of that.
It's measured in deaths per 100k. If you have 100k people and 300 die, that's 300/100k. If you have 200k people and 600 die, that's 300/100k. If you have 200k people and 700 die, that's 350/100k. That's what went up, not just the total number of deaths.
It's really simple if you follow simple logic. Answer the two questions at the bottom of my previous post, they're designed to lead you right to that logic.
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.
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?
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.
Now consider that the second bottle may contain a poison that will kill you immediately upon ingestion. Do you still trust the bottle with ingredients printed on it?
Why? You didn't mix and bottle those ingredients yourself, you're only trusting whoever did not to have, instead, filled the bottle with poison.
Threat binaries the same way.
Why? Because no one has built anything of the level of typical modern software system from the ground up.
FYI: "build from source" refers to the binary in question, not the entire toolchain. There's a reason I mention the two concepts separately: because they're different.
in a typical open source software usage scenario - multiple entities down the distribution build the binaries
Right, so I have to trust multiple different entities not to have fucked with it
often with different toochains
Which will yield different and thus non-comparable binaries, leaving you no means to verify the code was unaltered by comparing multiple binaries
small modifications to code as per their (different) understanding...
and indistinguishable from a backdoored binary
Remember, these are multiple entities/people/groups/organizations who have no conflict of interest
You know that evidence you keep asking me for? While it's true that most may simply want to put out a good and useful binary, it only takes one bad actor and, as you said above, everyone's binaries are likely to be different for a multitude of reasons so you can't really catch it by comparing to your own compiled copy. At least we agree on that point.
don't have a single "management hierarchy"...
aside from the management structure of the project or distro, on behalf of whom they are compiling and providing the binary
not even live in the same legal jurisdiction
... making them harder to prosecute, should they turn a bad actor.
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?
It doesn't take the entire world cooperating to allow a bad binary into a repo, it takes the package maintainer of a single package in that repo deciding it would be nifty to slip a bit of malicious code into it, or having their credentials hijacked by someone who thinks so. In the case of the latter, it might (or might not) be reported in a timely manner and corrected before much damage is done, but in the case of the former, we've both already alluded to how difficult it would be to catch that, and why. Also, given that a package maintainer for a given distro has any number of people he can point the finger at to absolve himself of responsibility, while Microsoft has... well... Microsoft... in terms of raw accountability, I'd be more inclined to trust Microsoft.
Which has zero to do with my question - why is the TRUST LEVEL EQUAL between 2 completely different software development methodologies?
I answered that question, though it was orthogonal to the point being discussed. I'll repeat that answer yet again: If you're compiling your own binary from source you have reviewed, yes, that requires a lower level of trust than trusting a binary provided by someone else. I, however, am talking about the 99.95% of users who do not compile their own binaries and, therefore, must trust binaries provided by others. Those users, of which I'm nearly certain you are one, do not know what source the binaries they run were compiled from, because they did not compile those binaries themselves form known source. They have exactly as much insight into the actual source those binaries were compiled form as a user of closed source software has into the source those binaries were compiled from.
It doesn't matter how heavily reviewed, tested, vetted, and trusted the publicly available code of a project is if the person who supplied your binary skipped a bit of their own code in at compile time. The development methodology of the project has no effect on that. Period.
Now, as yo
Yes, but why is trust directly proportional to just "access to actual source your binaries are ... " ? Or, in general, an increasing function thereof?
Your other questions lead quite well to the answer.
Why doesn't a publicly discussed developmental model have a role in determining the level of trust?
If you're building from source yourself, it does.
Awareness of bug database, bug fix policy, open bugs (except the details of some security sensitive bugs) doesn't have a role?
That's relevant for the functional usability of the software, but not so much for trust in its security. Visibility into the source code itself is useful for that but, again, only if you're compiling it yourself (and with a trusted toolchain).
Code review reports from qualified, non-NDA-bound and non-conflict-of-interest people doesn't have a role?
No, not at all if you're part of the 99.95% of FOSS users who don't compile themselves and, therefore, have to trust someone else not to have slipped a backdoor into the code they compiled.
I don't see you produce any evidence of that.
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 some definitions of Open Source Software contain conditions about "easy" compilability of the source distributed. By the users.
And, yet, users who compile everything on their system from scratch are exceedingly in the minority, with most relying on binary packages available in their distro's repositories, such that they must trust the individuals who compiled those binaries not to have altered the publicly available source prior to compilation. Have I repeated myself enough times yet?
Why just as much as? Why is the trust level equal?
Because you have just as much guarantee that the package maintainer didn't slip malicious code into the project before compiling it. You see the code available in the project's repository but, by necessity, the package maintainer compiles from their own local copy of that code; nothing stops them from slipping in whatever other code they want before they compile. Again, I repeat myself.
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?
Trust in the code provided by Microsoft, and the binaries resulting when you compile it yourself? Yes. Trust in the binaries provided by Microsoft? Why would you trust them any more than you do today, given that you have no guarantee they were compiled from the exact same code made publicly available?
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 ?
Again, you must separate binaries compiled yourself from binaries compiled by others. If you compiled it yourself from well-audited code, trust it. If someone else compiled it, well, you don't know that they didn't modify the code before they compiled it. I keep repeating this, hoping that it'll eventually sink in: you DO NOT know what source a binary you did not compile yourself was compiled from. Even if the project's sou
Again: If you're not one of the few who compiles everything yourself, you have just as much access to the actual source your binaries are compiled from as someone using closed source software. Yes, you have access to the source the package maintainer claims to have compiled from, but you're trusting them, just as much as you're trusting Microsoft when you use Windows, to not have slipped a back door or some other baddies in before compile time.
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.
... I wrapped that top line in a quote tag and, yet, it did not get quoted... interesting...
You are correct, sir, but it certainly does help enable one to speak with authority on subjects they do not understand. ;)
... and grope.
Well there's the thing! Even with FOSS, most people do not compile their own binaries, and there's the trust issue again. And if your compiler is backdoored the same way as the package maintainer's compiler (which is perfectly possible if you both got your compilers from the same place), both will generate the same altered output. That is to say, the package maintainer may not even be the malicious party.
Check out Ken Thompson's Reflections on Trusting Trust. Yes, it's old, probably older than you if you haven't read it already, but it's still relevant, and will remain so for as long as we use computers.
Sure, you can review the source and fix security flaws that you find there; but, how can you know your compiler isn't replacing them or adding others? Read the paper.