Love and maintenance needed: Kaffeine

Opportunity ahead! Rex Dieter recently posted this link into the #kde channel: http://permalink.gmane.org/gmane.comp.video.kaffeine.devel/1255. Here we find that the Kaffeine maintainer Christoph Pfister has found it necessary to step back from maintaining Kaffeine. He says to be qualified if you should know a bit about Qt and KDE and preferably have some Dvb / Atsc equipment at hand.

This probably describes a lot of the folks reading this post. Do you have the time and desire to love and polish Kaffeine? Please join the Kaffeine-devel mail list and step forward. https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

If you know of any other projects needing more love and care, please write the Community Working Group, Community-wg@kde.org. Another good list to connect to is the new general Community list: KDE-Community@kde.org.

Good cheer to all this holiday season!

Nelson Mandela is gone

I heard this afternoon on the radio that Nelson Mandela has died. Since it was NPR (National Public Radio), I soon heard a BBC documentary on Mandela, including his teaching the interviewer about ubuntu. That bit really pained me; he's gone, and his gentle idealistic flame is no longer lighting the world.

Hear him explain it on Youtube: http://www.youtube.com/watch?v=vt72ORXUlao

But we have that flame too. Ubuntu the community and Linux distribution family takes inspiration from the concept of ubuntu. To me, the world encapsulates all of what is good in the open, free, software movement, and the free culture movement too. Mandela saw himself as human, no matter how inhumanly he was treated. He knew that bitterness and hatred on his part would engender bitterness and hatred in his beloved South Africa, and he wanted instead love, understanding, forgiveness, and democracy. I hope to continue to see his ideals in the Ubuntu community, and in my Kubuntu corner in particular.

I've often thought of Mandela as the embodiment of the saying be the change you want to see. Rest in peace, Madiba.

Changing behavior

I just finished a book called The Science of Consequences, by Susan M. Schneider. A couple of items in the Glossary struck me as interesting (yes, I'm the sort of person who reads the glossary and endnotes!).

Negative: If a behavior declines because of a consequence, that consequence is a negative (a punisher, an aversive) and the relationship is punishment. (Note that the negative can be an outcome involving the removal of a positive....)
It's important to note that things that seem like negatives sometimes aren't; what matters is what actually happens, not the intention or the appearance.... "Negatives" that have no effect on a behavior are not truly negatives; indeed, if the behavior is strengthened, they are reinforcers. Again, it's what actually happens that matters. [p263]

Reinforcement: When a consequence sustains a behavior, the relationship is reinforcement....The consequence can be an outcome involving the presentation of a positive, or the removal of a negative, or both simultaneously. [p263]

These are good things to keep in mind as we interact with others in life, and in our projects. Things go well when there is a ratio of 5/1 positive/negative. Things go badly when that ratio is reversed; you see divorces, the end of friendships, and forks in projects.

I'm mostly publishing this to remind me to pass along compliments, and remember to thank people for the good work they do. Thanks should outnumber bug reports and other complaints FIVE to ONE!

The Horse, The Wheel and Language: How Bronze-Age Riders from the Eurasian Steppes Shaped the Modern World

Just finished the most amazing book: The Horse, The Wheel and Language: How Bronze-Age Riders from the Eurasian Steppes Shaped the Modern World by David W. Anthony. It is a wonderful mix of historical linguistics and archaeology, packed with information from Russian research not seen in English before.

Tl;dr summary: Half the world speaks Indo-European languages, which spread from folk who domesticated the horse and used the wheel to carry their culture and language out from the Eurasian steppes. Among the cultural concepts discussed is how differing moral codes can hold neighboring cultures apart, creating long-lasting cultural borders.

I came to the book from The History of English podcast which I discussed earlier on this blog. This whole wonderful journey started with Eike Hein's frequent recommendation of The Decipherment of Linear B, which I also blogged about late last summer. One of the comments by Adrian Łubik on G+ led me to the history podcast, which led me to The Horse, The Wheel and Language. And the side voyage through an alternative old world with the Kushiel's Legacy books made this journey even more enjoyable and enlightening.

You would think that the beginnings of English, its forebear languages and the people who spoke them would be a dry, dusty topic, throwing no light on our culture, beyond our languages themselves. And oh, by our languages I mean most all of the languages spoken west of Russia and China, and north of Africa. This includes not only Greek and Latin and the rest of the Romance languages, but also the north Indian languages, all of the Norse and Germanic languages including English, and also all the Celtic tongues. Of course now this also includes most of North and South America as well.

How did a small group of prehistoric foragers spread their language over most of the world? To answer this question, the book uses not only the latest linguistic research, but also the archaeological evidence from all over Old Europe, the steppes covering the Ukraine and southern Russia, and many other Indo-European sites. Much of this research was unavailable to the West until recently.

One important discussion early on is explaining why this sort of analysis has not been done before. The sad truth is that with early linguistic and fragmentary archaeological evidence, some terrible theories of the "true homeland of the pure-blooded Aryans" were created and used to bloody effect. Race itself is only a social concept, not a biological reality. What Anthony examines is the evidence of the lives of these people, how they lived and died, what they ate, their social structures, migrations, and language.

Some of this evidence is tenuous, but the difference between groups becomes more clear and obvious at the borders between them. As we know, most borders are porous, and people move back and forth even in modern times, where we have states enforcing those borders. However, some cultural borders are long-lasting, even with no state involvement. A modern example Anthony uses is the English / Welsh, and the English / Scots. People might move back and forth between these regions of the UK, but the cultural difference and even language difference remains. Cultural borders are even stronger when there is also a geographic difference (ecotone) which differentiates how people make a living. The river valleys, steppe, and steppe-forest acted as borders separating people in the Eurasian steppe region for hundreds and in some cases, thousands of years.

Anthony says:

The North Pontic societies east of the Dniester frontier continued to live as they always had, by hunting, gathering wild plants, and fishing until about 5200 BCE. Domesticated cattle and hot wheatcakes might have seemed irresistibly attractive to the foragers who were in direct contact with the farmers who presented and legitimized them, but, away from that active frontier, North Pontic forager-fishers were in no rush to become animal tenders. Domesticated animals can only be raised by people who are committed morally and ethically to watching their families go hungry rather than letting them eat the breeding stock. Seed grain and breeding stock must be saved, not eaten, or there will be no crop and no calves the next year. Foragers generally value immediate sharing and generosity over miserly saving for the future, so the shift to keeping breeding stock was a moral as well as an economic one. It probably offended the old morals. It is not surprising it was resisted, or that when it did begin it was surrounded by new rituals and a new kind of leadership, or that the new leaders threw big feasts and shared food when the deferred investment paid off. These new rituals and leadership roles were the foundation of Indo-European religion and society. [p154-155]

Another contrast between the older societies and those of  the new farming and herding, was whom they worshipped. The goddesses of Old Europe were maiden/mother/crone figures, found in most rooms of each house, where people lived in villages. The steppe dwellers worshipped a sky god, and often a war god, and sacrifices were blood and meat. Images were not found; instead, piles of bones from the ritual feasts. So the gods that people worshipped typified the society: the partnership societies had goddesses and god who seemed friendly, helpful, and part of everyday life, while the herders and farmers worshipped distant, untrustworthy gods who had to be placated with blood sacrifices.

Anthony says,

Participation in long-distance trade, gift exchange, and a new set of cults requiring public sacrifices and feasting became the foundation for a new kind of social power. Stockbreeding is by nature a volatile economy. Herders who lose animals always borrow from those who still have them. The social obligations associated with these loans are institutionalized among the world's pastoralists as a basis for a fluid system of status distinctions. Those who loaned animals acquired power over those who borrowed them, and those who sponsored feasts obligated their guests. Early Proto-Indo-European included a vocabulary about verbal contracts bound by oaths ... used in later religious rituals to specify the obligations of the weak (humans) and the strong (gods).... As leaders acquired followers, political networks emerged around them--and this was the basis of tribes.
... The Pre-Proto-Indo-European language family probably expanded with the new economy during the Early Eneolithic in the western steppes. Its sister-to-sister linguistic links may well have facilitated the spread of stockbreeding and the beliefs that went with it. [p191]

When I read the paragraphs I quoted, I couldn't help but think about an article I had read earlier, about an interesting aspect of American politics today: Tea Party radicalism is misunderstood: Meet the “Newest Right.” In the article, the author, Michael Lind says,

... The dominant members of the Newest Right are white Southern local notables—the Big Mules, as the Southern populist Big Jim Folsom once described the lords of the local car dealership, country club and chamber of commerce.  These are not the super-rich of Silicon Valley or Wall Street (although they have Wall Street allies). The Koch dynasty rooted in Texas notwithstanding, those who make up the backbone of the Newest Right are more likely to be millionaires than billionaires, more likely to run low-wage construction or auto supply businesses than multinational corporations. They are second-tier people on a national level but first-tier people in their states and counties and cities.

These are the same people! The same leaders (patrons) who got big herds, and got clients by lending out stock, only now their stock is cars and trucks, construction jobs and such. To be clear, Anthony never draws such a link; this is entirely my own comparison.

When in Genesis 4:9 of the Christian Bible, God asks Cain, "Where is Abel your brother?" He said, "I do not know. Am I my brother's keeper?" It seems to me that Cain answers a question with a question in the same way that the leaders within this cultural system always have done. They do not feel a responsibility to the poor, the widow, the orphan. Their morality is based on saving for the future, and building a following, a clientele. The thing is, we live in a world where there is food enough for everyone. There is no need to starve the children! There is plenty of seed corn.

To tie up this long review, I'll close with a final quotation, from Anthony's summary chapter, Words and Deeds, page 459:

Innovation in transportation technology are among the most powerful causes of change in human social and political life. The introduction of the private automobile created suburbs, malls, and superhighways; transformed heavy industry; generated a vast market for oil; polluted the atmosphere; scattered families across the map; provided a rolling, heated space in which young people could escape and have sex; and fashioned a powerful new way to express personal status and identity. The beginning of horseback riding, the invention of the heavy wagon and cart, and the development of the spoke-wheeled chariot had cumulative effects that unfolded more slowly but eventually were equally profound. One of these effects was to transform Eurasia from a series of unconnected cultures into a single interacting system. How that happened is a principal focus of this book.
[p461]...The institutions that regulated peaceful exchange and cross-cultural relationships were just as important as the institution of the raid.
The reconstructed Proto-Indo-European vocabulary and comparative Indo-European mythology that two of those important integrative institutions were: the oath-bound relationship between patrons and clients, which regulated the reciprocal obligations between the strong and the weak, between gods and humans; and the guest-host relationship, which extended these and other protections to people outside the ordinary social circle.
Archaeology and Language
Indo-European languages replaced non-Indo-European languages in a multi-staged, uneven process that continues today, with the world-wide spread of English. No single factor explains every event in that complicated and drawn-out history--not race, demographics, population pressure, or imagined spiritual qualities. The three most important steps in the spread of Indo-European languages in the last two thousand years were the rise of the Latin-speaking Roman Empire (an event almost prevented by Hannibal); the expansion of Spanish, English, Russian and French colonial powers in Asia, America and Africa; and the recent triumph of the English-speaking Western capitalist trade system, in which American-business English has piggybacked onto British-colonial English. No historian would suggest that these events shared a single root cause. If we can draw any lessons about language expansion from them, it is perhaps only that an initial expansion can make later expansions easier (the lingua franca effect), and that languages generally follow military and economic power.

Let's get the Code-In Task Collection in Gear!

This blog post is stolen! Blatantly thieved from Lydia, who so sweetly wrote to a few lists earlier, saying:

Google Code-in is a great opportunity to attract new bright young minds to KDE. We've taken part in the contest 3 times already and I just filled out our application for the 4th one. (If you have no idea what I am talking about have a look at https://www.google-melange.com/gci/homepage/google/gci2013 for more
information.)

