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
You might also like to take a look about the general, future
roadmap and the
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
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
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
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.
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
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
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
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
Support for 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
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
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
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).
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?
- project title
- synopsis: a short description
- benefits for T2, and the Open-Source landscape
- qualification: e.g. 'ported T2 to ARM xy', 'T2 package maintainer',
'open source contribution to', ...
- project details: a more detailed description
- project schedule: How long will the project take? What are the milestones?
When can you begin work?