[2283] in athena10
Re: DebConf9: Call For Papers (fwd)
daemon@ATHENA.MIT.EDU (Greg Price)
Wed Apr 15 04:52:43 2009
Date: Wed, 15 Apr 2009 04:51:56 -0400
From: Greg Price <price@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
Cc: debathena@mit.edu
Message-ID: <20090415085156.GZ21912@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.10.0903222120070.8575@vinegar-pot.mit.edu>
On Tue, Apr 14, 2009 at 12:58:06PM -0400, Tim Abbott wrote:
> Title: Debian Configuration Packages
>
> The latest version of MIT's Athena platform, Debathena, is based on Debian
> and Ubuntu. Unlike past versions of Athena, Debathena is actually a set
> of packages maintained in near compliance with Debian policy, built for
> all releases of Debian and Ubuntu currently supported upstream. This has
> made Debathena very popular on laptops and other machines owned by
> students and staff.
>
> A key innovation of Debathena is its configuration packages, which
> configure services like Kerberos for use at MIT. Unlike many systems for
> managing configuration, these packages are designed to provide site
> defaults, not take the role of the system administrator. So, anyone at
> MIT can install Debathena on top of their existing system via apt to
> configure Athena services and install Athena-specific software, without
> sacrificing their ability to customize their machine.
>
> In this session, I hope to briefly overview what we've done, and then have
> a discussion of how Debian can make things like Debathena easier.
What are the things you hope people will remember from this talk?
Several that this abstract suggests are
- tabbott/MIT does awesome things
- config-package-dev is useful, I could try it
- Debian maintainers could make their packages more flexible, here's how
Those would all be nice, but perhaps the most general of them all --
and therefore perhaps the most realistic for people to retain -- is
- Awesome things can be done with Debian technology outside of Debian proper.
If that one actually sticks with people, then they may make better
decisions as they design their packaging and make other choices that
impact the implementation of Debathena-like systems. If they remember
that, and remember to look for config-package-dev if they ever want to
do such awesome things themselves, then I think the talk has served
its purpose well. (And if they remember your name, Athena's, or MIT's
in connection with the awesomeness, then that's a bonus.)
So one thing I'd like to have in the abstract is some mention of the
general concept of Debian technology applied outside of Debian proper,
of which Debathena is an example and for which config-package-dev is
one tool. E.g. perhaps a new paragraph after the second one, saying
that.
You should definitely mention the name "config-package-dev" in the
abstract, so people can make that connection and so web searches for
config-package-dev might record that you gave a talk about it. You
might consider also mentioning CDBS to similarly contribute to its
record, though it's possible that the cost in people reacting
unreasonably to the name "CDBS" would be too great.
In the second paragraph I'd say specifically that "Debian packaging
technology", or perhaps "dpkg" or even mention dpkg-divert, enables
Debathena to leave the system administrator in control. That gives
Debian a little more credit and may make people feel good.
The mention of "things like Debathena" could be clearer about how
broad this category is. Perhaps the whole clause could be "and then
discuss how Debian maintainers can make their packages more flexible
for Debian-enabled systems like Debathena".
You might also try to promise a takeaway about how attendees can use
Debathena's config-package-dev and other Debian technology to
configure their local workplace, so there's something to gain as well
as something to be exhorted to do.
I'm skeptical of the discussion of "MIT's Athena platform" in the
first paragraph; for people who've never heard of Athena I think it
may be hard to understand. In particular, a natural reaction to the
contrast in the second sentence may be "OK, so your predecessors made
messy packages, what else is new?" for a reader who doesn't know that
previous implementations of Athena made it a monolithic complete
system and a totally curated computing environment.
Do you have a list in mind of the best-practices you'll encourage
people to follow? E.g.
- keep config files static, find alternatives to modifying them in postinsts
- .d directories are one honking great idea -- let's do more of those
(but use run-parts --list or something else to exclude funny-named files)
Looking at such a list might help in aiming the "make things easier
for us" part of the pitch, even though you may not want to write it
down in the abstract.
OK, that's enough for one email.
Greg
