Archive:GSOC ideas 2013

Jump to: navigation, search
Community> Google Summer of Code
[Guidelines] · [Project Ideas] · Proposal Template · Organization Application


This is a list of ideas for projects which could be done for openSUSE as part of the Google Summer of Code program. If you have an idea and want to mentor it, please add it it to the list. You might also find inspiration on the GSoC 2012 Ideas page or openFATE.

If you are a student and want to work on an idea, please submit a proposal. You are not limited to the ideas listed here. If you have an own idea or want to approach an idea in a completely different way, feel free to submit this as proposal as well. Sometimes these are the best projects. Creativity and initiative are highly appreciated.



General

CloudStack/Eucalyptus setup

  • Description: The openSUSE project provides the most choice in software stacks at many levels compared to other distributions. We would like to continue this "tradition" in the Cloud management infrastructure area. We already have OpenNebula and OpenStack. OpenNebula is the most complete offering with packages documentation and an appliance example. The OpenStack packages are building and the framework has been tested, yet we lack documentation around setup and configuration. For Eucalyptus and CloudStack our packages are way behind upstream and work is needed to move the packages forward. For both CloudStack and Eucalyptus the project includes everything from beginning to end until we have a presentable solution along the lines of the OpenNebula setup shown at https://en.opensuse.org/SDB:Cloud_OpenNebula
  • Mentor: Robert Schweikert
  • Skills: Packaging, Perl, Python, Java
  • Skill Level: Medium
  • Student: Scott DuBois (first), Sanidhya Kashyap (second), Kaan Özdinçer (third) interested


openSUSE News/Planet on Android

  • Description: openSUSE news and planet are a great source of information on what is happening in the project, and what the contributors are upto. It would be great to have an Android app, which would notify users about new posts on these platforms. There could also be an option to watch posts by specific authors, and view by languages. A good interface would be integral to the app.
  • Mentor:Manu Gupta
  • Skills: Android
  • Skill Level: Easy - Medium
  • Student: 3 students have expressed interests



Open Build Service

Port bento to twitter bootstrap

  • Description: The openSUSE bento theme was supposed to be the great UI unification of all our web-pages. But it only came so far as adding a unified theming and some UI elements, most notably the top bar. Nowadays there is a great collection of HTML UI "libs" like twitter bootstrap that achieve way more. If we could port bento over to bootstrap we would reach the initial goal we set out to reach. The mentors would prefer to use the Open Build Service (OBS) as reference implementation for this project.
  • Mentor: Henne Vogelsang, Stephan Kulow
  • Skills: HTML, CSS, Javascript, Ruby on Rails, GIT
  • Skill Level:Medium
  • Student:Lagakis Paraskevas(Interested)


Open Badges for the Open Build Service

  • Description: Mozilla has a nice badge system based on open standards and an open API. There are several opportunities to issue badges in the OBS that show packaging skills and distro management skills. The student would have to implement a badge issuer system like badges engine or similar in the OBS API/Webui
  • Mentor: Henne Vogelsang
  • Skills: HTML/CSS, Javascript, Ruby on Rails, GIT
  • Skill Level: Hard
  • Student: Scott DuBois (interested)


Discussion System for the Open Build Service

  • Description: There are a lot of "objects" like packages, projects, patches etc. in the Open Build Service that would greatly benefit from user feedback. The goal of this project is to add some way of discussing those objects in the OBS by means of either an external commenting system like juvia or by adding the functionality to the OBS objects directly.
  • Mentor: Henne Vogelsang, Stephan Kulow
  • Skills: HTML/CSS, Javascript, Ruby on Rails, GIT
  • Skill Level:Medium/Hard (depends on the implementation route)
  • Student:Shayon Mukherjee(Interested)


Windows support using NSIS and Nuget/Chocolatey

Bitbake support in Open Build Service

  • Description: Bitbake is a build system that allows to build packages easily for both rpm and deb based distributions. On top of it provides means for inheritance which makes packagers life even easier. Project goal is to add support for this kind of recipes into Open Build Service. It would require diving into internals of OBS on one hand, bitbake on the other and some basic understanding of how packaging works.
  • Mentor: Michal Hrusecky
  • Skills: Perl, Python, basics of packaging
  • Skill Level: Hard
  • Student: 赵旭


