Slashdot Mirror

theodp writes "Raw intellect ain't always all it's cracked up to be, advises Ted Dziuba in his introduction to Programming Things I Wish I Knew Earlier, so don't be too stubborn to learn the things that can save you from the headaches of over-engineering. Here's some sample how-to-avoid-over-complicating-things advice: 'If Linux can do it, you shouldn't. Don't use Hadoop MapReduce until you have a solid reason why xargs won't solve your problem. Don't implement your own lockservice when Linux's advisory file locking works just fine. Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job. Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look.' Any cautionary tips you'd like to share from your own experience?"

Yesterday's story about a creative approach to dealing with uninvited (and unwanted) users on a private wireless network -- by intercepting and modifying the images received downstream -- provoked some thoughtful comments on open wireless networks, and a storm of analogies about networks and property generally. Read on for some of the most interesting comments in the Backslash summary of the conversation.

Several readers offered comments on the methods of network interference suggested in the examples linked from the story, or offered other creative ways to impede network freeloaders. First, reader blantonl offers some insight into implementing the same image-flipping technique:

For those that are struggling to understand how the author of this article is accomplishing his approach, here is some further information.

The author obviously has a Linux server in his house, that is running DHCPD

To selectively send some clients to some locations, and others to the normal internet, he assigns an IP address on a different network to clients that don't have MAC Addresses that he knows about.

Forwarding on to sites of his choice is done by using IPTables, which is a utility that allows you to configure the packet filtering components of the Linux TCP/IP Stack. In this instance, the Linux box is just functioning as a firewall, and he is selectively sending requests from certain IP addresses to different hosts of his choosing.

Finally, the Up-side-down and blurry-image conversions is accomplished by sending page requests from those before-mentioned IP addresses to a proxy server, which in this case is Squid — and then allowing the proxy server to run a script which calls an ImageMagick command called mogrify which allows you to resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much more.

(Writing "I'm paranoid - I work in information security," reader hab136 points out some potential vulnerabilities in the system as described.)

As to the actual methods of annoyance, jpellino writes

Upside down is cute, but blurry is just too fantastic. You know they were on the horn to the vendor after punching every monitor control and several loud screaming matches and an expensive service call for a monitor that then worked just fine on the bench... As a webmaster I can now say April 1 just got very far away...

Reader Sloppy also admires the "blurry-net" approach ("That's subtle and I love it"), but suggests that image manipulation is only for starters

The next step is to spy on them and see what websites they visit, and then insert some fake content one day. For example, if they use it to read CNN, insert a casual story about a nuclear weapon getting used in the Middle-East or South Asia, or a story about the president of USA selecting a new vice-president due to the assassination last week ("What?! I didn't hear about that!"), or the CDC in Atlanta is investigating the recent rash of improbable claims about the dead returning to life to feast on the flesh of the living, etc. If they visit Slashdot, then the jig is probably up, but maybe it would be great to have a story where a security study found Windows98 to kick OpenBSD's ass and then a bunch of comments where everyone agrees that the findings pretty much match their own experience, along with complains about "how is this news for nerds?!"

And perhaps the ultimate in annoyance-as-warning, reader Midnight Thunder writes

I suppose you could also add a frame to every page and then sell advertising space. Since you probably know a bit about your neighbour it is much easier make targeted advertising. Of course you could always make the top frame read:

"This is borrowed bandwidth. Have you thought about getting your own connection."

Oh and make sure it is flashing. Actually you could make it so that the whole content flash.

Not all uninvited users are actually unwanted users, though, at least for some readers. Reader Elektroschock writes

Sorry, I am a supporter of open networks. I think the freifunk olsr-protocol approach of open wireless networks is best. We don't need internet providers and we don't need internet providers which leak our communication data to the governments and endanger the freedom of the net. The net should be a net and wireless technology is great for the creation of a real P2P internet.

I cannot support any action against people who use your network. It is against my understanding of hacker ethics. When you don't like it then close your network. But no childish games please.

I may even say that I find it unethical to exclude your neighbours from using your network but I respect your opinions. When your network is open it means: Be free to use it. Not: You can use it but I will fuck up or intercept your communication.

Similarly, trewornan writes

