SSL is a sort of "shim" that runs in the application layer. Other inter-layer shims include ARP, IPSec, etc.
In a sense this is true, but SSL is a lot more than just a "thunking" layer (like compression can be) since it requires it's own handshaking etc. I normally wouldn't think of a shim on one machine talking directly to a shim on another machine, but in a layered protocol model equivalent layers talking to each other makes some sense.
Of course, a weakness in the OSI model, is that it doesn't spend a lot of time getting into how to make the API's between layers more consistent, standard and useable... Which is invariably an issue.
To me, it has always been clear the OSI 7 layer model is a good general description of how protocol stacks go togther, while TCP/IP is one good example of a well-implemented (and minimal) protocol stack.
This is clear when the models are put side-by-side like this:
OSI . . . . ..TCP/IP . . ..DOD Application ..Application . Process Presentation . Application . Process Session . . ..TCP . . . . . Host to Host Transport . ..TCP . . . . . Host to Host Network . . ..IP . . . . ..Internet Data Link . ..Ethernet . ..Network Access Physical . . . Ethernet . ..sub-network access
Why does the fact TCP and OSI were once competitors matter in modern discourse?
Trying to fit [the TCP/IP model] up against the 7-layer OSI model doesn't work because it doesn't give you an accurate picture of what is going on. ...
For example, UDP doesn't handle restreaming the way TCP does, so if you want to handle streams over UDP (i.e. as in TFTP), you impliment this in the application layer. The OSI model doesn't really model this in any way which matches what is going on.
I don't follow this reasoning, I've just shown you the matchup, where exactly doesn't that matchup work?
As to how well you can model doing UDP streaming via an application under the OSI model, one can either argue the OSI model doesn't work because it's messy to model UDP streaming, or one can argue that streaming UDP is messy when the OSI model shows various software modules spanning logical protocol layers in strange ways. Either way OSI is just a model, a way of thinking about a problem, that sometimes helps categorize and understand it better. No single framework works equally for every application.
what is more dead and broken about the OSI 7 layer model versus the DoD 4 layer model?
The 4-layer DoD model is really simple. You have 4 layers which handle specific problems (from the bottom up): ...
This model matches what is actually happening. The OSI model does not...
Okay, so DoD is simpler and matches the most commonly deployed TCP/IP stacks as implemented. That makes it a better direct description of TCP/IP, but not necessarily a better model for thinking about protocol stacks and protocol implementations in general. And DoD *should* be a better direct description of TCP/IP, since it is really a protocol description based on TCP/IP rather than a model for building protocol stacks based on broad experience in the first place...
Finally, how exactly are the basic assumptions of OSI and TCP so different?
OSI was designed around the assumption that every layer would handle very specific types of problems
Actually, my understanding was always that the OSI model broke the protocol description/implementation problem space into 7 logical and easily identifiable layers which could be implemented in any number of physical or logical modules to get the job done (These modules might span layers, break down individual layers into smaller chunks, or even be missing in some cases.) In fact, one of the original reasons for having the OSI model was so when two developers wrote different modules which had to interact with each other they'd know where everyone sat on the whole "protocol food-chain" as it were.
If we always had to have a one to one mapping between layers in our model and layers in our implementation, then inventions like SSL/TLS would require whole new models, not just new stack implementations. And yet, no one talks about the "5-layer SSL model", or at least no one I've ever heard of. Instead SSL managed to slide neatly into the Presentation Layer gap left in the TCP/IP implementation. Something we wouldn't even be able to talk about under the 4 layer DoD model. (Even better, SSL managed to keep an interface almost identical to TCP to avoid application rewriting...)
When Firefox first came out, it was widely perceived as "a fully secure browser" that you could "install and forget". Cleary both IE and Firefox have now had vulnerabilities in the last year. Just as clearly IE's track record isn't as good. Still, to really buck the establishment and start pushing hard for a switch to Firefox I'd like to see a security record you can eat off of, and that just hasn't happened yet.
When Firefox becomes the OpenBSD of browsers, then maybe I'll start flogging it again. Until then, I just assume people are going to catch viruses and exploits when browsing the web on Windows no matter what browser they use (except maybe Opera but that costs either $$$ or ad-time).
...with few people even remembering that OSI was supposed to be a competitor to TCP and built along fundamentally different assumptions... The problem is compounded by broken requirements like knowing the OSI model which is not only dead but broken.
I'll bite.
Why does the fact TCP and OSI were once competitors matter in modern discourse? Further, what is more dead and broken about the OSI 7 layer model versus the DoD 4 layer model? Finally, how exactly are the basic assumptions of OSI and TCP so different? (The prioritization of goals may be somewhat different, interoperability versus reliability for instance, but I don't see how the basic problem spaces differ so extremely.)
You're saying that Paul McCartney doesn't deserve to make any money from the music he wrote 40 years ago, so that you can fire up eMule without feeling guilty about it.
I don't know what anyone else says, but I'd say rights to copy in Mr. McCartney's works, which he may or may not have been swindled out of early on, should probably have expired about 20 years ago. Why? Because it would make for a more free, vibrant and useful public domain, which would allow for the creation of newer and better works by artists of all kinds. (Including Mr. McCartney.)
Copyright is not an excuse to sit on your hands, it's a social contract providing limited rights for limited times to creators to entice them to spend more time creating. That's it. It's certainly not an inalienable right which someone has been willing to die over.
When was the last time you heard someone say, "Give me royalties or give me death?"
And when I bought that new Mini Cooper, they threw in a free FM radio. So, now and then I just go ahead and turn the damn thing on. It's free. Why not?
Of course, if I had to pay for it, I'd be doing exactly as you say.
Making it so once more would certainly be a good first step in getting things back into line.
If a copyright holder wants to enforce his rights and recover from the damage that infringers have cost him, that's fine.
We must also decide that a compromise such as copyright is necessary, reasonable and exactly what that compromise entails before there are any "damages" to be disputed. 70 years work for hire with a bullet and heavily restrictued use sounds like anything but fair to me. (ie: vendor approved device, which costs $$$ and pay-per-view etc.)
If you think the Turing Test can be administered in one question, then I think you wholly misunderstand the concept.
Heck, if we had decently good AI chat bots, they could even be rated by how long it takes a competent tester to determine they are not human. I've yet to see one that doesn't get really obvious in about 2-3 questions currently. (For one thing, bots can't handle context. Throw in a dash of context related to your current conversation and watch just how fast they fall apart. For example:)
me: You're a bot. bot: I'm not a bot. me: Are too! bot: Am not! me: You aren't what? bot: *emits botly nonsense*
Or more realisticly, talking to say, Alice: Human: You're a bot ALICE: How did you know I am a machine? Human: Your website says you're a machine. ALICE: That could be considered an insult in some cultures. Human: It's *your* website. ALICE: website says me is my website? it is?
By 2 questions/statements it becomes somewhat apparent Alice is not a human (or even a human pretending to be a "smart" machine). By 3 it is plainly obvious and I'm already getting bored with the responses and ready to move on as the whole thread of conversation has been lost.
No, the Turing test calls for a person of "Average intelligence." There is nothing about "competant" in the definition. Average intelliegence is an IQ of 100
Ya, but one response like that doesn't fail a turing test, keep asking questions over and over and see if the pattern repeats... Sheesh.
He at least got the context right, and gave an original answer, that's a bare minimum human response. The human shouldn't have to "try" to seem human. (Of course, they also shouldn't be trying to seem less than human or the test is unfair in the other direciton)
Maybe those trying to "administer" Turing tests need to learn to have a bit more of an attention span...
Of course, if the pattern repeats and this happens after an extended conversation, this guy probably just isn't a very good listener.
Oh well, like others have said, I'll wait for a better source than MSNBC before I start running around like a chicken with it's head cut off.
More specifically, it's probably a good idea to wait for an actual draft to come out rather than harping on rumors about what Stallman *might* write. The GPL governs redistribution, not use. As long as this remains true, I have trouble seeing how the license can become too terribly honerous.
Worst case scenario, you can have your customers download GPL'ed stuff themselves, much like various Java VM's and tools require.
Well... keep in mind that just like with a smaller accident, there's only so many resources that are useful. Beyond that you're just another rubbernecker.
Of course, it's hard to imagine money and doctors being oversupplied.
It clearly isn't what happened in this case. I'm saying this is a way it *could* have been done, or could be done in the future. Particularly if you keep records that can prove it.
bnet.d could not reasonably be reverse engineered without using the client, I think.
Again, the whole "difficulty" matter. There are thousands of users, give me (or a better reverse engineer) sniffing access to a router near one of the blizzard servers and we'd see...
I *think* you must alter the client in order to use them (retarget the server address
Modification is not the same thing as reverse engineering. This should be trivially easy, wouldn't be done by the same group as the server components (and alone may even be legitimate according to the Blizzard license in order to handle issues like broken DNS servers etc...)
At worst having people go through some sort of proxying firewall aught to work... ie: Modify the environment not the app to redirect the IP traffic.
Who cares how much the carpenters, painters, sets, directors, actors, etc cost?
Anyone think maybe we, US culture, are wasting a heck of a lot of money on things that really don't matter? I mean, if we've gotta create a draconian big-brother society just to pay the production of ENTERTAINMENT, what has the world come to? Maybe it'd be better if we just ran a yearly lottery to pick gladiators that can entertain us in a ring by dieing?
If this argument holds water, then couldn't I let you buy a copy of World of Warcraft, which I could then legally reverse engineer by sniffing the packets while you play it?
How packets passing through Bill's router any different than a document emailed to Bob?
(Note: This wouldn't exactly be the easiest method of reverse engineering, then again it might be enough...)
Slashdot Mirror
SSL is a sort of "shim" that runs in the application layer. Other inter-layer shims include ARP, IPSec, etc.
In a sense this is true, but SSL is a lot more than just a "thunking" layer (like compression can be) since it requires it's own handshaking etc. I normally wouldn't think of a shim on one machine talking directly to a shim on another machine, but in a layered protocol model equivalent layers talking to each other makes some sense.
Of course, a weakness in the OSI model, is that it doesn't spend a lot of time getting into how to make the API's between layers more consistent, standard and useable... Which is invariably an issue.
To me, it has always been clear the OSI 7 layer model is a good general description of how protocol stacks go togther, while TCP/IP is one good example of a well-implemented (and minimal) protocol stack.
This is clear when the models are put side-by-side like this:
I don't follow this reasoning, I've just shown you the matchup, where exactly doesn't that matchup work?
As to how well you can model doing UDP streaming via an application under the OSI model, one can either argue the OSI model doesn't work because it's messy to model UDP streaming, or one can argue that streaming UDP is messy when the OSI model shows various software modules spanning logical protocol layers in strange ways. Either way OSI is just a model, a way of thinking about a problem, that sometimes helps categorize and understand it better. No single framework works equally for every application.
Okay, so DoD is simpler and matches the most commonly deployed TCP/IP stacks as implemented. That makes it a better direct description of TCP/IP, but not necessarily a better model for thinking about protocol stacks and protocol implementations in general. And DoD *should* be a better direct description of TCP/IP, since it is really a protocol description based on TCP/IP rather than a model for building protocol stacks based on broad experience in the first place...
Actually, my understanding was always that the OSI model broke the protocol description/implementation problem space into 7 logical and easily identifiable layers which could be implemented in any number of physical or logical modules to get the job done (These modules might span layers, break down individual layers into smaller chunks, or even be missing in some cases.) In fact, one of the original reasons for having the OSI model was so when two developers wrote different modules which had to interact with each other they'd know where everyone sat on the whole "protocol food-chain" as it were.
If we always had to have a one to one mapping between layers in our model and layers in our implementation, then inventions like SSL/TLS would require whole new models, not just new stack implementations. And yet, no one talks about the "5-layer SSL model", or at least no one I've ever heard of. Instead SSL managed to slide neatly into the Presentation Layer gap left in the TCP/IP implementation. Something we wouldn't even be able to talk about under the 4 layer DoD model. (Even better, SSL managed to keep an interface almost identical to TCP to avoid application rewriting...)
When Firefox first came out, it was widely perceived as "a fully secure browser" that you could "install and forget". Cleary both IE and Firefox have now had vulnerabilities in the last year. Just as clearly IE's track record isn't as good. Still, to really buck the establishment and start pushing hard for a switch to Firefox I'd like to see a security record you can eat off of, and that just hasn't happened yet.
When Firefox becomes the OpenBSD of browsers, then maybe I'll start flogging it again. Until then, I just assume people are going to catch viruses and exploits when browsing the web on Windows no matter what browser they use (except maybe Opera but that costs either $$$ or ad-time).
...with few people even remembering that OSI was supposed to be a competitor to TCP and built along fundamentally different assumptions ...
The problem is compounded by broken requirements like knowing the OSI model which is not only dead but broken.
I'll bite.
Why does the fact TCP and OSI were once competitors matter in modern discourse? Further, what is more dead and broken about the OSI 7 layer model versus the DoD 4 layer model? Finally, how exactly are the basic assumptions of OSI and TCP so different? (The prioritization of goals may be somewhat different, interoperability versus reliability for instance, but I don't see how the basic problem spaces differ so extremely.)
I certainly hope you're not arguing against layering of protocols altogether.
You're saying that Paul McCartney doesn't deserve to make any money from the music he wrote 40 years ago, so that you can fire up eMule without feeling guilty about it.
I don't know what anyone else says, but I'd say rights to copy in Mr. McCartney's works, which he may or may not have been swindled out of early on, should probably have expired about 20 years ago. Why? Because it would make for a more free, vibrant and useful public domain, which would allow for the creation of newer and better works by artists of all kinds. (Including Mr. McCartney.)
Copyright is not an excuse to sit on your hands, it's a social contract providing limited rights for limited times to creators to entice them to spend more time creating. That's it. It's certainly not an inalienable right which someone has been willing to die over.
When was the last time you heard someone say, "Give me royalties or give me death?"
Maybe if they could get the judge to stop laughing long enough.
Seriously though. If you taped it and put it on the internet, they'd have your ass...
And when I bought that new Mini Cooper, they threw in a free FM radio. So, now and then I just go ahead and turn the damn thing on. It's free. Why not?
Of course, if I had to pay for it, I'd be doing exactly as you say.
Are you upholding this lawsuit as an example of what you consider to be "good law"?
Further, this'd be more like throwing the mom in jail when one of her kids friends gets caught smoking pot in the basement...
Copyright infringement is chiefly a civil matter
Was, we live under the DMCA now.
and ideally should only be civil.
Making it so once more would certainly be a good first step in getting things back into line.
If a copyright holder wants to enforce his rights and recover from the damage that infringers have cost him, that's fine.
We must also decide that a compromise such as copyright is necessary, reasonable and exactly what that compromise entails before there are any "damages" to be disputed. 70 years work for hire with a bullet and heavily restrictued use sounds like anything but fair to me. (ie: vendor approved device, which costs $$$ and pay-per-view etc.)
Ya, but did your rot13 it all...
If you think the Turing Test can be administered in one question, then I think you wholly misunderstand the concept.
Heck, if we had decently good AI chat bots, they could even be rated by how long it takes a competent tester to determine they are not human. I've yet to see one that doesn't get really obvious in about 2-3 questions currently. (For one thing, bots can't handle context. Throw in a dash of context related to your current conversation and watch just how fast they fall apart. For example:)
me: You're a bot.
bot: I'm not a bot.
me: Are too!
bot: Am not!
me: You aren't what?
bot: *emits botly nonsense*
Or more realisticly, talking to say, Alice:
Human: You're a bot
ALICE: How did you know I am a machine?
Human: Your website says you're a machine.
ALICE: That could be considered an insult in some cultures.
Human: It's *your* website.
ALICE: website says me is my website? it is?
By 2 questions/statements it becomes somewhat apparent Alice is not a human (or even a human pretending to be a "smart" machine). By 3 it is plainly obvious and I'm already getting bored with the responses and ready to move on as the whole thread of conversation has been lost.
From gnu.org:
No, the Turing test calls for a person of "Average intelligence." There is nothing about "competant" in the definition. Average intelliegence is an IQ of 100
That's testee, not necessarily testor(s)...
I don't know, I just do! (if true) might be the best answer in that situation...
I think that's a matter of opinion. I'd say Eliza does worse, of course, maybe I'm using a crippled version...
Who said I like music? You insensitive clod!
Ya, but one response like that doesn't fail a turing test, keep asking questions over and over and see if the pattern repeats... Sheesh.
He at least got the context right, and gave an original answer, that's a bare minimum human response. The human shouldn't have to "try" to seem human. (Of course, they also shouldn't be trying to seem less than human or the test is unfair in the other direciton)
Maybe those trying to "administer" Turing tests need to learn to have a bit more of an attention span...
Of course, if the pattern repeats and this happens after an extended conversation, this guy probably just isn't a very good listener.
Oh well, like others have said, I'll wait for a better source than MSNBC before I start running around like a chicken with it's head cut off.
More specifically, it's probably a good idea to wait for an actual draft to come out rather than harping on rumors about what Stallman *might* write. The GPL governs redistribution, not use. As long as this remains true, I have trouble seeing how the license can become too terribly honerous.
Worst case scenario, you can have your customers download GPL'ed stuff themselves, much like various Java VM's and tools require.
Well... keep in mind that just like with a smaller accident, there's only so many resources that are useful. Beyond that you're just another rubbernecker.
Of course, it's hard to imagine money and doctors being oversupplied.
500 buses * 40 people per bus = 2000 people
Wow. That's some really bad math there. You might wanna think about bringing a calculator with you next time...
It clearly isn't what happened in this case. I'm saying this is a way it *could* have been done, or could be done in the future. Particularly if you keep records that can prove it.
bnet.d could not reasonably be reverse engineered without using the client, I think.
Again, the whole "difficulty" matter. There are thousands of users, give me (or a better reverse engineer) sniffing access to a router near one of the blizzard servers and we'd see...
I *think* you must alter the client in order to use them (retarget the server address
Modification is not the same thing as reverse engineering. This should be trivially easy, wouldn't be done by the same group as the server components (and alone may even be legitimate according to the Blizzard license in order to handle issues like broken DNS servers etc...)
At worst having people go through some sort of proxying firewall aught to work... ie: Modify the environment not the app to redirect the IP traffic.
Who cares how much the carpenters, painters, sets, directors, actors, etc cost?
Anyone think maybe we, US culture, are wasting a heck of a lot of money on things that really don't matter? I mean, if we've gotta create a draconian big-brother society just to pay the production of ENTERTAINMENT, what has the world come to? Maybe it'd be better if we just ran a yearly lottery to pick gladiators that can entertain us in a ring by dieing?
If this argument holds water, then couldn't I let you buy a copy of World of Warcraft, which I could then legally reverse engineer by sniffing the packets while you play it?
How packets passing through Bill's router any different than a document emailed to Bob?
(Note: This wouldn't exactly be the easiest method of reverse engineering, then again it might be enough...)