I can see how moving a service like this into the kernel could have stability implications, but you didn't say anything about that
You obviously didn't read the first line of my post, so here it is again:
good thing IIS has proven itself both secure and stable. otherwise, this could really be an issue
I could have sworn that 10th word is stable, my bad.
Concerning security, you're partially correct. Running the HTTP stack in kernel mode doesn't make it inherently less secure. It does allow any subsequent exploit to run without any of the protections built into the OS, though (don't even try to tell me that that won't happen, either. network stack code is notoriously susceptable to buffer overflow). Want to destroy the partition table? Easy, just access the drive directly. Access kernel data structures? Sure, kernel memory is wide open. Pass bullshit to the hardware to try and get it to fail? OK, the system bus is yours. And, I could be wrong, but I'm fairly sure that kernel level access is all that's required to update the system bios, which could be especially nasty. Finally, causing a system crash is trivial, as the OS is no longer able to kill/deny the HTTP stack process when it trys to do something it shouldn't. But, isn't that stability and not security?!? The truth is that it, and virtually all the other things I brought up, are BOTH. A lack of stability is a security risk and vice versa, as anyone who has suffered a ping-of-death style DOS attack will gladly tell you.
Honestly, I don't hate Microsoft. As you noted, they have been extremely successful and I respect that. It just urks me that they seem entirely willing to unleash bug ridden code without much thought for what happens when said bugs are used to compromise a substantial chunk of the systems on the net. Running an application level network protocol stack in the kernel is just one of many examples of this. Another good one was their narrowly thwarted attempt to allow any user process access to raw IP sockets in XP, which would have exponentially increased the difficulty in dealing with DDOS attacks. Even a little forethough on their part on issues like this would go a long way, and it's a sham that they don't use it.
good thing IIS has proven itself both secure and stable. otherwise, this could really be an issue:
IIS adds a number of Unix-style playing cards to its hand in this release, including text-file-based configuration, much tighter security defaults, user-level instead of administrator-level privileges, and a kernel-mode HTTP request handler and cache.
For over 200 years, the basic role of the Patent and Trademark Office (PTO) has remained the same: to promote the progress of science and the useful arts by securing for limited times to inventors the exclusive right to their respective discoveries.
As much as I agree that this is a laudable goal, I think it's obvious from this case and others that in today's high-paced climate, patents often serve to do exactly the opposite.
The truth of the matter is that after 20 years, modern technology is most likely so far behind the curve that it's useless or, at best, so developed that no right-minded business is willing to spend anything on it's continued development. Thus, patents such as these no longer serve to give a small advantage to inventors and protect fledgling technology. Rather, they tend to provide a means for the Chucks of the world to significantly inhibit development for the entire useful life of the technology. This isn't the industrial age anymore; to think that 20 years still represents a "limited time" is both ignorant and counterproductive.
The current emphasis on low power CPU's isn't an effort to reverse the power consumption trend, merely to slow it down. In most cases, power consumption offsets performance. Historically, designers have almost always favored performance, resulting in power consumption varying roughly with clock speed (P~af^2) squared for the same family of chip. Current efforts are to bring that closer to a linear relationship (P~af). However, even in this "ideal" relationship, faster chips will use more power (and while you're right about a general shift in priorities, don't kid yourself for a minute that the market will altogether stop demanding faster CPUs anytime soon). While it is technically feasible to make a faster chip use less power (provided the original chip is reasonably inefficient), it is extremely difficult and costly (TTM, R&D efforts, material cost, chip size, etc.).
A second issue is miniturization, since the issue we are concerned about here is not necessarily power consumption, but temperature. Even if we assume that power consumption will stay the same, if we make the chip with half the surface area, then the power dissipation per unit area (roughly proportional to temperature) will double. Thus, even without increasing the power consumption, we run into issues that can only be addressed by advanced cooling systems such as this.
While the airphone example does illustrate his point nicely, it seems to be overly convenient. You could easily (try to) make the same argument against cell phones (permanet) v. land lines (nearlynet) in the context of the early to mid 90's, and we all know who's winning that battle. The truth is that people are willing to pay a reasonable premium for ubiquity. Does this prove that 3G will succeed? No, but it does illusrate that in some cases the permanet can come out on top.
Another big thing that wasn't addressed is that, regardless of whether they use it for 3G data, most people already are, or will soon be, walking around with a 3G enabled device (i.e. cell phone). Even today, it is relatively difficult to purchase a cell phone that does not support GPRS or cdma2000. Furthermore, carriers and device manufacturers are going to continue to strive to make obtaining and using these devices for 3G data transmission as simple as possible. Thus the powerful issue of convenience comes into play. In my mind, the sheer simplicity of having one device with one account that is responsible for all your voice and data transmissions (either from that device or as a gateway to another device) will greatly increase the appeal of 3G over WiFi.
In my opinion, these two things (and others) make the 3G/WiFi situation and the AirPhone/cell phone situation sufficiently different to render any parallels between them inconclusive. There are other factors at work here well outside of the scope of the permanet/nearlynet concept.
scot
BTW, in reference to the flat v. metered rate issue, most people who are familiar with both markets agree that cell phone customers in the US are getting screwed by the (essentially flat rate, for most people) approach to billing compared to the (entirely metered) approach used in Europe and elsewhere.
Slashdot Mirror
I can see how moving a service like this into the kernel could have stability implications, but you didn't say anything about that
You obviously didn't read the first line of my post, so here it is again:
good thing IIS has proven itself both secure and stable. otherwise, this could really be an issue
I could have sworn that 10th word is stable, my bad.
Concerning security, you're partially correct. Running the HTTP stack in kernel mode doesn't make it inherently less secure. It does allow any subsequent exploit to run without any of the protections built into the OS, though (don't even try to tell me that that won't happen, either. network stack code is notoriously susceptable to buffer overflow). Want to destroy the partition table? Easy, just access the drive directly. Access kernel data structures? Sure, kernel memory is wide open. Pass bullshit to the hardware to try and get it to fail? OK, the system bus is yours. And, I could be wrong, but I'm fairly sure that kernel level access is all that's required to update the system bios, which could be especially nasty. Finally, causing a system crash is trivial, as the OS is no longer able to kill/deny the HTTP stack process when it trys to do something it shouldn't. But, isn't that stability and not security?!? The truth is that it, and virtually all the other things I brought up, are BOTH. A lack of stability is a security risk and vice versa, as anyone who has suffered a ping-of-death style DOS attack will gladly tell you.
Honestly, I don't hate Microsoft. As you noted, they have been extremely successful and I respect that. It just urks me that they seem entirely willing to unleash bug ridden code without much thought for what happens when said bugs are used to compromise a substantial chunk of the systems on the net. Running an application level network protocol stack in the kernel is just one of many examples of this. Another good one was their narrowly thwarted attempt to allow any user process access to raw IP sockets in XP, which would have exponentially increased the difficulty in dealing with DDOS attacks. Even a little forethough on their part on issues like this would go a long way, and it's a sham that they don't use it.
Hope I answered your question.
good thing IIS has proven itself both secure and stable. otherwise, this could really be an issue:
IIS adds a number of Unix-style playing cards to its hand in this release, including text-file-based configuration, much tighter security defaults, user-level instead of administrator-level privileges, and a kernel-mode HTTP request handler and cache.
hackers, start your engines...
From the USPTO site:
For over 200 years, the basic role of the Patent and Trademark Office (PTO) has remained the same: to promote the progress of science and the useful arts by securing for limited times to inventors the exclusive right to their respective discoveries.
As much as I agree that this is a laudable goal, I think it's obvious from this case and others that in today's high-paced climate, patents often serve to do exactly the opposite.
The truth of the matter is that after 20 years, modern technology is most likely so far behind the curve that it's useless or, at best, so developed that no right-minded business is willing to spend anything on it's continued development. Thus, patents such as these no longer serve to give a small advantage to inventors and protect fledgling technology. Rather, they tend to provide a means for the Chucks of the world to significantly inhibit development for the entire useful life of the technology. This isn't the industrial age anymore; to think that 20 years still represents a "limited time" is both ignorant and counterproductive.The current emphasis on low power CPU's isn't an effort to reverse the power consumption trend, merely to slow it down. In most cases, power consumption offsets performance. Historically, designers have almost always favored performance, resulting in power consumption varying roughly with clock speed (P~af^2) squared for the same family of chip. Current efforts are to bring that closer to a linear relationship (P~af). However, even in this "ideal" relationship, faster chips will use more power (and while you're right about a general shift in priorities, don't kid yourself for a minute that the market will altogether stop demanding faster CPUs anytime soon). While it is technically feasible to make a faster chip use less power (provided the original chip is reasonably inefficient), it is extremely difficult and costly (TTM, R&D efforts, material cost, chip size, etc.).
A second issue is miniturization, since the issue we are concerned about here is not necessarily power consumption, but temperature. Even if we assume that power consumption will stay the same, if we make the chip with half the surface area, then the power dissipation per unit area (roughly proportional to temperature) will double. Thus, even without increasing the power consumption, we run into issues that can only be addressed by advanced cooling systems such as this.
scot
two things:
In my opinion, these two things (and others) make the 3G/WiFi situation and the AirPhone/cell phone situation sufficiently different to render any parallels between them inconclusive. There are other factors at work here well outside of the scope of the permanet/nearlynet concept.
scot
BTW, in reference to the flat v. metered rate issue, most people who are familiar with both markets agree that cell phone customers in the US are getting screwed by the (essentially flat rate, for most people) approach to billing compared to the (entirely metered) approach used in Europe and elsewhere.