Within the next 2 weeks we need to collect tasks for the 13 to 18 year olds to work on during Code-in. These tasks are the most important part of our application. Please help find exciting and useful tasks and submit them via this form:
https://docs.google.com/forms/d/17C81ExuBcgU5_Wkj1Zt035vCxbquhS61Lzob2oX4R8U/viewform

You can see all tasks already submitted here: https://docs.google.com/spreadsheet/pub?key=0Al1cWa29jR2idGE5VGI2Uno5TEJrelFURHZVd2NvNkE&output=html 

And for some inspiration here are the tasks we offered last year:
http://community.kde.org/GoogleCodeIn/2012/Ideas

It would be amazing to see especially previous Code-in and GSoC students offer tasks here and mentor the next bunch :)  To see what kind of an impact this program can have check out
http://dot.kde.org/2013/07/15/akademy-2013-day-two

Cheers
Lydia
PS: I am about to head off to Brazil for the next 11 days. In case of questions I hope Teo, Myriam, Valorie and David will be able to help as well.

To this, I can only add: We're always available in #kde-soc on Freenode IRC, and on the Community list. Let's kickstart this list of tasks, and rev up this year in Code-In!

Oh, I hope Lydia doesn't sue me for stealing her intellectual property!

Celebrating Kubuntu 13.10 release

This was such a nice release. Working with the team as part of the Council has all been delightful, and working with the rest of the documentation team was great, as well. We were very ambitious, and didn't finish all of what we started, but we're very proud of the documentation we're publishing with this release. We plan to finish and polish for the LTS 14.04. I loved being able to test a bit this round, as well.

Besides documentation, Kubuntu has lots of improvements this outing, and we now have paid support available, along with a shirt shop! See http://www.kubuntu.org/news/kubuntu-13.10 for more information. I just ordered my polo shirt, and it took less than 5 minutes. Can't wait for mail from Finland!

I seed all the *buntu torrents each release. This time out, the torrents.ubuntu.com is maxed out! I hope to begin seeding more torrents tomorrow, when the servers are a bit less busy.

Temptation

Chani recently blogged about How to Not be a Rockstar. It's excellent, give it a look. And her piece got me thinking about how we are always being tempted, by social pressure, by advertising, by the oppressive side of our culture, to worry about the surface of reality, instead of engaging with actual life.

Often, parents have taught us to be obedient and pleasant, rather than capable and independent. That's easy to understand; they get kudos for having obedient and pleasant children, and disapproval for raising kids who rock the boat, are messy, creative, loud or otherwise 'out of the norm.' Also, obedient and pleasant children are easier! So most of us have that early training to overcome. There is nothing wrong with being pleasant, but knowing how to do stuff, and not being afraid to do it, are what is needed to build a life.

In school, most of us have teachers who carry on with that program, and try to help us get good grades, and pass tests. How many of us are lucky enough to have teachers who challenge us to learn, who whet our curiosity, and then teach us how to find our own answers? Of course schools are established to enculturate children, and to pass along the basic canons of knowledge. Should the good school, the excellent teachers stop there, or use that as the foundation for life-long learning? I have nothing against good grades, and passing tests, but those are merely the appearance of learning. What good does it do to have good grades, if you haven't really mastered the material? If you've only been exposed to what's on the test; and don't know or don't take the time to learn more?

What is taught in home and school is only part of the problem facing children and teenagers. School social systems are often so toxic to kids that they learn to hide their true selves, rather than learning who they are, what they want, and what sort of people suit them as friends, lovers and collaborators. Aren't these the keys to a happy, successful life? Or do we really want to produce cogs which fit into society's machine, producing the same old stuff?

