Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Big BLU -- Options



I know its easy to do, I just sense a 'we should run x not y' issue
approaching =)

-miah

On Wed, Aug 18, 2004 at 03:22:34PM -0400, Drew Taylor wrote:
> Even if the individual machines were distributed physically, it seems 
> reasonable to ask that each system be running the same OS version. It 
> could be as simple as a boot CD (since netbooting over a consumer 
> broadband connection would be SLOOOOW). If you can get a complete distro 
> on a single CD (Knoppix), it should be relatively easy to do the same 
> for our cluster's OS which will have significantly less software.
> 
> Drew
> 
> miah wrote:
> 
> >A requirement of distcc is that each system have the same exact
> >version of gcc.  If everybody is running a different distro on their
> >systems, this will be a problem.
> >
> >-miah
> >
> >On Wed, Aug 18, 2004 at 02:30:00PM -0400, Keller, Tim wrote:
> >
> >>I was thinking about what Big BLU could be used for and I had a couple of
> >>ideas.
> >>
> >>1. http://distcc.samba.org distcc cluster. This would allow the users todo
> >>stuff like recompile an entire distribution for a specific architecture.
> >>2. There is a version of povray called MPI-Povray that'll run on a Beowulf
> >>cluster.
> >>3. Prime Number evaluation
> >>
> >>That's what comes to mind at the moment.
> >>
> >>Tim.
> >>
> >>-----Original Message-----
> >>From: Jeff Kinz [mailto:jkinz at kinz.org]
> >>Sent: Wednesday, August 18, 2004 1:25 PM
> >>To: discuss at blu.org
> >>Subject: Re: Big BLU -- Options
> >>
> >>
> >>On Wed, Aug 18, 2004 at 12:48:56PM -0400, markw at mohawksoft.com wrote:
> >>
> >>>We could have a very loose cluster, where we basically keep our machines
> >>>at home and they connect to some central server node. This is sub optimal
> >>>because the network connection is slow. This would force what ever tasks
> >>>we run on this to have a much higher ratio of CPU to data, but it would 
> >>>be
> >>>the easiest.
> >>
> >>A virtual cluster.  This may work better than we think.  Many BLU
> >>folks are on Cable or DSL.  Not great for truly distributed processing
> >>but we can utilize it with partitionable tasks.
> >>
> >>
> >>>We could start small, only a few machines in someone's basement.
> >>
> >>Yes, cooler & no weight concerns, AC? Dust? (Dpends on the basement)
> >>Spend bucks (below) on paying them for power and AC?
> >>
> >>
> >>>We could all chip in a few bucks and see what that, and the generosity of
> >>>some colo, will get us.
> 
> -- 
> ----------------------------------------------------------------
> Drew Taylor                 *  Web development & consulting
> Email: drew at drewtaylor.com  *  Site implementation & hosting
> Web  : www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
> ----------------------------------------------------------------
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
> 




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org