Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Monday, December 24, 2007

Copied pictures

The Huffington Post has an article about a column by Frank Rich. The article includes this composite image consisting of pictures of both Rich and Bill Clinton. At the bottom of the article the following credits appear.
Photo of Frank Rich from the NYT; photo of Bill Clinton via frankejames.com.
The credits include the link to the original source of the Clinton picture.

Yet the composite image was stored on The Huffington Post website. It was not (as are the images in my blog entries—like this one) references to the original image sources. My question is whether The Huffington Post asked for permission to copy the images. It seems unlikely because an exchange of emails requesting and granting permission would have taken too long. So The Huffington Post probably just copied the original images and created a derived combined (mashup) image without permission. What are the copyright implications of that?

There is a sense in which it is preferable to copy images than to refer readers to the original source. Copied images are retrieved from one's own web server. When the original source is used, one is forcing that web server to supply the images. So by copying the images, The Huffington Post did the original source a favor — of sorts. But they also violated copyright, didn't they?

Monday, December 17, 2007

Multi-processing

The New York Times has an article on multi-core processors. It's focus is primarily on the fact that Microsoft is taking the problem seriously and putting lots of money into it. The problem, if course, is that software developers don't know how to develop software for parallel computation. The article quotes David Patterson of Berkeley as saying
Industry has basically thrown a Hail Mary. The whole industry is betting on parallel computing. They’ve thrown it, but the big problem is catching it.
The "Hail Mary" reference is to the fact that the hardware industry has run into problems that makes it very difficult to make individual chips run faster. The alternative to faster chips is more chips. That also increases the raw computing power. The problem is that we don't know how to use it.

Parallelizing software is very difficult. We don't know how to do it. It's unlikely that we will solve that problem soon. So what's to do? Two things.
  • We can and should focus on more loosely coupled processes. Parallelization is the attempt to break a single process down into subprocesses that can perform the same overall computation but with some of them done in parallel. Loose coupling is an attempt to think about computation in terms of multiple computations that interact less often. It's coordinating the interactions that make parallelization so difficult. If there were fewer interactions or if the interactions were less tightly coupled, the result would be easier to produce. Of course that's easier said than done. But agent-based computing has been around for quite a while, and it has produced some useful results.

    On the discouraging side is the fact that process algebra has also been around for quite a time and has not produced much in the way of practical results. We just don't know how to coordinate even loosely coupled processes except through very generic mechanisms. The fact that most of what we experience in life consists of loosely coupled processes should be encouraging. But we have a long way to go before we understand how it works.

  • The second approach is to work on developing systems that work at many levels of processing simultaneously. Apparently our brains do that. At the same time as we are doing something we are aware of the fact that we are doing it, and we can regulate how we do it. Aspect-Oriented Programming (AOP) is a move in the right direction. It is an attempt to develop programming languages that allow the programmer to write software that both operates at the process level while at the same time operates at a meta-level that observes the operational level. AOP as currently structured attempts to map all of these processes onto a single process programming language. That, of course, is not only not necessary, it's the wrong way to proceed. In the future we will have many processors. We should be working on putting them all to work at different observational levels.