Jacob Peddicord

Contact information

• Your Name: Jacob Peddicord

• Email Address: jpeddicord@ubuntu.com

• IRC nickname: jacob

• Launchpad ID: ~jpeddicord

• Skype username: jacobmp92 (largely unused)

• Jabber: jacobmp92@gmail.com

• Webpage/blog: http://jacob.peddicord.net/

• College-University: The Ohio State University

• Major: Computer Science & Engineering

Project

• Project Name: Upstart compatible services-admin

• Project Description:
  • The previous service administration tool was able to list available services and enable/disable them. I plan to create a new services tool from scratch with a few goals in mind:
    • Ease of use - it should display the necessities needed to manage services, while not getting too technical
      • (though some technical knowledge is assumed if a user is messing around with services)

    • Properly secured using PolicyKit

    • Compatibility with Upstart and old-style SysV scripts
    • Configurable - should be able to change properties of services and reload them
    • Package and Launchpad integration - provide methods to uninstall the services' package and to report a bug on it

If you would be willing and able to do other projects instead, which ones?

Clipboard improvements would be another idea that interests me, having been a victim of the "copy, close, paste, realize nothing happened" model.

Why did you like this idea?

Upstart has replaced nearly all of the old boot scripts from /etc/init.d with newer, more concise jobs in /etc/init. The syntax of these files is easy to read, but powerful. That's the same idea in mind here: there should be an easy to use but powerful tool around to manage both Upstart jobs and older SysV scripts. It seems like something that would complement Upstart nicely.

In addition, I'm a server administrator myself and have messed around with Upstart & boot scripts. I'd love to be able to bring this functionality to the desktop in the form of a nice interface.

Please describe a tentative project architecture or an approach to it

There are a few main components that make up this idea:

• Backends - One common internal API should be used for managing services. This could be accessed using PolicyKit. Two backends would then be used:

  • upstart - managed using dbus

  • sysv - managed via /etc/init.d/ scripts and the service command

• Management - Services should be able to:

  • be stopped & started

  • be restarted
  • change whether they run on boot
  • have their configuration reloaded (backend-dependent)
  • send other custom signals depending on the service
  • possible for a dependency tree to be calculated for upstart jobs
• Configuration - To configure service properties, I've thought of a few ideas. One that would most likely work out would include shipping configuration "description" files, either with this project or with service packages themselves. These files would include information on:
  • Variables available for configuration and their types
  • Possible values/constraints
  • Where the actual configuration file(s) is/are stored
  • What needs to happen once the configuration is changed (force-reload, restart, etc)
  • Possibility to launch an external application to configure a service (big maybe here)
• Package integration - Poll dpkg for information on which package owns a particular service
  • Provide an option to uninstall that package (via aptd or synaptic)

  • Ability to report a bug on that package for a specific service via apport & ubuntu-bug

Give us details about the milestones for this project

• First milestone
  • Interface skeleton should be designed
  • Upstart backend should be functioning
  • Services should be able to be disabled/enabled/stopped/started/restarted
• Second milestone (GSoC midpoint)
  • Basic configuration backend and UI in place
  • SysV backend should be functioning
  • Services should be able to be configured and reloaded
• Final milestone

  • Configuration UI & backend should be complete

  • Configuration descriptions for default system services should be available
  • Documentation should be available on how to ship a service configuration description
  • Package integration should be finished
  • Polish, polish, polish

Why will your proposal benefit Ubuntu?

Both Mac OS X and Windows offer system utilities to administer services. Ubuntu used to, though with a rather limited applet. Having a full-fledged but easy-to-use application to administer and configure services would greatly benefit the user experience. The use of a graphical application would free up the need to use the terminal to configure services. It would make configuration quicker and safer. Instead of needing to launch a root editor to change a setting, a user would only need to set some options in a PolicyKit-managed application. It would make Ubuntu look more friendly to both the tweaking end-user and to the enterprise market, since many businesses may want to be able to easily disable services and set policies on what can be run.

UI mockup

Open Source

Please describe any previous Open Source development experience

I've been submitting occasional patches to Ubuntu for a while, and somewhat more frequently work on bug management. I've created some projects of my own, including Commandeer and Mound, both of which I've received merge requests on and eventually plan on getting into the archives. I've already packaged gfire for the archives, and have worked on other packages as well.

Why are you interested in Open Source?

Who isn't interested in open source? Seriously, I've always been peeved by the fact that I have to pay to use the computer I bought, and I can't even change it. The open source community has always appealed to me, so much that a few of us have created a site called FOSSwire to write about it (though my activity there has declined lately as I've been involved in other areas). I love the fact that if I make a mistake or need help, there's a whole community of developers who know just what to do. I used to write closed-source applications on Windows years ago, and I can definitely say it is much more fun to stay open.

Availability

How long will the project take? When can you begin?

It will likely take the entire duration of GSoC. I know a good amount about GTK+ and Python programming, but I still will need to research methods of managing services, PolicyKit, and effective communication over DBus. I can begin as soon as the timeline allows. I will have two weeks of class and exams left on May 24, but that hasn't affected my development work in the past.

How much time do you expect to dedicate to this project? (weekly)

Considering I like to write code in my free time, I'd say a very good amount.

• Where will you based during the summer?
• Do you have any commitments for the summer? (holidays/work/summer courses)
• Please designate a back up student (in case you need to withdraw your application)

Other

• Have you ever participated in a previous GSoC? (describe your project)
• Have you applied for any other 2010 Summer of Code projects? If yes, which ones?
• Why did you apply for the Google Summer of Code ?
• Why did you choose Ubuntu as a mentoring organisation?
• Why do you want to participate and why should Ubuntu choose you?