I chose to leave my wireless network open so that if someone nearby needed a connection it would be available for them. If someone was to impose an unreasonable load on the network I might do something about it but so far (12 months) I've had about half a dozen people connect and download relatively small amounts of data - my guess is they were checking email. Why would I object to that? No . . . why would *you* object to that? The way I see it it's a chance to do something nice for other people, why not get yourself some good karma.

Even without that sort of altruism, many readers feel that, as geekoid puts it,

[By]leaving it open he is inviting other people to connect.

Some computer says to the router "Hey, can I come in?" and the router says "Sure." Now, the moment you put something up, like needing a password, then you are no longer inviting people in.

• Computer says "Hey, can I come in" router says "Sure, if you know the password."
• Or you can encrypt it; Computer says "Hey, can I come in?" the router says "KE*jd7638JDEJE*834899(&^&#nd&#&bd*e#"

Not so fast, goes an argument exemplified in another comment from R2.0:

Yes, the computer is "asking" the router "permission," and the router is "granting permission" — the only problem is, the words we use to describe these actions may appear to be descriptive of thinking and volition, but they really mean neither. Computers and routers simply CANNOT give "permission" in any legal or moral sense.

To use the yard analogy that seems to be popular for these threads, lets supposed your neighbor's massively retarded child asks your massively retarded child for permission for his Daddy to use your yard, and your child agrees. Neighbor then comes over and stages a cookout on your lawn, or for that matter just walks across it.

When you confront him, he says "But my kid asked your kid, and he said yes." This is binding? Common sense and the law would say no, yet you would allow devices with an order of magnitude less analytical power than a retarded child to give and receive similar permissions.

Repeat after me folks: devices cannot give and receive permission for human actions without those permissions expressly being granted via some other means.

A traffic light doesn't give you permission to cross the street; the government (that you studied to get your license) gives you permission to cross the intersection when a light is green, and denies it when red.

Your ID badge doesn't ask permission to enter your building, and the security system doesn't grant permission; YOU ask for permission by presenting the badge, and your employer grants it by programming said system to accept your request.

Closer to the typical small-time network admin, perhaps, bennomatic writes

If I leave my bike outside unlocked for 10 minutes, am I giving explicit permission to anyone who sees it that they can take it? No. Am I allowing it to happen through negligence? Sure, but call it what it is; it's still stealing, or at least trespassing.

Even something as amorphous as bandwidth is a limited resource. To paraphrase the head of the commerce committee, an open wireless connection is not a dump truck you can just load up with as much as you like; it's a tube!

Various forms of the same disagreement surfaced in various corners of the discussion: squiggleslash, for instance, writes

[I]t makes sense that no implied permission is given by simply having your router be unsecured, given "unsecured" is the default configuration of most off-the-shelf routers.)

It really isn't an issue in practice. If you want to use someone else's network, all you have to do is ask them. With 802.11, you're close enough to be able to do so. There's no reason not to ask, other than knowing that "No" is likely to be the answer. And I think that's why people tell themselves the myth that somehow they have implied permission simply because the "door" was left unlocked.

The figurative "visibility" of an open wireless network also isn't enough to convince reader R2.0 that it's fair game for passers by. He writes:

So the router is "visible," with an option to make it invisible. Big deal. My garden is visible from the street, but I can put a tarp around it to obscure its existence. What you are saying is that, unless I put a tarp up around my garden, everyone has a right to use it.