Cross-distribution topics

The openSUSE project is proudly pushing cross-distribution collaboration.

Code review for projects on GitHub

The goal of this project is to extend git-review to make code review on GitHub even simpler.

A lot of our projects have moved their code to GitHub. Using pull requests is a comfortable way to collaborate on projects hosted there and if done in a browser there is also a nice UI for it. However, since most developers use the command line for all of their git operations anyways, git-review was created to add some commands to git and thus enable developers to handle code review from the command line, too.

Goal of this project is to enable git-review to work on different forks of a project, use the latest GitHub API (v3), and add support for tools like Pullermann. For further information please take a look at the project's list of open issues.

Mentor: Dominik Bamberger

Required knowledge: Ruby, Git, RSpec

Skill Level: Medium

Student: Benoît Legat interested

Compositor Colour Management

Colour Management has to be easy for casual developers and automatic for users. To get there it is an good idea to have all applications colour corrected inside the window manager. On the other side graphics applications, want to do own colour management and should be able to say a window shall not be colour managed. To do so easily exists the X Color Management spec and the implementation of this protocol in libXcm.

The ICC based colour correction is easy for compositing window managers, as they support mostly shaders. Shaders run on the GPU and allow for a very fast and efficient colour correction.

The project targets at providing colour management inside a compositing window manager of your choice. The protocol part to be implemented is the Baseline spec with _ICC_COLOR_REGIONS and additional the _ICC_COLOR_PROFILES atom.

This implementation prepared a easy transition into Wayland compositor colour management, which will as well be window based.

Required knowledge: OpenGL, GPU shaders, Oyranos, C

Skill level: intermediate

Mentor: Kai-Uwe Behrmann + someone from the according WM project

Student: STUDENT NEEDED.

Gtk Front End to Oyranos

The Oyranos project is a cross desktop and cross OS colour management system (CMS) to provide easy to use and while robust colour management services to applications. The main goal of Oyranos is to provide colour management without user interaction. But in some situations and especially experts might want to configure and tweak the various settings manually.

Front ends exist in Qt and for KDE. For Gtk based Desktop Environments it is currently only possible to use the Qt front end. For a better appearance and integration it makes sense to provide a native Gtk GUI for settings and configuration.

Required knowledge: Gtk, Oyranos, C, good communication

Skill level: intermediate

Mentor: Kai-Uwe Behrmann

Student: STUDENT NEEDED.

OpenICC Colour Configuration Data Base

Users, who configure their colour management system (CMS) behaviour and devices, want to share these settings on one host without any intervention among installed CMSes. The project will introduce the OpenICC data base into CMSes like ArgyllCMS, Oyranos and colord and replaces existing own DB access code.

device DB example: http://www.freedesktop.org/wiki/Specifications/icc_meta_tag_for_monitor_profiles

existing code: http://openicc.git.sourceforge.net/git/gitweb.cgi?p=openicc/openicc;a=tree

Required knowledge: C, good communication

Skill level: intermediate

Mentor: Kai-Uwe Behrmann

Student: STUDENT NEEDED.

Links:

AppArmor profile development tool

The AppArmor project is a MAC like security extension for Linux. Its policy is based around profiles that are used to define the set of permission an application will be granted.

The project goal is to implement a new smarter profile development tool, that is better at creating abstractions, and inter-profile policy analysis.

The base part of the project will be to implement a library and basic tool using the library that can develop a profile from audit log files, and basic user interaction. This tool will replace the existing aa-logprof and aa-genprof tools, which are unmaintained and out of date.

The remainder of the project will be to extend the base library and tool, in any of several possible directions:

  • doing analysis on the interaction of rules within a profile as well as how profiles interact. This can be used to simplify rules, suggest simplifications or abstrations, and discover potential security holes in the provided policy.
  • doing static analysis on applications to extract possible rules and rule patterns. This can be used to preseed profile development by feeding the output into the base part of the project, and find program behavior that may not be discovered by standard execution on an application.
  • creating a tool to merge multiple profiles together. Working similar to logprof, but using profiles instead of a log as input.
  • developing a better interface that will aid the user in being able to find abstractions, and analyze inter-profile behavior.
  • update the existing YaST module to interface with the new profile development tool.

