The basic FFT algorithm is easily checkable. All SETI@Home has to do with a new version to test it is run a few blocks through. If the routine is truly just an optimized version that returns the same results, then they should be able to easily verify this.
And I don't know where you get the idea that everyone will run their own client. That's like assuming everyone runs a cracked client now.
Security by obscurity isn't. If they want believable results at the end of this, they have to let people audit their methods. If the code is a black box, and nobody knows what it does, nobody can trust it to return the right answer.
So you look at the source and submit changes to the SETI@Home people. They take the best patches and optimizations. Test them like crazy, and release the next official client.
Sure, some people could run unauthorized clients, with unchecked code, but people have already started cracking the client, sending back fake blocks.
The worst case scenario is the same. The average case is much better with open source.
(More speed allows more redundancy to catch idiots who mess with the results.)
Process the data packets, hash the results, with MD5 or SHA, then return the hash along with whatever other results are needed.
SETI@Home picks some random number of packets and sends them out to a second user, checking to see if both users return the same hash value.
And this doesn't just stop malicious forgery, but it also stops bugs which may cause incorrect packets to be returned some of the time.
This does require keeping a list of the packets a user processes, but this shouln't be that hard. Especially because they start fresh every week (month?) with the new data.
Where this gets really hard is with Bovine, and the code breaking.
The message is known to the users, so the cracker (bad guy) knows what result to watch for. And he knows what result to return (yes, or no). Easy to forge.
Bovine is also more likely to get a user hiding hits, instead of faking misses. For misses, they simply use a hash of the first bytes of the 'plaintext' after each decryption and compare these. For a hit, they need to hope that the packet with the hit is one sent out for inependent verification.
What they need is a cryptographic way of hiding the true results from the user.
As in, in you have C, a cyphertext, and P, a plaintext, and want to find K, the key that turns C into P, is there some transformation you can make to C and P that allows the same key to function, but masks the cypher and plaintext?
This isn't as impossible as it sounds... Imagine a rotation cypher with a numeric key.
Let's imagine the key is 3.
Plaintext 'CAT' becomes 'FDW'
Add the transformation -1 to both
'CAT' becomes 'BZS', 'FDW' becomes 'ECV'
Now, imagine the Bovine group wanting to test their users. They think people will hide a success, making the project continue.
If the user knows that the random-looking cypher text decrypts into 'CAT' they simply watch for 'CAT' to be decrypted and they've found the key.
So, Bovine sends T(C1) and T(P), the transformed (T layer) cyphertext (C1) and plaintext (P1). The user knows that T(P1) is the desired result, 'FDW' in this case. But they don't know if that plaintext is the contest winner, or a loyalty check. So they decrypt T(C1) and low and behold, it matches T(P1) ('BZS' becomes 'ECV') and the software says 'We did it!'.
If they report this set of keys as a failure, Bovine *could* have planted this key, and shut them down when it isn't reported. Or, it could be the real key. They'd never know.
So they're compelled to be correct, because if their answers don't match the ones Bovine expects, Bovine doesn't trust their other answers and their stats are thrown out.
So, we need to find the transformation (T) that allows T(C)+K to equal T(P) for all cyphertexts and all plaintexts.
There may not be such a transformation that does this, but if there is, this is the ultimate answer for Bovine, and other projects like this.
They should be checking a random sampling of returned blocks to make sure the processing is correct.
This could catch both malicious forgery and accidents, like perhaps there's a bug in the code so that a k6-2 of 450Mhz returns false answers... How would they know?
And the idea of an open client means, at least to me, that we'd submit changes to SETI@Home, and they'd release the next approved client.
That's not a way to handle it. If everyone who has a problem with the specific implementation goes away you end up with SETI@Home being critically underpowered. And I like what SETI@Home is trying to do. I just wish they didn't make it an either-or choice of helping them or helping other projects. A well written client would allow people to participate in more computing projects with the same number of spare cycles.
I don't think you really understand how to optimize code.
You optimize the sections of the code that take the most processor time, and the programs you use the most. If lilo completes in milliseconds, don't optimize it. If your whole office app is a pig, optimize the parts that the user spends the most time in. If your shell is fairly quick, yet you spend eight hours a day working in it, it might be worth optimizing those input routines even if it's only a 10% overall speed gain.
With SETI@Home, sure, they run out of data before they run out of time. But, they don't have to perfectly match. By your logic we should slow down the client so as not to waste any cycles on unimportant non-SETI@Home processing.
I'd prefer to optimize SETI@Home and either require less users, or process the week's signals faster and be able to run other distributed projects.
Because SETI@Home *is* a valid target for optimization. It sucks an incredible number of cycles. And now that we're used to running distributed projects, those aren't useless cycles anymore. You can see SETI@Home as competing directly with other projects for computer time.
It's much the same as a slow subroutine making the whole application slow. But in this case the subroutine is SETI@Home and it's making the application of providing computing resources to as many distributed projects as possible run poorly.
Because it's a pain in the ass having to look at the television the whole time. If the show is dubber you can make out the words even if the picture underneath is complicated, or if you want to go look in the fridge, where you can hear the TV, but not see it...
If I wasn't english speaking (or had a favorite movie which was foreign) I would watch it at least once subtitled instead of dubbed, to see if I missed anything, but usually, I'd use the dubbed version.
When I watch Anime with my friends (who are bug-fuck, and I mean like Magic the Gathering level bug-fuck, for it) I prefer the dubbed version because it's easier to watch.
And, "so much of the feeling the director intended to convey"??? Evidently you have mistaken TV and movies for art.
It's funny to watch my friends rant about cartoon (Anime) and how it's "just not the same" when dubbed. Like any of them speak Japanese...
SETI@Home is partially worried about people submitting unchecked data packets to boost their score, or not submitting a signal if found, simply to mess with the project.
But, they're also concerned with the project working too well. If their weekly allotment of data was processed in a day, users would either sit idle for the rest of the week, or recheck data. Either is likely to make people look for another project.
We need to have a general distributed processing client with modular cores. That way people can check for alien signals when the new SETI@Home client comes out, then evaluate various check opening moves, or try code keys, or any other project that needs users.
The basic shell of a distributed client is fairly simple, and in most cases is very similar. The system sends you data, tells you what to do with the data, and accepts processed data for return.
The same client could send out SETI@Home packets and DES keyspaces depending on which project had a more immediate need for help, and what the client computer was capable of.
Cracking code keys is a lightweight process. It takes very little RAM, and can be suspended instantly. Running FFTs on radio signals (SETI@Home) is a heavyweight process. It requires a lot of RAM, and isn't generally appropriate to run in the background while using the computer.
A multi-core client could deal with this beautifully. When you're using the computer, a lightweight process is selected based on your preferences and need, and runs in spare cycles, not being noticed. When the screensaver kicks in indicating an idle computer, the lightweight process is swapped out for a heavyweight process like SETI@Home or chess analysis, to be run when a performance deficit on the client won't be noticed.
The user could download processing cores for the projects they'd like to participate in, and list the jobs in order of preference. For instance, SETI@Home then chess analysis for the screen-saved modules, and Bovine code cracking for the spare-cycle modules.
Then the system would crack codes between keypresses, and switch to SETI@Home when there are data blocks available, but switch seamlessly to the less time-critical chess analysis when the SETI@Home blocks run out.
The system has the benefit that not every author of a distributed project would have to write a whole system, plus servers, and bug test it. You'd simply write a processing module and a server module to properly serve that data, and compile the client module for as many systems as possible, or distribute it as compilable code. Thus allowing SETI@Home to run on an SGI machine for instance, without the authors having to write a communication system that would run on that computer.
Mathematical tasks, like cracking keys, or recursively iterating chess moves, or FFT calculations are fairly easy to implement in a small program, and are fairly portable, usually not relying on the OS for much.
Currently, there are many ideas for distributed projects which never get explored because they don't have anybody capable of coding a client as stable/easy as the bovine, or of finding a large enough audience to make it worthwhile. Having one shell with multiple cores would allow anyone who can express their problem in code to reach a large audience of people ready to work on their distributed project.
So, if they released their source, bugs would magically appear?
Open source doesn't cause bugs. Fast development cycles cause bugs. End of story.
If they open sourced the project they'd speed it up enough (proof: AMD and other organizations have offered both general speedups and processor-specific speedups of over 100%) to add redundancy, both to check the method by processing some packets with an alternate algorithm, and to guard against false packet returns.
They aren't obligated to open-source the project, but I for one quit running SETI@Home when I heard about them refusing optimization help because they didn't want to process the packets too quickly. I don't care what their reasons are, I simply refuse to run something that's woefully unoptimized, especially when they were presented with alternatives. Now I'm running other distributed projects with my spare cycles. And I suspect I'm not the only convert.
But, it *is* about finding the signal. It may not be about *you* finding the signal, but the *whole point* is to track down a signal.
To track down the signal, units must be processed. If we process signals faster it'll either let them eventually process more signals (larger spectrum, etc) or use less computers. Either is a worthy goal. One helps science, the other simply saves power and lets people run other distributed projects.
SETI@Home is hindering their own project by insisting on slow (They refused AMD's offer of help to speed the client up, doing more work, as carefully as before, in less time.) clients just to keep a large number of users helping is a bad PR move. You could help a project that wants to process data, or you could help SETI who wants a large number of users, who incidentally process some data.
Good point. Heck, I don't think you'd even get a free OS, because to be good, a OS has to be current...
Well, a school is primarily a name thing. I went to [name], and [name] was my professor for my main course. Thus it helps to have known professionals for the big courses.
And it also helps to have a consistent course, where all the material is written and presented by one person, so they really understand it and how to teach it.
Some course work, the lower courses especially, and a lot of the TA work, helping students, could be done by less well-known people.
In fact, it could be like the usenet oracle. As part of your tuition, you spend some number of hours tutoring people in lower classes.
But, I don't think open-source is a good model for the upper class teaching. Consistency of presentation is important. It probably wouldn't cost much though, because most of what a prof charges for is the constant demand on their time. If they could record one set of course work, even with a bunch of suplemental work, they could do it in less time than teaching two courses.
I for one, would rather learn at a school with Knuth and Sedgewick, etc, teaching comp-sci than a bunch of random 'professionals' who all donate a badly recorded two-hour MP3 of what they feel is important. I'm not into paying $10k a year, but $500 is pocket change for getting a well known prof.
I don't think you'd ever get free schools, because to be good, a course has to be current, and for that you need new material which means paying someone good to write it.
And there are problems trying to teach a full university curriculum without physical space. Many science courses require labs, etc.
But, a good comp-sci technical school could be done. And if not free, it could be done quite cheap.
You'd need to have content written and presented by the professors. And you'd need to have them available a certain ammount of time online to answer student questions and explain the lesson.
You'd also need to charge a bit just to run the day to day business end of the school. Secretaries, librarians (even if the resources are electronic, they need to be properly cataloged.)
If you were going to give certificates you wanted to mean anything, you'd have to have fairly cheat-proof testing. Ditto if you want people to be able to challenge a course. This probably means hiring a bunch of local firms to test the students in their area.
So, free is unlikely, especially if you want to have your degree mean anything, not just teach people. But cheap. Cheap is doable.
I'd go to a school like this. I don't have time for 'school' but I could always learn something new, and having a piece of paper saying I know the things I've learned on the job would be handy. Especially if I could challenge the course if I knew it that well.
Fine. Rid the net of spam theives. Do so when people are no longer in pain. When our youth is receiving the education it deserves. When women can feel safe walking down any street in america, day or night. When no one dies of cancer, aids, or even worse, things we already have a vaccine for. When politicians are no longer currupt, and governments no longer opress their people.
But, don't try to stop random murders until you've stopped the abusive childhoods that make the people that way. And don't try to stop abuse until you rid everyone of the taste for alcohol. And don't do that until you've cured the basic insecurities that cause people to have an addictive personality.
Or, sit and home, sucking your thumb, withdrawing from the world because you can't tackle anything less than the absolute biggest problems and you don't have a hope of winning against those without solving smaller problems first. You go get that windmill. It'll do society and you a lot of good to waste any good intentions of energy you might have by fighting the unwinnable fights.
Hmmmm. Maybe we could do things that we have a chance of suceeding at. And when done that, with the experience we've gained, we can work on bigger injustices... That way, not only would things get done, but eventually the big stuff would get done too.
Fight the spammers. They're stealing from you by using bandwidth you pay for to send you advertising. They can be fought. It's not that hard. And it's a battle worth winning.
If the government wants us to respect the law, it should set a better example.
Is this sarcasm or accidental irony?
It's a bloody good idea. If the rich, and those with political connections didn't get away with so much, it might make people respect our legal system more.
But, if the rich can win any court battle by throwing lawyers at it, and the politicans can get away with nearly any crime, why should we respect the system?
Companies buy quad Xeons with 2-4GB of RAM, massive SCSI RAIDs, etc etc, to serve static web content?
*choke*
Not bloody likely.
If a 486 can saturate a T1, a Dual Celeron or single P2 can easily saturate a T3.
And, if someone does buy this killer machine, they don't deserve to get decent performance at webserving because they bought the wrong hardware. You wouldn't expect to get better performance out of an 18-wheeler in place of a 2-door car for running your local courier business...
If anyone buys something based just on a sales pitch, they deserve the massive waste of money they end up with.
The second CPU isn't as much to make the web stuff run faster as it is to keep general system stuff from eating web server cycles.
Running 'other apps' on an NT Web server means your a pretty darned small company, or it's a department level server that doesn't do much web serving at all..
Not at all. There's a *lot* going on behind the scenes on a standard web serving NT box. Run File Monitor or Reg Monitor to see everything that goes on. And a lot of it isn't related to the task at hand. That's what a dual CPU machine handles well. All the minor stuff gets done on one CPU allowing the other CPU to do nothing but the task at hand.
The nice thing about Celerons is that you can get this second CPU for $200 or so, including the extra cost of the mb that will support it. It's IMHO not worth $800 or so for a second P2 or P3, but a Celeron can give these sort of things a nice kick.
In a transaction based environment, which web serving is, the Xeon will kick your Dual celeron out of the stratusphere..
I highly doubt you could come up with a price/performance study that showed a quad Xeon beating a dual Celeron cluster in web serving.
But yes, if you can only have one machine, or have very CPU intensive tasks to perform on that machine inbetween the serving, a quad Xeon will perform a lot better than a dual Celeron. As should anything that costs eight times as much.
But I doubt you'd get a quad Xeon benchmarking more than four times faster on anything that wasn't specifically written to fit into a Xeon's larger cache.
Re:It's all how you look at it
on
Copyright!
·
· Score: 1
But if the GPL wasn't enforcable due to copyright laws going away, you could disassemble whatever you want.
Besides, few people are saying copyrights should 'go away', they just want them back to normal terms. Who needs copyrights for 150 years after the death of the author? That's not needed for the author, or for the care of their loved ones after their death.
The only entities who benefit from this are ones which can live that long, corporations.
IMHO, 20 years after the creators death is a good point for copyrights to end, or fifty years, whichever is longer. That way if someone wrote something and died a month later, their family would get a decent ammount of copyright protection. And fifty years is also more than enough for a corporation to profit from an idea.
Sure, but a Dell Dual Xeon was around $4500, a Quad Xeon was $14,500...
That extra $10k could even buy two copies of NT Server.
But, that $15k could buy two three dual Xeons, or ten dual celerons...
My company runs a fair bit of web stuff off of dual celerons. The second CPU isn't as much to make the web stuff run faster as it is to keep general system stuff from eating web server cycles. If you find a pair that work well together, they do SMP like a dream. And a dual celeron 433 is even faster than a P2 650 and most things.
Wouldn't audiophiles be better served by taking very high quality 90+Khz, 32b, etc, and compressing it to get the same ammount of music on the device?
I mean, you lose a little bit of the data with lossy compression, but a 128kbps MP3 is far better than a 128kbps WAV, so wouldn't a 4mbps MP3 be better than a 4mbps WAV?
Assuming you had equipment that would let you record at this fidelity...
For a PC, yes. 4 CPUs is very big. Ditto with 2GB of RAM.
As in, so big they should look at a low-end mini, or a cluster of smaller PCs.
This is like strapping an F-16 engine onto a volkswagen. That's a BIG engine. But then you come along and say it's not because the SR-71 has bigger engines.
The point isn't that a 4 CPU PC is the biggest thing ever made, but that it's way bigger than it should be.
Strapping a jet engine on a VW doesn't let you take on enemy MIGs, and neither does building a $35k PC let you challenge real mini-computers.
You get a lot more out of this sort of test if you have a monetary goal and let both teams build a system for less than that.
Nobody would be dumb enough to run a webserver off of a 4 CPU Xeon with 2GB of RAM. Nobody.
For that price they could get four or five 2 CPU P2s and blow the performance out of the water.
Not only is a 4 CPU Xeon massively expensive, but by the time you scale a data-moving operation like web serving up enough to tax the CPUs, you've saturated the bus.
Sure, NT beats Linux, on that hardware.
The tests would have been a lot more even if the Linux people got to pick the components in the system (one faster gigabit ethernet card, etc)... The tests would have gone the other way with clusters. And if you factored software price in, would have been as outrageously in favour of Linux as the original Mindcraft study was for NT.
Sure, these tests show that Linux has some weak spots, and they will eventually get fixed, but the tests are still biased FUD.
Do you know of a fortune 500 company where the CEO would say "Build a Quad Xeon with 2GB of RAM and etc etc.. to serve our web pages" or does "Take this $20k and go build us something to serve web pages" sound more likely?
Restrictive hardware decisions like that don't happen, so testing on those machines is pointless.
(Not even an NT bigot would do that, because they'd get more from two Dual Xeons than one Quad, and they know it.)
What you miss is that those are good ideas. For 99% of the users, having those ports blocked is good.
For the 1%, well, they should be smart enough to read the docs and request that those features be ignored for them.
I would personally have no problem with an ISP that did this, as long as it was run by fairly compotent people who would remove these 'protections' from my account if I asked.
Especially the 100 sent emails a day. I've only needed to go near this limit a few times, and my email logs would show that I had sent similar numbers of messages, all with different subjects and contents, in the proceeding days.
If a spammer went through the trouble of sending out enough 'real' email to appear to be legit, then let them spam, once. It'd stop all of the casual spammers.
As long as the ISP is partially responsible for the actions of the users, (as in, will be RBLed if they screw up too much) they should take precautions to prevent these malicious user actions.
And, if you absolutely can't stand it... buy an unrestricted shell account somewhere and use a tunneling protocol to communicate with it without your ISP watching.
It had the same good top-down view as the rest, but it was larger, had more detailed NPCs, more items, etc.
It also fixed a lot of user interface 'features' imho.
Like, in 5, you could target distance weapons in more than eight cardinal directions. You could also repeat your last attack. It made the game play a lot better because you got through the fights without putting as much time into them, and got into the quests.
Four and five were my faves, but five was (imho again) miles better than four.
Slashdot Mirror
The basic FFT algorithm is easily checkable. All SETI@Home has to do with a new version to test it is run a few blocks through. If the routine is truly just an optimized version that returns the same results, then they should be able to easily verify this.
And I don't know where you get the idea that everyone will run their own client. That's like assuming everyone runs a cracked client now.
Security by obscurity isn't. If they want believable results at the end of this, they have to let people audit their methods. If the code is a black box, and nobody knows what it does, nobody can trust it to return the right answer.
So you look at the source and submit changes to the SETI@Home people. They take the best patches and optimizations. Test them like crazy, and release the next official client.
Sure, some people could run unauthorized clients, with unchecked code, but people have already started cracking the client, sending back fake blocks.
The worst case scenario is the same. The average case is much better with open source.
(More speed allows more redundancy to catch idiots who mess with the results.)
Ok, I'm done. Don't know what took you so long.
Process the data packets, hash the results, with MD5 or SHA, then return the hash along with whatever other results are needed.
SETI@Home picks some random number of packets and sends them out to a second user, checking to see if both users return the same hash value.
And this doesn't just stop malicious forgery, but it also stops bugs which may cause incorrect packets to be returned some of the time.
This does require keeping a list of the packets a user processes, but this shouln't be that hard. Especially because they start fresh every week (month?) with the new data.
Where this gets really hard is with Bovine, and the code breaking.
The message is known to the users, so the cracker (bad guy) knows what result to watch for. And he knows what result to return (yes, or no). Easy to forge.
Bovine is also more likely to get a user hiding hits, instead of faking misses. For misses, they simply use a hash of the first bytes of the 'plaintext' after each decryption and compare these. For a hit, they need to hope that the packet with the hit is one sent out for inependent verification.
What they need is a cryptographic way of hiding the true results from the user.
As in, in you have C, a cyphertext, and P, a plaintext, and want to find K, the key that turns C into P, is there some transformation you can make to C and P that allows the same key to function, but masks the cypher and plaintext?
This isn't as impossible as it sounds... Imagine a rotation cypher with a numeric key.
Let's imagine the key is 3.
Plaintext 'CAT' becomes 'FDW'
Add the transformation -1 to both
'CAT' becomes 'BZS', 'FDW' becomes 'ECV'
Now, imagine the Bovine group wanting to test their users. They think people will hide a success, making the project continue.
If the user knows that the random-looking cypher text decrypts into 'CAT' they simply watch for 'CAT' to be decrypted and they've found the key.
So, Bovine sends T(C1) and T(P), the transformed (T layer) cyphertext (C1) and plaintext (P1). The user knows that T(P1) is the desired result, 'FDW' in this case. But they don't know if that plaintext is the contest winner, or a loyalty check. So they decrypt T(C1) and low and behold, it matches T(P1) ('BZS' becomes 'ECV') and the software says 'We did it!'.
If they report this set of keys as a failure, Bovine *could* have planted this key, and shut them down when it isn't reported. Or, it could be the real key. They'd never know.
So they're compelled to be correct, because if their answers don't match the ones Bovine expects, Bovine doesn't trust their other answers and their stats are thrown out.
So, we need to find the transformation (T) that allows T(C)+K to equal T(P) for all cyphertexts and all plaintexts.
There may not be such a transformation that does this, but if there is, this is the ultimate answer for Bovine, and other projects like this.
They should be checking a random sampling of returned blocks to make sure the processing is correct.
This could catch both malicious forgery and accidents, like perhaps there's a bug in the code so that a k6-2 of 450Mhz returns false answers... How would they know?
And the idea of an open client means, at least to me, that we'd submit changes to SETI@Home, and they'd release the next approved client.
That's not a way to handle it. If everyone who has a problem with the specific implementation goes away you end up with SETI@Home being critically underpowered. And I like what SETI@Home is trying to do. I just wish they didn't make it an either-or choice of helping them or helping other projects. A well written client would allow people to participate in more computing projects with the same number of spare cycles.
I don't think you really understand how to optimize code.
You optimize the sections of the code that take the most processor time, and the programs you use the most. If lilo completes in milliseconds, don't optimize it. If your whole office app is a pig, optimize the parts that the user spends the most time in. If your shell is fairly quick, yet you spend eight hours a day working in it, it might be worth optimizing those input routines even if it's only a 10% overall speed gain.
With SETI@Home, sure, they run out of data before they run out of time. But, they don't have to perfectly match. By your logic we should slow down the client so as not to waste any cycles on unimportant non-SETI@Home processing.
I'd prefer to optimize SETI@Home and either require less users, or process the week's signals faster and be able to run other distributed projects.
Because SETI@Home *is* a valid target for optimization. It sucks an incredible number of cycles. And now that we're used to running distributed projects, those aren't useless cycles anymore. You can see SETI@Home as competing directly with other projects for computer time.
It's much the same as a slow subroutine making the whole application slow. But in this case the subroutine is SETI@Home and it's making the application of providing computing resources to as many distributed projects as possible run poorly.
Because it's a pain in the ass having to look at the television the whole time. If the show is dubber you can make out the words even if the picture underneath is complicated, or if you want to go look in the fridge, where you can hear the TV, but not see it...
If I wasn't english speaking (or had a favorite movie which was foreign) I would watch it at least once subtitled instead of dubbed, to see if I missed anything, but usually, I'd use the dubbed version.
When I watch Anime with my friends (who are bug-fuck, and I mean like Magic the Gathering level bug-fuck, for it) I prefer the dubbed version because it's easier to watch.
And, "so much of the feeling the director intended to convey"??? Evidently you have mistaken TV and movies for art.
It's funny to watch my friends rant about cartoon (Anime) and how it's "just not the same" when dubbed. Like any of them speak Japanese...
SETI@Home is partially worried about people submitting unchecked data packets to boost their score, or not submitting a signal if found, simply to mess with the project.
But, they're also concerned with the project working too well. If their weekly allotment of data was processed in a day, users would either sit idle for the rest of the week, or recheck data. Either is likely to make people look for another project.
We need to have a general distributed processing client with modular cores. That way people can check for alien signals when the new SETI@Home client comes out, then evaluate various check opening moves, or try code keys, or any other project that needs users.
The basic shell of a distributed client is fairly simple, and in most cases is very similar. The system sends you data, tells you what to do with the data, and accepts processed data for return.
The same client could send out SETI@Home packets and DES keyspaces depending on which project had a more immediate need for help, and what the client computer was capable of.
Cracking code keys is a lightweight process. It takes very little RAM, and can be suspended instantly. Running FFTs on radio signals (SETI@Home) is a heavyweight process. It requires a lot of RAM, and isn't generally appropriate to run in the background while using the computer.
A multi-core client could deal with this beautifully. When you're using the computer, a lightweight process is selected based on your preferences and need, and runs in spare cycles, not being noticed. When the screensaver kicks in indicating an idle computer, the lightweight process is swapped out for a heavyweight process like SETI@Home or chess analysis, to be run when a performance deficit on the client won't be noticed.
The user could download processing cores for the projects they'd like to participate in, and list the jobs in order of preference. For instance, SETI@Home then chess analysis for the screen-saved modules, and Bovine code cracking for the spare-cycle modules.
Then the system would crack codes between keypresses, and switch to SETI@Home when there are data blocks available, but switch seamlessly to the less time-critical chess analysis when the SETI@Home blocks run out.
The system has the benefit that not every author of a distributed project would have to write a whole system, plus servers, and bug test it. You'd simply write a processing module and a server module to properly serve that data, and compile the client module for as many systems as possible, or distribute it as compilable code. Thus allowing SETI@Home to run on an SGI machine for instance, without the authors having to write a communication system that would run on that computer.
Mathematical tasks, like cracking keys, or recursively iterating chess moves, or FFT calculations are fairly easy to implement in a small program, and are fairly portable, usually not relying on the OS for much.
Currently, there are many ideas for distributed projects which never get explored because they don't have anybody capable of coding a client as stable/easy as the bovine, or of finding a large enough audience to make it worthwhile. Having one shell with multiple cores would allow anyone who can express their problem in code to reach a large audience of people ready to work on their distributed project.
So, if they released their source, bugs would magically appear?
Open source doesn't cause bugs. Fast development cycles cause bugs. End of story.
If they open sourced the project they'd speed it up enough (proof: AMD and other organizations have offered both general speedups and processor-specific speedups of over 100%) to add redundancy, both to check the method by processing some packets with an alternate algorithm, and to guard against false packet returns.
They aren't obligated to open-source the project, but I for one quit running SETI@Home when I heard about them refusing optimization help because they didn't want to process the packets too quickly. I don't care what their reasons are, I simply refuse to run something that's woefully unoptimized, especially when they were presented with alternatives. Now I'm running other distributed projects with my spare cycles. And I suspect I'm not the only convert.
But, it *is* about finding the signal. It may not be about *you* finding the signal, but the *whole point* is to track down a signal.
To track down the signal, units must be processed. If we process signals faster it'll either let them eventually process more signals (larger spectrum, etc) or use less computers. Either is a worthy goal. One helps science, the other simply saves power and lets people run other distributed projects.
SETI@Home is hindering their own project by insisting on slow (They refused AMD's offer of help to speed the client up, doing more work, as carefully as before, in less time.) clients just to keep a large number of users helping is a bad PR move. You could help a project that wants to process data, or you could help SETI who wants a large number of users, who incidentally process some data.
Don't forget to close that italic tag...
Good point. Heck, I don't think you'd even get a free OS, because to be good, a OS has to be current...
Well, a school is primarily a name thing. I went to [name], and [name] was my professor for my main course. Thus it helps to have known professionals for the big courses.
And it also helps to have a consistent course, where all the material is written and presented by one person, so they really understand it and how to teach it.
Some course work, the lower courses especially, and a lot of the TA work, helping students, could be done by less well-known people.
In fact, it could be like the usenet oracle. As part of your tuition, you spend some number of hours tutoring people in lower classes.
But, I don't think open-source is a good model for the upper class teaching. Consistency of presentation is important. It probably wouldn't cost much though, because most of what a prof charges for is the constant demand on their time. If they could record one set of course work, even with a bunch of suplemental work, they could do it in less time than teaching two courses.
I for one, would rather learn at a school with Knuth and Sedgewick, etc, teaching comp-sci than a bunch of random 'professionals' who all donate a badly recorded two-hour MP3 of what they feel is important. I'm not into paying $10k a year, but $500 is pocket change for getting a well known prof.
I don't think you'd ever get free schools, because to be good, a course has to be current, and for that you need new material which means paying someone good to write it.
And there are problems trying to teach a full university curriculum without physical space. Many science courses require labs, etc.
But, a good comp-sci technical school could be done. And if not free, it could be done quite cheap.
You'd need to have content written and presented by the professors. And you'd need to have them available a certain ammount of time online to answer student questions and explain the lesson.
You'd also need to charge a bit just to run the day to day business end of the school. Secretaries, librarians (even if the resources are electronic, they need to be properly cataloged.)
If you were going to give certificates you wanted to mean anything, you'd have to have fairly cheat-proof testing. Ditto if you want people to be able to challenge a course. This probably means hiring a bunch of local firms to test the students in their area.
So, free is unlikely, especially if you want to have your degree mean anything, not just teach people. But cheap. Cheap is doable.
I'd go to a school like this. I don't have time for 'school' but I could always learn something new, and having a piece of paper saying I know the things I've learned on the job would be handy. Especially if I could challenge the course if I knew it that well.
But, don't try to stop random murders until you've stopped the abusive childhoods that make the people that way. And don't try to stop abuse until you rid everyone of the taste for alcohol. And don't do that until you've cured the basic insecurities that cause people to have an addictive personality.
Or, sit and home, sucking your thumb, withdrawing from the world because you can't tackle anything less than the absolute biggest problems and you don't have a hope of winning against those without solving smaller problems first. You go get that windmill. It'll do society and you a lot of good to waste any good intentions of energy you might have by fighting the unwinnable fights.
Hmmmm. Maybe we could do things that we have a chance of suceeding at. And when done that, with the experience we've gained, we can work on bigger injustices... That way, not only would things get done, but eventually the big stuff would get done too.
Fight the spammers. They're stealing from you by using bandwidth you pay for to send you advertising. They can be fought. It's not that hard. And it's a battle worth winning.
Is this sarcasm or accidental irony?
It's a bloody good idea. If the rich, and those with political connections didn't get away with so much, it might make people respect our legal system more.
But, if the rich can win any court battle by throwing lawyers at it, and the politicans can get away with nearly any crime, why should we respect the system?
Companies buy quad Xeons with 2-4GB of RAM, massive SCSI RAIDs, etc etc, to serve static web content?
*choke*
Not bloody likely.
If a 486 can saturate a T1, a Dual Celeron or single P2 can easily saturate a T3.
And, if someone does buy this killer machine, they don't deserve to get decent performance at webserving because they bought the wrong hardware. You wouldn't expect to get better performance out of an 18-wheeler in place of a 2-door car for running your local courier business...
If anyone buys something based just on a sales pitch, they deserve the massive waste of money they end up with.
Running 'other apps' on an NT Web server means your a pretty darned small company, or it's a department level server that doesn't do much web serving at all..
Not at all. There's a *lot* going on behind the scenes on a standard web serving NT box. Run File Monitor or Reg Monitor to see everything that goes on. And a lot of it isn't related to the task at hand. That's what a dual CPU machine handles well. All the minor stuff gets done on one CPU allowing the other CPU to do nothing but the task at hand.
The nice thing about Celerons is that you can get this second CPU for $200 or so, including the extra cost of the mb that will support it. It's IMHO not worth $800 or so for a second P2 or P3, but a Celeron can give these sort of things a nice kick.
In a transaction based environment, which web serving is, the Xeon will kick your Dual celeron out of the stratusphere..
I highly doubt you could come up with a price/performance study that showed a quad Xeon beating a dual Celeron cluster in web serving.
But yes, if you can only have one machine, or have very CPU intensive tasks to perform on that machine inbetween the serving, a quad Xeon will perform a lot better than a dual Celeron. As should anything that costs eight times as much.
But I doubt you'd get a quad Xeon benchmarking more than four times faster on anything that wasn't specifically written to fit into a Xeon's larger cache.
But if the GPL wasn't enforcable due to copyright laws going away, you could disassemble whatever you want.
Besides, few people are saying copyrights should 'go away', they just want them back to normal terms. Who needs copyrights for 150 years after the death of the author? That's not needed for the author, or for the care of their loved ones after their death.
The only entities who benefit from this are ones which can live that long, corporations.
IMHO, 20 years after the creators death is a good point for copyrights to end, or fifty years, whichever is longer. That way if someone wrote something and died a month later, their family would get a decent ammount of copyright protection. And fifty years is also more than enough for a corporation to profit from an idea.
Sure, but a Dell Dual Xeon was around $4500, a Quad Xeon was $14,500...
That extra $10k could even buy two copies of NT Server.
But, that $15k could buy two three dual Xeons, or ten dual celerons...
My company runs a fair bit of web stuff off of dual celerons. The second CPU isn't as much to make the web stuff run faster as it is to keep general system stuff from eating web server cycles. If you find a pair that work well together, they do SMP like a dream. And a dual celeron 433 is even faster than a P2 650 and most things.
Efficent usage of money.
Actually, that was funny.
Wouldn't audiophiles be better served by taking very high quality 90+Khz, 32b, etc, and compressing it to get the same ammount of music on the device?
I mean, you lose a little bit of the data with lossy compression, but a 128kbps MP3 is far better than a 128kbps WAV, so wouldn't a 4mbps MP3 be better than a 4mbps WAV?
Assuming you had equipment that would let you record at this fidelity...
A bad admin shouldn't make a unix box crash. They shouldn't be able to do much other than configure it badly and waste performance.
A stable unix should be proof against most newbie admin blunders.
For a PC, yes. 4 CPUs is very big. Ditto with 2GB of RAM.
As in, so big they should look at a low-end mini, or a cluster of smaller PCs.
This is like strapping an F-16 engine onto a volkswagen. That's a BIG engine. But then you come along and say it's not because the SR-71 has bigger engines.
The point isn't that a 4 CPU PC is the biggest thing ever made, but that it's way bigger than it should be.
Strapping a jet engine on a VW doesn't let you take on enemy MIGs, and neither does building a $35k PC let you challenge real mini-computers.
Except that most DVD piracy is from exact duplicates of the master disk. They didn't have to crack anything to do that.
As long as movies are too big to easily upload and store on the HD, I can't see mass piracy being a problem when user copying is considered.
You get a lot more out of this sort of test if you have a monetary goal and let both teams build a system for less than that.
Nobody would be dumb enough to run a webserver off of a 4 CPU Xeon with 2GB of RAM. Nobody.
For that price they could get four or five 2 CPU P2s and blow the performance out of the water.
Not only is a 4 CPU Xeon massively expensive, but by the time you scale a data-moving operation like web serving up enough to tax the CPUs, you've saturated the bus.
Sure, NT beats Linux, on that hardware.
The tests would have been a lot more even if the Linux people got to pick the components in the system (one faster gigabit ethernet card, etc)... The tests would have gone the other way with clusters. And if you factored software price in, would have been as outrageously in favour of Linux as the original Mindcraft study was for NT.
Sure, these tests show that Linux has some weak spots, and they will eventually get fixed, but the tests are still biased FUD.
Do you know of a fortune 500 company where the CEO would say "Build a Quad Xeon with 2GB of RAM and etc etc.. to serve our web pages" or does "Take this $20k and go build us something to serve web pages" sound more likely?
Restrictive hardware decisions like that don't happen, so testing on those machines is pointless.
(Not even an NT bigot would do that, because they'd get more from two Dual Xeons than one Quad, and they know it.)
What you miss is that those are good ideas. For 99% of the users, having those ports blocked is good.
For the 1%, well, they should be smart enough to read the docs and request that those features be ignored for them.
I would personally have no problem with an ISP that did this, as long as it was run by fairly compotent people who would remove these 'protections' from my account if I asked.
Especially the 100 sent emails a day. I've only needed to go near this limit a few times, and my email logs would show that I had sent similar numbers of messages, all with different subjects and contents, in the proceeding days.
If a spammer went through the trouble of sending out enough 'real' email to appear to be legit, then let them spam, once. It'd stop all of the casual spammers.
As long as the ISP is partially responsible for the actions of the users, (as in, will be RBLed if they screw up too much) they should take precautions to prevent these malicious user actions.
And, if you absolutely can't stand it... buy an unrestricted shell account somewhere and use a tunneling protocol to communicate with it without your ISP watching.
Really? I liked Ultima V the best.
It had the same good top-down view as the rest, but it was larger, had more detailed NPCs, more items, etc.
It also fixed a lot of user interface 'features' imho.
Like, in 5, you could target distance weapons in more than eight cardinal directions. You could also repeat your last attack. It made the game play a lot better because you got through the fights without putting as much time into them, and got into the quests.
Four and five were my faves, but five was (imho again) miles better than four.