John W. Dean wrote in insightful series of three articles for Findlaw about Authoritarian Conservatives [1]. In summary there are Authoritarian Followers who follow their leader blindly and Authoritarian Leaders who do whatever it takes to gain and maintain power. The Authoritarian mindset lends itself towards right-wing politics. Mick Ebeling gave an inspiring TED talk about his work developing a system to produce art that is controlled by eye movements [2]. The development work was started to support the quadriplegic graffiti artist TEMPT1. Mick s most noteworthy point is that all the hardware design and software are free so anyone can implement it without asking an insurance company or hospital (this is one of the few occasions when a TED speaker has received a standing ovation during a talk). The Eyewriter.org site has the designs and source which is licensed under the GPL [3]. Morgan Spurlock (who is famous for Supersize Me ) gave an amusing TED talk titled The Greatest TED Talk Ever Sold [4]. He provides some interesting information about the brand sponsorship process and his new movie The Greatest Movie Ever Sold . Ralph Langner gave an interesting TED talk about reverse-engineering the Stuxnet worm and discovering that it was targetted at the Iranian nuclear program [5]. The fact that the Stuxnet environment could be turned to other uses such as disrupting power plants is a great concern, particularly as it has special code to prevent automatic safety systems from activating. Angela Belcher gave an interesting TED talk about using nature to grow batteries [6]. She is evolving and engineering viruses to manufacture parts of batteries and assemble them, the aim is to scale up the process to manufacture batteries for the Prius and other large devices at room temperature with no toxic materials. She is also working on biological methods of splitting water into hydrogen and oxygen which has the obvious potential for fuel-cell power and also solar PV cells. As an aside she mentions giving a copy of the Periodic Table to Barack Obama and he told her that he will look at it periodically . Bruce Schnier gave a good overview of the issues related to human perceptions of security in his TED talk about The Security Mirage [7]. There isn t much new in that for people who have been doing computer work but it s good to have an overview of lots of issues. TED has an interesting interview with Gerry Douglas about his work developing touch-screen computer systems for processing medical data in Malawi [8]. This is worth reading by everyone who is involved in software design, many of the things that he has done go against traditional design methods. Mike Matas gave an interesting demo at TED of the first proper digital book [9]. The book is by Al Gore and is run on the iPad/iPhone platform (hopefully they will have an Android version soon). His company is in the business of licensing software for creating digital books. The demonstration featured a mixture of pictures, video, audio, and maps with the pinch interface to move them around. Dr Sommers of Tufts University wrote an interesting post for Psychology Today titled Why it s Never About Race [10]. It seems that there are lots of patterns of people being treated differently on the basis of race but for every specific case no-one wants to believe that racial bias was involved. The Register has an amusing article about what might have happened if Kate had left Prince William at the altar [11]. Fiorenzo Omenetto gave an interesting TED talk about synthetic silk [12]. He is working on developing artificial fibers and solids based on the same proteins as silk which can be used for storing information (DVDs and holograms), medical implants (which can be re-absorbed into the body and which don t trigger an immune response), and cups among other things. Maybe my next tie will have a no pupae were harmed in the production notice. ;) The CDC has released a guide to preparing for a Zombie apocalypse [13], while it s unlikely that Zombies will attack, the same suggestions will help people prepare for the other medical emergencies that involve the CDC. Salon has an interesting article by Glenn Greenwald who interviewed Benjamin Ferencz about aggressive warfare [14]. Benjamin was a prosecutor for war crimes at Nuremberg after WW2 and compares the US actions since 9-11 with what was deemed to be illegal by the standards of WW2. Eli Pariser gave an interesting TED talk about Online Filter Bubbles [15]. He claims that services such as Facebook and Google should give more of a mixture of results rather than targetting for what people want. The problem with this idea is that presenting links that someone doesn t want to click doesn t do any good. It s not as if the filter bubble effect relies on modern media or can be easily solved. Terry Moore gave a TED talk about how to tie shoelaces [16]. Basically he advocates using a doubly-slipped Reef Knot instead of a doubly-slipped Granny Knot. Now I just need to figure out how to tie a doubly-slipped Reef Knot quickly and reliably. Terry uses this as a mathaphor for other ways in which one might habitually do something in a non-optimal way.

• [1] http://writ.news.findlaw.com/dean/20070925.html
• [2] http://www.ted.com/talks/mick_ebeling_the_invention_that_unlocked_a_locked_in_artist.html
• [3] http://www.eyewriter.org/developer/
• [4] http://www.ted.com/talks/morgan_spurlock_the_greatest_ted_talk_ever_sold.html
• [5] http://www.ted.com/talks/ralph_langner_cracking_stuxnet_a_21st_century_cyberweapon.html
• [6] http://www.ted.com/talks/angela_belcher_using_nature_to_grow_batteries.html
• [7] http://www.ted.com/talks/bruce_schneier.html
• [8] http://blog.ted.com/2011/04/29/fellows-friday-with-gerry-douglas/
• [9] http://www.ted.com/talks/mike_matas.html
• [10] http://www.psychologytoday.com/collections/201104/happy-birth-certificate-mr-president/why-its-never-about-race
• [11] http://www.theregister.co.uk/2011/04/28/operation_pumpkin/
• [12] http://www.ted.com/talks/fiorenzo_omenetto_silk_the_ancient_material_of_the_future.html
• [13] http://emergency.cdc.gov/socialmedia/zombies_blog.asp
• [14] http://www.salon.com/news/osama_bin_laden/index.html?story=/opinion/greenwald/2011/05/13/nuremberg
• [15] http://www.ted.com/talks/lang/eng/eli_pariser_beware_online_filter_bubbles.html
• [16] http://www.ted.com/talks/terry_moore_how_to_tie_your_shoes.html

