er... needed to add more...
Open Source as you speak of it assumes that people *want* to have bug-free and usable code that produces correct results. That is why bug fixes are checked back into the tree.
*This* type of cheating would love the source so they could modify the source at home even easier with less effort/time (with no intention ever of checking the changes into the source tree) to produce bogus results faster.
Re:Wasn't cheating to be "impossible" ?
on
Cheating at Seti@home
·
· Score: 2, Insightful
In a very ideolistic view, yes. Opening the source also makes it *very* easy for me to take the source, then do whatever I want to the code to produce whatever results I want using as much/little CPU as I want and return whatever results I want. Basically, I can change the program to be like this:
int main() {
read_data_from_server();
compute_bogus_validator();
send_bogus_results_to_server(); }
and since I have the *source*, it is very easy to read and interpret (don't need to know ASM or anything or deal with decyphering of disassembled code).
Yes, you can fix bugs and submit the changes to fix the source tree but you make it *much* easier for cheaters to cheat if they want (and quite possibly enable more people to cheat).
heh... so you make your conclusion fit to the facts then =)
First,.NET was bigger so it was better obviously because they inlined and knew what they were doing. Now,.NET is smaller so the same thing =) I love/. readers and their religions =)
I think a better rebuttal would have been for DreamBean to have (re-)written the code for the J2EE benchmark like they describe and rerun the tests. They only have to publish the J2EE benchmark numbers, thus avoiding any issues with Microsoft. Instead, the easy way out is to publish a paper describing what they would have done and promise us that it would have been better. They tell us not to take the word of a group who publish numbers then expect us to take their word with nothing more than their promises of better performance.
I like/. a lot but I also make sure I temper everything here knowing the enormous Linux/OSS slant/religion (even to the point of making other flavors of Unix-a-likes 2nd class citizens), I'm OK =)
Posting *anything* on this board that 'beats' Linux/Unix in any way and it will get flamed for being FUD, false, biased, or (insert your favorite invalidating comment here).
The only tests that are praised for being fair and accurate are the ones that say Linux/Unix is better/faster/stronger/cheaper/etc.
"Change friendly" depends a lot on how the app was written... I can write something in any language that is change unfriendly. I can also write something in many languages that is change friendly.
Then do it, troll. Put your money where your mouth is.
I can write that app in 2000 lines of code.
mmm.. I can write it in 1500 lines of code.
Bob, write that code!
a) Intel learned that the value of computers is in the software they run. Backwards compatibility is very important
b) I20
c) the key components behind the "PC" is cost. It is a cheap, simple design. There have been several alternatives in the past, none of which caught on -- MicroChannel, EISA, I20, etc. In each case, they were more expensive (sure, there is a cost of scale associated with them that they needed to overcome, but it is a tough one to beat) and people just didn't buy them because they were more expensive than the "regular PC".
Show-of-hands is worthless anyway -- and especially so in such an audience that was there. There is no way, or it would be very difficult, to prove that every student that had his/her hand raised to the question of whether filesharing makes them buy more music. In fact, I would be willing to suppose that many of those there would support whatever points would further his/her side of the debate's cause. I personally know 100s of people who download music, most of them do so because they wouldn't buy CDs anyway, many of the others download the music and burn their own CDs instead of buying one in stores. I personally think the vast majority of those who download music do not buy the CD in stores. They may buy a few CDs, but they do not buy CDs that contain all (or even many) of the songs they listen to.
In any case, downloading music isn't just in the USA. It is just as popular in other countries (if not more so) to download mp3s and not buy CDs.
I agree completely. Today, games rely more on generating images than any real gameplay. 'Back in the day' games had to have gameplay to 'survive'. It's why you see games like M.U.L.E. still in the top 100 lists of all time. Today, just put some fancy graphics in a first person shooter and that's it.
People will accept/play anything these days as long as it is 'pretty' (also known as eye-candy).
Database file systems weren't dreamed up by Microsoft, afaik. I think there are several platforms that have been hinted at having dbfs in the future plans.
Sure... let's give out our atomic explosion simulation softare so that countries who don't currently have nuclear weapons can develop them faster, cheaper, and more efficiently.
There are actually two checks. I have my updates set on Manual. That means I have to explicitly initiate the check for any patches. After it checks, it then provides me with a list of patches that are available (if any) and then I select each patch that I wish to apply (or deselect them in the case of a 'critical' update which is selected by default). After generating my list of patches to apply, I click on the link to apply the patches. At this time, a EULA type box appears where I must click 'yes, I agree' or 'no, I don't agree' to the terms of the agreement. Assuming I press the 'yes, I agree' option, the patch(s) are then downloaded and installed on my computer.
So...
- I have to manually initiate the patch check
- I select each patch, from the available patches, that I wish to install
- I initiate the install
- I then have a license agreement check
- Then the patches are installed
It's more than that. Networks of workstations are good at solving problems that are very coarse grained. For fine grained apps, they are poor because of the latencies of the communication medium (100Mb Ethernet has very high latency) and also by the relatively low bandwidth (100Mb Ethernet is about 10MB/s depending on manufacturer or cards, your network, etc). Latency critical apps usually have many small transfers from node to node (and are also finely grained usually) and a Beowulf cluster is not good at those types of things, in general.
For fine-grained apps, you usually have to go to a 'big iron' type machine -- ones with specialized interconnects or shared memory or hybrids.
Yeah... I get a kick out of all the people who think P2P is a magic AND silver bullet. It works great for some things but people tend to ignore things like bandwidth requirements and such.
Slashdot Mirror
so... I left out
int main(int argc, char *argv[])
I wasn't trying to provide something for you to feed into a compiler.
er... needed to add more... Open Source as you speak of it assumes that people *want* to have bug-free and usable code that produces correct results. That is why bug fixes are checked back into the tree. *This* type of cheating would love the source so they could modify the source at home even easier with less effort/time (with no intention ever of checking the changes into the source tree) to produce bogus results faster.
In a very ideolistic view, yes. Opening the source also makes it *very* easy for me to take the source, then do whatever I want to the code to produce whatever results I want using as much/little CPU as I want and return whatever results I want. Basically, I can change the program to be like this:
int main()
{
read_data_from_server();
compute_bogus_validator();
send_bogus_results_to_server();
}
and since I have the *source*, it is very easy to read and interpret (don't need to know ASM or anything or deal with decyphering of disassembled code).
Yes, you can fix bugs and submit the changes to fix the source tree but you make it *much* easier for cheaters to cheat if they want (and quite possibly enable more people to cheat).
heh... so you make your conclusion fit to the facts then =)
.NET was bigger so it was better obviously because they inlined and knew what they were doing. Now, .NET is smaller so the same thing =) I love /. readers and their religions =)
First,
Religion at its finest! =)
I think a better rebuttal would have been for DreamBean to have (re-)written the code for the J2EE benchmark like they describe and rerun the tests. They only have to publish the J2EE benchmark numbers, thus avoiding any issues with Microsoft. Instead, the easy way out is to publish a paper describing what they would have done and promise us that it would have been better. They tell us not to take the word of a group who publish numbers then expect us to take their word with nothing more than their promises of better performance.
I like /. a lot but I also make sure I temper everything here knowing the enormous Linux/OSS slant/religion (even to the point of making other flavors of Unix-a-likes 2nd class citizens), I'm OK =)
No way... not from this crowd...
Rule #1: Linux ownz0rs all!
Rule #2: See Rule#1
Posting *anything* on this board that 'beats' Linux/Unix in any way and it will get flamed for being FUD, false, biased, or (insert your favorite invalidating comment here).
The only tests that are praised for being fair and accurate are the ones that say Linux/Unix is better/faster/stronger/cheaper/etc.
"Change friendly" depends a lot on how the app was written... I can write something in any language that is change unfriendly. I can also write something in many languages that is change friendly.
Then do it, troll. Put your money where your mouth is. I can write that app in 2000 lines of code. mmm.. I can write it in 1500 lines of code. Bob, write that code!
but... will it be the best of both worlds or the worst of both worlds??? =)
http://www.grudge-match.com/History/index.html
a) Intel learned that the value of computers is in the software they run. Backwards compatibility is very important
b) I20
c) the key components behind the "PC" is cost. It is a cheap, simple design. There have been several alternatives in the past, none of which caught on -- MicroChannel, EISA, I20, etc. In each case, they were more expensive (sure, there is a cost of scale associated with them that they needed to overcome, but it is a tough one to beat) and people just didn't buy them because they were more expensive than the "regular PC".
Except the 6502 was developed by MOS Technologies and originally made by Rockwell, not Motorola. http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?6502
I noticed that there were a number of subheadings where there were only one contributor. Also... from the first link there:
The move eventually galvanized an entire industry, as computer and Internet companies quickly moved to emulate Microsoft's political savvy.
If this is so... then why is Microsoft the only one listed under Computers/Internet in the chart in the second link?
Show-of-hands is worthless anyway -- and especially so in such an audience that was there. There is no way, or it would be very difficult, to prove that every student that had his/her hand raised to the question of whether filesharing makes them buy more music. In fact, I would be willing to suppose that many of those there would support whatever points would further his/her side of the debate's cause. I personally know 100s of people who download music, most of them do so because they wouldn't buy CDs anyway, many of the others download the music and burn their own CDs instead of buying one in stores. I personally think the vast majority of those who download music do not buy the CD in stores. They may buy a few CDs, but they do not buy CDs that contain all (or even many) of the songs they listen to.
In any case, downloading music isn't just in the USA. It is just as popular in other countries (if not more so) to download mp3s and not buy CDs.
I agree completely. Today, games rely more on generating images than any real gameplay. 'Back in the day' games had to have gameplay to 'survive'. It's why you see games like M.U.L.E. still in the top 100 lists of all time. Today, just put some fancy graphics in a first person shooter and that's it.
People will accept/play anything these days as long as it is 'pretty' (also known as eye-candy).
Database file systems weren't dreamed up by Microsoft, afaik. I think there are several platforms that have been hinted at having dbfs in the future plans.
You simply have caused someone to 'reinvent the wheel' and implement their own version of the code because they can't use yours.
Sure... let's give out our atomic explosion simulation softare so that countries who don't currently have nuclear weapons can develop them faster, cheaper, and more efficiently.
Dunno... maybe we would have all been running some derivative of HyperText.... oh wait...
There are actually two checks. I have my updates set on Manual. That means I have to explicitly initiate the check for any patches. After it checks, it then provides me with a list of patches that are available (if any) and then I select each patch that I wish to apply (or deselect them in the case of a 'critical' update which is selected by default). After generating my list of patches to apply, I click on the link to apply the patches. At this time, a EULA type box appears where I must click 'yes, I agree' or 'no, I don't agree' to the terms of the agreement. Assuming I press the 'yes, I agree' option, the patch(s) are then downloaded and installed on my computer.
So...
- I have to manually initiate the patch check
- I select each patch, from the available patches, that I wish to install
- I initiate the install
- I then have a license agreement check
- Then the patches are installed
Technically... an operating system is just another app :)
It's more than that. Networks of workstations are good at solving problems that are very coarse grained. For fine grained apps, they are poor because of the latencies of the communication medium (100Mb Ethernet has very high latency) and also by the relatively low bandwidth (100Mb Ethernet is about 10MB/s depending on manufacturer or cards, your network, etc). Latency critical apps usually have many small transfers from node to node (and are also finely grained usually) and a Beowulf cluster is not good at those types of things, in general.
For fine-grained apps, you usually have to go to a 'big iron' type machine -- ones with specialized interconnects or shared memory or hybrids.
Yeah... I get a kick out of all the people who think P2P is a magic AND silver bullet. It works great for some things but people tend to ignore things like bandwidth requirements and such.