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.

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).

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.

Some notes can also be found in the refernce mailing list post.

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.

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.

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.

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.

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.

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.

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.

Implementing this functionality in T2 would mean basing on daily updated package meta-data repository with nearly 3000 packages.

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

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.

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).