"In the example of a single atom decaying, since we cannot rule out the possibility, one day, of being able to predict decay rate, I don't see how we can assert that the process is inherently random in some objective sense. Saying it's random is equivalent to saying we don't know..."
No, saying it's random is *not* equivalent to saying we don't know. Saying it's random is equivalent to saying that we *cannot* know.
There are situations where "not knowing" and "it being impossible to know" have differences with testable consequences. See, for example, Bell's Inequality.
Not only can we not predict whether or not a particular atom can decay, we have good reasons to believe that we will never be able to predict atomic decay because it is random. You can hypothesize that we are wrong about this, of course, but you can respond to *any* scientific conclusion by saying "perhaps it's wrong".
While anything random can't be predicted to the extent that it's random, and all things seem random until we can predict them, some things are fundamentally random and will never be predictable.
For example, consider a single atom of a radioactive isotope with a half-life of 12 hours. Whether or not that atom will decay in the next 12 hours (assuming it is not molested) is truly random. It doesn't depend on anything else. It is, we believe, fundamentally unpredictable.
The same is true of an electron that might tunnel. As far as we know, nothing external or internal effects its behavior. It simply might or might not tunnel.
Note that random events might be predictable in mass. If you have 12 kilos of that radioactive substance, after 12 hours you will have pretty darn close to 6 kilos left. However, they can also be unpredictable in mass, google "Scroedinger's cat".
There are quite a few ways of generating truly random numbers. They all basically boil down to three basic mechanisms. One is radioactive decay. Another is thermal noise. The last is direct quantum effects.
They vary in quality, but it really doesn't matter. With the proper post-processing, they all provide true randomness that is basically as good as randomness is possible to be.
Radioactive decay tends to be the most expensive and the least practical. Shot noise in a reverse-biased zener diode is generally the cheapest if you're going to build hardware to produce it. In a traditional computer such as the one on your desk, there are often several usable sources of true randomness.
Thermal noise in the lowest bits of your sound card work fairly well. You simple digitize the unconnected audio input.
Another good source is microscopic zone temperature variations in two independent crystal oscillators. You can usually find this by grabbing the TSC (instruction cycle counter) when a packet is received. Your network card has a crystal oscillator that is independent of the oscillator that generates your processor's core clock. (Obviously, only the lowest bits are useful.)
Something can be both random on a micro scale and predictable on a macro scale. The weather is like millions of dice being rolled. You can't say much about each individual die, but you can say an awful lot about the million in aggregate.
This technique is similar. The power on patterns of memory bits display both randomness and predictability. You can either mine the randomness, and get a source of truly random numbers, or you can mine the predictability, and get a fingerprint.
An interesting question is precisely on what the random outputs depend. If it's quantum effects in the individual electrons as the power comes on, then it should be truly random.
It's obviously not going to have an interrupt dispatcher, but it may well have an I/O handler and a CPU scheduler. Probably "platform" is a better term than "operating system".
"Say you're testing to see if substance X causes cancer in mice. Maybe all the mice you used just happened to be significantly more or less susceptible to cancer, for instance, due to a faulty batch of feed used during the experiment. If you just compare your results to the expected baseline, rather than an actual control, you have no way of knowing if the results you recieved were due to the feed or due to the substance X."
Right, but this is much cheaper, simpler, and just as good the 98% of the time when you don't find any more cancers than expected. This allows you to rule out 10 times as many possible causes of cancer than using a control group each time.
"Visual based avoidance doesn't work very well with human pilots."
Umm, what? The vast majority of airplanes in the air right now are flying under visual flight rules, which means that avoidance of other planes is primarily visual. Why do you say it "doesn't work very well"?
"With very simple GPS, point-to-point radio systems - every thing in the air and more importantly on the ground could participate in active collision avoidance."
There are two problems with this. One is simply that such a system is not nearly as simple as you seem to think. Perhaps you are confusing simple in principle with simple to actually get working on such a large scale. (Our current air traffic control system is simple in principle.)
The other problem is that there are a lot of things in the air that are unlikely to be able to participate in such a system. This includes everything from parachutists to hang gliders to old planes with no electrical system.
"UAV can be made small, light and from foam-based materials which would render them less harmful than birds even in the event of a collision, At some point the benefits outweigh the risks, full-on paranoia is unproductive."
Surely at some point the benefits will outweigh the risks, but we're not anywhere close to there yet. We have an airspace system that's primarily based on "see and be seen". We have the technology to do things different, but it will likely be at least two decades before we actually have an airspace system based on that new technology.
I don't think anyone in the pilot community has any object to UAVs provided they can follow the same see-and-be-seen rules that everyone else has to follow. How would you feel about unmanned trucks on the highways if they couldn't slow down and speed up to fit in with other traffic as manned trucks do? How would you feel about one lane of traffic just for them?
You do not need a lot of pins or a lot of board area for parallel read. So long as the interface transfer rate exceeds the device's internal speed by a significant amount, you can increase the effective transfer speed without increasing the pin count.
Basically, each device simply determines where it is in the chain (either by a two-pin series connection or by self-sorting by unique device ID) and ignores the data that isn't for it. So you could, for example, clock 32 units of data for each of 32 physical devices and have each device assert an acknowledge when it's done. By the time you get back to the first device, it's already finished the previous access.
On power up, each device interrogates the others and determines how many devices are physically present and what device number it is. This can be done in less than a second for dozens of devices and only requires a single data pin and a single clock pin connected together on all devices.
If there are 32 devices and we are device 2, we simply look at each read or write and if the last 5 bits don't equal 2, we ignore it. A device acknowledges an operation as soon as it has started it and needs room to hold the next operation and an operation in progress. This way, sequential reads and writes will go to all 32 devices in rotation, allowing a device to acknowledge an operation immediately, since it has already finished the preceding access to it (31 accesses ago).
This is very simple, well understood, and permits large numbers of devices to operate concurrently even with all their pins connected in parallel and without a large number of extra pins for coordination.
It only works, however, when the interconnection between devices is several times faster than a single device's transfer rate. This is the case for most flash devices.
"Why should a cellular provider be able to give me any less generous terms?"
You don't have to accept any terms you don't like. So what you are asking is, "why should I be allowed to accept bad terms?" And the answer is that you are a responsible adult who can make their own decisions. You don't need anyone else to protect you from your own stupidity because you aren't stupid.
If you want to accept some level of lock-in in exchange for a lower price, why should someone else prevent you from doing so?
That said, there are providers that use deception and, in some cases, outright fraud. *That* should not be allowed. But it makes no sense to prohibit deals agreeable to both sides where both sides understand all the details of the deal just because third parties think it's not a particularly good deal.
It's not unusual to perform a study with no control group when you are looking for something rare and don't expect to find it. It's a lot cheaper and easier, and nine times out of ten provides equally good results. However, this is that one time in ten when it doesn't.
This will have to be followed up with larger studies with control groups and double-blind protocols. The reaction to this study should be to demand more and better studies.
I use ISDN. I live in the mountains of northern California. I'm out of range of DSL and cable. Satellite providers don't seem to offer business-class service and have terms of use that you'd have to be an idiot to agree to.
"Yeah, too bad the world was incredibly linear and with one narrow corridor you could follow through the whole game."
That's always a delicate balance in a game. The flipside of this is having to search the entire world to find the one little switch, door, or object that you missed the first time through with no idea where it could possibly be.
But there's no explanation of how or why Linux allowed the number of servers to be reduced. For all we know, they simply switched to Linux and reduced the number of servers at the same time. Heck, the number of servers could have been gradually dropping over time with some of the drop occurring pre-switch and some post-switch.
It's also possible that Linux really did result in huge savings. It's possible Linux let them reduce their number of servers from 50 or 60 to 15 because it was so much more efficient or performed so much better. But we can't tell, because the article doesn't tell us anything.
That's why the store has no credibility. What it's saying is basically true and has proven true for many other companies, but the story tells us almost nothing about what this company actually did and actually experienced.
"No, they aren't a Linux company. They don't sell Linux and their own products are not Linux-specific."
From their web site:
"Mindbridge Software is an open sourced business innovator."
"I generally prefer Linux for my technical work and server implementations."
I'm not sure whether you're right or not. It's hard to tell just from their public content. I may have jumped to that conclusion. Nevertheless, I don't think it weakens my overall argument. Their story is a press release with no details that looks like a self-serving attempt to court the Linux community.
"It costs us significantly more to support a Windows box than a Linux box"
That's a pretty vague statement. How much more? How many boxes? No personal experience is evidence here, he's just repeating something lots of people say. (Note that I'm not saying it's not true. I'm saying he's giving us no evidence it is or that he's seen that it is.)
"You put out an email to a user mailing list, and you may get a response from the developer. Try doing that with most commercial vendors. It's hard to get access to those people. In the open source world, it's relatively easy."
Again, he gives no examples of particular problems he's had or people he's contacted. He just repeats a general claim and asserts blindingly that he has some evidence to support that claim. He doesn't share that evidence with us or discuss particular events.
The problem with writing faster and more streamlined code is that that comes at a cost. It used to be that you had to write the fastest possible code or your application just would not be practical. This caused performance to be the primary factor in software design and implementation choices.
This is no longer the case for the vast majority of software. This allows more focus to be put on testability, maintainability, simplicity, and so on. This results in more reliable code that can be more easily reused. It means new features can more easily be added. It means fewer bugs and an easier time locating the bugs that do crop up.
Being forced to give more important to performance, resource consumption, and other factors in software development *will* mean that other things will have to give. Nothing comes for free.
I lot of older programmers have to re-learn that things other than performance can be extremely important.
*Absolutely* true. While that obviously justifies pointing out when Microsoft's case studies are erroneous, self-serving, or both, it doesn't justify other people using the same tactics.
Not that I'm saying this article is as bad as most of those articles. It's not. No specifics is a lot better than completely false and misleading specifics pulled out of your corporate ass or intentionally deceptive test methodologies you pick but then get a "neutral third-party" to perform so they will "fairly and without bias" find that your product is best.
Microsoft: We didn't do these tests, Braincraft did. They found that our products were better.
Us: Did you pay them?
Microsoft: Well, yeah.
Us: Did you tell them what tests to perform and exactly how to perform?
Microsoft: Well, yeah.
Us: And did you already do those tests and carefully select the ones that make your product look the best without any regard for what thoses tests have to do with reality?
Linux.com and Mindbridge are both Linux companies. Mindbridge wants some attention, so it writes an article about how great Linux is and gets Linux.com to publish it. The article is very vague, no numbers, no specific case information, and no meat. It has no credibility.
This story has no credibility with me. The article is ridiculously light on details and seems to be an attempt at self-serving cross-promotion. There is no discussion of how they saved money or what those servers are actually doing. They talk about how much is costs them to "support" a Microsoft box, but they're such a small company, it's hard to imagine what their "support" even consists of.
They're a Linux company. They're telling us how great Linux is. They're not giving any details.
Personally, I have quite a bit of experience operating, maintaining, and supporting both Linux and Microsoft servers. I have found that both work well for the vast majority of applications. I've found other people's Linux servers to be easier to support than other people's Microsoft servers, but this might just be because the average Linux server contact is more knowledgeable than the average Microsoft server contact.
One huge difference is that it is *much* easier to figure out what a Linux server is doing and to start analyzing why it's not doing what it's supposed to do.
The idea that people will make better decisions with less information strikes me as completely bogus. Understanding that, for example, Microsoft has a vested interest in a standard being passed may well help people make better decisions.
To even suggest things this crazy, you must seriously misunderstand the purpose of the standardization process and how it works.
They probably don't do this in such an early chip because, as you suggest, this is intended to demonstrate capacity, not speed. But they can connect all the pins in parallel and minimize the pin count and *still* operate the chips in parallel. There are a number of ways to do this.
One simple way is for each device to have two 'chain' pins, one for 'in' and one for 'out'. You connect one chip's in to the supply, and then each chip's out to the next chip's in. The last chip's out is grounded. On power up, each chip looks at its in and out pins and figures out where in the sequence it is.
Then, when you want to write data, you put the last chip's data on the wire, pulse the clock, then the next to last, pulse the clock, and so on. Each chip knows which data it should store and when all the data has been sent, so they all store on the final pulse. For read, they all take the address at once, and then the last chip writes its output, when you send a clock pulse, that chip knows to stop sending its output and the second-to-last knows to start sending its output.
It can be done even if literally all the pins are connected together if each device has a unique burned-in serial number. There are simple techniques for each chip to detect what other chips it's connected to and to sort themselves into serial number order.
Slashdot Mirror
"In the example of a single atom decaying, since we cannot rule out the possibility, one day, of being able to predict decay rate, I don't see how we can assert that the process is inherently random in some objective sense. Saying it's random is equivalent to saying we don't know..."
No, saying it's random is *not* equivalent to saying we don't know. Saying it's random is equivalent to saying that we *cannot* know.
There are situations where "not knowing" and "it being impossible to know" have differences with testable consequences. See, for example, Bell's Inequality.
Not only can we not predict whether or not a particular atom can decay, we have good reasons to believe that we will never be able to predict atomic decay because it is random. You can hypothesize that we are wrong about this, of course, but you can respond to *any* scientific conclusion by saying "perhaps it's wrong".
While anything random can't be predicted to the extent that it's random, and all things seem random until we can predict them, some things are fundamentally random and will never be predictable.
For example, consider a single atom of a radioactive isotope with a half-life of 12 hours. Whether or not that atom will decay in the next 12 hours (assuming it is not molested) is truly random. It doesn't depend on anything else. It is, we believe, fundamentally unpredictable.
The same is true of an electron that might tunnel. As far as we know, nothing external or internal effects its behavior. It simply might or might not tunnel.
Note that random events might be predictable in mass. If you have 12 kilos of that radioactive substance, after 12 hours you will have pretty darn close to 6 kilos left. However, they can also be unpredictable in mass, google "Scroedinger's cat".
There are quite a few ways of generating truly random numbers. They all basically boil down to three basic mechanisms. One is radioactive decay. Another is thermal noise. The last is direct quantum effects.
They vary in quality, but it really doesn't matter. With the proper post-processing, they all provide true randomness that is basically as good as randomness is possible to be.
Radioactive decay tends to be the most expensive and the least practical. Shot noise in a reverse-biased zener diode is generally the cheapest if you're going to build hardware to produce it. In a traditional computer such as the one on your desk, there are often several usable sources of true randomness.
Thermal noise in the lowest bits of your sound card work fairly well. You simple digitize the unconnected audio input.
Another good source is microscopic zone temperature variations in two independent crystal oscillators. You can usually find this by grabbing the TSC (instruction cycle counter) when a packet is received. Your network card has a crystal oscillator that is independent of the oscillator that generates your processor's core clock. (Obviously, only the lowest bits are useful.)
Something can be both random on a micro scale and predictable on a macro scale. The weather is like millions of dice being rolled. You can't say much about each individual die, but you can say an awful lot about the million in aggregate.
This technique is similar. The power on patterns of memory bits display both randomness and predictability. You can either mine the randomness, and get a source of truly random numbers, or you can mine the predictability, and get a fingerprint.
An interesting question is precisely on what the random outputs depend. If it's quantum effects in the individual electrons as the power comes on, then it should be truly random.
It's obviously not going to have an interrupt dispatcher, but it may well have an I/O handler and a CPU scheduler. Probably "platform" is a better term than "operating system".
"Say you're testing to see if substance X causes cancer in mice. Maybe all the mice you used just happened to be significantly more or less susceptible to cancer, for instance, due to a faulty batch of feed used during the experiment. If you just compare your results to the expected baseline, rather than an actual control, you have no way of knowing if the results you recieved were due to the feed or due to the substance X."
Right, but this is much cheaper, simpler, and just as good the 98% of the time when you don't find any more cancers than expected. This allows you to rule out 10 times as many possible causes of cancer than using a control group each time.
"Visual based avoidance doesn't work very well with human pilots."
...
Umm, what? The vast majority of airplanes in the air right now are flying under visual flight rules, which means that avoidance of other planes is primarily visual. Why do you say it "doesn't work very well"?
"With very simple GPS, point-to-point radio systems - every thing in the air and more importantly on the ground could participate in active collision avoidance."
There are two problems with this. One is simply that such a system is not nearly as simple as you seem to think. Perhaps you are confusing simple in principle with simple to actually get working on such a large scale. (Our current air traffic control system is simple in principle.)
The other problem is that there are a lot of things in the air that are unlikely to be able to participate in such a system. This includes everything from parachutists to hang gliders to old planes with no electrical system.
"UAV can be made small, light and from foam-based materials which would render them less harmful than birds even in the event of a collision,
At some point the benefits outweigh the risks, full-on paranoia is unproductive."
Surely at some point the benefits will outweigh the risks, but we're not anywhere close to there yet. We have an airspace system that's primarily based on "see and be seen". We have the technology to do things different, but it will likely be at least two decades before we actually have an airspace system based on that new technology.
And then, if we have a GPS outage,
I don't think anyone in the pilot community has any object to UAVs provided they can follow the same see-and-be-seen rules that everyone else has to follow. How would you feel about unmanned trucks on the highways if they couldn't slow down and speed up to fit in with other traffic as manned trucks do? How would you feel about one lane of traffic just for them?
Not sure if you intended that as a joke, but no. "JoelKatz" is not anything like my real name.
You do not need a lot of pins or a lot of board area for parallel read. So long as the interface transfer rate exceeds the device's internal speed by a significant amount, you can increase the effective transfer speed without increasing the pin count.
Basically, each device simply determines where it is in the chain (either by a two-pin series connection or by self-sorting by unique device ID) and ignores the data that isn't for it. So you could, for example, clock 32 units of data for each of 32 physical devices and have each device assert an acknowledge when it's done. By the time you get back to the first device, it's already finished the previous access.
On power up, each device interrogates the others and determines how many devices are physically present and what device number it is. This can be done in less than a second for dozens of devices and only requires a single data pin and a single clock pin connected together on all devices.
If there are 32 devices and we are device 2, we simply look at each read or write and if the last 5 bits don't equal 2, we ignore it. A device acknowledges an operation as soon as it has started it and needs room to hold the next operation and an operation in progress. This way, sequential reads and writes will go to all 32 devices in rotation, allowing a device to acknowledge an operation immediately, since it has already finished the preceding access to it (31 accesses ago).
This is very simple, well understood, and permits large numbers of devices to operate concurrently even with all their pins connected in parallel and without a large number of extra pins for coordination.
It only works, however, when the interconnection between devices is several times faster than a single device's transfer rate. This is the case for most flash devices.
"Why should a cellular provider be able to give me any less generous terms?"
You don't have to accept any terms you don't like. So what you are asking is, "why should I be allowed to accept bad terms?" And the answer is that you are a responsible adult who can make their own decisions. You don't need anyone else to protect you from your own stupidity because you aren't stupid.
If you want to accept some level of lock-in in exchange for a lower price, why should someone else prevent you from doing so?
That said, there are providers that use deception and, in some cases, outright fraud. *That* should not be allowed. But it makes no sense to prohibit deals agreeable to both sides where both sides understand all the details of the deal just because third parties think it's not a particularly good deal.
It's not unusual to perform a study with no control group when you are looking for something rare and don't expect to find it. It's a lot cheaper and easier, and nine times out of ten provides equally good results. However, this is that one time in ten when it doesn't.
This will have to be followed up with larger studies with control groups and double-blind protocols. The reaction to this study should be to demand more and better studies.
Tea leaf readers?
Psychics?
Phrenologists?
I use ISDN. I live in the mountains of northern California. I'm out of range of DSL and cable. Satellite providers don't seem to offer business-class service and have terms of use that you'd have to be an idiot to agree to.
What is tat? Where can I get it? And how do I trade it for that other thing?
(With apologies to whoever said this first. Saturday Night Live?)
"Yeah, too bad the world was incredibly linear and with one narrow corridor you could follow through the whole game."
That's always a delicate balance in a game. The flipside of this is having to search the entire world to find the one little switch, door, or object that you missed the first time through with no idea where it could possibly be.
But there's no explanation of how or why Linux allowed the number of servers to be reduced. For all we know, they simply switched to Linux and reduced the number of servers at the same time. Heck, the number of servers could have been gradually dropping over time with some of the drop occurring pre-switch and some post-switch.
It's also possible that Linux really did result in huge savings. It's possible Linux let them reduce their number of servers from 50 or 60 to 15 because it was so much more efficient or performed so much better. But we can't tell, because the article doesn't tell us anything.
That's why the store has no credibility. What it's saying is basically true and has proven true for many other companies, but the story tells us almost nothing about what this company actually did and actually experienced.
"No, they aren't a Linux company. They don't sell Linux and their own products are not Linux-specific."
From their web site:
"Mindbridge Software is an open sourced business innovator."
"I generally prefer Linux for my technical work and server implementations."
I'm not sure whether you're right or not. It's hard to tell just from their public content. I may have jumped to that conclusion. Nevertheless, I don't think it weakens my overall argument. Their story is a press release with no details that looks like a self-serving attempt to court the Linux community.
"It costs us significantly more to support a Windows box than a Linux box"
That's a pretty vague statement. How much more? How many boxes? No personal experience is evidence here, he's just repeating something lots of people say. (Note that I'm not saying it's not true. I'm saying he's giving us no evidence it is or that he's seen that it is.)
"You put out an email to a user mailing list, and you may get a response from the developer. Try doing that with most commercial vendors. It's hard to get access to those people. In the open source world, it's relatively easy."
Again, he gives no examples of particular problems he's had or people he's contacted. He just repeats a general claim and asserts blindingly that he has some evidence to support that claim. He doesn't share that evidence with us or discuss particular events.
This is a self-serving press release, that's all.
The problem with writing faster and more streamlined code is that that comes at a cost. It used to be that you had to write the fastest possible code or your application just would not be practical. This caused performance to be the primary factor in software design and implementation choices.
This is no longer the case for the vast majority of software. This allows more focus to be put on testability, maintainability, simplicity, and so on. This results in more reliable code that can be more easily reused. It means new features can more easily be added. It means fewer bugs and an easier time locating the bugs that do crop up.
Being forced to give more important to performance, resource consumption, and other factors in software development *will* mean that other things will have to give. Nothing comes for free.
I lot of older programmers have to re-learn that things other than performance can be extremely important.
*Absolutely* true. While that obviously justifies pointing out when Microsoft's case studies are erroneous, self-serving, or both, it doesn't justify other people using the same tactics.
Not that I'm saying this article is as bad as most of those articles. It's not. No specifics is a lot better than completely false and misleading specifics pulled out of your corporate ass or intentionally deceptive test methodologies you pick but then get a "neutral third-party" to perform so they will "fairly and without bias" find that your product is best.
Microsoft: We didn't do these tests, Braincraft did. They found that our products were better.
Us: Did you pay them?
Microsoft: Well, yeah.
Us: Did you tell them what tests to perform and exactly how to perform?
Microsoft: Well, yeah.
Us: And did you already do those tests and carefully select the ones that make your product look the best without any regard for what thoses tests have to do with reality?
Microsoft: Well, that's all the time we have.
Linux.com and Mindbridge are both Linux companies. Mindbridge wants some attention, so it writes an article about how great Linux is and gets Linux.com to publish it. The article is very vague, no numbers, no specific case information, and no meat. It has no credibility.
This story has no credibility with me. The article is ridiculously light on details and seems to be an attempt at self-serving cross-promotion. There is no discussion of how they saved money or what those servers are actually doing. They talk about how much is costs them to "support" a Microsoft box, but they're such a small company, it's hard to imagine what their "support" even consists of.
They're a Linux company. They're telling us how great Linux is. They're not giving any details.
Personally, I have quite a bit of experience operating, maintaining, and supporting both Linux and Microsoft servers. I have found that both work well for the vast majority of applications. I've found other people's Linux servers to be easier to support than other people's Microsoft servers, but this might just be because the average Linux server contact is more knowledgeable than the average Microsoft server contact.
One huge difference is that it is *much* easier to figure out what a Linux server is doing and to start analyzing why it's not doing what it's supposed to do.
The idea that people will make better decisions with less information strikes me as completely bogus. Understanding that, for example, Microsoft has a vested interest in a standard being passed may well help people make better decisions.
To even suggest things this crazy, you must seriously misunderstand the purpose of the standardization process and how it works.
They probably don't do this in such an early chip because, as you suggest, this is intended to demonstrate capacity, not speed. But they can connect all the pins in parallel and minimize the pin count and *still* operate the chips in parallel. There are a number of ways to do this.
One simple way is for each device to have two 'chain' pins, one for 'in' and one for 'out'. You connect one chip's in to the supply, and then each chip's out to the next chip's in. The last chip's out is grounded. On power up, each chip looks at its in and out pins and figures out where in the sequence it is.
Then, when you want to write data, you put the last chip's data on the wire, pulse the clock, then the next to last, pulse the clock, and so on. Each chip knows which data it should store and when all the data has been sent, so they all store on the final pulse. For read, they all take the address at once, and then the last chip writes its output, when you send a clock pulse, that chip knows to stop sending its output and the second-to-last knows to start sending its output.
It can be done even if literally all the pins are connected together if each device has a unique burned-in serial number. There are simple techniques for each chip to detect what other chips it's connected to and to sort themselves into serial number order.