I think this weakness, this worship of the shallow in our culture is what has fueled the growth of both art and FOSS communities. We humans long to produce work that improves the world, and collaborate with people who share our values. In FOSS communities there are a multitude of ways to create cool stuff, whether we love coding or art, design or making great UI, writing or making websites. I think everyone who contributes is not only 'scratching their itch,' but also making the world a better place, and changing our culture for the better at the same time.

Kushiel's Legacy: books set in alt-medieval Europe

I've just finished a great series of books by Jacqueline Carey. Not only were the books well-written, but also sex-positive, and set in a fascinating period of history/alternate history. Fallen angel Blessed Elua is the founder of Terre d'Ange (resembles France), the "Land of the Angels" and with his companions, ancestor of the  D'Angeline people. The command he left was "love as thou wilt", and the novels are an examination of how love and sexual freedom could have changed the world.

There are three intertwined trilogies. The first, Phèdre Trilogy series follows the story of Phèdre nó Delaunay, the foremost courtesan of her day. Phèdre was a thrilling hero, as she and her bodyguard, companion and lover, and eventual consort, Joscelin Verreuil traveled far and wide. In the final novel of the trilogy, they find and save their eventual foster son, prince Imriel.

The Imriel Trilogy series (UK title: Treason's Heir trilogy) follows the story of Imriel de la Courcel nó Montreve. It was lovely to see Phèdre and Joscelin again, as minor characters, and to see Imriel overcome the horrors of his past and his treasonous ancestry.

The final books are set one hundred years later. Called the Moirin Trilogy, they follow the story of Moirin of the Maghuin Dhonn from Alba, who is half D'Angeline. These books take us to China, Mongolia, Russia (or perhaps the Ukraine), up into the Himilayas and down into India, and finally to the Aztec and Inca civilizations.

I really loved these books. They have enriched my thinking about religion, love, sex and human nature and the power of ideas playing out in history. The characters were wonderful to spend time with, and as usual I love seeing cultures in contrast.

Banned books!

Great article on Forbes: Five Banned Books That You Should Read (That You Probably Haven't). I had not read any of the five, but now am planning to do so. Fortunately, the two recent books are available at my local library, so I've ordered them. And the classics Dialogue Concerning the Two Chief World Systems by Galileo Galilei, Zhuangzi and The Epic of Gilgamesh are all available free for download. I just searched for the title plus free ebook.

I just love my old Kindle for reading stuff like that, and the free application Calibre for managing the downloaded files. It can even be used as a reader, although usually I only use that function to check that the files are readable. (Calibre is available as a package for most linux distros, including Kubuntu)

Over and over, I've been surprised by old classics. They seem to be fusty and boring, until I get into the rhythm of the older language. At that point, it's easy to appreciate why they have become classics. And my recent podcast listen to the History of English has given me a renewed sense of the sweep of history and our modern world's place in that history.

Read the classics! Read banned books, and open your mind!

History of the English Language (and further adventures in the CLI)

Language and history geeks, I want to tell you about a wonderful podcast called History of English. Unfortunately for us FOSS types, it is only available via iTunes (according to the podcast. However, the website gives an RSS feed url). But the author, lawyer Kevin Stroud, allows download of the episodes. In order to listen to them in Amarok, rather than relying on flash on the website, I used wget on all of the episodes to present.

* Fortunately, I waited a day to publish this! I've always used Amarok to fetch and store my podcasts automatically, as well as to play them. I wanted to try out the gPodder service as well, which is needlessly complicated on the website. Fortunately, I decided to just add it via Amarok, and the plugin works flawlessly. So all the wgetting is only necessary if you want to fetch and listen to the episodes outside of Amarok, etc. RSS feed url: http://historyofenglishpodcast.com/feed/podcast/ *

Please visit the podcast website for maps and to leave comments, even if you download: http://historyofenglishpodcast.com

If you want to copy all the episides, first create a directory (put it in your ~/Music directory if you want it in your Music collection): mkdir HistoryofEnglishPodcast && cd HistoryofEnglishPodcast, then do the wgetting from that dir.

Since all the eps are individually named, I copied my commands from the terminal by giving the command history and copying them! Thanks to http://tech.karbassi.com/2007/01/14/view-and-change-bash-history/ for that useful command.

wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep01-Introduction.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep02-Indo-European-Discovery.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep03-TheIndo-EuropeanFamilyTree.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep04-Grimm-Brother-Resurrects-the-Dead.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep05-Centum-Satem-and-Letter-C.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep06Indo-European-Words.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep07-More-Indo-European-Words.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Bonus-Episode-1.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep08-Indo-European-Grammar.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep09Who-Were-The-Indo-Europeans.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep10Early-Indo-European-Migrations.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep11Germanic-Ancestors.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep12Early-Greek-Hittite-and-Trojan-War.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep13Greece-Phoenicia-and-the-Alphabet.mp3
 2009  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep14Greek-Word-Horde.mp3
 2010  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep15Etruscans-Romans-and-Modified-Alphabet.mp3
 2011  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep16Rise-of-Rome-and-Latin.mp3
 2012  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep17Ancient-Celts-and-Latin-Invasion-Gaul.mp3
 2013  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep18Keeping-Time-With-Romans.mp3
 2014  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep19-Romanization-of-Britain.mp3
 2015  wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep20-Early-Germanic-Tribes.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Bonus-Episode-2-History-of-Alphabet2.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep21-Early-Germanic-Words.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep22-Early-Germanic-Grammar.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep23-Tacitus-and-Germanic-Society.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep24-Germanic-Mythology.mp3
 wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep25-Germanic-Markings-and-Runes.mp3
 wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep26-Imperial-Crisis-and-Goths.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep27-Broken-Empire.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep28-Angles-Saxons.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep29-Anglo-Saxon-Invasion.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Bonus-Episode-3.mp3
wget http://media.blubrry.com/historyofenglish/p/content.blubrry.com/historyofenglish/Ep30-Celtic-Legacy.mp3

Enjoy!

The wonderful book The Decipherment of Linear B is also a great look at language and history, which I recently wrote about.

Coffee and Doctorow

KDE Planet often has some thought-provoking blogs, whether or not they are "strictly" speaking, about the KDE community or our software. For example, Jeff blogged about how to make cold-brewed coffee. When I read that, I remembered that we used to have a toddy kit, like this one listed on Amazon.

When I was looking for a light book to read, Adityab suggested Little Brother, by Cory Doctorow. Since it's available for download for my kindle, yes! It is light as in 'short and YA,' but rather serious in considering the consequences of the increasing use of government surveillance, and where that can lead. Fortunately, the young hero of the book creatively fights back. Also, it is set in San Francisco, a city I love. Highly recommended.

I found out that Doctorow has recently followed up Little Brother with Homeland. The first section of the book takes place at Burning Man, which was really cool. The up-to-the-minute timeliness is alternately delightful and scary. So what did our heroes bring to Burning Man to share around? Cold-brewed coffee! The 'desert process' was even more relaxed than Jeff describes. With this second reminder, I dug around in the cupboard over the refrigerator, found the toddy, and brewed up some coffee.

Now I've gotten into a rhythm with it. No measuring, and I usually steep it a couple of days, since as soon as I empty the carafe, I bring out the steeping grounds, filter them, clean out the grounds and felted filter, and start the process again. It takes me a few days to drink the delicious coffee, and letting it steep longer just seems to make it better. I just use pre-ground coffee for now, but I'm going to investigate getting a grinder, since I do love the aroma of fresh-ground coffee.

Why did we ever stop using the toddy? I wish I could remember, but I think we are using it from here on out. Even my husband who loves the aroma of fresh-brewed coffee, is switching to the toddy coffee on weekends. Give it a try, and enjoy! And snap up some Doctorow. He might just re-inspire you to do some more free software work. Individual people are the ones who make the difference.

Confrontation is scary! Confront your fear.

One of my recent CWG (KDE Community Working Group) emails said, in part:

...the confrontation seems to have clarified some issues...

Of course! That is what confrontation is about. It isn't necessarily a power struggle, although it's usually seen that way. Confrontation, argument, fights are all about issues. Of course sometimes the issue is power, and access to resources, but more often the issue is about how to get to a shared goal or value. Confrontation is best and most productive when it clarifies: How can we best collaborate?

Arguments aren't bad! They bring issues out in the open. And if people learn to 'fight fair' - focus on resolving issues, not people, not positions, then stuff gets done. Even if you aren't directly involved in an argument, sometimes your part is to remind the 'opponents' of that, and support them as they 'get to yes.' If there is anger involved, it's good to be able to blow off steam without injecting that heat into the argument itself. Often a friendly ear is invaluable there.

I think confrontation is scary to people because most of us are taught as children NOT to confront, but to obey authority. This is understandable from the parents' point of view, but over the long term, people need to learn confrontation, negotiation, and fighting fair. As a parent I tried to teach my kids how to fight fair --even with me. Because mama is not always right.

I've only been in the community for a few years, so I can't compare 'the old days' to now. The KDE, Kubuntu and Ubuntu communities are spread all over the world, with people from a lot of different cultures; it would be amazing if we had no misunderstandings, spats, fights, disagreements. It is my hope that we all learn to do this better, and remember to be respectful during the struggle.

The Codes of Conduct are our support here. A CoC is often seen as a club, or a codification of law, which I think is wrong. Re-read your CoC, and I think you'll find that it is a description of the community we want, and the way we want to work. I hope to see fewer mentions of "CoC violation" and more examples of living up to our shared ideals. Read 'em again:

KDE Code of Conduct: http://www.kde.org/code-of-conduct/

Ubuntu Code of Conduct: http://www.ubuntu.com/about/about-ubuntu/conduct

Linuxchix boils it down the best, I think. Two rules: Be polite, and be helpful.

The Decipherment of Linear B

This wonderful little book has been recommended quite a few times by my friend Sho_. Today it arrived from the library, and I'm so happy to have read it. Yes, it's slim and readable; with afterward and appendices less than 150 pages. It's a loving tribute to Michael Ventris, who 'broke the code' of Linear B, then died before his publication presenting it to the word, by his co-author, John Chadwick.

Why a book on such an obscure subject? Yes, it's about Mycenaean Greek! But more important, it's about how a young person with an interest in languages and training in architecture (Michael Ventris) could use this background to crack one of the biggest mysteries revealed by modern archaeology. And he contradicted the leading experts and prevailing opinion that Linear B could not be Greek. When he proved that the Mycenaeans spoke Greek, he pushed the beginnings of European history back many centuries.

Ventris won over the experts by doing careful analysis, and always sharing his work as he proceeded. In fact, after reading all the published research, he began his work by surveying the twelve leading experts with a series of questions. This questionnaire was penetrating enough that he got ten answers. After compiling these answers and adding his own analysis, he sent out the survey results to all the experts. By getting a good grasp of current scholarship, he had built a wonderful foundation on which to build his study of the inscriptions.

Although it has not been proven that Ventris did any code-breaking during the war, his method of analysis certainly owes much to that Bletchley Park work. Also discussed here is Alice Kober, whose early work set Ventris on the right path. Her card catalogue was invaluable to Ventris, after her life was cut short by cancer. Ventris always consulted other experts, and was generous in sharing credit. He never succeeded in proving what he set out to do, which was prove that Linear B was Etruscan. Instead, he put in the hard work of analysis of all the evidence, and followed the trail to the end, proving what he started out believing impossible: Linear B is ancient Greek.

Read this book, and be inspired! Grab it used or get it from the library as I did. Although available for Kindle, the symbols render badly in that edition.

Getting a Green Thumb

The phrase green thumb comes from gardening. When a person is really in tune with their garden plants, they often rub off nubs which will become branches in the wrong place, or pull out small, tender weeds before they grow to be pest-sized, thus ending up with green-stained fingers and thumbs. In our community, such tuned-in consciousness can help us grow and thrive. When one sees or hears a comment heading into negative territory, each of us can perhaps take a moment to ask the commenter more about their situation. Maybe they have encountered a bug, or just don't see how to choose to do what they need to get their task done. If you are a developer, maybe their difficulty can guide you toward a better user interface! If you do documentation, their questions and difficulties might help you explain the software more clearly. Perhaps the person is feeling bad for some other reason entirely. In any case, by asking for more information, you will effectively have turned what could have turned into a "trollish" situation, into a pleasant personal interaction and maybe more. Of course not all of us have the time or feel like spending our time being tuned in all the time. Which is why I urge each of my readers to take your turn by doing this part of the time. Our list moderators, IRC channel operators, and forum admins get tired, have vacations and other time off, and so forth. We can all be leaders of the community part-time, in this gentle, non-confrontational way. If you're good at it, and enjoy it, maybe it's time to volunteer to help moderate a list, become one of the channel operators, or help administer the forums. It is not necessary to have an official leadership position though, to exercise leadership. Perhaps you would like to become part of the KDE Community Working Group?[1] We have a need for a new team member right now. See the KDE-Community list for more information.[2] And see the Freenode Catalysts page [3] for more details about this mode of leadership. The Ubuntu 1. Community Working Group: http://ev.kde.org/workinggroups/cwg.php 2. KDE-Community list: https://mail.kde.org/mailman/listinfo/kde-community 3. Be a Catalyst: http://freenode.net/catalysts.shtml

Generosity, Family

After trying to connect to Mohammed Nafees, our GCi student winner from India, I finally was able to talk with him this afternoon. I was asking about his experience with KDE, and if he had gotten the help and support he needed. The enthusiasm of his reply was a bit surprising. He said he had chosen KDE because it is more than a community. When he couldn't think of the word he wanted to use to finish his sentence, I said that to me, KDE is family. He said, "YES! KDE is family."

Hours later, I'm still smiling about that. What a wonderful way to end the official Akademy program.

Right now, I'm typing this on my little netbook, surrounded by enthusiastic hackers. Even after working all day, most are hacking still at midnight! With occasional breaks for table tennis and pool, of course. The power cords snaking over the floor are hilarious!

Some of us paid our own way to this wonderful conference, but many of us are sponsored in whole or in part by the KDE e.V. Such generosity is what family is all about. However, as my mother used to say, money doesn't grow on trees! If you have not yet "Joined the Game", please think about signing up. Our e.V. needs a reliable funding stream to continue to support those who create the wonderful KDE ecosystem. http://jointhegame.kde.org/

I'm really here.....

Weeeeeee, Akademy!

This year for the second time I’ll be able to attend Akademy, the annual world meeting of the KDE community. We'll be in Bilbao, in the Basque country of Spain from 13th to 19th of July.



Check the full program here, and if you plan to come, register here. My endless thanks to the e.V. for sponsoring my travel. I hope to be able to pay for part myself this year, to spare the expense.

So much happens; I hope to see you there!

Catalyst Leadership

I read a list post thread tonight that saddened me. I won't say what community it is part of, or point out the participants, because it is far too common in many of our community meeting places, whether they be lists, IRC or forums. Stereotypes are used rather than names here.

Newperson speaks up, I think for the first time, wondering when a new project result will be put to use, and offering a possible sample.

Longtime Devel speaks up, using rather angry questions about how the old symbol came to be displaced.

Another Oldtimer speaks up defending the symbol, accusing Longtime Devel of being out of touch.

And on. And on. The listowners don't redirect the discussion, and when questions are asked, they are answered angrily.

Newperson probably has departed by this point.

This seems like a small occurrence, but it is bad for every single participant, and each bystander has the power to change the conversation at each point.

This blog is a call for each of us to think about our power to influence the community spaces we inhabit, to exercise leadership, to become a catalyst for dialog, to open up trust. When I was first asked to become an IRC channel operator, I was asked to read the Freenode Philosopy: Catalysts. Whether or not you use IRC, I recommend reading this page to change your thinking about how you interact with others in your free software project. In fact, these ways of thinking about personal interaction would transform business, education and politics if put into wide use.

We know that bullying in schools can be brought to a stop by bystanders who show the courage to immediately speak up on behalf of the victim, and walk away from the confrontation. While I don't want to label those who use abusive language as bullies, we can transform tense situations in similar ways by speaking up in a positive, calm manner, as outlined in the Catalyst page.

Labeling people as trolls doesn't defuse the situation, or create an atmosphere of trust and dialog.

Please folks, if you are in an IRC channel, on a list, or help out on a forum: read the Catalyst page, and remind yourself often to be the change you want to see in the world. You don't need to be an op, a listowner, or a moderator, to be a leader; bloom where you are! Our Codes of Conduct aren't bludgeons to be used against evildoers; rather they are guides to our everyday interaction with one another.

Why we do this crazy thing we do

Looking through a nice blog by Andreas Schilling, I found this classic linked:

It catches very well why we're here, and perhaps why you are reading this blog.

Also, if you are mentoring in GSoC or Season of KDE this year, remind yourself what motivates you and your students, both. We all want to make the world a better place.

The water we swim in

Healthy relationships. I've been thinking about them not in my personal life, but in terms of teams in free software. When I first began contributing, it was within a team creating an application (Amarok), so rather small. Then I became active in Ubuntu-Women, which is larger, but still not huge. Then Kubuntu, then the larger Ubuntu community, and now KDE, which is truly enormous.

In all of these projects, communication and trust are paramount. Dialog which fosters creativity and progress is only possible when people enlarge their trust in one another. Along the way to the highest trust levels, many barriers will come down, as people allow them. Sometimes these barriers are invisible, until someone points them out.

I thought I'd seen a cartoon illustrating this story, but a web search tells me it's a story by David Foster Wallace:

Two young fish meet an older fish, who asks them “How’s the water?” The younger fish look at each other and say, “What the hell is water?”

I was reminded of this story recently while observing the various reactions to the removal of the Community link on Ubuntu.com, the portal to the Ubuntu project. The link is coming back, so I'm not complaining. However, what I've noticed is that most of the people discussing the issue seem to be talking past the folks they are hoping to connect with. The emotions expressed range from puzzlement, to shock and outrage, with little understanding on the other "side" on the perceptions causing these reactions.

So how is the water? To me, the drama played out completely predictably, because any time you have one company selling a product, and volunteers working in that same project, you will have class issues, and class is like the water fish swim in. People are often not aware of it, and thus have difficulty dealing with their emotions around it, because they have been taught to ignore it, or even that it doesn't exist. So when the designers removed the link, it was felt as a slap to the face of community members, while the designers see it as just a step to a clean, functional design. The conversation about this change at the recent vUDS clearly betrays this lack of understanding of the other on all sides. http://summit.ubuntu.com/uds-1305/meeting/21740/community-1305-ubuntu-website-planning/

There is no such thing as a culture without class. There are always power imbalances, and privileges. However, that doesn't mean that class is the death of the Ubuntu project, or that volunteers and companies can't happily co-exist. They can, but the fact of class must be acknowledged, and those with privilege and power must realize what they have, and use them on behalf of the project.

A healthy culture has hierarchy, but not one based on domination. In fact, in FOSS that is part of what we are attempting to dislodge, right? We want our hierarchies to be constructed for function, not to rule over us. For instance, those who demonstrate their skill in packaging or coding are given the right to upload to the repositories. And those who grant them that right are those who already have built their reputations by using their skill and trustworthiness in that domain.

Recently there has been a breakdown -- or an apparent breakdown -- in that hierarchy of function in Ubuntu. And I think that both those inside Canonical and those outside, perceive that the other is the one causing that break. So, some repair is needed.

All of our differences can be overcome as we build (or re-build) trust. However, all sides of the issue will need to think about, process emotion about, and finally discuss openly what has gone on. The replacement of the Community link alone will not mend this breach, nor will brief virtual UDS sessions. In fact, I think the lack of in-person face-to-face interaction is allowing this divide to grow.

Folks, we don't want resentment and suspicion to grow, so we are all going to need to work on this if the Ubuntu project is going to continue to thrive as a free software enterprise. In my opinion, thinking about and discussing class issues are fundamental to that effort.

This blog appears on the Linuxchix, KDE and Ubuntu planets, and these issues of class appear in all teams. Health and progress are the goal, and honest dialog is the means. I propose we look one another in the eye and start a conversation. These are difficult dialogs, but our health is at stake.

Tea and cookies for your new team members

What does every development team want? New contributors!

I'd like to suggest a simple process that can turn visitors to your website, list or IRC channel into a successful part of the development team. When people actually contribute, they quickly feel like a valuable part of the group. New people bring fresh energy, and new ideas.

At your next sprint or meeting, start dreaming. Is your user documentation well-written and up-to-date? Do you need promotion, or video guides? How about art or diagrams for your website? Speaking of your website, when was the last time all the links were tested, and it was checked for spelling and grammar? Create a nice, friendly list of tasks for your newcomers.

Could your codebase use some grooming, for common misspellings, for instance? (EBN is a great source for these). When you run across a bit of code which needs pruning or refactoring, or normalizing signal-slot stuff, the easy thing is to fix it while it's in front of your eyes. Instead, consider which of these small tasks can be filed as a "Junior Job", created for the purpose of getting those knowledgeable people to move from faithful user, to part of the team.

The Bugsquad and Quality Control teams can likely suggest more ideas, too.

KDE Junior Jobs can be easily found: http://kde.org/jj. Teams can create their own shortcut links too, such as Amarok has done, listed in the #amarok IRC channel topic: http://tinyurl.com/amarokjjs. Other tasks can be blogged about, posted on a trello, on the Community wiki; whatever your team likes to use. For more ideas, see http://community.kde.org/Getinvolved.

The Kubuntu team has a list of tasks in Trello, which works well.

So, when you feel like not fixing a little issue, don't feel lazy. Feel responsible! File a bug, make it a JJ, and call attention to those issues when new folks show up and ask, how can I help?


PS: Thanks to the #kde-www team for suggesting this blog. Einar77, neverdingo, mamarok; you are wonderful.

PPS: How LibreOffice does it: https://wiki.documentfoundation.org/Development/Easy_Hacks

New to the commandline? Don't lose heart

Beginners, you are not alone! Many of us have tried to work through problems, only to be stymied when the steps to work through the problem don't work, and efforts to google those error messages yields nothing helpful. In fact, that's why I started this blog; not just to remind myself how to fix various problems, but to point the way to others who are trying to learn the way to CLI-foo.

A word to the wise who are trying to help beginners -- please don't leave out "obvious" steps!

I'll illustrate with a recent experience I had, trying to help a user work through a problem using Krusader.  A bit of googling told me that s/he wasn't alone; there are bugs filed on both launchpad[1] and bugs.kde.org[2]. First, kudos to the unnamed person for asking for help in IRC. That's an excellent place to get step-by-step help.

In the launchpad bug, a helpful person posted a series of step to fix the bug by building an updated version from source:

Made my own deb from 2.4.0.beta3 which solved the `krarc` problem.
How to:
0 Uninstall Krusader
1 download source from http://www.krusader.org/
2 cd krusader-2.4.0-beta3
3 cmake -DCMAKE_INSTALL_PREFIX=/usr/ -DQT_INCLUDES=/usr/share/qt4/include
4 make
5 sudo checkinstall
Don´t forget in step 5 to set version on 3 instead of beta3, only digits are allowed in versions in debs nowadays.

The unfortunate user came back into IRC, and posted this error message:

xy@xy-ubuntu:~/Downloads$ cmake -DCMAKE_INSTALL_PREFIX=/home/user/app/krusader-2.4.0-b3-2 -DQT_INCLUDES=/usr/share/qt4/include
CMake Error: The source directory "/home/jony/Downloads" does not appear to contain CMakeLists.txt.

Having struggled through this process myself, I see what's missing in the instructions. The person posting them didn't realize, I'm sure, that steps were being left out, because they have become automatic. To a beginner, they are bewildering.

Step zero, uninstall, is unambiguous. So far, so good.
Step one, download source, leaves out the best practice, which is to create a directory into which you want your source file! Probably not specified as people have their own schemes of organization, but in general, I advise a ~/kde folder into which I put all source files and builds (thank you for your advice on that, Myriam!)

So step one should be: a) open a konsole, and type or paste: mkdir kde && cd kde && mkdir krusader && cd krusader && wget http://downloads.sourceforge.net/krusader/krusader-2.4.0-beta3.tar.bz2
Then, step b) tar xf krusader-2.4.0-beta3.tar.bz2

