I always cringe when I see this statement in a discussion about programming languages. The presence or absence of a particular feature will impact the third-party libraries you use, the code samples and tutorials you come across, and the legacy apps you inherit. Even if you develop in a vacuum, some features can impact you by accident [operator overloading isn't a good example, but implict-conversion-of-numeric-types-to-boolean is].
In $FEATURE desirable or not for a particular programming language? Most always, that's going to be a complex usability/design question answerable by some combination of analysis, research, experience, testing, etc. Read the programming languages weblog or the discussion forums for D, Haskell, etc., to see the level of thought that goes into make these tradeoffs.
The term "open source" may have be deliberated crafted to appeal to the masses, but it is also undeliberately crafted in a flawed way, so that it could be interpred on two ways, and one of them is damaging to FOSS. By the way, if you want to know what the damaging interpretation is, you just have to ask Microsoft.
What is the flawed interpretation and how have you seen Microsoft use it? It seems to me that OSI was fairly successful in defining the term, marketing it, and preventing Microsoft from directly bastardizing it (e.g., as with the whole "shared source" initiative). We would be in much worse shape if they had chosen the ambiguous "free software" or the unmarketable "libre software".
It is not that difficult to detect the problems...
Maybe not for an experienced code reviewer who's examining 20 lines of code for an extremely simple security need. In the real world it takes extraordinary resources (talent, discipline, passion) at both the individual and organizational level to produce "logically" secure software. Even then, it usually takes academic/hacker security research to find subtle, indirect attacks that depend on power consumption, network behavior, and other such complexities [the SSH packet-timing vulnerability springs to mind here].
Every professional software developer can, at some point in their life, benefit from studying material similar to Meacham's vulnerability. Maybe you are so far beyond that level that you do not appreciate the Underhanded C Contest's educational potential. Pity that it's not better established, but maybe that will come in time.
In the end I suppose you need to build a compiler by hand to make sure no backdoors are present.
In the end, you'd have to build the computer and all it's components by hand, at least from the standpoint of Thompson's "Reflections on Trusting Trust".
The list of things they have eliminated or made less useful is almost endless.
What sort of things? And was Awesomebar really that infuriating? Are people paralyzed by seeing the dropdown options as they type? Seems sooooo much easier than using the history panel to me.
But for the MILLIONS of people whose job requires them to use antiquated legacy systems, it is often essential.... The sheer volume and costs of re-engineering these systems mean that they will be with us for years to come, no matter how ugly and inefficient when compared to modern systems.
But realistically, that's not a good reason to avoid re-purposing the caps lock key. If so many people need it, options will emerge for re-enabling caps lock behavior when/where needed. And that's exactly what Google is doing by providing an option to revert the search key to caps lock. Even if they didn't, somebody else would develop a system extension or USB dongle or whatnot to provide the option to the minority of users that need it.
Eliminating one choice may introduce new, more meaningful choices.
Eliminating a choice may be a beneficial design trade-off that makes the system/product better in some other respect.
Irrelevant and overabundant choices tend to be psychologically overwhelming. Eliminating or hiding such choices tends to have a liberating effect on the end user.
Perhaps the commentator is subconsciously equating choice with flexibility, freedom, or power. Sometimes that's the case and sometimes choices actually work to hinder such things. If you're designing for the good of your users, seek to understand their wants, needs, and capabilities and then optimize your product to serve and most easily enable the range of choices they are actually seeking make.
Apparently, Google is doing this as the caps lock key is now a search key that you can optionally revert to caps lock behavior if you need it.
Rich banker gets to escape felony hit and run charges, because the judge felt "a felony charge would hurt his ability to make shit tons of money".
It was the DA, not the judge, who decided to seek two misdemeanor charges instead of a felony charge.
Googling for "Martin Joel Erzinger" and consulting the non-emotional news items [such as this one], it seems the DA thought this course of action more likely to (1) guarantee conviction [thereby resulting in damage to his permanent record and maybe prison time] and (2) guarantee restitution.
Perhaps the DA is a scumbag with a special place in his heart for rich people, but I'm so sick of media (and blogger) spin that I'm going to say that maybe, just maybe, he knows more about the ins and outs of Colorado felony hit-and-run convictions than I do and was acting in good faith.
Yep... anybody can just saunter into NYSE, plug their laptop into the same colocation racks as G. Sachs, et. al, and immediately being making money the ULLDMA way.
Let's give a round applause for two groups of people thinking creatively in order to get better at doing what they do: the law enforcement folks for considering new approaches and the art folks for doing more to make their profession relevant to society.
I realize you are trying to justify WikiLeaks, but they aren't the ones shooting guns and launching bombs. Our starting supposition should be that humanity has an intrinsic right to enforce transparency upon power wielders, particularly governments and militaries, so that the may be held to account for the efficacy and morality of their actions. Here, WikiLeaks serves the public good, and--excepting gross violation of journalistic ethics--we must credit with them doing something basically right even though many powerful people would like us to see them as basically wrong. IMO, somebody's handling their journalistic obligations much better than, for instance, The New York Times did with warrantless wiretapping [they delayed publishing for a year], or Fox News did with the Downing Street Memo [they fanned the runaway bride story and diverted public interest].
Now if say he broke into you car and all he took was the bag of groceries out of the trunk you were on the way home with well, we might say they must have been hungry and it was kind of them to do the littlest damage possible, I guess, but there is nobody who "needs" a CD changer, that is just theft and vandalism and I really don't feel much need to excuse the guy the perp.
Thieves don't steal CD changers so they can listen to tunes: they steal so they can pawn/fence/resell the goods and get cash for drugs/HDTV/food/whatever. Who causes less harm to society: a thief that breaks into 10 cars for groceries or a thief that breaks into 1 car to get a CD changer with which to buy the same amount of groceries? IMO, the latter thief is morally superior because he caused less collateral damage in terms of damaged property and psychological stress on victims. Of course, if you're the victim in either of these cases, you KNOW that the first guy stole because of fundamental need whereas the second may or may not have bought groceries with the proceeds of his crime (in the real world: probably not).
Bottom line 1: a criminal who steals for fundamental need (food, medicine) is morally superior to one who steals for non-fundamental needs (recreational drugs, entertainment systems).
Bottom line 2: a criminal who takes some effort to minimize/mitigate the impact on his victims is morally superior to one who does not.
I'd love to fire up a rich IDE, pull in some standard widely-known libraries, create a program in a smart statically-typed language, build a Linux-native executable, package it up and publish it to the world via a distribution network ("app store"?) that's friendly to both open source and commercial interests.
"But but but..." someone will say, "we have all the pieces, and you have tons of choices, and choices are good!" And I don't disagree with that, but there's no ONE de facto solution for targeting Linux that lets all potential developers play the same game instead of acting in isolated pocket communities. By contrast, it's obvious what you need to use if you're developing for MacOS (XCode, Objective C), Android (Eclipse, Java), and Windows (Visual Studio, C#). Maybe winning the desktop is not important to you (and that's okay), but Linux needs some focus if it's to stand on its own as a brand for programming.
You may think that C++/AutoTool/Makefile/Dpkg is the answer (and that might be the closest thing we have), but those tools are difficult to learn, test, and use. We need developers who are experts in a wide variety of subject matters; making them be experts in an archaic build chain or obtuse packaging tools means that we lose them. Java and Python could be good bets, but there's still a bunch of fragmentation in regards to language/VM versions as well as the number of libraries (persistence frameworks, web frameworks, injection frameworks, etc.) that all do the same thing.
The problem I think is the people doing the research and not the research itself. People can lie about the results, which happen far to often.
Deliberate deceit is only one avenue of error mentioned in the article.
Flawed experiment design and statistical analysis are also major problems.
The significant question is not "who do we punish?" or "how do we avoid conflict of interest?", it's "how do we better scrutinize research and researchers?".
Answer that and you'll raise the overall quality of medical study as well as the care with which doctors lean on current researchers for informing their practice. Is there something that works better than the current grant/research/publish/cite process, or does science fall apart once too many extrinsic interests get involved?
From my sophomore algebra class:
1/3 =.333333...
2/3 =.666666...
1 =.999999...
We sort of had the can't-be-right disbelief the summary expresses until our teacher pointed out that the decimal representations were really limits.
Why not... show an image of someone famous, then ask who that person is.
Collecting the pictures for this would be pretty expensive. You've got to figure out licensing, tagging (including acceptable synonyms in several target languages), down-sampling, storage, accessibility, etc. The attacker only has to figure some (imperfect) tagging, and they can use well-researched ideas (facial recognition) to help with this. Moreover, the larger and more valuable target you are, the more images you must find. Would 10,000 images cut it for Yahoo! or Microsoft? Certainly not... they would need millions (even billions) of images with unique responses. By contrast, an 8-character alphanumeric captcha has 2.8 trillion possible responses without any per-response overhead.
Crappy Approach
on
Autotools
·
· Score: 2, Insightful
I understand that adoption/marketing/historical factors may have justified this particular approach to cross-platform builds of C/unix apps, but is this such a big problem that it requires 5-6 languages to solve (counting the syntax of C, sh, configure.ac, Makefile.am, makefile and possibly other intermediate formats)? Sheesh...
A social network that limits it's audience to a specific group of people isn't very 'social'.
While true in one sense, targeting a specific audience might be a good way to get things rolling on this project. Specialization lets you crystallize some critical tenants of how the system is perceived and used that then paves the way for wider adoption. Facebook itself was originally limited to.edu domains.
the mantra so often chanted here ("security through obscurity is no security at all"), is dead wrong
Slogans emphasize critical insights at the expense of supporting details, so it's not surprising that there are naive misinterpretations. And you're absolutely right... obscurity is a tool that can be used or misused. The slogan is still valid though, because it summarizes these critical observations that software makers have learned the hard way again and again:
Software vendors should fix holes in their systems instead of pretending that technical difficulties will be sufficient to stop attackers. They won't be.
Software architects need to make their systems secure-by-design instead of pretending that debuggers and packet sniffers and other such tools don't exist. They do. (As such, obscurity limits you to very narrow situations, such as generating some secret bytes and keeping them in a protected data store... a.k.a., private keys.)
Cryptography users should use algorithms that have been scrutinized by the entire crypto-academic community instead of pretending that whoever came up with the algorithm was smart enough to understand all the mathematical traps they might have fallen into. They weren't. (I'd say that a similar argument applies to the implementations as well.)
Lots of people saying "No empirical testing? Then it's crap!", without apparently realizing that vital questions they have to face in everyday life, such as ethics, are part of philosophy.
Everybody knows that we are all philosophers. The empiricist also knows that we aren't very good philosophers: that there are all sorts of weird hiccups in human reasoning that lead us to mistake thought for truth. Unless constantly checked against the real world, it's all too easy for an entire field of knowledge (*cough* cultural studies) to wander into the dark, taking with it the energies of countless institutions and entire generations of scholars. For knowledge to be meaningful, it must be tested. Mathematics, with its inhuman capacity for strict formalism, is the only field that gets a bye.
Philosophy has her triumphs, but she prefers to celebrate false heroes and dead ends. It's a shame because we do need philosophy and better ways of going about it.
[Oracle's] revenue stream is testimonial to the quality of their products.
Technical quality does not equate to market dominance. They may or may not have been ahead of the curve at one time, but now CIO's seem to buy Oracle just because there's a stigma if you don't. That's an effect of market saturation.
What I can say is that, as a developer, Oracle is extremely clunky. Clunky extensions to SQL. Clunky permissions handling. Clunky name resolution. Clunky client installation. Clunky developer/admin tools. Crap loads of painful clunkiness that constantly interrupt real development with unnecessary confusion and complexity.
They couldn't give a rats ass as to what developers feel about Java.
Apparently, they don't give a rat's ass as to what developers feel at all... and that makes Java's future look even bleaker.
Whatever has happened to personal responsibility? Why is this such a problem? If a nurse is doing their job, then they will follow the tubing back to the source to ensure that they are connecting the right ones. Why is this so hard?
Good design anticipates human performance errors and safeguards against them. You ALWAYS want to include appropriate labeling, lockouts, and other such features when designing safety-critical equipment. This is not a surrender of personal responsibility on behalf of the end-user: it's an embracing of professional and moral responsibility by the designers of such equipment and the administrators of our institutions.
If he used this modified calculator with prohibited software to take a test, he cheated.
Only the prohibited software gives a non-trivial performance advantage for taking the test, and he used it for such purposes. I suspect many who are capable of doing such a hack are just interested in preserving the programs they've written. (Then again, I guess USB cords are ubiquitious these days, unlike the older models where you had to buy a kit.)
get a list of exceptions that can be thrown by a call so you know what you could check for
.NET will generally document expected exceptions, but in general, you should not assume to know all the reasons that a method can fail. Even if you think you know all the reasons a method might fail today, tomorrow that call might be modified to hit a database or do something completely different and whole new failure categories open up.
If you don't know what to do with an exception (and you usually don't), clean up your resources and throw it up the call chain until you do know what to do with it (log it, tell the user, ignore it and try a fallback strategy, attempt to fix it, wait a few second and try it again, etc., etc.). Distinguishing the type of the exception only matters in special cases where it impacts your response strategy.
Slashdot Mirror
I always cringe when I see this statement in a discussion about programming languages. The presence or absence of a particular feature will impact the third-party libraries you use, the code samples and tutorials you come across, and the legacy apps you inherit. Even if you develop in a vacuum, some features can impact you by accident [operator overloading isn't a good example, but implict-conversion-of-numeric-types-to-boolean is].
In $FEATURE desirable or not for a particular programming language? Most always, that's going to be a complex usability/design question answerable by some combination of analysis, research, experience, testing, etc. Read the programming languages weblog or the discussion forums for D, Haskell, etc., to see the level of thought that goes into make these tradeoffs.
What is the flawed interpretation and how have you seen Microsoft use it? It seems to me that OSI was fairly successful in defining the term, marketing it, and preventing Microsoft from directly bastardizing it (e.g., as with the whole "shared source" initiative). We would be in much worse shape if they had chosen the ambiguous "free software" or the unmarketable "libre software".
Maybe not for an experienced code reviewer who's examining 20 lines of code for an extremely simple security need. In the real world it takes extraordinary resources (talent, discipline, passion) at both the individual and organizational level to produce "logically" secure software. Even then, it usually takes academic/hacker security research to find subtle, indirect attacks that depend on power consumption, network behavior, and other such complexities [the SSH packet-timing vulnerability springs to mind here].
Every professional software developer can, at some point in their life, benefit from studying material similar to Meacham's vulnerability. Maybe you are so far beyond that level that you do not appreciate the Underhanded C Contest's educational potential. Pity that it's not better established, but maybe that will come in time.
In the end, you'd have to build the computer and all it's components by hand, at least from the standpoint of Thompson's "Reflections on Trusting Trust".
What sort of things? And was Awesomebar really that infuriating? Are people paralyzed by seeing the dropdown options as they type? Seems sooooo much easier than using the history panel to me.
But realistically, that's not a good reason to avoid re-purposing the caps lock key. If so many people need it, options will emerge for re-enabling caps lock behavior when/where needed. And that's exactly what Google is doing by providing an option to revert the search key to caps lock. Even if they didn't, somebody else would develop a system extension or USB dongle or whatnot to provide the option to the minority of users that need it.
What a naieve view! Consider:
Perhaps the commentator is subconsciously equating choice with flexibility, freedom, or power. Sometimes that's the case and sometimes choices actually work to hinder such things. If you're designing for the good of your users, seek to understand their wants, needs, and capabilities and then optimize your product to serve and most easily enable the range of choices they are actually seeking make.
Apparently, Google is doing this as the caps lock key is now a search key that you can optionally revert to caps lock behavior if you need it.
It was the DA, not the judge, who decided to seek two misdemeanor charges instead of a felony charge.
Googling for "Martin Joel Erzinger" and consulting the non-emotional news items [such as this one], it seems the DA thought this course of action more likely to (1) guarantee conviction [thereby resulting in damage to his permanent record and maybe prison time] and (2) guarantee restitution.
Perhaps the DA is a scumbag with a special place in his heart for rich people, but I'm so sick of media (and blogger) spin that I'm going to say that maybe, just maybe, he knows more about the ins and outs of Colorado felony hit-and-run convictions than I do and was acting in good faith.
Yep... anybody can just saunter into NYSE, plug their laptop into the same colocation racks as G. Sachs, et. al, and immediately being making money the ULLDMA way.
Let's give a round applause for two groups of people thinking creatively in order to get better at doing what they do: the law enforcement folks for considering new approaches and the art folks for doing more to make their profession relevant to society.
I realize you are trying to justify WikiLeaks, but they aren't the ones shooting guns and launching bombs. Our starting supposition should be that humanity has an intrinsic right to enforce transparency upon power wielders, particularly governments and militaries, so that the may be held to account for the efficacy and morality of their actions. Here, WikiLeaks serves the public good, and--excepting gross violation of journalistic ethics--we must credit with them doing something basically right even though many powerful people would like us to see them as basically wrong. IMO, somebody's handling their journalistic obligations much better than, for instance, The New York Times did with warrantless wiretapping [they delayed publishing for a year], or Fox News did with the Downing Street Memo [they fanned the runaway bride story and diverted public interest].
Thieves don't steal CD changers so they can listen to tunes: they steal so they can pawn/fence/resell the goods and get cash for drugs/HDTV/food/whatever. Who causes less harm to society: a thief that breaks into 10 cars for groceries or a thief that breaks into 1 car to get a CD changer with which to buy the same amount of groceries? IMO, the latter thief is morally superior because he caused less collateral damage in terms of damaged property and psychological stress on victims. Of course, if you're the victim in either of these cases, you KNOW that the first guy stole because of fundamental need whereas the second may or may not have bought groceries with the proceeds of his crime (in the real world: probably not).
Bottom line 1: a criminal who steals for fundamental need (food, medicine) is morally superior to one who steals for non-fundamental needs (recreational drugs, entertainment systems).
Bottom line 2: a criminal who takes some effort to minimize/mitigate the impact on his victims is morally superior to one who does not.
I'd love to fire up a rich IDE, pull in some standard widely-known libraries, create a program in a smart statically-typed language, build a Linux-native executable, package it up and publish it to the world via a distribution network ("app store"?) that's friendly to both open source and commercial interests.
"But but but..." someone will say, "we have all the pieces, and you have tons of choices, and choices are good!" And I don't disagree with that, but there's no ONE de facto solution for targeting Linux that lets all potential developers play the same game instead of acting in isolated pocket communities. By contrast, it's obvious what you need to use if you're developing for MacOS (XCode, Objective C), Android (Eclipse, Java), and Windows (Visual Studio, C#). Maybe winning the desktop is not important to you (and that's okay), but Linux needs some focus if it's to stand on its own as a brand for programming.
You may think that C++/AutoTool/Makefile/Dpkg is the answer (and that might be the closest thing we have), but those tools are difficult to learn, test, and use. We need developers who are experts in a wide variety of subject matters; making them be experts in an archaic build chain or obtuse packaging tools means that we lose them. Java and Python could be good bets, but there's still a bunch of fragmentation in regards to language/VM versions as well as the number of libraries (persistence frameworks, web frameworks, injection frameworks, etc.) that all do the same thing.
Deliberate deceit is only one avenue of error mentioned in the article. Flawed experiment design and statistical analysis are also major problems. The significant question is not "who do we punish?" or "how do we avoid conflict of interest?", it's "how do we better scrutinize research and researchers?".
Answer that and you'll raise the overall quality of medical study as well as the care with which doctors lean on current researchers for informing their practice. Is there something that works better than the current grant/research/publish/cite process, or does science fall apart once too many extrinsic interests get involved?
From my sophomore algebra class: .333333... .666666... .999999...
1/3 =
2/3 =
1 =
We sort of had the can't-be-right disbelief the summary expresses until our teacher pointed out that the decimal representations were really limits.
Collecting the pictures for this would be pretty expensive. You've got to figure out licensing, tagging (including acceptable synonyms in several target languages), down-sampling, storage, accessibility, etc. The attacker only has to figure some (imperfect) tagging, and they can use well-researched ideas (facial recognition) to help with this. Moreover, the larger and more valuable target you are, the more images you must find. Would 10,000 images cut it for Yahoo! or Microsoft? Certainly not... they would need millions (even billions) of images with unique responses. By contrast, an 8-character alphanumeric captcha has 2.8 trillion possible responses without any per-response overhead.
I understand that adoption/marketing/historical factors may have justified this particular approach to cross-platform builds of C/unix apps, but is this such a big problem that it requires 5-6 languages to solve (counting the syntax of C, sh, configure.ac, Makefile.am, makefile and possibly other intermediate formats)? Sheesh...
While true in one sense, targeting a specific audience might be a good way to get things rolling on this project. Specialization lets you crystallize some critical tenants of how the system is perceived and used that then paves the way for wider adoption. Facebook itself was originally limited to .edu domains.
Slogans emphasize critical insights at the expense of supporting details, so it's not surprising that there are naive misinterpretations. And you're absolutely right... obscurity is a tool that can be used or misused. The slogan is still valid though, because it summarizes these critical observations that software makers have learned the hard way again and again:
Everybody knows that we are all philosophers. The empiricist also knows that we aren't very good philosophers: that there are all sorts of weird hiccups in human reasoning that lead us to mistake thought for truth. Unless constantly checked against the real world, it's all too easy for an entire field of knowledge (*cough* cultural studies) to wander into the dark, taking with it the energies of countless institutions and entire generations of scholars. For knowledge to be meaningful, it must be tested. Mathematics, with its inhuman capacity for strict formalism, is the only field that gets a bye.
Philosophy has her triumphs, but she prefers to celebrate false heroes and dead ends. It's a shame because we do need philosophy and better ways of going about it.
Technical quality does not equate to market dominance. They may or may not have been ahead of the curve at one time, but now CIO's seem to buy Oracle just because there's a stigma if you don't. That's an effect of market saturation.
What I can say is that, as a developer, Oracle is extremely clunky. Clunky extensions to SQL. Clunky permissions handling. Clunky name resolution. Clunky client installation. Clunky developer/admin tools. Crap loads of painful clunkiness that constantly interrupt real development with unnecessary confusion and complexity.
Apparently, they don't give a rat's ass as to what developers feel at all... and that makes Java's future look even bleaker.
Good design anticipates human performance errors and safeguards against them. You ALWAYS want to include appropriate labeling, lockouts, and other such features when designing safety-critical equipment. This is not a surrender of personal responsibility on behalf of the end-user: it's an embracing of professional and moral responsibility by the designers of such equipment and the administrators of our institutions.
Only the prohibited software gives a non-trivial performance advantage for taking the test, and he used it for such purposes. I suspect many who are capable of doing such a hack are just interested in preserving the programs they've written. (Then again, I guess USB cords are ubiquitious these days, unlike the older models where you had to buy a kit.)
If you don't know what to do with an exception (and you usually don't), clean up your resources and throw it up the call chain until you do know what to do with it (log it, tell the user, ignore it and try a fallback strategy, attempt to fix it, wait a few second and try it again, etc., etc.). Distinguishing the type of the exception only matters in special cases where it impacts your response strategy.
Or bribery.