From: Geoffrey Thomas Date: Sat, 20 Mar 2010 18:02:22 +0000 (-0400) Subject: A couple of ideas from the murky depths of my brain X-Git-Url: https://sipb.mit.edu/gitweb.cgi/wiki.git/commitdiff_plain/d421b244bcaa5e0f0a17d14222becaf03665f82a A couple of ideas from the murky depths of my brain --- diff --git a/projects/ideas.mdwn b/projects/ideas.mdwn index 4587e04..3e293d3 100644 --- a/projects/ideas.mdwn +++ b/projects/ideas.mdwn @@ -227,6 +227,39 @@ _Contact: jhamrick_ _Contact: davidben_ +## Etherpad + +[Etherpad](http://etherpad.com/) is an awesome tool for online collaborative text editing. It's recently been open-sourced; set up a Java servlet container on XVM, make it work, and then start adding cool MIT features like, oh, the ability to edit daemon.etherpad-writable files in AFS, login with certs and see all your files, and print to Athena printers. Or add cool non-MIT features such as an Emacs client (possibly proxying [Infinote](http://gobby.0x539.de/trac/wiki/Infinote/Protocol), which appears to have some F/OSS implementations already), or integration with [codepad](http://codepad.org/) or [gists](http://gist.github.com/). + +_Contact: geofft_ + +## RFC pretty-printing + +I think every RFC website I know of just puts the entire RFC plain text in a <pre&rt; tag. It should be possible to parse out the headers and footers every "page", make section headings into useful ones, and reflow the non-diagram text in a proportional font, which would make RFCs more readable. + +_Contact: geofft_ + +## scripts.mit.edu file upload form + +Really, it should not be as hard as it is to make a website where people can upload files too big for e-mail to your locker. Either find a good, simple, PHP or Python or something file upload app, or write a (relatively small) one of your own and a scripts autoinstaller. + +_Contact: geofft_ + +## fakechrooted distros in AFS + +Thanks to the deeply disturbing magic of a couple of programs named fakeroot and fakechroot, you can without root privileges enter a "chroot" of an operating system and look at how things work in it. Create some appropriate chroots for popular Linux distros in a locker and appropriate wrapper scripts. + +_Contact: geofft, broder_ + +## A couple of C/C++ hacking projects + +* Each AFS cell has its own database of users and groups. If you run `ls`, it will look up users and groups against the local machine's conception of users and groups, so if you take a stock Linux etc. machine and look at most any AFS cell, you'll get a bunch of unhelpful numbers. Make an interface that stands a decent chance of being merged into upstream `ls` to permit it to call `pts examine` (or, rather, the AFS library equivalent) against the appropriate servers instead of `getpwnam` etc. on AFS files. See also [Debathena Trac #300](http://debathena.mit.edu/trac/ticket/300). +* OpenSSH has an option to enable [non-strict acceptor checking](http://www.sxw.org.uk/computing/patches/openssh-patches/strict-acceptor) for Kerberos authentication, so you can ssh to, say, scripts.mit.edu and successfully authenticate despite being load-balanced to a machine that thinks its name is, say, old-faithful.mit.edu. (Specifically a non-strict acceptor lets you authenticate to a machine using any credential in its keytab; a strict acceptor will require that you authenticate to the specific key for the machine's name.) Port the non-strict acceptor option to [Cyrus SASL](http://asg.web.cmu.edu/sasl/) so that scripts.mit.edu can pull the same trick for SVN and LDAP and so forth. +* I often find that [sbuild](http://packages.debian.org/stable/sbuild) installs many of the same packages into the "base" chroot; for instance, a bunch of Debathena packages depend on cdbs and config-package-dev. sbuild should have the ability to take advantage a chroot with these packages preinstalled (so long as all the packages in this chroot still are a subset of the build dependencies), and for extra awesome bonus points, look at a repository and suggest what non-base chroots I should create. +* [Write a caching NSS module](http://debathena.mit.edu/trac/ticket/486) that will play more nicely with Debathena than nscd (the current solution) does. It will probably end up looking like nss_nonlocal. + +_Contact: mostly geofft_ + ## Your Project Here SIPB can help you out in terms of both computing resources and