Slashdot Mirror

http://jbrout.python-hosting.com/wiki Cross platform. Claims to have been tested on GNU/Linux and Windows XP/2K. Been meaning to try it as my own photo collection is starting to get a little unwieldy, but haven't done so yet.

I have used JBrout for a while. It is written in Python and writes tags as IPTC keywords in the picture.

Trac is a web-based software project management and bug/issue tracking system. It provides an interface to Subversion and an integrated wiki. It uses Apache and mod_python, but it's really easy to install if you follow the instructions.

You can see examples of it in use at PylonsHQ and the Django site, both of which are styled nicely. You can see a default install at PyDelicious.

And no, it's not only Python sites that use it. Those are just the ones off the top of my head. :)

• Django: http://www.djangoproject.com/
• Turbogears: http://www.turbogears.org/
• Subway: http://subway.python-hosting.com/

In practice coercion in a first world country is irrelevant and there are laws in place to protect you.

Whereas corruption of votes is a real and ongoing threat.

Verification of votes is important and there are ways to reduce chances of the already irrelevant coercion:
the physical copy contains two sheets that seperate to in effect obscure the result, but can still matched up for verification.

http://yro.slashdot.org/article.pl?sid=03/11/25/21 3206

An explanation with pretty pictures here

Though there are concerns:
http://gnosis.python-hosting.com/voting-project/No vember.2003/0126.html

Really you should support the Open Voting Consortium.

Someone is, and it's called Subway: http://subway.python-hosting.com/

Using SQLObject is very popular with CherryPy users. CherryPy works with just about any templating system out there. This also makes it very easy to port from other Python web frameworks because you can use your existing templates.
  Subway was created to use CherryPy, SQLObject and Cheetah templates in a very Ruby on Rails-like way, so you don't have to go through the 10 zillion decisions of what to use with CherryPy and tells you "what to do and where to put it".

http://xinha.python-hosting.com/ is an textarea replacement based on HTMLArea. Works in IE and Gecko-based browsers. It has "Remove Word Formatting" and Tidy buttons.

If you were going to use forms to cut and paste Word content, this should be your route.

Yes, a few betas within the beta already have access to "rich formatting" as they call it, but it has not reached me yet so I assume there are a few problems they are working on. http://xinha.python-hosting.com/ looks like an interesting alternative, but does not have a mac version yet.

I predict there will be basically two categories of posts about Rails.

Either, one, that Rails is so amazing that after you use it sex seems laughably trivial by comparison, even and especially you count the production value -- one can, after all, only have one child (on average) using sex, but with Rails, dude, I HAD TEN.

Or, two, that Rails is no big deal, it's just another MVC re-think, heck I rolled one of those myself one afternoon a coupla years back, yeah it ruled but, you know, I'm really into that Java thing now. Besides, Rails is no good for BIG projects, for that you need Hibernate and a crane.

So I'll post one for the middle-of-the-road. Rails rules. I love it. I've reimplemented, in a week-and-a-half, a fairly large application that took me two months to do with Python. It's not a fair comparison because with Python I used Webware but did everything, like user management and logging, with no starting point, and also the first time around I wasn't as familiar with the problem domain.

With Rails I used the Salted Hash Login Generator which got the basics of my user login and management done in one fell swoop, an hour or two of work. I also re-used the view code from the Python app.

But the rest of it was fun. I enjoyed it. Things were done quickly and the API is awesome. ActiveRecord is not Hibernate -- yes, Javapeople, we know, we know -- but it's good. It's really good and super easy. And while there's some magic going on behind the scenes with Rails, it's not hard to understand at all.

That said, yes, if you're an online payroll system for IBM, Rails won't cut it. There are flaws, but for day-to-day stuff, not too many. It's updated very frequently, too.

My only complaint is the ubermensch of Rails, Dave Heinemeier, who, while smart, is also all too aware of it, and frequently shoots his blog off about topics which go beyond Web frameworks and into areas of either glib tech-prejudice or, at times, more subtle see-how-smart-I-am dorkposts -- the most insufferable species of Geek.

Otherwise, I strongly encourage anyone to check Rails out. It's great and a *lot* of other frameworks in other languages could stand to pay attention to the innovations in Rails. These innovations aren't so much technical epiphanies, as they are the meeting of many good ideas in one place, along with enthusiastic support and a lot of glue. Ruby's fun, too.

Check out, also, the frameworks from other languages which are shamelessly stealing from Rails:

Subway (Python)
Catalyst (Perl)

If you are comparing Rails and Zope, you probably aren't comparing things properly. Doing a CMS? Then Zope has a lot of infrastructure, and Rails has none. Doing a small databased-backed web application? Then Zope will be rather painful.

If you want to compare a Python option to Rails and Ruby, you should look at something like Paste/Webware, CherryPy, Subway, Aquarium, or others. There's a lot of choices, but there's very active work to bring together these web platforms, so won't be trapped by your initial choice.