What do Assholes do? Rusty just wrote a post titled If you didn t run code written by assholes, your machine wouldn t boot [1] about some of the anti-social tendencies demonstrated by programmers, including some that are implied to be fairly important. His post seems to imply that there are really great programmers who are anti-social and that we should just put up with it because of their great code. One of the problems with his post is that he doesn t define asshole . Holocaust deniers and all other Nazi supporters seem to clearly by assholes by any definition. People who have silly ideas about medicine and tell others seem to be merely misguided (although my dictionary gives stupid or irritating or ridiculous in the definition of asshole so technically they can meet the criteria). In the comments Rusty states that nuttiness is relative . While that is correct it doesn t seem to have much bearing on whether someone is an asshole. For example I know some very nice people who are utterly convinced by creationism. Is Anyone Essential to Free Software? Most projects have one person or several people in leadership positions, usually there seems to be a combination of project management and lead-programmer positions. Such people are obviously quite important to a project. But we have seen examples of people dying, being employed by Microsoft, retiring, relicensing the source in a bad way, and just losing interest without the project ceasing. It seems clear that in most cases when a project which has a significant amount of use has significant bugs and no maintainer then someone will step in. The cases where no-one takes over the project are often resolved by someone creating a competing project. If no-one takes over an abandoned Free Software project then it s a strong indication that the project wasn t particularly important anyway. I have no doubt that if any bug or missing feature made Linux systems stop booting then someone would fix it quite quickly. In a more general sense it seems that every time someone takes a position in a project that is of wide interest they are displacing someone else who might have done the job. When you volunteer to do significant work for a project you may be displacing someone who is more skillful than you this isn t necessarily a bad thing as there are plenty of other projects to work on, some of which require more skill. Growing More Programmers It seems to me that a large part of becoming a great programmer is facing great challenges. People who could be described as optimistic or arrogant will tend to take on more challenging tasks and therefore learn more. I m sure that there are a lot of people out there who have the potential to be great programmers apart from not taking on the challenging work, this seems to be an unfortunate waste of talent. Given a large enough population if someone leaves a senior position there should be someone else who can obtain the skills needed to take over. One advantage of this for Free Software development is that even if the best person to take on the challenge isn t living in the most convenient continent that won t be an obstacle, while with proprietary software development projects the teams are small and it s common that no-one else is capable of stepping up to a lead position. Another advantage is that when the lead developer leaves there are generally many candidates to replace them, all of whom can start work and be judged on the work that they do. I think that the best claims that can be made regarding essential people are not in regard to technical skill alone but to a combination of technical and people skills. Getting a group of programmers to work together is really hard but it s something that needs to be done for any significant project. Also the larger projects tend not to stand alone, being able to get changes included in other projects requires some skill. Ben Collins-Sussman and Brian Fitzpatrick gave an insightful talk at Google IO 2008 titled How to Protect Your Open Source Project From Poisonous People [2]. The first half of their talk is mostly about people who are misguided or difficult rather than what most people would consider poisonous and the second half is more about people who are actively poisonous and need to be removed. They advocate a community based on Politeness, Respect, Trust, and Humility. They describe in detail how the methods they advocate result in the members of their community being more productive, it seems obvious that those principles will lead to better career growth for people within the community and more friendly people wanting to join. When is being an Asshole OK? I once worked for a company that apparently had a team consisting solely of assholes. Apparently one asshole got promoted to management and after some internal transfers they ended up with all the assholes in the company on one team. I guess that when someone has negative interactions with everyone they won t notice the difference if they are put in a team where everyone is difficult. For a corporate environment that lacks a no jerks hiring policy this is probably a good way of improving productivity overall. I am not aware of any significant Free Software project that was comprised of mostly jerks although I have seen a few with dysfunctional environments that encourage the worst behavior from their members. The smaller Free Software projects have less need for people who can relate to other people. There are many useful Free Software projects which have only one developer, in most cases anyone can take the source code and use it without dealing with the author. But even for a single-developer project an asshole can cause some serious problems. One example I know of concerns a developer who had unclear licenses and started making legal threats in response to a request for a clear license. Another example is of a developer who released code that was designed to not work when one particular user compiled it and redistributed the binaries. Both of them caused some significant amounts of time to be wasted by people who were unfortunate enough to develop systems that interacted with the code in question, and even more time was wasted when some misguided people defended them in the inevitable flame-wars. Even for a project with only one developer it s still better for everyone if that developer isn t an asshole. One comment I ve seen related to this issue suggesting that some types of asshole behavior shouldn t be a problem an example that was cited is a colleague who cheats on a romantic partner. Jeremy Clyman (who is currently doing a Ph.D in Psychology) has written an interesting article about this for Psychology Today [3]. He reviews the movie The Dilemma which deals with someone catching their colleague s wife cheating. Jeremy analyses the psychological issues involved and how they can (among other things) impact the ability for such people to work. I once worked in an office where two married employees were very open about having an affair and we were all apparently expected to lie on their behalf if necessary, it really affected the quality of the working environment. Extreme Assholes There are lots of people involved in Free Software development who are difficult and many who are to some extent assholes. But some of them take being an asshole to the extreme, such as Holocaust deniers (an example which Rusty used). In the comments on his post the Westboro Baptist Church is also mentioned. It is possible to entirely disagree with someone on a contentious issue such as abortion but still be able to get along with them. But when someone supports a hate-based organisation such as the WBC or supports Nazis in any way then there will be many people who just can t tolerate them and no-one should be expected to tolerate such people. I have seen two instances where Free Software developers advocated pro-Nazi positions (one had an archive of neo-Nazi propaganda and the other claimed that Nazis were not responsible for the Holocaust). Neither of the pro-Nazi programmers was evicted for defending Nazis, but both of them ended up leaving the community in adverse ways after causing other damage in the mean time. I don t think it takes any great ability to predict the future to determine that someone who defends Nazis will eventually end up doing something that requires expulsion and drive away users and developers in the mean-time. There is no possibility that someone can support the Nazi or WBC ideology only when not associated with your project, it will affect all aspects of their life. When a Holocaust denier is allowed to be a member of a community it also sends out a message that members of the groups which were persecuted by Nazis aren t particularly welcome in the community. Helping Minor Assholes There are a lot of people who don t have malevolent aims but who unintentionally cause some difficulty (it seems that the truly malicious are a tiny minority). I don t think that excusing the bad things that they do on the basis of writing good code helps them in the long term. Many of the suggestions that Ben Collins-Sussman and Brian Fitzpatrick make seem likely to help people who don t want to be assholes and direct them towards positive involvement in the community. One trend that seems apparent is the non-linear response to certain types of bad behavior. There is often little difference in severity between something that gets almost no attention and something that results in a large and extremely hostile reaction. If someone persists in acting like an asshole for long enough it seems to be inevitable that they will eventually exceed some threshold for what is tolerated and get a very significant negative response. It would be good if things didn t need to get to that stage. I think that the most unfortunate aspect of Rusty s blog post is that most people will probably interpret it as encouragement to write better code as a way of getting a free pass for being an asshole. I know that this isn t what Rusty intended, but most people on the Internet don t know Rusty as well as I do. Conclusion Ben Collins-Sussman and Brian Fitzpatrick seem to have some of the best ideas for how to deal with these issues when you control a project, but most of us aren t in that position. Everyone can advocate better behavior. Extreme assholes need to be removed quickly and without a great debate about their contributions, freedom of speech, or other issues. Since considering this issue I ve been wondering about when one should avoid the lesser assholes and asshole-positive environments. People tend to adapt to their environment, so if you associate with assholes a lot then there s a good chance you will start to become like them. Is

• [1] http://rusty.ozlabs.org/?p=196
• [2] http://www.youtube.com/watch?v=-F-3E8pyjFo
• [3] http://www.psychologytoday.com/blog/reel-therapy/201105/what-causes-the-dilemma

Or how to get rid of Evolution without removing your whole system There is a complain I have heard several times from people after they installed Debian: I use Icedove/Thunderbird so I do not need Evolution: I tried to remove it but this would remove my whole system, that sucks! Explanation The reason behind this situation is that GNOME is installed by a meta-package, which is a dummy package that depends on each component of the official GNOME desktop, including Evolution. So it got installed as a dependency of that dummy package. This means that you, or rather, the Debian installer, never asked explicitly to install either Evolution or any other specific software: it came automatically. Now, you want to remove Evolution: very well, but this implies removing the meta-package, as you are removing one of its dependencies. But if you are removing this meta-package, there is no reason to keep all this software you did not asked for, so, as they got installed automatically, they are now removed automatically as well The solution So, do you still want to remove Evolution but keep the remaining of your GNOME desktop? Of course you will not keep GNOME , because GNOME includes Evolution, so strictly speaking GNOME without Evolution is not GNOME any more. Well, there is a solution: marking all the dependencies of the meta-package as manually installed, that is, faking that you installed them explicitly Aptitude is able to do that with its powerful search functions:

# aptitude unmarkauto '?reverse-depends(gnome)   ?reverse-recommends(gnome)'
# aptitude unmarkauto '?reverse-depends(gnome-core)   ?reverse-recommends(gnome-core)'
# aptitude unmarkauto '?reverse-depends(gnome-desktop-environment)'\
'   ?reverse-recommends(gnome-desktop-environment)'

What did we do? Well, exactly what is written: unmarking as automatically installed the packages that reverse-depend or reverse-recommend gnome or gnome-desktop-environment. In other words, those that are dependencies or recommendations of gnome, gnome-core or gnome-desktop-environment. Why these three packages? Because the GNOME environment that Debian provides by default is composed of several meta-packages: I shall let you refer to their respective descriptions for further information. Now, you can safely remove Evolution without pulling out your whole desktop system:

# aptitude remove evolution

<iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm.amazon.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=dedasys-20&amp;o=1&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;ref=ss_til&amp;asins=B004IYISQW" style="width: 120px; height: 240px; float: left; margin-right: 20px; margin-bottom: 8px;"></iframe> Many small business owners start a business with the idea of greater freedom in mind, yet end up chaining themselves to something that takes even more dedication than a regular job. This book discusses the dos and don'ts that business owners need to be conscious of in order to create a business that is independent of its owner(s) in order to be able to sell it. It does so in an easy to read format that's a bit of a gimmick - a fictional story illustrating the authors points. Like most business books, the core idea isn't that hard to explain. the book even includes a handy summary of the main points, which I'll paraphrase here:

1. Focus on one thing you can do really well; even a service business can be 'productized' by creating a standard service that is the focus of the business.
2. If your business revolves around one or two key clients, the risk inherent in that approach will lower the value or scare of potential buyers completely.
3. Put a process in place, from sales through production.
4. Don't "be" your company. If the company is all about you, what's a potential buyer really getting if you sell it and leave?
5. By focusing on products, you can charge up front rather than having poor cash flow. If you pay people to work on a project for 3 months, and don't get paid for another month, you are, by the end, out 4 months salary while waiting for the payment.
6. Say no to projects outside the scope of your business. Only by focusing narrowly can you really excel at what you do.
7. Spend time doing some research and calculations to estimate your potential market size; buyers will want to know this.
8. If you have a business that has sales people, hire at least two so that they'll compete with one another.
9. You want people who are good at selling products, not services; the latter will want to tweak your offering for each and every client, rather than selling it as-is and trying to find how it can meet the customer's needs that way, which is the best strategy for a product.
10. If you were previously running a more 'generic' services company, and you switch to a more productized approach, be prepared to take a hit the year when you switch.
11. Potential acquirers will want to see at least a couple of years of steady growth with the new model after making the switch.
12. If you grow, you'll need a management team that can work without you. Put an incentive system into place to reward their loyalty and results.
13. When looking for an adviser to sell your company, aim for one where you will not be the largest or smallest client.
14. If your adviser really only has one company in mind to sell yours to, they may be trying to sell you off cheap as a favor.
15. Consider how much you could grow with the resources of a buyer. Think big, and show them what kind of growth could happen with the right backing.
16. Think and speak like a product business with 'customers' rather than 'clients'.
17. Stock options are more complex than simpler options like bonuses that are paid out over a period of time, in terms of ways to give people an incentive to stay.

