Those guys think they are entitled to prevent people from reverse engineering their protocols and shut down open-source projects that implement those protocols. Unfortunately, according to the law, they may be right.
It still doesn't mean we shouldn't boycott them for using the DMCA to shut down the bnetd Free Software project.
Boycott Blizzard, they are a copyright-abusing company.
This list is a joke. If I held it to the same standard that Microsoft is held against, every item in that list would have to be removed.
No, your reply is a joke, not a single thing you claim is true.
Software installation: it's all been done before, and done better.
Oh, why don't you show me one system that does this then? A single non-Open Source system?
GUI: - Desktop/Network integration: see IE & Explorer, and yes copying from one FTP window to the other DOES WORK You haven't really tried it have you? FTP explorer windows are limited to copying to local folders and otherwise work somewhat different from local file browsers. Also, sometimes "ftp://..." opens up an index.html-alike page. Other Explorer-like file-systems in Windows also behave different from the local file-system. In KDE, all file systems served from any protocol work alike.
- "Applets" -- You got the copied part right, but in the wrong direction
Oh really? Show me where I can find panel applets for Windows, and the date from which they exist?
Password wallets: it's been done; they're a horrible idea and have fortunately never caught on
Why don't you back it up? Anyhow, who gives a damn about whether or not you think it is a good idea? Its Open Source innovation.
tabbed commandline consoles... see firefox (the only OSS project which has done anything innovative lately)
Eh? FireFox does tabbed browsing, not tabbed command-lines. KDE in fact generalized the concept of "tabbed windows" into all of their applications, including the command line console emulation.
desktop customization: see explorer Again, you throw statements in the air without backup. Show me how I can customize my desktop's behaviours such as:
Click/double-click to activate icons.
Shortcut keys that control window management (minimize/maximize/etc).
Application launch feedback
Splash (login) Screen
The Window decorations, placing the close/minimize/maximize buttons where-ever I want.
etc/etc.
"division of responsibility"? That isn't "innovative", that's pure common sense
Oh, so why didn't Microsoft do it?
search feature... adding the ability to search through a large list is hardly innovative
"Obviousness" is a silly criterion for innovation. The Wheel, the Screw and Screwdriver, and many other genius inventions are "obvious". But it takes a smart man to recognize and apply the obvious.
Dev tools: - diffing and patching has been around since the dawn of time
Oh really? Show me an automated patch tool before Larry Wall's patch?
gcc: cross platform compilers are nothing new, and multiple languages through one compiler was done ages ago by Microsoft
Show me a compiler as portable and language-supportive as gcc, instead of throwing empty statements in the air.
xemacs: a large featureset != innovation
xemacs is not only a large featureset, but also the entire platform of writing an editor in a dynamic environment, and extending the editor in a dynamic fashion by working and developing in the same environment the editor lives in! This is innovative and has made extending emacs easy enough that many people did it. In fact, this is why it is the largest featureset. Not only this, but xemacs contains countless innovations such as dynamic-word-completion, context-sensitive completions, searchable lists of commands, powerful key bindings, multi-display frames, etc. etc. And these are all features emacs had many years ago.
Python, Perl, Ruby: Perl is hardly a new development in the OSS community, dating back to 1987. Ruby and Python are just different versions of Perl.
A. Nope, only few of the desktop features were inherited from propietary Unix. B. diff may have been in Unix, but patch is Larry Wall's creation, for which he got aways from Open Source organizations. C. "Innovation" does not mean "invention". Applying existing technologies and discoveries to create new implementations that do what was not possible before - is also innovation. gcc's portability makes new things possible. D. Python, Perl and Ruby have invented many features of their own, as well as incorporated existing features in innovative ways. E. About TeX I agree, its another very nice Open Source technical innovation.
Technical innovation from opensource
on
Ballmer on Innovation
·
· Score: 3, Informative
Lets see, Software installation management:
A central repository of packages, and a GUI with more than 10000 packages, all installable with 2 clicks.
Automatic upgrading of all these packages.
Uniform interface to install, remove or upgrade all of these packages.
Automatic installation of packages according to file access attempts (auto-apt).
GUIs:
Desktop/network integration (i.e: ftp exploration works just like local file exploration) (and no, this does not work, not even in Windows XP, try copying files from one ftp to another, for example).
Panel applets bringing usefulness to the panel, as well as quick browsers/bookmark lists in the panel (Microsoft copied some of this)
Tabbed command-line consoles
Password-keeping wallets for all applications, allowing the user to remember just one password
Customization of desktop behavior, shortcut keys to basic operations such as minimizing/maximizing, and any other feature in the desktop.
Division of responsibility, window management keeps working even when applications hang.
Search feature in Configuration Manager.
Countless other innovations
Development tools:
The diff/patch tools.
gcc: A single compiler handling the compilation of a huge collection of languages, in a large set of platforms.
xemacs: An environment platform that allows extensions via a dynamic language with seamless on-the-fly compilation of the extension code you write. Also, the most featureful platform out there for this purpose, with powerful macro recorders/editors, customizable key binding, etc.
Languages: Python, Perl, Ruby. Microsoft is still behind in this area, despite its.NET technology, which is less innovation, and more an extension of the Java platform (I would even say, Java done right). Many more languages are Open Source, but I simply don't recall the exact history of other language to tell for sure.
Vast libraries in each of these languages, many of which are filled with technical innovation (i.e: Twisted Matrix, SDL, pygame)
Transparent RPC's for: Python, Ruby, Smalltalk. Microsoft, to the best of my knowledge, does not implement a single transparent RPC. (Transparent means that the server needs not be aware of what objects the client will use, nor does it require any code to explicitly export the object's features to the client, as Microsoft's COM/.NET technologies require).
Emulation:
CoLinux: Modifying the Linux Kernel to run in kernel-mode side-by-side a host operating system.
bochs: Unprivileged, 100% user-space emulation of an entire PC.
qemu: Like bochs, but with dynamic code translation.
All in all, I may have misattributed a few innovations, but most of these are from Open Source. Also, there are many others I can't remember or simply don't know. Microsoft has done less innovation than Open Source, that much is obvious.
I would appriciate information fillers on innovations from other projects I'm less familiar with, such as Apache, the Kernel.
I am pretty sure Ballmer really believes what he says, because most people, surely Microsoft employees, are quite ignorant of Opensource offerrings and their innovations.
Show me an implementation of transparent rpc in Scheme, and I'll show you how its not really a Scheme. Or maybe Scheme really defines a way to control built-in operations on objects such that transparent proxies are implementable - but I doubt it.
Try using (car some-xml-rpc-object) and see what that yields (when some-xml-rpc-object should actually represent a list in the other end).
I find the indentation level syntax of Python to be vile, probably because I started as a Fortran programmer. There also seem to be a lot of gratuitous colons.
The whitespace grows on you:-)
Once you realize how much block-close-character noise it saves you (because you do indent anyway), you love it.
The colons are openers of nested code. They serve important purposes:
It shows that this is a hierarchic construct and that there is code "under" the statement. It can also be unindented, in which case it is also conveying critical information (if x: y = 2).
The editor and reader knows that what follows a line that ends with a colon should be indented.
Also, in a 4 line program, 2 colons doesn't seem like a "lot" to me, and they contribute greatly to readability.
You cannot undefine primative procedures like car/cdr to mean something else. But there is nothing preventing you from defining my:car and handling any combination of arguments and types you want. This is a lot nicer than C++ where you have to use clunky templates. In Scheme, procedures that smoothly handle multiple types and numbers of arguments are built right in.
Well, this is a problem. In Python, almost all access to objects is done through methods of the object. When converting the object to a string in order to print it, its __str__ method is called. When trying to evaluate it as True/False for a conditional, its __nonzero__ method is called. When an attribute in the object is looked up, __getiter__ is called. This allows me to "hook" those operations, and manipulate the way the object is accessed.
This is a very powerful feature, that enabled me to write PyInvoke, for example.
I can create Proxy objects that redirect almost all operations done with them to a server. With Scheme, I would not be able to implement this, because I couldn't Proxy a list object, as a (car proxy) access would not be interceptable in order to forward to a server.
This means transparent RPC is possible in Python and not in Scheme.
I am surrounded by Python users, that is true.
Some of those Python users used to be Perl users, but they were all convinced that Python is simply better.
Perl has at least 5 jaw-dropping mis-features, each by itself ruling out the language for practical use:
The "scalar" type encompassing all of the different basic types creating a horrible weak-typed system (i.e ("Hello" + 1 == 1)). Also, this requires developers to remember hundreds of operators because operators are not polymorphic!
Informal parameter passing (via $_ or shift or such), awful! This one is only partially-horrible because most programmers work around it by specifying their parameters in the first function line. Though auto-documentation and reflection are still difficult.
The "scalar" type is the only one that can sit inside a hash. This requires using "references" as scalars. Such references are not ref-counted properly, and some objects may disappear because the hash doesn't keep track of them properly, ugh!
Perl lacks class definitions, and instead uses a "bless" operation. This means you cannot easily understand in a piece of code what classes are defined, what methods these have, etc. Also, it takes more code to define classes in Perl than in other languages because of this.
The syntax is HUGE and reading random Perl code without a Perl manual nearby is nearly impossible.
Ugly? Why? Python code tends to have no syntax noise at all, and looks very clean.
For example: def fibonacci(a, b):
while True:
yield a
a, b = b, a+b
My hobby language is Scheme, but that is definitely a minority preference, and I have given up hope that it will be a widely used for Linux "glue" programming.
Scheme is very cute. But I always missed a few features in it (tell me if I just missed them):
The ability to overload the behavior of standard functions (such as car/cdr) on objects I define.
The ability to create new "sequence" types or other types by adhering to a protocol (as in Python, by implementing __iter__ or __getitem__ in an object).
Consider a set of routers routing packets through a bottleneck. When their buffers are full, they drop incoming traffic. Without your scheme, that traffic is simply lost and must be retransmitted. This doubles the latency on some packets, but no packet sits in a buffer for very long so all packets which actually arrive are delivered with low latency. With your scheme, routers send back NACKs when they drop a packet and the sending router retransmits. No packets are dropped inside the network (instead they are NACK'd at the outside when buffers are full), but packets spend longer in router buffers (waiting for the next router in line to make space in its buffer) so the average latency for packets which actually arrive increases. There is no free lunch here.
This is simply wrong:
You only wait until the next hop has room for your packet in the buffer, this is typically a no-wait operation (0 time). When it is not, the alternative (in current IP, is losing the packet and doubling or tripling its latency).
The periods of wait are not long unless the next link's bandwidth cannot keep up with the previous, in which case simple transmission control should help and without it you are very screwed anyways.
Mandating a certain approach at the IP level is misguided. Let it be decided at the transport layer where the decision belongs.
This is not really an argument, it is your conclusion re-stated.
On some networks, packet corruption/loss may be common and retransmission is necessary for decent performance. For example, wireless network protocol actually do implement extensive retransmission features. On some other types of networks, corruption is practically unheard of and so retransmission provides no benefit.
When there is no packet loss, the small buffer size is limited by the bandwidth of the link multiplied by its latency, which is a very small number for a single link (because a single link typically has very low latencies). So the payment is negligible.
When the payment is large - the alternative is worse.
You could still enjoy the "default port" feature by having a host suffix address of zeros, that is replaced by a standard address of a service.
For example, a full entity address can be used or given in DNS addressing a specific application as I said, or a partial address (host address) can be used, in which case the suffix of zeros is replaced with a specific entity.
This is also cool because it allows having a default ssh box of any arbitrary subnet, not just a specific host.
So in fact, instead of typing:
ssh -C shells.sourceforge.net
You would type:
ssh -C sourceforge.net
And the sourceforge.net address, which addresses a whole subnet, would have its lower part of the address replaced by a default string naming ssh that addresses a specific entity in a specific host. If the DNS so desires, though, it still has the power to fill those zeros with actual values.
This combines the advantages of both worlds, with some new ones.
Right now it is optional. I want it mandatory (by including it in TCP/IP for example), so that one can rely on the low latencies it would achieve, and to increase efficiency.
Ports are layer 4 because that's where they put them, not because of any inherent feature. Ports are logically just part of the entity's address you're talking to.
Doing data transfers over raw IP talks with a host, and not an entity within a host. I am proposing having addressing of entities inside hosts be part of the IP address itself.
In my case, a daemon would still listen via a single socket. Instead of binding the socket to a certain (address,port) pair, it would bind it to an address alone, so the daemons would actually be simpler. Each server would "internally route packets" just like it does with ports, only using the low address bits of the IP address itself.
What I am proposing is very similar to what exists today, only with less concepts. Simply think about it as moving the bits that currently represent the port into the IP itself, and you can get rid of UDP altogether and still talk with specific entities _in_ hosts, rather than just hosts. Also, you can simplify TCP as ports become implemented by the IP layer itself.
This leads to more powerful DNS, simply because it is more logical to not divide the address into several different concepts. And port is part of the address.
It's not necessary or desirable to have retransmission at the IP level. Firstly, it would put a humongous burden on routers because they would have to keep packets in memory after they have been sent, in case they need to be retransmitted. This would only make "load issues" worse and result in *more* packets being dropped, not less. Secondly, the correct response to packet loss on a link is to route around the link, not to retransmit over the link and produce more congestion. Routing around the link will not only reduce current packet loss but reduce future loss as well by evening out the load. This makes any packet loss due to congestion temporary, unless there is one link that can't be routed around (a bottleneck). In this case, retransmitting still can't help you because there simply isn't enough bandwidth to satisfy user demands. Some packets will be eventually dropped *no matter what*, and the only solution is to add more bandwidth.
The memory required in order to retransmit packets over a single link to a neighbor is negligible, because the latency of a single link is very small (compared to a whole route) and thus ack's arrive very fast (amount of unacked data is very small). If they don't, then retransmission can occur instantly. Transmission control can propagate to neighbours when the load is too high on the links. The latency added for packets that check out fine should also be negligble because checksum'ing in hardware is very fast.
I agree that TCP must be able to handle packet loss as well, its just that when it is the only entity that does, you get two problems: A. Inefficiency, re-routing through whole routes when packets are lost. B. Huge latency payments for every lost packet.
The latency payment when the link retransmits is just a single link's latency multipled by 2 at worst (rather than the latency of the whole route + route-size-unknown-factor).
IPv6, to me, was a bit of a disappointment because it lacks two features that I find important:
A) A protocol between the ordinary level2 and IP(level3) (Could be named layer 2.5) that takes care of error-corrections via retransmissions. Not replacing TCP's error-correcting retransmissions, but in addition to those. The reason is that most lost packets are lost packets on a single link because of load issues and such, and not because a whole link falls and breaks a route. In those cases, it is very inefficient to retransmit the whole route, and to add a huge latency-overhead to the packet transmission.
B) Get rid of the silly "port" concept. Ports are just internal-computer addresses, and as such, should simply be part of the address itself. There should be no reason to distinguish between the network address and the host address and thus subnets were created, and that separation no longer exists. Just the same, there should be no reason to distinguish between net/host address an application addresses. Removing the "port" concept and placing it as part of the IP address itself has the following benefits:
I) UDP becomes redundant to IP itself, the whole protocol is about adding the port address and can be discarded.
II) DNS entries can point to applications and not hosts. This would allow www.server.com and www2.server.com to point to different webservers in the same computer. This would allow to discard the "virtual web hosts" feature. It would also allow to support multiple servers of any type (ftp, smtp, etc) on any host, all pointed by dns, without messing with the port supplied to the user.
III) An internal network can route the same application address to any host it chooses, easing the distribution of load. It would also not expose to the external world how applications are served on which hosts.
Anyhow, I look forward to seeing those features in IPv7.
Without copyright, the GPL loses it power. But without copyright, the GPL does not need power.
Microsoft will lose its incentive to create a closed variant of a GPL'd program because it would not be proprietary and they could not gain much from it.
Slashdot Mirror
We should all boycott Blizzard for using the DMCA to shut down bnetd.
Those guys think they are entitled to prevent people from reverse engineering their protocols and shut down open-source projects that implement those protocols. Unfortunately, according to the law, they may be right.
It still doesn't mean we shouldn't boycott them for using the DMCA to shut down the bnetd Free Software project.
Boycott Blizzard, they are a copyright-abusing company.
Linux could have an even better system than this. I'd like a list of my installed apps, with their data directories and configs.
/mnt/network_drive/installed_packages
/mnt/network_drive/installed_packages
If you're running Debian (or a Debian-based) distro, you can.
Correct me if I'm wrong but I think the commands are:
dpkg --get-selections >
dpkg --set-selections <
And then:
apt-get dselect-upgrade
Its a bit ironic that they are willing to consider the death sentence for hackers, but not willing to consider switching to another operating system.
No, your reply is a joke, not a single thing you claim is true.
Software installation: it's all been done before, and done better.
Oh, why don't you show me one system that does this then? A single non-Open Source system?
GUI:
- Desktop/Network integration: see IE & Explorer, and yes copying from one FTP window to the other DOES WORK
You haven't really tried it have you? FTP explorer windows are limited to copying to local folders and otherwise work somewhat different from local file browsers. Also, sometimes "ftp://..." opens up an index.html-alike page.
Other Explorer-like file-systems in Windows also behave different from the local file-system. In KDE, all file systems served from any protocol work alike.
- "Applets" -- You got the copied part right, but in the wrong direction
Oh really? Show me where I can find panel applets for Windows, and the date from which they exist?
Password wallets: it's been done; they're a horrible idea and have fortunately never caught on
Why don't you back it up? Anyhow, who gives a damn about whether or not you think it is a good idea? Its Open Source innovation.
tabbed commandline consoles
Eh? FireFox does tabbed browsing, not tabbed command-lines. KDE in fact generalized the concept of "tabbed windows" into all of their applications, including the command line console emulation.
desktop customization: see explorer
Again, you throw statements in the air without backup.
Show me how I can customize my desktop's behaviours such as:
"division of responsibility"? That isn't "innovative", that's pure common sense
... adding the ability to search through a large list is hardly innovative
Oh, so why didn't Microsoft do it?
search feature
"Obviousness" is a silly criterion for innovation. The Wheel, the Screw and Screwdriver, and many other genius inventions are "obvious". But it takes a smart man to recognize and apply the obvious.
Dev tools:
- diffing and patching has been around since the dawn of time
Oh really? Show me an automated patch tool before Larry Wall's patch?
gcc: cross platform compilers are nothing new, and multiple languages through one compiler was done ages ago by Microsoft
Show me a compiler as portable and language-supportive as gcc, instead of throwing empty statements in the air.
xemacs: a large featureset != innovation
xemacs is not only a large featureset, but also the entire platform of writing an editor in a dynamic environment, and extending the editor in a dynamic fashion by working and developing in the same environment the editor lives in! This is innovative and has made extending emacs easy enough that many people did it. In fact, this is why it is the largest featureset. Not only this, but xemacs contains countless innovations such as dynamic-word-completion, context-sensitive completions, searchable lists of commands, powerful key bindings, multi-display frames, etc. etc. And these are all features emacs had many years ago.
Python, Perl, Ruby: Perl is hardly a new development in the OSS community, dating back to 1987. Ruby and Python are just different versions of Perl.
Wow, now you got me thinking that you are a troll
Indeed, I would agree Microsoft's IDE's are innovative. They are even very innovative. They also suck, but there is no contradiction :-)
A. Nope, only few of the desktop features were inherited from propietary Unix.
B. diff may have been in Unix, but patch is Larry Wall's creation, for which he got aways from Open Source organizations.
C. "Innovation" does not mean "invention". Applying existing technologies and discoveries to create new implementations that do what was not possible before - is also innovation. gcc's portability makes new things possible.
D. Python, Perl and Ruby have invented many features of their own, as well as incorporated existing features in innovative ways.
E. About TeX I agree, its another very nice Open Source technical innovation.
I already talked about this in this comment.
GUIs:
Development tools:
Emulation:
All in all, I may have misattributed a few innovations, but most of these are from Open Source. Also, there are many others I can't remember or simply don't know. Microsoft has done less innovation than Open Source, that much is obvious.
I would appriciate information fillers on innovations from other projects I'm less familiar with, such as Apache, the Kernel.
I am pretty sure Ballmer really believes what he says, because most people, surely Microsoft employees, are quite ignorant of Opensource offerrings and their innovations.
XML rpc is not transparent rpc.
Show me an implementation of transparent rpc in Scheme, and I'll show you how its not really a Scheme. Or maybe Scheme really defines a way to control built-in operations on objects such that transparent proxies are implementable - but I doubt it.
Try using (car some-xml-rpc-object) and see what that yields (when some-xml-rpc-object should actually represent a list in the other end).
The whitespace grows on you
Once you realize how much block-close-character noise it saves you (because you do indent anyway), you love it.
The colons are openers of nested code. They serve important purposes:
Also, in a 4 line program, 2 colons doesn't seem like a "lot" to me, and they contribute greatly to readability.
You cannot undefine primative procedures like car/cdr to mean something else. But there is nothing preventing you from defining my:car and handling any combination of arguments and types you want. This is a lot nicer than C++ where you have to use clunky templates. In Scheme, procedures that smoothly handle multiple types and numbers of arguments are built right in.
Well, this is a problem. In Python, almost all access to objects is done through methods of the object. When converting the object to a string in order to print it, its __str__ method is called. When trying to evaluate it as True/False for a conditional, its __nonzero__ method is called. When an attribute in the object is looked up, __getiter__ is called. This allows me to "hook" those operations, and manipulate the way the object is accessed.
This is a very powerful feature, that enabled me to write PyInvoke, for example.
I can create Proxy objects that redirect almost all operations done with them to a server. With Scheme, I would not be able to implement this, because I couldn't Proxy a list object, as a (car proxy) access would not be interceptable in order to forward to a server.
This means transparent RPC is possible in Python and not in Scheme.
The GPL is a way to fight fire with fire.
Without copyright, there is no need to fight it.
To simplify: If there's no legal way to place restriction on others, there's no need to restrict the restriction.
Ugly? Why? Python code tends to have no syntax noise at all, and looks very clean.
For example:
def fibonacci(a, b):
while True:
yield a
a, b = b, a+b
My hobby language is Scheme, but that is definitely a minority preference, and I have given up hope that it will be a widely used for Linux "glue" programming.
Scheme is very cute. But I always missed a few features in it (tell me if I just missed them):
Yeah, what a huge advantage not mandating \n's is isn't it??
You got it all right, except:
Python, of course.. Rarely do I find anyone who thinks Perl is a sane choice for anything more than a 5-liner...
This is simply wrong:
You only wait until the next hop has room for your packet in the buffer, this is typically a no-wait operation (0 time). When it is not, the alternative (in current IP, is losing the packet and doubling or tripling its latency).
The periods of wait are not long unless the next link's bandwidth cannot keep up with the previous, in which case simple transmission control should help and without it you are very screwed anyways.
Mandating a certain approach at the IP level is misguided. Let it be decided at the transport layer where the decision belongs.
This is not really an argument, it is your conclusion re-stated.
On some networks, packet corruption/loss may be common and retransmission is necessary for decent performance. For example, wireless network protocol actually do implement extensive retransmission features. On some other types of networks, corruption is practically unheard of and so retransmission provides no benefit.
When there is no packet loss, the small buffer size is limited by the bandwidth of the link multiplied by its latency, which is a very small number for a single link (because a single link typically has very low latencies). So the payment is negligible.
When the payment is large - the alternative is worse.
You could still enjoy the "default port" feature by having a host suffix address of zeros, that is replaced by a standard address of a service.
For example, a full entity address can be used or given in DNS addressing a specific application as I said, or a partial address (host address) can be used, in which case the suffix of zeros is replaced with a specific entity.
This is also cool because it allows having a default ssh box of any arbitrary subnet, not just a specific host.
So in fact, instead of typing:
ssh -C shells.sourceforge.net
You would type:
ssh -C sourceforge.net
And the sourceforge.net address, which addresses a whole subnet, would have its lower part of the address replaced by a default string naming ssh that addresses a specific entity in a specific host.
If the DNS so desires, though, it still has the power to fill those zeros with actual values.
This combines the advantages of both worlds, with some new ones.
Indeed it is computable, but not via 22 and 7...
Right now it is optional. I want it mandatory (by including it in TCP/IP for example), so that one can rely on the low latencies it would achieve, and to increase efficiency.
Ports are layer 4 because that's where they put them, not because of any inherent feature. Ports are logically just part of the entity's address you're talking to.
:)
Doing data transfers over raw IP talks with a host, and not an entity within a host. I am proposing having addressing of entities inside hosts be part of the IP address itself.
In my case, a daemon would still listen via a single socket. Instead of binding the socket to a certain (address,port) pair, it would bind it to an address alone, so the daemons would actually be simpler. Each server would "internally route packets" just like it does with ports, only using the low address bits of the IP address itself.
What I am proposing is very similar to what exists today, only with less concepts. Simply think about it as moving the bits that currently represent the port into the IP itself, and you can get rid of UDP altogether and still talk with specific entities _in_ hosts, rather than just hosts. Also, you can simplify TCP as ports become implemented by the IP layer itself.
This leads to more powerful DNS, simply because it is more logical to not divide the address into several different concepts. And port is part of the address.
A win-win proposition
It's not necessary or desirable to have retransmission at the IP level. Firstly, it would put a humongous burden on routers because they would have to keep packets in memory after they have been sent, in case they need to be retransmitted. This would only make "load issues" worse and result in *more* packets being dropped, not less. Secondly, the correct response to packet loss on a link is to route around the link, not to retransmit over the link and produce more congestion. Routing around the link will not only reduce current packet loss but reduce future loss as well by evening out the load. This makes any packet loss due to congestion temporary, unless there is one link that can't be routed around (a bottleneck). In this case, retransmitting still can't help you because there simply isn't enough bandwidth to satisfy user demands. Some packets will be eventually dropped *no matter what*, and the only solution is to add more bandwidth.
The memory required in order to retransmit packets over a single link to a neighbor is negligible, because the latency of a single link is very small (compared to a whole route) and thus ack's arrive very fast (amount of unacked data is very small). If they don't, then retransmission can occur instantly. Transmission control can propagate to neighbours when the load is too high on the links.
The latency added for packets that check out fine should also be negligble because checksum'ing in hardware is very fast.
I agree that TCP must be able to handle packet loss as well, its just that when it is the only entity that does, you get two problems:
A. Inefficiency, re-routing through whole routes when packets are lost.
B. Huge latency payments for every lost packet.
The latency payment when the link retransmits is just a single link's latency multipled by 2 at worst (rather than the latency of the whole route + route-size-unknown-factor).
IPv6, to me, was a bit of a disappointment because it lacks two features that I find important:
A) A protocol between the ordinary level2 and IP(level3) (Could be named layer 2.5) that takes care of error-corrections via retransmissions. Not replacing TCP's error-correcting retransmissions, but in addition to those. The reason is that most lost packets are lost packets on a single link because of load issues and such, and not because a whole link falls and breaks a route. In those cases, it is very inefficient to retransmit the whole route, and to add a huge latency-overhead to the packet transmission.
B) Get rid of the silly "port" concept. Ports are just internal-computer addresses, and as such, should simply be part of the address itself. There should be no reason to distinguish between the network address and the host address and thus subnets were created, and that separation no longer exists. Just the same, there should be no reason to distinguish between net/host address an application addresses. Removing the "port" concept and placing it as part of the IP address itself has the following benefits:
I) UDP becomes redundant to IP itself, the whole protocol is about adding the port address and can be discarded.
II) DNS entries can point to applications and not hosts. This would allow www.server.com and www2.server.com to point to different webservers in the same computer. This would allow to discard the "virtual web hosts" feature. It would also allow to support multiple servers of any type (ftp, smtp, etc) on any host, all pointed by dns, without messing with the port supplied to the user.
III) An internal network can route the same application address to any host it chooses, easing the distribution of load. It would also not expose to the external world how applications are served on which hosts.
Anyhow, I look forward to seeing those features in IPv7.
Without copyright, the GPL loses it power.
But without copyright, the GPL does not need power.
Microsoft will lose its incentive to create a closed variant of a GPL'd program because it would not be proprietary and they could not gain much from it.