Consider this. The unweighted--completely unweighted--data from the last four presidential elections before this year are as follows:
1988: Dukakis, 50.3; Bush, 49.7
1992: Clinton, 46; Bush, 33.2
1996: Clinton, 52.2; Dole, 37.5
2000: Gore, 48.5; Bush, 46.2
President Dukakis? Obviously, the unweighted data have always been highly problematic and--interestingly--have always shown a strong Democratic bias. Now these unweighted data from past years do not, admittedly, correspond to where we were in the weighting process on election night this year when the +3 Kerry poll hit the 'net--those data had presumably already been weighted to some extent to correct for factors 1. and 2.--but it is still food for thought.
Exit polls have been wrong before, because as I stated and as those sites show, there are flaws to the methodology of exit polling. The reason that they eventualy become accurate as the day wears on is because of wieghting and adjusting for trends.
Furthermore, electronic machines are not new in 2004. They were used in 2000, and appeared in a siginificant section (about 7% of the voting populus) in 1996.
No, he's right. Exit polls are worthless because they only measure certian areas.
Look at a map of NY state by county for last election. If your exit pollers were in NYC or Albany, Kerry was winning. If your pollers were anywhere else in the state, the state would be going to bush.
It's true for all exit polls, they're only as useful as the data they cover. Since exit polls don't cover every voting location, they're only good for data at the locations they do cover.
And why the stuff on the sealed box and not the internal tape? Most voters wont even look at the card (they can't even be bothered to read voting directions in the first place).
Prove the ballots in the box are the real thing, and that they weren't all replaced.
Prove that the number of ballots in the box is the right number.
Prove the internal tape is wrong.
Prove the machine total is wrong
The very nature of secret ballots makes it impossible to guarantee accuracy. The best we can do is trust the voting process and continue to run audits.
No, they can't, hence the point of secret voting. There's a reason why the vote counters are specific people. And there's no guarantee that what goes in the ballot boxes is what comes out, nor a guarantee that the counters will count correctly, or represnt the results correctly. The very nature of secret ballots is that somewhere not everyone will get to see what happens, and at that moment, something can go wrong.
Any system creates a two party system. Either for or against X candidate. No matter how you do it, only one person gets into the presidential spot. Which means everyone who didn't vote for that person loses their vote.
Personaly, I'm beginning to think we should change the system so that the president is the one with the most votes, vice president is the runner up and sec state is the third place guy.
It doesn't have to work that way. A few states in the US split their electoral votes. There's no federal law saying that all the votes have to go to one candidate. Any law saying that is a state law.
People should learn to accept that using a computer requires some basic form of clue. If people are not willing to acquire such clue, they should watch TV instead so that they won't harm anybody with the viruses, spam and DDoS attacks perpetrated through their zombified computers.
Which is why all the food you cook is made entirely from raw materials, cooked over a fire and without instructions right?
You know you can say how it's all about the users but quite frankly each new round becomes less about them and more about Apple vs KHTML ideologies. See as far as the users are concerned, Safari = KHTML, Konq = KHTML so a change in safari should be easy to put into Konq. But they don't come fast and people get annoyed at Konq because they're not working fast enough for them (a common problem is software development).
However, if the KHTML team was truely fed up with their users, the statement should have been:
"We're working as fast as we can, but there are siginificant differences in the Safari code and our own code that make integrating these patches difficult."
And that would have been the end of it. it's the truth of the heart of the matter and there wouldn't be a problem. Instead, KHTML took the chance to air their dirty laundry, criticising Apple for not letting them look at prerelease code without an NDA, for not giving up full access to bug logs, for releasing huge chunks of code at a time instead of a trickle stream and for more or less outpacing KHTML and not offering to have their PAID developers work on backporting their code to what are now very very divergent code bases.
So while it may have been the users that started it all, make no mistake this is all about Apple Vs KHTML ideology.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
So two years isn't countless man hours? Because the KHTML team has spent more time, that makes their code somehow more worthy?
Look neither side is being co-operative. KHTML doesn't want to jump through Apple's hoops, Apple doesn't want to jump through KHTML's hoops. It's a fork that has more work than either side is willing to put into to ensure that the forks run concurrent, and there's nothing wrong with that.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
Obviously you're not reading it right. Apple offered to let them get at most of what they needed, but they were going to have to sign NDAs and go through some screening since it was all based on internal builds. I don't give me any bullshit about how they're just bug reports. Look at the bug fixes described in the webcore changelong and see how many of them reference things that didn't exist until Tiger. There's information to be had from bug logs.
Again, the offer is there, the KHTML team doesn't want to take advantage of it because of the work involved.
You can't expect khtml developers to ditch their own codebase in favour of webcore - that is a pretty cruel thing to ask from people who spent hundreds of manhours polishing, refining and improving their code, and became somewhat attached to it. And I believe Apple knows that as well.
And Apple's team spent countless man hours on their fork. Should we expect them to give it up because their changes aren't compatable or easily integrated into KHTML?
What did you have in mind when you wrote: "Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches."
Just what I said. Apple had patches, but the KHTML team didn't want them because they were done the "wrong way".
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
As a futher note, for all the bitching about how hard Apple makes it hard to know what changes they've made and what teh fixes were for, the change log seems to have a description of the problem, the files changed and the calls changed for each bug:
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
How can one claim that KDE developers have been just as uncooperative.
Because they have. Perhpas one should RTFA?
They even offered to sign NDAs with apple (and their offer was completely ignored) in order to get them.
And according to the article, when Apple gave them NDAs, they balked.
And this makes hardly any sense:"Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches." Excuse me? What were you trying to say?
I'd explain it to you, but it would require reading the article to get the context. Perhaps you should try that.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
Except in this part of the discussion we're clearly talking about the internal changes that would be covered under an NDA and not the shipped product whose relevant source code is available online. Please do try to keep up.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
Nope. Internal modifications that aren't distributed to the public do not fall into the same catagory as regular releases under the GPL:
Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA.
Re:Sound like KHTML team doesn't want to play eith
on
Safari vs. KHTML
·
· Score: 1
No we had to sign NDA's to look at code that _was_ part of KHTML, in fact directly based upon on our own code.
And the problem with this is.............?
If it wasn't released, they don't have to open the code.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 4, Insightful
Yes, because running it through the obfuscator is not how you work on code.
But the source files are just that.
If some 3 man team in the middle of nowhere started working on KHTML and just realeased the changed documents back to the public, would there be such a great outcry over the fact that they aren't providing the bug trackers?
Sound like KHTML team doesn't want to play either
on
Safari vs. KHTML
·
· Score: 3, Insightful
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE), and merging your changes into that," Apple engineer Maciej Stachowiak wrote in an e-mail dated May 5. "I think the Apple trees have seen a lot more change since the two trees diverged, although both have useful changes. We'd be open to making our tree multi-platform."
The suggestion, which KHTML developers said they were unlikely to accept,
So Apple is open to making the tree cross platform, and presumeably to them back porting web core (which is nessesary to implement some of the things Apple has done since) and KHTML doesn't want to.
So by choice KHTML has already limited the changes they can use.
"In open source, everything's supposed to be done the right way, but sometimes the less correct way is faster," Rusin said. "In fixing one problem, they were breaking a whole bunch of other things. Apple developers were focused on fixing bugs in such a way that we could not merge them back into KHTML. Those fixes were never an option for us."
Ignoring for a moment the fact that OSS is not done the "right way" many times, Apple has an obligation to turn out code and to do it fast. They have obligations to their customers. The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version.
Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches.
KDE volunteers said they suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code.
So you mean once KHTML devs wanted access to code that wasn't part of KHTML, they had to play by Apple's rules? Say it isn't so! Apple plays by their rules for their code, but KHTML doesn't want to play by Apple's rules for Apple code. Again, choices by KHTML to limit their own options.
"As long as they needed us, they used us, but when they gained enough knowledge they had no reason to keep sending us reviews and patches," Rusin said. "At a certain point they decided it was a waste of time for them, and at that point the communication just stopped...We had hopes that they would pour resources into KHTML. But that never happened."
No, it did happen, but they're pouring resources in to the ways that allow them to serve their customers best too, and that means leveraging OS X technologies. KHTML has chosen to be just as uncooperative as Apple.
Now, the question is, why would I want to buy FLAC? It's worthless to me. I listen to my music through a $30 set of headphones while i concentrate on programming. I run it through a pair of crappy desktop speakers, or pump it through the stock system in my car. FLAC to me is a worthless waste of space when I'll I'm going to be doing is reencoding it down to MP3 anyway.
you probably could do the same thing, but for the sake of most of their users, and the sake of keeping with the never have to use the command line thought process, they just tell you to resart.
As it stands, service is a command in OS X so I assume it would work.
Slashdot Mirror
What changed is that we looked at early exit polls rather than late exit polls. From a less biased (from your point of view) source than myself:
o nkeyrising/archives/000940.php
t he_exit_p.html
http://www.emergingdemocraticmajorityweblog.com/d
Specifically:
Consider this. The unweighted--completely unweighted--data from the last four presidential elections before this year are as follows:
1988: Dukakis, 50.3; Bush, 49.7
1992: Clinton, 46; Bush, 33.2
1996: Clinton, 52.2; Dole, 37.5
2000: Gore, 48.5; Bush, 46.2
President Dukakis? Obviously, the unweighted data have always been highly problematic and--interestingly--have always shown a strong Democratic bias. Now these unweighted data from past years do not, admittedly, correspond to where we were in the weighting process on election night this year when the +3 Kerry poll hit the 'net--those data had presumably already been weighted to some extent to correct for factors 1. and 2.--but it is still food for thought.
And to follow up:
http://www.mysterypollster.com/main/2004/12/have_
Exit polls have been wrong before, because as I stated and as those sites show, there are flaws to the methodology of exit polling. The reason that they eventualy become accurate as the day wears on is because of wieghting and adjusting for trends.
Furthermore, electronic machines are not new in 2004. They were used in 2000, and appeared in a siginificant section (about 7% of the voting populus) in 1996.
No, he's right. Exit polls are worthless because they only measure certian areas.
Look at a map of NY state by county for last election. If your exit pollers were in NYC or Albany, Kerry was winning. If your pollers were anywhere else in the state, the state would be going to bush.
It's true for all exit polls, they're only as useful as the data they cover. Since exit polls don't cover every voting location, they're only good for data at the locations they do cover.
Odd that when this argument is used to justify police searches, we have people screaming rights violations.
You have to prove the original ballots are the originals though. Once the seal is broken, the ballots are contaminated and can't be trusted again.
No system is perfect, what we need is not a perfect system, but a thorough series of audits.
And why the stuff on the sealed box and not the internal tape? Most voters wont even look at the card (they can't even be bothered to read voting directions in the first place).
Prove the ballots in the box are the real thing, and that they weren't all replaced.
Prove that the number of ballots in the box is the right number.
Prove the internal tape is wrong.
Prove the machine total is wrong
The very nature of secret ballots makes it impossible to guarantee accuracy. The best we can do is trust the voting process and continue to run audits.
No, they can't, hence the point of secret voting. There's a reason why the vote counters are specific people. And there's no guarantee that what goes in the ballot boxes is what comes out, nor a guarantee that the counters will count correctly, or represnt the results correctly. The very nature of secret ballots is that somewhere not everyone will get to see what happens, and at that moment, something can go wrong.
Any system creates a two party system. Either for or against X candidate. No matter how you do it, only one person gets into the presidential spot. Which means everyone who didn't vote for that person loses their vote.
Personaly, I'm beginning to think we should change the system so that the president is the one with the most votes, vice president is the runner up and sec state is the third place guy.
It doesn't have to work that way. A few states in the US split their electoral votes. There's no federal law saying that all the votes have to go to one candidate. Any law saying that is a state law.
People should learn to accept that using a computer requires some basic form of clue. If people are not willing to acquire such clue, they should watch TV instead so that they won't harm anybody with the viruses, spam and DDoS attacks perpetrated through their zombified computers.
Which is why all the food you cook is made entirely from raw materials, cooked over a fire and without instructions right?
You know you can say how it's all about the users but quite frankly each new round becomes less about them and more about Apple vs KHTML ideologies. See as far as the users are concerned, Safari = KHTML, Konq = KHTML so a change in safari should be easy to put into Konq. But they don't come fast and people get annoyed at Konq because they're not working fast enough for them (a common problem is software development).
However, if the KHTML team was truely fed up with their users, the statement should have been:
"We're working as fast as we can, but there are siginificant differences in the Safari code and our own code that make integrating these patches difficult."
And that would have been the end of it. it's the truth of the heart of the matter and there wouldn't be a problem. Instead, KHTML took the chance to air their dirty laundry, criticising Apple for not letting them look at prerelease code without an NDA, for not giving up full access to bug logs, for releasing huge chunks of code at a time instead of a trickle stream and for more or less outpacing KHTML and not offering to have their PAID developers work on backporting their code to what are now very very divergent code bases.
So while it may have been the users that started it all, make no mistake this is all about Apple Vs KHTML ideology.
So two years isn't countless man hours? Because the KHTML team has spent more time, that makes their code somehow more worthy?
Look neither side is being co-operative. KHTML doesn't want to jump through Apple's hoops, Apple doesn't want to jump through KHTML's hoops. It's a fork that has more work than either side is willing to put into to ensure that the forks run concurrent, and there's nothing wrong with that.
Obviously you're not reading it right. Apple offered to let them get at most of what they needed, but they were going to have to sign NDAs and go through some screening since it was all based on internal builds. I don't give me any bullshit about how they're just bug reports. Look at the bug fixes described in the webcore changelong and see how many of them reference things that didn't exist until Tiger. There's information to be had from bug logs.
Again, the offer is there, the KHTML team doesn't want to take advantage of it because of the work involved.
You can't expect khtml developers to ditch their own codebase in favour of webcore - that is a pretty cruel thing to ask from people who spent hundreds of manhours polishing, refining and improving their code, and became somewhat attached to it. And I believe Apple knows that as well.
And Apple's team spent countless man hours on their fork. Should we expect them to give it up because their changes aren't compatable or easily integrated into KHTML?
What did you have in mind when you wrote: "Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches."
Just what I said. Apple had patches, but the KHTML team didn't want them because they were done the "wrong way".
As a futher note, for all the bitching about how hard Apple makes it hard to know what changes they've made and what teh fixes were for, the change log seems to have a description of the problem, the files changed and the calls changed for each bug:
/ WebCore-413/ChangeLog
http://www.opensource.apple.com/darwinsource/10.4
How can one claim that KDE developers have been just as uncooperative.
Because they have. Perhpas one should RTFA?
They even offered to sign NDAs with apple (and their offer was completely ignored) in order to get them.
And according to the article, when Apple gave them NDAs, they balked.
And this makes hardly any sense:"Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches." Excuse me? What were you trying to say?
I'd explain it to you, but it would require reading the article to get the context. Perhaps you should try that.
Except in this part of the discussion we're clearly talking about the internal changes that would be covered under an NDA and not the shipped product whose relevant source code is available online. Please do try to keep up.
GPL Does not require redistribution of private code
The GPL and NDAs Please note the following
GPL and fair use
No we had to sign NDA's to look at code that _was_ part of KHTML, in fact directly based upon on our own code.
And the problem with this is.............?
If it wasn't released, they don't have to open the code.
Yes, because running it through the obfuscator is not how you work on code.
But the source files are just that.
If some 3 man team in the middle of nowhere started working on KHTML and just realeased the changed documents back to the public, would there be such a great outcry over the fact that they aren't providing the bug trackers?
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE), and merging your changes into that," Apple engineer Maciej Stachowiak wrote in an e-mail dated May 5. "I think the Apple trees have seen a lot more change since the two trees diverged, although both have useful changes. We'd be open to making our tree multi-platform."
The suggestion, which KHTML developers said they were unlikely to accept,
So Apple is open to making the tree cross platform, and presumeably to them back porting web core (which is nessesary to implement some of the things Apple has done since) and KHTML doesn't want to.
So by choice KHTML has already limited the changes they can use.
"In open source, everything's supposed to be done the right way, but sometimes the less correct way is faster," Rusin said. "In fixing one problem, they were breaking a whole bunch of other things. Apple developers were focused on fixing bugs in such a way that we could not merge them back into KHTML. Those fixes were never an option for us."
Ignoring for a moment the fact that OSS is not done the "right way" many times, Apple has an obligation to turn out code and to do it fast. They have obligations to their customers. The fact that KHTML wants to take their sweet time and Apple wants to get the patches done fast and out the door shows where the divergence is. Apple can't afford to take the open source approach of spending 5 years in beta before releasing the next version.
Once again a choice by KHTML. The patches are there, but they choose to do the patches their way, thus eliminating Apple patches.
KDE volunteers said they suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code.
So you mean once KHTML devs wanted access to code that wasn't part of KHTML, they had to play by Apple's rules? Say it isn't so! Apple plays by their rules for their code, but KHTML doesn't want to play by Apple's rules for Apple code. Again, choices by KHTML to limit their own options.
"As long as they needed us, they used us, but when they gained enough knowledge they had no reason to keep sending us reviews and patches," Rusin said. "At a certain point they decided it was a waste of time for them, and at that point the communication just stopped...We had hopes that they would pour resources into KHTML. But that never happened."
No, it did happen, but they're pouring resources in to the ways that allow them to serve their customers best too, and that means leveraging OS X technologies. KHTML has chosen to be just as uncooperative as Apple.
And this:
And when you've bought it, head over to http://www.misticriver.net/ to figure out how to use it.
is why this:
iRiver = iPod Killer.
Will never be true
Now, the question is, why would I want to buy FLAC? It's worthless to me. I listen to my music through a $30 set of headphones while i concentrate on programming. I run it through a pair of crappy desktop speakers, or pump it through the stock system in my car. FLAC to me is a worthless waste of space when I'll I'm going to be doing is reencoding it down to MP3 anyway.
You can buy and upgrade to Tiger without buying panther.
They are documented for tech users, you just might actually have to, GASP, read the documentation.
you probably could do the same thing, but for the sake of most of their users, and the sake of keeping with the never have to use the command line thought process, they just tell you to resart.
As it stands, service is a command in OS X so I assume it would work.
How is that anymore helpful though?
Network error what?
No connection?
No network inferface?
Bad authentication
Bad protocol?
Bad Packet?