[wuug-list] Collaboration Projects?

[Brad Bobak]

the prolog interpreter would be pretty cool.. It would be better as a 'distributed prolog interpreter :)'

 I've been tossing around some ideas. First off is a window manager. I know theres gazillions of them, but it would be a good Xlib learning point.
 Second would be an IRC client. I irc alot, so this would be interesting.
 Anything distributed peaks my interest. I like thinking multi-threaded and all that. (no flames plz matt :)
 I have been working on a lan monitor over the last week. The project was started because I wanted to monitor all distcc compiles on my network. Its pretty bare bones, and the only plugin I've made for it so far is the distcc one. But the general framework is still there. It dlopens a shared libary, and requires a few symbols to be defined. On the client end it passes in a pointer to a GtkWidget pointer which the plugin can use to draw its output. This was my first gtk app, so I'd also be interested in anything gtk too.
 Well, thats all that comes up right now, maybe I'll have more ideas later.
 And of course theres always the possibility of writing a posix compliant os.. (joking)



--- On Mon, 6/16/08, Matt Draisey <matt at draisey.ca> wrote:

> From: Matt Draisey <matt at draisey.ca>
> Subject: [wuug-list] Collaboration Projects?
> To: wuug-list at wuug.org
> Received: Monday, June 16, 2008, 8:18 PM
> I am disappointed that no one has come forward with any
> ideas for
> collaboration projects so here a few things I have been
> mulling over.
> 
> 
> 
> 1. An RFC for a replacement for SMTP.
> 
> A conceptual rather than a strictly programming project.
> 
> Email is developing in ways that I don't care for.  All
> this verifying
> of servers, secure DNS stuff takes away from the simplicity
> of the
> protocol and erects all sorts of barriers to implementing
> your own email
> transport.  My idea is to have servers accept mail for
> published email
> addresses from anyone but to make it sufficiently
> computationally
> expensive for the sender that spamming isn't cost
> effective.
> 
> Unlike SMTP mail this would be one-to-one not one-to-many. 
> For each
> mail sent their would follow a challenge/response handshake
> between the
> sender and recipient server.  The recipient machine would
> demand a
> battery of spam filters be applied.  The sender would be
> required to
> apply the filters (computationally expensive) and return
> all the
> resulting scores.  The recipient could verify a subset of
> these to
> verify that the sender isn't cheating and if the scores
> are low enough
> accept the mail straight away.  If the spam scores are too
> high the
> recipient would challenge with another battery of tests. 
> The number of
> challenges would decrease geometrically (but slowly) so
> there will be an
> eventual finite (but large) number of challenges before the
> recipient
> machine gives in and accepts the mail anyway.
> 
> If at any point the sender is learnt to have cheated on the
> spam scores
> the mail would not be accepted.  Somebody would have to
> look at this
> from a game theoretical point of view to determine the best
> strategy to
> avoid cheats.  I haven't done such an analysis but my
> gut instinct is
> that it shouldn't be too expensive for the recipient.
> 
> Presumably there would need to be a standard interpreter in
> which the
> spam filters would run so that execution on the sender and
> recipient
> would yield identical results.  It needn't be an
> efficient interpreted
> language as the computational cost is the whole point. 
> Inputs would be
> restricted to the mail itself, the script, and some
> ancillary data tied
> to the script (e.g. a dictionary).  It would need to be
> carefully
> sandboxed so as not to be able to compromise the
> sender's server and to
> be able to throttle scripts that aren't terminating. 
> As part of the
> handshake the recipient's machine would send a
> reference to the text of
> a particular script in a public repository; the scripts
> would be
> retrieved by reference: maybe an url or a SHA through a
> domain name
> lookup?  They might even be cryptographically signed for
> soundness.
> 
> 
> 
> 
> 2. A shell that would have support delimited continuations
> 
> Delimited continuations are a pet interest of mine lately. 
> They seem an
> ideal fit for a simple shell programming language. 
> Something much
> simpler than scheme.  This is a real pie-in-the-sky
> project.
> Potentially very interesting though.
> 
> 
> 
> 
> 3. Anything on the web with Ruby on Rails.
> 
> Ruby on Rails is fun to develop with.  Can't vouch for
> the utility of
> the result however.  Ruby is a slow language.
> 
> 
> 
> 
> 4. Writing a Drupal 6 module
> 
> Drupal is a great php CMS.  I've been using drupal for
> several years
> without knowing how the code works or having written a line
> of php.  I'm
> interested in learning.  Maybe a drupal theme too.
> 
> 
> 
> 
> 5. Writing a practical programme in Haskell
> 
> Probably impossible.
> 
> 
> 
> 
> 6. Finish my rsync like downloader that runs over http.
> 
> This is a combination of zlib file compression and a
> differential
> downloader that works with files that are prepared
> beforehand and made
> available by a static http server that supports byte range
> downloads
> (practically all of them).
> 
> The code is a horrible mish-mash of perl and C++ and I have
> been
> planning on finishing it for years.  This was meant to be a
> one-week
> project in perl.  Ha.  Perl was too slow for the algorithm.
>  And the
> actual downloading routine sprouted unexpected complexity. 
> Surprisingly
> the code actually works quite well even if installing it is
> a pig.
> 
> One day I may learn how to write code elegantly in C++.  Or
> maybe not.
> 
> 
> 
> 
> 7. Finish my trivial prolog interpreter.
> 
> I wrote a proof of concept in java about 10 years ago, and
> a simple port
> to C++ about 5 years ago.  It runs but is mostly useless. 
> I was
> learning the intricacies of C++ at the time so the code is
> incredibly
> crufty and portability is a distant dream.
> 
> 
> 
> 
> I hope that this might initiate an email thread.  These are
> just things
> I have been wanting to itch.  Other people's itches
> might yield better
> project ideas.
> 
> Matt


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/