Required knowledge: Python

Helpful knowledge: C and Perl as some components are written in these languages, YCP (if the student decides to update the YaST module), some knowledge of Perl would be good but is not required

Skill Level: Intermediate - Hard (depends on implementation route)

Mentors: John Johansen, Christian Boltz

Student: Kshitij Gupta(Interested)


Wayland Input method protocol support for Fcitx

  • Description:

The fcitx is a cross desktop input method framework, aim to provide native support for different desktop/environment.

Input method communicates with application via some IPC protocol. In wayland, input method need to talk with client （a.k. application) by input method protocol provided by wayland. As for application changes need to be done on toolkit side, while similar changes also need to be done on the input method framework side to support international character typing under wayland.

Required knowledge: wayland, C

System Management

Automatic resizing of LVM volumes and filesystems

openSUSE currently provides good support for creating LVM volumes and installing the OS on these volumes. However, if the filesystem becomes full, the user/administrator has to increase the volume size and contained filesystem capacity manually.

The goal of this project would be to implement automatic resizing of LVM volumes and contained filesystems. This resizing would be triggered e.g. by the package manager before installing the packages, if the free space drops before certain threshold etc. The installer should be modified to compute the necessary space needed for installing the selected set of packages and allocate the LVM volumes 'just big enough' for the installation. With future automatic resizing of the LVM/FS, this would save storage capacity in the volume group which would otherwise be unnecessarily allocated for /, /usr etc.

Required knowledge: At least basic experience with C/C++, RPM, scripting (Python, bash). Understanding of LVM is a plus, but not necessary. Willingness to learn and investigate is a must.

Skill level: Intermediate

Mentor: Dinar Valeev

Student: (Interested) Akif KhanAyush Agrawal Veselin Baliyski

Virtualization

Improve libxenlight driver in libvirt

The upstream xen project has slowly developed a replacement for the aging xm/xend toolstack called libxenlight (or libxl). In Xen 4.2, the libxenlight toolstack reached sufficient maturity to become the default toolstack, and the legacy xm/xend toostack was marked deprecated and will be completely removed in a future xen release. Since the inception of libvirt, it has supported the legacy xen toolstack. libvirt 1.0.1 introduced support for the Xen 4.2 libxenlight toolstack, but this driver (referred to as the libvirt libxl driver) is missing several features wrt the legacy xen driver.

The goal of this project is to improve feature parity between the legacy xen driver and the new libxl driver. Some examples include support for migration, PCI passthrough, SMBIOS information, and lock manager integration.

Mentor: Jim Fehlig

Required knowledge: C

Skill Level: Medium

Student: (Interested) Braydn Clark


ownCloud

Mobile app that syncs with ownCloud News app

  • Description:

The News app is an atom/rss reader app that will be shipped with ownCloud 6. The app was developed as a GSoC 2012 project. The app now exposes an API, which can be used to synchronize external stand-alone readers with the app.

API specification will be documented on time before GSoC starts.

The project consists of designing, building and testing an rss feed reader for a mobile platform that uses this API and so synchronizes with the ownCloud News app.

