Tales of software craftsmanship

Tales of software craftsmanship

Calamares 2.3 out now

I’ve just released Calamares 2.3, a feature release with a major focus on disk encryption support (see full release announcement).

Calamares is a distribution-agnostic system installer, with an advanced partitioning feature and support for third party branding and modules. It is used by several distributions, including Netrunner, Manjaro, Tanglu, OpenMandriva, KaOS, Chakra and many others.

Calamares 2.3 leverages the LUKS functionality Andrius Štikonas and I had previously developed for KPMcore and KDE Partition Manager, and integrates it with sensible guesswork and a usable installer UI. Calamares 2.3 also sets up early decryption from within GRUB, and resuming from suspend-to-disk with an encrypted swap partition.

Interested in deploying Calamares on your own Linux distribution? Check out the new Calamares wiki with up to date deployment advice for Calamares 2.3, or drop by #calamares on Freenode.

How to write a kick-ass proposal for Google Summer of Code

In a few weeks students can begin submitting their applications for Google Summer of Code 2016.

KDE has been accepted as a mentoring organization again this year, and I’ve already been contacted by several students looking to do a Google Summer of Code project with KDE. Prospective Summer of Code students usually have lots of enthusiasm, and they often write great proposals with little or no help, but sometimes these proposals lack key information.

I’ve seen my share of good and bad proposals. I’ve been a Google Summer of Code student with KDE three times (four if you count Summer of KDE) so I’ve been in the very situation prospective Summer of Code students find themselves right now. I’ve also been on the other side of the fence: I have been a Google Summer of Code and Google Code-In mentor (and organization administrator) and I’ve been working as a software engineering instructor (since 2008), so I like to think I can relate with both students and mentors in this case.

This post is for students who wish to take part in Google Summer of Code.

Google Summer of Code is a kind of like a scholarship program, and a very competitive one: if you get picked, you’re one of just a thousand students in the world (about 1300 last year, 36 of those with KDE) who get to spend their summer hacking on open source software while learning from the very best software craftspeople, and get paid for it too. In order to achieve that, you need to submit an application to Google. An application is essentially a bunch of information you enter in a form, the most important part of it is your proposal.

A Google Summer of Code proposal is a document, it can be rich text but it’s best to consider it plain text because the web application that handles proposal only has basic formatting features.

The KDE community maintains a wiki page specifically targeted at Summer of Code students with very useful information on how to get started. Read it. Really, read it, please. Yes, all of it. Done? Great! Assuming you’ve gone through points 1-3 of the Recommended steps list, it’s time to prepare your proposal.

Writing a good proposal is not easy, especially if you’re a student making first contact with an organization: in this case your proposal is your best advertisement. You have to convince the organization (or at least some key people inside it) why you of all people are the right person for the job. What follows applies to KDE, but it should work for other organizations as well.

I used to structure my proposals the following way (worked well 3 times). This is not a hard rule. You can structure your proposal otherwise, but I think this is a good guideline if you need some inspiration:

  1. Introduction. Your software project should solve a clearly defined problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What is the current state of things? What issue do you wish to solve and why? Then you should conclude with a sentence or two about your solution. This is somewhat like an elevator pitch.
  2. Project goals. This section should again be short and to the point, and it might be a good idea to format it like a list. You should propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the three months of the Google Summer of Code season is what counts. It is better to promise less and deliver more than to promise a lot and then fall short. At this point you are making a commitment, and should your proposal be accepted, your mentor will evaluate your progress through these deliverables  (and other factors).
  3. Implementation. This section can be longer and more detailed. You should describe your plans as a solution for the problem you defined earlier. You don’t need to provide a lot of technical details, but you do need to show that you understand the technology and illustrate key technical elements of your proposed solution in reasonable detail.
  4. Timeline. This section is easily overlooked, yet it’s arguably more important than the previous section. With the timeline section you show that you understand the problem, that you have thought hard about a solution, and that you have also broken the solution down into manageable bits. If your timeline is reasonable and its deadlines achievable, you show that you have an actual path in mind that would take you from idea to delivery. With this section you set expectations, so do not make promises you cannot keep. A humble, realistic and detailed timeline is much better than a timeline that promises to move mountains. Google has selected the very best open source organizations in the world to take part in Google Summer of Code, and the mentors in these organizations are often the top professionals in their respective fields. Mentors can easily spot unrealistic timelines. Be upfront about other commitments during the season’s coding period, including but not limited to: exams, classes, travel and vacation days, internships, jobs, volunteer work, etc.
  5. About me. If you’re done with the other sections this will be a piece of cake. Just put down your contact information and write a few sentences about you and why you think you’re the best for this job. It’s ok to brag a little. If you’ve already done some open source work, don’t forget to include links.

