I'm not sure what you're trying to say there. I asked a couple of questions: How many gas cars light on fire as opposed to being lit on fire? How can electric cars be made safer?
It's not clear what you're trying to say, so tell me if I have this right:
You have no idea what the answer is to either question, but "Tesla comes out on top". Why? Because Tesla man! Fuck yeah Tesla motherfucker! Tesla kicks ass man!
>. Flex where? If it's up against the battery, when it flexes it will compress the cells, causing exactly the kind of damage that causes fires...
Intuitively, you'd think to make a car safer, you'd make it stronger. In fact, you reduce G forces by designing it to crush - crumple zones. How can the shielding or battery positioning be improved? I don't know, but I hope Tesla's engineers are asking those questions.
At Texas Transportation Institute (part of the agency I work for) they're still crash testing gas cars to figure out how safety can be improved. The same needs to be done with Tesla cars, that's all.
Yes, you just need to redo http. While you're redoing http, you make several improvements. As you improve http, you realize the biggest performance issues for http come from the fact that it's limited by the requirement that sends and recieves via an ancient protocol that wasn't designed to carry http. Http doesn't run atop TCP because it's a good fit - on runs atop http because that's what was available.
I think it's more like designing automobiles 3.0, designed to go 300 MPH, and realizing that if you want 300 MPH vehicles, you might need to make some significant changes to highway design.
The "all car fires" stat includes dropped cigarettes that smolder, cars intentionally set on fire, etc. How many regular cars light on fire on the highway after running over a debris such as a hitch?
Also, how many do you want to have on fire? How many would ignite if there was a shield that would flex rather than puncture?
Thank for that info, and for making your test scripts available on Github. I'm curious* what were the results of web page tests? Obviously a typical web page with CSS files, Javascript files, images, etc. is much different from a monolithic 10 MB file.
* curious, but not curious enough to run the tests for myself.
As I understand it, QUIC is largely about multiplexing - downloading all 35 files needed for a page concurrently. The test was the opposite of what QUIC is designed for
TCP handles one file at at a time* - first download the html, then the logo, then the background, then the first navigation button....
QUIC gets all of those page elements at the same time, over a single connection. The problem with TCP and the strength of QUIC is exactly what TFA chose NOT to test. By using a single 10 MB file, their test is the opposite of web browsing and doesn't test the innovations in QUIC.
* browsers can negotiate multiple TCP connections, which is a slow way to retrieve many small files.
Did you copy / paste the whole review? How long was it? If it was more than a few sentences, you probably should have linked to the full review and copied only a few sentences, or better yet, a few key phrases, like this:
I agree with Jody Bruchon, who says " It's unfortunate that there aren't SLAPP laws in every state". Write our own opinion, blah, blah, blah.
Blah, blah, Bruchon is incorrect is the assertion that "the person with the most money always wins" because...
You say you copied the review "so I could refute it ", but you don't have to copy and paste an entire work in order to refute it. I can refute Obama's latest speech without copying and pasting the entire thing.
Of course if the original review was only two sentences, my comment doesn't apply.
In fact they MUST pick and choose. To avoid losing their mark, they need to be proactive about instances that could be considered infringement. They can allow certain users and decline others. What they can't do, under the law, is ignore potential infringement - they are supposed to either allow it or object to it. One way they do that is through the published policy, which grants people the right to use their trademark in specific ways:
It's been an interesting conversation, thanks. I believe I do understand your point, I just have a different view.
I understand you to be saying that a CD "is" a bunch of numbers. That's true, whether it's a music CD or a software CD. However, I'm of the opinion that it's myopic to view the contents of the CD as "a bunch of numbers". Mozart isn't a bunch of numbers. To say that's what music IS, one misses the essence of the thing.
Similarly, my wife IS a pile of hydrogen and oxygen. She's defined mostly by her DNA, a mathematical sequence. To look at it that way is to be absolutely blind to what my wife truly is, in my opinion.
Anyway, thanks again for an interesting conversation. I look forward to reading your thoughts on the next topic.
Ps - you're independent weak encryption is not hard to figure out. Let's say you use it for some PHP script on your web site. Well, it's on a publicly accessible web server, and it's friggin PHP, so I'll have the source code in ten minutes. As soon as I see the source, not only do I know what weak algorithms you're using, but I can also see the common flaws in your particular implementation.
A case in point - A common "do it my own way" idea is to stack hash algorithms. Take a sha256 of the data, an MD5 of that, and RC4 that or whatever. Well, stacking hashes results in a hash that's provably WEAKER than the weakest hash in the chain. Each step you take to make it stronger actually makes it weaker.
I'm a total DIYer. I'd even DIY stitching a cut. There are two things you shouldn't DIY - high explosives and information security. (But low explosives are fun.)
The best way to deal with strong encryption is to go around it, to use the back door. Those are the flaws an audit would reveal, issues not with the actual encryption, which is a fairly small part of the software, but with the other 90% of the code .
The encryption itself has been analyzed, and will continue to be analyzed, outside of Truecrypt, which is just one of many packages that use the same encryption.
We know that the current version of GCC doesn't have the "Ken Thompson" trojan. The original version could have, theoretically a but it couldn't survive so many versions. Also, gdb would have revealed it long ago. Maybe gcc also trojans gdb? And ptrace, and... You have to imagine that the author wrote specialized trojans for a bunch of programs that hadn't been created yet, and hid them all in a few kilobytes. That's beyond impossible, even for the best programmer in the world.
As nasty as that is, I'm pleasantly surprised Slashdot (Dice) ran this. Somebody has character to approve this story. I hope it doesn't get them fired for telling the truth.
> I am saying that the PRODUCT is math, not the thought process that goes into it.
A PRODUCT is something people buy. I suggest that one of the greatest software makers of all time*, Steve Jobs, would tell us that the product is anything but math. The math behind Mac is mostly the same as the math behind FreeBSD. The difference is the artistic aspects - design, etc. They are the same math, are they the same product? One is a bestselling product, the other hasn't even become a product at all.
Steve Jobs did a lot of stuff that annoys me, but he did it very well.
Many coders who work in high level languages don't know what an "algorithm" is, so I disagree with the idea that they are professional algorithm designers.
A naive implementation of an interpreter is "algorithms" - generic functions for converting any pattern of type A into type B. As you said, long ago someone did the math, just as long ago someone designed the (mathematical) musical scale. Today's musicians and developers don't do a lot of math.
Designing a user interface that's beautiful, simple for beginners, and powerful for power users isn't a mathematical equation, it's an art, left-brain activity. If it were a math I could do it. My development team consists of me (the algorithms guy) and three people with art degrees. I can't do their job, not even a little bit. They can't do fractions, that's how mathematical they are. To make software requires all four of us - one math person and three people who have no math skills at all.
My 25% of a project is to take their art and manipulate it mathematically.
> not invented by humans, not the product of human activity. It's like saying the earth or the sun or Newton's laws of gravity should be patentable.
A = A is like the law of gravity, and not patentable. An elevator is an invention based on gravity, and is patentable. An entirely new type of spam filter is a new invention, based on math.
It seems to me that the laws of physics and the laws of mathematics should be treated the same. That also happens to be current law.
New inventions which make use of those laws similarly should be treated the same.
You say people could "disguise the laws" in a patent. You could just as easily disguise Newton's laws. There's no difference there between a machine built of wood and a machine built of pits in an optical disk. You're pretending there is a difference where there is none.
Since the laws of physics are not only similar to the laws of math, but in some cases the exact same laws, there are two arguments one can logically make: invalid patents should be reduced (such as by allowing punitive damages in a counter-claim against a crap patent). Nothing based on physics, and therefore nothing at all, should be patentable.
For me, I prefer option #1. If you sue on a patent and the court rules your patent is frivolous because it's obvious or whatever, you have to pay treble damages. That would reduce dumb patent suits and the motivation to file for dumb patents.
I see you didn't bother to read one word of my post before replying. Does the computer in the hotel business center have ssh installed? No. Does a borrowed phone have ssh? No.
Slashdot Mirror
I'm not sure what you're trying to say there.
I asked a couple of questions:
How many gas cars light on fire as opposed to being lit on fire?
How can electric cars be made safer?
It's not clear what you're trying to say, so tell me if I have this right:
You have no idea what the answer is to either question, but "Tesla comes out on top". Why? Because Tesla man! Fuck yeah Tesla motherfucker! Tesla kicks ass man!
Do I have that about right?
>. Flex where? If it's up against the battery, when it flexes it will compress the cells, causing exactly the kind of damage that causes fires...
Intuitively, you'd think to make a car safer, you'd make it stronger. In fact, you reduce G forces by designing it to crush - crumple zones. How can the shielding or battery positioning be improved? I don't know, but I hope Tesla's engineers are asking those questions.
At Texas Transportation Institute (part of the agency I work for) they're still crash testing gas cars to figure out how safety can be improved. The same needs to be done with Tesla cars, that's all.
Yeah, I assume that's obvious. Send the html first, then css, js, and images concurrently.
Also, I hope you don't browse too many pages with 20MB of images. :)
Yes, you just need to redo http. While you're redoing http, you make several improvements.
As you improve http, you realize the biggest performance issues for http come from the fact that it's limited by the requirement that sends and recieves via an ancient protocol that wasn't designed to carry http. Http doesn't run atop TCP because it's a good fit - on runs atop http because that's what was available.
I think it's more like designing automobiles 3.0, designed to go 300 MPH, and realizing that if you want 300 MPH vehicles, you might need to make some significant changes to highway design.
The "all car fires" stat includes dropped cigarettes that smolder, cars intentionally set on fire, etc.
How many regular cars light on fire on the highway after running over a debris such as a hitch?
Also, how many do you want to have on fire? How many would ignite if there was a shield that would flex rather than puncture?
> You're conflating HTTP with TCP.
I'm discussing how HTTP over TCP works, in contrast to how it works over QUIC.
TCP provides one stream, which when used with HTTP means one file.
QUIC provides multiple concurrent streams specifically so that http can retrieve multiple concurrent files.
Thank for that info, and for making your test scripts available on Github.
I'm curious* what were the results of web page tests? Obviously a typical web page with CSS files, Javascript files, images, etc. is much different from a monolithic 10 MB file.
* curious, but not curious enough to run the tests for myself.
As I understand it, QUIC is largely about multiplexing - downloading all 35 files needed for a page concurrently. The test was the opposite of what QUIC is designed for
TCP handles one file at at a time* - first download the html, then the logo, then the background, then the first navigation button ....
QUIC gets all of those page elements at the same time, over a single connection. The problem with TCP and the strength of QUIC is exactly what TFA chose NOT to test. By using a single 10 MB file, their test is the opposite of web browsing and doesn't test the innovations in QUIC.
* browsers can negotiate multiple TCP connections, which is a slow way to retrieve many small files.
Did you copy / paste the whole review? How long was it? If it was more than a few sentences, you probably should have linked to the full review and copied only a few sentences, or better yet, a few key phrases, like this:
I agree with Jody Bruchon, who says " It's unfortunate that there aren't SLAPP laws in every state". Write our own opinion, blah, blah, blah. ...
Blah, blah, Bruchon is incorrect is the assertion that "the person with the most money always wins" because
You say you copied the review "so I could refute it ", but you don't have to copy and paste an entire work in order to refute it. I can refute Obama's latest speech without copying and pasting the entire thing.
Of course if the original review was only two sentences, my comment doesn't apply.
> They cant pick and choose.
In fact they MUST pick and choose. To avoid losing their mark, they need to be proactive about instances that could be considered infringement.
They can allow certain users and decline others. What they can't do, under the law, is ignore potential infringement - they are supposed to either allow it or object to it.
One way they do that is through the published policy, which grants people the right to use their trademark in specific ways:
http://www.canonical.com/intellectual-property-policy
One thing their policy explicitly grants permission for is:
You can use the Trademarks in discussion, commentary, criticism or parody, provided that you do not imply endorsement by Canonical.
It seems to me this use was already authorized under that published statement of permission.
The system above IS in use on some tranny sites!
I think I'd rather use a test that just asks me to click on the hot women real quick.
http://bettercgi.com/images/face-turing-captcha.png
It's been an interesting conversation, thanks.
I believe I do understand your point, I just have a different view.
I understand you to be saying that a CD "is" a bunch of numbers.
That's true, whether it's a music CD or a software CD.
However, I'm of the opinion that it's myopic to view the contents of the CD as "a bunch of numbers". Mozart isn't a bunch of numbers. To say that's what music IS, one misses the essence of the thing.
Similarly, my wife IS a pile of hydrogen and oxygen. She's defined mostly by her DNA, a mathematical sequence. To look at it that way is to be absolutely blind to what my wife truly is, in my opinion.
Anyway, thanks again for an interesting conversation. I look forward to reading your thoughts on the next topic.
That's a good point and I retract my comment in the context of console servers.
The point I had in mind is that although I use CLI for almost everything, sometimes a GUI is much nicer. The CLI for LSI RAID cards comes to mind.
That made me chuckle. Can I mod down my own GP comment?
My comment would have made a lot more sense if the URL was Slashdot.org/logo.png
Ps - you're independent weak encryption is not hard to figure out. Let's say you use it for some PHP script on your web site. Well, it's on a publicly accessible web server, and it's friggin PHP, so I'll have the source code in ten minutes. As soon as I see the source, not only do I know what weak algorithms you're using, but I can also see the common flaws in your particular implementation.
A case in point -
A common "do it my own way" idea is to stack hash algorithms. Take a sha256 of the data, an MD5 of that, and RC4 that or whatever. Well, stacking hashes results in a hash that's provably WEAKER than the weakest hash in the chain. Each step you take to make it stronger actually makes it weaker.
I'm a total DIYer. I'd even DIY stitching a cut. There are two things you shouldn't DIY - high explosives and information security. (But low explosives are fun.)
The best way to deal with strong encryption is to go around it, to use the back door. Those are the flaws an audit would reveal, issues not with the actual encryption, which is a fairly small part of the software, but with the other 90% of the code .
The encryption itself has been analyzed, and will continue to be analyzed, outside of Truecrypt, which is just one of many packages that use the same encryption.
We know that the current version of GCC doesn't have the "Ken Thompson" trojan. The original version could have, theoretically a but it couldn't survive so many versions. Also, gdb would have revealed it long ago. ...
Maybe gcc also trojans gdb? And ptrace, and
You have to imagine that the author wrote specialized trojans for a bunch of programs that hadn't been created yet, and hid them all in a few kilobytes. That's beyond impossible, even for the best programmer in the world.
I agree with most of what has been said.
As nasty as that is, I'm pleasantly surprised Slashdot (Dice) ran this. Somebody has character to approve this story. I hope it doesn't get them fired for telling the truth.
> I am saying that the PRODUCT is math, not the thought process that goes into it.
A PRODUCT is something people buy.
I suggest that one of the greatest software makers of all time*, Steve Jobs, would tell us that the product is anything but math.
The math behind Mac is mostly the same as the math behind FreeBSD. The difference is the artistic aspects - design, etc. They are the same math, are they the same product? One is a bestselling product, the other hasn't even become a product at all.
Steve Jobs did a lot of stuff that annoys me, but he did it very well.
Try running some random executable from a thumb drive on a hotel computer and tell me how will that works.
Then the next person you see, ask them if it's okay for you to install weird "hacker" apps on their phone
Many coders who work in high level languages don't know what an "algorithm" is, so I disagree with the idea that they are professional algorithm designers.
A naive implementation of an interpreter is "algorithms" - generic functions for converting any pattern of type A into type B. As you said, long ago someone did the math, just as long ago someone designed the (mathematical) musical scale. Today's musicians and developers don't do a lot of math.
Designing a user interface that's beautiful, simple for beginners, and powerful for power users isn't a mathematical equation, it's an art, left-brain activity. If it were a math I could do it. My development team consists of me (the algorithms guy) and three people with art degrees. I can't do their job, not even a little bit. They can't do fractions, that's how mathematical they are. To make software requires all four of us - one math person and three people who have no math skills at all.
My 25% of a project is to take their art and manipulate it mathematically.
> not invented by humans, not the product of human activity. It's like saying the earth or the sun or Newton's laws of gravity should be patentable.
A = A is like the law of gravity, and not patentable.
An elevator is an invention based on gravity, and is patentable. An entirely new type of spam filter is a new invention, based on math.
It seems to me that the laws of physics and the laws of mathematics should be treated the same.
That also happens to be current law.
New inventions which make use of those laws similarly should be treated the same.
You say people could "disguise the laws" in a patent.
You could just as easily disguise Newton's laws.
There's no difference there between a machine built of wood and a machine built of pits in an optical disk. You're pretending there is a difference where there is none.
Since the laws of physics are not only similar to the laws of math, but in some cases the exact same laws, there are two arguments one can logically make:
invalid patents should be reduced (such as by allowing punitive damages in a counter-claim against a crap patent).
Nothing based on physics, and therefore nothing at all, should be patentable.
For me, I prefer option #1. If you sue on a patent and the court rules your patent is frivolous because it's obvious or whatever, you have to pay treble damages. That would reduce dumb patent suits and the motivation to file for dumb patents.
I see you didn't bother to read one word of my post before replying.
Does the computer in the hotel business center have ssh installed? No. Does a borrowed phone have ssh? No.
Ssh is great, until I run out of battery.
A web UI means I can handle an issue from any device - a computer in a hotel, grandma's cell phone, whatever.
Also, with many systems, a UI to navigate groups of systems can be handy.