The real problem is that under a heavy traffic storm the server is buried in an avalanche of initial key exchanges. As the first few sockets are hogging all the CPU during setup, a huge backlog of connetions gathers in the queue. The server will die.
Most of the hardware crypto devices are utterly useless for anything other than IPSec VPN, where the number of keys required is measured in single digits. This includes the Niagara T2. Hardware crypto sounds good on paper until you realize that the keyspace on the chip is limited and the programming model for loading keys and connection state was designed by a hardware guy who never did any programming in his whole life. Beyond a certain number of key pairs, programming the crypto engine becomes more expensive than simply using OpenSSL on the main CPU.
Oh, hell yes. The initial key exchange to start an https connection is wonderfully expensive.
Note to web "masters" everywhere: you cannot distribute huge files to millions of people using MySQL and SSL. Full stop. Upload that shit to Amazon S3 or Akamai or YouTube or _anything_ other than mediawiki. Thanks!
Sure, but you can replace ptrace() at run time from within GDB. This has _always_ been necessary ever since the iTunes Music Store was invented, way before DTrace landed.
We already have all those things. We have public databases of donations to politicians (fec.gov), public databases of members of corporate boards and beneficial shareholders (sec.gov), and fully open information about bills sponsored by or voted on (thomas.loc.gov). What else do you want?
Well you're right, I was looking at an older TI catalog, but they still list budgetary pricing for this dual-phy peripheral interface at $10 in quantity.
It's relevant because it's ridiculous to trumpet that you have accomplished something green by eliminating 0.00001% of your environmental impact. Every member of congress flies across the nation twice a week. The executive branch is currently in the business of buring five million gallons of gas per day in a war. So I don't want to hear about their absurd petty greenwashing.
Paper is a renewable resource like rice or strawberries. It's grown on farms like any other crop. They aren't out there chopping down ancient redwoods for paper.
The issue of going paperless to save the planet was always bogus. Driving a mile in a car has a much larger impact on the planet than printing a page.
This is the stupidest and most-wrong, and also the most commonly believed, reason for FireWire's relative obscurity. Sure, there was a royalty for the FireWire name, but that hardly mattered in the great scheme of things. Early FireWire ASICs cost $50. Even today, a FireWire interface will set you back $20. USB interfaces are in the vicinity of $1. On top of that, your device must implement a complicated peer-to-peer software protocol. This costs even more. So the $1 royalty was only a tiny part of FireWire's overall higher cost.
If you want to find out exactly how complicated the FireWire protocol is, just look in the Linux kernel. The 1394 subsystem is a huge piece of code, and it's also by far the lowest quality of all the major subsystems. Compare to the USB subsystem, which works perfectly.
In my admittedly limited experience, any user account can do some pretty scary stuff in Windows XP. I once was surprised to find out that I could load a firmware update onto a Plextor DVD burner using the guest account on a Windows XP machine. If you can program device firmware you can obviously subvert the entire operating system. I was appalled, and I showed it to the local Windows sysadmin, and he was appalled. It seemed to be a bit of clever programming on the part of the Plextor people, and there did not seem to be any way to defend against it.
Yeah right. Do you think the virus idiots know how to program a virus into 512 bytes these days? I've seen self-styled viruses that are carrying around msvcrt.dll. Those guys should be embarrassed.
I just profiled your page with Venkman and it seems that > 96% of the CPU time is spent in document.getElementsByName. Were you trying to prove my point?
I think this "benchmark" is deeply weird. It only exercises the pure execution paths, while pretty much ignoring all of the data structures that make a web page work. Every web app I've written or tried to optimize is limited not by time spent in javascript, but rather time spent manipulating the dom and drawing.
I guess there's value in such a benchmark, but it goes against the conventional wisdom of Amdahl's Law. If JS execution accounts for only 10% of the runtime of your application, it will be of little value to make JS 20% faster. You must concentrate on the other 90%.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
It's not hard at all. Slurp it up into a DOM. At this point, it becomes an object and ceases to be a stupid string. You can then walk the tree removing nodes that are not allowed (example: in a forum post you can remove the script tag while ignoring bold and italics.)
I don't know why people are stupid about this. It's true that you probably can't do it with a regex. That's why $GOD gave us the DOM.
That's why the whole idea is absurd. Some software acting on my behalf sends a request to your software. Your software can choose to answer the request and how, or to ignore it. As a citizen who has not had the opportunity to undergo the brain-erasure procedure they use at law schools, I fail to see where the contract attaches.
You might find it odd, but there's a lot of lawyers out there (almost all of them, in my experience) who seriously claim that the Terms of Service linked at the bottom of every commercial website. They say it's binding even if you've never read it, and even if it changes and you haven't read the changes. It's binding even if it's not linked from anywhere obvious.
Now, I realize that these people are idiots, and that probably their future involves a wall, their backs, and a revolution, but at present their counsel is widely respected among the holders of wealth and power. So when you say that robots.txt is "not a contract" you should talk to a lawyer about that. You'd be amazed at the things they say.
Industrial users are billed for their metered power consumption, divided by the measured power factor. So you bills can really escalate if you have a reactive load. That's why many industries employ power-factor-correcting equipment from companies like American Superconductor (despite the name, the mostly don't make superconductors).
The funny thing is that dozens of major biotech and pharma companies are headquartered in Switzerland precisely because in the recent past that nation did not recognize patents at all. Those companies which are now patent hard-liners were once patent free-loaders.
Try going out and getting a gigabit port with a gigabit commit and then get back to me on pricing. Yes, the per-megabit price scales in the favor of the customer, but only from 1 to 100 megabits. After that the price starts creeping up and then suddenly you find that there's actually only a few places in the world where you can even get a gigabit port, and even fewer people who will sell you a gigabit commit.
That's why I wondered whether they might have just offloaded the whole headache on Akamai or another CDN that's already well positioned for spamming out the bytes.
I'm sure they made a lot of money, but I bet the bandwidth costs were at least 20x greater than you claim. Not only would they need hundreds of terabytes of transfer to serve more than 1 million people a full album of music, they would need the majority of that transfer in the first day or the first few days, or in other words an aggregate transfer rate in excess of 1gbps, and servers capable of pushing that amount of data. On top of that they would need an e-commerce system for booking the orders.
I wonder if they just used Akamai to distribute the files?
Keep piling it on. When you say "sub-megahertz" you only further compound your error. The important bit is not, and has never been, the symbol rate. The important thing is the rise time, and today's transmitters have rise times measured in 100s of picoseconds. So any cable is likely to distort this signal, some more than others, and reflection can be a serious problem. That's why you have to treat these cables as transmission lines. Even if your equipment happens to have expensive transmitters with slew-rate limiting, you are still likely to be looking at signals in the 50MHz area.
It doesn't help that S/PDIF is not exactly low-voltage. Signals levels are in the vicinity of 700mV. You try pushing an edge that fast on a cable that looks like a gigantic unterminated antenna.
Your mind experiment seems impressive, if you have never read the literature on this topic. Dunn and Hawksford showed long ago that 100ps jitter is audible in blind listening tests. Not only that, they derived the equations for calculating harmonic distortion based on jitter, using real mathematics, not your sheer conjecture. And, again, you have totally misrepresented my point by focusing on bit errors, which are of course not common in consumer electronics.
Here's the point, once again, for those who seem intent on ignoring it. You cannot simply focus on the magnitude of timing errors. In D-A conversion the spectrum of phase noise is mapped, directly, onto the output. If you have a 120Hz jitter, you will have a 120Hz peak on your output spectrum, which will be audible, depending on the magnitude. Audible magnitudes are on the order of 1ns, not 1us. Since you are a ham operator, I'm sure I don't need to point out that 120Hz is an extremely common stray magnetic field. Also you should have realized when writing that lengthy non-explanation that a 10us timing error would be so gross as to unlock the receiver. For you to claim that such an error would be inaudible is absurd on its face.
The only thing that's perfectly clear is that nobody commenting in this thread aside from myself has ever built, measured, and seriously listened to digital audio equipment. The upthread mind experiments are nothing more than mental masturbation and ignore all the relevant literature accumulated over the quarter-century since the invention of the art. My only consolation is that this impressive display of ignorance has been captured by Google for all time.
If you're making your own cables, then you are likely to be way ahead of the game anyway. But since you asked, Dunn and Hawksford found that jitter of 100ps at 20kHz was audible in controlled listening tests. You can read more about that in their AES paper, or in Digital Interface Handbook (2003). Proceedings of the 111th AES says that your basic consumer S/PDIF receiver has jitter of 4600ps. Therefore, your average consumer digital interconnect has audible problems. You might argue that the remainder of your "basic consumer receiver" has other problems which swamp this, and you would probably be right about that. But the original poster, way upthread, who tried to imply that digital is digital and therefore perfect, is dead wrong. In reality it's much more difficult to make a really good digital system compared to the difficulty of a really good analog one.
Wrong again. Did you read the paper? He's inducing jitter into the test circuit using a magnetic loop around the S/PDIF cable. The result is clearly visible in the output distortion. Here's another peer-reviewed paper where the same test circuit is used. See page 3 for the test jig. http://www.scientificonversion.com/AES2001.pdf
Slashdot Mirror
Here's a hint: if something has a half-life of 4.5 /billion/ years, that substance is not dangerously radioactive.
The real problem is that under a heavy traffic storm the server is buried in an avalanche of initial key exchanges. As the first few sockets are hogging all the CPU during setup, a huge backlog of connetions gathers in the queue. The server will die.
Most of the hardware crypto devices are utterly useless for anything other than IPSec VPN, where the number of keys required is measured in single digits. This includes the Niagara T2. Hardware crypto sounds good on paper until you realize that the keyspace on the chip is limited and the programming model for loading keys and connection state was designed by a hardware guy who never did any programming in his whole life. Beyond a certain number of key pairs, programming the crypto engine becomes more expensive than simply using OpenSSL on the main CPU.
Oh, hell yes. The initial key exchange to start an https connection is wonderfully expensive.
Note to web "masters" everywhere: you cannot distribute huge files to millions of people using MySQL and SSL. Full stop. Upload that shit to Amazon S3 or Akamai or YouTube or _anything_ other than mediawiki. Thanks!
Sure, but you can replace ptrace() at run time from within GDB. This has _always_ been necessary ever since the iTunes Music Store was invented, way before DTrace landed.
We already have all those things. We have public databases of donations to politicians (fec.gov), public databases of members of corporate boards and beneficial shareholders (sec.gov), and fully open information about bills sponsored by or voted on (thomas.loc.gov). What else do you want?
Well you're right, I was looking at an older TI catalog, but they still list budgetary pricing for this dual-phy peripheral interface at $10 in quantity.
http://focus.ti.com/docs/prod/folders/print/tsb43aa82a.html
If you're looking at an expansion card with multiple ports it probably has only 1 ASCI (if it has 4 ports or fewer).
It's relevant because it's ridiculous to trumpet that you have accomplished something green by eliminating 0.00001% of your environmental impact. Every member of congress flies across the nation twice a week. The executive branch is currently in the business of buring five million gallons of gas per day in a war. So I don't want to hear about their absurd petty greenwashing.
Paper is a renewable resource like rice or strawberries. It's grown on farms like any other crop. They aren't out there chopping down ancient redwoods for paper.
The issue of going paperless to save the planet was always bogus. Driving a mile in a car has a much larger impact on the planet than printing a page.
This is the stupidest and most-wrong, and also the most commonly believed, reason for FireWire's relative obscurity. Sure, there was a royalty for the FireWire name, but that hardly mattered in the great scheme of things. Early FireWire ASICs cost $50. Even today, a FireWire interface will set you back $20. USB interfaces are in the vicinity of $1. On top of that, your device must implement a complicated peer-to-peer software protocol. This costs even more. So the $1 royalty was only a tiny part of FireWire's overall higher cost.
If you want to find out exactly how complicated the FireWire protocol is, just look in the Linux kernel. The 1394 subsystem is a huge piece of code, and it's also by far the lowest quality of all the major subsystems. Compare to the USB subsystem, which works perfectly.
In my admittedly limited experience, any user account can do some pretty scary stuff in Windows XP. I once was surprised to find out that I could load a firmware update onto a Plextor DVD burner using the guest account on a Windows XP machine. If you can program device firmware you can obviously subvert the entire operating system. I was appalled, and I showed it to the local Windows sysadmin, and he was appalled. It seemed to be a bit of clever programming on the part of the Plextor people, and there did not seem to be any way to defend against it.
Yeah right. Do you think the virus idiots know how to program a virus into 512 bytes these days? I've seen self-styled viruses that are carrying around msvcrt.dll. Those guys should be embarrassed.
I just profiled your page with Venkman and it seems that > 96% of the CPU time is spent in document.getElementsByName. Were you trying to prove my point?
I think this "benchmark" is deeply weird. It only exercises the pure execution paths, while pretty much ignoring all of the data structures that make a web page work. Every web app I've written or tried to optimize is limited not by time spent in javascript, but rather time spent manipulating the dom and drawing.
I guess there's value in such a benchmark, but it goes against the conventional wisdom of Amdahl's Law. If JS execution accounts for only 10% of the runtime of your application, it will be of little value to make JS 20% faster. You must concentrate on the other 90%.
It's not hard at all. Slurp it up into a DOM. At this point, it becomes an object and ceases to be a stupid string. You can then walk the tree removing nodes that are not allowed (example: in a forum post you can remove the script tag while ignoring bold and italics.)
I don't know why people are stupid about this. It's true that you probably can't do it with a regex. That's why $GOD gave us the DOM.
That's why the whole idea is absurd. Some software acting on my behalf sends a request to your software. Your software can choose to answer the request and how, or to ignore it. As a citizen who has not had the opportunity to undergo the brain-erasure procedure they use at law schools, I fail to see where the contract attaches.
You might find it odd, but there's a lot of lawyers out there (almost all of them, in my experience) who seriously claim that the Terms of Service linked at the bottom of every commercial website. They say it's binding even if you've never read it, and even if it changes and you haven't read the changes. It's binding even if it's not linked from anywhere obvious.
Now, I realize that these people are idiots, and that probably their future involves a wall, their backs, and a revolution, but at present their counsel is widely respected among the holders of wealth and power. So when you say that robots.txt is "not a contract" you should talk to a lawyer about that. You'd be amazed at the things they say.
Industrial users are billed for their metered power consumption, divided by the measured power factor. So you bills can really escalate if you have a reactive load. That's why many industries employ power-factor-correcting equipment from companies like American Superconductor (despite the name, the mostly don't make superconductors).
The funny thing is that dozens of major biotech and pharma companies are headquartered in Switzerland precisely because in the recent past that nation did not recognize patents at all. Those companies which are now patent hard-liners were once patent free-loaders.
Try going out and getting a gigabit port with a gigabit commit and then get back to me on pricing. Yes, the per-megabit price scales in the favor of the customer, but only from 1 to 100 megabits. After that the price starts creeping up and then suddenly you find that there's actually only a few places in the world where you can even get a gigabit port, and even fewer people who will sell you a gigabit commit.
That's why I wondered whether they might have just offloaded the whole headache on Akamai or another CDN that's already well positioned for spamming out the bytes.
I'm sure they made a lot of money, but I bet the bandwidth costs were at least 20x greater than you claim. Not only would they need hundreds of terabytes of transfer to serve more than 1 million people a full album of music, they would need the majority of that transfer in the first day or the first few days, or in other words an aggregate transfer rate in excess of 1gbps, and servers capable of pushing that amount of data. On top of that they would need an e-commerce system for booking the orders.
I wonder if they just used Akamai to distribute the files?
Keep piling it on. When you say "sub-megahertz" you only further compound your error. The important bit is not, and has never been, the symbol rate. The important thing is the rise time, and today's transmitters have rise times measured in 100s of picoseconds. So any cable is likely to distort this signal, some more than others, and reflection can be a serious problem. That's why you have to treat these cables as transmission lines. Even if your equipment happens to have expensive transmitters with slew-rate limiting, you are still likely to be looking at signals in the 50MHz area.
It doesn't help that S/PDIF is not exactly low-voltage. Signals levels are in the vicinity of 700mV. You try pushing an edge that fast on a cable that looks like a gigantic unterminated antenna.
Your mind experiment seems impressive, if you have never read the literature on this topic. Dunn and Hawksford showed long ago that 100ps jitter is audible in blind listening tests. Not only that, they derived the equations for calculating harmonic distortion based on jitter, using real mathematics, not your sheer conjecture. And, again, you have totally misrepresented my point by focusing on bit errors, which are of course not common in consumer electronics.
Here's the point, once again, for those who seem intent on ignoring it. You cannot simply focus on the magnitude of timing errors. In D-A conversion the spectrum of phase noise is mapped, directly, onto the output. If you have a 120Hz jitter, you will have a 120Hz peak on your output spectrum, which will be audible, depending on the magnitude. Audible magnitudes are on the order of 1ns, not 1us. Since you are a ham operator, I'm sure I don't need to point out that 120Hz is an extremely common stray magnetic field. Also you should have realized when writing that lengthy non-explanation that a 10us timing error would be so gross as to unlock the receiver. For you to claim that such an error would be inaudible is absurd on its face.
The only thing that's perfectly clear is that nobody commenting in this thread aside from myself has ever built, measured, and seriously listened to digital audio equipment. The upthread mind experiments are nothing more than mental masturbation and ignore all the relevant literature accumulated over the quarter-century since the invention of the art. My only consolation is that this impressive display of ignorance has been captured by Google for all time.
If you're making your own cables, then you are likely to be way ahead of the game anyway. But since you asked, Dunn and Hawksford found that jitter of 100ps at 20kHz was audible in controlled listening tests. You can read more about that in their AES paper, or in Digital Interface Handbook (2003). Proceedings of the 111th AES says that your basic consumer S/PDIF receiver has jitter of 4600ps. Therefore, your average consumer digital interconnect has audible problems. You might argue that the remainder of your "basic consumer receiver" has other problems which swamp this, and you would probably be right about that. But the original poster, way upthread, who tried to imply that digital is digital and therefore perfect, is dead wrong. In reality it's much more difficult to make a really good digital system compared to the difficulty of a really good analog one.
Wrong again. Did you read the paper? He's inducing jitter into the test circuit using a magnetic loop around the S/PDIF cable. The result is clearly visible in the output distortion. Here's another peer-reviewed paper where the same test circuit is used. See page 3 for the test jig. http://www.scientificonversion.com/AES2001.pdf