Proofread your proposal. We get that English may not be your first language, and nobody will reject an otherwise good proposal just for a few spelling mistakes, but please check your punctuation and use a spellchecker. A proposal with too many spelling and punctuation mistakes can be hard to read and looks sloppy. With your proposal you want to present yourself as the opposite of sloppy.

Submit your proposal early, keep it short but include all the necessary information. Get it reviewed by the right people in the organization, well before submitting it to the Google Summer of Code web application. As far as KDE is concerned, you should submit your proposal to the developers mailing list of the relevant subproject as published on the ideas page. I can’t stress this enough: get feedback. Organizations want good proposals and good students, and are usually eager to help you improve your proposal. Just write a brief and informal email, attach your proposal and ask for feedback.

I hope this advice proves useful. We have also gathered some accepted proposals from past years, you might find them useful as inspiration.

You can submit more than one proposal to the same organization or different organizations to increase your chances, but my advice is to not overdo it: quality is better than quantity.

Good luck!

Code all the summer

Calamares 2.0 is out

The Calamares team is proud to announce the immediate availability of Calamares 2.0, a major release that brings countless new features and improvements over the 1.1 series. Calamares is a distribution-independent system installer. After almost five months of intense development since the last maintenance release, Calamares 2.0 is a user ready product.

Highlights of this release include:

  • thoroughly rewritten partitioning feature, now based on KPMcore (the same library used by KDE Partition Manager);
  • overhauled modules system, allowing for much more flexibility in configuring and arranging views and jobs;
  • support for post-install mode, which turns Calamares into a first run configuration tool;
  • improvements in many modules, including locale, bootloader and displaymanager.

Get it from our release announcement or find it soon as the system installer in one of our downstreams.

Sometimes you need to reinvent the wheel

On behalf of the Calamares team and Blue Systems, I am proud to announce the immediate availability of Calamares 1.0.

Calamares is a distribution independent installer framework. I had the initial idea for Calamares in May 2014, less than a year ago, and out of frustration: many successful independent Linux distributions came with lackluster installers, and all of these installers were a result of competition rather than cooperation. Improving one of the existing installers wouldn’t have fixed this, as every installer was more or less distribution specific. I wanted to create a product that would satisfy the requirements of most Linux distributions, developed as an upstream project for all of them.

Everything went better than expected.

With support from Blue Systems and some help from Aurélien Gâteau I started from scratch around June 2014, with a highly modular design and some valuable contributions from KaOS, Manjaro, Maui and Netrunner developers. Contributors from Fedora, BBQLinux, OpenMandriva and the KDE Visual Design Group joined in afterwards. Now, a little over half a year of design and development frenzy later, we choose to call it 1.0. While there is still room for improvement, we have decided that the first development iteration is done, and we are presenting a modest yet feature-complete product.

Calamares is built with Qt 5, C++11, Boost.Python, (bits of) KDE Frameworks 5 and KDE Partition Manager.

Feature highlights include:

  • a completely modular design, with three plugin interfaces: C++, Python and generic process;
  • a threaded job executor, with C++ and Python API;
  • a collection of over 25 modules, ranging from boot loader support to partitioning, to user management and much more, with the opportunity of deploying your own;
  • a self-contained branding component mechanism, which allows distributions to ship a consistent user experience without patching;
  • an advanced partitioning tool, with automation and resize functionality and both DOS and GPT partition table support.

The Calamares team hangs out in #calamares on Freenode, feel free to drop by.

Bugs should be reported to our issue tracker, and pull requests go to GitHub.

KDE accepted for Google Summer of Code 2013

Google Summer of Code 2013

I’m happy to announce that KDE has been accepted as a mentoring organization in Google Summer of Code 2013. This is our 9th consecutive year. Congrats to all accepted organizations, and a big thanks to everyone who helped to make this happen for KDE!