Platform suggested are Firefox OS (http://www.mozilla.org/en-US/firefox/partners/#os) or Phonegap (http://phonegap.com/). The student is strongly encouraged to discuss the platform and the details of the project with the mentors before submitting the project proposal.

  • Mentors:
Lead Mentor: Alessandro Cosentino <cosenal at gmail dot com>
Alternative Mentor: Bernhard Posselt <nukeawhale at gmail dot com>
  • Contacts: zimba12 and Raydiation on #owncloud-dev, Freenode
  • Skills: (depdending on the chosen platform) At least basic knowledge of: JS, CSS, HTML. Previous experience with programming for mobile platforms is recommended

Map application for ownCloud

  • Description:

The project consists of designing, building and testing map application for ownCloud.

Based on the appframework provided by ownCloud, the student will develop an application that provides simple features like adding / editing a point and a set of points (route).

The student will have to integrate the app with other ownCloud apps, such as:

  • Contacts (show contacts on a map, display a map when want to localize a contact)
  • Calendar (show events)
  • ownPrey (device tracking)
  • Pictures (geolocation of pictures)

If the student have time, he will design and implement a HTTP API to export / import object from external applications like Marble (the student will have to coordinate with marble GSoC project at KDE side for this part).

Leaflet, angularJS and doctrine can be use to make this app.

  • Mentors:
Lead Mentor: Brice Maron <merzhin __ At __ gmail.com>
Alternative Mentors: Bernhard Posselt <nukeawhale at gmail dot com>, Jan-Christoph Borchardt <hey at jancborchardt dot net>
  • Contacts: eMerzh and Raydiation on #owncloud-dev, Freenode or email address as XMPP
  • Skills: At least basic knowledge of: JS, CSS, HTML. Experience with leaflet and or angular is a plus


Forwarding the ownCloud core design

  • Description:

The project will be to conceive, design, implement and test improvements for interaction and interface of three key aspects in ownCloud:

These three aspects will allow the student to explore how to design interfaces for different target groups (users as well as admins) while keeping the design concise and consistent. We will go through the whole design cycle, from discussing the concepts, sketching mockups, to implementing everything in HTML, CSS and JavaScript, continuously conducting small user tests to validate the changes and gather feedback.

  • Mentors:
Lead Mentor: Jan-Christoph Borchardt <hey at jancborchardt dot net>
Alternative Mentor: Bernhard Posselt <nukeawhale at gmail dot com>
  • Contacts: jancborchardt and Raydiation on #owncloud-dev, Freenode
  • Skills: Knowledge of interface+interaction design, HTML, CSS, basic Javascript & jQuery


Shiva integration for ownCloud / media app replacement

  • Description:

OwnCloud is based upon open protocols like WebDav, CalDav and CardDav. Shiva (https://github.com/tooxie/shiva-server#resources) is a RESTful API designed for interaction with music libraries. This project consists of both an implementation of a shiva server in ownCloud and an ownCloud media app to use the provided data.

This should cover several things:

  • implementation of the API (maybe based on data provided by current "media app")
  • provide a client (maybe use shiva-client (https://github.com/tooxie/shiva-client) or implement one)
  • full replacement for current "media app" is preferable
  • Mentor:: Jörn Friedrich Dreyer <jfd at owncloud.com>
  • Contacts: butonic on #owncloud-dev, Freenode
  • Skills: Basic knowledge of: JS, CSS, HTML, PHP.
  • Student: Morris Jobke

syslog-ng

A dedicated MySQL destination

The goal of the project would be to set the stage for a libdbi-less SQL destination, focusing on MySQL for a start. The idea is to implement a destination that does not have any of the drawbacks of the libdbi-based solution, and brings a lot of good things instead, such as better performance, support for value-pairs (and optionally type-hinting), and making it much easier to extend the driver to use more efficient methods than transactioned INSERT statements.

An overhaul of the SQL destination has been in the roadmap for a long, long time, this GSoC project is the first step in that direction, with a strong possibility of further involvement in syslog-ng development.

  • Proposed by: Gergely Nagy

Deliverables of the project:

  • A basic driver that can store logs in MySQL...
  • ...with support for authentication and database selection
  • ...with support for transactions
  • ...with support for templatable table names, and automatic table & index creation
  • ...with support for value-pairs()
  • Higher speed than the existing libdbi-based solution
  • If type hinting lands in syslog-ng mainline during GSoC, then support for type hinting would become an optional goal, if time permits

Desirable skills:

  • Familiarity with syslog-ng on at least a strong user level
  • Familiarity with MySQL on a simple user level
  • Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
  • Prior knowledge of the syslog-ng code base is recommended, but not required

What the student will learn:

  • Working with an existing, well-established software project
  • Simple, but efficient multi-threaded programming in C
  • How to use the mysql C client library
  • How to store data in SQL efficiently
  • Basic Bison & Flex skills, an intro into writing parsers and grammars

Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.

Redis destination

The goal of the project is to develop a new syslog-ng destination plugin, one that can add or change data in redis. Unlike most other destinations, the primary objective is not log storage (though that should be possible and supported aswell), but real-time counters, statistics, or in other cases, caching. This would open up a whole new field where syslog-ng can be used, and would make it much easier to collect log statistics, as the collection can be combined with the log processing power of syslog-ng.

  • Proposed by: Gergely Nagy
  • Mentor: Gergely Nagy
  • Student: Tihamer Petrovics

Deliverables of the project:

  • A new syslog-ng destination driver that interfaces with Redis
  • ...with support for MULTI & EXEC -based transactions
  • ...supporting customisable, complex commands (such as a combination of INCR, LSET, and so on, within a single transaction, or one after another)
  • Documentation, both a HOWTO, and a few example use-cases
  • If type hinting lands in syslog-ng mainline during GSoC, then support for type hinting would become an optional goal, if time permits

Desirable skills:

  • Familiarity with syslog-ng on at least a strong user level
  • Familiarity with redis on a simple user level
  • Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
  • Prior knowledge of the syslog-ng code base is recommended, but not required

What the student will learn:

  • Working with an existing, well-established software project
  • Simple, but efficient multi-threaded programming in C
  • How to use the hiredis client library
  • Use-cases for redis
  • Basic Bison & Flex skills, an intro into writing parsers and grammars

Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.

XMPP destination for syslog-ng

The goal of this project is to deliver an XMPP destination, which can push log messages to an XMPP server as XMPP messages. Either simple messsage push, with configurable node, jid, password, and destination jid, or publish/subscribe model should be supported.

  • Proposed by: Viktor Tusa
  • Mentor: Viktor Tusa (co-mentor Gergely Nagy)

Deliverables of the project:

  • A simple XMPP destination, able to communicate with an XMPP server, and deliver messages.
  • Simple message push model, or publish subscribe model.
  • Code flexible enough to support the other model later, or at worst, code that is easy enough to adapt and improve upon

Desirable skills:

  • Familiarity with syslog-ng on at least a strong user level
  • Stable knowledge of XML
  • Familiarity with at least one IM protocols.
  • Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
  • Prior knowledge of the syslog-ng code base is recommended, but not required

What the student will learn:

  • Working with an existing, well-established software project
  • Simple, but efficient multi-threaded programming in C
  • XMPP protocol knowledge, and Instant Messaging systems model.
  • Basic Bison & Flex skills, an intro into writing parsers and grammars

Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.

Log signing mechanism

The goal of the project is the development of a library offering a signing mechanism for the log entries that could assist in the reliable use of log files either for internal verification by the system administrators or in their use as forensic evidence. Althouth log files can be used to reveal malicious or abnormal activities, the grade up to which the integrity of their contents can be guaranteed is under question because they are one of the first targets of attackers. Hence, additional cryptographic mechanisms have to be embedded to enhance their validity. This project will focus on integrity checks by using Message Authentication Codes in combination with a hash chain scheme that provides a consecutive correlation between each subsequent entry with its previous one. Such proposals are documented in `[1]` and `[2]`.

Other papers have also been published but to the best of our knowledge, no such mechanism is added to any widely used open source logging system. This GSoC project can generate the workground to the direction of secure logging since further additions can be made to extend their protection with syslog-ng as its benchmark.

  • Proposed by: Christos Tsopokis

Deliverables of the project:

  • A mechanism signing regular log files in the above mentioned fashion...
  • ...with the ability to check log files' consistency once they are opened
  • ...with the ability to verify violation of messages generated before an intrusion takes place
  • ...with the ability to report detected discrepancies in the predefined log files
  • ...with the ability to report tactful files in the predefined log files
  • ...with support to easily extend the available hashing algorithms
  • Low computational overhead compared to current syslog-ng performance
  • If time permits the ability to adopt a flexible attaching scheme for the log stamps of each entry specified by the user through the configuration file

Desirable skills:

  • Familiarity with syslog-ng on at least a strong user level
  • Familiarity with openssh library on a simple programming level
  • Familiarity with the C language (deep knowledge not required, but C coding experience is strongly recommended)
  • Prior knowledge of the syslog-ng code base is recommended, but not required

What the student will learn:

  • Working with an existing, well-established software project
  • How to shield and add value to the content of generated log files
  • How to embed cryptographic primitives in a logging service reliably

Communication & Code repository: The syslog-ng OSE mailing list will be used for communication, and GitHub for code hosting.

`[1]` Bruce Schneier and John Kelsey. 1999. Secure audit logs to support computer forensics. _ACM Trans. Inf. Syst. Secur. 2, 2 (May 1999)_, 159-176. DOI=10.1145/317087.317089 http://doi.acm.org/10.1145/317087.317089

`[2]` Jason E. Holt. 2006. Logcrypt: forward security and public verification for secure audit logs. In _Proceedings of the 2006 Australasian workshops on Grid computing and e-research - Volume 54 (ACSW Frontiers '06)_, Rajkumar Buyya, Tianchi Ma, Rei Safavi-Naini, Chris Steketee, and Willy Susilo (Eds.), Vol. 54. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 203-211.

Hedgewars

Hedgewars - Add more AI to the game

  • Description: Even though computers are generally labeled as "stupid", there's always room for improvement! Let's teach AI teams how to properly use weapons so that single play can become as fun as network play. As well as weapons, the AI could be taught of:
i. Movement (teleportation, saucer, parachute, rope);
ii. Effective use of utilities (vampirism, invulnerability, extra damage etc);
iii. Thinking when not his turn;
iv. Increase AI threading to make better use of multiprocessor.
  • Mentor: unc0rr, sheepluva or nemo (#hedgewars)
  • Skills: Pascal, AI
  • Skill Level: Hard
  • Student:

GL-ES 2 + WebGL (take two)

  • Description: We have an experimental branch that uses OpenGL-ES 2 and was once able to compile all the engine in a pure HTML5/WebGL version! It is not complete and doesn't have all the new juicy stuff of the main branch. For this project you'll resurrect the code and maintain the branch for some time. You should also merge and complete the texture atlas and batching work, do some code cleaning, and add online play over WebSockets.
  • Mentor: nemo or koda (#hedgewars)
  • Skills: HTML5 APIs, JavaScript, Pascal, OpenGL-ES2, (optional) Haskell
  • Skill Level: Hard
  • Student:

Test framework

  • Description: After reaching the n-th line of code, you often start wondering if what you wrote actually works. This project involves creating a test framework from scratch triggering all possible values for the most important sections of the game. Using CTest would be preferred as it would integrate perfectly in our build system. In addition we'd like to have automated testing w/ buildbot and some visual test report. Ideally the bot should also run test games to verify play. Since the code is lightly documented, the student will need to familiarise themselves with the codebase and document what they learn.
  • Mentor: unc0rr, sheepluva or koda (#hedgewars)
  • Skills: Pascal, CTest, Documentation, Testing automation
  • Skill Level: Medium
  • Student:

Sequel for "Mission Campaign"

  • Description: Our campaign and our training system just received some love, but it's never enough! For this project you should design another adventure from scratch and implement it with lua scripts; alternatively you could think of a simple training system that teaches the basics of the game. We have a lot of examples to learn from! Also a small section of the GUI should be updated to reflect this new adventure.
  • Skills: Pascal, Lua, C++, Game design
  • Mentor: mikade or nemo (#hedgewars or email)
  • Skill Level: Easy
  • Student:

One common GUI

  • Description: It'd be nice to have a common graphical user interface for all our platforms! We currently run on Windows, OS X (three archs), Linux (all archs), Android (arm), iOS (all archs) and HTML5 and currently only three platform share common frontend code. That's too little and we need some abstraction between all of them. Maybe an HTML/JS SDK could provide some high level tools that we could go with or Qt5 might be enough to bring the desktop frontend to the mobile platforms. In any way a lot of the GUI should be tailored for different screen resolution and take advantage of any platform specifics (as well as follow the DE rules).
  • Skills: GUI desing, C++, HTML, Javascript
  • Mentor: unc0rr, koda, sheepluva, or medo42 (#hedgewars)
  • Skill Level: Medium
Retrieved from "https://en.opensuse.org/index.php?title=Archive:GSOC_ideas_2013&oldid=66373"