(I know, in courts the most money wins, not justice or truth.... we have O.J. to thank for showing the country that.)
The OJ case isn't the best example of this maxim, though I do believe there is truth in it. If the LA police department weren't such a bunch of racist bastards in the first place, the defense couldn't have used that fact as a hook to cast doubt on OJs guilt.
So, if you really think MS has all kinds of back-doors in it, why not actually go crack it? Go prove it, make a huge name for yourself, and expose MS.
Given the NSA's history with various companies (Crypto AG anyone?) and their encryption software, I think the opposite proof is required. All proprietary products must be assumed to have back doors unless they can somehow prove otherwise. BTW, good luck with that proof without releasing source code.
Also, Microsoft has a pretty bad history (their VPN software for example) of making things that really are secure in the cryptography arena. So again, I think the burden of proof is the other way.
All Microsoft software is only as secure as it absolutely has to be in order to sell it, and history (and knowing the average buyer) shows that's not very secure. Trusting Microsoft with security is like trusting an unregulated S&L with your money.
Your CAT NAT replacement technology is based on the faulty assumption that you're selling a 'subscription' to the Internet. That is an extremely cable providerish way of looking at things, and precisely the reason I avoid cable (and tell my friends to as well) like the plague.
What you're selling me is a connection to the Internet. You're selling me bandwidth. That's all you're selling me. That's it. You can't care what I have on the other end of the pipe anymore than the water company can care whether or not I have a dishwasher plugged in or water a neighbors lawn.
If you're basing your pricing and bandwidth provisioning on expected usage, it's cheaper and easier to implement traffic shaping and aggregate (as opposed to burst) bandwidth limiting than it is to develop a whole set of proprietary protocols that people will just get around anyway, thereby starting a technology war (which cable companies will ultimately lose) with your customers. Then you can charge people if they want to exceed your expectations. This model is enforceable, will be seen as reasonable, and doesn't require expensive proprietary and invasive technologies to implement.
I find it kind of amusing (and scary) how so many companies want to have broken business models, call customers criminals when they don't work, and try to implement invasive technological solutions that give the service provider immense control. It's stupid and wrong, and you should know better than to have written an article advoacting such iodiocy.
Cable will never enter my home until you guys get a clue and stop trying to make me into a passive consumer instead of a happy customer.
Umm, I've seen plenty of programs that have a threading model just as I described. If you listened to people 2-3 years ago, that idea was all the rage.
I don't want things that prevent you from doing stupid stuff. I just want things that don't encourage you to.
Does a call that results in a bunch of SOAP formatted XML being put on the wire look like a function call or not? Does that function call have arguments that mirror the data stuck on the wire or not? If the answer is yes, then SOAP is designed to encapsulate a function call, and is evil.
I don't know of any programs outside of a proprietary environment that do that. I know of some older research grade programs that do that. I haven't investigated GNOME carefully.
I think that the simplicity is as false as the simplicity of starting up a new thread for every connection when you have to talk to 5000 people at once.
Oops, I didn't answer your question before. You don't WANT to use SSL because it's expensive.
Well, SSL/TLS, or something like it is the only solution that's really any better than plain text XML. If you think something more obscure is better, you're just fooling yourself. Though you can use something other than HTTPS (which assumes you will be making HTTP requests over SSL/TLS) you might want to design your own protocol and encapsulate it in SSL/TLS instead.
The advantage to doing your own protocol would be that you could have different session setup and teardown semantics than HTTP. HTTP tends to assume that you'll fetch a web page (or a few pages in HTTP/1.1) then disconnect. You might to avoid the setup and teardown overhead because that's the most expensive part of an SSL/TLS session, so designing your own protocol that kept the connection around longer might be an idea.
I don't like SOAP either. When I talked about XML in my 'paper', I meant XML documents that aren't designed to encapsulate a function call, but merely carry information.
One question I have is how do you do authentication with web services. Also HTTPS is relatively expensive and might not be the perfect alternative in every scenario. So you end up sending everything in plain text xml across the wire? This may not be appropriate in a lot of cases (especially with the authentication process)
SSL isn't an RPC protocol. It's fine to use to hide your data.:-)
The document you reference has no explanation about why the function call model is evil, misleading, or broken. All you do is put forward a short argument that it more tightly couples endpoints than exchanging XML documents and that it is lower performance than dumping raw memory.
I also complain a lot about latency, and I should complain about the lack of a shared address space, which leads to even more latency. That's the biggest issue. The function call model encourages you to ignore unavoidable latency in network messages. It's a fine model for things within the same process, but latency makes it misleading and evil for network messages.
To call it misleading you would need to provide an argument for why the function call paradigm makes sense when both program components are on the local machine but not when they are distributed. Why should that make a difference? Why should I care where the other end of my transaction be located?
Because, when it's located far away, you have several issues to contend with. First, a function call normally has a latency in the nanosecond range. A network message over the Internet normally has a latency in the millisecond range. Even LAN messages have a latency in the 100s of microsecond range. That's at least 4-5 orders of magnitude (base 10) difference. That's gigantically huge. Yet, it sits there in your program looking like an innocent function call that you'd normally expect to extract an overhead of a few nanseconds.
The other problem is that you don't have very much control over the state of the other program, especially if someone else wrote it. You're essentially introducing close state dependencies between programs that are largely unrelated, and several milliseconds apart. There is nothing _inherent_ about the function call model that forces you to introduce these dependencies, but everything that everybody knows about programming causes you to make certain assumptions about function calls that just aren't true for network messages, especially between largely unrelated programs.
RPC is evil because it hides those essential differences from you.
I don't think it matters which you use. Allowing people to make functional requests to programs inside your firewall is just as much of a security risk either way. I actually think the function call model is an evil, misleading, broken way of thinking about messages over networks, but like several other practices, people seem bound and determined that this is the way to do things. If you must do this evil thing, it probably doesn't matter (from a security standpoint) how you do it.
The only thing you really gain by not going through port 80 is that the attacker theoretically won't be able to break into your web server software by breaking into your RPC software, but I wouldn't count on that being the case. Besides, either way, they've gotten onto your box, does it really matter how?
Holes in firewalls aren't intrinsically bad things. It's what they lead to that's the problem.
It clearly relates to stuff Slashdot covers all the time. The existence of Open Source, the legal jeporady Open Source is in with things like the DMCA and the SSSCA.
Also, an article like this takes time to read for intelligent people who aren't intent on stupid trolling.
Your post consists largely of FUD about Linux on the desktop, lies about the administration ease of Windows, and untruths (or simply bad analysis) about what has driven the Internet revolution. I suspect it of being a troll, but if it is, it's an ingenious one.
For all of you who are sitting here on this thread chewing this guy out, he's complaining that the thing needs its own device drivers, not exactly that it doesn't support a USB mouse. On this, I agree. I don't need a mini-OS just to boot my OS, that's silly.
One of the few Loki games I won't buy. I have no problems with its being produced, but everything I've heard about the game tells me that it will disgust me. I don't need a game like that.
People must be held accountable for the actions of the states (nations, large political bodies) they live in. Even if they did not personally send the message or set up the organization, they are still part of that organization. Just as we in America must all be held accountable for the actions of our leaders.
Before patents, companies kept everything secret to protect themselves and science was stifled.
Example please. This seems an unsubstantiated statement to me. I would provide my own unsubstantiated statement that the software industry was significantly more open and innovative before patents came into the picture.
I live in Minneapolis, MN and have a friend who GMs a Matrix style game he designed that's pretty well done. He concentrates on the action aspects of it mostly, and his game design is purposely streamlined to make it fast. It's pretty good.
I can't see how anything you said contradicts my post (well, aside from the liquid helium being colder. I actually kinda thought it was, but assumed the previous poster knew more then (s)he did about low temperature physics). It was kind of a ludicrous thread anyway. I did talk about using liquid helium, and I was well aware that the superconducting temperatures were in the range of 0-2k. Yes, it ridiculous to assume that you'd be able to get good enough thermal conduction away from the processor to maintain it at these temperatures, but it's silly to think about cooling it in liquid helium in the first place.:-)
I'd be worried about liquid hydrogen being a conductor. I'd rather use liquid helium. Almost as cold, and definitely non-conductive. Of course, you may end up inducing superconductivity in some of the copper in the chip and on the board, and that might be bad.
Slashdot Mirror
The OJ case isn't the best example of this maxim, though I do believe there is truth in it. If the LA police department weren't such a bunch of racist bastards in the first place, the defense couldn't have used that fact as a hook to cast doubt on OJs guilt.
Given the NSA's history with various companies (Crypto AG anyone?) and their encryption software, I think the opposite proof is required. All proprietary products must be assumed to have back doors unless they can somehow prove otherwise. BTW, good luck with that proof without releasing source code.
Also, Microsoft has a pretty bad history (their VPN software for example) of making things that really are secure in the cryptography arena. So again, I think the burden of proof is the other way.
All Microsoft software is only as secure as it absolutely has to be in order to sell it, and history (and knowing the average buyer) shows that's not very secure. Trusting Microsoft with security is like trusting an unregulated S&L with your money.
Your CAT NAT replacement technology is based on the faulty assumption that you're selling a 'subscription' to the Internet. That is an extremely cable providerish way of looking at things, and precisely the reason I avoid cable (and tell my friends to as well) like the plague.
What you're selling me is a connection to the Internet. You're selling me bandwidth. That's all you're selling me. That's it. You can't care what I have on the other end of the pipe anymore than the water company can care whether or not I have a dishwasher plugged in or water a neighbors lawn.
If you're basing your pricing and bandwidth provisioning on expected usage, it's cheaper and easier to implement traffic shaping and aggregate (as opposed to burst) bandwidth limiting than it is to develop a whole set of proprietary protocols that people will just get around anyway, thereby starting a technology war (which cable companies will ultimately lose) with your customers. Then you can charge people if they want to exceed your expectations. This model is enforceable, will be seen as reasonable, and doesn't require expensive proprietary and invasive technologies to implement.
I find it kind of amusing (and scary) how so many companies want to have broken business models, call customers criminals when they don't work, and try to implement invasive technological solutions that give the service provider immense control. It's stupid and wrong, and you should know better than to have written an article advoacting such iodiocy.
Cable will never enter my home until you guys get a clue and stop trying to make me into a passive consumer instead of a happy customer.
I was tempted to moderate it down just on general principles, but, sadly, it's worth a '3'. If it were '4', I would've.
Umm, I've seen plenty of programs that have a threading model just as I described. If you listened to people 2-3 years ago, that idea was all the rage.
I don't want things that prevent you from doing stupid stuff. I just want things that don't encourage you to.
Does a call that results in a bunch of SOAP formatted XML being put on the wire look like a function call or not? Does that function call have arguments that mirror the data stuck on the wire or not? If the answer is yes, then SOAP is designed to encapsulate a function call, and is evil.
I don't know of any programs outside of a proprietary environment that do that. I know of some older research grade programs that do that. I haven't investigated GNOME carefully.
I think that the simplicity is as false as the simplicity of starting up a new thread for every connection when you have to talk to 5000 people at once.
Oops, I didn't answer your question before. You don't WANT to use SSL because it's expensive.
Well, SSL/TLS, or something like it is the only solution that's really any better than plain text XML. If you think something more obscure is better, you're just fooling yourself. Though you can use something other than HTTPS (which assumes you will be making HTTP requests over SSL/TLS) you might want to design your own protocol and encapsulate it in SSL/TLS instead.
The advantage to doing your own protocol would be that you could have different session setup and teardown semantics than HTTP. HTTP tends to assume that you'll fetch a web page (or a few pages in HTTP/1.1) then disconnect. You might to avoid the setup and teardown overhead because that's the most expensive part of an SSL/TLS session, so designing your own protocol that kept the connection around longer might be an idea.
I don't like SOAP either. When I talked about XML in my 'paper', I meant XML documents that aren't designed to encapsulate a function call, but merely carry information.
SSL isn't an RPC protocol. It's fine to use to hide your data. :-)
I also complain a lot about latency, and I should complain about the lack of a shared address space, which leads to even more latency. That's the biggest issue. The function call model encourages you to ignore unavoidable latency in network messages. It's a fine model for things within the same process, but latency makes it misleading and evil for network messages.
Because, when it's located far away, you have several issues to contend with. First, a function call normally has a latency in the nanosecond range. A network message over the Internet normally has a latency in the millisecond range. Even LAN messages have a latency in the 100s of microsecond range. That's at least 4-5 orders of magnitude (base 10) difference. That's gigantically huge. Yet, it sits there in your program looking like an innocent function call that you'd normally expect to extract an overhead of a few nanseconds.
The other problem is that you don't have very much control over the state of the other program, especially if someone else wrote it. You're essentially introducing close state dependencies between programs that are largely unrelated, and several milliseconds apart. There is nothing _inherent_ about the function call model that forces you to introduce these dependencies, but everything that everybody knows about programming causes you to make certain assumptions about function calls that just aren't true for network messages, especially between largely unrelated programs.
RPC is evil because it hides those essential differences from you.
I don't think it matters which you use. Allowing people to make functional requests to programs inside your firewall is just as much of a security risk either way. I actually think the function call model is an evil, misleading, broken way of thinking about messages over networks, but like several other practices, people seem bound and determined that this is the way to do things. If you must do this evil thing, it probably doesn't matter (from a security standpoint) how you do it.
The only thing you really gain by not going through port 80 is that the attacker theoretically won't be able to break into your web server software by breaking into your RPC software, but I wouldn't count on that being the case. Besides, either way, they've gotten onto your box, does it really matter how?
Holes in firewalls aren't intrinsically bad things. It's what they lead to that's the problem.
It clearly relates to stuff Slashdot covers all the time. The existence of Open Source, the legal jeporady Open Source is in with things like the DMCA and the SSSCA.
Also, an article like this takes time to read for intelligent people who aren't intent on stupid trolling.
Your post consists largely of FUD about Linux on the desktop, lies about the administration ease of Windows, and untruths (or simply bad analysis) about what has driven the Internet revolution. I suspect it of being a troll, but if it is, it's an ingenious one.
As I heard it, the plot originally had them using humans as processors, but it was felt that would be too much for people to grasp.
For all of you who are sitting here on this thread chewing this guy out, he's complaining that the thing needs its own device drivers, not exactly that it doesn't support a USB mouse. On this, I agree. I don't need a mini-OS just to boot my OS, that's silly.
CDs are 1411kbps. 128kbps just _can't_ be CD quality.
One of the few Loki games I won't buy. I have no problems with its being produced, but everything I've heard about the game tells me that it will disgust me. I don't need a game like that.
People must be held accountable for the actions of the states (nations, large political bodies) they live in. Even if they did not personally send the message or set up the organization, they are still part of that organization. Just as we in America must all be held accountable for the actions of our leaders.
True innocence is very hard to come by.
Example please. This seems an unsubstantiated statement to me. I would provide my own unsubstantiated statement that the software industry was significantly more open and innovative before patents came into the picture.
I live in Minneapolis, MN and have a friend who GMs a Matrix style game he designed that's pretty well done. He concentrates on the action aspects of it mostly, and his game design is purposely streamlined to make it fast. It's pretty good.
If you're interested, send mail to me at eric-slash@omnifarious.org and I'll tell you more.
I already tell h(im/er) that. :-)
I can't see how anything you said contradicts my post (well, aside from the liquid helium being colder. I actually kinda thought it was, but assumed the previous poster knew more then (s)he did about low temperature physics). It was kind of a ludicrous thread anyway. I did talk about using liquid helium, and I was well aware that the superconducting temperatures were in the range of 0-2k. Yes, it ridiculous to assume that you'd be able to get good enough thermal conduction away from the processor to maintain it at these temperatures, but it's silly to think about cooling it in liquid helium in the first place. :-)
At extremely low temperatures, ordinary bulk metals become superconductive.
I'd be worried about liquid hydrogen being a conductor. I'd rather use liquid helium. Almost as cold, and definitely non-conductive. Of course, you may end up inducing superconductivity in some of the copper in the chip and on the board, and that might be bad.