[Adium-devl] Hardware plans

Evan Schoenberg evan.s at dreskin.net
Sun Aug 19 21:33:31 UTC 2007


On Aug 19, 2007, at 4:16 PM, David Smith wrote:

> If we're going to have this much power available I think we should
> brainstorm additional uses.
Definitely!

> One thing that sounds nifty to me is a
> custom build maker. You'd submit (email?) a patch to the server, and
> it generates a build and sends the download link back.
Colin wrote:
> Buildbot actually has this functionality built in :)

That's a good idea, and cool that buildbot can do it.  Out of  
curiosity, what does the workflow look like?

> SubEthaEdit Server?
http://www.codingmonkeys.de/blog/articles/2006/04/03/running-a- 
subethaedit-server is perhaps the script Zac found.  It'd be nice not  
to have to only share a predefined list of documents (though we could  
use VLC or the like to actually open and share a document via remote  
control, that's a bit inelegant).  Anyone know of anything cleaner?   
One way or another, SEE server would definitely be a great use.

> Cocoa stuff serverside? Also, 10.5 Server has some rather neat team  
> collaboration stuff.
I think we'll definitely want to move to 10.5 Server once it's out.   
That time might also be the right time to add a Mac Mini -- we could  
run 10.4 on it and therefore have a guaranteed 10.4 box for anyone  
who needed testing (since most of us will presumably move to 10.5 ASAP).

> Overall expected improvement: ~20%, with some specific applications
> doing much better (DIVX, for example, is MUCH faster)
>
> That said, it's unclear how Apple's plans will interact with this.
>
> After that it'll be fairly dry on the processor front until the
> second half of '08 when the introduce a new architecture.

I imagine Apple will move up to that chip given it's been a year  
since a refresh and it can be assumed that many people -- like us --  
are on the fence on a purchase waiting on it.  I think we should do  
so...

> Upgrade-wise, do we want to focus on reliability, functionality, or
> performance? i.e. more memory, OSX server, RAID, redundant power
> supplies, etc...

My thoughts are:
  * Upgrade the processor.  In the current gen, that'd be either  
2x2.66ghz dual core Xeon or 2x3.0 dual core Xeon.  If we wait for the  
next gen, that level of performance will likely be the baseline...
  * Upgrade RAM to 2 GB (which is 4 x 512 mb) or 4 GB (4 x 1 GB). I  
think this is pretty much requisite; I don't like running OS X on 1  
GB of RAM for personal use, and I imagine server use demands even more.
  * Hard drive upgrade? The default is 80 GB; we could add 80 more  
for $200 or move to 750 gb for $500 (prices at baseline, not  
considering ADC or education discount).  I don't think a RAID is  
necessary for our current purposes, personally.
  * Doesn't it come with OS X server?
  * Redundant power supply: I think we should get Applecare on the  
machine and -not- get a redundant power supply.  We're going to be  
doing a lot of awesome stuff with this but it won't be mission  
critical in terms of 100% uptime; putting that money towards  
Applecare means that if there were a problem of any sort we could get  
rapid resolution.

> I also agree with Chris's suggestion to investigate multiple minis.
> XServes may not be the optimal choice in this situation.
I don't think we have any call for multiple XServe machines.  A mini  
alongside the XServe at some point in the future, perhaps running  
10.4, could be good.  More machines is more administrative hassle and  
more potential maintenance... and the XServe is going to far  
outperform multiple Minis, I think, though I don't have hard numbers  
on that.

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070819/2ab98cc0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070819/2ab98cc0/attachment.sig>


More information about the devel mailing list