Then, do step two, which is correctly stated as cd krusader-2.4.0-beta3

Step three is almost all there, with a missing note: be sure you have cmake installed! My bet is that my troubled user did not.

Cmake ran uneventfully, as did make, so steps three and four are perfect. Step five, however, does not work at all for me, because I don't have checkinstall installed. And I don't think I'll do that for the sake of finishing this blogpost! I don't need a deb file, when Krusader is available from source.

I hope our Kubuntu packagers will get the newest version packaged soon, and make it easy for my troubled user.

1. https://bugs.launchpad.net/ubuntu/+source/krusader/+bug/1065110
2. https://bugs.kde.org/show_bug.cgi?id=294542

Contribute joy

I've just finished a memoir by Roger Ebert, called Life Itself: A Memoir. This passage struck a chord.

"Kindness" covers all of my political beliefs....I believe that if, at the end, according to our abilities, we have done something to make others a little happier, and something to make ourselves a little happier, that is about the best we can do. To make others less happy is a crime. To make ourselves unhappy is where all crime starts. We must try to contribute joy to the world. That is true no matter what our problems, our health, our circumstances. We must try. I didn't always know this and am happy I lived long enough to find out.

We in free and open source software are making the world a better place, and making others happier; often people whom we don't know and will never meet. Roger Ebert shared his love of movies with the world, and I'll miss his voice now that he's gone.

