Integrate the LLVM, Low Level Virtual Machine,
to act as an additional, optional compiler that can potentially build many
packages to run on any target CPU, like a "universal binary" (bytecode)
Linux distribution where only the kernel and LLVM would need to be ported
for each new CPU and all application binaries being compiled and optimized
just-in-time.

Dynamic package dependency scheduling and cost model

Altough the T2 sandbox tracks build dependencies and caches the resulting
data in reference builds, they are not yet used to schedule the packages
dynamically. The task would be to use this information, and dynamically
schedule the packages and remove the current static build priority tag.

Additionally parallel compilation of the packages on a single machine or
a grid should be implemented taking the cached build-time "cost" into account
in the scheduler for optimal load cross the "nodes" (grid or multi-cpu
systems).

Generic and flexible multilib support

Currently all T2 packages are built against the system C library. Only
dietlibc has special code to select building some packages against
dietlibc and some architectures (notably sparc64 with 32bit user-space)
contain custom code to build some vital system libraries additionally for
64bit.

The task would be to impement and test a generic "mulitplexer" in the
build system to allow building any package for a variety of multilib
combination. That can be just 32 and 64bit for some basic system libraries,
but also be FP(floating point), no-FP for embedded boards, or just be building
a system C library version of a package that otherwise is statically linked
with dietlibc due inclusion in the initial ramfs (initramfs) such as udev.

Currently building a T2 based system has to be done as root user due to
the chroot sandbox setup and archiving special file permissions. Facilities
such as "fakeroot" could
be added or implemented to allow cross-building embedded system as Jane Doe.

Remote package distribution using binary diffs

To save bandwidth and time updating system using binary deltas is
stage of the art. Support for the vanilla tarballs as used by T2
and other projects would be a benefit for all of us.

Support for the Minix3 microkernel

Minix 3 is a tiny microkernel
with self healing capability. Because of the microkernel architecture
and it's size Minix 3 can be of interested e.g. for embedded use.

The task would envolve to split the Minix3 microkernel into well
defined modules that can be integrated for cross compilation with T2.
The task would likely envolve digging deep into the internals of
Minix3 and either package the C compiler used or port assembly
chunks to GCC.

Support for GNU/Hurd

GNU/Hurd is the
long envolving GNU operating-system. Integration for cross compiling
the GNU/Hurd kernel could give it a refreshing spin to allow clean
and automatic compilation and thus attract more people to use and work
on GNU/Hurd.

Support for OpenBSD

OpenBSD is the operating-system
famous for it's in-depth security review. Due to this property it's of
interest in embedded network appliances as well as server systems and
integration support for building OpenBSD kernel based system would make
creating those products easier.

Support for Haiku

Haiku is an open-source implementation
of the BeOS operating-system famous for it's multimedia capabilities,
speed and usability.

The individual source modules of Haiku could be integrated to allow
creating Haiku OS images with T2.

Non-system builds, e.g. Mac OS X and Sun Solaris

Implement support to build into foreign OS where the whole system
build can not build the OS kernel.

Although the whole OS can not be build from scratch T2 would still
simplify installing open-source components in the way of
Fink for OS X or what
Autopackage wanted to archive.

Add the packages such as OpenMosix
or OpenSSI and the surrounding
configuration and target setup for cluster deployment.

Create new targets for handheld - PDA or Cellphone - systems

Add the missing packages and kernel patches as well as pre-configuration
to build systems exactly suitable for commercial real-world PDA and
cell-phone hardware. A recent candidate might be the recent FIC Neo1973
cellphone.

Integrate Scratchbox a-like functinoality

The Scratchbx project allows
compilation of sources that are not yet cross compile aware by off-loading
running the resulting native binaries (of configure runs or helper tools
etc.) to the real CPU or an emulator (such as Qemu). By doing so in theory
all source packages can be cross compiled instead of modifing the packages'
build system to be clean for cross compilation.

Either Scratchbox as it - or simillar functionality - would allow T2
to instantly cross build more packages until they are fixed to cross build
(after all real cross builds are still preferable as no emulator or hardware
needs to be available and also proceed faster).

Application template

Here we compiled some suggestions what kind of information we would find useful to
receive from the students: Remember - you are going to commit to several months' of
work. The more information and planning you can provide initially, the more we and Google
will have to rank your application.

name, email - how and where can we contact you

background: something about yourself: technical skills, experience, etc.
Who are you? What makes you the best person to work on this project?