this is really a turing machine emulated on a NXT using lego as a physical memory display. This is still cool, but its not "turing machine built out of lego" except by the extreme interpretation that a NXT computer is sold by the lego corporation.
According to the video (which is now working) it reads the state of those lego pieces using an optic sensor. So they are not just used for display, they are used as actual memory. There is no requirement as to how you implement the state machine of a turing machine, except that it has to be final state. And the NXT is final state. So it is a turing machine.
Are you implying that you cannot include an NXT in something and say that it is built out of lego? Surely the NXT is overkill for the task, but I don't think lego is selling components that are less overkill while remaining a suitable replacement in the specific machine.
Given how long it takes for something to go from 'new' to 'common' and from 'common' to 'deprecated'
Common and deprecated are not mutually exclusive. Something can stay common long after it has become deprecated. Seeing technologies remaining common for a decade after they became deprecated is one of the main reasons for the 'thank' in the 'finally dead, and thank god for that' state that you mentioned.
If the availability of internet cafes is sufficient to cover your needs, then you could reduce the need for carrying equipment significantly, if you could find a way to make use of a computer without having to trust it.
If you did all of the computing on a stationary machine that you trust (located in your home or in a data center), then you have reduced the task to solve to handling input and output. Would you trust a machine in an internet cafe to send what is on the screen from your own machine to the monitor you are located at? For the rest of my suggestion, I'll assume the answer to that question is yes.
First solution would then be to carry your own keyboard and mouse plus a device that can securely get input from those input devices to your computer. A quite simple task in comparison with the task of handling general purpose computing. The device could be something with a SIM card and use data roaming to get data back to your computer. It is only a tiny amount of data, so no worry about data usage.
Now what you do is sit down at a public untrusted computer. You open a webbrowser and go to your own homepage with an applet (flash, java, whatever, depending on what the browser supports). The applet will show a pairingcode, you type that code on your trusted keyboard, and all input will happen using your trusted keyboard and mouse.
Things could be simplified a little bit if you can plug your own USB unit into the public computer. Then your unit could type in the webaddress, such that you don't have to do it yourself. And the pairing code could be send the other way around from your device through the applet. But the best part is that your device could pull power from the computer such that it wouldn't need a battery, and the encrypted and authenticated stream of keyboard and mouse input could be send as keypresses into the applet instead of over the mobile network. Then you won't need a SIM either.
You still need to carry around one tiny computing device to do the encryption with one USB connection to the public computer and two USB connectors for keyboard and mouse. Do you really need to carry around keyboard and mouse? Would you trust the keyboard and mouse in the webcafe? If you unplug those two units from the public computer and plug them into your little device, then you have reduced the equipment to carry to one tiny unit with three USB connectors.
Of course this is not 100% secure. The ability to see all your video output and manipulate it makes you an easier target for phishing attacks. It is of course still not trivial, an attacker can't just get you onto a phishing page in the first place as they cannot manipulate your input stream. But it might be secure enough for you, it all depends on your needs.
If I understood things correctly, Intel processors offer two ways of doing things, AMD just the one. The one that Intel borked is the one they offer to be compatable with AMD.
That's not how I understood it. AMD designed the architecture (with a lot of inspiration from the earlier 32 bit architectures). When Intel realized that their own 64 bit architecture was not taking off, but the one designed by AMD was, Intel decided to start producing AMD compatible CPUs. Intel build the CPUs to work according to the specs released by AMD. But Intel made a mistake in the implementation of some feature, which now turns out to be a security problem. It is true that there are two ways to do the same thing.
It is true that there are two ways to do the same thing. There is the old method, which is more or less the same as it was on the 386 CPUs. And there is the new method, which is designed to improve performance. But methods are part of the spec and supported by both Intel and AMD. However only Intel introduced this particular bug in the new and improved method. Now all operating systems have to go back to the old method because of this bug in the Intel CPUs.
Hopefully they can somehow detect situations where it is necessary such that we don't see a drop in performance because they need to use the slower method.
You can keep your shitty caching schemes and your hybrid drives (which are just shitty caching schemes in a black box).
Yeah. It should be done with a virtual block device using one physical harddisk and one physical SSD (a later version could support multiple of each kind). Having the driver in the kernel and open source like the rest of it, will get rid of black box problem. And in a few iterations it can evolve into a very efficient caching scheme. Moving it into the kernel also opens up for better integration with the file system. For example if the hybdrid layer would move a block of data from SSD to harddisk, but the diskblock is now free space, then it can just skip that move. Additionally if properly designed a failing SSD will in the worst case lose the latest hour (or so) of writes, and you can just keep going disk only (with reduced performance) until you can replace the SSD.
SSDs all the way. If I need bigbadstorage, I buy multiple SSDs.
If you do that for any commercial use, you will have a competitive disadvantage.
The only problem I have with SSDs is the inability to securely erase shit without blanking the entire drive.
A hybrid solution could solve that problem too. Everything on SSD is kept encrypted, keys are only stored on harddisk and in RAM. When data is flushed to disk, you also wipe out all the keys for data which has been logically overwritten.
Sounds fair until you realize that it would be possible to set up multiple corporations just to get multiple tickets in the draw. If you try to defeat this by requiring a payment in order to apply for a domain, then you turn it into an auction.
This Corporation is a nonprofit public benefit corporation and is not organized for the private gain of any person.
There is plenty of nonprofit organizations that could use the money. Each bidder should bid as much money as they would want to pay plus specify which nonprofit organization would receive the money. Before the actual bidding starts each bidder would submit a list of suggested nonprofit organizations that are allowed, an independent body would need to validate the suggested organizations before actual bidding starts. Make the bidding a second price auction, because that is generally a sensible thing to do, and moves less money around.
Why develop a "random generator system" that need to be audited, instead of putting "the faith of their application into the applicants' own hands" (by "digital archery")?
You don't think that needs to be audited? A random generator system is easier to audit. Each bidder submit a random string. All random strings submitted before the deadline are then hashed together to choose randomly between those parties submitting before the deadline. Alternatively the input data for the hash could include the opening price of some stock index from a date after the deadline. As long as the method is published beforehand and all input is public, it is easy for anybody to validate the result.
There is still some fine details about the deadline. In practice that is a lot easier to deal with than this so called archery.
That one is not in the file. However CorrectHorseBatteryStaple hashes to a9cb82349d8c4f9aa4ba3210fadde81049300d0b, which is in the leaked list of hashes. That means either:
This is actually the password for Randal Munroe's linkedin profile
And if the hypothesis about the first five characters in the file having been overwritten on those entries that were cracked already is true, this means this one was not cracked until now.
I was responding particularly to the GP - who was apparently under the impression that THIS experiment had sent a signal out and was declared a failure for not receiving a reply.
You mean the guy who started out calling other people stupid and then proceeded to demonstrate his own lack of knowledge about the project? Your reply to that was like between 90 and 99% accurate, that is certainly a lot better than what you replied to.
The problem is that we've now got to send out an errata slip explaining that Pluto is no longer a planet, so the diagram of the solar system we sent isn't accurate any more.
Sending the entire message again would be a good idea if we do want to communicate with aliens. An updated and slightly different version would be fine. If some aliens actually picked up both the original and the new message, how would they interpret it?
If they could figure out that the message was encoding information about the Sun and planets, and if they are able to confirm the presence of the larger planets and maybe even the four innermost planets, what are they going to think of the messages we sent? Pluto is probably too small for them to detect, and they are going to look on the different messages in horror as they realize an Earth sized planet has been vaporized within the last 40 years.
Yeah, sounds like it. I thought it had been send a few times, but I may have been mistaken about that. If we seriously want alien civilisations to see it, we need to send it more often, and be more careful about the direction in which it is sent.
We have waited for a repetition, to confirm it's really an alien signal.
I'm not sure what repetition really confirms. The more interesting question is whether we were able to decode the signal in the first place.
Anyway, we never answered.
Yeah, we could have resent the Arecibo message in the direction of the source of messages we think may be from alien civilisations. It's not that those who sent the message in the first place would hear the reply because it could arrive several generations later. But if there is still intelligent life there, somebody else could pick up the reply. Of course with alien life we don't know how long generations are. We don't even know if the concept of generations and even the concept of individuals will make sense in an alien civilisation.
If any aliens have received the Arecibo signal, and those aliens are somewhat like us, they also have waited for a repetition of that signal, and since that repetition never came, they'll not answer.
Good point. We don't know how aliens would communicate. But if we want a chance to communicate with aliens, at least we should be using a method that would make communication possible if they communicate the same way as us.
But that had nothing to do with the SETI project now did it ?
I am not aware of any connection between the two, other than perhaps the Arecibo message was an inspiration for the SETI project. It's not that SETI is listening for the replies to the Arecibo message. It would be too early for that anyway. But if some alien civilisation send out messages similar to the Arecibo message, we might pick it up.
I was just pointing out that stating none of the signals were intended for alien consumption is slightly inaccurate. But it is true that alien civilisations would be more likely to pick up a signal that was intended for a recipient on Earth than one which we sent with the intention of reaching an alien civilisation.
While working with headphones may be a bit distracting and reduce productivity I find the noises that I would hear without the headphones to be more distracting. Finding a quite workplace is not as easy as it should be.
Also, there is something important to be said about link-layer error detection: it is not end-to-end. If corruption occurs while the packet is being handled by a router (as opposed to while it is traversing a link), the link-layer won't be able to detect it.
Very true. I have gotten into some verbal fights over that in the past with people insisting their error checking was good enough, and they didn't want to support the same kind of error checking other people were using. I kept pointing out, that the it was not a question about whether their error checking was good enough, but rather that they had to use the same as other people in order to get end-to-end checking.
In the end I backed down a little bit and instead insisted on having overlap, such that you'd compute the new checksum before verifying the old one, such that it was unlikely for a corruption to happen without affecting at least one of the checksum verifications.
I do wonder, though, how many people actually use TCP-MD5 these days?
I have gotten the impression it is used for most BGP sessions, and not much else. But I really wouldn't know since I haven't touched BGP directly. I have never used MD5 in TCP myself. Whenever I have needed better checks than what the default TCP checksum provided, I have always been using checks at a higher protocol layer.
In IPv4, both the network layer (IP) and transport layer (TCP) detect transmission errors via checksums.
That is not correct. The IP header does have a checksum, but it covers only the header itself. Corrupted data would not be detected by the IP checksum. TCP has a checksum that covers the TCP header, all the payload data, and a few important fields of the IP header (such as source and destination IP).
In IPv6, the network layer does not actually detect errors at all (I believe this is so in order to speed up routers by not having them calculate checksums).
That's correct. It also reduced the header size by two bytes. In total six bytes were removed from the part of the IP header before the addresses, but two new bytes were added as well, meaning an overall reduction from 12 to 8 bytes. The address part was quadrupled from 8 to 32 bytes.
There's only the TCP checksum and whatever link-layer error detection you have protecting you from corrupted packets.
Right. There are commonly error checking at the link layer below IP as well as in the transport layer on top of IP. And both of them will cover the IP header. It was considered redundant to have three separate layers compute checksums of the IP header, thus it was removed. It never covered anything but the header itself.
A few other changes were made at the same time to make up for the loss of the IP checksum. For UDP the checksum was made mandatory. It used to be optional, an IPv4 packet can carry UDP with a checksum of 0, and it will be considered valid for any data. Unlike UDP and TCP, the checksum in ICMP didn't cover any of the header bytes in IPv4. In IPv6 this was changed such that the ICMPv6 checksum also covers the IP addresses. If you for some reason don't like the fact that you are now being forced to checksum all data send over UDP, you can develop new applications using UDPlite. With UDPlite the checksum is mandatory, but it does not have to cover all the data. It covers the IP and UDP headers and as many of the data bytes as you like it to.
In the end those checksums are not really great. It turns out 16 bits of checksum is not enough to catch all the random errors that do occur. The probability that all 16 bits do by chance match when corruption happened is a bit too high. So in many cases you will make use of stronger checksums at a higher layer, in many cases even a cryptographic message-authentication-code. You can use MD5 at the TCP layer. At higher layers there are even more options.
If they start affecting legal p2p downloads, then what they are doing is solely illegal.
Moreover there is probably an overlap between those people using bittorrent for legal purposes, and those people who dislike Microsoft and want to hurt the company through any legal means.
How long until somebody getting their legal downloads disrupted by the system will start suing Microsoft?
Some servers don't care, and you can get away with just using nc. And as you point out, a few extra keypresses can get nc to send the newline as required by the protocol. But I don't see why that is in any way better than using the telnet command, which will do the right thing by default.
Author forgot to set Firefox to tunnel DNS requests, alot of danger is still exposed via DNS.
Why is it that Firefox sets network.proxy.socks_remote_dns to false by default? I know of several scenarios where setting it to true works better than setting it to false. I don't know of any situation where the default value is actually better.
True, but on systems where pppd is unavailable (permissions or just not there!) then SSH tools are most useful!
I have on some occasions used PPP over SSH without having pppd available on the server. I used pppd on the client and slirp on the server. The result was usable, though performance of anything trying to layer IP on top of TCP is not going to be great. At some point I switched to running PPP over UDP packets and just used an SSH connection to start the software in each end. I used scp to transfer a key for encrypting the traffic.
Imagine that you could just pipe the output from a command into some magical ssh command in a remote machine and your ssh client would ask where you would like to pipe the stream in your local machine.
Sort of how zmodem would do over a serial line. If you have a typical terminal emulator and hook it up to a serial login on a Linux machine, you can type the command "sz <filename>", and once the sz command executes on the server it will send a message that the terminal emulator will understand an ask you where to store the file.
I don't see any reason why the ssh client couldn't implement zmodem as well such that you could type the same sort of command in an ssh session and have the file stored on the client. However one might argue that such a feature doesn't belong in the ssh client, but rather in the terminal. You shouldn't expect such advanced features to show up in xterm any time soon, but why don't gnome-terminal or something similar support receiving files using zmodem? If the terminal supported it, then it should just work with ssh, rsh, telnet, rlogin, or even just su.
One day, they do some load balancing or something, and they shift my account to a different box. To me, it doesn't matter if they do that, but they don't exactly send out emails on each occasion. It has happened roughly three times a year for me. Every time I get the fingerprint-changed warning, it would be nice to have some confidence in it without resorting to the telephone.
I experienced something similar from a company that shall not be named here. I was responsible for a system that would ssh to their ssh server. But it turns out that the IP they had their hostname resolves to was actually some sort of loadbalancer, that would communicate with 3 or 4 actual ssh servers.
On a couple of occasions they would put an incorrect key on one of those ssh servers. That meant successive TCP connections to port 22 would end up on different servers with different hostkeys.
Naturally when I contacted them, I didn't ask them if their hostkeys had changed. Rather I insisted on them fixing their servers, such that we would consistently get the same hostkey when connecting to port 22 on that IP. That's not to say they can never change the hostkey, but if they do feel a need to change it, it is also their responsibility to ensure that it gets updated simultaneously on all the hosts, and to communicate the new public key in a secure way to their customers.
Them being incompetent in managing ssh servers might have been more tolerable if they had been very competent in their primary field of business. Sadly, they demonstrated even more incompetence in their primary field of business.
Slashdot Mirror
According to the video (which is now working) it reads the state of those lego pieces using an optic sensor. So they are not just used for display, they are used as actual memory. There is no requirement as to how you implement the state machine of a turing machine, except that it has to be final state. And the NXT is final state. So it is a turing machine.
Are you implying that you cannot include an NXT in something and say that it is built out of lego? Surely the NXT is overkill for the task, but I don't think lego is selling components that are less overkill while remaining a suitable replacement in the specific machine.
Common and deprecated are not mutually exclusive. Something can stay common long after it has become deprecated. Seeing technologies remaining common for a decade after they became deprecated is one of the main reasons for the 'thank' in the 'finally dead, and thank god for that' state that you mentioned.
http://www.youtube.com/watch?v=cYw2ewoO6c4
If the availability of internet cafes is sufficient to cover your needs, then you could reduce the need for carrying equipment significantly, if you could find a way to make use of a computer without having to trust it.
If you did all of the computing on a stationary machine that you trust (located in your home or in a data center), then you have reduced the task to solve to handling input and output. Would you trust a machine in an internet cafe to send what is on the screen from your own machine to the monitor you are located at? For the rest of my suggestion, I'll assume the answer to that question is yes.
First solution would then be to carry your own keyboard and mouse plus a device that can securely get input from those input devices to your computer. A quite simple task in comparison with the task of handling general purpose computing. The device could be something with a SIM card and use data roaming to get data back to your computer. It is only a tiny amount of data, so no worry about data usage.
Now what you do is sit down at a public untrusted computer. You open a webbrowser and go to your own homepage with an applet (flash, java, whatever, depending on what the browser supports). The applet will show a pairingcode, you type that code on your trusted keyboard, and all input will happen using your trusted keyboard and mouse.
Things could be simplified a little bit if you can plug your own USB unit into the public computer. Then your unit could type in the webaddress, such that you don't have to do it yourself. And the pairing code could be send the other way around from your device through the applet. But the best part is that your device could pull power from the computer such that it wouldn't need a battery, and the encrypted and authenticated stream of keyboard and mouse input could be send as keypresses into the applet instead of over the mobile network. Then you won't need a SIM either.
You still need to carry around one tiny computing device to do the encryption with one USB connection to the public computer and two USB connectors for keyboard and mouse. Do you really need to carry around keyboard and mouse? Would you trust the keyboard and mouse in the webcafe? If you unplug those two units from the public computer and plug them into your little device, then you have reduced the equipment to carry to one tiny unit with three USB connectors.
Of course this is not 100% secure. The ability to see all your video output and manipulate it makes you an easier target for phishing attacks. It is of course still not trivial, an attacker can't just get you onto a phishing page in the first place as they cannot manipulate your input stream. But it might be secure enough for you, it all depends on your needs.
That's not how I understood it. AMD designed the architecture (with a lot of inspiration from the earlier 32 bit architectures). When Intel realized that their own 64 bit architecture was not taking off, but the one designed by AMD was, Intel decided to start producing AMD compatible CPUs. Intel build the CPUs to work according to the specs released by AMD. But Intel made a mistake in the implementation of some feature, which now turns out to be a security problem. It is true that there are two ways to do the same thing.
It is true that there are two ways to do the same thing. There is the old method, which is more or less the same as it was on the 386 CPUs. And there is the new method, which is designed to improve performance. But methods are part of the spec and supported by both Intel and AMD. However only Intel introduced this particular bug in the new and improved method. Now all operating systems have to go back to the old method because of this bug in the Intel CPUs.
Hopefully they can somehow detect situations where it is necessary such that we don't see a drop in performance because they need to use the slower method.
You can keep your shitty caching schemes and your hybrid drives (which are just shitty caching schemes in a black box).
Yeah. It should be done with a virtual block device using one physical harddisk and one physical SSD (a later version could support multiple of each kind). Having the driver in the kernel and open source like the rest of it, will get rid of black box problem. And in a few iterations it can evolve into a very efficient caching scheme. Moving it into the kernel also opens up for better integration with the file system. For example if the hybdrid layer would move a block of data from SSD to harddisk, but the diskblock is now free space, then it can just skip that move. Additionally if properly designed a failing SSD will in the worst case lose the latest hour (or so) of writes, and you can just keep going disk only (with reduced performance) until you can replace the SSD.
SSDs all the way. If I need bigbadstorage, I buy multiple SSDs.
If you do that for any commercial use, you will have a competitive disadvantage.
The only problem I have with SSDs is the inability to securely erase shit without blanking the entire drive.
A hybrid solution could solve that problem too. Everything on SSD is kept encrypted, keys are only stored on harddisk and in RAM. When data is flushed to disk, you also wipe out all the keys for data which has been logically overwritten.
Your question inspired me to write a proof of concept.
Sounds fair until you realize that it would be possible to set up multiple corporations just to get multiple tickets in the draw. If you try to defeat this by requiring a payment in order to apply for a domain, then you turn it into an auction.
There is plenty of nonprofit organizations that could use the money. Each bidder should bid as much money as they would want to pay plus specify which nonprofit organization would receive the money. Before the actual bidding starts each bidder would submit a list of suggested nonprofit organizations that are allowed, an independent body would need to validate the suggested organizations before actual bidding starts. Make the bidding a second price auction, because that is generally a sensible thing to do, and moves less money around.
You don't think that needs to be audited? A random generator system is easier to audit. Each bidder submit a random string. All random strings submitted before the deadline are then hashed together to choose randomly between those parties submitting before the deadline. Alternatively the input data for the hash could include the opening price of some stock index from a date after the deadline. As long as the method is published beforehand and all input is public, it is easy for anybody to validate the result.
There is still some fine details about the deadline. In practice that is a lot easier to deal with than this so called archery.
That one is not in the file. However CorrectHorseBatteryStaple hashes to a9cb82349d8c4f9aa4ba3210fadde81049300d0b, which is in the leaked list of hashes. That means either:
And if the hypothesis about the first five characters in the file having been overwritten on those entries that were cracked already is true, this means this one was not cracked until now.
You mean the guy who started out calling other people stupid and then proceeded to demonstrate his own lack of knowledge about the project? Your reply to that was like between 90 and 99% accurate, that is certainly a lot better than what you replied to.
Sending the entire message again would be a good idea if we do want to communicate with aliens. An updated and slightly different version would be fine. If some aliens actually picked up both the original and the new message, how would they interpret it?
If they could figure out that the message was encoding information about the Sun and planets, and if they are able to confirm the presence of the larger planets and maybe even the four innermost planets, what are they going to think of the messages we sent? Pluto is probably too small for them to detect, and they are going to look on the different messages in horror as they realize an Earth sized planet has been vaporized within the last 40 years.
Yeah, sounds like it. I thought it had been send a few times, but I may have been mistaken about that. If we seriously want alien civilisations to see it, we need to send it more often, and be more careful about the direction in which it is sent.
I'm not sure what repetition really confirms. The more interesting question is whether we were able to decode the signal in the first place.
Yeah, we could have resent the Arecibo message in the direction of the source of messages we think may be from alien civilisations. It's not that those who sent the message in the first place would hear the reply because it could arrive several generations later. But if there is still intelligent life there, somebody else could pick up the reply. Of course with alien life we don't know how long generations are. We don't even know if the concept of generations and even the concept of individuals will make sense in an alien civilisation.
Good point. We don't know how aliens would communicate. But if we want a chance to communicate with aliens, at least we should be using a method that would make communication possible if they communicate the same way as us.
I am not aware of any connection between the two, other than perhaps the Arecibo message was an inspiration for the SETI project. It's not that SETI is listening for the replies to the Arecibo message. It would be too early for that anyway. But if some alien civilisation send out messages similar to the Arecibo message, we might pick it up.
I was just pointing out that stating none of the signals were intended for alien consumption is slightly inaccurate. But it is true that alien civilisations would be more likely to pick up a signal that was intended for a recipient on Earth than one which we sent with the intention of reaching an alien civilisation.
One could argue that the Arecibo message was designed for alien consumption.
The first character of a TLD must be a letter.
While working with headphones may be a bit distracting and reduce productivity I find the noises that I would hear without the headphones to be more distracting. Finding a quite workplace is not as easy as it should be.
Very true. I have gotten into some verbal fights over that in the past with people insisting their error checking was good enough, and they didn't want to support the same kind of error checking other people were using. I kept pointing out, that the it was not a question about whether their error checking was good enough, but rather that they had to use the same as other people in order to get end-to-end checking.
In the end I backed down a little bit and instead insisted on having overlap, such that you'd compute the new checksum before verifying the old one, such that it was unlikely for a corruption to happen without affecting at least one of the checksum verifications.
I have gotten the impression it is used for most BGP sessions, and not much else. But I really wouldn't know since I haven't touched BGP directly. I have never used MD5 in TCP myself. Whenever I have needed better checks than what the default TCP checksum provided, I have always been using checks at a higher protocol layer.
That is not correct. The IP header does have a checksum, but it covers only the header itself. Corrupted data would not be detected by the IP checksum. TCP has a checksum that covers the TCP header, all the payload data, and a few important fields of the IP header (such as source and destination IP).
That's correct. It also reduced the header size by two bytes. In total six bytes were removed from the part of the IP header before the addresses, but two new bytes were added as well, meaning an overall reduction from 12 to 8 bytes. The address part was quadrupled from 8 to 32 bytes.
Right. There are commonly error checking at the link layer below IP as well as in the transport layer on top of IP. And both of them will cover the IP header. It was considered redundant to have three separate layers compute checksums of the IP header, thus it was removed. It never covered anything but the header itself.
A few other changes were made at the same time to make up for the loss of the IP checksum. For UDP the checksum was made mandatory. It used to be optional, an IPv4 packet can carry UDP with a checksum of 0, and it will be considered valid for any data. Unlike UDP and TCP, the checksum in ICMP didn't cover any of the header bytes in IPv4. In IPv6 this was changed such that the ICMPv6 checksum also covers the IP addresses. If you for some reason don't like the fact that you are now being forced to checksum all data send over UDP, you can develop new applications using UDPlite. With UDPlite the checksum is mandatory, but it does not have to cover all the data. It covers the IP and UDP headers and as many of the data bytes as you like it to.
In the end those checksums are not really great. It turns out 16 bits of checksum is not enough to catch all the random errors that do occur. The probability that all 16 bits do by chance match when corruption happened is a bit too high. So in many cases you will make use of stronger checksums at a higher layer, in many cases even a cryptographic message-authentication-code. You can use MD5 at the TCP layer. At higher layers there are even more options.
Moreover there is probably an overlap between those people using bittorrent for legal purposes, and those people who dislike Microsoft and want to hurt the company through any legal means.
How long until somebody getting their legal downloads disrupted by the system will start suing Microsoft?
Some servers don't care, and you can get away with just using nc. And as you point out, a few extra keypresses can get nc to send the newline as required by the protocol. But I don't see why that is in any way better than using the telnet command, which will do the right thing by default.
Why is it that Firefox sets network.proxy.socks_remote_dns to false by default? I know of several scenarios where setting it to true works better than setting it to false. I don't know of any situation where the default value is actually better.
I have on some occasions used PPP over SSH without having pppd available on the server. I used pppd on the client and slirp on the server. The result was usable, though performance of anything trying to layer IP on top of TCP is not going to be great. At some point I switched to running PPP over UDP packets and just used an SSH connection to start the software in each end. I used scp to transfer a key for encrypting the traffic.
Imagine that you could just pipe the output from a command into some magical ssh command in a remote machine and your ssh client would ask where you would like to pipe the stream in your local machine.
Sort of how zmodem would do over a serial line. If you have a typical terminal emulator and hook it up to a serial login on a Linux machine, you can type the command "sz <filename>", and once the sz command executes on the server it will send a message that the terminal emulator will understand an ask you where to store the file.
I don't see any reason why the ssh client couldn't implement zmodem as well such that you could type the same sort of command in an ssh session and have the file stored on the client. However one might argue that such a feature doesn't belong in the ssh client, but rather in the terminal. You shouldn't expect such advanced features to show up in xterm any time soon, but why don't gnome-terminal or something similar support receiving files using zmodem? If the terminal supported it, then it should just work with ssh, rsh, telnet, rlogin, or even just su.
I experienced something similar from a company that shall not be named here. I was responsible for a system that would ssh to their ssh server. But it turns out that the IP they had their hostname resolves to was actually some sort of loadbalancer, that would communicate with 3 or 4 actual ssh servers.
On a couple of occasions they would put an incorrect key on one of those ssh servers. That meant successive TCP connections to port 22 would end up on different servers with different hostkeys.
Naturally when I contacted them, I didn't ask them if their hostkeys had changed. Rather I insisted on them fixing their servers, such that we would consistently get the same hostkey when connecting to port 22 on that IP. That's not to say they can never change the hostkey, but if they do feel a need to change it, it is also their responsibility to ensure that it gets updated simultaneously on all the hosts, and to communicate the new public key in a secure way to their customers.
Them being incompetent in managing ssh servers might have been more tolerable if they had been very competent in their primary field of business. Sadly, they demonstrated even more incompetence in their primary field of business.