[6708] in Release_7.7_team

home help back first fref pref prev next nref lref last post

RE: thirdparty packages

daemon@ATHENA.MIT.EDU (Oliver Thomas)
Fri May 7 14:13:02 2010

From: "Oliver Thomas" <othomas@MIT.EDU>
To: Jonathan D Reed <jdreed@mit.edu>, Alex T Prengel <alexp@mit.edu>
CC: "release-team@mit.edu" <release-team@mit.edu>
Date: Fri, 7 May 2010 14:12:55 -0400
Message-ID: <E3560CFE983F2C4C82277F69E11BCF3A01BEAAD995@EXPO8.exchange.mit.edu>
In-Reply-To: <107A1C3A-0E49-46BD-BC39-43AEB7D63D5C@mit.edu>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

You're not alone in your view. For me it's not about disk or network, though. There's a perhaps small but certainly non-zero incremental cost to each separate install we do and then need to track, update, and support to some extent. And it adds up to a lot of complexity and "real money" over time. So having clearly defined rules, a process to decide what goes where, and a limit of duplication to the necessary (along with a definition of what's necessary) seems quite reasonable.

Oliver

-----Original Message-----
From: Jonathan Reed [mailto:jdreed@MIT.EDU] 
Sent: Friday, May 07, 2010 14:04
To: Alex T Prengel
Cc: release-team@mit.edu
Subject: Re: thirdparty packages

> So clearly there's not enough time for detailed review but some general
> thoughts below. I'd feel a lot better if we had at least a full semester
> before we make significant deletions. Also, what machines are being
> monitored? I presume cluster only. Is is all of those?

Yes, just -cluster machines.  But this means any machines running -cluster, regardless of whether they are physically located in a cluster).

> There's a number of things that I know get used...

Sure, and if there are packages requested by courses, they should stay.  However, you mention wrapper logs for pymol -- if people are all using the pymol from the locker, and not the local version, then is there any point in us continuing to ship it locally? (rhetorical question)

My primary point is this:  It's not sustainable for us to continue installing EVERYTHING both in lockers and in -thirdparty.  It also does a disservice to the users if we have N different versions of the same software floating around.  And it makes support harder.  If there's stuff that's better suited to lockers, then it should stay in lockers.  If there's stuff that's only in lockers because we had no way of putting it in the release in Athena 9, then it shouldn't go in lockers.

We've talked before about the corner case where a professor needs a bleeding-edge version of software that's newer than what's in Ubuntu.  And that's fine.  But my point is that we need to come up with a consistent policy, and most importantly we need to stick to it.   Lockers have a number of benefits -- they're easily to centrally deploy and configure, and they're accessible to anyone using AFS, not just Athena users.  But this might be a good thing and a bad thing, and we need to think about what we actually want.   And this may mean pushing back on some requests for locker software, and it may mean pushing back on requests to have things added to -thirdparty.  

There is the argument that disk is cheap, and network is (or should be cheap), so we should just install everything.  But (and maybe I'm alone in this view, and if so, I'll stop bringing it up) it just seems wrong to install EVERYTHING on local disk and in lockers and then hope for the best.

-Jon


home help back first fref pref prev next nref lref last post