The second needs refinement. If evil is a potential and not a thing, then evil must exist so long as God exists. There needn't be actual evil in the absence of actual evil actions.
True that the potential for evil does exist, provided there are free will agents that are not equal to God.
that a thing is not a proper object makes any attempt at referencing the thing impossible... as it not a thing... we might just as well say that the thing is not a thing.
Therefore, there is no rock having the given description and thus ceases to be a problem for God... or for anyone.
Show me a circle that is bigger than itself. Agreed that is nonsense? Any such nonsense stops there... it is pointless to draw any further conclusions... such as whether I can draw such a circle.
First, there is nothing in the definition of "you" that includes omnipotence.
Second, how do you get that "omnipotence" is internally inconsistent?
Third, something which is not at first possible does not imply a limitation.
That an all powerful God cannot create a man whose hair is both completely white and completely black simultaneously under a consistent interpretation implies no limitations on God's power, as it is not a valid proposition at all.
We may view any self-referential contradiction as invalid.
For example:
"All things are relative" is invalid (albeit heavily used and sounds good at face value)
How so?
The assertion "All things are relative" includes itself, under the "All things" part, such that the statement itself cannot be absolute, yielding "Not all things are relative", revealing the hidden self-referential contradiction, a logical fallacy.
Oddly, the contradiction in the big rock paradox is not so hidden. It is patently self-contradictory and thus useless as an argument against God's omnipotence.
nope I always get it from mozilla.com
I think others in this thread have indicated the same bundling. There was a news article about this too... I'll locate it.
Well, here's from a simpleton's point of view. When it comes to, say, http request/response processing, there is a stage that pretty much has to be single-threaded, and to generalize, control logic tends to be procedural/single-threaded/imperative, since the order of operations are necessarily so. I'm not sure how such an operation can be divided into parallel tasks.
However, I can see how the control thread might be a subscriber to multiple services that are not run in a serial fashion. In the case of a single database lookup, there's no point, right? But perhaps there is opportunity in the case of a services mashup.
A business has no intrinsic right to exist. If it wishes to exist, it may need to play the game, and it needn't play well or play fair. However, the motivation to get rich quick, whether it be through good or poor business practices can be just the faulty assumption that will drive a business into the dirt.
There are different styles of business, just as there are different styles of programming. Some feel that business is like a WWF fight, whereas other conduct business calmly and earnestly. The excitable, frenetic form that is indistinguishable from bi-polar syndromes is simply weaker and fundamentally less stable albeit perhaps more likely to win the lottery.
If a kid is on a sugar high and deems it necessary to feed his craving at the local corner store, he is probably not considering the most effective and efficient route to his continued satisfaction but rather the easiest and fastest road to his immediate gratification. This is the same type of behavior we find in drug addicts that will sacrifice everything for instant relief. If a business is to be handled in this fashion, the facilitators will have to accept this lack of vision. I suspect that it's up to us as developers to decide if we need to work for organizations with some self-respect and quality products or if we shall succomb to consorting with mud-wrestlers or drifting with pirates.
We simply cannot equate a business motiviation with the engineering process methodology, especially when a business is not a Business (with a capital B) but just an ordinary, everyday punk opportunity for some two-bit egoist mongrels.
A business might be entitled to make its own decisions, but like anything else, the act of sovereignty does not make a Business, in the same way as late night karaoke stint doesn't make a Hollywood actor. Business people and managers that don't bother to look past their own fake smiles are just the fools we work for. We are the of jesters of kings and pompadours but who is the greater buffoon, the one that struggles to keep a sinking ship afloat or the one that bought a boat with holes?
This quote just happened to appear at the base of this article:
"Your reasoning is excellent -- it's only your basic assumptions that are wrong."
Let us assume that business concerns dictate software development cycles to some degree. Certainly a developer can sympathize with the pressures of competitive business urgency. However, I think there's a tendency (especially in startups) for the quality of a business concept to be inversely related to the "need" for fast time to market.
An extremely poor idea, for instance, might appeal to extremely fast development so that its weak business model doesn't collapse under even basic competition, whereas a unique and fruitful concept may deserve quality software development attention.
Organizations that expect "poor" software development can themselves be indicative of a weak business plan. If the business concept foundation isn't solid, there is no reason to expect the business drivers to want anything but fast and cheap software results. The lack of appreciation toward software development is a reflection of a bad business. Bad input, bad output.
To argue that rapid and vapid software development is justifiable for business reasons is a logical misstep if we don't also ask what it is that justifies bad business? For businesses that possess a reasonable product concept with quality management that finds itself in need of hazardously rapid software production, this message is not for you.
Let's just make sure we don't allow the debate between rapid and pensive software development to be unduly influenced by immature businesses that believe that unsophisticated, bare-knuckled business practices should be reflected in an engineering discipline.
There is a reason why software developers are not allowed to fail but salespersons are. There is simply a different scale of rigor, knowledge, and discipline involved. Business principals won't like to hear it, but it's the sad truth, and it's the world we live in. I doubt that any of this will change, as it's really as much about human nature, fallibility, sometimes corruption. But for our own sanity, if we can't change it, at least there is some solace in the knowledge that we can work to find solutions to genuine problems but that we are often doomed by faulty or simply missing business premises.
Slashdot Mirror
I agree with the first statement.
The second needs refinement. If evil is a potential and not a thing, then evil must exist so long as God exists. There needn't be actual evil in the absence of actual evil actions.
True that the potential for evil does exist, provided there are free will agents that are not equal to God.
that a thing is not a proper object makes any attempt at referencing the thing impossible... as it not a thing... we might just as well say that the thing is not a thing.
Therefore, there is no rock having the given description and thus ceases to be a problem for God... or for anyone.
Show me a circle that is bigger than itself. Agreed that is nonsense? Any such nonsense stops there... it is pointless to draw any further conclusions... such as whether I can draw such a circle.
no. logic bears a relation to truth. it is necessary to affirm that God is Truth to see that logic is not outside of God but stems from God.
First, there is nothing in the definition of "you" that includes omnipotence. Second, how do you get that "omnipotence" is internally inconsistent? Third, something which is not at first possible does not imply a limitation. That an all powerful God cannot create a man whose hair is both completely white and completely black simultaneously under a consistent interpretation implies no limitations on God's power, as it is not a valid proposition at all. We may view any self-referential contradiction as invalid. For example: "All things are relative" is invalid (albeit heavily used and sounds good at face value) How so? The assertion "All things are relative" includes itself, under the "All things" part, such that the statement itself cannot be absolute, yielding "Not all things are relative", revealing the hidden self-referential contradiction, a logical fallacy. Oddly, the contradiction in the big rock paradox is not so hidden. It is patently self-contradictory and thus useless as an argument against God's omnipotence.
Yep, you are right. mozilla wasn't distributing the bundle... it was google that was distributing the firefox/googleToolbar bundle.
nope I always get it from mozilla.com I think others in this thread have indicated the same bundling. There was a news article about this too... I'll locate it.
ok, but i have upgraded firefox b4 and been prompted to install the google toolbar. I believe mozilla got money from google to do this.
Doesn't the firefox install offer google toolbar?
Well, here's from a simpleton's point of view. When it comes to, say, http request/response processing, there is a stage that pretty much has to be single-threaded, and to generalize, control logic tends to be procedural/single-threaded/imperative, since the order of operations are necessarily so. I'm not sure how such an operation can be divided into parallel tasks.
However, I can see how the control thread might be a subscriber to multiple services that are not run in a serial fashion. In the case of a single database lookup, there's no point, right? But perhaps there is opportunity in the case of a services mashup.
There are different styles of business, just as there are different styles of programming. Some feel that business is like a WWF fight, whereas other conduct business calmly and earnestly. The excitable, frenetic form that is indistinguishable from bi-polar syndromes is simply weaker and fundamentally less stable albeit perhaps more likely to win the lottery.
If a kid is on a sugar high and deems it necessary to feed his craving at the local corner store, he is probably not considering the most effective and efficient route to his continued satisfaction but rather the easiest and fastest road to his immediate gratification. This is the same type of behavior we find in drug addicts that will sacrifice everything for instant relief. If a business is to be handled in this fashion, the facilitators will have to accept this lack of vision. I suspect that it's up to us as developers to decide if we need to work for organizations with some self-respect and quality products or if we shall succomb to consorting with mud-wrestlers or drifting with pirates.
We simply cannot equate a business motiviation with the engineering process methodology, especially when a business is not a Business (with a capital B) but just an ordinary, everyday punk opportunity for some two-bit egoist mongrels.
A business might be entitled to make its own decisions, but like anything else, the act of sovereignty does not make a Business, in the same way as late night karaoke stint doesn't make a Hollywood actor. Business people and managers that don't bother to look past their own fake smiles are just the fools we work for. We are the of jesters of kings and pompadours but who is the greater buffoon, the one that struggles to keep a sinking ship afloat or the one that bought a boat with holes?
This quote just happened to appear at the base of this article: "Your reasoning is excellent -- it's only your basic assumptions that are wrong." Let us assume that business concerns dictate software development cycles to some degree. Certainly a developer can sympathize with the pressures of competitive business urgency. However, I think there's a tendency (especially in startups) for the quality of a business concept to be inversely related to the "need" for fast time to market. An extremely poor idea, for instance, might appeal to extremely fast development so that its weak business model doesn't collapse under even basic competition, whereas a unique and fruitful concept may deserve quality software development attention. Organizations that expect "poor" software development can themselves be indicative of a weak business plan. If the business concept foundation isn't solid, there is no reason to expect the business drivers to want anything but fast and cheap software results. The lack of appreciation toward software development is a reflection of a bad business. Bad input, bad output. To argue that rapid and vapid software development is justifiable for business reasons is a logical misstep if we don't also ask what it is that justifies bad business? For businesses that possess a reasonable product concept with quality management that finds itself in need of hazardously rapid software production, this message is not for you. Let's just make sure we don't allow the debate between rapid and pensive software development to be unduly influenced by immature businesses that believe that unsophisticated, bare-knuckled business practices should be reflected in an engineering discipline. There is a reason why software developers are not allowed to fail but salespersons are. There is simply a different scale of rigor, knowledge, and discipline involved. Business principals won't like to hear it, but it's the sad truth, and it's the world we live in. I doubt that any of this will change, as it's really as much about human nature, fallibility, sometimes corruption. But for our own sanity, if we can't change it, at least there is some solace in the knowledge that we can work to find solutions to genuine problems but that we are often doomed by faulty or simply missing business premises.