All in all, it was an enjoyable read, with solid points. Even if you have no intention of selling your business, thinking of the business itself as a sort of "product" that is not dependent on you to work correctly is a sensible way to go about creating and growing a business. He's certainly not, nor claims to be the first one to discuss this idea, and indeed references the well known E-Myth Revisited which focuses less on selling a business, and more on how to go about extricating you and your skills from the business.

Today I was baptized and joined the Mennonite Church. I imagine this might surprise some of you for various reasons, so let me provide a bit of background. I ve had a lot of people, both in person and in comments responding to my blog post, express surprise with statements I have made. The view of Christianity that many people have is of a group that devalues scientific inquiry and places a lot of emphasis on things like opposition to gay marriage, evolution, and abortion, and enjoys political leaders that say bring it on. While I know some Christians that fall into that mold, there are quite a few that don t as well. Some churches, such as the one we attend, have a surprisingly diverse set of people and yet still function and get along well. Today they accepted me with joy. Nobody was concerned that I started my statement with a reference to ancient Greek philosophy, wound up suggesting that the church ought to make sure to make illegal immigrants, gays and lesbians, and prostitutes feel welcome, and embraced both religion and scientific inquiry, feeling them complimentary. Mennonites practice adult baptism rather than infant baptism. A traditional age for people to be baptized is during high school, though emphasis is placed more on the individual than their age, so it s not unheard-of for someone to do so a bit later in life as I have. Part of the baptism involves the candidate sharing their faith story. These are typically intensely personal, widely varied, heartfelt, and honest. Some people s stories involve struggles with depression, physical disabilities, or the place of religion in their lives, while others reflect little struggle at all. Mine involves letting go of a lot of things, and also seeing some things, such as serious intellectual inquiry or existential questions about God (such as is there a god? ), as a positive rather than a negative feature of a Christian life. But it also involves a recognition and deep respect for those that don t approach things in this way. Though given publicly in a church, baptism testimonies are rarely published or shared more broadly. But I m going to share mine here. I have edited it only very lightly to remove a few local references that wouldn t make sense out of the context of this community. This was delivered in front of a rather different audience than is likely to be reading this post, so if you have questions, do feel free to ask in the comments. But before I begin, I just have to pass along a joke a friend told me: John, you picked quite a day for your baptism the day after the rapture. Baptism Testimony John Goerzen May 22, 2011 Those of you that know me well will probably not be surprised that I will begin my Christian baptism testimony with a story about an ancient Greek philosopher, and also touch on the philosophical nature of truth. These are key parts of my story. As legend goes, Socrates famously said, I know that I know nothing in other words, he believed that nothing could be known with absolute certainty. The Greek Oracle thought to be infallibly wise said that Socrates, the man that thought he knew nothing, was the wisest man in all Athens. An interesting paradox, and one that sheds light on my own religious story. My story involves coming to grips with the understanding that I know very little, that no person can ultimately know much about God, and finding a way to make peace with that situation. Growing up in this community, I thought I knew some things about faith and Christianity. At a certain age, it all seemed so simple. We took the Bible to be literally true. We marveled in Sunday School at how the apostles could sometimes appear so blind. And, modeled both implicitly and explicitly, was this notion: the stronger our faith, the fewer inner questions or doubt we have about the nature of God, the literal accuracy of the entire Bible, or our relationship to God. Those I perceived held up as examples never seemed to question any of these things, and showed outwardly, at least complete certainty about them. Moreover, holding certain intellectual beliefs was key to Christian identity, and even more importantly, to eternal life. This model has quite obviously worked well for many people for many years. The good that has happened, and continues to happen, from people that have that kind of certainty is manifest all around us. And yet, it didn t seem to work out for me. I m not the kind of person that accepts a lot of things at face value. It is helpful to be able to examine and challenge ideas and even more helpful to have other people challenge my ideas. From well before I was in high school, I was questioning some things about the Bible, God, and religion in general. My thoughts ranged from the impact of evolution on religion to the apparently vengeful God of the Old Testament to the very existence of God. In the Christian context, I perceived having these questions as a personal failing, something that I ought to repress. The more I tried to repress them, the more troublesome they became. Why, for instance, should a loving merciful God decide whether to let us into heaven based on whether we hold certain intellectual beliefs? In high school, I participated in the catechism class here at this church, and was frustrated because it didn t tackle deeper meanings or the kinds of questions I had. I wasn t yet able to articulate all my thoughts and questions very well, and I probably had an overactive case of teenage cynicism. As a result, I didn t get baptized like most others my age did. As I learned more about the early history of Judaism and Christianity, I only found more reasons to question the model of faith I thought I had received the one in which Biblical literalism and a divine guarantee of sorts was key. More recently, I gradually became aware that the model of Christianity I had in mind was one of many views. Christians, Mennonites, and even this church are incredibly diverse groups, and in retrospect, I am surprised that it took me so long to realize this. Three major steps led me to baptism. The first step was the realization that, whatever our understanding of the literal accuracy of the Bible, literal truth is often inferior to metaphorical truth. As an example, many of us have read the works of Shakespeare. They are fictional, but the reason they have been revered for so many centuries is that they are true. They teach us things about ourselves and our world in a way that no history book can. By placing such an emphasis on literal truth in the Bible, I was missing out on the message right there for me. By concerning myself with creationism or evolution, I missed out on thinking about what the story in Genesis meant for the Jews, and what it could mean for me. Evolution ceased to be a threat to religion; it became simply a tool for learning about a different sort of truth than we get from religion. N. T. Wright mentions an incident that illustrates this point. A woman attending a religious conference asked the speaker, a prominent theologian, Is it true that the serpent in Genesis actually spoke like you and I speak? The theologian answered, It doesn t matter whether the serpent could speak. What matters is what the serpent said. The second step I took towards being baptized was realizing where the real core of Christianity lies. It s not some debate about Genesis, but rather the death to one s old self, and the rebirth and continual remaking of oneself in the example of Jesus. Given that, a lot of questions seem unimportant or even irrelevant. Good can be expressed in many ways, and if one person achieves a remarkably Christian life via a literal understanding of the Bible, and another via a more metaphorical reading, then it is my place only to affirm both and say that they both got it right. If we say that the task of remaking ourselves is like climbing a mountain, then what matters is not how we are climbing the mountain, but simply that we are climbing it. I used to equate faith with an intellectual belief. I have come to see that was a narrow view. Faith, to me now, is more about vision: do we see the world like Christ did? Where do our loyalties and our trust lie in God or in human institutions? What are our goals in life? We humans have failed to understand God, and probably always will. I too share in that incomplete understanding, but I have come to accept that it is OK. I know enough to know that I want my loyalty to lie in Jesus, to know what kind of vision of the world I want to have, and I have learned to accept that intellectual questions can even be a form of meditation, enlightenment, and prayer. The third step toward baptism was moving past my own shortcomings. For a long time, I thought I didn t believe the right things, didn t believe them strong enough, wasn t certain enough about God, didn t pray enough, didn t read enough, didn t understand enough, didn t love enough and ultimately, that I wasn t good enough. I request baptism today understanding that, despite the various imperfections I still have, and we all have, everyone is good enough and deserving of love and peace. God s love is for everyone. No exceptions! Following Jesus boils down to this: I too must be an agent of love and peace to everyone, without exception. My vision must be centered around the fact that we are to emulate the God that loves the entire world, sinners all, and therefore I should as well. I hope I can show others the kind of love that has been shown me. I hope, too, to share with this congregation and the global church in the vision of love. I hope that we can continually strive to re-focus on Christ s vision. As an example, we all know that many different viewpoints about whether homosexuality is sinful exist in Mennonite Church USA. These opinions are deeply held and personal for many, and have been discussed over and over and over. But ultimately, they aren t terribly relevant to the church s mission. The example of Jesus unites us all: he embraced everyone. He accepted criminals and prostitutes and showed them love and kindness. Our difficult task, which is also my difficult task, is to show this same love to absolutely everyone, regardless of our varying opinions about them and their conduct. The forgotten and repressed of our day perhaps criminals, homeless, Muslims, addicts, gays and lesbians, illegal immigrants, ethnic minorities, and still prostitutes deserve the love of Christ s church and all its members. My hope is that any one of the earth s 7 billion people could step through the doors of our church, or any church, and immediately feel Christ s love, and the unconditional, non-judgmental, welcome and love of Christ s followers, no matter what. This prayer from Ephesians 3 sums up my hope and my vision, for myself and everyone:

