Aren't human personalities also a type of programmed responses? Don't we spend years training children to respond in the way that makes us happy? Why is it different when we use the same stimulus-response training with a computer?
I don't understand how any of that address the points I made but: I believe it's a moral imperative to limit the maximum pay ratio, based on precisely the same factors you used to determine it was morally wrong (I assume, since you didn't list any). I also don't see it as a penalty for the rich any more than taxes are.
Perhaps more importantly I do not see how limiting the pay ratio is something that could be "extended to all of the country" with respect to limiting everyone's pay (or again, how that's fundamentally different than income tax) -- by definition a pay ratio limit only affects the highest pay rates.
You can analyze literally any proposal for regulation with: 1) People will try to cheat 2) If we stop them from cheating they will leave and you wouldn't be wrong.
But I don't understand why that means we shouldn't try.
Says a man who has obviously never take a bus from Minneapolis to St. Louis -- 18 hours over 3 buses, sitting shoulder-to-shoulder the whole way with no more freedom to move around than you'd have in a plane.
In a metro system of even moderate size you can be on the same bus traveling in the same direction for 2+ hours. That's not a long plane ride, but it's not a trivial amount of time either. And inter-city routes can obviously be much longer.
That's right. You only have to speak over the sound of the diesel engine, the wind noise, the traffic noise, and the road noise.
Airplane cabins are probably someplace in the 70-80 dB range, depending on the type of plane and where you are sitting. That's just about what you'd expect from moderate traffic that includes large vehicles or high speeds. I'm sure there are some buses that are quieter than planes, but it doesn't strike me as a major difference.
Cell phone use is allowed on busses (metro and inter-city), and it doesn't seem to be a huge problem there. Why should I assume that planes would be significantly worse?
Actually, back in the day, the 7-digit phone number was seen as an upper limit to the maximum length it was reasonable to memorize without much practice, and early implementations often used only 5 digits to further easy the burden. 10-digit-dialing didn't come about until almost the new century; in many places in the US it was impossible to dial a "local" number with 10 digits until the late 90s -- if you tried it would ask you to hang up and dial again without the area code or long-distance access prefix.
UDP and TCP have different uses; one isn't better than the other, they just do different things.
UDP is message-based. When I send a UDP message the remote end either gets the whole message or none of it. This can make parsing in applications a lot easier; rather than putting delimiters into a stream and trying to pick apart the data as it comes in in chunks I can be sure that I'm always working with a complete message, and the messages can by of different types/sizes/etc. as dictated by my application-layer needs. But there's a maximum size for messages, and if I need to send more data than fits in a single message it's up to my application to ensure they get put into the right order when they are received.
UDP is unreliable, in that if a UDP packet gets drop the message is lost and no notification is made to the sender. Often this is bad, but in certain instances it is valuable. One such instance is data with a short lifetime, such as games or streaming media. If I'm in the middle of a game and a packet gets dropped it doesn't do me any good to get that packet 2 seconds later -- the game has moved on. This unreliable nature also makes UDP simpler; there's no need to setup a "connection" to send UDP data -- you just slap an IP address on the packet and send it along, and the other end will get it or not and use it or not and you don't have to care. So if you're writing a server that will handle billions of clients UDP has a lot less overhead as it doesn't have to keep track of billions of "connections" (or have billions ports available).
TCP is a streaming protocol. You put data in on one end and it pops out in the same order on the other. This is great if you're sending a single file -- you can be sure the other end will get all the bits in the right order. But it also means if you have something important to say you have to wait in line until all of the preceding data has been transmitted, possibly including things that will be expired by the time they are received. It also means your application-layer protocol has to have some method to separate messages if you send more than one thing over a single connection.
TCP has reliable delivery. Often this is a good thing, as the sender can be sure the receiver got all the data (and got it in the right order). But in order to make the protocol reliable the receiver must acknowledge each and every packet from the sender, and the sender and receiver must store information about each other so they can keep track of this ongoing bi-directional connection. So there's at least a couple of round-trip exchanges necessary to setup a TCP connection, and when you connect to a server it must have a free TCP port number for each and every client it's connected to, and enough memory to keep track of all of the connections.
QUIC (and several other new-ish protocols) are proposing a sort of compromise protocol -- a protocol that's both message-based and reliable, and frequently that allows messages of any size. Such protocols provide the delivery assurances of TCP without the waiting-in-line issues the streaming model can produce, and they reduce the amount of setup overhead by allowing clients to open a single connection to the server and fetch many different things.
UDP isn't used for ping either. You're thinking of ICMP -- a lower-level protocol than TCP or UDP. ICMP is *almost* part of the IP layer; technically it uses IP for data transfer, but IP also depends on it for control messaging.
The back off mechanism is one of the problems they're trying to fix. Internet protocols need some way to control bandwidth usage, but there are a lot of limitations with the existing options in TCP. And if your RTFA you'd see they intend to provide alternative mechanisms to regulate bandwidth, addressing both the continuing need to avoid flooding and the limitations of TCP's back off mechanisms.
Plus stream protocols are inefficient when transferring multiple items (which is the typical use case for HTTP) and require more complicated parsing in the application layer (which is bad for security, among other things). Reliable message passing, as opposed to streaming, makes a lot of sense for use in web browsers and similar applications.
And for that matter, modern end-user DNS is a arguable a poor use case for UDP. Most hosts issues DNS requests against only a small number of resolvers (often only 1 or 2), frequently issue a number of requests in rapid succession, and generally retry if there is some network failure rather than just accepting the loss. Given those restraints a reliable transfer mechanism is very desirable and there's very little cost to doing a once-per-boot connection setup to the DNS resolver. UDP makes more sense for the peer-to-peer style system in place at higher levels (and around which DNS was designed) but that's just not the case for end-user DNS.
TCP is a stream protocol. UDP is a message protocol. They have different limitations and features and aren't always suitable for the same purposes. How do you expect to participate in a discussion about the limitations of TCP if you can't be bothered to learn even the basics of the existing protocols?
TCP has limitations even on links like yours. In fact many of the limitations of TCP are worse on lossy, low-bandwidth links than on faster, more reliable ones. And the fact that you can saturate your link is not evidence that TCP isn't slowing you down -- given enough ACKs I can fill any pipe, but that doesn't mean I'm transferring data efficiently.
Also be careful how you characterize "wasteful of bandwidth". For example, a typical TCP over a typical DSL connection would be unusable without the FEC correction provided at the link layer; when tuned correctly that "wasted" bandwidth used for duplicate signaling actually increases throughput significantly by eliminating retransmissions. FEC is actually a very common technique in purpose-built across-a-high-bandwidth-pipe WAN acceleration technology, and can be useful even when your packet loss rate is quite small.
Actually non-Google studies suggest the SPDY is only marginally helpful in decreasing page load times unless there's aggressive server push of dependent documents AND favorable parameters and network conditions for the underlying TCP connection. For example, SPDY does very poorly on lossy connections, particularly with the default TCP recovery settings. And even server push has problems -- in addition to requiring configuration it bypasses the client cache mechanism, and on low-bandwidth connections the additional data transfer may overwhelm the other savings SPDY.
Don't get me wrong, I think SPDY is a good idea in general. But it's still built on TCP and subject to the limitations thereof. If it were built on a reliable message-passing protocol instead the application layer of SPDY would be significantly simpler and network performance would improve in a number of common cases.
It's pretty easy to find USBSerial interfaces that include a unique ID of some sort. That plus 4 seconds editing your udev config will give you stable device naming.
Many IMAP servers don't really have folders. The IMAP protocol is specifically designed to support that sort of storage implementation. Gmail might have folder issues, but they aren't caused by the "just a mail heap with pointers" storage implementation.
There are obviously downsides to having only one provider in any market (there are benefits as well) but that's not really the point. There are many ways to preserve competition without penalizing businesses who have a non-traditional sales model; intentionally discriminatory rules only serve to enforce the status quo, not to promote justice. And France has a long history of attempting to preserve their "culture" via exclusionary and discriminatory trade rules; the politically powerful people in France get to keep their culture and the rest of the world (including most people in France) get screwed.
We can regulate automated cars and deal with accidents the same way we already deal with automated planes (and trains and other such things) -- with regulation on the systems qualified to control the vehicle (FAA) and investigations into accidents (NTSB). We'll need some new rules, but the general problem space is well understood and already regulated.
Beyond that it's not clear to me why the government would be in any better position to disable your self-driving car than your human-driving care -- if they're going to start install remote-kill switches there's nothing that would prevent them from doing it on today's cars. I can see why you're concerned about the general concept, but I don't understand why you're attaching it to self-driving cars.
You also might consider how removing drivers from cars will change the economics of car ownership, cabs, bus routes, etc. -- I'm not so sure many people will ever own a self-driving car, because why would you want to hassle with it when you can just rent one when you need it and get door-to-door service? If you drive a lot, or if you really like the idea of being able to leave things in the car, you could still buy one, but unlike today car ownership wouldn't be clearly necessary for people who drive only tens of hours a week.
It's also worth noting that the "freedom" and "low cost" you have today has a significant cost in human lives and economic productivity -- I know dead, poor people don't get paid much attention, but I suspect they'd argue that not having to buy a car in order to get to work and not being dead due to human drivers would *increase* their freedom and *decrease* their costs.
Where do you drive that they've worked out all the flaws in human-controlled cars? Or are you just ignoring the status quo to complain about the scary new system?
Also, what part of your argument couldn't be equally applied to the transition from human-and-animal-powered transit to steam-and-oil powered-transit? We've made these changes before. Most people are happy with them. I suspect you're happy with them. Why is this set of changes different and objectionable?
First of all, low-income people already have a reduced rate of car ownership compared to the other groups you list, so half of what you're predicting is "no change from the status quo".
Second, why would you want to own a car when you could rent a driverless cab (or ask the automated bus to swing by my current location)? The economics of car ownership change entirely when you take drivers out of the loop.
He's a socialist for pointing out that cars require huge, mostly capitalist, social support to exist and function?!? Exactly what would he have to do to demonstrate his commitment to capitalism?
If only there were some other highly-automated transportation system in place we could use as a model. Maybe set up some sort of mandatory validation methodology for the control systems and a post-accident review system to assess problems found in the field. If we nationalized those services they might be called the Federal Automated Automobile Administration and the National Automative Transportation Safety Board. But that's just silly I know -- these problems are totally new and we are completely unable to find ways to deal with them, so we should just stop now.
Slashdot Mirror
Aren't human personalities also a type of programmed responses? Don't we spend years training children to respond in the way that makes us happy? Why is it different when we use the same stimulus-response training with a computer?
I don't understand how any of that address the points I made but:
I believe it's a moral imperative to limit the maximum pay ratio, based on precisely the same factors you used to determine it was morally wrong (I assume, since you didn't list any). I also don't see it as a penalty for the rich any more than taxes are.
Perhaps more importantly I do not see how limiting the pay ratio is something that could be "extended to all of the country" with respect to limiting everyone's pay (or again, how that's fundamentally different than income tax) -- by definition a pay ratio limit only affects the highest pay rates.
You can analyze literally any proposal for regulation with:
1) People will try to cheat
2) If we stop them from cheating they will leave
and you wouldn't be wrong.
But I don't understand why that means we shouldn't try.
Says a man who has obviously never take a bus from Minneapolis to St. Louis -- 18 hours over 3 buses, sitting shoulder-to-shoulder the whole way with no more freedom to move around than you'd have in a plane.
And that's not even a long bus trip.
In a metro system of even moderate size you can be on the same bus traveling in the same direction for 2+ hours. That's not a long plane ride, but it's not a trivial amount of time either. And inter-city routes can obviously be much longer.
That's right. You only have to speak over the sound of the diesel engine, the wind noise, the traffic noise, and the road noise.
Airplane cabins are probably someplace in the 70-80 dB range, depending on the type of plane and where you are sitting. That's just about what you'd expect from moderate traffic that includes large vehicles or high speeds. I'm sure there are some buses that are quieter than planes, but it doesn't strike me as a major difference.
Cell phone use is allowed on busses (metro and inter-city), and it doesn't seem to be a huge problem there. Why should I assume that planes would be significantly worse?
Except that being fully manual is dangerous too -- overall automation has reduced crashes.
Actually, back in the day, the 7-digit phone number was seen as an upper limit to the maximum length it was reasonable to memorize without much practice, and early implementations often used only 5 digits to further easy the burden. 10-digit-dialing didn't come about until almost the new century; in many places in the US it was impossible to dial a "local" number with 10 digits until the late 90s -- if you tried it would ask you to hang up and dial again without the area code or long-distance access prefix.
UDP and TCP have different uses; one isn't better than the other, they just do different things.
UDP is message-based. When I send a UDP message the remote end either gets the whole message or none of it. This can make parsing in applications a lot easier; rather than putting delimiters into a stream and trying to pick apart the data as it comes in in chunks I can be sure that I'm always working with a complete message, and the messages can by of different types/sizes/etc. as dictated by my application-layer needs. But there's a maximum size for messages, and if I need to send more data than fits in a single message it's up to my application to ensure they get put into the right order when they are received.
UDP is unreliable, in that if a UDP packet gets drop the message is lost and no notification is made to the sender. Often this is bad, but in certain instances it is valuable. One such instance is data with a short lifetime, such as games or streaming media. If I'm in the middle of a game and a packet gets dropped it doesn't do me any good to get that packet 2 seconds later -- the game has moved on. This unreliable nature also makes UDP simpler; there's no need to setup a "connection" to send UDP data -- you just slap an IP address on the packet and send it along, and the other end will get it or not and use it or not and you don't have to care. So if you're writing a server that will handle billions of clients UDP has a lot less overhead as it doesn't have to keep track of billions of "connections" (or have billions ports available).
TCP is a streaming protocol. You put data in on one end and it pops out in the same order on the other. This is great if you're sending a single file -- you can be sure the other end will get all the bits in the right order. But it also means if you have something important to say you have to wait in line until all of the preceding data has been transmitted, possibly including things that will be expired by the time they are received. It also means your application-layer protocol has to have some method to separate messages if you send more than one thing over a single connection.
TCP has reliable delivery. Often this is a good thing, as the sender can be sure the receiver got all the data (and got it in the right order). But in order to make the protocol reliable the receiver must acknowledge each and every packet from the sender, and the sender and receiver must store information about each other so they can keep track of this ongoing bi-directional connection. So there's at least a couple of round-trip exchanges necessary to setup a TCP connection, and when you connect to a server it must have a free TCP port number for each and every client it's connected to, and enough memory to keep track of all of the connections.
QUIC (and several other new-ish protocols) are proposing a sort of compromise protocol -- a protocol that's both message-based and reliable, and frequently that allows messages of any size. Such protocols provide the delivery assurances of TCP without the waiting-in-line issues the streaming model can produce, and they reduce the amount of setup overhead by allowing clients to open a single connection to the server and fetch many different things.
UDP isn't used for ping either. You're thinking of ICMP -- a lower-level protocol than TCP or UDP. ICMP is *almost* part of the IP layer; technically it uses IP for data transfer, but IP also depends on it for control messaging.
The back off mechanism is one of the problems they're trying to fix. Internet protocols need some way to control bandwidth usage, but there are a lot of limitations with the existing options in TCP. And if your RTFA you'd see they intend to provide alternative mechanisms to regulate bandwidth, addressing both the continuing need to avoid flooding and the limitations of TCP's back off mechanisms.
Plus stream protocols are inefficient when transferring multiple items (which is the typical use case for HTTP) and require more complicated parsing in the application layer (which is bad for security, among other things). Reliable message passing, as opposed to streaming, makes a lot of sense for use in web browsers and similar applications.
And for that matter, modern end-user DNS is a arguable a poor use case for UDP. Most hosts issues DNS requests against only a small number of resolvers (often only 1 or 2), frequently issue a number of requests in rapid succession, and generally retry if there is some network failure rather than just accepting the loss. Given those restraints a reliable transfer mechanism is very desirable and there's very little cost to doing a once-per-boot connection setup to the DNS resolver. UDP makes more sense for the peer-to-peer style system in place at higher levels (and around which DNS was designed) but that's just not the case for end-user DNS.
TCP is a stream protocol. UDP is a message protocol. They have different limitations and features and aren't always suitable for the same purposes. How do you expect to participate in a discussion about the limitations of TCP if you can't be bothered to learn even the basics of the existing protocols?
TCP has limitations even on links like yours. In fact many of the limitations of TCP are worse on lossy, low-bandwidth links than on faster, more reliable ones. And the fact that you can saturate your link is not evidence that TCP isn't slowing you down -- given enough ACKs I can fill any pipe, but that doesn't mean I'm transferring data efficiently.
Also be careful how you characterize "wasteful of bandwidth". For example, a typical TCP over a typical DSL connection would be unusable without the FEC correction provided at the link layer; when tuned correctly that "wasted" bandwidth used for duplicate signaling actually increases throughput significantly by eliminating retransmissions. FEC is actually a very common technique in purpose-built across-a-high-bandwidth-pipe WAN acceleration technology, and can be useful even when your packet loss rate is quite small.
Actually non-Google studies suggest the SPDY is only marginally helpful in decreasing page load times unless there's aggressive server push of dependent documents AND favorable parameters and network conditions for the underlying TCP connection. For example, SPDY does very poorly on lossy connections, particularly with the default TCP recovery settings. And even server push has problems -- in addition to requiring configuration it bypasses the client cache mechanism, and on low-bandwidth connections the additional data transfer may overwhelm the other savings SPDY.
Don't get me wrong, I think SPDY is a good idea in general. But it's still built on TCP and subject to the limitations thereof. If it were built on a reliable message-passing protocol instead the application layer of SPDY would be significantly simpler and network performance would improve in a number of common cases.
It's pretty easy to find USBSerial interfaces that include a unique ID of some sort. That plus 4 seconds editing your udev config will give you stable device naming.
Get Plex, rip your DVDs, and run your own streaming service (including remote access).
All rules *are* silly because they are by nature unjust.
Many IMAP servers don't really have folders. The IMAP protocol is specifically designed to support that sort of storage implementation. Gmail might have folder issues, but they aren't caused by the "just a mail heap with pointers" storage implementation.
There are obviously downsides to having only one provider in any market (there are benefits as well) but that's not really the point. There are many ways to preserve competition without penalizing businesses who have a non-traditional sales model; intentionally discriminatory rules only serve to enforce the status quo, not to promote justice. And France has a long history of attempting to preserve their "culture" via exclusionary and discriminatory trade rules; the politically powerful people in France get to keep their culture and the rest of the world (including most people in France) get screwed.
We can regulate automated cars and deal with accidents the same way we already deal with automated planes (and trains and other such things) -- with regulation on the systems qualified to control the vehicle (FAA) and investigations into accidents (NTSB). We'll need some new rules, but the general problem space is well understood and already regulated.
Beyond that it's not clear to me why the government would be in any better position to disable your self-driving car than your human-driving care -- if they're going to start install remote-kill switches there's nothing that would prevent them from doing it on today's cars. I can see why you're concerned about the general concept, but I don't understand why you're attaching it to self-driving cars.
You also might consider how removing drivers from cars will change the economics of car ownership, cabs, bus routes, etc. -- I'm not so sure many people will ever own a self-driving car, because why would you want to hassle with it when you can just rent one when you need it and get door-to-door service? If you drive a lot, or if you really like the idea of being able to leave things in the car, you could still buy one, but unlike today car ownership wouldn't be clearly necessary for people who drive only tens of hours a week.
It's also worth noting that the "freedom" and "low cost" you have today has a significant cost in human lives and economic productivity -- I know dead, poor people don't get paid much attention, but I suspect they'd argue that not having to buy a car in order to get to work and not being dead due to human drivers would *increase* their freedom and *decrease* their costs.
Where do you drive that they've worked out all the flaws in human-controlled cars? Or are you just ignoring the status quo to complain about the scary new system?
Also, what part of your argument couldn't be equally applied to the transition from human-and-animal-powered transit to steam-and-oil powered-transit? We've made these changes before. Most people are happy with them. I suspect you're happy with them. Why is this set of changes different and objectionable?
First of all, low-income people already have a reduced rate of car ownership compared to the other groups you list, so half of what you're predicting is "no change from the status quo".
Second, why would you want to own a car when you could rent a driverless cab (or ask the automated bus to swing by my current location)? The economics of car ownership change entirely when you take drivers out of the loop.
He's a socialist for pointing out that cars require huge, mostly capitalist, social support to exist and function?!? Exactly what would he have to do to demonstrate his commitment to capitalism?
If only there were some other highly-automated transportation system in place we could use as a model. Maybe set up some sort of mandatory validation methodology for the control systems and a post-accident review system to assess problems found in the field. If we nationalized those services they might be called the Federal Automated Automobile Administration and the National Automative Transportation Safety Board. But that's just silly I know -- these problems are totally new and we are completely unable to find ways to deal with them, so we should just stop now.