Because using cellphones statistically seems to downgrade everyone a bit
[citation needed]
Seriously, do you have any good basis for your claim? In particular, which studies use the correct baseline of "distracted by everything except cell phone", rather than "not distracted", when comparing the impact of driving "distracted by a cell phone"? The US death rate due to traffic accidents dropped quite a lot over the last two decades -- and that is true whether you measure deaths per vehicle-mile, per capita, or per registered vehicle. (For example, fatalities per 100 million vehicle-miles traveled dropped from 1.73 in 1994 to 1.14 in 2009, even as phones-in-cars went from near zero to near ubiquitous.) Sure, we have a lot of other new safety systems in newer cars that help bring death rates down, but the marginal distraction due to mobile phone use is obviously hard to quantify.
I'm halfway convinced you are engaging in some kind of elaborate troll or performance art. You are the one who is attaching automated testing (and tagging based on the results) to a revision control system; I am not. I have professionally developed software in a (useful) business setting, and I have managed a ten-person software development group. I saw the increase in code quality -- and more predictable release schedules -- when I migrated that group from Subversion to Git+Gerrit (which imposes mandatory code review and a tested-by sign-off before a change is applied to the line of development).
Revision control systems are for recording a series of configuration snapshots that you care about. The qualifier at the end is critical.
If what you care about is breaking the configuration for fellow developers, and that works for you, that's fine: keep committing untested changes. Just don't tell me that I am wrong for rejecting that model. When I am working with one or two other people, I do not care so much: They are not likely to break anything so badly that I cannot reverse it or work around it easily, but I still like to be able to bisect to find regressions. (Some of my less capable coworkers care more even at small scales.) When I am working with a lot of other people, I do care whether people test before merging their changes: Without some discipline, the chance that someone will break something important goes up with at least the square of the code churn rate.
Your second paragraph is pretty gutsy for a guy who claimed that someone *else* wasn't doing real (team) development.
The point is not that people only commit fully functional code -- just that they only commit reasonably functional code; that means code that others could reliably use as a basis for further development. During a development phase, that usually means missing features or known bugs. But see also how the Linux kernel, gcc, and other large free software code bases are maintained: They all have phases or steps where they only accept changes to the baseline if those changes are believed to be defect-free.
I provided additional reasoning for shared development servers in a separate reply.
Why have a development server if everything is tested locally? A development server is useful for integration purposes and for running tools or tests that are not in the "innermost loop" of development: churn statistics, perhaps static analysis, builds for less-used targets or feature combinations, and so forth.
Why bother testing locally? Committing a broken build to a shared development line is counterproductive for you and frustrating for other developers. (I am tempted to draw an analogy with defecating on another person's dinner plate.) Depending on the scope of the breakage, others might be unable to test their changes, may get false failures from their tests, or may ignore true test failures because the test was failing before their commit. Tests are also never perfect, and automated tests are especially prone to missing things. If you discover an regression that escaped the automated tests, and have a culture of not caring whether commits work, it makes it much harder to identify the source of the regression.
Have you ever used any revision system except Subversion?
Your entire workflow seems based around a high-powered central server with a reliable pipe to every developer. That isn't true for a lot of people, and will usually not scale well (even if you have a cloud deployment of your CI tools, running enough tests to adequately test a commit will increase the cycle time before it gets marked as good or bad).
If someone asked me to work on a shared repository that had more than about 5% non-working commits, I would find a different place to work. My time and sanity are worth more than the alleged benefits of a dumb client/smart server development system.
Even more than that, what the heck does the "85 percent" rate mean? I would think that MIT's press release could at least bother to indicate sensitivity and specificity as separate numbers. If they falsely predict that 15% of people (one out of roughly six) who stop are about to run the light, that poses major problems for any field use of the system.
On the off chance that you're not trolling in a phenomenally stupid manner: Take your cultural relativism and your totalitarian apologetics and shove them where the sun doesn't shine.
My "less harmful" was meant primarily in the sense that a posteriori censorship of known content is more specific (less likely to result in an unintended match) than a priori censorship based on keywords or similar patterns. But if you want to look at it from a moral perspective, then yes, Google's censorship of sites selling illegal wares is still less harmful than China's censorship of peaceful dissent.
There is definitely less -- and less harmful -- censorship in Google's results. Chinese search engines block results by words and phrases (what kind of results do you think you'd get for "Tiananmen Square"?). Google blocks results by URL (which is easier to change without changing the message).
If CouchDB doesn't work, there are at least six other competing solutions that will tell you how they are a better fit for your needs than all the others. Cassandra, Hadoop/HBase, MongoDB, and more. If one doesn't work for you, you can waste as much time as you like trying the others!
If no one is required to provide some service, how are you going to get on the Internet with unfiltered access? (Have you forgotten what "ISP" stands for?)
There are a bunch of defensible regulations, like network neutrality. There are a bunch of really bad ideas -- like "three strikes" laws when the mechanism is enforced by ISPs and copyright owners, with no judicial oversight or involvement. But there is a huge difference between saying that you have a right to speak your mind and saying that when you contract with an Internet service provider for network access, they have this or that restriction on how they route packets. The latter is not a right.
Also, on medical care: US law prohibits discrimination based on the protected classes you mention -- at least by providers of public accommodations that are used in interstate commerce (it is amazing how much of US Federal law would fall apart without Wickard v. Filburn). US law also requires providers who accept Medicare to (at least) stabilize all patients, even if the patients cannot afford to pay -- but this is as a condition of accepting the funding. It does not recognize a right to medical care.
I did not claim that the Declaration of Independence was legally binding -- just that it listed rights that were recognized as inalienable. Many philosophers -- particularly those who influenced the Founding Fathers -- view(ed) inalienable rights as ones that are inherent to a person; they can be recognized by a government, but that does not establish or grant them as rights. At any rate, the Constitution does not use the term "inalienable right", and I did not want to get into a pedantic argument whether phrases like "shall not be infringed" or "shall not be violated" meant "inalienable right".
No. As counter-examples, the Declaration of Independence identified life, liberty and the pursuit of happiness as inalienable rights. The death penalty deprives people of life -- and was generally accepted for a long time (even now the usual arguments against are based on morality and accuracy rather than government powers). Imprisonment, or even pre-trial detention, deprives people of liberty.
Perhaps a better way to think of an inalienable right is something that you cannot give to someone else.
Whether the right is "Internet" or "unfiltered Internet access" (or food or shelter or healthcare) is irrelevant to the property-rights/contract question.
There is certainly an argument to be made that network neutrality is a reasonable regulation. I just don't think it makes sense to present it as a right.
So what happens if the government recognizes "unfiltered Internet access" as an inalienable right?
imamac's point was that recognizing it as a right doesn't get you anywhere. It is like saying food security or access to medical care is an inalienable right: Somebody has to pay to provide it, and it requires the transfer of goods or services from one person to another. That makes it different from the things that we traditionally recognize as inalienable rights.
Normal stock is shares you own. Vested options let you buy a share of stock at a particular price. Unvested options will let you buy a share at some point in the future, assuming certain conditions occur (for these employee incentive plans, usually the options vest after a certain period of time if you remain employed by the company).
There is a simple explanation for why the US is not a polite society: The particularly impolite people in the US are the same ones who want to confiscate all the weapons.
It is one thing to look at somebody else's work product and be impressed. It's an entirely different thing to look at your own and decide that, yea verily, that was a nearly optimal way to spend your time. (The major difference is that you usually have a much better idea of how much time and frustration you spent than what someone else spent.) Unless your objective is making computers run fast or maintaining the OS, time spent tweaking things at a low level -- which FreeBSD requires -- is probably not worth it.
The effort spent by programmers around the world who have written GObject overhead -- the annotations in C, the extra macros when using it, and so forth -- dwarfs what it would take to create a tool to extract similar information from C++ class definitions. There are free-software C++ parsers out there, and well-known techniques to extract annotations from comments.
But hey, GObject lets people save an entire register that might otherwise be dedicated to the "this" pointer.
My point was that you are just hand-waving to say that this could improve traffic safety. It seems much more likely to be a good way to extend the time and space spans of congestion, make people take longer to get from point A to point B, and increase local revenue on the backs of out-of-towners.
Ticketing everybody is a fine theory -- except that it is dangerous, and in some cases illegal, to travel much slower than the prevailing rate of traffic. I'm not going to hang out in the right lane going 55 if everyone around me is driving 70 (which is a common case where I live). Also, the people in charge of implementing these robo-police seldom use the technology on themselves; the usual laws require some human to review the citation for accuracy, and somehow citations for publicly owned vehicles are almost always rejected. As lots of other people have mentioned, there are far too many places where the speed limits are set artificially low to help enhance revenue. These systems might result in wider enforcement of laws, but it is naive to think they will somehow lead to better or more uniform enforcement.
It may be a huge differentiator, but is it a useful one? If there are not many vehicles on the road, this feature isn't necessary. If there are many vehicles on the road, and they're all going the same speed, maybe TICKET ALL THE VEHICLES is not a defensible tactic. If there are many vehicles on the road, and only a few are going much faster than the others, I think what you really want is a patrol car -- or at least video -- to deal with what might be reckless driving.
It is not necessary, but it is plainly taught by basic principles in UI design. Sure, a designer could use a limited, secondary input method to unlock the screen (but why?). Sure, a designer could allow unlock without visual cues or visual feedback to the user (but why, except to implement something like Android's information-leaking PIN unlock method?). Sure, a designer could resize the feedback indicator rather than move it (but is that distinction patentable?).
Slashdot Mirror
Because using cellphones statistically seems to downgrade everyone a bit
[citation needed]
Seriously, do you have any good basis for your claim? In particular, which studies use the correct baseline of "distracted by everything except cell phone", rather than "not distracted", when comparing the impact of driving "distracted by a cell phone"? The US death rate due to traffic accidents dropped quite a lot over the last two decades -- and that is true whether you measure deaths per vehicle-mile, per capita, or per registered vehicle. (For example, fatalities per 100 million vehicle-miles traveled dropped from 1.73 in 1994 to 1.14 in 2009, even as phones-in-cars went from near zero to near ubiquitous.) Sure, we have a lot of other new safety systems in newer cars that help bring death rates down, but the marginal distraction due to mobile phone use is obviously hard to quantify.
Perhaps you should tell the Linux and Android developers how wrong they are to use a strict version of the model I described.
I'm halfway convinced you are engaging in some kind of elaborate troll or performance art. You are the one who is attaching automated testing (and tagging based on the results) to a revision control system; I am not. I have professionally developed software in a (useful) business setting, and I have managed a ten-person software development group. I saw the increase in code quality -- and more predictable release schedules -- when I migrated that group from Subversion to Git+Gerrit (which imposes mandatory code review and a tested-by sign-off before a change is applied to the line of development).
Revision control systems are for recording a series of configuration snapshots that you care about. The qualifier at the end is critical.
If what you care about is breaking the configuration for fellow developers, and that works for you, that's fine: keep committing untested changes. Just don't tell me that I am wrong for rejecting that model. When I am working with one or two other people, I do not care so much: They are not likely to break anything so badly that I cannot reverse it or work around it easily, but I still like to be able to bisect to find regressions. (Some of my less capable coworkers care more even at small scales.) When I am working with a lot of other people, I do care whether people test before merging their changes: Without some discipline, the chance that someone will break something important goes up with at least the square of the code churn rate.
Your second paragraph is pretty gutsy for a guy who claimed that someone *else* wasn't doing real (team) development.
The point is not that people only commit fully functional code -- just that they only commit reasonably functional code; that means code that others could reliably use as a basis for further development. During a development phase, that usually means missing features or known bugs. But see also how the Linux kernel, gcc, and other large free software code bases are maintained: They all have phases or steps where they only accept changes to the baseline if those changes are believed to be defect-free.
I provided additional reasoning for shared development servers in a separate reply.
Why have a development server if everything is tested locally? A development server is useful for integration purposes and for running tools or tests that are not in the "innermost loop" of development: churn statistics, perhaps static analysis, builds for less-used targets or feature combinations, and so forth.
Why bother testing locally? Committing a broken build to a shared development line is counterproductive for you and frustrating for other developers. (I am tempted to draw an analogy with defecating on another person's dinner plate.) Depending on the scope of the breakage, others might be unable to test their changes, may get false failures from their tests, or may ignore true test failures because the test was failing before their commit. Tests are also never perfect, and automated tests are especially prone to missing things. If you discover an regression that escaped the automated tests, and have a culture of not caring whether commits work, it makes it much harder to identify the source of the regression.
Have you ever used any revision system except Subversion?
Your entire workflow seems based around a high-powered central server with a reliable pipe to every developer. That isn't true for a lot of people, and will usually not scale well (even if you have a cloud deployment of your CI tools, running enough tests to adequately test a commit will increase the cycle time before it gets marked as good or bad).
If someone asked me to work on a shared repository that had more than about 5% non-working commits, I would find a different place to work. My time and sanity are worth more than the alleged benefits of a dumb client/smart server development system.
Even more than that, what the heck does the "85 percent" rate mean? I would think that MIT's press release could at least bother to indicate sensitivity and specificity as separate numbers. If they falsely predict that 15% of people (one out of roughly six) who stop are about to run the light, that poses major problems for any field use of the system.
On the off chance that you're not trolling in a phenomenally stupid manner: Take your cultural relativism and your totalitarian apologetics and shove them where the sun doesn't shine.
My "less harmful" was meant primarily in the sense that a posteriori censorship of known content is more specific (less likely to result in an unintended match) than a priori censorship based on keywords or similar patterns. But if you want to look at it from a moral perspective, then yes, Google's censorship of sites selling illegal wares is still less harmful than China's censorship of peaceful dissent.
There is definitely less -- and less harmful -- censorship in Google's results. Chinese search engines block results by words and phrases (what kind of results do you think you'd get for "Tiananmen Square"?). Google blocks results by URL (which is easier to change without changing the message).
If CouchDB doesn't work, there are at least six other competing solutions that will tell you how they are a better fit for your needs than all the others. Cassandra, Hadoop/HBase, MongoDB, and more. If one doesn't work for you, you can waste as much time as you like trying the others!
If no one is required to provide some service, how are you going to get on the Internet with unfiltered access? (Have you forgotten what "ISP" stands for?)
There are a bunch of defensible regulations, like network neutrality. There are a bunch of really bad ideas -- like "three strikes" laws when the mechanism is enforced by ISPs and copyright owners, with no judicial oversight or involvement. But there is a huge difference between saying that you have a right to speak your mind and saying that when you contract with an Internet service provider for network access, they have this or that restriction on how they route packets. The latter is not a right.
Also, on medical care: US law prohibits discrimination based on the protected classes you mention -- at least by providers of public accommodations that are used in interstate commerce (it is amazing how much of US Federal law would fall apart without Wickard v. Filburn). US law also requires providers who accept Medicare to (at least) stabilize all patients, even if the patients cannot afford to pay -- but this is as a condition of accepting the funding. It does not recognize a right to medical care.
So how many inalienable rights are there under your definition? Freedom of conscience?
Also, "laws preventing one from inciting rights": hah. I'm sure lots of politicians would love to pass those.
I did not claim that the Declaration of Independence was legally binding -- just that it listed rights that were recognized as inalienable. Many philosophers -- particularly those who influenced the Founding Fathers -- view(ed) inalienable rights as ones that are inherent to a person; they can be recognized by a government, but that does not establish or grant them as rights. At any rate, the Constitution does not use the term "inalienable right", and I did not want to get into a pedantic argument whether phrases like "shall not be infringed" or "shall not be violated" meant "inalienable right".
No. As counter-examples, the Declaration of Independence identified life, liberty and the pursuit of happiness as inalienable rights. The death penalty deprives people of life -- and was generally accepted for a long time (even now the usual arguments against are based on morality and accuracy rather than government powers). Imprisonment, or even pre-trial detention, deprives people of liberty.
Perhaps a better way to think of an inalienable right is something that you cannot give to someone else.
Whether the right is "Internet" or "unfiltered Internet access" (or food or shelter or healthcare) is irrelevant to the property-rights/contract question.
There is certainly an argument to be made that network neutrality is a reasonable regulation. I just don't think it makes sense to present it as a right.
So what happens if the government recognizes "unfiltered Internet access" as an inalienable right?
imamac's point was that recognizing it as a right doesn't get you anywhere. It is like saying food security or access to medical care is an inalienable right: Somebody has to pay to provide it, and it requires the transfer of goods or services from one person to another. That makes it different from the things that we traditionally recognize as inalienable rights.
Normal stock is shares you own. Vested options let you buy a share of stock at a particular price. Unvested options will let you buy a share at some point in the future, assuming certain conditions occur (for these employee incentive plans, usually the options vest after a certain period of time if you remain employed by the company).
There is a simple explanation for why the US is not a polite society: The particularly impolite people in the US are the same ones who want to confiscate all the weapons.
These stories get posted so that people have threads where they can say "Netcraft confirms: FreeBSD is dead" ... and have it be remotely on topic.
It is one thing to look at somebody else's work product and be impressed. It's an entirely different thing to look at your own and decide that, yea verily, that was a nearly optimal way to spend your time. (The major difference is that you usually have a much better idea of how much time and frustration you spent than what someone else spent.) Unless your objective is making computers run fast or maintaining the OS, time spent tweaking things at a low level -- which FreeBSD requires -- is probably not worth it.
The effort spent by programmers around the world who have written GObject overhead -- the annotations in C, the extra macros when using it, and so forth -- dwarfs what it would take to create a tool to extract similar information from C++ class definitions. There are free-software C++ parsers out there, and well-known techniques to extract annotations from comments.
But hey, GObject lets people save an entire register that might otherwise be dedicated to the "this" pointer.
My point was that you are just hand-waving to say that this could improve traffic safety. It seems much more likely to be a good way to extend the time and space spans of congestion, make people take longer to get from point A to point B, and increase local revenue on the backs of out-of-towners.
Ticketing everybody is a fine theory -- except that it is dangerous, and in some cases illegal, to travel much slower than the prevailing rate of traffic. I'm not going to hang out in the right lane going 55 if everyone around me is driving 70 (which is a common case where I live). Also, the people in charge of implementing these robo-police seldom use the technology on themselves; the usual laws require some human to review the citation for accuracy, and somehow citations for publicly owned vehicles are almost always rejected. As lots of other people have mentioned, there are far too many places where the speed limits are set artificially low to help enhance revenue. These systems might result in wider enforcement of laws, but it is naive to think they will somehow lead to better or more uniform enforcement.
It may be a huge differentiator, but is it a useful one? If there are not many vehicles on the road, this feature isn't necessary. If there are many vehicles on the road, and they're all going the same speed, maybe TICKET ALL THE VEHICLES is not a defensible tactic. If there are many vehicles on the road, and only a few are going much faster than the others, I think what you really want is a patrol car -- or at least video -- to deal with what might be reckless driving.
It is not necessary, but it is plainly taught by basic principles in UI design. Sure, a designer could use a limited, secondary input method to unlock the screen (but why?). Sure, a designer could allow unlock without visual cues or visual feedback to the user (but why, except to implement something like Android's information-leaking PIN unlock method?). Sure, a designer could resize the feedback indicator rather than move it (but is that distinction patentable?).