Wireless networks may make themselves conspicuous, but that does not confer an invitation to use them. The connection between "visible" and "inviting" is not legally or morally valid. (I am excepting the concept of "attractive nuisance," but I don't think open routers will come under that area of liability)

Reader 4e617474 fired the next volley in this battle of analogies:

No, actually we're saying that if your garden pelts us with carrots and peas as we walk past on the public street, we're at liberty to catch them and consume them. Only if you place anti-vegetable-flight netting around your garden (or stop planting vegetables that lend themselves to comparison to an unsecured WAP) does it become incumbent upon us to behave as good citizens.

Hey! Analogies are fun! Somebody compare Internet privacy law to hunting and fishing licenses!

Readers like ShawnDoc make a case persuasive for discouraging bandwidth borrowing on the basis of enlightened self-interest.

If someone uses your connection for illegal activity (downloading Meet the Fockers, kiddie porn) it will be your IP address that the RIAA/MPAA/FBI will trace. Good luck convincing them it wasn't you. You might be able to do it, but it will take up time and money (lawyers) to clear your name. And in the case of kiddie porn or other criminal act, expect every computer, PDA, and cell phone in your home to be confiscated to be analyzed for incriminating data. The second problem is you are allowing strangers access to not only your Internet connection, but also your LAN. I have multiple computers and put files in shared folders so I can access them from different machines. I don't want some strange to have access to those files, or worse, have their computer be infected with a worm/virus that propagates across the network.

Thanks to all the readers whose comments informed this conversation, and in particular to those whose comments are quoted above.

Yesterday's story about a creative approach to dealing with uninvited (and unwanted) users on a private wireless network -- by intercepting and modifying the images received downstream -- provoked some thoughtful comments on open wireless networks, and a storm of analogies about networks and property generally. Read on for some of the most interesting comments in the Backslash summary of the conversation.

Several readers offered comments on the methods of network interference suggested in the examples linked from the story, or offered other creative ways to impede network freeloaders. First, reader blantonl offers some insight into implementing the same image-flipping technique:

For those that are struggling to understand how the author of this article is accomplishing his approach, here is some further information.

The author obviously has a Linux server in his house, that is running DHCPD

To selectively send some clients to some locations, and others to the normal internet, he assigns an IP address on a different network to clients that don't have MAC Addresses that he knows about.

Forwarding on to sites of his choice is done by using IPTables, which is a utility that allows you to configure the packet filtering components of the Linux TCP/IP Stack. In this instance, the Linux box is just functioning as a firewall, and he is selectively sending requests from certain IP addresses to different hosts of his choosing.

Finally, the Up-side-down and blurry-image conversions is accomplished by sending page requests from those before-mentioned IP addresses to a proxy server, which in this case is Squid — and then allowing the proxy server to run a script which calls an ImageMagick command called mogrify which allows you to resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much more.

(Writing "I'm paranoid - I work in information security," reader hab136 points out some potential vulnerabilities in the system as described.)

As to the actual methods of annoyance, jpellino writes

Upside down is cute, but blurry is just too fantastic. You know they were on the horn to the vendor after punching every monitor control and several loud screaming matches and an expensive service call for a monitor that then worked just fine on the bench... As a webmaster I can now say April 1 just got very far away...

Reader Sloppy also admires the "blurry-net" approach ("That's subtle and I love it"), but suggests that image manipulation is only for starters

The next step is to spy on them and see what websites they visit, and then insert some fake content one day. For example, if they use it to read CNN, insert a casual story about a nuclear weapon getting used in the Middle-East or South Asia, or a story about the president of USA selecting a new vice-president due to the assassination last week ("What?! I didn't hear about that!"), or the CDC in Atlanta is investigating the recent rash of improbable claims about the dead returning to life to feast on the flesh of the living, etc. If they visit Slashdot, then the jig is probably up, but maybe it would be great to have a story where a security study found Windows98 to kick OpenBSD's ass and then a bunch of comments where everyone agrees that the findings pretty much match their own experience, along with complains about "how is this news for nerds?!"

And perhaps the ultimate in annoyance-as-warning, reader Midnight Thunder writes

I suppose you could also add a frame to every page and then sell advertising space. Since you probably know a bit about your neighbour it is much easier make targeted advertising. Of course you could always make the top frame read:

"This is borrowed bandwidth. Have you thought about getting your own connection."

Oh and make sure it is flashing. Actually you could make it so that the whole content flash.

Not all uninvited users are actually unwanted users, though, at least for some readers. Reader Elektroschock writes

Sorry, I am a supporter of open networks. I think the freifunk olsr-protocol approach of open wireless networks is best. We don't need internet providers and we don't need internet providers which leak our communication data to the governments and endanger the freedom of the net. The net should be a net and wireless technology is great for the creation of a real P2P internet.

I cannot support any action against people who use your network. It is against my understanding of hacker ethics. When you don't like it then close your network. But no childish games please.

I may even say that I find it unethical to exclude your neighbours from using your network but I respect your opinions. When your network is open it means: Be free to use it. Not: You can use it but I will fuck up or intercept your communication.

Similarly, trewornan writes

I chose to leave my wireless network open so that if someone nearby needed a connection it would be available for them. If someone was to impose an unreasonable load on the network I might do something about it but so far (12 months) I've had about half a dozen people connect and download relatively small amounts of data - my guess is they were checking email. Why would I object to that? No . . . why would *you* object to that? The way I see it it's a chance to do something nice for other people, why not get yourself some good karma.

Even without that sort of altruism, many readers feel that, as geekoid puts it,

[By]leaving it open he is inviting other people to connect.

Some computer says to the router "Hey, can I come in?" and the router says "Sure." Now, the moment you put something up, like needing a password, then you are no longer inviting people in.

• Computer says "Hey, can I come in" router says "Sure, if you know the password."
• Or you can encrypt it; Computer says "Hey, can I come in?" the router says "KE*jd7638JDEJE*834899(&^&#nd&#&bd*e#"

Not so fast, goes an argument exemplified in another comment from R2.0:

Yes, the computer is "asking" the router "permission," and the router is "granting permission" — the only problem is, the words we use to describe these actions may appear to be descriptive of thinking and volition, but they really mean neither. Computers and routers simply CANNOT give "permission" in any legal or moral sense.

To use the yard analogy that seems to be popular for these threads, lets supposed your neighbor's massively retarded child asks your massively retarded child for permission for his Daddy to use your yard, and your child agrees. Neighbor then comes over and stages a cookout on your lawn, or for that matter just walks across it.

When you confront him, he says "But my kid asked your kid, and he said yes." This is binding? Common sense and the law would say no, yet you would allow devices with an order of magnitude less analytical power than a retarded child to give and receive similar permissions.

Repeat after me folks: devices cannot give and receive permission for human actions without those permissions expressly being granted via some other means.

A traffic light doesn't give you permission to cross the street; the government (that you studied to get your license) gives you permission to cross the intersection when a light is green, and denies it when red.

Your ID badge doesn't ask permission to enter your building, and the security system doesn't grant permission; YOU ask for permission by presenting the badge, and your employer grants it by programming said system to accept your request.

Closer to the typical small-time network admin, perhaps, bennomatic writes

If I leave my bike outside unlocked for 10 minutes, am I giving explicit permission to anyone who sees it that they can take it? No. Am I allowing it to happen through negligence? Sure, but call it what it is; it's still stealing, or at least trespassing.

Even something as amorphous as bandwidth is a limited resource. To paraphrase the head of the commerce committee, an open wireless connection is not a dump truck you can just load up with as much as you like; it's a tube!

Various forms of the same disagreement surfaced in various corners of the discussion: squiggleslash, for instance, writes

[I]t makes sense that no implied permission is given by simply having your router be unsecured, given "unsecured" is the default configuration of most off-the-shelf routers.)