An open-source (GPL v 2) Content Based Image Retrieval program already exists: imgSeek .

To search a photo, you don't need a similar photo, simply draw a rough sketch. See this screenshot.

Oh, you mean like imgseek?

There already is imgSeek (GPL):
http://imgseek.python-hosting.com/

If you are only interested in searching for images on your own computer, have a look at imgSeek. http://imgseek.python-hosting.com/

It's been around for some time now. You can not only use an existing image to search, but also do a rough sketch. Check the screenshots:

Nice complement to what has been presented in this article.

Because it still has problems - you'll note that the pictures seem to be compared simply based on color similarity. That's the same thing imgSeek does (a great program for sorting and searching your photos) on photo searches. It works wonderfully if you're searching a very limited picture subset (say, airplanes), but if you search a wide variety of pictures, the results can be quite amusing.

I checked out the video demo at http://media.nextangle.com/rails/rails_setup.mov and I have to admit that I'm pretty impressed. This framework eliminates a lot of the tedium that goes into developing web apps... Here's my problem though... Is there any reason it has to be in Ruby? I've heard of python's equivalent 'subway' ( http://subway.python-hosting.com/ ), and I'm wondering if Ruby has some language feature that makes it inherently more suitable than other languages (like python) for this 'rails-style' of development...

Otherwise, I think I'd just rather stick with Python... It seems to have a bigger and more mature standard library, and I can find more web hosts to support it... I'm not trying to start a language war, I'm just looking for the practical solutions...

TAACS is an open-source system for doing very similar (automatically responding to threats) being put together by a student at the University of Texas - Pan American.

http://taacs.python-hosting.com

For the lazy: http://subway.python-hosting.com

Python has a great low-level framework called CherryPy http://www.cherrypy.org/ and a Rails-killer called Subway http://subway.python-hosting.com/, built on top of CherryPy, Cheetah and SQLObject

clickable links one, two, three, four, five

AFAIK, the only hosting provider that supports Plone 2.0 is python-hosting.com
(although Zettai
will probably support it soon as well ...)

The problem with receipts are that they are not a legally binding vote. For a DRE voting machine (think Diebold, Sequoyah, etc), the vote is what gets recorded electronically. The receipts don't even get looked at unless the race is close enough to force a recount. So if you want to cheat, you just cheat in a big way: >= 10% margins. Note that the individual voters could still 'verify' that the receipt printed matches the vote displayed on the screen. What actually get recorded electronically could still be different!

In the OVC system, the printed paper is the actual legally binding vote. The electronic stuff is there to assist in counting. There are procedures (beta-versions mind you) in place for handling spoiled ballets, ballot stuffing prevention, etc.

Check out the mailing list for more info.

Do these people have the attention of legislators and governors?

Yes! The idea is to get research funding (from HAVA) in as many states as possible. The funding will be used to apply the scientific method to the voting process; something that has never been done before. The grand scheme includes creating a F/OSS voting software suit and logical, unified, standardized voting processes that are publicly verifiable throughout.

If you are interested in helping (or seeing what this is all about), please join the OVC e-mailing list. We even have an online archive for public inspection.

I think it *is* usable for computer illiterates. If you use a hosting provider such as Python-hosting.com or Ingeniweb.com, they'll install Plone for you and it will be ready to use when you get your account. You'll never have to know what Zope or Python is ... The main problem with Zope/Plone is that they use soooo much ressources ... There are just way too many layers in there ! But hey, it's your hosting provider's problem, not yours :-)

As it happens I discussed Chaum's system just today on the Voting-Project mailing list. I guess I might as well quote myself:

Re: securing electronic ballots