This year KDE will also participate in the Free and Open Source Outreach Program for Women, an internship opportunity running almost simultaneously with Google Summer of Code, from June to September. Please note that while the Outreach Program for Women shares many goals and methods with Google Summer of Code, the two programs are not related. Unlike Google Summer of Code, the Outreach Program for Women also allows non-coding contributions. For more information about applying, see KDE’s Outreach Program for Women wiki page.

KDE will also be hosting Season of KDE 2013, with more information to come in the following weeks. Season of KDE is expected to start later in the summer, around the Google Summer of Code midterm.

Students. Now that you have a list of accepted organizations, it’s time to start working on your proposal. The KDE community maintains an ideas page which is an excellent starting point, and don’t forget to check our student guidelines. Also, last year I published an article with some tips on how to structure your proposal, you might find it useful.

You can come up with your own idea or base your proposal on something from the ideas page, but either way it’s very important that you get feedback from the team you wish to work with well before the submissions deadline. If you have general questions about getting involved with KDE as a Google Summer of Code student you’re welcome to ask on our IRC channel #kde-soc on Freenode, or join the mailing list kde-soc@kde.org. For questions about a specific idea please contact the relevant team (subproject) directly.

Finally, make sure to keep an eye on the official Google Summer of Code timeline – those deadlines are always closer than they seem 😉

Mentors. Now that we know that KDE has been accepted, it’s time to get ready to mentor some students. If you wish to be a mentor your next steps should be:

  1. subscribe to kde-soc-mentor@kde.org,
  2. sign up on http://www.google-melange.com and apply as a mentor for KDE,
  3. contact one of the admins to approve your requests.

For questions you can reach the admin team in #kde-soc on Freenode or at kde-soc-mentor-owner@kde.org.

And most importantly, in the following weeks you’ll be contacted by prospective students with questions and feedback requests for their proposals. It might take a bit of time and you might get questions with very obvious answers. Please be patient and keep an eye on the timeline 😉


Google Code-In is on!

Google Code-In began today, November 26th 2012, precisely at 17:00 UTC.

The KDE Community is proud to take part once again in this great program. Find out more about Google Code-In and the other accepted organizations in the announcement.

On the KDE side, tasks have been collected, mentors are signed up, and we are ready to go!

For any question or problem mentors and students are welcome to ask in #kde-soc on irc.freenode.net.

Good luck and most importantly, have fun!

Attention prospective mentors: Google Code-in tasks needed!

Good news for the Free Software community: Google Code-in 2012 has recently been announced.

Google Code-in is in some ways the pre-university counterpart of Google Summer of Code, and KDE has has been a very successful mentoring organization since its first edition in 2010. Needless to say, we are applying to be a mentoring organization again this year.

If you are a prospective Code-in student, stay tuned – mentoring organizations have not been selected so we have no news for you yet. If we get accepted, we’ll be delighted to mentor you.

If you are a prospective Code-in mentor, please read on 🙂

The KDE student programs team has already applied on behalf of KDE, but to be successful we now need to add as many tasks as we can think of to the Google Code-in 2012 Ideas page in the KDE community wiki.

Most importantly, please only add tasks you are willing and available to mentor. Mentoring Google Code-in students is a very rewarding activity, but it takes a fair bit of patience and dedication.