It really isn't an issue in practice. If you want to use someone else's network, all you have to do is ask them. With 802.11, you're close enough to be able to do so. There's no reason not to ask, other than knowing that "No" is likely to be the answer. And I think that's why people tell themselves the myth that somehow they have implied permission simply because the "door" was left unlocked.

The figurative "visibility" of an open wireless network also isn't enough to convince reader R2.0 that it's fair game for passers by. He writes:

So the router is "visible," with an option to make it invisible. Big deal. My garden is visible from the street, but I can put a tarp around it to obscure its existence. What you are saying is that, unless I put a tarp up around my garden, everyone has a right to use it.

Wireless networks may make themselves conspicuous, but that does not confer an invitation to use them. The connection between "visible" and "inviting" is not legally or morally valid. (I am excepting the concept of "attractive nuisance," but I don't think open routers will come under that area of liability)

Reader 4e617474 fired the next volley in this battle of analogies:

No, actually we're saying that if your garden pelts us with carrots and peas as we walk past on the public street, we're at liberty to catch them and consume them. Only if you place anti-vegetable-flight netting around your garden (or stop planting vegetables that lend themselves to comparison to an unsecured WAP) does it become incumbent upon us to behave as good citizens.

Hey! Analogies are fun! Somebody compare Internet privacy law to hunting and fishing licenses!

Readers like ShawnDoc make a case persuasive for discouraging bandwidth borrowing on the basis of enlightened self-interest.

If someone uses your connection for illegal activity (downloading Meet the Fockers, kiddie porn) it will be your IP address that the RIAA/MPAA/FBI will trace. Good luck convincing them it wasn't you. You might be able to do it, but it will take up time and money (lawyers) to clear your name. And in the case of kiddie porn or other criminal act, expect every computer, PDA, and cell phone in your home to be confiscated to be analyzed for incriminating data. The second problem is you are allowing strangers access to not only your Internet connection, but also your LAN. I have multiple computers and put files in shared folders so I can access them from different machines. I don't want some strange to have access to those files, or worse, have their computer be infected with a worm/virus that propagates across the network.

Thanks to all the readers whose comments informed this conversation, and in particular to those whose comments are quoted above.

gbulmash asks: "Recently, I began working on a graphics project and wanted to use ImageMagick. As a PHP coder, I figured I'd use MagickWand for PHP. But after some investigation, I decided that an alpha at 0.1.8 with sparse documentation just wasn't going to be good enough for production use. I decided that PerlMagick would be a much better API, but I didn't want to code the whole project in Perl. In the end, I found a cool package for embedding Perl code in PHP scripts (with an article on its use) and it went to a 1.0.0 release, earlier this year. I think I've found my answer, but before I make a final decision and go ahead with it, I thought I'd ask the knowledgeable Slashdot crowd: Is there a better way of interfacing Perl with PHP so you can get the best of both worlds?" So you've got Perl in your PHP, is there a way to do PHP in your Perl?

gbulmash asks: "Recently, I began working on a graphics project and wanted to use ImageMagick. As a PHP coder, I figured I'd use MagickWand for PHP. But after some investigation, I decided that an alpha at 0.1.8 with sparse documentation just wasn't going to be good enough for production use. I decided that PerlMagick would be a much better API, but I didn't want to code the whole project in Perl. In the end, I found a cool package for embedding Perl code in PHP scripts (with an article on its use) and it went to a 1.0.0 release, earlier this year. I think I've found my answer, but before I make a final decision and go ahead with it, I thought I'd ask the knowledgeable Slashdot crowd: Is there a better way of interfacing Perl with PHP so you can get the best of both worlds?" So you've got Perl in your PHP, is there a way to do PHP in your Perl?

Michael J. Ross writes "To modify a digital image, most computer users turn to a GUI-based image processing application, such as Photoshop. However, while Photoshop and many other similar programs can process multiple images in batch mode, they still require manual usage, and thus typically are unable to process images via a command line or within a second application. Those capabilities call for a programmatic digital image manipulation tool such as ImageMagick, which is explored in a relatively new book, The Definitive Guide to ImageMagick." Read the rest of Michael's review. The Definitive Guide to ImageMagick author Michael Still pages 335 publisher Apress rating 7 reviewer Michael J. Ross ISBN 1590595904 summary An introduction to using ImageMagick for digital image manipulation.

The author of this title is Michael Still, a programmer who gained experience with ImageMagick during his eight years of working on imaging applications, as well as writing articles on ImageMagick for IBM DeveloperWorks. Apress maintains a Web page for the title, where a visitor can purchase the electronic version of the book, read its table of contents, or download its source code or a sample chapter (Chapter 4 — Using Other ImageMagick Tools) in PDF format. They also have a link where readers can submit errata — and apparently be the first to do so, as there are no existing errata listed on the Web page.

The book's 335 pages are organized into a dozen chapters, following an introduction and a few other standard sections, including a forward written by ImageMagick's principal architect, Christy, who briefly explains the product's 20 years of history, development, and lack of decent documentation. That is where this book is intended to fill the gap, and Christy notes that most future questions about ImageMagick will be answered by pointing people to this book, as is also noted on ImageMagick's homepage.

The first chapter of the book explains how to install and configure ImageMagick, for several Linux distros, as well as Microsoft Windows — using the precompiled versions, or by compiling from ImageMagick's source code. The chapter is wrapped up with a brief description of ImageMagick's online help, debug output, verbose output, and version information. The next ten chapters fall into two categories: ImageMagick usage as a standalone, and from within other applications. The first category of chapters covers basic image manipulation, compression, other metadata, ImageMagick tools, artistic transformations, other image transformations, and drawing commands. The second category discusses how to utilize ImageMagick from within programs written in Perl, C, Ruby, and PHP. The 12th and final chapter is quite brief, and describes where to find online help (Web sites, blogs, mailing lists, and forums) and where to report any apparent bug in ImageMagick.

For Windows users, the first chapter may begin badly, as the author fails to explain which precompiled version the reader should select if they wish to install ImageMagick on a Windows PC. For each version, there are four flavors to choose from. But which one is right for the reader? "static" vs. "dll?" "Q16" vs. "Q8?" What are the differences? The ImageMagick Web site and FTP file listings appear to have no README file or installation help file to explain which flavor you should download. The book should provide some assistance here, but does not. The former topic, static versus DLL, is mentioned only in reference to compiling ImageMagick from source — information which the reader will probably never see, should they choose to install the precompiled binaries and get started on ImageMagick as quickly as possible.

The latter topic is not covered at all — not even in the index, where a "quantum depth" entry would be useful. For those readers who are interested, "Q8" indicates 8 bits-per-pixel components, and "Q16" means 16 bits-per-pixel. The latter allows one to read or write 16-bit images without losing precision, but requires twice as much resources as Q8. Apparently Q16 is the best choice for medical or scientific images, or those with limited contrast. Otherwise, Q8 should be sufficient, and offers greater performance.

The material most likely to be read, referenced, and valued in this book, is the chapters devoted to explaining how to use ImageMagick for resizing, compressing, transforming, and drawing digital images. Most of these first-category chapters begin with a concise summary of the theory put into practice throughout the rest of the respective chapter — a wise inclusion in each case, since even the most experienced computer programmers and other users have had no instruction or experience in image theory. All of these chapters do a competent job of explaining what each ImageMagick command is used for, and then illustrating it with a straightforward example.

The most glaring deficiency in these chapters, and the book as a whole, is that far too many of the book's figures (digital images, naturally) fail to reflect what is intended to be conveyed by each figure. This is primarily because they are all in black-and-white, and in many cases do not offer the size and resolution necessary. In other words, there are many cases where the "before" and "after" images look almost identical. In the cases of color manipulation, most of those black-and-white images are of little value — occasionally laughably so.

The second-category chapters, covering ImageMagick usage with Perl, C, Ruby, and PHP, proved disappointing, primarily due to their narrow focus, and lack of tips, recommendations, and coverage of the APIs' capabilities. The details are presented in the form of a single example for each language. For instance, the Perl chapter devotes too many pages to source code listings of a Perl program written by the author, that few readers would probably download from the publisher's Web site, much less read.

Nonetheless, this book should be useful to any programmer interested in making the most of ImageMagick's capabilities, and that is not just because it is the only ImageMagick book on the market. Michael Still certainly had his work cut out for him when he agreed to document the bulk of what ImageMagick can do. It is unfortunate that the color images that he created for the book cannot be seen by the reader, and that the Windows binary versions and ImageMagick APIs, were given short shrift. We can hope that future editions of this book will be significantly strengthened, such as including color and higher resolution images where needed — even if it requires grouping them together within the book, if that reduces production costs.

Lastly, it should be mentioned that, as a smaller technical publisher, Apress is not resting on its laurels, and is not only scheduled to release an impressive variety of programming books this year, but their customer support — at least in my experience — was outstanding, as there was a problem with the shipping of this title, and they bent over backwards to make it right.

Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com."

You can purchase The Definitive Guide to ImageMagick from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

millert writes "Alek's Christmas Lights Webcam is back again which allows you to: 'pan/zoom the webcam and control the 17,000 christmas lights - yep, turn 'em on and off and annoy my understanding) neighbors! ;-)' For those who like a lot of links, check out his christmas lights summary, christmas FAQ (answers quite a bit), what's new for Christmas 2004 (optimization of analog controls and mod_perl on the web server -- he says "I might stand a chance against Slashdot" ... we'll see about that!), real-time Christmas stats (including browser percentage -- go Firefox, currently at 13%), and his analysis of the Slashdot effect." Read on for more.

millert continues "You can Email Santa page and he does respond to Email inquiries. Alek is already thinking ahead for Christmas 2005 ...

The picture quality on his cool webcam pictures seems much better than a run-of-the-mill webcam; the image quality under low-light conditions is surprisingly good. In question D-5 of his FAQ, he says he has it under non-disclosure and all he can say is that it is a "640x480 pixel image using 1/2.7" sensor - size matters when it comes to pixels" and he is right about that -- this is one of the reasons the pictures of Mars from the Spirit Rover were so good. Even more interesting is the info in the jpegs' EXIF header (as displayed by ImageMagick's identify utility. There's quite a bit of information in there, including a reference to a company that provided IP-based video security for the 2004 Olympics and a comment saying 'do NOT release to marketing droids' Fortunately, this is Slashdot.

Slashdot crushed it in 2002 and 2003 -- will the 3rd time be the charm for Alek?"