Most social science experiments, well actually probably the overwhelming majority, are not well-designed.
That is true, but that can not usually be fixed with a larger sample size. If your experiment's testing procedure is bunk, then increasing the sample size is not going to help one bit. Only very, very rarely can a poorly designed experiment be saved by throwing more samples at it.
There are ten thousand different ways to get misleading results out of a poorly designed experiment. One of those ways is interpreting noise in your data as a meaningful signal, where by the barest chance you get a bunch of data points that are all weird outliers by sheer luck.
The other nine thousand nine hundred and ninety-nine ways involve introducing bias into your data -- your experimental procedure is such that you systematically are measuring the wrong thing. Perhaps your experimental subject selection procedure is such that it tends to disproportionately select the weird outliers, or perhaps the phrasing of your questions causes people to answer a different question than the one you were aiming for. This is the broad category is mistakes that social science experiments are particularly vulnerable to.
Choosing a large sample size, and other statistical methods, help avoid the error where you are measuring noise and interpreting it as a useful signal. It does not do anything whatsoever to deal with bias problems. If your experiment falls prey to one of the nine thousand nine hundred and ninety-nine mistakes where it's measuring a biased signal, then making sure you have a large number of samples will not help in the slightest. Performing your experiment with a million subjects will prove oh so definitely that you are not looking at noise -- you have measured something, all right. But that something could either be a genuine result, or the consequence of bias in your data, and to tell the difference you'll have to examine your experimental procedure in a way that has nothing to do with statistics or sample sizes.
Large sample sizes are a remedy against one specific way to ruin your experiment, out of ten thousand gotchas to watch for. It doesn't mean your procedure is sound, only that it's one mistake you didn't make. And conversely, it's not a silver bullet to avoid the other nine thousand nine hundred and ninety-nine problems either -- if your sample size is large enough to avoid the noise-based problems, then making it even larger will not help with the other gotchas.
Therefore, whenever you see a study with a sample of 80 (or a few hundred) claiming this or that, the default reaction should be extreme doubt in the results.
In our company this is not necessary bad intent towards the customer, but more a way of protection our own business because selling only gives you 1 paycheck, service gives you hundreds in the course of years.
I hate to break it to you, but trying to extort the customer for maintenance IS bad intent towards them.
So when every yahoo on your segment fires up BitTorrent your VoIP stops working? No thank you.
Of course not. When every yahoo on my segment fires up bittorrent, everyone's available bandwidth gets limited to the total available bandwidth divided by the number of people. As long as I am using less bandwidth than that number, my traffic outprioritizes any and all data by users that exceed it. No content-based prioritization required.
As a service, you may prioritize MY voip traffic against MY torrents. But under no circumstances can there be tradeoffs between MY torrents and YOUR voip traffic -- that tradeoff is based on your and my traffic in general, without caring about the type.
I was talking about the more general case of locked-down phones, smart TVs, bluray players, and cars. I think that's currently legal in most of the world, but it shouldn't be.
Doing something like prioritizing VOIP packets over FTP, for instance, is perfectly acceptable,
Is it? I'm not sure I agree.
If my connection is saturated while I am using both VOIP and FTP, it is entirely acceptable to me that my ISP prioritizes my VOIP traffic over my FTP traffic.
If my ISP's total uplink connection is saturated (whether or not this should happen is another discussion), it is entirely acceptable to me that the ISP throttles its users that are currently using the highest amounts of bandwidth. Ideally, they throttle every user using more than X amounts of bandwidth down to X, where X is the highest number that they can sustain; and not do anything for all the users using less than X. This done without looking at the type of traffic of the different users, only the total bandwidth use. Of course, within the scope of a given user's such-throttled bandwidth, that's user's VOIP traffic may be prioritized over that user's FTP traffic, per the above clause.
But it is not acceptable to me if your VOIP traffic is prioritized over my FTP traffic independent of our total bandwidth usages. If I am trying to use 100 Mbit/s of FTP and you are trying to use 100 Mbit/s of VOIP and the ISP can only sustain 120 Mbit/s total, then it can throttle us both down to 60 Mbit/s, but it must not throttle me down to 20 Mbit/s instead because VOIP outprioritizes FTP. And when I am trying to use 50 Mbit/s with my FTP and you are trying to use 100 Mbit/s with your VOIP, then you go down to 70 Mbit/s, while my bandwidth stays intact.
If your move would repeat the previous board position, you must play somewhere else.
Then I highly doubt they calculated all legal positions in the game. They probably calculated all legal positions of the board, but that's a different thing.
The number of possible positions of the board is upper-bounded by 3^(19^2), with 19^2 positions that each can hold a black stone, a white stone, or no stone at all. This exact number was probably computed by this research.
But the possible positions of the game include not just the current board position, but also the set of all previous board positions; after all, the same board position can admit different future games, and be won by different players, depending on the previously-seen board positions. Thus, the possible positions of the game is vastly huger than the number of possible positions of the board, upper bounded by 2^(3^(19^2)).
6) WinIoT doesn't auto-update. Again, people would be pissed off if their "things" suddenly stopped working because an update broke compatibility. Not gonna happen.
The exact same consideration applies on desktop windows, and microsoft doesn't give a crap about such complaints in that area. Why would they feel differently for WinIoT?
I don't think anyone will dispute the claim that (for instance) platform independence is an important sysvinit feature that systemd has sacrificed, and that (say) being a single point of failure for dozens of mostly-independent subsystems is a significant architectural downside of systemd. I make no claims as to the relative importance most people attach to those downsides versus the real upsides of systemd, but downsides they be.
Most people will agree that systemd adds a number of important features to GNU/Linux that the old alternatives didn't offer.
This is very true. Most people will also agree that it accomplishes this at the cost of significant downsides inherent to the design of systemd, and sacrificing important features that the old alternatives do offer. The controversy is about whether the upsides are worth the downsides.
Adopting systemd will over time lead to a better system.
Depending on your position regarding the aforementioned tradeoff.
Well, division by zero should never happen, but you want it to be handled gracefully in case it does.
You are aware that segfaults are there specifically as a graceful handling of error conditions, right? We could just have every invalid memory access return 17 if we preferred. You seem to be underestimating just how nongraceful not aborting would be. The alternative to a segfault is a program that could go do absolutely anything, unpredictably.
Nobody wants the autopilot in charge of a barge train to segfault.
I would much prefer that over the autopilot deciding that its current speed is [broken computation... division by zero... "zero"] and the desired speed is 50km/h, so hit the accelerator until the division by zero situation resolves itself.
While C++ happens to be useful for cross platform mobile development, that's not because of C++ itself is better at cross platform development.
Yes it is. Well-written C++ code will run on any platform, whereas even the best java code only runs on the java platform. This makes C++ much more suitable for cross platform development than java.
Is this sophistry? I don't think so. Java is not a cross-platform system, java *is* a platform. And I think that no matter what the initial intentions may have been, time has shown that languages that compile to any platform, while less convenient than languages that bring their own platform, are actually the more flexible and practical for cross platform development of the two designs.
In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.
In my mind, it comes down to streamlining the common use cases for a given system, while throwing under the bus everyone who wants to do something with their system that Lennart didn't think of or doesn't care to support.
What we really need is some kind of standardized identity management system-- like you know how you can sign onto various sites using either your Facebook or Google+ sign-on? Like that, but standardized. We need a true single-sign-on solution that is easy to manage, hard to screw up and lose your identity permanently, and usable everywhere.
Is there any particular reason why we shouldn't just use public key authentication as the standard authentication method to use absolutely everywhere, optionally delegated to some remote single-signon service of your choice which is not in any way visible to the service you're authenticating against? This seems like the obviously correct solution to me, but for some reason I never see it mentioned in threads about replacing passwords as an authentication scheme.
If an activity is safe for a hobbyist to perform, why is it suddenly dangerous and in need of regulation when a professional does it?
Because "commercial" is really code for "on a large scale", and "hobbyist" is code for "on a small scale". What's safe on a small scale need not be safe on a large scale.
Of course, "commercial" is only a poor approximation of "on a large scale", but it's measurable and hard to game and does a pretty good job as an approximation in practice, so that's what the law will say.
Currently cars use several other technologies to prevent 'stupid' and everyone is ok with it.
The problem is that I, and very many people with me, find it ethically absolutely unacceptable to have tools work against their owners. This is exactly the reason why people hate DRM so much. My tools are mine and should listen to me only, and anyone trying to oppose that is evil. Seriously evil.
Also note that none of the examples you posted are an example of this.
Slashdot Mirror
Most social science experiments, well actually probably the overwhelming majority, are not well-designed.
That is true, but that can not usually be fixed with a larger sample size. If your experiment's testing procedure is bunk, then increasing the sample size is not going to help one bit. Only very, very rarely can a poorly designed experiment be saved by throwing more samples at it.
There are ten thousand different ways to get misleading results out of a poorly designed experiment. One of those ways is interpreting noise in your data as a meaningful signal, where by the barest chance you get a bunch of data points that are all weird outliers by sheer luck.
The other nine thousand nine hundred and ninety-nine ways involve introducing bias into your data -- your experimental procedure is such that you systematically are measuring the wrong thing. Perhaps your experimental subject selection procedure is such that it tends to disproportionately select the weird outliers, or perhaps the phrasing of your questions causes people to answer a different question than the one you were aiming for. This is the broad category is mistakes that social science experiments are particularly vulnerable to.
Choosing a large sample size, and other statistical methods, help avoid the error where you are measuring noise and interpreting it as a useful signal. It does not do anything whatsoever to deal with bias problems. If your experiment falls prey to one of the nine thousand nine hundred and ninety-nine mistakes where it's measuring a biased signal, then making sure you have a large number of samples will not help in the slightest. Performing your experiment with a million subjects will prove oh so definitely that you are not looking at noise -- you have measured something, all right. But that something could either be a genuine result, or the consequence of bias in your data, and to tell the difference you'll have to examine your experimental procedure in a way that has nothing to do with statistics or sample sizes.
Large sample sizes are a remedy against one specific way to ruin your experiment, out of ten thousand gotchas to watch for. It doesn't mean your procedure is sound, only that it's one mistake you didn't make. And conversely, it's not a silver bullet to avoid the other nine thousand nine hundred and ninety-nine problems either -- if your sample size is large enough to avoid the noise-based problems, then making it even larger will not help with the other gotchas.
Therefore, whenever you see a study with a sample of 80 (or a few hundred) claiming this or that, the default reaction should be extreme doubt in the results.
I don't think this follows at all.
Posting to cancel mistaken moderation.
In our company this is not necessary bad intent towards the customer, but more a way of protection our own business because selling only gives you 1 paycheck, service gives you hundreds in the course of years.
I hate to break it to you, but trying to extort the customer for maintenance IS bad intent towards them.
So when every yahoo on your segment fires up BitTorrent your VoIP stops working? No thank you.
Of course not. When every yahoo on my segment fires up bittorrent, everyone's available bandwidth gets limited to the total available bandwidth divided by the number of people. As long as I am using less bandwidth than that number, my traffic outprioritizes any and all data by users that exceed it. No content-based prioritization required.
As a service, you may prioritize MY voip traffic against MY torrents. But under no circumstances can there be tradeoffs between MY torrents and YOUR voip traffic -- that tradeoff is based on your and my traffic in general, without caring about the type.
I was talking about the more general case of locked-down phones, smart TVs, bluray players, and cars. I think that's currently legal in most of the world, but it shouldn't be.
Do you say this about your iPhone or your smart TV or your blueray player or your automobile?
Damn right I do.
There are also plenty of locked down models in the same market that do not let you modify firmware or certain settings.
And it's HIGH time this became very illegal.
If Google truly believed this, three quarters of the Android base operating systems would be individually installable and removable packages.
Doing something like prioritizing VOIP packets over FTP, for instance, is perfectly acceptable,
Is it? I'm not sure I agree.
If my connection is saturated while I am using both VOIP and FTP, it is entirely acceptable to me that my ISP prioritizes my VOIP traffic over my FTP traffic.
If my ISP's total uplink connection is saturated (whether or not this should happen is another discussion), it is entirely acceptable to me that the ISP throttles its users that are currently using the highest amounts of bandwidth. Ideally, they throttle every user using more than X amounts of bandwidth down to X, where X is the highest number that they can sustain; and not do anything for all the users using less than X. This done without looking at the type of traffic of the different users, only the total bandwidth use. Of course, within the scope of a given user's such-throttled bandwidth, that's user's VOIP traffic may be prioritized over that user's FTP traffic, per the above clause.
But it is not acceptable to me if your VOIP traffic is prioritized over my FTP traffic independent of our total bandwidth usages. If I am trying to use 100 Mbit/s of FTP and you are trying to use 100 Mbit/s of VOIP and the ISP can only sustain 120 Mbit/s total, then it can throttle us both down to 60 Mbit/s, but it must not throttle me down to 20 Mbit/s instead because VOIP outprioritizes FTP. And when I am trying to use 50 Mbit/s with my FTP and you are trying to use 100 Mbit/s with your VOIP, then you go down to 70 Mbit/s, while my bandwidth stays intact.
If your move would repeat the previous board position, you must play somewhere else.
Then I highly doubt they calculated all legal positions in the game. They probably calculated all legal positions of the board, but that's a different thing.
The number of possible positions of the board is upper-bounded by 3^(19^2), with 19^2 positions that each can hold a black stone, a white stone, or no stone at all. This exact number was probably computed by this research.
But the possible positions of the game include not just the current board position, but also the set of all previous board positions; after all, the same board position can admit different future games, and be won by different players, depending on the previously-seen board positions. Thus, the possible positions of the game is vastly huger than the number of possible positions of the board, upper bounded by 2^(3^(19^2)).
6) WinIoT doesn't auto-update. Again, people would be pissed off if their "things" suddenly stopped working because an update broke compatibility. Not gonna happen.
The exact same consideration applies on desktop windows, and microsoft doesn't give a crap about such complaints in that area. Why would they feel differently for WinIoT?
What you can't get away from entirely, you may still wish to minimize.
I don't think anyone will dispute the claim that (for instance) platform independence is an important sysvinit feature that systemd has sacrificed, and that (say) being a single point of failure for dozens of mostly-independent subsystems is a significant architectural downside of systemd. I make no claims as to the relative importance most people attach to those downsides versus the real upsides of systemd, but downsides they be.
Most people will agree that systemd adds a number of important features to GNU/Linux that the old alternatives didn't offer.
This is very true. Most people will also agree that it accomplishes this at the cost of significant downsides inherent to the design of systemd, and sacrificing important features that the old alternatives do offer. The controversy is about whether the upsides are worth the downsides.
Adopting systemd will over time lead to a better system.
Depending on your position regarding the aforementioned tradeoff.
Well, division by zero should never happen, but you want it to be handled gracefully in case it does.
You are aware that segfaults are there specifically as a graceful handling of error conditions, right? We could just have every invalid memory access return 17 if we preferred. You seem to be underestimating just how nongraceful not aborting would be. The alternative to a segfault is a program that could go do absolutely anything, unpredictably.
Nobody wants the autopilot in charge of a barge train to segfault.
I would much prefer that over the autopilot deciding that its current speed is [broken computation... division by zero... "zero"] and the desired speed is 50km/h, so hit the accelerator until the division by zero situation resolves itself.
While C++ happens to be useful for cross platform mobile development, that's not because of C++ itself is better at cross platform development.
Yes it is. Well-written C++ code will run on any platform, whereas even the best java code only runs on the java platform. This makes C++ much more suitable for cross platform development than java.
Is this sophistry? I don't think so. Java is not a cross-platform system, java *is* a platform. And I think that no matter what the initial intentions may have been, time has shown that languages that compile to any platform, while less convenient than languages that bring their own platform, are actually the more flexible and practical for cross platform development of the two designs.
In my mind, this comes down to whether we want a better functioning OS or an OS that adheres to the mindset that I think attracted many of us to Linux in the first place.
In my mind, it comes down to streamlining the common use cases for a given system, while throwing under the bus everyone who wants to do something with their system that Lennart didn't think of or doesn't care to support.
What we really need is some kind of standardized identity management system-- like you know how you can sign onto various sites using either your Facebook or Google+ sign-on? Like that, but standardized. We need a true single-sign-on solution that is easy to manage, hard to screw up and lose your identity permanently, and usable everywhere.
Is there any particular reason why we shouldn't just use public key authentication as the standard authentication method to use absolutely everywhere, optionally delegated to some remote single-signon service of your choice which is not in any way visible to the service you're authenticating against? This seems like the obviously correct solution to me, but for some reason I never see it mentioned in threads about replacing passwords as an authentication scheme.
If an activity is safe for a hobbyist to perform, why is it suddenly dangerous and in need of regulation when a professional does it?
Because "commercial" is really code for "on a large scale", and "hobbyist" is code for "on a small scale". What's safe on a small scale need not be safe on a large scale.
Of course, "commercial" is only a poor approximation of "on a large scale", but it's measurable and hard to game and does a pretty good job as an approximation in practice, so that's what the law will say.
Mining ASICs don't count, though -- ASICs are not microprocessors, so they don't run code, written in assembly or otherwise.
Why exactly is it different when talking about cellphones? The exact same approach still works. What could Starbucks do to improve on this?
Sounds like a triumph of Amazing Breakthrough Day.
Then again, most people who are not technically knowledgeable don't try to make laws about it.
Likewise, just because copyright is broken doesn't mean we should get rid of it either.
No, but the notion that the whole basic concept is a bad one sure does.
For one thing, for many applications you NEED the plaintext passwords. You can't do cram-md5 authentication without it, for example.
Currently cars use several other technologies to prevent 'stupid' and everyone is ok with it.
The problem is that I, and very many people with me, find it ethically absolutely unacceptable to have tools work against their owners. This is exactly the reason why people hate DRM so much. My tools are mine and should listen to me only, and anyone trying to oppose that is evil. Seriously evil.
Also note that none of the examples you posted are an example of this.