Google Summer of Code

Google is organizing a fantastic opportunity for students to help out with FLOSS development this summer, and get paid for doing it. More information is available on their site.

We're looking for enthusiastic people to work on specific projects, which are listed on this projects page (see below). You don't necessarily need lots of experience or be a PhD candidate.

Want to do your own project idea? Cool... Just let us know.

You might also like to take a look about the general, future roadmap and the Issue tracker.

LLVM integration
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.

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

Build as non-root
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.

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

Ready targets for cluster use
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.