The basic component in the internet are the routers which have no hierarchy if we look at the domain of a single ISP or backbone provider. All routers are basically at the same level. This means that information can use the shortest path from point A to point B in the network.
In contrast to this the structure of mobile (data) networks I know is hierarchical and basically all traffic of the network is concentrated at a single point. In order to transport the traffic from this single point to the mobile IP packets are encapsulated in a tunneling protocol and directed to the proper radio cells. In the mobile phones the encapsulated packets are decapsulated and e.g. transmitted to a laptop.
Therefore traffic enters the network basically always at the same point, regardless of where the user is located. By means of implementing this behavior in a possible next version of the IP you lose a lot of advantages which are available with IPv4 as there are error protection by means of re-routing or a equal distribution of the traffic all over the network.
Mobile IPv4 and IPv6 already provides much of the features present in a cell network. But there are few problems:
Using (e.g.) WIFI it is very hard to get the same quick handover performance which is available in cell networks
Since WIFI operates in an unlicenced band you can not give guarantees about the delivery of the traffic.
Routers have to be equipped with the Mobile IP stack and need to track every single user
IMHO the requirements of a new protocol for military use are very different from these offered by cell networks.
In our company we use a MS exchange email server. This server has the annoying behaviour that if a message arrives which has an unknown charset and is not 7bit clean, the body is mime-attached and the body is replaced with a message saying this email is not 7bit clean (or UTF, or something different). The reason for this decision is beyound my knowledge, maybe it is due to some outlook internal properties.
A lot of important messages have arrived this way with the need for opening the attachment for reading the actual message. So a lot of users in our company have "learned" how to read this attached messages. In other words the worm uses this learned behaviour in order to get "installed".
Since there are dozens of executeable extensions (.src,.bat,...) one it might be hard for some person to decide what attachments not to open. This and the fact that MS-users are used to have intuitive useable applications (which is not per se a bad thing) might be a reason that this worm is extraordinary successful.
Under *nix we use specialised tools which do the job best:
Have a look at this. One may also have a look at the README which describes the uses of this tool:)
My theory is as follows: In order provide Macrovision for DVD playback, matrox (as well as other companies) needs to add tv-out chips on the graphic cards which support Macrovision. As we all know Macrovision is patented and you have to sign contracts before you are allowed to use Macrovision.
Maybe there is a requirement in this contract which says that no one must be able write a driver where macrovision on the output will be activated without paying licensing fees. If the soure for tv-out is open this requirement would not be met since a different comany can use the matrox cards (don't ask me what kind of comany this would be) for getting macrovision output.
AFAIK the documentation for a lot of macrovision enabled tv-out chips is available online, maybe even for the matrox one. So matrox has the only possibility of meeting the requirements by means of not releasing the tv-out specs.
I don't think that it is easy for an ISP to block a freenet port since freenet chooses a random port for every new installation. Your port number is distributed through freenet. Therefore establishing your node on freenet is a slow process.
And if your port is ever blocket you might move to another port. So, its definitely _not_ easy for an IPS to block freenet and you have a public IP.
Did you know that even the "nicest" linux processes, as the d.net client is, consume at least 10% of the processing time? I find that annoying.
The reason is the lack of a real IDLE scheduling facility in the linux kernel. I waited for this feature since I first run the d.net client, but it never has been implemented.
Hopefully this will happen sometime in the future. But until then, even the d.net client costs quite an amount of cpu resources.
Slashdot Mirror
Seems to be on-topic. But beware, it's rude :)
http://www.youtube.com/watch?v=6D7rWLzloOI
In contrast to this the structure of mobile (data) networks I know is hierarchical and basically all traffic of the network is concentrated at a single point. In order to transport the traffic from this single point to the mobile IP packets are encapsulated in a tunneling protocol and directed to the proper radio cells. In the mobile phones the encapsulated packets are decapsulated and e.g. transmitted to a laptop.
Therefore traffic enters the network basically always at the same point, regardless of where the user is located. By means of implementing this behavior in a possible next version of the IP you lose a lot of advantages which are available with IPv4 as there are error protection by means of re-routing or a equal distribution of the traffic all over the network.
Mobile IPv4 and IPv6 already provides much of the features present in a cell network. But there are few problems:
- Using (e.g.) WIFI it is very hard to get the same quick handover performance which is available in cell networks
- Since WIFI operates in an unlicenced band you can not give guarantees about the delivery of the traffic.
- Routers have to be equipped with the Mobile IP stack and need to track every single user
IMHO the requirements of a new protocol for military use are very different from these offered by cell networks.In our company we use a MS exchange email server. This server has the annoying behaviour that if a message arrives which has an unknown charset and is not 7bit clean, the body is mime-attached and the body is replaced with a message saying this email is not 7bit clean (or UTF, or something different). The reason for this decision is beyound my knowledge, maybe it is due to some outlook internal properties.
.bat, ...) one it might be hard for some person to decide what attachments not to open. This and the fact that MS-users are used to have intuitive useable applications (which is not per se a bad thing) might be a reason that this worm is extraordinary successful.
A lot of important messages have arrived this way with the need for opening the attachment for reading the actual message. So a lot of users in our company have "learned" how to read this attached messages. In other words the worm uses this learned behaviour in order to get "installed".
Since there are dozens of executeable extensions (.src,
Ok, this has nothing to do with Mozilla.
My theory is as follows: In order provide Macrovision for DVD playback, matrox (as well as other companies) needs to add tv-out chips on the graphic cards which support Macrovision. As we all know Macrovision is patented and you have to sign contracts before you are allowed to use Macrovision.
Maybe there is a requirement in this contract which says that no one must be able write a driver where macrovision on the output will be activated without paying licensing fees. If the soure for tv-out is open this requirement would not be met since a different comany can use the matrox cards (don't ask me what kind of comany this would be) for getting macrovision output.
AFAIK the documentation for a lot of macrovision enabled tv-out chips is available online, maybe even for the matrox one. So matrox has the only possibility of meeting the requirements by means of not releasing the tv-out specs.
I don't think that it is easy for an ISP to block a freenet port since freenet chooses a random port for every new installation. Your port number is distributed through freenet. Therefore establishing your node on freenet is a slow process.
And if your port is ever blocket you might move to another port. So, its definitely _not_ easy for an IPS to block freenet and you have a public IP.
Hmm, this is all true aside from the gcc3.1 point. SuSE 8.0 does contain gcc3.0.4, but is compiled using gcc-2.95.3. Maybe 8.1?
Did you know that even the "nicest" linux processes, as the d.net client is, consume at least 10% of the processing time? I find that annoying.
The reason is the lack of a real IDLE scheduling facility in the linux kernel. I waited for this feature since I first run the d.net client, but it never has been implemented.
Hopefully this will happen sometime in the future. But until then, even the d.net client costs quite an amount of cpu resources.