From: David Mertz %lt;voting-project_at_gnosis_dot_cx%gt;
Date: Tue Nov 25 2003 - 12:16:05 CST
|I found [the Chaum paper] here in case anyone wants to read it. |http://www.vreceipt.com/
Thanks Clay, for looking up this paper. It is consistent with what Mercuri described more briefly, but I found reading the white paper to contain additional interesting details. Btw. for other readers: the press release at that URL is fine for a summary, but look at the linked white paper for real information.
Reading the paper, I see that Chaum's system really is flawed in practice. The reason it is flawed is precisely because Chaum is TOO smart--he's great at math, but misses the real world of elections.
One weakness of the system is the one I've raised a couple times. Voters cannot understand how the system works (in any meaningful detail). For example, imagine I were a voter who did not have any graduate-level mathematics training (a large majority of voters, I think... probably a majority of this list, in fact). Now imagine that I was not entirely trustful of "the experts", and worry that someone can puncture the anonymity of my vote by properly analyzing my receipt. Sure it doesn't contain a visually readable vote, but I know in a general way that there are barcode scanners, and clever things that mathematicians and CS people do.
In answer to my concern, all I really get back is the Diebold-style answer: "Trust us, we're very smart, and we wouldn't let any errors exist in our voting system." I don't think this answer inspires general voter confidence. I personally happened to have already known about Chaum before hearing about this system, and basically trust his motives and intelligence... but how many voters can say that; how many LIST MEMBERS can say that, even?
The second weakness is the real world of voting places--typically a hastily arranged room in a church or a community center, staffed by well-meaning, but amateur volunteers. Imagine that prior to the election some guys with brass knuckles stop by my house, and let me know that they would appreciate a vote for their candidate (or equally, for example, a coercive or manipulative spouse or relative). As a gesture of good faith, they suggest, I should keep both layers of the voting receipt so that it remains clear how I voted. According to Chaum's system, the poll workers are SUPPOSED TO shred one layer on my way out. Anyone who has been to a polling place knows that it would not be of great practical difficulty to "forget" to place a layer in the shredder prior to leaving the building. Even should I make such an omission, the electronic vote was already recorded when the receipts were printed.
+++
Btw. With the EVM2003 system, a related forgetfullness is possible. Voters might forget to place the printed ballot in the ballot box. Their electronic ballot is still recorded on the machine, but only a subset of electronic ballots will be matched by corresponding printed ballots in the ballot boxes. Hopefully, this will generally be a large subset (98%+ say), but a certain discrepency rate must be expected.
Placing cryptographic codes on the printed ballots allows us to assure that every such ballot is -legitimate-, hence preventin

As it happens I discussed Chaum's system just today on the Voting-Project mailing list. I guess I might as well quote myself:

Re: securing electronic ballots

From: David Mertz %lt;voting-project_at_gnosis_dot_cx%gt;
Date: Tue Nov 25 2003 - 12:16:05 CST
|I found [the Chaum paper] here in case anyone wants to read it. |http://www.vreceipt.com/
Thanks Clay, for looking up this paper. It is consistent with what Mercuri described more briefly, but I found reading the white paper to contain additional interesting details. Btw. for other readers: the press release at that URL is fine for a summary, but look at the linked white paper for real information.
Reading the paper, I see that Chaum's system really is flawed in practice. The reason it is flawed is precisely because Chaum is TOO smart--he's great at math, but misses the real world of elections.
One weakness of the system is the one I've raised a couple times. Voters cannot understand how the system works (in any meaningful detail). For example, imagine I were a voter who did not have any graduate-level mathematics training (a large majority of voters, I think... probably a majority of this list, in fact). Now imagine that I was not entirely trustful of "the experts", and worry that someone can puncture the anonymity of my vote by properly analyzing my receipt. Sure it doesn't contain a visually readable vote, but I know in a general way that there are barcode scanners, and clever things that mathematicians and CS people do.
In answer to my concern, all I really get back is the Diebold-style answer: "Trust us, we're very smart, and we wouldn't let any errors exist in our voting system." I don't think this answer inspires general voter confidence. I personally happened to have already known about Chaum before hearing about this system, and basically trust his motives and intelligence... but how many voters can say that; how many LIST MEMBERS can say that, even?
The second weakness is the real world of voting places--typically a hastily arranged room in a church or a community center, staffed by well-meaning, but amateur volunteers. Imagine that prior to the election some guys with brass knuckles stop by my house, and let me know that they would appreciate a vote for their candidate (or equally, for example, a coercive or manipulative spouse or relative). As a gesture of good faith, they suggest, I should keep both layers of the voting receipt so that it remains clear how I voted. According to Chaum's system, the poll workers are SUPPOSED TO shred one layer on my way out. Anyone who has been to a polling place knows that it would not be of great practical difficulty to "forget" to place a layer in the shredder prior to leaving the building. Even should I make such an omission, the electronic vote was already recorded when the receipts were printed.
+++
Btw. With the EVM2003 system, a related forgetfullness is possible. Voters might forget to place the printed ballot in the ballot box. Their electronic ballot is still recorded on the machine, but only a subset of electronic ballots will be matched by corresponding printed ballots in the ballot boxes. Hopefully, this will generally be a large subset (98%+ say), but a certain discrepency rate must be expected.
Placing cryptographic codes on the printed ballots allows us to assure that every such ballot is -legitimate-, hence preventin

I tried posting a story about the EVM2003 project a couple weeks ago, but unfortunately it was rejected. I'll try again soon, I suppose. So this note is a little less complete (not all the background URLs and the like). The project comes out of several years of background work by some well known computer scientists, political scientists, lawyers, elections officials, and political activists. But the demo (to be written in Python, btw), is just starting development.

Anyway, the short story is that I am involved in a project to create an open source voting system, with the extra twist that the machines also produce printed ballots. That is, the electronic part makes selection more clear, and prevent overvotes and other errors, but after using the touchscreen (or mouse, or blind accomodation), voters can visually verify their ballot for accuracy before submitting it to the ballot box.

Read an announcement of the project at http://gnosis.cx/voting-project/announce.html.

Check out the sourceforge page for EVM2003. We also have a mailing list archive.