I pray that out of his glorious riches he may strengthen you with power through his Spirit in your inner being. I pray that Christ may dwell in your hearts through faith. And I pray that you, being rooted and established in love, may have power, together with all the Lord s people, to grasp how wide and long and high and deep is the love of Christ. And I pray that you will know this love that surpasses knowledge that you may be filled to the measure of all the fullness of God. (3.16-19)

tar and cpio tar(5) and cpio(5) are two competing archive formats, that provide almost identical features. Both are streamed formats, originally designed to be used on tapes. Their major practical difference is the style of their standard command line utilities:

• cpio(1) takes the list of files to archive on its standard input, allowing a very high control but requiring to use another utility such as find(1) to archive an entire tree;
• tar(1) usually takes the list of file to archive on its command line, and browses directories recursively be default.

Peace! There is a traditional opposition between these two formats and utilities and their respective supporters. To fix this, the POSIX specification deprecated both commands in 2001, replacing them by a single one called pax(1), that can be used either in cpio-like or tar-like style. This specification also defined a pax interchange format, which these vile trolls derived from tar! Now, considering the actual practice, you can notice that tar has won, and that almost nobody uses pax. Almost every free software project I know release tarballs, not cpio archives. This is probably the reason why the GNU tar utility has evolved much more than GNU cpio: tar now integrates seamlessly with compressors such as gzip, bzip2 or xz, autodetecting the compression format when needed whereas cpio has no such features as far as I know. However, cpio is notably used by the Linux kernel for its initial memory file system, aka initrd. tar and cpio drawbacks Now I come to the title of this article: I personally prefer the cpio format over tar, although I usually use tar because of the advanced features of GNU tar. In fact, tar suffers from a drawback that usually has to be worked around: it cannot store any type of file. There exist seven file types: regular files, directories, symbolic links, character devices, block devices, FIFOs and Unix sockets. Well, tar can only represent six of them, and misses the ability to store sockets. Thus, if you try to archive your entire filesystem with tar, you may get the following output:

tar: /var/spool/postfix/private/rewrite: socket ignored
tar: /var/spool/postfix/private/bsmtp: socket ignored

If you try the same with cpio, you will see that sockets get archived without any problem. Given that the tar format has a type byte, with one reserved value, I am surprised that its 2001 revision did not use it for sockets, but for some reason it did not. In practice, programs that use sockets work around this problem by creating them at startup. To be honest, I must mention that cpio also has one significant drawback: when a file has several links, it gets copied several times in the archive. Edit: It appears that archiving sockets is completely pointless, given that they must be unlinked if they exist, and then created before they are used by a program. Thus, the question becomes: why does cpio support sockets?

• More info: mdjonline.com/view/full_story/13289144/article-Spaniards-protest-banks--political-parties
• Foto galleries and more info www.demotix.com/news/693670/madrid-protesters-leaving-court
• Still more: www.tmcnet.com/usubmit/2011/05/17/5517295.htm
• [Edit] BoingBoing carries a very complete article: http://www.boingboing.net/2011/05/17/nobody-expects-the-s.html

Spain is struggling to recover from the double blow of the global recession and the bursting of a decade-long property bubble, and the unemployment rate is more than 21 percent.

Thanks to Ralf's work, dose3 has been just accepted in debian experimental !!! yuppiiiii \o/

  Dose3 is a framework made of several OCaml libraries for managing
  distribution packages and their dependencies.
  Though not tied to any particular distribution, dose3 constitutes a pool of
  libraries which enable analyzing packages coming from various
  distributions.
  Besides basic functionality for querying and setting package properties,
  dose3 also implements algorithms for solving more complex problems
  (monitoring package evolutions, correct and complete dependency resolution,
  repository-wide uninstallability checks). 

For the ocaml affectionados the API of the library is available here (there is still a bit of work to do here...) . The source code shipped in each release does not include a vast range of applications sitting in the experimental directory. You can have a look at these in our svn. if you want to get a copy of the development / bleeding edge / unstable version from svn, you can check it out from the svn

 svn co https://gforge.info.ucl.ac.be/svn/mancoosi/trunk/dose3

user/pass : mancoosi/mancoosi

My previous blog entry about Test Driven Distro Development (TDDD) was rather rambling. Here is the condensed version, plus some further thoughts. I would like to automatically determine whether "testing" is minimally ready to be released, at any given point in time. To implement this, I would like to see Debian get tools that would allow us to define specific minimal functionality that should work in a Debian release, and automatically verify that it does. I would like us to use these tools to determine whether a release is ready for release, with manual override from the release team. Ideally, we would use the tools to prevent breakages from moving into "testing", so that it gets closer to always being releasable. Getting test coverage sufficiently high that we can replace the release team's judgement abour releasablity will never happen: Debian is rather too large and and complex for that. However, we can reap much benefit from even relatively small coverage. Here is my initial suggestion for the minimal criteria that should be satisfied, at all times, in "testing". They are aimed at making sure that even if something else breaks, at least the basic stuff works well enough that one can log in and fix things.

• there are no open ports in a base install
• logging in via getty works
• logging in via ssh works, if openssh-server is installed
• su, sudo, ls, cp, mv, rm, and vi work at least in some typical use cases
• web pages can be accessed from outside the system, given suitably configured apache2
• after automatic login into a graphical desktop environment, all the crucial per-session programs start up, as well as web browsers and other GUI programs that almost everyone expects to be part of a desktop environment
  • if there are good GUI testing tools, we may want to test in more detail, but that may have to wait for later

These are minimal criteria. They're not meant to verify that everything in Debian works. After these work, adding more coverage is not just possible, but reasonably easy in many cases. Want to make sure DNS gets configured right? Write a test that logs in and does a lookup inside the test system. After the tools have evolved, writing a simple test like that should be only a line or two. The tests I am talking here are system tests, or acceptance tests for the whole system, not just for individual packages. Unit tests would test individual functions or methods or classes; integration tests would test groups of them, or possibly entire programs; system tests test groups of programs/packages. The point is not to verify that every package works in every possible case, but that the system as a whole works. Most package-specific functional tests should be part of the package's own test suite. We should also run those, but that's somewhat orthogonal to the vision I'm trying to articulate here. At least the following scenarios should be tested (the above tests should be run after each scenario):

• install "stable" and upgrade to "testing"
• install "testing" using latest d-i release, and upgrade to current "testing"
• use an install from the previous successful test run, and upgrade to the current "testing"
  • this answers the question "if testing worked yesterday, does it still work if we add these new packages"

