No (non-quantom) computer can compute the result of any single operation faster than the speed it takes electrons to propagate through the gates for that operation. The clock speed for that computer is limited to (right around) the lowest value n/t (where n is the number of electrons in an operation, and t is the time it takes before another electron can be pushed into the operation). If the clockspeed is raised past that then operations will begin to fail (due to things like 2 different operands being at the same gate at close enough to the same time that they effect each other).
A clockless design still suffers this. The difference is that in a clockless processor will not need to wait for the lowest n/t value in order to do an instruction. Instead it would be able to do an instruction as soon as it is ready for another operand.
IIRC intel has already worked around the biggest effect of this (add and similar instructions are faster than mult and div) by seperating the adders away from the ALU and operating it at 2x the clock speed of the main clock.
It is unlikely that a clockless design has any potential to go faster (or should I say, do the same amount of work in less time) than a clocked design. This is not only because of the higher amount of pipelining available and the smaller amount of overhead around each instruction (clockless needs handshaking all over, clocked assumes the destination is ready because it already sent its value elsewhere).
The advantage of a clockless design is that it does not require any energy, nor does it emit any em waves, when it is not computing a result. It is not that it does more work, and it will never be that it does more work.
it has to be limited at least by the time it takes an electron to go from one end of the processor to another. That is about as fast as any processor can get.
I doubt it is anywhere close to this though or we would already have these (and the problem we would be trying to solve would be simply making it smaller, hence less distance, hence more work done).
30 Ghz = 30 billion times per second, 8 bits each time = 240*10^9 bps 240,000,000,000 bps * 3600 = 864,000,000,000,000 bits of data That is over 2^49 possible starting points for one antenna, given an hour of uncertainty
With 2^15 antennas you now have 2^64 possible starting points.
This still doesn't take into account that if 2 people are sampling the same random data at the same frequency they need to pick the data at exactly the same time. One person's 30 Ghz sample could be offset from another person's 30 Ghz sample. For example if person A captured at 12:00 and 500 picoseconds and person B began sampling at 12:00 and 750 picoseconds, the analog signal they are sampling from could have changed in those 250 picoseconds time.
More likely the 2 parties will decide on several things: the quasar, the starting point, and the frequency; they would then need to agree on an algorithm to ensure they are recording the same data (at some high probability, because it is possible they record the same numbers for some period of time and then (because they were not on the same stream) suddenly begin recording different numbers).
Supposing the eavesdropper could get the starting timeframe down to an hour, know the quasar, and the frequency of the transmittion, they would need to gather the possible pads from the quasar at a very high frequency (many multiples above the frequency of the transmittion) and then downsample it to the frequency of the transmittion and check if it gives a valid message. On a 30 Ghz transmittion a 4800 Ghz sampling from the quasar may be required to ensure close enough values that an error correction will be able to discover the plaintext.
Needless to say, a quasar would certainly provide enough random data to be used as a very secure encryption mechanism. The reason this hasn't been done already is precisely the comment about radio signals at the end of the article. If 2 parties were communicating via this encryption and another wanted to listen in (and had the capabilities of launching hundreds of satellites) it would be fairly simple to bombard the communications facilities of the 2 parties with a radio signal that appears random enough, but the eavesdropping persons would know the signal is not random and could create it to decrypt any message. I could just imagine sending the first couple billion digits of pi over and over again at 120 Ghz would be enough to make it look random for a while (while still making it easy enough to crack).
If this person has managed how to get around that problem, then we may have a good new encryption.
You could install and set up mpich2 (http://www-unix.mcs.anl.gov/mpi/mpich2/) and use it to run the same program on each computer seperately and output the results on the terminal that you entered the command.
ex. (get the hostname from 4 different computers) #mpiexec -n 4/bin/hostname fred frank fluffy twirl
This is most likely very overkill for what the author wants tho.
My plan is the 250 message plan ($5 IIRC) meaning I pay for 250 messages every month regardless. I can send and recieve to other verizon customers as much as I want (good because all my friends also have VZW) for free as long as I have one of the message plans. I send about 700 messages a month (around 600 of them are to my friends on VZW), and the other 100 are to GOOGL (46645) and I recieve around 750 (600 from friends within VZW and 150 from google).
This plan is a pretty good deal for me, because I mostly text to my friends who are also in the "in" network. The other carriers here offer similar rates (free within their network, costing outside it). If I was paying for all sent messages this would equate to (5/700 =.007) seven tenths of a cent for me each message (.045 DKR per sent message).
These pricing schemes seem to lead to localized monopolies (everyone around me uses VZW, If you go about 50 miles northwest of me most people use sprint) because if you want the cheapest bill, you go with whatever the people around you have.
You can get message plans at 250, 500, and 1000 messages sent or recieved from anywhere, along with free "in" messages. These numbers are combined send and recieve numbers.
As soon as you install type "yum update yum" then "yum update" in a terminal as root. I have done this 6 times already (different installs), and each time it fails on a dependancy around 4 minutes into the update.
vs: gentoo (installed feb 2003 then let sit[dual boot system, stayed in windows for a while] till december 2005)
type: "emerge --sync" then "emerge --update portage" then "emerge --update world"
Get up and let the system update itself, you don't have to sit there and say "y" to every dependency list.
Yum is slow. It is slow because you have to wait for it to update the headers every time you run it and because (in my experience) you cannot update the entire system in one shot (each of those 6 systems I had to update one package at a time, it took 11 days each; in contrast my gentoo update finished in 8).
I don't know if I would be willing to trust Atlassian. On their page for the top ten features of JIRA here
They have this as the first reason: JIRA has features that you just will not find in any other issue tracker:
* Easily build and save highly-configurable filters (dynamic queries) across all issues in the system. Umm... SugarCRM, Bugzilla, SalesForce, and Remedy have this (to varying degrees)
* Share filters with other users, or subscribe to them and get the results emailed to you periodically. In Bugzilla(email the search link to share, RSS feeds) In SugarCRM(not sure how to share; I suppose you could email search links, RSS feeds as well) The other 2 I listed before, I don't know, haven't used too much.
* Dynamic issue links allow you to link issues across projects, for example duplicates or subissues. SugarCRM, Bugzilla, SalesForce, and Remedy have this (linking bugs back and forth should be a standard feature in a bug tracker)
* The Dashboard gives each user a single place to view all information relevant to them at a glance. Bugzilla - My Bugs Remedy - My Issues (if I remember correctly) SugarCRM - Home SalesForce - Home (yeah it is a stretch on these last 2, you are managing way too much information to fit it all on one screen usually with these apps)
* Custom fields, Bugzilla - (not exactly yet [there are patches that do this now tho], see this buglist, and especially bug 91037 SugarCRM - yep Remedy - yep (as I understand it, everything is a custom field in Remedy) SalesForce - I believe so
project roadmaps, Bugzilla - define roadmap exactly, if you are looking for milestones and dependencies, then yes, if you are looking for marketing hype then possibly not SugarCRM, Remedy, SalesForce - yep
changelogs, Bugzilla - sorta, if you are using it correctly SugarCRM, Remedy, SalesForce - I don't know
REST API What is this? Bugzilla - not a "REST" API... (lots of perl modules, for users wanting server API for writing plugins, bug 224577 is the start of a future SOAP API that would let bugzilla become a web service:)) SugarCRM, SalesForce - Both have their own API's for writing plugins Remedy - Is there any need for one? The problem with Remedy is that it often does too much. This is why they send a person to your installation site to discuss with you exactly what you need, and then they customize it for you.
and much, much more... This doesn't even need commenting.
I am just using these 4 (very different) products to demonstrate because I have used each of them. I am sure there are others that maintain each of those features.
I would love a piece of software that does this, if it would save me the hour or two (depending on if I choose to manually uninstall, or simply reformat) on every new dell box that comes across my desk at work (that is, every new box for the company).
Neither of these is a good option, because in both instances I need to sit there and click away at the machine.
Even better maybe, if a player reaches a certain level in their account then they can choose to take the place of NPCs throughout the game, and as they level up their main account, they can get more options in the NPCs, example: lvl 10-20 they can be some random NPC(monster) throughout the early world lvl 21-30 they can also become NPC boss characters (whatever the stronger things in quests) 31-40 any non quest/non endgame NPC in the world 41-50 any quest NPC 51-59 any endgame NPC 60 "Quest Master" (could design quests for players to accomplish, like "guide me through the molten core to the far side and back without me dying and I'll give you this")
Additionally devise a voting system for who can get to be what NPC so high level guilds can vote who becomes what NPC (so better people can do it more often).
Mac refers to the fact that it is apple hardware. You could buy any ppc and install Apple's OS on it (like a bebox), but you were not suppossed to call it a mac (at least this is how I understood it).
The only thing that would cost money would be time and creativity. Someone would need to actually move things away from the duplication machine(s). And anything new would need to be created without the machine.
Why does this get marked redundant? I tried to point out a mistake in the article, and was the first (and only) one to do so:
Scott 'Gallenite' Hartsman, Senior Producer for Everquest 2, has announced the pending combination of ten servers with ten other others. Normally, this sort of announcement would be met with immediate derision, a collectively vindictive sneering about a game that wasn't successful or is dying. However, because of when this combination is coming, and how it is being handled, I have a slightly different view." Additional commentary at Aggro Me.
Use Bugzilla (or Trac, but that isn't quite as good yet, OTOH it integrates with subversion; or use sugarcrm's bug tracking software, but again that isn't quite as polished)
Make every new feature go through bugzilla as an enhancement.
Never do more than one thing in a function (if your function requires more sentence structure than that of a 6 year old to describe what is happenning: you are doing too much)
Head every function set with the following comments (consider using xml based versions of this that can be exported to an html page by using a generator):
//Summary: // the 6 year old's description here //Requires: // name of each function and data type used here along whith the file they are located in //Preconditions: // the state expected for each variable that your function uses before the function begins //Postconditions: // the state of variables and the return value as the function completes //Throws: // possible exceptions thrown by the function
void main() {
string bin = "0100100100100000011101000110100001101001011011100 1 10101100100000011000100111100100100000001001110110 01100111010101101110011011100111100100101100001001 11001000000111010001101000011001010010000001101101 01101111011001000111001100100000011011010110010101 10000101101110011101000010000000100111011000010110 11100110111001101111011110010110100101101110011001 110010111000100111"; // getline(cin,bin);//uncomment this to get binary from stdin
unsigned char c=0, i=0;
for(int p=0; p<bin.size();++p) {
switch(bin[p]) {
case '0':
c = c<<1;
i++;
break;
case '1':
c = (c<<1) + 1;
i++;
}
if(i==8) {
cout<<c;
c=i=0;
}
}
getline(cin,bin); }
Re:My short experience with perl...
on
What is Perl 6?
·
· Score: 1
It may help new users even more to simply think of $ and @ as a description of the context you are writing in. Sort of like writing a sentence using plural words.
It helped me to think of @ as making your sentence plural. For example:
1: there is no evolutionary problem with the Cambrian explosion (In fact evolution explains it very well, there were spaces to fit, so species evolved to fit the spaces) 2: people lie 3: ID doesn't make any discoveries
Most of all, I didn't prove God doesn't exist. I merely proved that one of those seven assumptions is false. If 1,2,3,5,6, and 7 are true then heaven cannot exist, as people cannot go there. If 1,2,4,5,6 and 7 are true then even god cannot know everything. If 1,2,3,4,6, and 7 then there exists a place where people are happier then heaven.
I actually assumed that god does exist, and reached a contradiction; this means that at least one of the assumptions is wrong.
I would rather God didn't exist, then any of the other conclusions that the arguments come to, but I cannot prove that a god doesn't exist with that argument.
Slashdot Mirror
I didn't quite word that correctly I guess:
No (non-quantom) computer can compute the result of any single operation faster than the speed it takes electrons to propagate through the gates for that operation. The clock speed for that computer is limited to (right around) the lowest value n/t (where n is the number of electrons in an operation, and t is the time it takes before another electron can be pushed into the operation). If the clockspeed is raised past that then operations will begin to fail (due to things like 2 different operands being at the same gate at close enough to the same time that they effect each other).
A clockless design still suffers this. The difference is that in a clockless processor will not need to wait for the lowest n/t value in order to do an instruction. Instead it would be able to do an instruction as soon as it is ready for another operand.
IIRC intel has already worked around the biggest effect of this (add and similar instructions are faster than mult and div) by seperating the adders away from the ALU and operating it at 2x the clock speed of the main clock.
It is unlikely that a clockless design has any potential to go faster (or should I say, do the same amount of work in less time) than a clocked design. This is not only because of the higher amount of pipelining available and the smaller amount of overhead around each instruction (clockless needs handshaking all over, clocked assumes the destination is ready because it already sent its value elsewhere).
The advantage of a clockless design is that it does not require any energy, nor does it emit any em waves, when it is not computing a result. It is not that it does more work, and it will never be that it does more work.
it has to be limited at least by the time it takes an electron to go from one end of the processor to another. That is about as fast as any processor can get.
I doubt it is anywhere close to this though or we would already have these (and the problem we would be trying to solve would be simply making it smaller, hence less distance, hence more work done).
30 Ghz = 30 billion times per second, 8 bits each time = 240*10^9 bps
240,000,000,000 bps * 3600 = 864,000,000,000,000 bits of data
That is over 2^49 possible starting points for one antenna, given an hour of uncertainty
With 2^15 antennas you now have 2^64 possible starting points.
This still doesn't take into account that if 2 people are sampling the same random data at the same frequency they need to pick the data at exactly the same time. One person's 30 Ghz sample could be offset from another person's 30 Ghz sample. For example if person A captured at 12:00 and 500 picoseconds and person B began sampling at 12:00 and 750 picoseconds, the analog signal they are sampling from could have changed in those 250 picoseconds time.
More likely the 2 parties will decide on several things: the quasar, the starting point, and the frequency; they would then need to agree on an algorithm to ensure they are recording the same data (at some high probability, because it is possible they record the same numbers for some period of time and then (because they were not on the same stream) suddenly begin recording different numbers).
Supposing the eavesdropper could get the starting timeframe down to an hour, know the quasar, and the frequency of the transmittion, they would need to gather the possible pads from the quasar at a very high frequency (many multiples above the frequency of the transmittion) and then downsample it to the frequency of the transmittion and check if it gives a valid message. On a 30 Ghz transmittion a 4800 Ghz sampling from the quasar may be required to ensure close enough values that an error correction will be able to discover the plaintext.
Needless to say, a quasar would certainly provide enough random data to be used as a very secure encryption mechanism. The reason this hasn't been done already is precisely the comment about radio signals at the end of the article. If 2 parties were communicating via this encryption and another wanted to listen in (and had the capabilities of launching hundreds of satellites) it would be fairly simple to bombard the communications facilities of the 2 parties with a radio signal that appears random enough, but the eavesdropping persons would know the signal is not random and could create it to decrypt any message. I could just imagine sending the first couple billion digits of pi over and over again at 120 Ghz would be enough to make it look random for a while (while still making it easy enough to crack).
If this person has managed how to get around that problem, then we may have a good new encryption.
That is just too perfect. Well done.
Your shell runs 50 MB??? that sucks
RAIDed mail server on a quad processor system, over 10gb lan
You could install and set up mpich2 (http://www-unix.mcs.anl.gov/mpi/mpich2/) and use it to run the same program on each computer seperately and output the results on the terminal that you entered the command.
/bin/hostname
ex. (get the hostname from 4 different computers)
#mpiexec -n 4
fred
frank
fluffy
twirl
This is most likely very overkill for what the author wants tho.
In the states everything is about bundles.
.007) seven tenths of a cent for me each message (.045 DKR per sent message).
My plan is the 250 message plan ($5 IIRC) meaning I pay for 250 messages every month regardless.
I can send and recieve to other verizon customers as much as I want (good because all my friends also have VZW) for free as long as I have one of the message plans. I send about 700 messages a month (around 600 of them are to my friends on VZW), and the other 100 are to GOOGL (46645) and I recieve around 750 (600 from friends within VZW and 150 from google).
This plan is a pretty good deal for me, because I mostly text to my friends who are also in the "in" network. The other carriers here offer similar rates (free within their network, costing outside it). If I was paying for all sent messages this would equate to (5/700 =
These pricing schemes seem to lead to localized monopolies (everyone around me uses VZW, If you go about 50 miles northwest of me most people use sprint) because if you want the cheapest bill, you go with whatever the people around you have.
If it is not an "in" message they do. To quote their plan offering page:
TXT Messaging
Fun, easy way to stay in touch. TXT Messaging is a two-way text messaging service. Send and receive text messages of up to 160 characters right on your two-way messaging-capable phone. $0.10 for messages received and $0.10 for messages sent. Bundle plans also available. Sending and receiving text messages do not deduct from a calling plan's airtime allowance.
Not Available in some areas.
© 2006 Verizon Wireless
-----------------
emphasis theirs.
You can get message plans at 250, 500, and 1000 messages sent or recieved from anywhere, along with free "in" messages. These numbers are combined send and recieve numbers.
I know this is nothing more than a little flamewar, but...
try this: fresh install of fedora core 4 (custom install -> everything)
As soon as you install type "yum update yum" then "yum update" in a terminal as root. I have done this 6 times already (different installs), and each time it fails on a dependancy around 4 minutes into the update.
vs: gentoo (installed feb 2003 then let sit[dual boot system, stayed in windows for a while] till december 2005)
type: "emerge --sync" then "emerge --update portage" then "emerge --update world"
Get up and let the system update itself, you don't have to sit there and say "y" to every dependency list.
Yum is slow. It is slow because you have to wait for it to update the headers every time you run it and because (in my experience) you cannot update the entire system in one shot (each of those 6 systems I had to update one package at a time, it took 11 days each; in contrast my gentoo update finished in 8).
He could if he logged out to post the comment (or had 2 usernames).
Wow, I like these (Fitnesse and HyperPerl).
I don't know if I would be willing to trust Atlassian. On their page for the top ten features of JIRA here
:))
They have this as the first reason:
JIRA has features that you just will not find in any other issue tracker:
* Easily build and save highly-configurable filters (dynamic queries) across all issues in the system.
Umm... SugarCRM, Bugzilla, SalesForce, and Remedy have this (to varying degrees)
* Share filters with other users, or subscribe to them and get the results emailed to you periodically.
In Bugzilla(email the search link to share, RSS feeds)
In SugarCRM(not sure how to share; I suppose you could email search links, RSS feeds as well)
The other 2 I listed before, I don't know, haven't used too much.
* Dynamic issue links allow you to link issues across projects, for example duplicates or subissues.
SugarCRM, Bugzilla, SalesForce, and Remedy have this (linking bugs back and forth should be a standard feature in a bug tracker)
* The Dashboard gives each user a single place to view all information relevant to them at a glance.
Bugzilla - My Bugs
Remedy - My Issues (if I remember correctly)
SugarCRM - Home
SalesForce - Home (yeah it is a stretch on these last 2, you are managing way too much information to fit it all on one screen usually with these apps)
* Custom fields,
Bugzilla - (not exactly yet [there are patches that do this now tho], see this buglist, and especially bug 91037
SugarCRM - yep
Remedy - yep (as I understand it, everything is a custom field in Remedy)
SalesForce - I believe so
Excel integration,
Bugzilla, SugarCRM, Remedy, SalesForce - yep
project roadmaps,
Bugzilla - define roadmap exactly, if you are looking for milestones and dependencies, then yes, if you are looking for marketing hype then possibly not
SugarCRM, Remedy, SalesForce - yep
changelogs,
Bugzilla - sorta, if you are using it correctly
SugarCRM, Remedy, SalesForce - I don't know
REST API
What is this?
Bugzilla - not a "REST" API... (lots of perl modules, for users wanting server API for writing plugins, bug 224577 is the start of a future SOAP API that would let bugzilla become a web service
SugarCRM, SalesForce - Both have their own API's for writing plugins
Remedy - Is there any need for one? The problem with Remedy is that it often does too much. This is why they send a person to your installation site to discuss with you exactly what you need, and then they customize it for you.
and much, much more...
This doesn't even need commenting.
I am just using these 4 (very different) products to demonstrate because I have used each of them. I am sure there are others that maintain each of those features.
I would love a piece of software that does this, if it would save me the hour or two (depending on if I choose to manually uninstall, or simply reformat) on every new dell box that comes across my desk at work (that is, every new box for the company).
Neither of these is a good option, because in both instances I need to sit there and click away at the machine.
Even better maybe, if a player reaches a certain level in their account then they can choose to take the place of NPCs throughout the game, and as they level up their main account, they can get more options in the NPCs, example:
lvl 10-20 they can be some random NPC(monster) throughout the early world
lvl 21-30 they can also become NPC boss characters (whatever the stronger things in quests)
31-40 any non quest/non endgame NPC in the world
41-50 any quest NPC
51-59 any endgame NPC
60 "Quest Master" (could design quests for players to accomplish, like "guide me through the molten core to the far side and back without me dying and I'll give you this")
Additionally devise a voting system for who can get to be what NPC so high level guilds can vote who becomes what NPC (so better people can do it more often).
Mac refers to the fact that it is apple hardware. You could buy any ppc and install Apple's OS on it (like a bebox), but you were not suppossed to call it a mac (at least this is how I understood it).
The only thing that would cost money would be time and creativity. Someone would need to actually move things away from the duplication machine(s). And anything new would need to be created without the machine.
I believe the grandparent was making fun of the OP.
On that note, correct spelling and grammar couldn't hurt the cause (and it will probably help).
Scott 'Gallenite' Hartsman, Senior Producer for Everquest 2, has announced the pending combination of ten servers with ten other others. Normally, this sort of announcement would be met with immediate derision, a collectively vindictive sneering about a game that wasn't successful or is dying. However, because of when this combination is coming, and how it is being handled, I have a slightly different view." Additional commentary at Aggro Me.
A couple more things:
I thought the same thing.
ten other others???
fix that.
It may help new users even more to simply think of $ and @ as a description of the context you are writing in. Sort of like writing a sentence using plural words.
;
It helped me to think of @ as making your sentence plural. For example:
@names = (["John","Doe"],["Jane","Doe"],["Bobby","Smith"])
$name = ["Mary","Dayton"];
@names is a list of peoples first and last names, where $name is one person's first and last name.
1: there is no evolutionary problem with the Cambrian explosion (In fact evolution explains it very well, there were spaces to fit, so species evolved to fit the spaces)
2: people lie
3: ID doesn't make any discoveries
Most of all, I didn't prove God doesn't exist. I merely proved that one of those seven assumptions is false. If 1,2,3,5,6, and 7 are true then heaven cannot exist, as people cannot go there. If 1,2,4,5,6 and 7 are true then even god cannot know everything. If 1,2,3,4,6, and 7 then there exists a place where people are happier then heaven.
I actually assumed that god does exist, and reached a contradiction; this means that at least one of the assumptions is wrong.
I would rather God didn't exist, then any of the other conclusions that the arguments come to, but I cannot prove that a god doesn't exist with that argument.