A few things to keep in mind.

  • Google Code-in is not just about code. We also need other tasks (likely even more than coding tasks).
  • We need at least 5 tasks in each category to qualify.
  • A task should take a normal KDE contributor about 2 hours. This is a guideline for you, to give you some idea of how much work a task should be. The actual time needed for students to complete a task can vary greatly. If you have doubts/questions feel free to ask the student programs team (teo- or Nightrose on #kde-soc).
  • Unlike the previous years, there are no translation tasks.
  • There is no distinction between easy/normal/hard tasks – while difficulty will of course vary between tasks, all tasks are treated the same.
  • The mentoring organization gets to choose 2 grand-prize winners among our best students. This means students are much more likely to stick with one org throughout the Code-in season than in previous editions.
  • The students don’t get money for each task. They get a Code-in t-shirt after clearing at least three tasks, and they compete for the grand prizes.
  • Google expects a turnaround time on tasks of less than 36 hours, but we should try to get to less than 24 hours if at all possible.
  • Check the timeline. If you are not available to approve and review tasks for some of that time please add that to the task description.

Our tasks list must be finished by November 5th, but please submit your tasks as early as possible.

Season of KDE: help wanted!

Last weekend, after countless emails and weeks of digging through a huge Google spreadsheet, I have finalized Season of KDE selections. The KDE student programs team is confident that we have made the best possible choices and matched as many students as possible with competent mentors.

KDE student programs by the numbers

Congratulations and a big welcome to all the students who have been accepted for Season of KDE 2012!

This year we had almost 70 applicants. We found a mentor for 29 of them, and they will spend their summer hacking on KDE. Unfortunately, mentor availability was tight, so we had to say no to quite a few excellent submissions.

I’m not complaining though, this year KDE got more Google Summer of Code students than ever before, and more Season of KDE students than ever before (total headcount: 89). It’s going to be an awesome summer! 🙂

Help wanted: web application developers and artists

It is clear that KDE student programs as a whole are growing, and we have reached the point where a single Google spreadsheet as a tool for all administrative tasks concerning Season of KDE simply does not scale. The sheer amount of submissions (and therefore, data), combined with the size of the KDE community (and therefore, mentors to contact) has resulted in the Season of KDE 2012 selection period taking more than a month!

The current “spreadsheet+bunch of emails” workflow is definitely unsustainable, and the KDE student programs team agrees that a web application like Melange would help tremendously in managing Season of KDE more efficiently. Melange would probably be overkill though, and we have not managed to find any existing solution that would fit our requirements. Those requirements are quite simple: a web application with simple CRUD database operations that would allow the following:

  1. 3 categories of users, students, mentors and administrators can sign up, ideally through identity.kde.org;
  2. students can submit one or more applications for a currently active student program (e.g. Season of KDE);
  3. mentors can view submissions and declare their will to mentor one or more students;
  4. administrators can assign student-mentor matches, manage deadlines and properties of a student (active/inactive, shirt sent/not sent, etc.);
  5. mentors can pass or fail students with a simple yes/no switch (no need for questionnaires like in Melange).

Lydia Pintscher has drawn up a nice representation of the workflow we would like to have:

Sayak Banerjee has already started working on it, so we are hoping it could be ready for next year’s Season of KDE. If you wish to help, feel free to contact sayakb on #kde-www on Freenode.

We could also use a nice logo for Season of KDE, if you have drawing skills and would like to help contact the KDE student programs team at kde-soc-mentor-owner@kde.org.

Color your shell

The UNIX terminal UI has stood the test of time. Tools change, new tools crop up, certain tools are used commonly and others less so. I don’t see the familiar UNIX terminal concept becoming obsolete any time soon. The extensibility and sheer power that comes with it is the best thing since sliced bread.

Now, I like colors and pretty pictures. More specifically, I find it much easier to recognize a piece of information if it is colored in a meaningful way, this is the whole reasoning behind syntax highlighting in IDEs. Luckily some other people like colors and pretty pictures too, and with the power of Free Software they have come up with various ways to add some color to common UNIX-compatible shell tools.

Some of these are just wrapper scripts for existing tools, and some are entire rewrites with lots of added functionality. Some distributions already provide a somewhat colored environment. Some of them contribute to making my shell a much more colorful place.


cw is a color wrapper for common UNIX commands. According to the project’s website, “it is designed to simulate the environment of the commands being executed, so that if a person types ‘du’, ‘df’, ‘ping’, etc. in their shell it will automatically color the output in real-time according to a definition file containing the color format desired.”

cw wrapper scripts do not modify the functionality of the tools involved, they just add colors, so they are a good choice even if you alias some of them to other, more sophisticated tools. Some of the added colors are just eye candy, and some of them are actually very useful.


htop is an interactive process viewer for Linux. It is not just a wrapper for top, this is a completely rewritten and much more featureful program. I alias it in my .bashrc in place of top.


I have tried at least three colored replacements and/or wrappers for df, and dfc is the one I like best. I keep it aliased in place of df.

Other note worthy alternatives include pydf (also very nice) and cdf.


cdu stands for “color du” and it is a Perl wrapper for du. I keep it aliased in place of du.


ls++ is a tool I’m currently still testing. It is a wrapper for plain old ls, it uses common color schemes for file types (as used by the –color parameter of GNU ls) and mangles the output a bit to make it more relevant. I like how it shows permissions and dates.

Other programs

For many prominent toolchain elements there is a colorized variant or wrapper, such as colordiff, colorgcc, colorsvn, colormake and others. Some of them actually already produce very good colored output with the right options (without wrappers), like grep or tree, and are easily aliased in .bashrc to always show colored output.

Combine all that with a nice LS_COLORS in .bashrc courtesy of dircolors and a nice colored prompt and your shell will make you puke rainbows in no time 😉

Lastly, as a bit of bonus content for Archlinux users I’d like to mention pacman-color and yaourt, they make pacman so awesome it’s not even funny.

Google Summer of Code accepted student’s checklist

A little while ago Google published the list of accepted students for Google Sumer of Code 2012, and KDE got 60 students. If you are one of those 60, I wish you again a warm welcome to KDE.

I have put together a checklist of tasks and suggestions I advise you to follow during the community bonding phase. While you are not required to code until May 21 (end of the community bonding period), you are expected to get ready and be in good standing with your community. By now I suppose you have already contacted your mentor.

What follows also applies to Season of KDE students.

(1) Join the relevant communication channels.

KDE contributors do not just silently churn out code, they like to hang out a lot, exchange ideas and opinions. But since KDE pretty huge, different subprojects have their own communication channels. You should definitely join your subproject’s development mailing list (e.g. amarok-devel@kde.org for Amarok, digikam-devel@kde.org for digiKam, etc.) as an absolute minimum. I also strongly advise you to join your subproject’s IRC channel on irc.freenode.net, as many development discussions happen there (e.g. #kdevelop for KDevelop, #plasma for Plasma, etc.). You should also join #kde-devel and #kde-soc on irc.freenode.net. Your mentor will instruct you if there are other communication channels you should be aware of.

(2) Get acquainted with KDE’s infrastructure.

You should get a KDE Identity account and fill out your profile. This account works with most of the services provided by KDE, such as review board, wikis (Community and Techbase) and forums. You need to sign up separately for KDE’s issue tracker. You must then also apply for a contributor account to be able to commit code, please follow these instructions to do so.

(3) Get ready to blog.

Writing a blog is a great way to introduce yourself to the community and keep everybody informed on your progress. If you do not have a blog yet, consider starting one and having it aggregated on Planet KDE. I personally recommend WordPress which is also Free Software but you can use whatever platform you like. It is not mandatory but I think it’s a nice way to motivate yourself and bond with the community. Do not feel pressured to do it, but a few articles when you reach certain milestones in your project could be very nice.

(4) Learn the ways of the community.

Free Software communities work in certain specific ways which are sometimes very different from what a new Google Summer of Code student might be used to. To help you get up to speed quickly, Donnie Berkholz, Lydia Pintscher and Kevin Smith, Google Summer of Code administrators for Gentoo & X.Org, KDE and XMPP Standards Foundation respectively put together a very good article on the DOs and DON’Ts of Google Summer of Code for students. If you are new to KDE I consider this article a required reading assignment before starting your work. It is short, easy to read and to the point, and every word of it applies to your situation as Google Summer of Code students at KDE. For more information on getting involved with KDE specifically, I highly recommend the Free manual KDE Dev Guide, a step by step introduction to KDE for new contributors. A much more complete resource on getting involved with Free Software is Open Advice, a Free knowledge collection from a variety of prominent Free Software contributors.

(5) Talk it through.

You are not required to code for almost a month until the coding period begins, but work on your project starts now. Plan ahead. Do analysis and design. Make sure that if there’s any potential obstacle in your project, it comes up as soon as possible. Set aside a few hours and schedule meetings with your mentor to discuss the fine details of your project and iron out the kinks. It’s best if such discussions are held in the subproject’s IRC channel to allow all the interested parties in the community to contribute. Be ready to submit regular updates to your mentor once you start coding. KDE Google Summer of Code administrators strongly recommend weekly updates to the subproject’s development mailing list, but the exact way you do this is up to your mentor.