Posts Tagged ‘gentoo’
I just published an article over at LWN called “The state of Gentoo.” In it, I talk about Gentoo’s progress over the past few years as well as its current problems, how they’re affecting Gentoo’s user and developer communities, and how to begin fixing them.
I’ve gotten a lot of positive feedback from our developers on the article so I’m confident that it’s generally a fair representation of where things stand today. However, Alex Legler (a3li) kindly told me our security team does much more behind the scenes to report vulnerabilities and get updated packages stabilized, even if we don’t see the results in the form of GLSAs.
I’m running for the Gentoo council this year, and I wanted to post my “platform” here: who I am, why I’m running, how I see the council, and how I see Gentoo.
For anyone newer, I’d like to first introduce myself and my history with Gentoo. Over the past 8 years, I’ve spent time doing pretty much everything in Gentoo, from maintaining ebuilds to writing documentation and leading teams and projects. I’ve been a recruiter in devrel, served as desktop manager (back when we had top-level project managers, before GLEP 39), and later chaired the council. I also started the clustering team, led X11 maintenance for about 5 years (when I designed the modular X eclass and wrote all 400+ new modular packages as we transitioned from the old XFree86), spent a term as a foundation trustee, and acted as project manager for our ever-controversial GUI installer.
One of my primary roles at the moment is running our participation in the Google Summer of Code, one of our major sources of both income and new developers. Since I took over 3 years ago, we’ve more than doubled the size of our program (we have 15 students this year!) and greatly increased the proportion of students who eventually become Gentoo devs to roughly 67%.
At this point, I’m convinced I can make the biggest difference to Gentoo in two ways: focusing on specific projects like the git transition and improved eclass testing rather than ebuild maintenance (which we have tons of people doing), and leading Gentoo to greatness as a council member, where I’m in the best position to accomplish that goal.
On my last two terms as a council member, I was extremely active in council-related issues both on mailing lists and at meetings, rather than just showing up at meetings to vote and then disappearing into the sunset. I strongly believe that through preparation and accountability, we can have a more productive council, but this requires a true commitment on the part of every member.
Creating a great community
I see this as an area where the council can set direction for all of Gentoo, both through the positive examples of its members and by taking a stand against anything we won’t stand for in our community. The council should be providing guidance to devrel and userrel on what kinds of behaviors should be encouraged and what kinds shouldn’t be tolerated.
Additionally, we should begin collecting metrics on our community so we know where we’re going. Many other projects (and even distributions) do this already, to give them clues of when things are going wrong, what things are going right, etc.
Making progress now instead of waiting years for perfection
There’s a lot of ongoing projects and GLEPs that have been dragging on for years because people want a “perfect” solution. One personal example is the git transition, where I’ve already made this mistake in spending quite a bit of time trying to get a perfect repository layout working when we could have just done a simple conversion of the whole tree and put it in one repo (the current plan, with some changes).
GLEP 55 is another one. There are some times when any decision is better than no decision.
Removing bureaucracy in favor of more agile development & meritocracy
We all know that GLEP 39 needs some changes. I think that most devs just want to Get Stuff Done without fighting with policies, waiting around forever for votes, not getting majorities without any clear direction, and so forth. I believe that our devs vote in the council because they want those people in charge and trust the council members to do what they think is right, including deciding on changes to GLEP 39 to improve how we run things.
I favor a switch to a smaller group more along the lines of the Linux kernel, with a very small leadership core and more of a hierarchy than a huge committee.
Along the same lines, I favor a switch to a more meritocratic approach such as the lead appointments we’ve been discussing recently. Gentoo isn’t a country government that needs to provide for every sick and needy person in its geography; it’s a nonprofit with specific goals it needs to accomplish and should be run as such. In general, companies, including nonprofits, don’t have checks and balances or long, drawn-out votes. What they do have is a board of trustees at the top, which can replace the leadership when it deems necessary.
Another major problem is the lack of continuity in our leadership, mainly because the whole group is re-elected en masse every year. At a minimum, even if we can’t do the above changes, we should switch to a 2-year term and have half the council up for election each year so new councils can start out quickly.
Promoting innovation from individual developers instead of expecting it to all come from the top
As I mentioned above, one of my focuses now is working on interesting standalone projects. I hope that every developer does the same; in addition, or besides whatever you do every day (maintain ebuilds, write/translate docs, etc.), consider starting a new project that has a clear end in sight and that will help Gentoo get better. It doesn’t have to be anything big; and the great thing about projects with a finite length is that you actually finish them at some point.
Getting rid of policies that were created for a single incident, because they should only exist for patterns of repeated problems
A common problem in Gentoo is feeling like a one-time problem can’t be fixed without making a big policy about it, why it can’t be done, what will happen if it’s done again, etc. If you’ve been around Gentoo for a while and start reading through our developer docs, you’ll be able to connect a specific name and instance with pretty much every line that says something like “Don’t do stupid thing X” and “Don’t do ridiculous thing Y.”
I think part of this is rooted in a fear, for lack of a better word, to take personal responsibility for an action; instead, people want a rulebook to point at and say “That’s wrong” so the rulebook is the bad guy.
But rulebooks should only be for the common cases, the patterns, the problems that keep coming up over and over. One-time problems only deserve one-time solutions.
One of the most powerful aspects of popular high-level languages is the existence of a comprehensive standard library. Unfortunately, the most popular Linux shell, bash, lacks a full-featured library bundled with it. A number of people have written libraries to compensate for this lack, which can make your life infinitely easier if you need to write complex bash scripts. Here are links to all the bash/shell-scripting libraries and collections I’m aware of:
- Marco’s Bash Functions Library (mbfl)
- Bash Shell Function Library (bsfl)
- Bashinator: Bash Shell Script Framework (by our own wschlich)
- shesfw: shell script framework tool
- Wicked Cool Shell Scripts library (from the book)
- UNIX Power Tools library (from the book)
- Portable Shell Programming (from the book)
- Learning the bash shell (from the book)
- Bash Cookbook (from the book)
- Classic Shell Scripting (from the book)
- shunit2: A unit-test framework
- log4sh: A flexible logging framework
- libbash: Enables creation of dynamic-like shared libraries
- bashworks: Framework depending on bash-4 or newer
- bfw: Bash FrameWork (Harvard Neuroinformatics)
- rerun: Turns loose shell scripts into modular automation
It was a real pain to come up with this whole list, so hopefully it’s useful to some of you. In future posts, I’m thinking of reviewing these libraries in more depth and comparing them to equivalent functionality in Python, my other language of choice. My goal is not to have functionality re-implemented in shell script to replace basic tools like head/tail, but instead to discover or create (if necessary) a library using the full suite of standard UNIX tools to provide a fun and convenient experience for shell scripters.
Update (2013/07/08): Added rerun.
Update: Fixed a couple of broken links (bashworks and Portable Shell).
I’d like to point any potential Google Summer of Code applicants to a post on DOs and DON’Ts for students over on the Google Open Source blog that I wrote with Lydia Pintscher and Kevin Smith. They’re fellow admins from two other long-time GSoC participants, KDE and the XMPP Standards Foundation. Here’s a quick summary of the points; you’ll have to read the original post for details:
|Be on your best behavior.||Make a bad first impression: SMS speech, extremely poor English, rudeness/hostility, etc.|
|Read all the documentation, so you submit a useful application.||Submit a useless application.|
|Be transparent about other commitments.||Disappear.|
|Make Google Summer of Code your top priority.||Hold another major commitment.|
|Be realistic about your skills.||Over- or under-rate your abilities.|
|Commit and publicize your code frequently.||Make last-minute (or later) code drops.|
|Submit code that’s ready to integrate.||Finish the summer with code that’s “almost ready” but will take forever to ship.|
|Complete your project design before writing a line of code.||Start coding before finalizing design.|
|Use your resources wisely.||Refuse to ask for help.|
|Remember that you’re part of a community.||Consider it a solo project, like it often is in college.|
Google Summer of Code (GSoC) is an amazing program for college students that enables them to spend their summers working with open-source projects. Google chips in the money, and FOSS projects provide the mentorship and expertise. In the end, we benefit by gaining both new code and (more importantly) new developers.
I’m very excited this year because both Gentoo and X.Org were accepted for their 6th years in GSoC! Last year, Gentoo had 19 students working on diverse projects including webapps, package management, NetworkManager, the Dracut initrd framework, and more. X.Org, a more specialized project, had 5 students working on various aspects of open-source graphics.
If you’re a college student, I’d like to encourage you to apply for GSoC, whether it’s to Gentoo, X.Org, or another project altogether. It’s great real-world experience where you can prove your expertise to future employers (since the code is freely available), and you can become the world’s expert in your topic. The money doesn’t hurt, either.
To get more info, go to the Gentoo or X.Org GSoC homepages and check out the project ideas. If none of them strike your fancy, propose your own! We love original ideas, but please discuss them with us first to ensure they’ll be realistic and high-priority.
The latest drama sweeping across the open-source world is Canonical’s decision to redirect affiliate profits from music bought in the Banshee music player from 100% GNOME to a 25%/75% split (with Canonical receiving the majority). Nearly everyone has come out against this, but I disagree with parts of their argument. Also, everything I’ve seen has involved verbal wrist-slapping instead of concrete action, so I’m going to propose some possibilities.
“Open source” doesn’t mean “open source until someone makes a change you don’t like.” The whole premise of open source is that anyone can make any changes they want, they have the freedom to fork, and nothing restricts their actions besides copyright. Do we have a right to be angry at people who take advantage of the freedoms we’ve offered them? I don’t think so, but I see where people could disagree.
But what options does that leave anyone who wants to change the situation? Here’s a couple:
- Banshee has a trademark; enforce it. Make Ubuntu change the name of its music player to something else. This would involve talking to lawyers and definitely takes this confrontation to the next level. If Banshee doesn’t already have legal contacts, its developers might contact the GNOME Foundation and work through them, or get in touch with SFLC or another legal team of their choice. If you want your code used in Ubuntu, maybe the name change is enough. But you’ll obviously lose the name recognition.
- Banshee developers could treat Ubuntu as an unsupported configuration and refuse to work with affected users. For this to have any chance of working well for Banshee, it must require its developers to consistently place the blame on Canonical every time problems get reported, to preserve Banshee’s reputation. However, if you don’t support Ubuntu or its users, remember that most bugs aren’t specific to Ubuntu so you’re also hurting yourself. Furthermore, this could provoke Canonical to drop Banshee altogether and switch to a different player. I’d expect Canonical’s decisions to be based on a combination of usability, access to upstream support, and revenue, so its choices will likely try to find a balance of those factors.
- Banshee developers could use rational approaches to convince Canonical its existing terms are inconsistent with the broader software world. OpenSUSE community manager Jos Poortvliet made a great point: “Even Apple doesn’t take more than a 30% cut from people who ship applications through their App Store.” However, this is the next level beyond that; Apple’s recent move to take a 30% cut of subscriptions, books, etc sold via App Store applications is far more equivalent. And this move, even by Apple, is seen as largely negative, but they’re staying the course much like Canonical. If I were Canonical, I’d ask myself how much my users love me compared to how much Apple users love Apple, and adjust my portion of the Banshee revenue accordingly.
I favor the third approach, but you should always keep in mind the best alternative to negotiation, so everyone on both sides of the conflict knows what will happen if negotiation fails.
At the always-excellent Mentor Summit for the Google Summer of Code, I ran a session titled “Best Practices for GSoC Admins.” Many of these practices appear specific to a program like GSoC at first glance, but they easily transfer to recruiting new contributors outside GSoC; just imagine the same ideas with less process behind them. Here I want to share the main points of our session and expand upon some of them in the hopes that it can help future GSoC admins and other people interested in recruiting new developers.
We focused primarily on the biggest problems we face as admins. Intriguingly, although perhaps 30 people attended, nearly all the problems were universal (fortunately, some groups had already solved them!). The only exception to their universal nature was that smaller organizations seemed not to require the same level of progress tracking, because missing/poor progress quickly became obvious to everyone in a small group.
Here are the top problems, with suggested solutions:
- Tracking progress. Require weekly updates from both students and mentors. This means admins don’t need to personally track every student or ensure the mentor is around. Blogs or wiki pages (“journals”) work for many projects, although some have issues with blogs. A key point is to offload work to mentors so they tell you whether students are on track. Keep a spreadsheet (possibly public for tracking and shame?) to stay on top of things, because it’s easy to lose track after a few weeks.
- Knowing student skills. Model the type of things they would do during GSoC on a smaller scale. Require a patch during the application period to prove they can build and modify your software. Additionally, require that students interact with your community so you can consider how (and whether) they will fit in.
- Avoiding failure. Check in with students at “quarter points” — halfway between the start and the midterm, and halfway between the midterm and the final. This leaves time to fix any show-stopping problems before they guarantee failure. During the application period, get a calendar of when both students and mentors will be gone so you can take this into account. Investigate problems early to avoid failure instead of waiting until it’s inevitable. In the case of conflicts between students and mentors, admins can act as neutral mediator — make sure everyone knows this when the summer starts so they don’t feel helpless. Some students communicate poorly (grad-school model of independent work), so try to catch this early and push them. Are there non-binary solutions, ways to do something besides just pass or fail? Can we withhold T-shirts, pay less money based on final “grade”, increase number of payments, pay late, etc.
- Disappearing/lazy mentors. One major problem here is figuring out what motivates mentors: what are the incentives and punishments? The most common response to unacceptable mentoring was blocking that person from any future mentoring. Is that enough? Nobody knows; it seems to be mostly an after-the-fact solution that may not fix things during the summer.
- Inexperienced mentors. Pair new mentors with experienced mentors and/or backup mentors. Admins should offer to be “mentor-mentors,” teaching the beginners how it’s done.
- Increasing the number of proposals. Two student audiences exist: those familiar with your project and those who discover it through GSoC. For the first, target non-accepted students from previous years (Reject gently!). Publicize GSoC internally on your mailing lists, websites, etc. For the second, publicize your project in blogs, to college profs, etc. Have a good ideas list (where good means fun and exciting, so students apply to your project). Increase the time between org acceptance and student deadline so students have time to discover exciting organizations and ideas. Have more flexible ideas that give students some ownership (they must expand upon them!).
- Improving the quality of proposals. A high-quality application template is key. Problem: at least one organization saw a correlation between adding a template and getting fewer proposals. Could applying be made a two-step process, so that the template is displayed after a student commits to applying to a specific organization? Require a timeline in the proposal to ensure they understand project details at a level sufficient to code them, but allow it to flex once coding starts. Ask specific questions to gauge both understanding and enthusiasm. Do live interviews by IRC or phone, possibly with live coding.
If you have any suggestions for these problems, or more problems you’ve encountered, please let me know in the comments!
One of the strangest areas of Linux packaging is scientific software. Often it’s written by non-programmers, it has an ad-hoc, handwritten or poorly maintained build system, and it uses unusual features of strange languages (like Fortran, the topic of this post). I’ve given talks on how upstreams should package scientific software in the past, but this post touches on a different issue: how distributions should handle one of the stranger aspects of Fortran packages.
The rough equivalent of libraries in Fortran90 is modules. One major problem, however, is that modules (“libraries”) are stored differently and change for each compiler+version used to build the package. For example, modules built using GCC’s gfortran and Intel’s ifort are entirely incompatible; even gfortran 4.3 and 4.4 are not expected to play nicely together.
This becomes a problem for people who care about performance, or people who develop Fortran programs, because these people need to have modules available for many different compilers. Initially, you might think we should store Fortran modules in directories reflecting this diversity. Running `gcc -print-file-name=finclude` on recent GCC versions prints the location where GCC installs its own Fortran modules: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/finclude on my system. So you could imagine a series of directories like /usr/lib/$COMPILER/$VERSION/finclude/ where Fortran modules end up for each compiler.
But the problem arises when you consider how packaging actually works: you only get one simultaneous installation of each package+version. That means you can’t easily install modules for three different compiler+version combinations at once. For each module set, you need to rebuild the package for a new compiler and reinstall the package; this means you uninstall the old modules built for the other compiler.
Three possible solutions occurred to me:
- Litter modules by making the package forget it installed them. In this scenario, you would rebuild a package multiple times with different compilers, and the modules would get left behind in a compiler-specific directory like /usr/lib/$COMPILER/$VERSION/finclude/.
- Create a mechanism for switching between the same package version built by a different compiler. This might work by creating binary packages for module-installing packages, then storing them in directories like /usr/portage/packages/$COMPILER/$VERSION/. A switching script could examine these directories and switch between them on-demand by installing those packages using Gentoo’s PKGDIR setting. Using package-specific settings in /etc/portage/env/ to know when to create binaries by setting FEATURES=buildpkg, then adding a late hook to copy the binpkgs to the compiler-specific package directory, might be one route to this.
- Build the same package version with many compilers at once, then bundle it in a single package and install modules for all of them. This would work similarly to Gentoo’s experimental multi-ABI support (available in some overlays), which rebuilds a package numerous times for 32-bit or 64-bit within a single ebuild. This approach has two major downsides: (1) It requires explicit support to be written into every ebuild using it, and (2) a change to just one version of one compiler requires rebuilding the package for every compiler+version.
I’m leaning toward approach 2, which looks relatively easy and quick to support, with the benefit of feeling much cleaner than approach 1 and easier to implement & faster in action than approach 3. With approach 2, only one module directory is required rather than compiler-specific directories. A reasonably compiler-neutral location for Fortran modules would be /usr/$LIBDIR/finclude/, so that’s what I propose to use.
If you have any other ideas or think a different option is better, please let me know in the comments.
“The Hype Cycle describes the way that new technologies and projects are perceived over time, if they do a good job of handling themselves, going from a technology trigger, inflated expectations, disillusionment, enlightenment, before arriving at “the plateau of productivity” – a state where there is no more hype and the new technology is simply a normal part of our lives.”
The perception over the past few years that Gentoo is dying is in reality Gentoo’s arrival at the plateau of productivity. Hype has gone away and remaining is a distribution with a true niche that fits into the broader Linux ecosystem.
Similarly, you need to quickly build the same level of trust with our community. Do you have the tools it takes to hack into the code? and do you know how to use them? When a contributor uploads a patch to our mailing list or to our tracker (preferred, but to make sure you get noticed please post a link on the mailing list too) he builds instantaneously the same level of trust that the unknown cab driver builds with every new customer: he implicitly shows that he has the tools (hardware, operating system, internet connection, coding environment, repository access) and that he can use them for basic operations.