Via Jim Clarke, a link to the ACM Student Research Competition. The deadline for submissions to Supercomputing’07 is the end of July, and others are posted regularly. No sign of an RSS feed, though 
.
I have figured out why third-bit.com crawls from time to time: this blog is being inundated by a wave of comment spam. I’m using the Akismet plugin to filter it (I delete several hundred to several thousand spam comments a day, unread), but filing them away to be rejected is enough of a load on my server to constitute a denial of service attack in its own right . I’m now thinking about relocating this domain and StreetKnit to dreamhost.com or some other hosting service — I hope that’ll provide more uniform service levels.
Girl Scouts of the USA
420 5th Avenue
New York, NY 10018
V 212-852-5049 F 212-852-6515
rfarmer@girlscouts.org
www.girlscouts.org
What influenced you to pursue a career in information technology? What could we learn from you and other women working in IT that will increase the number of girls and women who are interested in the field?
The K-12 Informal Education Hub of the National Center for Women & Information Technology (NCWIT), led by the Girl Scouts of the USA (GSUSA), is conducting a three-phase study to determine what experiences or factors influence females to pursue work in information technology (IT). Study results will help guide efforts to increase the number of women entering the IT field.
This 20 minute survey is intended for women who work in IT. For the purposes of this study, IT is defined as all forms of technology used to create, store, exchange and use information in all its forms; the design and use of computers and communications to improve the way we live, learn, work and play. If this describes your work, please consider participating in the study by completing this survey. Your responses are anonymous and the results will only be reported in aggregate form.
Please follow the link to the online survey:
www.erasurvey.org/input/womeninit.htm
We would appreciate your help in disseminating the survey to as many technical women as possible. Please forward this email to other women you know working in IT.
Survey results will be available online at www.ncwit.org in November 2007. If you have technical problems, or have questions about the study, please email cliston@psctlt.org. Thank you for your participation.
Here’s the official announcement [update: yes, it's open to the general public, and free].
Update: here’s a map of UTM — the Kaneff Centre is right in the middle.
World-renowned activist and free software developer Dr. Richard Stallman, founder of the free software movement, will speak on “Copyright vs. Community in the Age of Computer Networks” in Matthews Auditorium, Room 137, Kaneff Center, University of Toronto, Mississauga, 3359 Mississauga Rd. N., on Thursday, July 5th at 5 pm.
The talk, which is being co-sponsored by the department of Mathematical and Computational Sciences and U of T’s Knowledge Media Design Institute, will be non-technical, and members of the general public, along with computer scientists and engineers, are encouraged to attend.
Copyright developed in the age of the printing press, and was designed to fit with the system of centralized copying imposed by the printing press. But the copyright system does not fit well with computer networks, and only draconian punishments can enforce it.
The global corporations that profit from copyright are lobbying for draconian punishments, and to increase their copyright powers, while suppressing public access to technology. But if we seriously hope to serve the only legitimate purpose of copyright—to promote progress, for the benefit of the public—then we must make changes in the other direction.
While still a graduate student at the Massachusetts Institute of Technology during the fabled ‘golden age of hacking’ in the 1980s, Dr. Stallman foresaw the growing centrality of software to society and culture, and in particular the importance of preserving software users’ rights and freedoms. In 1984, he drafted his now-famous GNU Manifesto, in which he laid out the ideals of ‘free software’ software that the user can freely use, copy, distribute and change – and founded the Free Software Foundation to promote these ideals. His work led to the development of the GNU/Linux system, now in use on tens of millions of computers worldwide. Currently, as our arts and other forms of expression become increasingly digitized, Dr. Stallman is at the forefront of the movement to ensure that our culture itself remains free.
Dr. Stallman is author of the book Free Software/Free Society (GNU Press, 2002), and numerous papers. He has received many honors and awards, including a MacArthur Foundation fellowship (a.k.a. ‘genius award’), the Grace Hopper Award of the Association of Computing Machinery, the Pioneer award of the Electronic Frontier Foundation, and the Takeda Award for Social/Economic Betterment. He also has several honorary doctorates.
Today I:
I’m now heading out to the pub with students and colleagues. Life isn’t bad.
Later: about forty people showed up at the pub. Madeleine was, of course, the hit of the party 
Thanks to Serguei for the photo below.
[Posted on behalf of Tony Balkissoon.]
Making sound arguments is not like playing sports. In sports, everyone remembers the hero, the amazing play, the unbelievable shot. It doesn’t matter how many times you miss, it’s the one you make that counts. That’s why everyone remembers Michael Jordan as a “clutch” player even though in a 1997 commercial he admits to missing more potential game-winning shots than he makes. The same phenomenon explains how this one amazing play made the name Masahiro Araki known to baseball fans around the world.
Sports fans have selective memories and are very forgiving — one spectacular, mind-blowing feat erases the memory of dozens of errors and bad decisions.
When it comes to making arguments though, it’s the other way around. One weak, poorly formulated argument cuts at your credibility and casts a cloud of suspicion over dozens of strong, reasonable ones. It might not be fair, but that’s the way it is.
Michael J. Quinn’s “Ethics for the Information Age” is a popular book on ethical issues relating to computer technology. It’s widely used and well-respected, but my own experience with the book was ruined by what I think is an exceptionally weak argument.
The topic is software patents, and the conclusion is consistent with the feeling of many programmers — that software patents are bad. The book claims to be appropriate for a “computers and society” course and I’d guess that programmers make up a majority of the book’s readers. Many of them will agree with the conclusion and may therefore read the argument less critically than they should. I’m here to point out some of the problems with the argument. By criticizing Quinn’s argument I’m not arguing in favour of the opposite conclusion. This distinction — one that Quinn unfortunately doesn’t make — is important enough to warrant an example:
John: “Some people must like cookies. I hate cookies and no two people are exactly alike, so some people must like cookies.”
Mary: “That doesn’t make sense. Even if everyone hates cookies, that doesn’t mean that any two people are exactly alike. People can differ in other ways.”
John’s argument is foolish. Although Mary points that out, she is not claiming that everyone hates cookies (that would also be foolish).
Back to Quinn’s argument. Section 4.9, “Morality of Intellectual Property Protection for Software” starts “…we are considering whether as a society we ought to give the producers of software the right to prevent others from copying the software they produce. In other words, should we give copyright and/or patent protection to software?” The way in which Quinn asks this question (and the location — the last sentence of the introductory paragraph) leads the reader to believe that the section will provide an answer. Instead, this is what Quinn does:
There are two problems here. The first is that showing that two specific arguments are weak is not the same as showing every argument in favour if IP protection is weak. The second problem is subtler. The structure of the section makes readers expect an answer to the question “should we give copyright and/or patent protection to software?” So when Quinn concludes, “the arguments for granting intellectual property protection for software are not strong,” readers must assume that the answer to the question is “no.” This is as if Quinn concluded “the arguments againstgranting intellectual property protection are strong.” Combined, these problems are equivalent to Mary concluding that since John’s argument is weak, everyone must hate cookies.
And the situation gets worse — Quinn’s critique of the second argument in favour of IP protection leaves much to be desired. He calls the argument “a consequentialist argument why copying software is bad.” Here it is:
Quinn likens the argument to a chain, with each of the five points above being one of the links. He then attempts to attack the validity of link in turn. Unfortunately, his criticisms all fit the “maybe-it’s-not-like-this” template. Although he may convince some, the careful reader will note that his arguments are flawed. For example, here’s how he attacks the first link:
The first claim is that copying software results in reduced sales of software. When talking about software piracy, the computer industry cites the dollar value of the copied software as if each instance of copying represents a lost sale. Obviously this is an exaggeration. Not everyone who gets a free copy of a computer game has the money or the desire to purchase the game for $50. In fact, sometimes software copying may lead to a sale. A person may not have been interested in buying a particular program. After trying it out for free, the person may decide it is so useful she is willing to buy a copy of the program in order to get access to all of the documentation, the technical support line, or another service provided to registered users of the program. It is fair to say that copying software sometimes results in reduced sales of software, but it is not always the case. Hence it is incorrect to make a universal statement.
Look closely. The software industry is claiming that copying software results in reduced sales. If you were going to disprove this point, or at least call its validity it into question, what would you do? You might try to quote sales figures from before and after copying was a problem, or take a survey of a representative sample of people to see if they would buy a piece of software even if it was available for free. But that’s not what he has done. Instead, he has come up with two scenarios that might be the case for an individual customer and used those to suggest that copying doesn’t reduce overall sales. Consider the following scenario:
Every one of Quinn’s points still holds. Not everyone that got a free copy was willing to buy it. And some new sales were generated. However, 4,999,990 sales were lost. Of course, this situation is entirely made up, but that’s exactly my point: Quinn’s description of possible individual motivations says absolutely nothing about the reality of software sales. It therefore does nothing to combat the claim that copying software reduces sales.
Let’s take a look at how he attacks the second link, the claim that reduced software sales result in a decline in the software industry:
The second claim is that reduced sales of software will result in a decline in the software industry. An argument against this claim is that Microsoft is flourishing, despite the fact that software counterfeiting is prevalent in some countries. A stronger argument against the claim is that it makes a strong cause-and-effect connection between the creation of software and financial renumeration. [I'm assuming this should be "remuneration"] However, the open-source movement demonstrates many people are willing to create software without being rewarded financially. Some people write programs because they find it fun. Others are motivated by the desire to gain a good reputation by writing a program many people find useful. Advocates of open-source software, including Richard Stallman, suggest that the best way to stimulate innovation is to allow a free exchange of ideas and source code. From this point of view, allowing software producers to control the distribution of their code stifles, rather than promotes, innovation in the software industry.
The spelling mistake is not Quinn’s fault. Typos happen—there are editors and proofreaders for that kind of thing. I probably have spelling and grammar mistakes in this article too, so I definitely don’t want to claim that a spelling mistake discredits an entire argument. The logical strength of the argument, though, is Quinn’s responsibility and he has come up short again. He makes the same mistake as he did for the first point, and additionally confuses a change in a quantity with the quantity itself. When he says that Microsoft is flourishing despite the fact that copying exists, this does not combat the idea that if copying increased, Microsoft would be hurt. That’s like saying we shouldn’t worry if there’s a mad cow outbreak because mad cow disease exists already and we’re still alive.
His attacks against the remaining links are equally unconvincing. However, Quinn’s introduction to ethical theories and his discussion of why intellectual property doesn’t fit nicely into Lockean views on natural property rights were useful and well explained. Additionally, the widespread use of the book is some evidence for its quality. I’m not trying to say that the book as a whole is poorly written, I was merely disappointed with section 4.9. And, as I explained earlier, one poor argument can (fairly or unfairly) cast doubt on a dozen strong ones. Although individual arguments should be evaluated on their own merits, after having read section 4.9 I’m more likely to closely examine any arguments made before accepting a claim from the author.
Secondly, my critique of Quinn’s argument is in no way a vote of support for software patents. Patent protection for software is a complex issue and I certainly understand the perspectives of people like Richard Stallman who are completely against them. Even if you agree with a conclusion, critiquing an argument is useful. After all, allowing weak arguments to represent your side cannot be good for your cause. Having strong arguments is much more important than having many; eliminating weak ones is as important as formulating strong ones. Remember, making arguments is not the same as playing sports. Fortunately, that can be a good thing. We can’t all hit 350-yard drives or land quadruple-toe-loops, but with careful thought and attention to detail we can all make sound arguments to advance our causes.
Depressing post on Slashdot for a change — US export restrictions may apply to the One Laptop Per Child program.
Another excellent post from Diomidis Spinellis, this one reporting a study of where CPU cycles are spent building software. On BSD, the four leaders are (in order):
Life at Google – The Microsoftie Perspective has been doing the rounds, so I might as well link to it as well. One can speculate for hours about whether it’s genuine, or a very clever piece of agitprop. (See also this piece from a while back…)
After spending ten years helping scientists write programs for massively-parallel computers, I realized that what scientists really needed was to learn how to program, full stop. It took me another eight years to (a) get up to speed with the theory and practice of modern software engineering, (b) realize how big the gap between the two was, and (c) accept that the only people who are entitled to have an opinion about how we ought to be building software are the ones who are studying how well their favorite tools and practices actually work in the field. I no longer care what you’re pushing—formal methods and cleanroom development or agile adhocracy and pair programming—unless you’ve gone the extra mile and collected data to show what effect it’s actually having.
That’s why I was so pleased to come across these two papers:
“ASCI” is the Accelerated Strategic Computing Initiative. Launched in the mid-1990s, its mission was to produce a new generation of software for the US nuclear weapons program. These are big pieces of code: millions of lines, with lifespans measured in decades, doing some of the most complicated math ever devised by human beings. Hundreds of millions of dollars have been spent, and thousands of programmer-years, so it’s worth asking, “How’s it going? And what could be done better?”
According to the authors of these papers, who have spent a lot of time studying the major projects within ASCI, the answers are “So-so” and “Lots” respectively. Some parts of ASCI are considered outright failures: the Blanca project, for example, was so much in love with funky technology like template metaprogramming that it never delivered the science it was supposed to. Other parts, though, have come through, though many have taken longer to do so than originally envisioned. As the authors point out, though, management was “aggressive” in setting ASCI’s specs, schedule, and resourcing levels, so it’s not surprising that mere mortals couldn’t live up to them.
A lot of what these papers say is standard project management dogma. For me, the most important point was, “Emphasize ‘best practices’ instead of ‘processes’.” Every successful development team I’ve ever seen worried more about “doing the right thing” than about following the steps in a flowchart. Knowing what the “right thing” is, now, that’s the tricky part, but it’s what I’d like most to impart to my students. If you come back in ten years and ask me how I’m doing, I ought to have some data for you.
Recent Comments