It's worth pointing out that this type of response by drivers is predictable. Not necessarily watching TV but zoning out in one way or another. You'll see Tesla trot out the excuse every time as well: "This system requires constant monitoring by the driver, it's not really fully self-driving, and the crash was the driver's fault for not paying attention when they should have."
But: equal--or even more--blame has to go to the designers of the system and testing protocol for not taking this obvious and well known fact about human behavior into consideration when designing their system and their testing protocol.
It's a simple fact of human behavior that once the system looks like it's working OK for a few dozen to a few hundred miles, you assume it's OK and you start to tune out.
In reality, drivers average between 90 million (auto v. auto fatalities) and 480 million (auto v. pedestrian fatalities) miles between fatal collisions. So a system that can manage to go a few dozen or a few hundred miles without anything disastrous happening is still many orders of magnitude less capable than even the worst human driver. But once the automated system has driven a certain route a few times successfully, just about any human "monitor" is going to start have confidence in the system and tune out.
There are many ways around this issue, and companies shouldn't be allowed to test self-driving systems out on the public roads without using some or all of them:
* Far more extensive testing can be done using simulators etc before going live on public roads. They should be testing many billions of miles in this type of environment first. Some companies are putting more emphasis on this now (ie, nVidia). All should be required to do this or something similar.
* Far more testing should be done on tracks & other non-public locations before testing proceeds on public roads.
* Systems should not be allowed to be tested on the public roads until they have proven they are actually capable.
* If systems do require human "safety drivers" as a backup then various monitoring systems and protocols must be in place to ensure that the humans are actually doing the work. You can't just hire random people at $12/hour, give them 3 hours of training, and hope. That is guaranteed failure.
* Companies doing this type of testing need to be 100% responsible for anything that goes wrong. The fact that some employee wasn't doing something 100% right is no excuse. The companies need to have enough of a safety culture, safety system, and safety protocol in place that they know whether or not any individual tester is doing what they should or not.
* Most of all, these safety-critical systems must be engineered in an environment of safety-critical engineering. Not the "move fast and break things" bullshit software development culture that is currently so pervasive.
"Move fast and break things" might be a great philosophy for developing a cell phone app, but operating a motor vehicle is a safety critical system operating in an environment with very high risk of serious injury and death. The systems and the testing must be designed to take this seriously from top to bottom.
FWIW Uber's corporate culture is like the polar opposite of this from top to bottom.
Congress is trying to pass a bill to allow nationwide testing of self-driving vehicle that is laughably lacking in any type of oversight. More here:
This is a known characteristic of the Tesla "autopilot". I wouldn't even call it a "defect" per se as it is simply operating as it is designed to work.
It won't pick up stationary objects, particularly if there is another vehicle in front of the autopilot vehicle, going about the same speed, and then that vehicles move aside with the stationary object right in the middle of the lane.
This is one reason of many why the Tesla system requires constant supervision by the human driver.
Of course the reason the whole type of system is a really bad idea is because it works great 99.9% of the time. Thus lulling the human driver into a false sense of security and safety. So then the human driver tunes out. Then 2000 miles later (or whatever) the "Autopilot" encounters a situation it can't handle and you wham into the back of a firetruck or whatever.
Related to this, Elon Musk has repeatedly claimed that Autopilot is safer than human drivers.
This claim is extremely exaggerated for a few reasons.
First of all, Musk is comparing autopilot to a human driver crash rates for ALL existing vehicles and ALL types of drivers.
But Tesla drivers are very much a self-selected subset of all drivers. Drivers of other similar expensive luxury type cars are quite a lot safer drivers than average.
Furthermore, vehicles in the similar price range to Teslas have many advanced safety features, ranging from crash-resistant construction to automated collision avoidance systems. So this type of vehicle is a few times safer than the average vehicle--which include older vehicles, pickup trucks, etc etc etc.
Finally, "Autopilot" is most typically used on the type of roads that are quite a lot safer than the average road. These roads are roughly 2X safer than average.
Putting this all together, Tesla "Autopilot" is approximately 10X more likely to be involved in a fatal crash than similar vehicles with similar drivers operating on similar roads. More detailed analysis here and here.
This type of analysis might go over the heads of the average citizen, but it's the type of thing Slashdot readers should be able to get their minds around.
And Musk really needs to get some pushback from the technical community when he makes this type of unsupportable claim.
The situation is where you are following another vehicle going about your same speed. It moves out of the way and there is a fire truck (or some other stationary object) direct ahead and stopped. The system doesn't recognize the stopped object and in fact will accelerate back to the programmed cruise speed instead of stopping.
So this is one (of many!) reasons the Autopilot & similar systems say that the driver must remain continually aware ready to re-take control of the vehicle at any moment.
The problem with this scenario is--as nearly every autopilot crash so far has demonstrated--that this goes 100% counter to human nature.
Once the autopilot has driving a few hundred or a few thousand miles successfully, the human driver starts to trust it more and more, and tune out more and more. Monitoring a very good autopilot system is b-o-r-i-n-g and, interestingly, the better the system the more boring it becomes.
Any human in this situation is going to tune out for lengthy periods of time.
Instead of human plus automated driving adding together to achieve a system that is safer than either alone (which seems to be the case for currently available collision avoidance systems which never take control of the vehicle except in rare collision situations) you end up with a system that combines the worst characteristics of human and automated driving.
The human zones out way too often (again, a predictable outcome of this type of system) while the Level 2 automated system has many, many blind spots.
I haven't tried this myself, but from the specs it looks to be reasonable inexpensive, reasonably small and light, and reasonably powerful:
- Intel NUC (about 1 pound)
- fit-Uptime UPS for mini-PCs (about 0.5 pound and should power the NUC for maybe 1-3 hours on battery, depending on exact model of NUC etc)
At 20 MPH, 5% of pedestrians involved in a car-pedestrian collision will die.
At 30 MPH, it is 37-45%.
At 40 MPH it is 83-85%.
If you are thinking of traffic as simple car vs car, then speed limit should be one thing--probably a lot higher than they are now. Because people in cars are pretty impervious to injury.
But as soon as you realize that **this street is going through a neighborhood** everything changes. Honestly we should not allow cars (or anything else) to go faster than 15-20 MPH in neighborhoods and places where there are many people.
Fast driving drives away people and endangers them. That is the opposite of what we want in our communities.
The most effective strategy for eliminating traffic fatalities has relied heavily on this approach--reduce speed, and fatalities reduce at least proportionately.
All chiclet style keyboards die in a fire and (at least for desktop computers where 'slimness' isn't either needed or a virtue, all keyboards must have a decent tactile feel. Something like the IBM Model M. http://www.theverge.com/2014/1...
I believe that both China and Russia had access to all the files that Snowden took well before Snowden took them because they've penetrated the NSA networks where those files reside.I believe that both China and Russia had access to all the files that Snowden took well before Snowden took them because they've penetrated the NSA networks where those files reside.
Uh, yeah. This was obvious from the beginning. If it was that easy for Snowden to grab all of those files without anyone noticing anything until it was too late, how many other bazillions of employees, contractors, sysadmins, etc etc etc etc also had similar access.
The Chinese & Russians (and others--Brits, Israelis, what have you) are actively trying to subvert all these thousands of folks.
It's really not rocket science, or even computer science. More, do you have the right contact. With so many potential contacts it becomes almost inevitable.
And that's without even getting into technical break-ins--which also seem very, very possible given the lax security that the Snowden affair demonstrates. If Snowden can get unauthorized access to all those files, then it's possible for others to do so as well.
One of my math professors worked for some kind of engineering firm in his earlier days. This was probably back in the 70s or so.
They were creating some kind of device and it was based on a math theorem of some kind--the usual thing where there are hypotheses A, B, C and **if those are exactly fulfilled** then there is a little algorithm you can use to give result X, Y, Z.
So his fellow engineers used this theorem, using the algorithm and result X, Y, Z but blithely ignoring the need to check that hypotheses A, B, C were fulfilled.
Prof warns fellow workers that this isn't going to work and is a recipe for disaster.
Fellow engineer-workers can't understand what the problem could possibly be, so proceed to manufacture the device as-is. It is some kind of hard-wired measuring tool or such, with custom manufactured circuit boards that bake in the programming logic etc etc etc.
Result: Device worked perfectly most of the time but occasionally, randomly, mysteriously completely malfunctioned. Of course--it worked perfectly whenever the hypotheses were fulfilled and complete malfunctioned otherwise.
Other result: Firing of numerous people on engineering team and complete re-design of the device from the ground up.
To answer your question: The reason not to follow your plan is that ALL of your programs are going to behave like this device. They will work fine most of the time (if you are lucky) but then there will be random and very-difficult-to-detect bugs that appear only during certain relatively rare and difficult-to-duplicate circumstances.
I dunno . . . more than half of "cleverly-chosen minor falsehoods" inserted into 30 articles are corrected within 2 months? That sounds more like **is** self-correcting than **is not**.
Nothing is perfectly self-correcting and that holds up here, too. But through the mid-2000s we kept a shelf full of encyclopedias dating from the 1980s or so. I'm pretty sure that thing was packed with various bits of incorrect, erroneous, outdated, and incomplete information, and strangely enough, not one snippet of it ever self-corrected in the 20 years the encyclopedias sat on the shelf.
He's developed his own measure for it: The percentage of people who will develop the disease of dependency, based on the DSM-IV guidelines, if they use a drug. . . .
"According to that, the most chemically addictive is nicotine because one third of people who use it during their lifetime will develop dependency," he said. "For cocaine, it's 20 percent. For heroin, it's 23 percent."
But if our work was open and people were forking it and improving it all the time, then it keeps up with changes as we go.
And meanwhile, will help all the Democrats* in down-ballot and off-year races--who, near as I can tell, are typically disorganized as possible about GOTV.
Yeah, and Republicans, too, but really the downballot Dems need more help as a rule and IMHO Ds will benefit far more in aggregate than Rs will.
Oh, yeah--and don't forget to take him through the economics of the project as well. "See, you've refactored this 100 lines of code, which only took you 8 hours, costing the company $X."
Now just do the math about how much it would cost to complete this little refactoring project on the entire codebase. It will be a fairly boggling amount and of course doesn't take into consideration that this simplistic estimation procedure will underestimate the cost and complexity of a full codebase refactoring by a few orders of magnitude.
Still, I'm guessing even the simplistic method will cost enough to make your point.
If the code is so bad, give him the assignment of fixing it. Allot say 8 hours, or maybe even a week if you want to get him out of your hair for that long, where is assignment is to find the worst problem area that will have the greatest possible positive effect on the project, that he can fix start-to-finish within that time span, re-write, test, go through your complete process whatever that is, get completely ready to commit. But it all has to be done/complete within the allotted time frame.
At the end of the time, take his code, evaluate & review it with him & 2-3 others who are intimately familiar with that project. If it's fabulous code that really does meet all requirements and improve on the existing code, then hurrah! Commit it and you're a step ahead.
If (as is more likely) is full of shit and has far more serious but possibly hidden problems than the code it's supposed to replace, then you explain the problems to your boy wonder, deep six the supposed improved code, and it's a learning experience for everyone.
Our current musical scale is a human creation and has nothing to do with how sound works.
Quite the contrary: Our current musical scale is a human creation and has something to do with how sound works.
Obviously, there are a lot of different ways to make scales and tonalities and music (and even music that doesn't have scales or tonalities). But there is no question that the currently used western scales and tonalities are a complex interplay among the physical properties of sound, the human auditory system, and human thought about sound.
Obviously another culture could take on this same elements, the same interplay and come up with a complete different answer, because the physical properties of sound remain the same but the other two elements are quite subjective. But that is a lot different than saying our current musical scale "has nothing to do with how sound works." Pretty much every single element of the scale and how it is used is shaped by some portion of the physical property of sound.
Slashdot Mirror
It's worth pointing out that this type of response by drivers is predictable. Not necessarily watching TV but zoning out in one way or another. You'll see Tesla trot out the excuse every time as well: "This system requires constant monitoring by the driver, it's not really fully self-driving, and the crash was the driver's fault for not paying attention when they should have."
But: equal--or even more--blame has to go to the designers of the system and testing protocol for not taking this obvious and well known fact about human behavior into consideration when designing their system and their testing protocol.
It's a simple fact of human behavior that once the system looks like it's working OK for a few dozen to a few hundred miles, you assume it's OK and you start to tune out.
In reality, drivers average between 90 million (auto v. auto fatalities) and 480 million (auto v. pedestrian fatalities) miles between fatal collisions. So a system that can manage to go a few dozen or a few hundred miles without anything disastrous happening is still many orders of magnitude less capable than even the worst human driver. But once the automated system has driven a certain route a few times successfully, just about any human "monitor" is going to start have confidence in the system and tune out.
There are many ways around this issue, and companies shouldn't be allowed to test self-driving systems out on the public roads without using some or all of them:
* Far more extensive testing can be done using simulators etc before going live on public roads. They should be testing many billions of miles in this type of environment first. Some companies are putting more emphasis on this now (ie, nVidia). All should be required to do this or something similar.
* Far more testing should be done on tracks & other non-public locations before testing proceeds on public roads.
* Systems should not be allowed to be tested on the public roads until they have proven they are actually capable.
* If systems do require human "safety drivers" as a backup then various monitoring systems and protocols must be in place to ensure that the humans are actually doing the work. You can't just hire random people at $12/hour, give them 3 hours of training, and hope. That is guaranteed failure.
* Companies doing this type of testing need to be 100% responsible for anything that goes wrong. The fact that some employee wasn't doing something 100% right is no excuse. The companies need to have enough of a safety culture, safety system, and safety protocol in place that they know whether or not any individual tester is doing what they should or not.
* Most of all, these safety-critical systems must be engineered in an environment of safety-critical engineering. Not the "move fast and break things" bullshit software development culture that is currently so pervasive.
"Move fast and break things" might be a great philosophy for developing a cell phone app, but operating a motor vehicle is a safety critical system operating in an environment with very high risk of serious injury and death. The systems and the testing must be designed to take this seriously from top to bottom.
FWIW Uber's corporate culture is like the polar opposite of this from top to bottom.
Congress is trying to pass a bill to allow nationwide testing of self-driving vehicle that is laughably lacking in any type of oversight. More here:
http://saferoads.org/2018/06/1...
https://www.cnbc.com/2018/06/1...
This is a known characteristic of the Tesla "autopilot". I wouldn't even call it a "defect" per se as it is simply operating as it is designed to work.
It won't pick up stationary objects, particularly if there is another vehicle in front of the autopilot vehicle, going about the same speed, and then that vehicles move aside with the stationary object right in the middle of the lane.
This is one reason of many why the Tesla system requires constant supervision by the human driver.
Of course the reason the whole type of system is a really bad idea is because it works great 99.9% of the time. Thus lulling the human driver into a false sense of security and safety. So then the human driver tunes out. Then 2000 miles later (or whatever) the "Autopilot" encounters a situation it can't handle and you wham into the back of a firetruck or whatever.
And no, I'm not making this up:
https://www.wired.com/story/te...
http://www.newsweek.com/tesla-...
https://www.teslarati.com/tesl...
FWIW Tesla has approx. 5-10X more fatal crashes than do similar cars driven by similar drivers on similar roads.
They are not by any stretch safer than human drivers. This is a myth promulgated by a master salesman.
I'm still on Eudora as well. It looks like my oldest sent mail there is 1/29/1995 and I've got a few pieces of incoming mail from 12/1994.
For various reasons, it's becoming gradually less & less tenable with time, but it's still my daily driver.
Related to this, Elon Musk has repeatedly claimed that Autopilot is safer than human drivers.
This claim is extremely exaggerated for a few reasons.
First of all, Musk is comparing autopilot to a human driver crash rates for ALL existing vehicles and ALL types of drivers.
But Tesla drivers are very much a self-selected subset of all drivers. Drivers of other similar expensive luxury type cars are quite a lot safer drivers than average.
Furthermore, vehicles in the similar price range to Teslas have many advanced safety features, ranging from crash-resistant construction to automated collision avoidance systems. So this type of vehicle is a few times safer than the average vehicle--which include older vehicles, pickup trucks, etc etc etc.
Finally, "Autopilot" is most typically used on the type of roads that are quite a lot safer than the average road. These roads are roughly 2X safer than average.
Putting this all together, Tesla "Autopilot" is approximately 10X more likely to be involved in a fatal crash than similar vehicles with similar drivers operating on similar roads. More detailed analysis here and here.
This type of analysis might go over the heads of the average citizen, but it's the type of thing Slashdot readers should be able to get their minds around.
And Musk really needs to get some pushback from the technical community when he makes this type of unsupportable claim.
Honestly it is a pretty amazing accomplishment that Tesla's Autopilot is even in the same ballpark as human drivers. It does give some reasonable hope that technical advances will be able to advance automated driving until it is actually safer than humans (though Tesla systems are unlikely to ever get there, as their sensors simply are not up to the task).
But still the "Autopilot" system is a whole order of magnitude more dangerous than similar vehicles with similar drivers on similar roads.
Both Tesla drivers and the general public need to understand that. When you switch on "Autopilot" you are literally trading convenience for safety.
In short, this is a known characteristic of this type of system.
The situation is where you are following another vehicle going about your same speed. It moves out of the way and there is a fire truck (or some other stationary object) direct ahead and stopped. The system doesn't recognize the stopped object and in fact will accelerate back to the programmed cruise speed instead of stopping.
So this is one (of many!) reasons the Autopilot & similar systems say that the driver must remain continually aware ready to re-take control of the vehicle at any moment.
The problem with this scenario is--as nearly every autopilot crash so far has demonstrated--that this goes 100% counter to human nature.
Once the autopilot has driving a few hundred or a few thousand miles successfully, the human driver starts to trust it more and more, and tune out more and more. Monitoring a very good autopilot system is b-o-r-i-n-g and, interestingly, the better the system the more boring it becomes.
Any human in this situation is going to tune out for lengthy periods of time.
Instead of human plus automated driving adding together to achieve a system that is safer than either alone (which seems to be the case for currently available collision avoidance systems which never take control of the vehicle except in rare collision situations) you end up with a system that combines the worst characteristics of human and automated driving.
The human zones out way too often (again, a predictable outcome of this type of system) while the Level 2 automated system has many, many blind spots.
I haven't tried this myself, but from the specs it looks to be reasonable inexpensive, reasonably small and light, and reasonably powerful:
- Intel NUC (about 1 pound)
- fit-Uptime UPS for mini-PCs (about 0.5 pound and should power the NUC for maybe 1-3 hours on battery, depending on exact model of NUC etc)
At 20 MPH, 5% of pedestrians involved in a car-pedestrian collision will die.
At 30 MPH, it is 37-45%.
At 40 MPH it is 83-85%.
If you are thinking of traffic as simple car vs car, then speed limit should be one thing--probably a lot higher than they are now. Because people in cars are pretty impervious to injury.
But as soon as you realize that **this street is going through a neighborhood** everything changes. Honestly we should not allow cars (or anything else) to go faster than 15-20 MPH in neighborhoods and places where there are many people.
Fast driving drives away people and endangers them. That is the opposite of what we want in our communities.
The most effective strategy for eliminating traffic fatalities has relied heavily on this approach--reduce speed, and fatalities reduce at least proportionately.
Sources:
http://www.visionzeroinitiativ...
http://humantransport.org/side...
All chiclet style keyboards die in a fire and (at least for desktop computers where 'slimness' isn't either needed or a virtue, all keyboards must have a decent tactile feel. Something like the IBM Model M. http://www.theverge.com/2014/1...
1. Physical keyboard on all phones
2. Phone battery lasts 2-3 days with phone becoming however much thicker as needed to make that happen.
I believe that both China and Russia had access to all the files that Snowden took well before Snowden took them because they've penetrated the NSA networks where those files reside.I believe that both China and Russia had access to all the files that Snowden took well before Snowden took them because they've penetrated the NSA networks where those files reside.
Uh, yeah. This was obvious from the beginning. If it was that easy for Snowden to grab all of those files without anyone noticing anything until it was too late, how many other bazillions of employees, contractors, sysadmins, etc etc etc etc also had similar access.
The Chinese & Russians (and others--Brits, Israelis, what have you) are actively trying to subvert all these thousands of folks.
It's really not rocket science, or even computer science. More, do you have the right contact. With so many potential contacts it becomes almost inevitable.
And that's without even getting into technical break-ins--which also seem very, very possible given the lax security that the Snowden affair demonstrates. If Snowden can get unauthorized access to all those files, then it's possible for others to do so as well.
One of my math professors worked for some kind of engineering firm in his earlier days. This was probably back in the 70s or so.
They were creating some kind of device and it was based on a math theorem of some kind--the usual thing where there are hypotheses A, B, C and **if those are exactly fulfilled** then there is a little algorithm you can use to give result X, Y, Z.
So his fellow engineers used this theorem, using the algorithm and result X, Y, Z but blithely ignoring the need to check that hypotheses A, B, C were fulfilled.
Prof warns fellow workers that this isn't going to work and is a recipe for disaster.
Fellow engineer-workers can't understand what the problem could possibly be, so proceed to manufacture the device as-is. It is some kind of hard-wired measuring tool or such, with custom manufactured circuit boards that bake in the programming logic etc etc etc.
Result: Device worked perfectly most of the time but occasionally, randomly, mysteriously completely malfunctioned. Of course--it worked perfectly whenever the hypotheses were fulfilled and complete malfunctioned otherwise.
Other result: Firing of numerous people on engineering team and complete re-design of the device from the ground up.
To answer your question: The reason not to follow your plan is that ALL of your programs are going to behave like this device. They will work fine most of the time (if you are lucky) but then there will be random and very-difficult-to-detect bugs that appear only during certain relatively rare and difficult-to-duplicate circumstances.
In short--nightmare material.
In other news, "Climate Change Skeptics Reveal Selves As Opportunistic Self Promoting Media Grubbing Asshats".
A law that is violated in my garden every Spring as the seeds germinate, take root, send up leaves, and decrease atmospheric carbon dioxide.
Put succinctly: Nope.
I dunno . . . more than half of "cleverly-chosen minor falsehoods" inserted into 30 articles are corrected within 2 months? That sounds more like **is** self-correcting than **is not**.
Nothing is perfectly self-correcting and that holds up here, too. But through the mid-2000s we kept a shelf full of encyclopedias dating from the 1980s or so. I'm pretty sure that thing was packed with various bits of incorrect, erroneous, outdated, and incomplete information, and strangely enough, not one snippet of it ever self-corrected in the 20 years the encyclopedias sat on the shelf.
Lots of my colleagues do not want to ride after seeing these [city biking] injuries.
And I don't want to drive after seeing a few injuries that resulted from automobile collisions . . .
He's developed his own measure for it: The percentage of people who will develop the disease of dependency, based on the DSM-IV guidelines, if they use a drug. . . .
"According to that, the most chemically addictive is nicotine because one third of people who use it during their lifetime will develop dependency," he said. "For cocaine, it's 20 percent. For heroin, it's 23 percent."
So by that standard, Oreos = 0% addictive.
Oh, well.
"the comments are where the real America is"
Uh, nope.
Who's the branding genius behind the name "Rape-Scan Systems".
I mean, really, that's exactly what it is--but usually they don't admit it so blatantly . . .
This is bad news for two reasons:
Boy, never thought I'd see myself defending North Korea about anything. Looks like in the North Korea vs. MPAA evilness matchup, MPAA wins . . .
But if our work was open and people were forking it and improving it all the time, then it keeps up with changes as we go.
And meanwhile, will help all the Democrats* in down-ballot and off-year races--who, near as I can tell, are typically disorganized as possible about GOTV.
Yeah, and Republicans, too, but really the downballot Dems need more help as a rule and IMHO Ds will benefit far more in aggregate than Rs will.
Oh, yeah--and don't forget to take him through the economics of the project as well. "See, you've refactored this 100 lines of code, which only took you 8 hours, costing the company $X."
Now just do the math about how much it would cost to complete this little refactoring project on the entire codebase. It will be a fairly boggling amount and of course doesn't take into consideration that this simplistic estimation procedure will underestimate the cost and complexity of a full codebase refactoring by a few orders of magnitude.
Still, I'm guessing even the simplistic method will cost enough to make your point.
If the code is so bad, give him the assignment of fixing it. Allot say 8 hours, or maybe even a week if you want to get him out of your hair for that long, where is assignment is to find the worst problem area that will have the greatest possible positive effect on the project, that he can fix start-to-finish within that time span, re-write, test, go through your complete process whatever that is, get completely ready to commit. But it all has to be done/complete within the allotted time frame. At the end of the time, take his code, evaluate & review it with him & 2-3 others who are intimately familiar with that project. If it's fabulous code that really does meet all requirements and improve on the existing code, then hurrah! Commit it and you're a step ahead. If (as is more likely) is full of shit and has far more serious but possibly hidden problems than the code it's supposed to replace, then you explain the problems to your boy wonder, deep six the supposed improved code, and it's a learning experience for everyone.
Quite the contrary: Our current musical scale is a human creation and has something to do with how sound works.
Obviously, there are a lot of different ways to make scales and tonalities and music (and even music that doesn't have scales or tonalities). But there is no question that the currently used western scales and tonalities are a complex interplay among the physical properties of sound, the human auditory system, and human thought about sound.
Obviously another culture could take on this same elements, the same interplay and come up with a complete different answer, because the physical properties of sound remain the same but the other two elements are quite subjective. But that is a lot different than saying our current musical scale "has nothing to do with how sound works." Pretty much every single element of the scale and how it is used is shaped by some portion of the physical property of sound.
"Vote for us, because the alternative is horrible" is not a very inspiring reason to vote.
I dunno, "the alternative is horrible" inspires me pretty well . . .