Convert most http: links to https:
[wiki.git] / projects / ideas.mdwn
index 2433d3a25f316484f78036d62f3c77312902a343..88a3d24baa6baf0a50be658219ce23d3f9b972e1 100644 (file)
@@ -34,9 +34,9 @@ _Contact: geofft_
 
 ## debdiffs of Debathena packages
 
-We have [a webpage](http://debathena.mit.edu/package-list/proposed) to
+We have [a webpage](https://debathena.mit.edu/package-list/proposed) to
 list all Debathena packages in the ["proposed"
-repository](http://debathena.mit.edu/experimental#proposed), i.e., things
+repository](https://debathena.mit.edu/experimental#proposed), i.e., things
 we just changed and are waiting a few days for testing before pushing to
 the clusters, etc. However, that page gives you no information on what
 the change was. A very useful addition would be to use the `debdiff`
@@ -46,15 +46,15 @@ _Contact: broder, debathena_
 
 ## Better Trac-email integration
 
-A bunch of SIPB projects use [Trac](http://trac.edgewall.org/) as a bug
+A bunch of SIPB projects use [Trac](https://trac.edgewall.org/) as a bug
 tracker. The current email adapter we use [isn't very
-clever](http://debathena.mit.edu/trac/ticket/308); it'll send
+clever](https://debathena.mit.edu/trac/ticket/308); it'll send
 out each update to a ticket with a generic subject line, so it doesn't
 easily indicate whether the bug was resolved or someone just commented
 on it. It also doesn't know how to receive e-mail, so we can't reply to
 the e-mails it generates and have our comments go back into the bug
 tracker, and we can't [make bugs@mit.edu create Trac
-tickets](http://debathena.mit.edu/trac/ticket/216). There are one or two
+tickets](https://debathena.mit.edu/trac/ticket/216). There are one or two
 alleged plugins to do this, but they create a new ticket on every
 e-mail, rather than doing something intelligent with replies; a better
 plugin in both directions would be extremely helpful.
@@ -127,12 +127,12 @@ Debathena and Macathena come with an automounter for /mit, so links
 automatically appear when you use them, and nobdy cares much about
 detaching them, but we still use most of the complexity of liblocker
 because we haven't gotten around to cleaning it up. There's a [design
-proposal](http://debathena.mit.edu/trac/wiki/FixingLiblocker) on the
+proposal](https://debathena.mit.edu/trac/wiki/FixingLiblocker) on the
 Debathena bug tracker listing what should be a better implementation.
 
 _Contact: broder, debathena_
 
-## [Checking scripts.mit.edu servers for consistency](http://scripts.mit.edu/trac/ticket/84)
+## [Checking scripts.mit.edu servers for consistency](https://scripts.mit.edu/trac/ticket/84)
 
 Now that we have five or six web servers (I've lost count), it's
 become entirely too easy to change something on one or some but not
@@ -157,7 +157,7 @@ _Contact: geofft, scripts-team_
 
 SIPB has a bunch of books in its library. It'd be nice if a list of
 the library books also existed online in some sort of sane, searchable
-database. One possible platform is the [Exhibit](http://simile-widgets.org/exhibit/) project (which originates from a collaboration between the Haystack group in CSAIL and the MIT Libraries). This would require mostly just making a spreadsheet of the information. Check out <http://sipb.mit.edu/library/> for the current state of the catalog.
+database. One possible platform is the [Exhibit](http://simile-widgets.org/exhibit/) project (which originates from a collaboration between the Haystack group in CSAIL and the MIT Libraries). This would require mostly just making a spreadsheet of the information. Check out <https://sipb.mit.edu/library/> for the current state of the catalog.
 
 _Contact: zhangc, fawkes_
 
@@ -184,7 +184,7 @@ _Contact: leonidg_
 
 ## Improve git with shared checkouts
 
-Around SIPB we're kind of [big](http://sipb.mit.edu/iap/git/) [fans](http://web.mit.edu/cluedumps/slides/understanding-git-2008.pdf) [of](http://blog.nelhage.com/2010/01/on-git-and-usability/) [git](http://negativespace.mit.edu/2010/03/08/gitionary-the-graphical-game-of-git-guessing/). But there is an area that git comes up short. We have a lot of common directories where people really just want to edit files in place (instead of wanting to clone/checkout, edit, commit, push...), but git doesn't support that well. It would be cool if there was a way to work with non-bare repositories in shared directories.
+Around SIPB we're kind of [big](https://sipb.mit.edu/iap/git/) [fans](https://web.mit.edu/cluedumps/slides/understanding-git-2008.pdf) [of](https://blog.nelhage.com/2010/01/on-git-and-usability/) [git](http://negativespace.mit.edu/2010/03/08/gitionary-the-graphical-game-of-git-guessing/). But there is an area that git comes up short. We have a lot of common directories where people really just want to edit files in place (instead of wanting to clone/checkout, edit, commit, push...), but git doesn't support that well. It would be cool if there was a way to work with non-bare repositories in shared directories.
 
 One idea might be using FUSE to present a separate checkout to each person using the directory.
 
@@ -192,27 +192,27 @@ _Contact: broder_
 
 ## Scripts Pony Improvements
 
-[Scripts Pony](http://pony.scripts.mit.edu) is scripts.mit.edu's new hostname management system.  It was just released recently, and has lots of bite-sized improvements remaining to be implemented.  Particularly good ideas include adding the ability to show and edit hostname aliases, checking whether hostname paths exist and giving appropriate feedback, creating a zephyrbot to allow people to approve tickets easily, and adding the ability to check hostnames in Moira automatically.
+[Scripts Pony](https://pony.scripts.mit.edu) is scripts.mit.edu's new hostname management system.  It was just released recently, and has lots of bite-sized improvements remaining to be implemented.  Particularly good ideas include adding the ability to show and edit hostname aliases, checking whether hostname paths exist and giving appropriate feedback, creating a zephyrbot to allow people to approve tickets easily, and adding the ability to check hostnames in Moira automatically.
 
-See [the project TODO file](http://web.mit.edu/pony/TODO) for more ideas.
+See [the project TODO file](https://web.mit.edu/pony/TODO) for more ideas.
 
 _Contact: xavid_
 
 ## A zephyr log viewer
 
-Many SIPB-affiliated people use the [Zephyr](http://zephyr.1ts.org/) messaging system, and the [BarnOwl](http://barnowl.mit.edu/) client for it in particular. BarnOwl has a number of very nice features that make it easy to follow large amounts of zephyr traffic: search, color coding, auto-narrowing, etc. BarnOwl can also store logs of zephyrs sent and received for future reference, but the logs are saved separated by class in a way that's quite annoying to navigate sometimes. A BarnOwl-like interface (perhaps implemented as a BarnOwl plugin) for viewing zephyr logs would be a great thing to have.
+Many SIPB-affiliated people use the [Zephyr](http://zephyr.1ts.org/) messaging system, and the [BarnOwl](https://barnowl.mit.edu/) client for it in particular. BarnOwl has a number of very nice features that make it easy to follow large amounts of zephyr traffic: search, color coding, auto-narrowing, etc. BarnOwl can also store logs of zephyrs sent and received for future reference, but the logs are saved separated by class in a way that's quite annoying to navigate sometimes. A BarnOwl-like interface (perhaps implemented as a BarnOwl plugin) for viewing zephyr logs would be a great thing to have.
 
 _Contact: oremanj_
 
 ## Multiple views in BarnOwl
 
-[BarnOwl](http://barnowl.mit.edu/) nominally has views support. However, it consists of verifying that the view name is "main" and returning an error otherwise. It would be nice to maintain multiple sets of view state at once. This would involve figuring out semantics, moving some data structures around, adding the new functionality, designing some interface, and probably much testing for subtle bugs.
+[BarnOwl](https://barnowl.mit.edu/) nominally has views support. However, it consists of verifying that the view name is "main" and returning an error otherwise. It would be nice to maintain multiple sets of view state at once. This would involve figuring out semantics, moving some data structures around, adding the new functionality, designing some interface, and probably much testing for subtle bugs.
 
 _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/).
+[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](https://gist.github.com/).
 
 *Note:* tvald has set up [etherpad.mit.edu](http://etherpad.mit.edu/).
 Coordinate with him if you'd like to get features into etherpad.mit.edu.
@@ -239,17 +239,17 @@ _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.
+* 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](https://debathena.mit.edu/trac/ticket/300).
+* OpenSSH has an option to enable [non-strict acceptor checking](https://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](https://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](https://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_
 
 ## Binary compatibility between OSes
 
 Help the cause of OS ecumenism! FreeBSD provides [binary
-compatibility](http://www.freebsd.org/doc/handbook/linuxemu.html) with
+compatibility](https://www.freebsd.org/doc/handbook/linuxemu.html) with
 Linux operating systems: an add-on module to the kernel knows how to
 interpret Linux-"personality" programs, just like the base kernel can
 interpret FreeBSD-"personality" ones, and a standard component in the
@@ -273,7 +273,7 @@ _Contact: zhangc, kasittig_
 
 ## Zephyr Client Hints
 
-Some time ago I wrote [a spec for zephyr client hints](http://geofft.mit.edu/p/zephyr-client-hints.txt), optional extensions that zephyr clients can easily implement to add nifty stuff like typing indicators and [preventing zwgc from starting more than once per user](http://debathena.mit.edu/trac/ticket/206) and such. I got lazy before actually implementing these specs, but I believe they'd be relatively easy extensions to both zwgc and BarnOwl (in their respective extension languages, even &mdash; no changes needed to core).
+Some time ago I wrote [a spec for zephyr client hints](http://geofft.mit.edu/p/zephyr-client-hints.txt), optional extensions that zephyr clients can easily implement to add nifty stuff like typing indicators and [preventing zwgc from starting more than once per user](https://debathena.mit.edu/trac/ticket/206) and such. I got lazy before actually implementing these specs, but I believe they'd be relatively easy extensions to both zwgc and BarnOwl (in their respective extension languages, even &mdash; no changes needed to core).
 
 _Contact: geofft_