We get to share our love with the world too.

Dropbox in Kubuntu Raring

Upgrades to the release candidate today went swimmingly. I tested on both this laptop, using the 64-bit release, and on my netbook for the 32. Everything is gorgeous. KDE 4.10 is like butter.

However, dropbox stopped working. A quick google later, and by using the code from the GetDropbox site, and instructions on setting up auto-start from Richard's (Nixternal) blog, I once more have a working dropbox, on both test boxes. I use it often to share docs between my computers, and the occasional file with the public.

Quoting from https://www.dropbox.com/install?os=lnx :

The Dropbox daemon works fine on all 32-bit and 64-bit Linux servers. To install, run the following command in your Linux terminal.
32-bit:
cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86" | tar xzf -
64-bit:
cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf - 

Next, run the Dropbox daemon from the newly created .dropbox-dist folder.
cd .dropbox-dist
~/.dropbox-dist/dropboxd

 What you need from Nixternal's blog is the section Configure Dropbox to run at start-up. It would be great to have kfilebox again, but until we do, this is pretty easy.

Promote Lamarckian evolution through GSoC

A short TED talk by neuroscientist Vilayanur Ramachandran inspired me to blog one more time about our upcoming Google Summer of Code project. Whether you are thinking of applying, are preparing to mentor, or are part of a team with some project ideas, give a listen (it's only 7:44 minutes) about how we are literally built to teach and learn from one another. http://www.ted.com/talks/vs_ramachandran_the_neurons_that_shaped_civilization.html?quote=628

What caught my ear was his comparison of Darwinian evolution, which is very slow, with Larmarckian evolution, which can leap ahead, exactly as our culture does. The students who struggle in GSoC, are the ones out of touch with the team, and with their mentors. Sometimes it is the students who withdraw contact when they're in trouble, and sometimes mentors are the ones who are not staying in touch. Either way, the team can notice what is happening, and in a friendly, helpful way, draw the two back into contact.

Success happens when we communicate, because that's how learning happens. Students, when you encounter difficulty, please remember to get into the IRC channel, and if no one answers, write an email. Don't wait a day; don't wait an hour. The summer rushes by and you need all the time so that you can relax and do good work.

Mentors, please experiment with your student at the beginning of your bonding time, what forms of communication work the best for the two of you, or three of you if you have a mentor team. Google hangouts or other voice chats work, as long as someone writes an email summing up the understanding of the road ahead. IRC is important for the team, and students can get a bouncer account by asking the KDE sysadmins once their developer accounts are in place.

Stay in touch! As Vilayanur Ramachandran says,

There is no real independent self, aloof from other human beings, inspecting the world, inspecting other people. You are, in fact, connected not just via Facebook and Internet, you’re actually quite literally connected by your neurons.

So work with your brain, and stay connected.

Progress? It depends on your perspective

I had a disturbing discussion with a family member recently. There were no arguments over facts; we agree on the facts underlaying our discussion. Yet I was shocked at how discouraged he was by the state of the world, and the prospects for progress. No matter what examples I raised, he had more examples which convince him that we're moving backwards. Neither of us managed to convince the other to change their mind. That part wasn't unusual! But I'm unused to encountering this negative view of the universe. I live in the US, and I know that our politics is full of fail!

In the FOSS community, I rarely come across this depressed perspective. In fact, quite the opposite. So I've been thinking about why this is. Perhaps it is because we are involved in changing the world! After all, we aren't just building and distributing free software; we're showing the world that freedom and friendship work. We constantly demonstrate that we can cooperate; with team members, with up and downstreams, with for-profit companies and with non-profit groups, with government and educational groups, and on and on.

We promote freedom, we promote equality, we promote quality. We constantly develop new friendships, we pay attention to our users, and those users help us help them by filing bug reports, cooperating with quality initiatives, by testing, by donating money. We learn to promote our projects, learn to give talks, speeches and reports, learn to build websites, write documentation, learn to communicate in multiple venues, and even learn to recognize bad behavior by friends and team members, or maybe even burnout in our own lives. And of course, we learn what to do in those tough situations, along with dealing with bugs in our software, crochety hardware and processes, or outdated techniques.

I've been reading a book about increasing brain fitness, (bad title warning): Make Your Brain Smarter, by Sandra Bond Chapman which might shed some light. In the section about innovation and creativity, she says you:

incite innovation ... when you: ... broaden and revamp your perspectives... by reading different types of books, exposing yourself to different types of people.... Dismantle old linkages of information to allow new thoughts to brew, ponder free-flowing ideas, consciously ... convert ideas into deliberate change [and] reflect and learn from mistakes -- quickly. [p. 115]

This is what I see in Linuxchix, in the KDE and Kubuntu teams I work in, and on the lists, forums, planets, and in IRC. I hear new perspectives, hear about books, hear from new people, and different people, see new ideas, and old ideas blown up, and see how immediate feedback improves quality fast. Every day!

I think these experiences explain the difference between hope and despair between my family member and me. Not only do I see many groups in my country and around the world who are making a difference, I'm part of a great movement which is improving the world. Whether or not this is the "year of the linux desktop," we are making great software, software which we use, software we are proud to share with the world. We're not only having fun doing it; we're part of how you make the world a better place.

PS: We're getting smarter and healthier as we do so, I hope. By the way, I'm encouraging my family member to get involved in our projects. Here's hoping.

Intentional community

This blog is generally seen in the planets for Ubuntu, KDE, and Linuxchix. These are all FOSS intentional communities, by which I mean that the founders and members form a community to in which they can create. I found Linuxchix first (thanks, Megan!), and I loved how welcomed I was, although I was still at the time using Windows. How many linux channels welcome an mIRC user? The longer I hung out there, the more I learned, and the more I was impressed by all the different work the community members were doing out in the greater FOSS world. I also loved that it was women and men working together to make FOSS a better place for women.

When I ended up using Kubuntu (after trying Mandrake and then Gentoo, and GNOME/Ubuntu), some of the Ubuntu Women members welcomed me onto Freenode. When I found that that freenode was where the Amarok team hung out as well, I added the server to my Konversation server list. Members of both of those teams made me welcome, taught me some of the Freenode quirks, and I learned a bit more about how Linux is made. Lots of teams, loads of projects, each with their own culture and ways of working. Because Ubuntu and KDE both have a Code of Conduct, I felt somewhat safe, although I had heard lots of horror stories about linux channels on freenode and elsewhere. After experiencing some quite frightening attacks in the Linuxchix channels, I learned how resilient a community can be, and how creative security can be -- even fun.

So, codes of conduct. In the wake of the recent controversy following PyCon, one of my friends said that they imply that all men are assholes. This surprised me. Linuxchix has two rules: Be polite. Be helpful. All people are expected to follow them; I see the rules as intentional community. We want polite and helpful resources, so those are the rules for everyone. The Ubuntu CoC has grown a bit through the years, but is still phrased positively: http://www.ubuntu.com/project/about-ubuntu/conduct. I prefer the old shorter one, but both are focused on creating a helpful, respectful community.

I like the KDE CoC a lot. Once I found it, I felt much better about becoming involved. It reminded me very much of the simple Linuxchix rules.

This Code of Conduct presents a summary of the shared values and “common sense” thinking in our community. The basic social ingredients that hold our project together include:

• Be considerate 

• Be respectful 

• Be collaborative 

• Be pragmatic 

• Support others in the community 

• Get support from others in the community -- quoted from http://www.kde.org/code-of-conduct/ 

In my opinion, there is nothing in any of these codes or rules that blames men, or is negative. They paint a picture of a place where we want to work, and hang out with friends afterwards. I'm an older woman as the name of this blog implies, and I don't want to pretend to be a guy to collaborate without hassle. I want to be myself, and be welcomed for the skills and passion I bring. I also want more women and other minorities to feel welcome. A boy's club is not welcoming, and linux has that reputation. Too often well deserved.

So I ask each of my readers, what do you want? Is your behavior creating what you want? This is not aimed at men, by the way. All of us create our culture together, intentionally or not. I hope we will more consciously make our community the most pleasant, welcoming and creative in all of FOSS.

[Note on PyCon: The entire controversy has left me feeling sick. Congratulations are in order to the conference staff and leadership, who conducted themselves well. Yet they now have this mess connected to their fine conference, rather than good memories. There are no winners here, from what I can see. Since I didn't attend, and am not part of that community, no comments on PyCon itself or the controversy will be published here.]

Testing, another way to help your favorite FOSS project

I've done some testing before, but this time I want to document it here, so I can come back later and remind myself of some of the critical steps, and so others new to testing can get the confidence to start contributing in this way as well. I'm mainly using Kubuntu as an example here, but applications and desktops need testing as well. If you are using a non-Debian distribution, the commands I use will not work. Consult your documentation for equivalents.

I'm lucky in that I have some extra computers I can use as testing machines. But when I didn't, I used virtual machines, and those aren't too difficult to set up. However, I'll discuss that another time.

In general, please read the /topic in your development IRC channel, then ask about testing, or join the testing channel if there is one. Often you'll be given bug numbers to test for a specific package -- please be sure to comment completely in the actual bug report, not just give feedback in the channel. Be sure to ask what information is necessary. ISO testing is another place where folks are needed; again, your devel channel /topic should give you some good information. And don't forget to join and read the relevant lists as well; no one can be in IRC all the time.

Right now, some packages need testing in the next Kubuntu distribution release. I prefer using the command line for things like this, because 1. in the console, upgrades happen "under" the desktop, so config files are updated cleanly, and 2. it is much faster. So first, the upgrade. Instructions to do this in the GUI: https://help.ubuntu.com/community/RaringUpgrades/Kubuntu

If your computer is already on, log out of your session. At the login screen, rather than typing in your password, hit Control + Alt + F2. Then log into first your computer with your username and password, then

sudo update-manager -d

This updates all your repositories to the development release. Next, the start the actual upgrade:

sudo do-release-upgrade -d

You'll have to OK a few things, so it's not entirely unattended. After the packages are all downloaded, the upgrade still takes quite awhile. Sometimes I start this at night, and just check on things in the morning.

Next, you'll need to install the package, or build the application from a tarball, or source. Depending on your distro tools, this might vary a bit.

Building from source

For Amarok, Myriam has a great blog post about how to build from git: http://blogs.fsfe.org/myriam/2009/09/26/compiling-amarok-from-git-locally-full-summary/, so I won't cover that. If you doing a local build of a different package, the steps will be similar. Consult the documentation for details. This blog post is kept updated, and deals with lots of different distributions.

Install from a PPA

To install a package from a PPA, in Debian-based distros, there is an easy way to add it (addrepo in Debian):

sudo add-apt-repository ppa:

This will download and register the public key, as well as adding the repository. Then you can simply install the package via the command line or using the GUI tools you prefer.

Build from a tarball

To get the tarball, cd to the directory where you want to unpack it, then wget the file. As as example, here's how I built phonon 4.4.4 from the tarball:

cd ~/kde/src/
wget http://download.kde.org/download.php?url=stable/phonon/4.4.4/src/phonon-4.4.4.tar.bz2
tar xf phonon-4.4.4.tar.bz2
cd phonon-4.4.4 && mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon-4.4.4
sudo make install

I'm not sure that building phonon in my home folder was a good idea, but since I build Amarok locally, I've gotten into the habit of doing that.

So now you have your package or packages, and can do the tests, and report your results. Have fun!

The Disgrace of the United States

Ten years ago tonight, my country, my beloved USA, became the Bad Guys. We became the attackers. Sad to say, this is not commonly admitted, any more than we admit that we admit that we invaded Canada in 1812, and were thrown out, or that we stole what is now the US Southwest from Mexico, and then called the treaty the Gadsden Purchase, or that we created, in part, the situations in Afghanistan, Iran and Iraq that are now still burdening us and the world. We like to think well of ourselves, as do all people. There is no excuse for teaching lies to kids in history books, though.

There were heroes then; many people opposed the war, voted against the war, marched against the war, and many then paid for their patriotism. The lucky ones were just booed, the more unfortunate lost their jobs. There are many now who still are out telling the truth, and bringing more facts out into the light. Along with the Bush administration, the American press let us down ten years ago with their unquestioning acceptance of the administration lies. And now that same press continues to call upon those guilty of this horrible war, the architects and shills, to give their assessment of the situation now! Unbelievable. And it isn't just Fox "News" either. These "neo-cons" should pay a price for lying to the country, leading to untold thousands upon thousands of deaths and injuries, and beggaring both the US economy and the entire nation of Iraq.

History is based upon the facts, not the white-washing that is currently being attempted. We invaded Iraq for no good reasons, our occupation wrecked the country, and we left in disgrace. Lying about the past will never change the truth. The US lost the War of 1812, and we were the aggressors in the Spanish-American War, the Mexican-American War, the Second Iraq War, and many others. I love my country, and I have to tell the truth.

And now back to free software.

Adventures in git

It has been a bit painful to learn to build from source, but I can do it both from git and from tarballs now. (Painful for me, and I'm sure even more painful for the patient devels who have helped me through my beginner mistakes. Thank you Amarok and KDE Multimedia devs, especially Harald and Myriam.)

Tonight, I was working with the developer of the wonderful little CLI application Rippit trying to get it to work on my system again. He gave me a patch to the tarball which cleared up one error, but then there was another, and GAH. Then I noticed that he used git, DUH, which I know how to clone from and then build. For instance, in this case, it was

mkdir rippit && cd rippit
git clone git://git.fedorahosted.org/rippit.git
cd rippit && mkdir build && cd build && cmake cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/rippit/rippit

sudo make install

From the error message, Trever could tell that I wasn't using the proper branch. So:

cd src

then, rather than ls to list all the branches, 

git branch -a 

git checkout remotes/origin/0.1 (I found this method on Stackoverflow. Thanks superlogical for your answer.)

From there, delete the build folder, and do the rest of the process as before. I love stringing together the commands with && which make it so much easier for me to copy/paste or use the up-arrow in Yakuake. I want to make it easy to rebuild so that testing can be quick.

Finally, a working Rippit again! Thanks again, Trever. You rock! KDE devels are the best.

Thoughts and worries about the proposed new Ubuntu processes

Today began in a virtual UDS session (Google Hangout) with the Xubuntu team. The video can be seen here: http://summit.ubuntu.com/uds-1303/meeting/21666/community-xubuntu-contingencies/ . Xubuntu devels stopped by #kubuntu-devel and asked us to bring our list of concerns to share. The list we developed:

• The new system will do away with releases for each upstream KDE release, which is a prominent feature of Kubuntu. One idea is to do releases of LTS+PPA with latest KDE but that's against policy and needs technical changes to make happen. Or will there be a way to create ISOs from PPAs?

• Mir is a worry since KWin will clash with it (a compositing manager inside a compositing manager). How good will continued Wayland and X support be?

• Where to put Beta releases of software? Testing is a huge part of quality. So while a PPA seems the obvious suggestion, but they'll get less testing there. Now we use a beta ppa only for backports. Consistent quality would require staging major changes somewhere else.

• How will library transitions be handled outside of cadence?

• Launchpad breakdowns. We are trying to automate more of our building tasks, but often the scripts must be run repeatedly because of Launchpad timeouts.

• Weakness of unit & hardware testing. This is crucial for a successful rolling release.   

• Security updates - who gets them? When, and how often? (LTS will get them as usual, but for rolling it seems the monthly snapshots don’t get any? you need to use rolling)

• We will be more dependent than ever on syncing with Debian for rolling. We already import, and release, Debian packages with RC bugs. Colin Watson suggested checking Ubuntu-Critical bugs anyway. Scott Kitterman replied that this would recreate painful Debian transition. Beta/buggy software is often uploaded into Debian Unstable, and proposed changes mean even less prevents bad software  from getting into Ubuntu -release.

• We need a policy for when to move packages from PPA to rolling.

• PPAs for non-Canonical contributors have low armhf/powerpc ability.           

          * KDE doesn't compile in qemu (bug 1077116) [Philip Muskovac]
          * Fixing these might be an acceptable cost of rolling release according to Steve Langasek.

I wish I could say we got answers to all of our questions. On the other hand, it was good to have those advocating for a rolling release listen to our concerns. The discussion continues on the Ubuntu-devel list and in the IRC channels. Of course the Kubuntu developers will continue to voice our concerns, and listen as the proposals change over time. As Rick Spencer said, he made a proposal to Ubuntu developers, not a announcement from Canonical. As we heard in the session today, no proposal has been formally submitted to the Technical Board. It seems possible that 13.04 will be released as planned, with the beginning of new processes put off until more of the necessary supports are put in place.

I want to thank everyone involved who continue to work so hard to provide an excellent user experience, even when we disagree about how best to do that. And especially the Kubuntu and KDE communities. You rock!

PS: This mini-UDS was a good place to share our concerns, and perhaps do some planning. But it in no way compares to a real UDS, with actual face-time, and the essential "hallway track."

Adventures in the CLI: fixing sound using apt logs

Plunging back into community involvement this week meant installing mumble, a free messaging system. The virtual UDS (Ubuntu Developer Summit) Canonical is hosting at short notice this week (today and tomorrow, actually) is being conducted on Google Hangouts. While these can be cool, they limit participation to ten, and to those who have GooglePlus logins. So the Kubuntu devels wanted to try mumble instead for our meeting(s).

I usually use apt-get to upgrade and install packages, just because it is faster and easier. Alt-F12 to get nifty drop-down bash session, up-arrow to get to commonly used commands, and viola, done! However, this time apt-get installed most of GNOME along with mumble, such as evolution, plus gnucash and other stuff! Once all this was installed, I had no sound of any sort; from speakers, in flash, through earphones. Sadness.

I began working through the sound troubleshooting guide, but none of it worked, and didn't seem to apply anyway. When I asked in #kubuntu-devel about the mumble install, Scott Kitterman asked the right questions, and told me that his list of dependencies was small, as was the list of recommended packages, and how to find the complete list:

$ cd /var/log/apt/
$ ls 
$ cat history.log

This gets you a wonderfully detailed list of all packages dealt with by apt. I started by removing the obviously un-needed packages, including mumble itself. The list was so huge that I didn't get far, however, ScottK had suggested removing slpd and roaraudio. After reading the man page for apt, I got a bit more clever about getting more stuff in one fell swoop:

sudo apt-get purge gnome-mahjong*

for instance, gets the libs and -dbg packages too. Once I went back and purged roar* -- I got the offending libs, and had sound again!

By coincidence (I think) I had a problem in flash in Firefox at the same time. So Youtube videos were silent and about 100 times too fast. Once sound came back, I noticed that I had sound in Youtube in Chromium, and everything was the correct speed as well. Flash still seems broken in FF, but that now seems unrelated.

By the way, when I re-installed mumble using Muon, everything worked well. Although I haven't tested it yet, I expect it to work as advertised. 

Planning for Google Summer of Code

Now that Google has announced GSoC 2013, we will soon hear the rules and schedule. It's never too early to plan for your participation, whether as a student, a mentor, or KDE administration team member.

I recently read an interesting book about time and how we perceive it, based on recent neuroscience: Time Warped: Unlocking the Mysteries of Time Perception, by Claudia Hammond. The section on planning projects seemed applicable for both mentors and students. Of course, for students, this is the time to get involved with the KDE community, figure out what projects look interesting, and start the learning the development process.

The crucial resource is the Handbook, written by participants. There is a Mentor's Guide and Student's Guide, also available in ebook format.

In addition to the Handbook, Time Warped offers some valuable insight into the Planning Fallacy which is the tendency to believe that the job will take less time than eventually does. The admins and mentors work with students to create a realistic and detailed timeline, which is one of the important ways to outwit this human tendency. Hammond suggests that you consider your plan and then compare the parts to projects you have done in the past, to fine-tune your time frame to completion. Hammond warns against the common belief that we will have more time in the future than we have now. This caution is very important for mentors too. And it is one reason KDE always tries to have at least one back-up mentor for each accepted project, as well as the teams for general help.

Finally, Hammond suggests that since other people make more accurate judgements about our time, describe the task to a friend and ask them to guess how long it will take you. Those who have mentored before can help new mentors with this, and students can ask those who have seen their previous programming work to help judge the prospective plan.

I look forward to seeing KDE folks, experienced and brand-new, getting to know one another, and digging into the code.