index.html does not have a standard format, making it impossible to write a robust file management application using it. Furthermore, you can't have a site which allows directory browsing and also has a nice default page for web browser users. The directory listing format doesn't necessarily have to be XML, and it probably wouldn't have been if it was in the original HTTP spec, but of course XML is the obvious choice today.
But that's just "bloat, complexity and security problems", right?:)
Yes, it is. WebDAV is HTTP with so much extra junk that it's hardly recognizable. A "few" extra methods? They added like 15 different methods and made it into a super revision control protocol that's going to save the world or something. Very few people actually need all that junk; for everyone else it's just extra bloat and complexity. What that means for users is that WebDAV is not widely implemented or widely used. Where it is used, its extra features are usually ignored. There needs to be something in between HTTP and WebDAV. Something simple and easy to implement, like HTTP is.
Amen. I only wish HTTP had an INDEX method, where you could get a real file/directory index listing in a standard XML format suitable for use in a file manager (where permitted only of course). That, and proper support for the PUT method. It would then truly blow all other file transfer protocols out of the water. Why use FTP, NFS, WebDAV, or SMB with all their bloat, complexity, and security problems when you could just be using good old HTTP which you already know and love? If only the creators of HTTP had seen fit to include an INDEX method, it would have saved us all so much trouble. I don't know why it's never been added by anyone as an extension, either.
You can disable the PDF plugin in Firefox, which causes the normal download window to be displayed instead of embedding the PDF in the browser window. You can do the same for video files in the same place. Go to options, the download section, in the bottom right there is a button labelled simply "plugins". Click the button, then uncheck all the checkmarks in the dialog that comes up (it doesn't actually disable the plugins when they are used inside HTML pages; it just disables embedding them directly into a window). I think this should be the default; it's way less annoying. Firefox 1.5 will have an easier and more obvious way of doing this when it is released with the new options dialog.
On Windows dropping files on the start button will create a shortcut in the start menu without moving the original file. Dropping stuff on the taskbar buttons will result in an annoying error dialog. Dropping stuff on the clock seems to always cancel, so I suppose that's something. Hardly intuitive though. Dropping files on the title bars of Explorer windows is not ignored, it actually moves (or else it copies) them to the folder displayed in the window, above the top of the screen, so they end up hidden and you have to scroll up to see them afterwards (if you noticed that the scroll bar appeared; otherwise you might just assume that the file got lost). Could that be any more dumb?
Escape is a relic of the past. It is not often used in the Windows world any more. No modern program requires you to hit escape. I don't think people trained on today's Windows would try it while in the middle of holding down their mouse button. Of course, as with all usability issues, it really would require a scientific usability test to settle the issue.
I wouldn't want to loose the option to use the escape key
Surely not. But it shouldn't be your only reliable option.
its an event that is all of 4 seconds in the future, surely most users can plan that far ahead?
Following that logic, we wouldn't need undo either. The user has already planned exactly what they wanted, right? Wrong. Users take things one step at a time. "OK, I've grabbed the file, now where did I want to put it?" You can tell the users "oh, you should have thought of that *before* you grabbed the file" but you will have to tell every single user, probably more than once. It's always better to adapt the system to the way users work rather than vice versa.
Fine, if you want to be pedantic about it. I admit error; my assertion should have been that it is not obvious to novices nor is it convenient since it requires two hands, two input devices, and movement from the home row of the keyboard, all while you are holding down a button on the mouse; my argument stands. I dislike vi and emacs equally. I use modern IDEs like Visual Studio, XCode, or KDevelop. When I'm forced to edit on the command line I use mcedit or pico.
Escape isn't a button on the mouse. You shouldn't have to switch input devices to cancel your action. Also, escape can't be hit from the home row of your keyboard, which makes it even worse because you have to look down to find it, then move your whole arm to hit it, even if you do have your non-mouse hand waiting on the keyboard, all the while holding the mouse button down with your other hand so you don't accidentally release the drag.
Doesn't appear to, sorry. I'm looking at Ethereal and I see very little traffic that might be part of a distributed hash table. I'm thinking that BitTorrent is having trouble connecting to the P2P network that is supposed to do the tracking; perhaps the canonical seed nodes are down right now.
OK, that one didn't seem to work. Try this one instead. I've put myself as a network seed in addition to router.bittorrent.com, which I suspect is down. However, this means that once I drop out of the swarm, other people won't join unless they are already a part of the global network. Tracking duties will still be shared, we'll see if this one works.
That sucks. Do trackerless torrents not work? I wondered why I hadn't seen any posted anywhere. I thought it was Bram Cohen's full-time job now to work on this stuff?
Did you try it? I found it annoying and unintuitive, having tried it without reading the directions first.
Firstly, I couldn't immediately figure out how to make the windows fold. Sure, when you move the mouse outside a window it begins to fold slightly. But it folds right back almost instanly, leaving you puzzled. I tried moving them mouse back when I saw the fold, but had no luck. It turned out that I just wasn't fast enough, but I didn't realize it until I went and read the site's directions, figuring I was doing it completely wrong. That definitely needs some work if my grandma is going to figure it out. I'd be surprised if she could even react that fast, not being trained on videogames since childhood. A longer delay is definitely necessary; however this would also be annoying in the common case that a window you didn't want to fold started folding.
The other major problem I had was that it's not easy to unfold large windows, or windows with other windows just behind them. It would be very hard to unfold maximized windows. And if you fold the window over completely it disappears and is impossible to get back. My grandma would be very disturbed if her windows disappeared (she's rather paranoid about losing stuff in the computer).
There's really nothing wrong with the "drag to the taskbar" approach. It's intuitive enough for people who are already familiar with the taskbar. For OS X's genie effect taskbar, it's so intuitive it hurts. The problem is that Windows implements taskbar dragging horribly, making you wait for no reason. The windows should flip instantly, as soon as your mouse is over the button. To avoid upsetting your window order, the windows should resume their original order afterwards (except the drag target should be on top so you can see, edit, or undo the results). And why the hell can't I drop things on taskbar buttons, Microsoft? You didn't change the cursor to indicate so. Surely it can't be too hard to provide an API call to register a drag handler for the taskbar button.
Actually, I dislike drag-and-drop as a UI concept in general, especially between different programs. Once you start dragging it's not always clear how to cancel; I generally move the mouse around randomly until I see the "no" cursor, but it's not always easy to find and sometimes I drop things unexpected places because I thought they wouldn't be "droppable". The results of drag-and-drop operations between windows are not predictable. Files might be copied, moved, or linked. Non-files are usually not supported, and when they are supported the results are often not exactly what you wanted. The position of things after you drop them is rarely what you intended because programs don't provide adequate feedback while dragging. Drag-and-drop is hard on the wrists if you have carpal tunnel.
Some of these problems could be fixed. I'd like it if you could release the mouse button after you start dragging; another click would release the hold, right clicking would cancel (or in some cases bring up a menu; canceling the menu would then cancel the drag). More importantly, though programs should provide *instant*, *completely accurate* feedback about the results of a drag operation. That means that the screen should look the same just before you drop an object you're holding and just after.
Wow, this turned into a major rant. Someday, I'll design my own OS, and fix all these dang problems.
Your argument would be convincing, except that DRM is fatally flawed. Microsoft's DRM will be broken, just as every other widespread DRM scheme protecting valuable content has before it. It won't be able to prevent organized piracy because they have the resources to break the DRM. It won't be able to prevent casual piracy because BitTorrent and P2P make it easy to obtain the products of organized piracy. At best it will inconvenience consumers using legitimately obtained content, make it difficult for libraries and archives and search engines to function, and make fair use illegal.
PlayStation 3's development environment is based on OpenGL. That alone makes it hardly a "niche" API. I believe the GameCube also uses OpenGL and Revolution probably will too.
I admit that my original statement was a bit strong. Having a few conflicting results is unavoidable (a fact that I admit in the original comment), and might even be helpful. But I do believe that too large a number of conflicting experiments indicates that the scientific process is not healthy. And I do believe that 33% is far too large a number.
Look at it this way: suppose you wanted to know with 95% probability that a hypothesis was true, and you did a number of studies which went both ways. Assuming that each study has a 66% probability of being correct, you need to do at minimum 25 different studies, all testing the same hypothesis, before you could say with 95% confidence that the majority of the studies are correct. And there's still a 1/20 chance that you're wrong. You'll need over 50 studies if you want 99% confidence. Should we really need to do 25 different studies on each hypothesis before we have a reasonable probability of truth? Is it any wonder there is so much controversy in areas of science where conflicting results are common? Cutting that error percentage from 33% to 20% would result in only 5 studies being required to reach 95% confidence. Is it really too much to ask, to have 4 out of 5 scientific studies be accurate and not misleading?
Not exactly. Science is supposed to be a series of experiments designed to prove or disprove hypotheses. Having hypotheses disproved is of course a normal part of this process. However, having different experiments prove and disprove the same hypothesis is *not* a normal part of a healthy scientific process. It indicates either an incorrectly formed hypothesis or errors in experimental methods.
Obviously errors are not completely avoidable because people are fallible; that's why we try to reproduce results and practice peer review. But I should think we ought to do better than having 33% of our supposedly "proven" hypotheses eventually disproved by subsequent experiments.
Note that I'm not talking here about trivial things like Netwon's laws of motion being "disproved" by relativity. Relativity is more like a generalization of Newton's laws than a refutation, and that *is* a part of the normal scientific process. I'm talking here about medical studies which come up with conflicting results or the innumerable global warming studies that the scientific community can't make up its mind on (for example).
The periods of wait are not long unless the next link's bandwidth cannot keep up with the previous
Did you miss the part where I stated that was the exact situation I was talking about? That's the very definition of a bottleneck. And did you also miss the part where I noted that bottlenecks are the cause of almost all packet loss on today's Internet? (I am interested in what you think causes most packet loss, if not bottlenecks. It's certainly not transmission errors.) Since your scheme only helps when packet loss is not caused by bottlenecks, and almost all packet loss *is* caused by bottlenecks, it cannot noticably reduce latencies on today's Internet.
There are new, safer fission reactors. The problems are with the old ones, and with public relations. Solar cells have recently come down in cost and are being installed faster than ever, now that energy prices are increasing. Oil prices are rocketing, and that's driving movement to and investment in alternative energy (Isn't it funny how capitalism can actually work sometimes? It may not be as fast as you would like, but don't proclaim its failure prematurely...)
The problem with nuclear rockets is largely in public relations as well. The problem with space travel in general is there's very little compelling need. Space has little usable real estate, questionable resource value, and getting to other stars is impossible for the forseeable future. The things for which a need exists (various useful satellites) are already getting done. Moonbases, space hotels, mars colonies, these things are just not all that practically useful when it comes down to it.
AI: Oh man, I guess I'll have to give you that one. Though I believe the real problem with AI is that we really *don't* have the CPU power that we think we do; the brain does more computing than we give it credit for. In fact, the real problem (IMHO of course) is that computer architecture is completely different from brain architecture. The bottleneck in modern computers is overwhelmingly in the memory system (the famous Von Neumann bottleneck), and I think that's because we're designing computer memories wrong. A memory consisting merely of a sequential list of bytes is far too slow, even with massive caching. We need to learn how evolution solved the memory problem in the brain, and use that solution in a computer memory. Only then will we have the power needed to implement true AI on a computer.
It would not achieve lower latencies unless there was packet loss. But the reasons for packet loss on today's Internet cannot be fixed by your scheme. The vast majority of packet loss is caused by bandwidth bottlenecks, not by transmission errors. Your scheme cannot help in this situation.
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.
Mandating a certain approach at the IP level is misguided. Let it be decided at the transport layer where the decision belongs. 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.
If you're only talking about retransmission at the level of a single link, then that's not a part of IP, and it shouldn't be. Instead it is an optional part of link-layer protocols that IP has nothing to do with. I don't see your point.
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.
As long as packet loss is temporary, then handling it at the TCP level is just fine. Yes, it occasionally introduces latency due to retransmission but it is worth it to keep the network simple. A simple network is more robust and more predictable, with cheaper hardware. Cheaper hardware means more hardware and more bandwidth, which then reduces latency and packet loss overall. This is the correct solution to packet loss problems.
Also, a big reason the Internet is as reliable as it is today is due to its inherent *unreliability*. It's a "worse is better" philosophy. When failures are an everyday occurrance, your failure-handling must be robust. This paradoxically makes the system as a whole more reliable. The Internet is the epitome of this philosophy. Packet loss is a natural and healthy thing for the Internet.
Slashdot Mirror
index.html does not have a standard format, making it impossible to write a robust file management application using it. Furthermore, you can't have a site which allows directory browsing and also has a nice default page for web browser users. The directory listing format doesn't necessarily have to be XML, and it probably wouldn't have been if it was in the original HTTP spec, but of course XML is the obvious choice today.
Yes, it is. WebDAV is HTTP with so much extra junk that it's hardly recognizable. A "few" extra methods? They added like 15 different methods and made it into a super revision control protocol that's going to save the world or something. Very few people actually need all that junk; for everyone else it's just extra bloat and complexity. What that means for users is that WebDAV is not widely implemented or widely used. Where it is used, its extra features are usually ignored. There needs to be something in between HTTP and WebDAV. Something simple and easy to implement, like HTTP is.
Amen. I only wish HTTP had an INDEX method, where you could get a real file/directory index listing in a standard XML format suitable for use in a file manager (where permitted only of course). That, and proper support for the PUT method. It would then truly blow all other file transfer protocols out of the water. Why use FTP, NFS, WebDAV, or SMB with all their bloat, complexity, and security problems when you could just be using good old HTTP which you already know and love? If only the creators of HTTP had seen fit to include an INDEX method, it would have saved us all so much trouble. I don't know why it's never been added by anyone as an extension, either.
You can disable the PDF plugin in Firefox, which causes the normal download window to be displayed instead of embedding the PDF in the browser window. You can do the same for video files in the same place. Go to options, the download section, in the bottom right there is a button labelled simply "plugins". Click the button, then uncheck all the checkmarks in the dialog that comes up (it doesn't actually disable the plugins when they are used inside HTML pages; it just disables embedding them directly into a window). I think this should be the default; it's way less annoying. Firefox 1.5 will have an easier and more obvious way of doing this when it is released with the new options dialog.
On Windows dropping files on the start button will create a shortcut in the start menu without moving the original file. Dropping stuff on the taskbar buttons will result in an annoying error dialog. Dropping stuff on the clock seems to always cancel, so I suppose that's something. Hardly intuitive though. Dropping files on the title bars of Explorer windows is not ignored, it actually moves (or else it copies) them to the folder displayed in the window, above the top of the screen, so they end up hidden and you have to scroll up to see them afterwards (if you noticed that the scroll bar appeared; otherwise you might just assume that the file got lost). Could that be any more dumb?
Escape is a relic of the past. It is not often used in the Windows world any more. No modern program requires you to hit escape. I don't think people trained on today's Windows would try it while in the middle of holding down their mouse button. Of course, as with all usability issues, it really would require a scientific usability test to settle the issue.
Surely not. But it shouldn't be your only reliable option.
its an event that is all of 4 seconds in the future, surely most users can plan that far ahead?
Following that logic, we wouldn't need undo either. The user has already planned exactly what they wanted, right? Wrong. Users take things one step at a time. "OK, I've grabbed the file, now where did I want to put it?" You can tell the users "oh, you should have thought of that *before* you grabbed the file" but you will have to tell every single user, probably more than once. It's always better to adapt the system to the way users work rather than vice versa.
Fine, if you want to be pedantic about it. I admit error; my assertion should have been that it is not obvious to novices nor is it convenient since it requires two hands, two input devices, and movement from the home row of the keyboard, all while you are holding down a button on the mouse; my argument stands. I dislike vi and emacs equally. I use modern IDEs like Visual Studio, XCode, or KDevelop. When I'm forced to edit on the command line I use mcedit or pico.
Escape isn't a button on the mouse. You shouldn't have to switch input devices to cancel your action. Also, escape can't be hit from the home row of your keyboard, which makes it even worse because you have to look down to find it, then move your whole arm to hit it, even if you do have your non-mouse hand waiting on the keyboard, all the while holding the mouse button down with your other hand so you don't accidentally release the drag.
Doesn't appear to, sorry. I'm looking at Ethereal and I see very little traffic that might be part of a distributed hash table. I'm thinking that BitTorrent is having trouble connecting to the P2P network that is supposed to do the tracking; perhaps the canonical seed nodes are down right now.
Well, thanks for testing anyway. Guess it doesn't work. Maybe I'll shoot Bram an email asking why.
OK, that one didn't seem to work. Try this one instead. I've put myself as a network seed in addition to router.bittorrent.com, which I suspect is down. However, this means that once I drop out of the swarm, other people won't join unless they are already a part of the global network. Tracking duties will still be shared, we'll see if this one works.
That sucks. Do trackerless torrents not work? I wondered why I hadn't seen any posted anywhere. I thought it was Bram Cohen's full-time job now to work on this stuff?
Hm, I'm not seeing any uploading happening on my end. Is anybody trying it?
alternate link if the first doesn't work
Firstly, I couldn't immediately figure out how to make the windows fold. Sure, when you move the mouse outside a window it begins to fold slightly. But it folds right back almost instanly, leaving you puzzled. I tried moving them mouse back when I saw the fold, but had no luck. It turned out that I just wasn't fast enough, but I didn't realize it until I went and read the site's directions, figuring I was doing it completely wrong. That definitely needs some work if my grandma is going to figure it out. I'd be surprised if she could even react that fast, not being trained on videogames since childhood. A longer delay is definitely necessary; however this would also be annoying in the common case that a window you didn't want to fold started folding.
The other major problem I had was that it's not easy to unfold large windows, or windows with other windows just behind them. It would be very hard to unfold maximized windows. And if you fold the window over completely it disappears and is impossible to get back. My grandma would be very disturbed if her windows disappeared (she's rather paranoid about losing stuff in the computer).
There's really nothing wrong with the "drag to the taskbar" approach. It's intuitive enough for people who are already familiar with the taskbar. For OS X's genie effect taskbar, it's so intuitive it hurts. The problem is that Windows implements taskbar dragging horribly, making you wait for no reason. The windows should flip instantly, as soon as your mouse is over the button. To avoid upsetting your window order, the windows should resume their original order afterwards (except the drag target should be on top so you can see, edit, or undo the results). And why the hell can't I drop things on taskbar buttons, Microsoft? You didn't change the cursor to indicate so. Surely it can't be too hard to provide an API call to register a drag handler for the taskbar button.
Actually, I dislike drag-and-drop as a UI concept in general, especially between different programs. Once you start dragging it's not always clear how to cancel; I generally move the mouse around randomly until I see the "no" cursor, but it's not always easy to find and sometimes I drop things unexpected places because I thought they wouldn't be "droppable". The results of drag-and-drop operations between windows are not predictable. Files might be copied, moved, or linked. Non-files are usually not supported, and when they are supported the results are often not exactly what you wanted. The position of things after you drop them is rarely what you intended because programs don't provide adequate feedback while dragging. Drag-and-drop is hard on the wrists if you have carpal tunnel.
Some of these problems could be fixed. I'd like it if you could release the mouse button after you start dragging; another click would release the hold, right clicking would cancel (or in some cases bring up a menu; canceling the menu would then cancel the drag). More importantly, though programs should provide *instant*, *completely accurate* feedback about the results of a drag operation. That means that the screen should look the same just before you drop an object you're holding and just after.
Wow, this turned into a major rant. Someday, I'll design my own OS, and fix all these dang problems.
Your argument would be convincing, except that DRM is fatally flawed. Microsoft's DRM will be broken, just as every other widespread DRM scheme protecting valuable content has before it. It won't be able to prevent organized piracy because they have the resources to break the DRM. It won't be able to prevent casual piracy because BitTorrent and P2P make it easy to obtain the products of organized piracy. At best it will inconvenience consumers using legitimately obtained content, make it difficult for libraries and archives and search engines to function, and make fair use illegal.
PlayStation 3's development environment is based on OpenGL. That alone makes it hardly a "niche" API. I believe the GameCube also uses OpenGL and Revolution probably will too.
Look at it this way: suppose you wanted to know with 95% probability that a hypothesis was true, and you did a number of studies which went both ways. Assuming that each study has a 66% probability of being correct, you need to do at minimum 25 different studies, all testing the same hypothesis, before you could say with 95% confidence that the majority of the studies are correct. And there's still a 1/20 chance that you're wrong. You'll need over 50 studies if you want 99% confidence. Should we really need to do 25 different studies on each hypothesis before we have a reasonable probability of truth? Is it any wonder there is so much controversy in areas of science where conflicting results are common? Cutting that error percentage from 33% to 20% would result in only 5 studies being required to reach 95% confidence. Is it really too much to ask, to have 4 out of 5 scientific studies be accurate and not misleading?
Obviously errors are not completely avoidable because people are fallible; that's why we try to reproduce results and practice peer review. But I should think we ought to do better than having 33% of our supposedly "proven" hypotheses eventually disproved by subsequent experiments.
Note that I'm not talking here about trivial things like Netwon's laws of motion being "disproved" by relativity. Relativity is more like a generalization of Newton's laws than a refutation, and that *is* a part of the normal scientific process. I'm talking here about medical studies which come up with conflicting results or the innumerable global warming studies that the scientific community can't make up its mind on (for example).
Did you miss the part where I stated that was the exact situation I was talking about? That's the very definition of a bottleneck. And did you also miss the part where I noted that bottlenecks are the cause of almost all packet loss on today's Internet? (I am interested in what you think causes most packet loss, if not bottlenecks. It's certainly not transmission errors.) Since your scheme only helps when packet loss is not caused by bottlenecks, and almost all packet loss *is* caused by bottlenecks, it cannot noticably reduce latencies on today's Internet.
The problem with nuclear rockets is largely in public relations as well. The problem with space travel in general is there's very little compelling need. Space has little usable real estate, questionable resource value, and getting to other stars is impossible for the forseeable future. The things for which a need exists (various useful satellites) are already getting done. Moonbases, space hotels, mars colonies, these things are just not all that practically useful when it comes down to it.
AI: Oh man, I guess I'll have to give you that one. Though I believe the real problem with AI is that we really *don't* have the CPU power that we think we do; the brain does more computing than we give it credit for. In fact, the real problem (IMHO of course) is that computer architecture is completely different from brain architecture. The bottleneck in modern computers is overwhelmingly in the memory system (the famous Von Neumann bottleneck), and I think that's because we're designing computer memories wrong. A memory consisting merely of a sequential list of bytes is far too slow, even with massive caching. We need to learn how evolution solved the memory problem in the brain, and use that solution in a computer memory. Only then will we have the power needed to implement true AI on a computer.
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.
Mandating a certain approach at the IP level is misguided. Let it be decided at the transport layer where the decision belongs. 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.
If you're only talking about retransmission at the level of a single link, then that's not a part of IP, and it shouldn't be. Instead it is an optional part of link-layer protocols that IP has nothing to do with. I don't see your point.
As long as packet loss is temporary, then handling it at the TCP level is just fine. Yes, it occasionally introduces latency due to retransmission but it is worth it to keep the network simple. A simple network is more robust and more predictable, with cheaper hardware. Cheaper hardware means more hardware and more bandwidth, which then reduces latency and packet loss overall. This is the correct solution to packet loss problems.
Also, a big reason the Internet is as reliable as it is today is due to its inherent *unreliability*. It's a "worse is better" philosophy. When failures are an everyday occurrance, your failure-handling must be robust. This paradoxically makes the system as a whole more reliable. The Internet is the epitome of this philosophy. Packet loss is a natural and healthy thing for the Internet.