I think US does have a right to take away GPS anytime they want. Did other country's citizen pay for the multi million dollars GPS sattelites? Did they pay even a cent on development of the system? No. But US residents did as did I with the taxes from our hard earned money.
US *does* have the right to take away GPS or anything they own. Telecom and internet access was from US, so if US believes that the recipient is not acting in the interest of US, US can do whatever they want. It is up to the recipient to prove that they are acting in US interest. It's a hard fact but beggers can't be choosers.
Also your analogy is false. US did not harboured the terrorists because if US knew of them, US would have kicked them out. These countries know that they have terrorists in their country but did nothing about them.
As for do I agree with what US did? No, I do not think shutting off telecom access is in the best interest of US and there is a better solution but US is perfectly within their right to do so here.
I believe the reason why US government is not sharing the evidence is for intelligence and national security issues not because "Americans would riot in the street if they knew what was really happening." If US government was to release the evidence, it will allow the Taliban and other hostile groups to figure out the intelligence capabilities of US as well as go on a spy witch hunt which probably hurt US intelligence capabilities. During the Cold War, CIA knew of many Soviet spies and plots but did nothing so that their sources in the Soviet KGB would not be compromised (not that is really did considering what ames did).
Furthermore, suspending parts of Constitution during war happens all the time. Abram Lincoln did that a lot during Civil War (although it was struck down in Supreme Court) as well as Roosevelt. It is all about check and balances between executive and the judicial at that point.
Also I belive that by negotiating with the Taliban, it gives that legitimacy - how can you have diplomacy with a government that you don't recognize?
While I share your skepticism with what US government is doing, I believe it is also naive not to be skeptical with what Taliban is saying. I believe that sharing evidence has no positives and all negatives. I belive that Taliban is lying when they say they will turn over bin Ladin when they get the evidence. Remeber, they have documented history of lying - yeah, Taliban saying let's solve this through diplomacy - I say bulls***.
Well, true if you are the owner of the entire program but what happens often is that your software has to interact with other programs. At that point, those programs may have been written beautifully or it could the worst piece of trash you ever seen. There could be missing specs or behaviors that were hacked it, etc etc. So in spite of how well you might program, there is few ways you personally can ensure that the entire project is bug free.
You could argue that if everyone followed the rule you specified, programs will be bug free but not everyone has the time-luxury to go over code in that depth - that is simply the reality. Also often you have to support legacy code because huge part of your company is depending on that.
So this isn't a flame but just saying that - yeah in a perfect world, programs will be bug free - but in our current world, it is almost impossible. I didn't make the rules, just trying to follow them.
Benefits depends on your situation
But one obvious benefit over the choices you gave are every request is handled by a single process vs single process for every cgi request - but this is a very old issue and php/asp/etc is good about it
Now benefits vs other web dev scripting languages such as php/asp/python is that java aspect of Tomcat. If you are building html-based, console based, java applet based applications simultaneously, you only have to code the main application part once and have a wrapper arround the ui aspect.
For example, if you could have a html page (served by Tomcat or other servlet engines) that does Foo and a server application that take Foo and produces Foo2 and later have another html page so that user can get Foo2, it makes more sense to do all of them in java to have a unified code base. You could possibly do this in perl or c++ but then you run into the program I described initially. I would not consider php/asp as good application languages (although you could run them in the console) so that rules out those choices.
Also, I personally find that Java servelets/applets/programs tend to be developed in a much more organized, semi-object oriented fashion. So maintenance tends to be easier over php/asp/perl where html and actual application overlap and you often get spaghetti code. Also as someone else has mentioned, Tomcat can be extended by modules like jetspeed that supposedly will speed up your development with very program-friendly libraries (although their documentation is horrendous - even compared to Tomcat). Also Java seems to have a lot of features that I use and works like xml parser (yes there are c++/perl parsers but java parsers seems to be better in memory leakage and abstraction), networking code, threading (yes I love java).
Those two are reasons I'm using Tomcat/java right now.
So if you like java, chances are, Tomcat would be a very good fit for you, if you hate java, then probably not. Your mileage may vary depending on situation.
No, that is NOT the point of the article. This article was about *corporate* support systems for linux and corporate support is a very different beast from user tech support.
Companies do not want to have their workers fixing their linux servers for most of their time but rather have them do company work. That is why they contract corporate support system.
Why would company like Nike want be an expert in fixing Linux problems? They would rather just have a very stable OS sitting in a corner and use the technology to market/develope better atheletic products. That is the point of corporate support system.
I don't think the author truly understands the issues or the words he is using. He claims that millions of computers will be more reliable than one big computer but what is his definition of reliable? Unless you are talking about non-serilizable or non-consistent clusters of computers, the point is mute. Consider a cluster of databases...are they more reliable? No, if one of the computer in the cluster fail, the entire cluster fails because of the basic unsolvability of group membership. And if he is talking about non-consistent clusters of computers, then how will answers be guaranteed?
Millions of CPU doing a job of a supercomputer...what do you think a supercomputer is? It is thousands of CPU clustered. Only difference is that a supercomputer is pre-packaged. To have million "regular" PC clusters, it simply won't be able to scale for most applications (with notable exception being SETI@HOME), since the cost of routing information quickly overwelms the useful information that is being passed arround.
He also claims that PCs are second class citizens and they need to be servers. But does he have any idea what this will entail? Think of the security issues...think of the privacy issues...think of the performance issue it will bring to the entire internet. Even if the cost of routing scales linearly, that still sucks because number of computers that are being connected is increasing exponentially.
I'm not here to dismiss p2p - I think p2p will have a great future for some applications. But I think the author needs to think hard about his statements - which I think has very little meaning at all. The article seems too much hot air religious fervor about p2p.
I wouldn't say SQL on NT will out-perform MySQL is just about every way. I personally was using SQL 7.0 on dual xeon 2g rdram and it got its ass kicked by mysql on the same system.
Actually you are right about MySQL. MySQL isn't great for everything and it doesn't have transaction support but SQL server is usually an overkill since SQL server is usually slow but has richer functionality.
I would say Postgres would be a better alternative.
Quantum Cryptography?
on
Stop, Light.
·
· Score: 1
Any ideas on how this will effect quantum cryptography?
The article didn't mention if they were able to perfectly reconstruct the photon. If they could then quantum cryptography is dead. But if that was true then heisenberg principle is also dead.
Isn't FPGA un-godly expensive to manufacture and slow as a sea cow?
I guess what you are proposing is to go to CISC instead of the current direction of RISC processors. Well, I'm sure there has been many discussions about merits of CISC and RISC proc but both has its advantages and disadvantages.
But I agree what is the purpose of a faster general purpose CPU? Do I really need a faster computer to do Word? Speech recognition and stuff may be cool but I really don't see any killer apps that will make me upgrade my computer (even games don't seem to stretch the capability of the computers as much as they used to)
Even then you run into inherent problems with distributed programs - latency and high cost of sync everything. Imagine running a 1000000 8088. Does this make this computer super fast? No, you have a system that might run a *distributed* program much faster than a typical computer but not much more for regular programs. Think about a typical distributed databases and wonder why there aren't too many of them. A truly replicated serializable database scales n^5 in the number of nodes! That's why there isn't too many massively replicated databases.
Distributed stuff is great (heck, my primary research is on distributed wireless crap) but I think there is too much hype and many people really don't understand the costs associated with it. Clusters are useful for *very* small number of situations.
Well, good point and cobalt's are probably over-priced but you may be missing the point. cobalts are rackmounts and you usually can't build rackmount computers offhand. I believe what you are paying for is the small form factor as well as the warantee (and someone to complain to if the box goes down)
No no no, multiple cpu will not give unlimited scalability nor will it give that much redundancy.
For example, just having two cpu instead of one does not mean you have twice as faster computer. There are inherent costs to having multiple cpu and even to do redundancy, it is very very expensive (i.e. sync-ing memory in shared memory model or sync-ing the buses or cooperating between the cpu's themselves). At some given point, the cluster will become too inefficient to use unless you are using specific applications that uses multiple chips.
Instead of thinking about chips, think about computers and how hard it is to have a distributed program.
I was working there for little while during the summer. The way they explained it Arbidopsis is a very genetic plant and can be thought of as the mother plant or something like that. Cornell's department was trying to see links between arabidopsis and the tomato plant.
And as someone else pointed out earlier, sequencing the half the job. The actual research goes in when the sequences are clustered and compared against other sequences. Anyway, good day for plant science.
Assets are depreciated over time and I'm sure their value is out of their books anyway.
However, it would be interesting if a company can claim "goodwill" asset for releasing an old program for free. I'm not an accountant so I don't know for sure...
Strange....approximate quering has been arround for quite a while in the database research community. If I recall correctly, Stanford and Wisconsin did research on approximate answers. Stanford is on approximate querying and Wisconsin paper did on approximate aggregation functions.
The papers are called
* Offering a Precision-Performance Tradeoff for Aggregation Quries over Replicated Data by Chris Olston and Jennifer Widom published in 1999
* Online Aggregation by Hellerstein, Hass and Wang published in 1997
And both papers refer to other older approximate querying process. So unless the patent is for something else, there are prior art for it (I couldn't figure out what they were saying in the patent - too much lawyer-speak)
I've tried JVM for palm and trust me, it's not that fun. I think for any small-device programs - at least for now - you want to use c/c++ using the libraries the manufacturer provides. That being said, WinCE blows nuts (at least for programming)
Well, most of the programmers out there are writing in c/c++ and java and I think that's why comparisons between those languages are important. Even if there is a super-dooper language foo, if no one uses it, it's mostly an academic discussion (and trust me, you don't want to argue about semantics and shit - I just finished a problem set about it and it hurts your brain).
On a side note, its kind of annoying that the discussion has turned into Java sucks/blows nuts or is da bomb. Look, Java is good for large subset of programs and it sucks for some applications. What the discussion should be is why is the JVM support in Linux crap (although much much better than BSD). It seems that most free JVMs in linux is far more unstable than free JVM in windows. It is true that blackdown.org is doing a decent job porting but performance-wise, I'd always use IBM jvm in windows rather than blackdown JVM in linux. (comercial JVM is another story though - for a crude benchmark look at http://www.volano.com/report.html)
On another side-note, the article mentioned is more specifically geared towards embedded-jvm and linux. READ THE ARTICLE BEFORE COMMENTING PLEASE. And it is true that for embedded stuff, Java is a not a good choice right now for various reasons. For embedded stuff you want strict memory management and more lower level controls which Java doesn't support. I disagree with the article saying that linux's main strength is in embedded stuff though, I always thought linux's main strength lied in server-side stuff.
Ummm, no. Scalability is always a problem in any network programs but especially so with p2p programs. Like the internet, gnutella has to exchange information about itself and others and eventually most of the information exchange becomes uselss information (redundant) and progress of query will be impeded by sheer number of messages. Look at internet right now - even though it is not collapsing, the main problem is the usless BCP packets are overwelming the network. So in all, gnutella does have a big scaling problem and no internet doesn't work too well (think reliability and scalability).
The problem with gnutella is not the bandwidth as the artile is saying. Granted, modem users don't have enough bandwidth but even if you get every gnutella users with t1 connections, the problem will lie in propagating information up and down the network.
I believe in a study done on internet routing, about 90% of the routing updates were useless and wasting the bandwidth.
So in a very superficial view, the problem would seem to be a bandwidth problem but the bandwidth problem is caused by the stupid routing information being passed arround and this is a problem with the internet as a whole, not just p2p applications.
Actually US had a personal "tactical" nuclear rockets. The idea was infantry will dig up holes go into the holes and launch a small nuclear device two miles ahead and wipe out the red army. Of course, this was not a good idea and good thing that it was never used.
I'm just wondering...considering programmers are considered one of the higher paying jobs, how is it that programmer's wage is held down? So a question is how much should a programmer be paid?
Slashdot Mirror
this post is karma whoring -
9 165 from previous story http://slashdot.org/article.pl?sid=01/11/01/131323 7
same post http://slashdot.org/comments.pl?sid=23266&cid=250
except for the sig
I think US does have a right to take away GPS anytime they want. Did other country's citizen pay for the multi million dollars GPS sattelites? Did they pay even a cent on development of the system? No. But US residents did as did I with the taxes from our hard earned money.
US *does* have the right to take away GPS or anything they own. Telecom and internet access was from US, so if US believes that the recipient is not acting in the interest of US, US can do whatever they want. It is up to the recipient to prove that they are acting in US interest. It's a hard fact but beggers can't be choosers.
Also your analogy is false. US did not harboured the terrorists because if US knew of them, US would have kicked them out. These countries know that they have terrorists in their country but did nothing about them.
As for do I agree with what US did? No, I do not think shutting off telecom access is in the best interest of US and there is a better solution but US is perfectly within their right to do so here.
Well, if were a government, then it would usually be war anyway. Taliban is not a legitimate government so your analogy is not valid.
I believe the reason why US government is not sharing the evidence is for intelligence and national security issues not because "Americans would riot in the street if they knew what was really happening." If US government was to release the evidence, it will allow the Taliban and other hostile groups to figure out the intelligence capabilities of US as well as go on a spy witch hunt which probably hurt US intelligence capabilities. During the Cold War, CIA knew of many Soviet spies and plots but did nothing so that their sources in the Soviet KGB would not be compromised (not that is really did considering what ames did).
Furthermore, suspending parts of Constitution during war happens all the time. Abram Lincoln did that a lot during Civil War (although it was struck down in Supreme Court) as well as Roosevelt. It is all about check and balances between executive and the judicial at that point.
Also I belive that by negotiating with the Taliban, it gives that legitimacy - how can you have diplomacy with a government that you don't recognize?
While I share your skepticism with what US government is doing, I believe it is also naive not to be skeptical with what Taliban is saying. I believe that sharing evidence has no positives and all negatives. I belive that Taliban is lying when they say they will turn over bin Ladin when they get the evidence. Remeber, they have documented history of lying - yeah, Taliban saying let's solve this through diplomacy - I say bulls***.
Well, true if you are the owner of the entire program but what happens often is that your software has to interact with other programs. At that point, those programs may have been written beautifully or it could the worst piece of trash you ever seen. There could be missing specs or behaviors that were hacked it, etc etc. So in spite of how well you might program, there is few ways you personally can ensure that the entire project is bug free.
You could argue that if everyone followed the rule you specified, programs will be bug free but not everyone has the time-luxury to go over code in that depth - that is simply the reality. Also often you have to support legacy code because huge part of your company is depending on that.
So this isn't a flame but just saying that - yeah in a perfect world, programs will be bug free - but in our current world, it is almost impossible. I didn't make the rules, just trying to follow them.
Benefits depends on your situation
But one obvious benefit over the choices you gave are every request is handled by a single process vs single process for every cgi request - but this is a very old issue and php/asp/etc is good about it
Now benefits vs other web dev scripting languages such as php/asp/python is that java aspect of Tomcat. If you are building html-based, console based, java applet based applications simultaneously, you only have to code the main application part once and have a wrapper arround the ui aspect.
For example, if you could have a html page (served by Tomcat or other servlet engines) that does Foo and a server application that take Foo and produces Foo2 and later have another html page so that user can get Foo2, it makes more sense to do all of them in java to have a unified code base. You could possibly do this in perl or c++ but then you run into the program I described initially. I would not consider php/asp as good application languages (although you could run them in the console) so that rules out those choices.
Also, I personally find that Java servelets/applets/programs tend to be developed in a much more organized, semi-object oriented fashion. So maintenance tends to be easier over php/asp/perl where html and actual application overlap and you often get spaghetti code. Also as someone else has mentioned, Tomcat can be extended by modules like jetspeed that supposedly will speed up your development with very program-friendly libraries (although their documentation is horrendous - even compared to Tomcat). Also Java seems to have a lot of features that I use and works like xml parser (yes there are c++/perl parsers but java parsers seems to be better in memory leakage and abstraction), networking code, threading (yes I love java).
Those two are reasons I'm using Tomcat/java right now.
So if you like java, chances are, Tomcat would be a very good fit for you, if you hate java, then probably not. Your mileage may vary depending on situation.
No, that is NOT the point of the article. This article was about *corporate* support systems for linux and corporate support is a very different beast from user tech support.
Companies do not want to have their workers fixing their linux servers for most of their time but rather have them do company work. That is why they contract corporate support system.
Why would company like Nike want be an expert in fixing Linux problems? They would rather just have a very stable OS sitting in a corner and use the technology to market/develope better atheletic products. That is the point of corporate support system.
I don't think the author truly understands the issues or the words he is using. He claims that millions of computers will be more reliable than one big computer but what is his definition of reliable? Unless you are talking about non-serilizable or non-consistent clusters of computers, the point is mute. Consider a cluster of databases...are they more reliable? No, if one of the computer in the cluster fail, the entire cluster fails because of the basic unsolvability of group membership. And if he is talking about non-consistent clusters of computers, then how will answers be guaranteed?
Millions of CPU doing a job of a supercomputer...what do you think a supercomputer is? It is thousands of CPU clustered. Only difference is that a supercomputer is pre-packaged. To have million "regular" PC clusters, it simply won't be able to scale for most applications (with notable exception being SETI@HOME), since the cost of routing information quickly overwelms the useful information that is being passed arround.
He also claims that PCs are second class citizens and they need to be servers. But does he have any idea what this will entail? Think of the security issues...think of the privacy issues...think of the performance issue it will bring to the entire internet. Even if the cost of routing scales linearly, that still sucks because number of computers that are being connected is increasing exponentially.
I'm not here to dismiss p2p - I think p2p will have a great future for some applications. But I think the author needs to think hard about his statements - which I think has very little meaning at all. The article seems too much hot air religious fervor about p2p.
I wouldn't say SQL on NT will out-perform MySQL is just about every way. I personally was using SQL 7.0 on dual xeon 2g rdram and it got its ass kicked by mysql on the same system.
Actually you are right about MySQL. MySQL isn't great for everything and it doesn't have transaction support but SQL server is usually an overkill since SQL server is usually slow but has richer functionality.
I would say Postgres would be a better alternative.
Any ideas on how this will effect quantum cryptography?
The article didn't mention if they were able to perfectly reconstruct the photon. If they could then quantum cryptography is dead. But if that was true then heisenberg principle is also dead.
Isn't FPGA un-godly expensive to manufacture and slow as a sea cow?
I guess what you are proposing is to go to CISC instead of the current direction of RISC processors. Well, I'm sure there has been many discussions about merits of CISC and RISC proc but both has its advantages and disadvantages.
But I agree what is the purpose of a faster general purpose CPU? Do I really need a faster computer to do Word? Speech recognition and stuff may be cool but I really don't see any killer apps that will make me upgrade my computer (even games don't seem to stretch the capability of the computers as much as they used to)
Even then you run into inherent problems with distributed programs - latency and high cost of sync everything. Imagine running a 1000000 8088. Does this make this computer super fast? No, you have a system that might run a *distributed* program much faster than a typical computer but not much more for regular programs. Think about a typical distributed databases and wonder why there aren't too many of them. A truly replicated serializable database scales n^5 in the number of nodes! That's why there isn't too many massively replicated databases.
Distributed stuff is great (heck, my primary research is on distributed wireless crap) but I think there is too much hype and many people really don't understand the costs associated with it. Clusters are useful for *very* small number of situations.
Well, good point and cobalt's are probably over-priced but you may be missing the point. cobalts are rackmounts and you usually can't build rackmount computers offhand. I believe what you are paying for is the small form factor as well as the warantee (and someone to complain to if the box goes down)
No no no, multiple cpu will not give unlimited scalability nor will it give that much redundancy.
For example, just having two cpu instead of one does not mean you have twice as faster computer. There are inherent costs to having multiple cpu and even to do redundancy, it is very very expensive (i.e. sync-ing memory in shared memory model or sync-ing the buses or cooperating between the cpu's themselves). At some given point, the cluster will become too inefficient to use unless you are using specific applications that uses multiple chips.
Instead of thinking about chips, think about computers and how hard it is to have a distributed program.
I was working there for little while during the summer. The way they explained it Arbidopsis is a very genetic plant and can be thought of as the mother plant or something like that. Cornell's department was trying to see links between arabidopsis and the tomato plant.
And as someone else pointed out earlier, sequencing the half the job. The actual research goes in when the sequences are clustered and compared against other sequences. Anyway, good day for plant science.
Not really,
Assets are depreciated over time and I'm sure their value is out of their books anyway.
However, it would be interesting if a company can claim "goodwill" asset for releasing an old program for free. I'm not an accountant so I don't know for sure...
Strange....approximate quering has been arround for quite a while in the database research community. If I recall correctly, Stanford and Wisconsin did research on approximate answers. Stanford is on approximate querying and Wisconsin paper did on approximate aggregation functions.
The papers are called
* Offering a Precision-Performance Tradeoff for Aggregation Quries over Replicated Data by Chris Olston and Jennifer Widom published in 1999
* Online Aggregation by Hellerstein, Hass and Wang published in 1997
And both papers refer to other older approximate querying process. So unless the patent is for something else, there are prior art for it (I couldn't figure out what they were saying in the patent - too much lawyer-speak)
I've tried JVM for palm and trust me, it's not that fun. I think for any small-device programs - at least for now - you want to use c/c++ using the libraries the manufacturer provides. That being said, WinCE blows nuts (at least for programming)
Well, most of the programmers out there are writing in c/c++ and java and I think that's why comparisons between those languages are important. Even if there is a super-dooper language foo, if no one uses it, it's mostly an academic discussion (and trust me, you don't want to argue about semantics and shit - I just finished a problem set about it and it hurts your brain).
On a side note, its kind of annoying that the discussion has turned into Java sucks/blows nuts or is da bomb. Look, Java is good for large subset of programs and it sucks for some applications. What the discussion should be is why is the JVM support in Linux crap (although much much better than BSD). It seems that most free JVMs in linux is far more unstable than free JVM in windows. It is true that blackdown.org is doing a decent job porting but performance-wise, I'd always use IBM jvm in windows rather than blackdown JVM in linux. (comercial JVM is another story though - for a crude benchmark look at http://www.volano.com/report.html)
On another side-note, the article mentioned is more specifically geared towards embedded-jvm and linux. READ THE ARTICLE BEFORE COMMENTING PLEASE. And it is true that for embedded stuff, Java is a not a good choice right now for various reasons. For embedded stuff you want strict memory management and more lower level controls which Java doesn't support. I disagree with the article saying that linux's main strength is in embedded stuff though, I always thought linux's main strength lied in server-side stuff.
Ummm, no. Scalability is always a problem in any network programs but especially so with p2p programs. Like the internet, gnutella has to exchange information about itself and others and eventually most of the information exchange becomes uselss information (redundant) and progress of query will be impeded by sheer number of messages. Look at internet right now - even though it is not collapsing, the main problem is the usless BCP packets are overwelming the network. So in all, gnutella does have a big scaling problem and no internet doesn't work too well (think reliability and scalability).
The problem with gnutella is not the bandwidth as the artile is saying. Granted, modem users don't have enough bandwidth but even if you get every gnutella users with t1 connections, the problem will lie in propagating information up and down the network.
I believe in a study done on internet routing, about 90% of the routing updates were useless and wasting the bandwidth.
So in a very superficial view, the problem would seem to be a bandwidth problem but the bandwidth problem is caused by the stupid routing information being passed arround and this is a problem with the internet as a whole, not just p2p applications.
Actually US had a personal "tactical" nuclear rockets. The idea was infantry will dig up holes go into the holes and launch a small nuclear device two miles ahead and wipe out the red army. Of course, this was not a good idea and good thing that it was never used.
I'm just wondering...considering programmers are considered one of the higher paying jobs, how is it that programmer's wage is held down? So a question is how much should a programmer be paid?