It may be useful to run the tests against "unstable" as well as "testing". However, rejecting an upload to "unstable" may be less wise than preventing packages from being copied from "unstable" to "testing". Exactly how this the development processes should adopt TDDD is an interesting question, but a reasonable toolset should be adaptable to anything we want to do. (Indeed, it would be possible to structure the toolset so that it isn't specific to developing a distro: a "system-test" tool that a sysadmin could use to verify that a server works would probably be useful to some people. Perhaps such a tool exists and could be adapted for TDDD?) Running these tests for security updates to "stable" would obviously also be a possibility that should perhaps be considered. Running these tests would happen something like this:

• generate a suitable virtual machine disk image, configured in the proper way for the test
• run the image under virtualization (or on real hardware if that can be remote-controlled suitably)
• run the tests against the image
• if tests fail, archive the image (or sufficient information to reproduce the start image)
  • also, automatically file bugs against all packages involved in the test, and e-mail debian-devel-announce with the names of the people who uploaded the new versions of packages compared to the previous successful test run, Cc'ing their spouses and parents for further shaming, and also Cc'ing the Debconf organization team so they can stood up before an audience armed with rotten tomatoes and eggs (this bullet point is here only to see if anyone actually reads my blog posts)

I would further like to see Debian make it possible to have isolated branches for development. This would help with, for example, large transitions that take a long time. The transition could be prepared in a branch of its own, and when it's ready to be pushed into unstable, the automatic tests outlined above could be used to verify the transition doesn't break anything too critical. (If the tests fail, the push fails; if necessary, that can be overridden manually, but that should be rare.) In my view, branches would greatly benefit Debian development, but they're not necessary for starting to implement TDDD. My condensed versions are still too long.

LightDM's a from-scratch implementation of an X display manager, ie the piece of software that handles remote X connections, starts any local X servers, provides a login screen and kicks off the initial user session. It's split into a nominally desktop-agnostic core (built directly on xcb and glib) and greeters, the idea being that it's straightforward to implement an environment-specific greeter that integrates nicely with your desktop session. It's about 6500 lines of code in the core, 3500 lines of code in the gtk bindings to the core and about 1000 in the sample gtk greeter, for a total of about 11,000 lines of code for a full implementation. This compares to getting on for 60,000 in gdm. Ubuntu plan to switch to LightDM in their next release (11.10).

This is a ridiculous idea.

To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves". People see gtk and think "Gosh, that's kind of big for a toolkit library. I'll write my own". And at some point they have to write a file dialog. And then they need to implement support for handling remote filesystems. And then they need to know whether the system has a functioning network connection or not, and so they end up querying state from Network Manager. And then they suddenly have a library that's getting on for the size of gtk, has about the same level of complexity and has had much less testing because why would you want to use a lightweight toolkit that either does nothing or is 90% of the size of the alternative and crashes all the time.

Adding functionality means that code gets larger. Given two codebases that are of significantly different sizes, the two possible conclusions are either that (a) the smaller one is massively more competently written than the larger one, or (b) the smaller one does less. The gdm authors have never struck me as incompetent, even if some people may disagree with some of their design decisions, and the LightDM authors don't seem to have argued on that basis either. So the obvious conclusion is that LightDM does less.

And, indeed, LightDM does less. Part of this is by design - as the proposal to the Gnome development list shows, one of the key advantages of LightDM is claimed as it not starting a Gnome session. And from that statement alone, we can already see that there's been a massive failure of understanding the complexity of the problem.

Let's go back to the comparisons of code size. LightDM's simple GTK greeter is about 1000 lines of code. gdm's greeter is almost 20,000. Some of this is arbitrary shiny stuff like the slidy effects that occur, but a lot of it is additional functionality. For example, some of it is devoted to handling the interface with AccountsService so gdm can automatically update when users are created or deleted. Some of it is providing UI for accessibility functionality. Some of it is drawing a clock, which I'll admit may be a touch gratuitous.

But if your argument is that your software is better because it's doing less, you should be able to ensure that you can demonstrate that the differences aren't important. And the differences here are important. For example, one of the reasons gdm starts a local gnome session is that it wants gnome-power-manager to be there to handle power policy. Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not. LightDM takes a different approach. Because there's no session, it has to take care of this kind of thing itself. So the backend daemon code speaks to upower directly, and the greeters ask the daemon to implement their policy decisions.

This is pretty obviously miserable. Now you've got two sets of policy - one at the login screen, and one in your session. How do I ensure they're consistent? The only sane solution is to ignore the functionality the backend provides and have my greeter run gnome-power-manager. And now how about accessibility preferences? Again, if I want to have the same selection of policy, I need to run the same code. So you end up with a greeter that's about as complex and large as the gdm one, and unused functionality in the backend. Lighter weight through code duplication. We have always been at war with Eurasia.

The entirety of LightDM's design is based on a false premise - that you can move a large set of common greeter functionality into a daemon and just leave UI presentation up to the greeter code. And if you believe that, then yes, you can absolutely implement a greeter in 1000 lines of code. It'll behave differently to your desktop - the range of policy you can implement will be limited to what the daemon provides, even if your desktop environment has a different range of features. It'll have worse accessibility for much the same reason. And eventually you'll end up with a daemon that's absolutely huge in order to attempt to provide the superset of functionality that each different desktop makes use of.

The only real problem LightDM solves is that it makes it easier to write custom greeters, and if you're really seeking to differentiate your project based on your login screen then maybe your priorities are a little out of line. I'm sure that Ubuntu will release with a beautiful 3D greeter that has a wonderful transition to the desktop. It's just a shame that it won't do any of the useful things that the existing implementations already do.

And if you think that when LightDM finally has the full feature set of gdm, kdm and lxdm it'll still be fewer lines of code and take less memory - I hear the BSD kernel is lighter weight than Linux. Have fun with it.

GBrowse, a genome browser, is packaged for Debian since three weeks. It is the result of a work started four years ago, and I am especially grateful to Olivier Sallou for having unblocked and finished the project while I was starting to go round in circles, and to Aaron M. Ucko for repairing the new package, that was not compatible with our build farm. GBrowse and similar software, like IGV, are used for graphical representation of a chromosome and its annotations, such as the gene positions and markers of their activity, and in particular the result of experiments using high throughput DNA sequencing. A Debian Med task is actually dedicated to gather programs for that topic. In a couple of years, it may be possible that any person who wants can sequence his chromosomes, that is, his genome. This will revolution medicine and perhaps break some founding myths. Even if software for the general public will look different, packages like gbrowse are a first step towards a better access of the public to his medical data. Work continues on GBrowse, with the goal of being able to install it with a reference version of the human genome with a command like apt-get install human-genome. The next step will be to update BioPerl, used by GBrowse, to version 1.6.9.

Date for end of sponsored registrations for this years DebConf11 in Banja Luka was set for May 8th, today that date has officially been extended to May 19th. Now to answer your question on why are you extending sponsored registrations 12 hours before it ends here s the answer. Registrations are going fine, we have more then 300 attendees who registered so far, it is due to change in our monetary resources as sponsorship level has changed from one to another, and we ve be granted to welcome more people. But it is also to give some possible attendees more time and information, as I ve got a feeling a lot of people from this region and elsewhere have been lacking some even general information, and thus I d like to bring everything closer to everybody. Before anything, heading to our website might be a good start as we have immense amount of information up there. Since government of Republika Srpska is our greatest and main financial sponsor, local team has made a document for them in which we tried to explain most basic and crucial things from what DebCamp and DebConf is over logistical/statistical data to what we have planned for Fun and Free time, so checking out that document might be a good idea as well DebConf11 Plan and Program. Since that might be too much for somebody as the documents stretches to some ~30 pages, I ll try to give answers to most common/asked questions. Registrations Who should register? In plain English, everybody. Only people that don t need to register are people who will attend Debian day, please see Plan and Program section 5.3 for more information on Debian Day. If you want to attend any of the DebConf lectures/presentations/whatever you should register. Registrations will play great deal in this years DebConf as if you register you ll get accreditation with your name on it and what you re allowed to do. Whether you have sponsored food/accommodation and thus allowed to eat for free or that you can sleep in certain hotel, or whether you re allowed to the pools for free; also as we re planning to have tight security in our Venue, in order for you to even enter Venue building you ll need to have accreditation on you. So, if you re planning to do anything with DebConf please do register. What is DebCamp/should I attend DebCamp? Please refer to Plan and Program document it s all said at the end of page 15. Sponsorship After registrations this is next thing that is brought up and that is most unclear to most of you. You re able to request travel, accommodation and food sponsorship, what each of those means is pretty self elaborate. But the real question here might be, who is eligible to request sponsorship? Again, everybody. What are is the criterion for getting sponsorship? There really isn t a written rule who gets the sponsorship and who doesn t but if you have ever been involved or contributed in any sort of way to Debian, or even have contributed or have been involved in any open source projects you re more then welcome to apply for sponsorship. Furthermore, due to the funds that we have been granted from Government of Republika Srpska, I even encourage you to ask sponsorship, don t be intimidated and just do it Professional/Corporate This is category for those who are sent by their companies, and whose participation/attendance is sponsored by the same. Professional covers the price of actual costs of their visit, while the corporate is double that price, which is for those who besides paying the actual costs also want to contribute money and help Debian. Organized transport and getting to Banja Luka Now, for those who are flying to Banja Luka I personally told you to come to via Zagreb. Why did I do this, if Banja Luka has its own airport? I told you this because Zagreb is much larger airport and thus has many budget companies, meaning cheaper flights. Once the registrations are closed, based on your arrival/departure dates we ll be able to statistically predict how many of you will be coming to Zagreb on each date and each time as we re planning to have organized transport. This means that we ll send buses/shuttles to pick people up in Zagreb. Of course to have this organized we ll need to set up arrival/departure pages with all the information that s need for us to have this organized. Now, for those who want to come directly to Banja Luka airport this might be bit pricer then going via Zagreb, but not by much. I personally value my time and I even fly from Zagreb to Sarajevo Phil for example booked his flight just this morning from London via Ljubljanja to Banja Luka and it wasn t that much more expensive then Zagreb. Also worth noting is that Banja Luka might be limited for some destinations, but I for a fact know that there are flights coming from Zurich, Ljubljanja, Belgrade and so on. Maybe someone from Banja Luka could follow up on this one with more information. Questions? With this post I hope I have brought some of these topics closer to you and that I made some things clearer. If you have any questions, please feel free to leave your comments or email whatever you re concerned about to our mailing list on: debconf11-localteam@lists.debconf.org Further reading:
Gunnar Wolf Posts explaining DebConf

It is a fundamental part of my belief structure that computers should be silent, unless told otherwise. A default install of the operating system should not make any sounds, unless there is a really good reason to. Thus, I object to the following:

• GDM beeping when it is ready to let me log in
• login sounds
• sound effects whenever I do anything, such as open or close windows
• sound effects whenever the computer wants to tell me something that isn't particularly important, such as new e-mail, IRC or IM messages to me, the networking going up or down, or a hard disk going missing
• a beep when I reboot or shutdown the computer

I'm sure there are situations when it would be OK for my computer to make noise to alert me. For example, supposed I'm asleep, and a zombie has penetrated my defensive perimeters and is about to chop off the top of my skull so it can devour my brain. In that case, I would be OK with my computer beeping. Once. Some remedies:

• With gdm3, edit /etc/gdm3/greeter.gconf-defaults to set /desktop/gnome/sound/event_sounds to false
• Configure GNOME's sound theme to be "No sounds". (It should not be necessary to set "alert sounds" to muted, but it won't hurt either.)
• Run amixer -q sset Beep off to shut up wall and other such tools. (I made an init.d script to make that happen automatically, and to make sure I don't forget it when I install new machines for myself.)

Now, it's possible that other people might like or need their computer to make sounds. I imagine, for example, that the GDM login-ready beep is to help people with vision problems. I'm all for that. However, I wish it be easier to shut things up in one simple place for those of us who don't need it. Edit: Thanks to NP237, noshadow, lindi-, flightplan, and others on #debian-devel with help on shutting up wall.

I mourn the loss of thousands of precious lives, but I will not rejoice in the death of one, not even an enemy. Returning hate for hate multiplies hate, adding deeper darkness to a night already devoid of stars. Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. anonymous (often attributed to Martin Luther King, Jr.)

Seen many times today.

Here is my attempt at a summary of the rolling discussion currently happening on debian-devel@. It might not be complete, it s probably a bit biased, but I hope that it s still better than nothing. It was also posted on debian-devel@. If you are involved in Debian development, please discuss it on debian-devel@, rather than in the comments of this blog. If you want to provide feedback about the Debian rolling idea, use this Doodle poll and/or the comments of this blog.
Update : Someone had the good idea to vandalize the poll, and remove all the votes from people in favor of rolling. Before the vadalism (log), the results were:
37 votes: I am a Debian user, I use testing or unstable, and I would like rolling to happen.
6 votes: I am a Debian user, I use testing or unstable, and I DON T want rolling to happen.
17 votes: I am a Debian user, I use stable, and I would like rolling to happen.
3 votes: I am a Debian user, I use stable, and I DON T want rolling to happen.
7 votes: I am NOT a Debian user, but I would probably use it if rolling happened.
1 vote: I am NOT a Debian user, and I don t care about rolling. Motivations There s some user demand for rolling releases. For evidence, one can look at the usage of Debian testing or unstable which clearly goes further than the Debian development community. Or at the quickly growing market share of ArchLinux. Or at the interest in LinuxMint and Aptosid. Or at the DPL s report of his interactions with the press. Debian s only official product is its stable releases. While it s a clearly great and useful product, many users and developers don t recognize themselves in it: it contains software that is too old for their needs. The success of Ubuntu is related to this problem: Ubuntu proposes a different compromise between stability and up-to-date-ness. While concurrencing Ubuntu with more frequent stable releases (released every 6-months, for example) doesn t look like the right thing to do, Debian is in a perfect position to provide a rolling release with marginal additional work, since Debian already has testing (and unstable) to build on. The rolling discussion investigates how we could endorse the concept of a rolling release, provided as a product in addition to stable releases. This rolling release would be based on the current testing branch. Benefits for Debian:

• Attract users who think that testing is only a development branch, and want newer software than what one finds in stable. Those users are likely to be rather advanced users (free software developers and contributors), thus interesting to work with (able to submit good-quality bug reports, etc). Some of them could also become Debian contributors. And even if they don t, more users of testing/rolling means more testers of the next stable release [remember how the bug reporting rate of Ubuntu is higher than Debian's -- some areas of Debian could use more testers].
• Give back to the free software world by providing a platform where new upstream releases would quickly be available to users. Since users would be able to test new upstream releases earlier, they would be able to provide feedback to upstream devs earlier, contributing to a shorter feedback loop. Debian is often identified by upstream developers as the platform with releases from two years ago. I would love to see Debian in a position to contribute more to improviing the quality of the Free Software world.
• Get back some attention that is currently taken away from Debian by derivatives. This is important to carry our political or technical messages, which are not necessarily carried out by our derivatives.

Current proposed plan for rolling (Disclaimer: this is mostly my view. It is shared by others, but some details might not be) rolling is mostly about (external) communication. It is not expected to change our development processes fundamentally.
It would be a statement by the project (through a GR, for example). A very preliminary draft was proposed by Raphael Hertzog:

Title: Debian endorses usage of testing by end-users, and renames it to rolling The Debian project recognizes that the Debian testing distribution initially created to make it easier to prepare and test the next stable release has become a useful product of its own. It satisfies the needs of users who are looking for the latest stable versions of software and who can cope (or even appreciate) a system that s constantly evolving. The Debian project decides to endorse this usage and will strive to provide a good experience to users of testing . To better communicate this policy change to our users, testing will be renamed rolling .

Yes, it s mostly PR bullshit , and I don t expect it to significantly change Debian development processes. However, communication is necessary if we want to attract new users. What would change is more attention from developers to what happens in testing/rolling, which is a good thing since a better testing/rolling makes it easier to create stable releases from it. Open questions Most of the discussion is about the influence of the introduction of rolling on Debian development processes, and in particular, on the painful process resulting in stable releases. Many fear that, with rolling , it will be harder to get stable releases out. The root question is: if we do rolling, what do we do during freezes? Several options have been mentioned in the thread:

1. We could decide not to do anything special: just freeze rolling for ~6 months, as we used to freeze testing. That might bore people who like the constant flux of new upstream releases, but if we decide that it s the only way to ensure high-quality stable releases, so be it.
2. We could decide to fork a frozen branch when we freeze, and continue to manage rolling using migrations from unstable.
3. We could mix both solutions: freeze rolling for 3 months, so that most of the stabilization work occurs with a single active branch, and then, for the final release preparation, fork frozen off rolling, and unfreeze rolling.

Two kinds of objections have been raised:

• Those against the rolling concept:
  • It s only about PR, Debian isn t about PR. Answer: PR does matter sometimes, especially if we want to attract users.
  • There s usually no installer for it, other than installing the latest stable release and dist-upgrading, which doesn t always work. Answer: True; but it sounds like an acceptable problem. And if upgrades from the latest stable fail, it s an RC bug, so we would like to know. And if we do get d-i betas, it s a great way to get user testing for them.
  • It will split the developers base between supporting rolling and supporting stable releases (which also need to be supported after they have been released). Answer: already the case today.
  • Testing is not targeted at end users, but is a tool for the release team to create stable releases. It needs to stay that way. Answer: really, can t we do both?
  • Renaming testing to rolling will require changes in many parts of Debian infrastructure. Answer: some problems can be mitigated by keeping a testing symlink. The remaining impact needs to be evaluated.
• Those against the two development branches during freezes problem:
  • It splits the users and developers base between two branches (less users means less bug reports ; less developers means less bug fixing). Answer: true.
  • It requires the use of two different entry points for packages (unstable for packages targeted at rolling, frozen-proposed-updates for packages targeted at frozen). Answer: true.
  • All in all, huge overhead for the release team. Answer: true.
  • Overhead for developers, who need to support two targets. Answer: true.
  • Just after a stable release, we would start the next release from rolling, instead of stable. So we would start from a less clean base. Answer: true.
  • It s even worse if you consider staged freezes (freezing base packages earlier than the rest of the distribution, for example). Answer: true; but is it really a problem if some base packages are frozen in rolling for a few months?

Other things that were discussed:

• possible changes to processes around testing to make it more usable (reduce the set of architectures required for migration to testing ; allow/encourage usage of t-p-u to rebuild unstable packages that are ready to transition except for the fact that they are entangled in a transition ; have different level of RC bugs: there are RC bugs that are acceptable in rolling that are not acceptable in stable)
• PPAs for Debian
• Developer activity during freeze (developer temporarily stopping to work on Debian during freezes)
• Let s improve our packaging process or reduce the duration of our freezes before introducing rolling. Answer: but then, shouldn t we also stop doing stable releases for a while? ;)
• Setting up an official rolling instance . Answer: that can t work. detailed answer
• Using unstable instead of testing as the basis for rolling. Answer: there seems to be more demand for something similar to testing, than for something similar to unstable.

Tentative personal conclusion I have the impression that advertising testing as a rolling release usable by end-users is generally considered a good thing.
The renaming of testing to rolling is not as consensual, but most opponents have a whatever ; if you want position. How we deal with freezes is the hard point in this discussion. I m personnally in favor of the freeze rolling for 3 months, then fork frozen and unfreeze rolling plan, though it has some problems too (it is not clear whether the required manpower really decreases at the end of freezes). Where do we go from there? After another round of discussion, we might postpone the how to deal with freezes question to later, and proceed with a GR to measure the support for the testing for end-users + s/testing/rolling/ proposal.

Today I resigned from the Debian project. The following packages are up for adoption:

• asql
• chronicle
• rinse
  • Thomas Lange is going to take this one by the looks of things.

I'll remove myself from Planet Debian tomorrow, assuming the keyring revokation isn't swift and merciless. ObQuote: This space is intentionally blank.

The discussion about Debian rolling started sooner than expected on debian-devel (see the thread here). I initially wanted to iron out the biggest problems through discussions on my blog and try to submit a somewhat polished proposal instead we ended up discussing the same things both on -devel and on my blog. That said it s not that bad (except for the time I lost to have similar conversations in both places) because the debian-devel discussions included members of the release team and it looks like they are not fundamentally opposed to the idea. Despite this, the introduction of a frozen suite branched off from testing/rolling is not really consensual (yet?). But the idea of officially supporting testing on a best-effort basis appears to have almost no opposition. While some will undoubtedly believe that this is a useless exercise, I believe it would help if the project stated this in a somewhat official manner. My answer to the question in the title is thus: I am thus considering to submit a general resolution to that effect. My current draft is below.

Title: Debian endorses usage of testing by end-users, and renames it to rolling The Debian project recognizes that the Debian testing distribution initially created to make it easier to prepare and test the next stable release has become a useful product of its own. It satisfies the needs of users who are looking for the latest stable versions of software and who can cope (or even appreciate) a system that s constantly evolving. The Debian project decides to endorse this usage and will strive to provide a good experience to users of testing . To better communicate this policy change to our users, testing will be renamed rolling . While we believe that this is a good move, we would like to remind our users that Debian is a volunteer project and that our resources are not infinite. Package maintainers are contributing to Debian on a best-effort basis. This means that they might not be able to properly support their package(s) in all distributions. In that case, the project recommends that maintainers apply the following priorities:

1. Support in stable (security updates, release critical bugs)
2. Preparation of the next stable release
3. Support in rolling

Note that this general resolution could have amendments with s/rolling/current/ and that would solve the bikeshedding over the name that started several times already. I deliberately separated Preparation of the next stable release and Support in rolling so that priorities are clear even if we decide to not freeze rolling and to introduce a frozen distribution to finalize the next stable release. I also did not go into too much details on the implications that it might have, it s best to leave that up to each contributor/team/etc. I hesitated to add a paragraph stating that we want to try to gradually improve the usability of testing but in the end I think it would be somewhat redundant. We re always trying to do our best when we decide to take on something. All comments welcome (even if you just agree and would be willing to second such a GR). Update: I will tweak the draft included in this article when I get good suggestions. Thanks to Lucas Nussbaum for the first one.

10 comments Liked this article? Click here. My blog is Flattr-enabled.

Guido Trentalancia started an interesting discussion on the SE Linux policy development list about how to manage the evolution of the policy [1]. The Problem The SE Linux policy is the set of rules that determine what access is granted. It assigns types to files and domains to processes and has a set of rules that specify all the permitted interactions between processes and files (among many other things). The policy evolves over time to match the requirements of programs (applications and daemons). As a program evolves the things that it does will change and the SE Linux policy will tend to evolve to permit the set of all operations that were requested by all versions because people only complain when things stop working not when excessive privilege is granted. So we need to periodically remove old allow rules from the policy. One difficulty in this regard is the fact that multiple versions of programs are often available for use at the same time. Debian in particular has a good history of providing separate packages for the old and new versions of programs such as Apache to meet the needs of users who want the tried and tested version and of users who want the newer version with better performance, more features, better documentation, or something else good. There is also a demand to have the same policy work with multiple versions of a distribution without excessive effort. Finally all the distributions that have SE Linux support have different people deciding when the new version of a daemon is ready for inclusion and therefore there is a need to support multiple versions for multiple distributions. So support for older versions of daemons can t be removed easily. One of the things I do to make these things a little easier to manage is to put ifdef( distro_debian', before any Debian specific bits of policy. When policy is conditional and only used in Debian I can freely remove it at any future time if Debian works well without it. Also it doesn t matter if such Debian specific policy allows access that is not needed or desired in other distributions, the only down-side to this is that sometimes other distributions need to repeat work that I did, they determine what access is needed for their configuration and discover that it was already enabled for Debian. What is Valid Policy? We went to only have Valid Policy (as described by Christopher J. PeBenito), so the challenge is determining what is Valid Policy. It seems to me that there are three type of access granted by valid policy (it is debatable whether type #3 is valid):

1. Access that is needed for an application to perform it s minimal designed task.
2. Access that is needed for the application to perform all the optional configurations, EG an ftpd running from inetd or as a daemon, and daemons like http server being granted access to ssl keys or not.
3. Access that is needed to perform all the operations the application requests, but which the application doesn t require or shouldn t require if it worked correctly.

Some common operations that aren t required include opening utmp for write, searching /root, and many other relatively innocuous access attempts which don t affect the program operation if they are denied. There are also many things such as writing temporary files to /root that don t seem unusual if the application developer is not considering SE Linux (but which are often considered bad practice anyway). Some of these things (like using /root for stuff that belongs in /var/lib) have the potential to break things (for the daemon or for other system processes) even if you don t consider SE Linux. How to deal with those types:

1. In most cases this can be determined without too much effort. For example a web server needs to listen on port 80 and read files and directories that relate to data. When writing policy I can write a lot of the allow rules without even testing the application because I know from the design what it will do. A large part of the other access is obvious in a I can t believe I didn t realise it would need this sense.
2. The main question here is whether we have booleans (settings which can be tuned at run-time by the sysadmin which determine how the policy works) to specify which optional tasks or whether we allow all access for optional configurations by default. The secondary question is when certain unusual corner cases should be not supported at all such that the people who do such unusual corner cases need to use audit2allow to generate local policy to allow their operations.
3. Sometimes we have to allow things that we really don t like. Even when we write policy to allow a daemon to do unusual things (such as using /root instead of /var/lib) it s still a lot better than running without SE Linux. Also SE Linux policy to allow such obviously broken things stands out and is a constant reminder that the daemon needs fixing, this is better than allowing symptoms of broken design to be forgotten.

How to Improve the Situation We could have comments in the policy source for everything that is in category 3. If the comments had a fixed format so that a recursive grep could find them all then it would allow us to more easily remove the gross things from the policy at a later date. But it seems to me that the main problem is a lack of people working on this. I am not aware of any people actively testing Debian policy for excessive privilege in regard to such issues.

• [1] http://oss.tresys.com/pipermail/refpolicy/2011-March/004115.html

Tomorrow Prince William will marry Kate Middleton. If we don t change anything he will probably become the King of Australia at some future time, so I think that now is the time to start discussing the options. Walter Block makes some interesting points in favor of longer terms for politicians and for having a monarch to get a long-term view of the national interest [1], he s not the only person to make such points, but he makes them in a better way than most. Of course the problem with this is the long history of kings not doing what s best for their country part of the ownership rights to property is the right to destroy it, so a monarch who owns a country therefore can be considered to have the right to cause the wholesale death of their subjects. There are some examples of President for Life political leaders demonstrating this at the moment. Even with a monarch who is generally a nice person and who has controls to prevent the worst abuses there is the possibility of Control Fraud. In the Constitutional Monarchy system that doesn t happen because a constitutional monarch has little power (no official position of power). But there is still the issue of whether the monarchy is any good. Charles Stross wrote an interesting post about the apparent human need to have a leadership figure [2]. So getting rid of a monarch tends to result in a president getting the trappings of a king, and if things go wrong (as they often do) then they get absolute power until the next revolution. It seems that having one person who is the head of government and the head of state (as done in the US for example) is a bad idea, they can start to think that it s all about them. I don t think that the US is at risk of getting a president for life in the near future and I don t think that Australia will do so if we become a republic, but that doesn t mean that the republican system works well. I think that the Australian system is working better than the US system and I will generally vote against any changes that make Australia more like the US. As long as the House of Windsor provides monarchs who are as sensible as Queen Elizabeth 2 I will vote in favor of the continued rule of the House of Windsor in preference to an Australian republic (if Prince Charles ever becomes king I may support a republic). A Way of Improving Things I want to have an Australian monarch. Someone who will live in Australia for most of the time (as opposed to a distant monarch who visits once a decade if we are lucky). Protocol should dictate that the Prime Minister and cabinet ministers are forced to show ritual respect to the monarch, bowing etc, and no touching. A separation between the person who performs most of the ceremonial functions and the person who actually makes the political decisions should help constrain political egos. When a Prime Minister feels the need to suck up to someone more powerful it would be better to have that person be an Australian monarch than the US president. Tradition has it that monarchs have to be descended from other monarchs (although there are cases of elected monarchs as happened in Danish history). An election for a monarch probably wouldn t work well in a modern political environment, so we need someone with royal ancestry. One possibility is to have a spare descendant of our current Queen become the monarch of Australia, I think it s quite likely that given a choice between remaining a UK prince or princess for the rest of their life and becoming the monarch of Australia there would be someone who would take the latter option and I expect that the Queen would consent to that arrangement if asked (she would have to prefer it to a Republic). Another possibility is the fact that Mary the Crown Princess of Denmark has more children than the Danish monarchy requires [3]. As she was born in Australia it seems likely that her children will have more interest in Australia than most royals and a skim read of some tabloid magazines indicates that her family is quite popular. I expect that if a Danish prince or princess was invited to become the monarch of Australia then this would be acceptable to the Queen of Denmark. In an ideal world there would not be such a thing as a monarchy. But as we don t get to have ideal voters and therefore our politicians are far from ideal it seems to me that the constitutional monarchy is the least bad system of government. Don t think that I am in favor of a monarchy, I just dislike it less than the other options. Finally the Queen is the Supreme Governor of the Church of England. I think that it would be good to have a separation between church and state and therefore anyone who is in a leadership position of any religious organisation should be considered unsuitable to be the monarch.

• [1] http://www.psychologytoday.com/blog/defending-the-undefendable/201101/term-limits-make-me-sick
• [2] http://www.antipope.org/charlie/blog-static/2011/04/make-it-stop.html
• [3] http://en.wikipedia.org/wiki/Mary,_Crown_Princess_of_Denmark

Sebastian Thrun gave an interesting TED talk about the Google driverless car project and explains how his main aim is to avoid all the needless road deaths that are due to human error [1]. Finally a good use for the Google street-view type data! AnnMarie Thomas gave an interesting short TED talk about using play-dough to make circuits [2]. There are two recipies for play-dough, the one made with salt conducts well and the one made with sugar conducts poorly. That allows making wires with salty dough and insulators with the sugar dough. John Robb has published an interesting article about a Chinese fake revolutionary group that is triggering a backlash from Chinese security forces [3]. Even if this isn t accurate it seems like a good way to make people hate their local security forces and thus demand political change. Chris Rock made an interesting observation, we aren t making progress on racial issues, white people are getting less crazy [4]. Red Hill has an interesting article about 486 motherboards with fake cache chips that were sold in the 90 s [5]. One thing I disagree with is that they blame the customers for seeking low prices. When a white-box PC cost $2000 (which is $3000 in today s money) it made sense to try and get the cheapest option possible. Now that major department stores sell name-brand laptops for $400 it really makes sense to buy name-brand quality rather than white-box rubbish. IHollaBack.org is an interesting project to combat street harassment of women [6]. Psychology Today has an interesting article by Joe Navarro (former FBI counter-intelligence agent and author) about the serious implications of attempting to detect lies [7]. His main point is that most people over-estimate their ability to detect lies and because the legal system believes such claims from law enforcement officers many innocent people get found guilty and criminals get away free! Cory Doctorow wrote an informative article about the ways of persuading people to pay for content that can be obtained for free [8]. The main message seems to be that the big media companies are doing things the wrong way in everything that they do. The news satire site CBS Breaking News has an interesting about page explaining their mission [9]. They stopped their automated disaster generator after the Japanese Tsunami, while I can understand them wanting to keep some good taste and be sympathetic to the plight of the Japanese people it seems that they have forgotten that there is always a disaster somewhere. The typical bus plunge is just as bad as the Tsunami to the people on the bus and their relatives! Psychology Today has an interesting blog post by Satoshi Kanazawa explaining how criminals don t specialise, the psychological factors that make someone likely to commit one crime will make them likely to commit others, this makes it logical to collect DNA samples from all criminals [10]. Psychology Today has an interesting blog post by Dave Niose about a landmark US legal case in 1948 where Vashti McCollum had to escalate to the Supreme Court to allow her children to receive secular education [11]. We need something like this in Australia now as the religious extremists are going too far in indoctrinating children. Sam Richards gave a TED talk titled A Radical Experiment in Empathy which aims to teach Americans how to understand the way that people in the middle-east feel [12]. The comments suggest that his talk wasn t successful. Of course the fact that empathy doesn t have a clear definition in the English language doesn t help, and the fact that most people don t seem to interpret it in any way that corresponds to any dictionary and that most people seem unable to define what they mean by it makes things worse. At the moment I can t think of any examples of successfully teaching empathy to unwilling people. The people who want to learn will do so eventually, you can have some good success in helping them to learn faster. Kathryn Schulz gave an interesting TED talk about Being Wrong [13]. One interesting point that she makes concerns the way that people assume that people who disagree are ignorant, stupid, or evil instead of just having a different set of data or a different understanding of the same data. Of course it is possible for someone to be ignorant/stupid/evil AND have a different understanding. Marcin Jakubowski gave an inspiring TED talk about his project to develop free blueprints that allow anyone to create all machines needed to sustain civilisation with minimal cost [14]. His Open Source Ecology project has a blog and a wiki with blueprints and files for CAD/CAM [15]. Dave Meslin gave an insightful TED talk about apathy in the political process [16]. Among other things he compares council notices that supposedly request citizen input with adverts for running shoes which encourage people to buy them. One thing he didn t mention is the difference that technology can make, a short council advert with a QR code is probably a lot more useful than the current dense text-based adverts for today s audience.

• [1] http://www.ted.com/talks/sebastian_thrun_google_s_driverless_car.html
• [2] http://www.ted.com/talks/annmarie_thomas_squishy_circuits.html
• [3] http://globalguerrillas.typepad.com/globalguerrillas/2011/04/the-jasmine-revolution.html
• [4] http://www.youtube.com/v/z_L7qoP17-w
• [5] http://www.redhill.net.au/b/b-bad.html
• [6] http://www.ihollaback.org/
• [7] http://www.psychologytoday.com/blog/spycatcher/201010/detecting-lies-v-detecting-truth-serious-implications
• [8] http://www.guardian.co.uk/technology/gamesblog/2011/apr/20/digital-free-persuade-pay-cory-doctorow
• [9] http://cbsbreakingnews.com/about
• [10] http://www.psychologytoday.com/blog/the-scientific-fundamentalist/201008/does-it-make-sense-collect-dna-samples-misdemeanor-convict
• [11] http://www.psychologytoday.com/blog/our-humanity-naturally/201104/atheist-mom-goes-the-supreme-court-and-wins
• [12] http://www.ted.com/talks/sam_richards_a_radical_experiment_in_empathy.html
• [13] http://www.ted.com/talks/kathryn_schulz_on_being_wrong.html
• [14] http://www.ted.com/talks/marcin_jakubowski.html
• [15] http://opensourceecology.org/
• [16] http://www.ted.com/talks/dave_meslin_the_antidote_to_apathy.html