॥ स्वक्ष ॥

To content | To menu | To search



Entries feed

2012 August 29 [Wednesday]

Contributing to Libre software

"How do I start contributing to Libre Software?" is a very common question (I asked that too) one comes across on most FOSS lists. Today, I posted the following on a private list and was asked for a public link, so here goes:


There are many Libre software projects to choose from, so choosing one project can be quite confusing when you are starting out. Do yourself a favor and take a few moments to do a SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis before you decide to jump onto the Libre software bandwagon.

Its better to give yourself time to think (or write down) which technical area or field interests you
  • Which language do you want to program in?
  • Is it front-end software or backend stuff?
  • Web programming or something else?
  • Do you like writing system software or application level software?
  • Or, do you like libraries, prefer working with algorithms/statistical applications, etc..

Once you have figured out your field of interest, its easier to shortlist something and get started on finding a project to work on.

From Failure to Success

If you are still having a hard time figuring out your interests, fret not ! Its OK to NOT know what you want when you are starting out - make sure you keep an open mind and be willing to try out new things that are unfamiliar (and sometimes hard and confusing) and/or fail at them. Failure is a good teacher!

Its what you do when you fail that distinguishes you from a successful person. If you give up your failure remains a failure BUT if you decide to practice and try again (and Again and AGAIN), you can convert your failure into success. Remember, the bridge between failure and success is Practice!


As I mentioned above, there are so many Libre software projects that its overwhelming at the outset. Having figured out your field, dont randomly visiting a bug-tracker and try to solve bugs, which is not a bad idea if you have only a few hours per week. However, if you want to wade a little deeper, try using Google to your advantage - scan the orgs at the Google Summer of Code.

This recently concluded program, has a ready list of organisations to choose from and the 2012 list is available at: http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2012. Besides these few hundred GSoC Orgs,
However, if you are interested in working outside of the SoC span, projects are always interested in contributors and would welcome your efforts 24x7x365. That said, these SoC tasks require a longer commitment of 40 hours per week in terms of time, so you need to decide what you want to do. Its not part-time work, so commitment and rigor is a prerequisite.


After you have searched Melange (or ESA) for keywords of your choice, visit the Ideas page for each organisation. Here, you will find a list of tasks ranked as per preference or difficulty level (NB: This entirely depends on the Org). Remember to cross-check with the Melange page if the task has already been completed via GSoC, or not.

If a task is still available, find out what is required to get started on it and prepare a short abstract. This will help you to,
  • figure out the development stack vis-a-vis your skillset,
  • realise how much time and effort is required to bridge the gap, if any ;
  • prepare a timeline estimate. (Dont obsess over the timeline as it is just an estimate and it will vary if the Org changes any requirements.)

These done, talk to the Org - always, Always, ALWAYS talk to the Org _before_ you start work on anything.
Just because a task is listed on the Ideas page does not mean its a part of their workflow (which can always change), nor is the opposite true. The best way to find out is to talk to them, first. Again, remember that these SoC tasks require a longer commitment in terms of time.


Most Libre projects have their own communication channels. This could be via Mailing lists or Forums, including IRC channels on dedicated servers or on freenode. Its important to work with them via these public channels and that means learning to communicate and not worry about asking silly (psst..there are none!) questions.
Communicating with the core developer and/or mentors and community of users is crucial - they can be an invaluable source for ideas and helpful hints. Many projects have separate lists (and IRC channels) for users and developers. Join them and introduce yourself (or lurk around to get a hang of how things work) and when you are ready, do talk about the task you want to work on.

A development mailing list, where the core developers would be available, is distinguishable via the "*-devel" mailing address. Same is true for IRC channels - If you like CLI tools, try Irssi or Quassel if you want a GUI client. Pick your poison from this list of IRC clients.


Finally, and most importantly, you must be comfortable working with the software the project uses - that means, you should be able to clone and get the software to install and work on your local machine. Here, communicating with your Org helps - You can ask for help if you have hardware or software issues, clarify installation and dependency issues, etc... No software works flawlessly (else, people would be out of jobs :)) and Libre software is no exception - the only difference being "software development on a libre / public scale".

Another aspect of getting familiar with the development stack is familiarizing yourself with the projects internal system - Since, each project uses its own bug tracker and DCVS, Wiki (for documentation), Email/Forum and IRC communication system, take some time to get familiar with each of these. If you plan to stick around for any length of time, you would be using some, or, all the software stacks they use on a regular basis.

Your transition from newbie to active contributor is a lot faster when you are comfortable with the development stack. Doing your homework before the SoC program starts will give you the confidence required to grok it enough to start working on the code-base, suggest changes or solve bugs, etc..

I hope these suggestions help you find your niche learning shell to contribute to, and of course, welcome to the Libre software. Have fun!

2011 May 3 [Tuesday]

Building packages from source tutorial by DebianWomen

DW is conducting a packaging tutorial. Do note, this is not a tutorial for upstream package building from source, but still, its worth listening to. Here is Marga's announcement::

Are you enthusiastic about Debian and thinking about contributing? We want to guide you with the basics.

We are convinced that there are a lot of people out there that want to get involved with Free Software but don't know where to start.  For Debian, the most common task you'll do as a contributor is rebuilding a package.

The Debian Women project, in collaboration with the OpenHatch project, will be holding an IRC event to help people that want to compile their first Debian package from source, and apply their first patch.

The event

On Saturday May 7th, two tutorial sessions will be held on #debian-women on irc.debian.org to help people rebuild a package for the first time.
The earlier session, suggested for those that live in Oceania, Asia, Africa and Europe, will be held at 11:00 UTC. 

The later session, suggested for those that live in the Americas, will be held at 22:00 UTC. You can find out the exact time in your timezone by using the timezone converter: http://www.timezoneconverter.com/cgi-bin/tzc.tzc

There will be people available to answer questions and generally help out with any difficulties that might arise all along the day.

More info at http://wiki.debian.org/DebianWomen/BuildItEvent

Intended audience

This event is aimed to anyone who wants to rebuild a Debian package for the first time, it's a simple task that doesn't require any previous knowledge, only a working installation of Debian (or Ubuntu, or other Debian-derived system).  We want to particularly encourage women who want to get involved, to take their first steps in
contributing to Free Software, but everybody is welcome.

More about IRC

IRC is a real-time chat system you can use to get in touch with members of the Debian community. You can connect to IRC through lots of different clients, including xchat, pidgin and konversation.

About Debian Women

The Debian Women project seeks to balance and diversify the Debian Project by actively engaging with interested women and encouraging them to become more involved with Debian. http://women.debian.org

About OpenHatch

OpenHatch is an open source community aiming to help newcomers find their way into free software projects. It works towards this goal through on-line and outreach events. This event is a reappropriation of the OpenHatch "Build it" events.


2010 September 18 [Saturday]

Gnome outreach program for women - 2010 internships

The application process for the first round of internships sponsored by the GNOME Foundation are now officially open. The dates for these internships are 2010Dec15 to 2011Mar15.

Any woman who has relevant experience and is available for a full-time internship is welcome to apply. The application deadline is 2010Oct25. As part of the application process, they are asking women to take the time to learn about the participating projects and make a contribution to the one they are interested in. These projects include ones in programming, graphic design, documentation, and marketing. For more program details, visit: http://live.gnome.org/GnomeWomen/OutreachProgram2010

Do consider applying for the internship, signing up as a mentor, or helping spread the word by encouraging woman to apply - Blog, email, dent/tweet or download this flyer (designed by Máirín Duffy) to send the information about this internship program to your local school/college/university or hand it out at conferences. All the materials for spreading the word are here: http://live.gnome.org/GnomeWomen/OutreachProgram2010/SpreadTheWord

2010 September 7 [Tuesday]

KDE-Koffice seeks code contributors

This post makes it after a long latency period that I'm not proud of. Apologies Boudewijn!

Boudewijn Rempt, CTO of KO GmbH, a company that works on open source projects around KOffice, OpenDocument and Qt is looking for Indian university contacts for establishing project channels to increase volunteer contribution to Free/Libre software.

In Europe, he has been a mentor of a student who did his MA Thesis on writing brush engines and algorithms for Krita and had visited India in May to give a training to some university students who were going to do an internship with Nokia, working on KOffice. A large part of that training was about getting involved with a free software project and he would like the opportunity to do the same for other groups of students and would love to work together with people to set up similar projects at Indian colleges, universities and with companies because when students do their internship or thesis in cooperation with a free software project, they will learn a lot that is really valuable: working together with teams, producing software that has end users, working with large, real-life code bases and the projects might gain long term contributors.

According to Boudewijn, KOffice is C++ based, very few applications can be scripted in Python and they use some Python scripts for things like quality control, but the core apps and libraries are C++. You can read the detailed build instructions and if it interests you then directly contact Boudewijn Rempt at boud@valdyas.org (private) OR boud@kogmbh.com (company address).

PS: Feel free to circulate this widely to all Indian universities and colleges as Libre Software is meant for everyone/anyone interested in learning something new.

2010 January 6 [Wednesday]

The Neuroscience of screwing up

I usually avoid reproducing articles from publications but this was a well-written piece that I wanted to etch it in my memory.

From, http://www.wired.com/magazine/2009/12/fail_accept_defeat/all/1

Accept Defeat: The Neuroscience of Screwing Up
By Jonah Lehrer | December 21, 2009  | 10:00 am  | Wired Jan 2010

It all started with the sound of static. In May 1964, two astronomers at Bell Labs, Arno Penzias and Robert Wilson, were using a radio telescope in suburban New Jersey to search the far reaches of space. Their aim was to make a detailed survey of radiation in the Milky Way, which would allow them to map those vast tracts of the universe devoid of bright stars. This meant that Penzias and Wilson needed a receiver that was exquisitely sensitive, able to eavesdrop on all the emptiness. And so they had retrofitted an old radio telescope, installing amplifiers and a calibration system to make the signals coming from space just a little bit louder.

But they made the scope too sensitive. Whenever Penzias and Wilson aimed their dish at the sky, they picked up a persistent background noise, a static that interfered with all of their observations. It was an incredibly annoying technical problem, like listening to a radio station that keeps cutting out.

At first, they assumed the noise was man-made, an emanation from nearby New York City. But when they pointed their telescope straight at Manhattan, the static didn’t increase. Another possibility was that the sound was due to fallout from recent nuclear bomb tests in the upper atmosphere. But that didn’t make sense either, since the level of interference remained constant, even as the fallout dissipated. And then there were the pigeons: A pair of birds were roosting in the narrow part of the receiver, leaving a trail of what they later  described as “white dielectric material.” The scientists evicted the pigeons and scrubbed away their mess, but the static remained, as loud as ever.

For the next year, Penzias and Wilson tried to ignore the noise, concentrating on observations that didn’t require cosmic silence or perfect precision. They put aluminum tape over the metal joints, kept the receiver as clean as possible, and hoped that a shift in the weather might clear up the interference. They waited for the seasons to change, and then change again, but the noise always remained, making it impossible to find the faint radio echoes they were looking for. Their telescope was a failure.

Kevin Dunbar is a researcher who studies how scientists study things — how they fail and succeed. In the early 1990s, he began an unprecedented research project: observing four biochemistry labs at Stanford University. Philosophers have long theorized about how science happens, but Dunbar wanted to get beyond theory. He wasn’t satisfied with abstract models of the scientific method — that seven-step process we teach schoolkids before the science fair — or the dogmatic faith scientists place in logic and objectivity. Dunbar knew that scientists often don’t think the way the textbooks say they are supposed to. He suspected that all those philosophers of science  — from Aristotle to Karl Popper — had missed something important about what goes on in the lab. (As Richard Feynman famously  quipped, “Philosophy of science is about as useful to scientists as ornithology is to birds.”) So Dunbar decided to launch an “in vivo”  investigation, attempting to learn from the messiness of real experiments.

He ended up spending the next year staring at postdocs and test tubes: The researchers were his flock, and he was the ornithologist. Dunbar brought tape recorders into meeting rooms and loitered in the hallway; he read grant proposals and the rough drafts of papers; he peeked at notebooks, attended lab meetings, and videotaped interview after interview. He spent four years analyzing the data. “I’m not sure I appreciated what I was getting myself into,” Dunbar says. “I asked for complete access, and I got it. But there was just so much to keep track of.”

Dunbar came away from his in vivo studies with an unsettling insight: Science is a deeply frustrating pursuit. Although the researchers were mostly using established techniques, more than 50 percent of their data was unexpected. (In some labs, the figure exceeded 75 percent.) “The scientists had these elaborate theories about what was supposed to happen,” Dunbar says. “But the results kept contradicting their theories. It wasn’t uncommon for someone to spend a month on a project and then just discard all their data because the data didn’t make sense.” Perhaps they hoped to see a specific protein but it wasn’t there. Or maybe their DNA sample showed the presence of an aberrant gene. The details always changed, but the story remained the same: The scientists were looking for X, but they found Y.

Dunbar was fascinated by these statistics. The scientific process, after all, is supposed to be an orderly pursuit of the truth, full of elegant hypotheses and control variables. (Twentieth-century science philosopher Thomas Kuhn, for instance, defined normal science as the kind of research in which “everything but the most esoteric detail of the result is known in advance.”) However, when experiments were observed up close — and Dunbar interviewed the scientists about even the most trifling details — this idealized version of the lab fell apart, replaced by an endless supply of disappointing surprises. There were models that didn’t work and data that couldn’t be replicated and simple studies riddled with anomalies. “These weren’t sloppy people,” Dunbar says. “They were working in some of the finest labs in the world. But experiments rarely tell us what we think they’re going to tell us. That’s the dirty secret of science.”

How did the researchers cope with all this unexpected data? How did they deal with so much failure? Dunbar realized that the vast majority of people in the lab followed the same basic strategy. First, they would blame the method. The surprising finding was classified as a mere mistake; perhaps a machine malfunctioned or an enzyme had gone stale. “The scientists were trying to explain away what they didn’t understand,” Dunbar says. “It’s as if they didn’t want to believe it.”

The experiment would then be carefully repeated. Sometimes, the weird blip would disappear, in which case the problem was solved. But the weirdness usually remained, an anomaly that wouldn’t go away. This is when things get interesting. According to Dunbar, even after scientists had generated their “error” multiple times — it was a consistent inconsistency — they might fail to follow it up. “Given the amount of unexpected data in science, it’s just not feasible to pursue everything,” Dunbar says. “People have to pick and choose what’s interesting and what’s not, but they often choose badly.” And so the result was tossed aside, filed in a quickly forgotten notebook. The scientists had discovered a new fact, but they called it a failure.

The reason we’re so resistant to anomalous information — the real reason researchers automatically assume that every unexpected result is a stupid mistake — is rooted in the way the human brain works. Over the past few decades, psychologists have dismantled the myth of objectivity. The fact is, we carefully edit our reality, searching for evidence that confirms what we already believe. Although we pretend we’re empiricists — our views dictated by nothing but the facts — we’re actually blinkered, especially when it comes to information that contradicts our theories. The problem with science, then, isn’t that most experiments fail — it’s that most failures are ignored. As he tried to further understand how people deal with dissonant data, Dunbar conducted some experiments of his own. In one 2003 study, he had undergraduates at Dartmouth College watch a couple of short videos of two different-size balls falling. The first clip showed the two balls falling at the same rate. The second clip showed the larger ball falling at a faster rate. The footage was a reconstruction of the famous (and probably apocryphal) experiment performed by Galileo, in which he dropped cannonballs of different sizes from the Tower of Pisa. Galileo’s metal balls all landed at the exact same time — a refutation of Aristotle, who claimed that heavier objects fell faster.

While the students were watching the footage, Dunbar asked them to select the more accurate representation of gravity. Not surprisingly, undergraduates without a physics background disagreed with Galileo. (Intuitively, we’re all Aristotelians.) They found the two balls falling at the same rate to be deeply unrealistic, despite the fact that it’s how objects actually behave. Furthermore, when Dunbar monitored the subjects in an fMRI machine, he found that showing non-physics majors the correct video triggered a particular pattern of brain activation: There was a squirt of blood to the anterior cingulate cortex, a collar of tissue located in the center of the brain. The ACC is typically associated with the perception of errors and contradictions — neuroscientists often refer to it as part of the “Oh shit!” circuit — so it makes sense that it would be turned on when we watch a video of something that seems wrong.

So far, so obvious: Most undergrads are scientifically illiterate. But Dunbar also conducted the experiment with physics majors. As expected, their education enabled them to see the error, and for them it was the inaccurate video that triggered the ACC. But there’s another region of the brain that can be activated as we go about editing reality. It’s called the dorsolateral prefrontal cortex, or DLPFC. It’s located just behind the forehead and is one of the last brain areas to develop in young adults. It plays a crucial role in suppressing so-called unwanted representations, getting rid of those thoughts that don’t square with our preconceptions. For scientists, it’s a problem.

When physics students saw the Aristotelian video with the aberrant balls, their DLPFCs kicked into gear and they quickly deleted the image from their consciousness. In most contexts, this act of editing is an essential cognitive skill. (When the DLPFC is damaged, people often struggle to pay attention, since they can’t filter out irrelevant stimuli.) However, when it comes to noticing anomalies, an efficient prefrontal cortex can actually be a serious liability. The DLPFC is constantly censoring the world, erasing facts from our experience. If the ACC is the “Oh shit!” circuit, the DLPFC is the Delete key. When the ACC and DLPFC “turn on together, people aren’t just noticing that something doesn’t look right,” Dunbar says. “They’re also inhibiting that information.”

The lesson is that not all data is created equal in our mind’s eye: When it comes to interpreting our experiments, we see what we want to
see and disregard the rest. The physics students, for instance, didn’t watch the video and wonder whether Galileo might be wrong. Instead, they put their trust in theory, tuning out whatever it couldn’t explain. Belief, in other words, is a kind of blindness.

How to Learn From Failure

Too often, we assume that a failed experiment is a wasted effort. But not all anomalies are useless. Here’s how to make the most of them.—J.L.

1. Check Your Assumptions : Ask yourself why this result feels like a failure. What theory does it contradict? Maybe the hypothesis failed, not the experiment.

2. Seek Out the Ignorant: Talk to people who are unfamiliar with your experiment. Explaining your work in simple terms may help you see it in a new light.

3. Encourage Diversity: If everyone working on a problem speaks the same language, then everyone has the same set of assumptions.

4. Beware of Failure-Blindness: It’s normal to filter out information that contradicts our preconceptions. The only way to avoid that bias is to be aware of it.

But this research raises an obvious question: If humans — scientists included — are apt to cling to their beliefs, why is science so successful? How do our theories ever change? How do we learn to reinterpret a failure so we can see the answer?

This was the challenge facing Penzias and Wilson as they tinkered with their radio telescope. Their background noise was still inexplicable, but it was getting harder to ignore, if only because it was always there. After a year of trying to erase the static, after assuming it was just a mechanical malfunction, an irrelevant artifact, or pigeon guano, Penzias and Wilson began exploring the possibility that it was real. Perhaps it was everywhere for a reason.

In 1918, sociologist Thorstein Veblen was commissioned by a popular magazine devoted to American Jewry to write an essay on how Jewish “intellectual productivity” would be changed if Jews were given a homeland. At the time, Zionism was becoming a potent political movement, and the magazine editor assumed that Veblen would make the obvious argument: A Jewish state would lead to an intellectual boom, as Jews would no longer be held back by institutional anti-Semitism. But Veblen, always the provocateur, turned the premise on its head. He argued instead that the scientific achievements of Jews — at the time, Albert Einstein was about to win the Nobel Prize and Sigmund Freud was a best-selling author — were due largely to their marginal status. In other words, persecution wasn’t holding the Jewish community back — it was pushing it forward.

The reason, according to Veblen, was that Jews were perpetual outsiders, which filled them with a “skeptical animus.” Because they had no vested interest in “the alien lines of gentile inquiry,” they were able to question everything, even the most cherished of assumptions. Just look at Einstein, who did much of his most radical work as a lowly patent clerk in Bern, Switzerland. According to Veblen’s logic, if Einstein had gotten tenure at an elite German university, he would have become just another physics professor with a vested interest in the space-time status quo. He would never have noticed the anomalies that led him to develop the theory of relativity.

Predictably, Veblen’s essay was potentially controversial, and not just because he was a Lutheran from Wisconsin. The magazine editor evidently was not pleased; Veblen could be seen as an apologist for anti-Semitism. But his larger point is crucial: There are advantages to thinking on the margin. When we look at a problem from the outside, we’re more likely to notice what doesn’t work. Instead of suppressing the unexpected, shunting it aside with our “Oh shit!” circuit and Delete key, we can take the mistake seriously. A new theory emerges from the ashes of our surprise.

Modern science is populated by expert insiders, schooled in narrow disciplines. Researchers have all studied the same thick textbooks, which make the world of fact seem settled. This led Kuhn, the philosopher of science, to argue that the only scientists capable of acknowledging the anomalies — and thus shifting paradigms and starting revolutions — are “either very young or very new to the field.” In other words, they are classic outsiders, naive and untenured. They aren’t inhibited from noticing the failures that point toward new possibilities.

But Dunbar, who had spent all those years watching Stanford scientists struggle and fail, realized that the romantic narrative of the brilliant and perceptive newcomer left something out. After all, most scientific change isn’t abrupt and dramatic; revolutions are rare. Instead, the epiphanies of modern science tend to be subtle and obscure and often come from researchers safely ensconced on the inside. “These aren’t Einstein figures, working from the outside,” Dunbar says. “These are the guys with big NIH grants.” How do they overcome failure-blindness?

While the scientific process is typically seen as a lonely pursuit — researchers solve problems by themselves — Dunbar found that most new scientific ideas emerged from lab meetings, those weekly sessions in which people publicly present their data. Interestingly, the most important element of the lab meeting wasn’t the presentation — it was the debate that followed. Dunbar observed that the skeptical (and sometimes heated) questions asked during a group session frequently triggered breakthroughs, as the scientists were forced to reconsider data they’d previously ignored. The new theory was a product of spontaneous conversation, not solitude; a single bracing query was enough to turn scientists into temporary outsiders, able to look anew at their own work.

But not every lab meeting was equally effective. Dunbar tells the story of two labs that both ran into the same experimental problem: The proteins they were trying to measure were sticking to a filter, making it impossible to analyze the data. “One of the labs was full of people from different backgrounds,” Dunbar says. “They had biochemists and molecular biologists and geneticists and students in medical school.” The other lab, in contrast, was made up of E. coli experts. “They knew more about E. coli than anyone else, but that was what they knew,” he says. Dunbar watched how each of these labs dealt with their protein problem. The E. coli group took a brute-force approach, spending several weeks methodically testing various fixes. “It was extremely inefficient,” Dunbar says. “They eventually solved it, but they wasted a lot of valuable time.”

The diverse lab, in contrast, mulled the problem at a group meeting. None of the scientists were protein experts, so they began a wide-ranging discussion of possible solutions. At first, the conversation seemed rather useless. But then, as the chemists traded ideas with the biologists and the biologists bounced ideas off the med students, potential answers began to emerge. “After another 10 minutes of talking, the protein problem was solved,” Dunbar says. “They made it look easy.”

When Dunbar reviewed the transcripts of the meeting, he found that the intellectual mix generated a distinct type of interaction in which the scientists were forced to rely on metaphors and analogies to express themselves. (That’s because, unlike the E. coli group, the second lab lacked a specialized language that everyone could understand.) These abstractions proved essential for problem-solving, as they  encouraged the scientists to reconsider their assumptions. Having to explain the problem to someone else forced them to think, if only for a moment, like an intellectual on the margins, filled with self-skepticism.

This is why other people are so helpful: They shock us out of our cognitive box. “I saw this happen all the time,” Dunbar says. “A scientist would be trying to describe their approach, and they’d be getting a little defensive, and then they’d get this quizzical look on their face. It was like they’d finally understood what was important.” What turned out to be so important, of course, was the unexpected result, the experimental error that felt like a failure. The answer had been there all along — it was just obscured by the imperfect theory, rendered invisible by our small-minded brain. It’s not until we talk to a colleague or translate our idea into an analogy that we glimpse the meaning in our mistake. Bob Dylan, in other words, was right: There’s no success quite like failure.

For the radio astronomers, the breakthrough was the result of a casual conversation with an outsider. Penzias had been referred by a colleague to Robert Dicke, a Princeton scientist whose training had been not in astrophysics but nuclear physics. He was best known for his work on radar systems during World War II. Dicke had since become interested in applying his radar technology to astronomy; he was especially drawn to a then-strange theory called the big bang, which postulated that the cosmos had started with a primordial explosion. Such a blast would have been so massive, Dicke argued, that it would have littered the entire universe with cosmic shrapnel, the radioactive residue of genesis. (This proposal was first made in 1948 by physicists George Gamow, Ralph Alpher, and Robert Herman, although it had been largely forgotten by the astronomical community.) The problem for Dicke was that he couldn’t find this residue using standard telescopes, so he was planning to build his own dish less than an hour’s drive south of the Bell Labs one.

Then, in early 1965, Penzias picked up the phone and called Dicke. He wanted to know if the renowned radar and radio telescope expert could help explain the persistent noise bedeviling them. Perhaps he knew where it was coming from? Dicke’s reaction was instantaneous: “Boys, we’ve been scooped!” he said. Someone else had found what he’d been searching for: the radiation left over from the beginning of the universe. It had been an incredibly frustrating process for Penzias and Wilson. They’d been consumed by the technical problem and had spent way too much time cleaning up pigeon shit — but they had finally found an explanation for the static. Their failure was the answer to a different question.

And all that frustration paid off: In 1978, they received the Nobel Prize for physics.

Contributing editor Jonah Lehrer (jonah.lehrer@gmail.com) wrote about how our friends affect our health in issue 17.10

2009 July 3 [Friday]

linuxchix-india moves to india.linuxchix.org

Its been some months since LCIN got a new home on Ketan's server and moved to a wiki at :

LC India Chapter website : http://india.linuxchix.org/
Planet : http://india.linuxchix.org/planet
Mailing list : http://mailman.linuxchix.org/mailman/listinfo/indichix
IRC : #indichix on the server irc.linuxchix.org

Well, Terri updated the official chapter page for India, so its high time Radha (i need your blog uri please !?) and Kadambari who completed the move and admin the server with Ram and Ketan helping them all along, got due credit. Thanks a ton folks - y'all r0ck :)

Lazy /me should have blogged about it earlier but i've been preoccupied with stuff. After wrestling with it for ages I finally started putting down my thoughts on all the linguistics stuff on a second blog earlier -- gee, i hardly have the patience to scribble on this blog and here i am creating another maintenance blackhole. *sigh* what was i thinking !!

Atm, in all probability it will remain a private space for me to distill my thoughts from the pen and paper khichidi which was turning me scatter-brained each time i ask someone for their opinions and thoughts.  Last week, MM and me were out and over-enthusiastic 'me' spent all my cash on some books (not that there are many great publications by Indian authors, but...duh !!), instead of that dress i wanted.

I was planning to attend the fosscomm meet in delhi, mainly as an excuse to meet Hassath, an LC'er with whom i've only corresponded online in the last 5 years. Maybe on Sunday, which gives me a day to extract my money's worth from the dead-tree versions before the trip.

2008 September 15 [Monday]


Its fantastic to see an idea grow and carried forward because other people believe in it. Thrilled to announce that we have a new addition to the LC family -- Labs in DELHI :-) YAY !!

FAT-net has agreed to host the space and bandwidth and its open to women learners only but men are allowed to conduct technical talks. Check the 'fat-net.org' website for their addres. Contact Hassath [hassath gmail com] and AjayKumar [ajuonline gmail com]for more details. With Delhi its 4 Indian metros covered ...the others being :

2.MUMBAI: At the Bigadda office in Malad. Contact Jayashree Pare [Jayashree DOT Pare # GMAIL DOT] or Warren Noronha - Email: warren.noronha AT gmail.com { Phone: +91-989-280-6204}

3.PUNE :  Contact Swatee Karpe (swateekarpe # GMAIL dot COM) for further details.

4.BANGALORE : DeepRoot Linux Pvt. Ltd., #93/4, First Floor, Nandidurga Road, Bangalore - 560 046 INDIA Phone: +91 (80) 4112 4781 / 82 / 85. Contact Mr. Abhas Abhinav or me.

2008 September 7 [Sunday]

FSF bengaluru meetup

FSF-India (aka gnu.org.in) is the force behind fending off the pro-software patent lobby in India. Thus far they have done a very good job of resisting the legislation of software patents. This was the first agenda, among other things, discussed in the planning meeting to celebrate Software Freedom Day/Week from Sep20-27.

FSUG-Bangalore met at Sunil's office and he pampered us with drinks, pastries and snacks :). If i recall all the names correctly it was Edwin, Jayakumar, Renukaprasad, Sujith, Abhas, Senthil, Anivar, Sunil, Sreedhar, and me attending yesterday..... Did I miss 2 names? sorry :-/

Among other things we had suggestions for :

0] Celebrating GNU's 25 b'day.

1] Statewide contest,

2] Say No to Software Patent Campaign debate

3] Install fests,

4] Celebrating SFD with BMS, RV, Christ, St.Joseph's college students at multiple venues.

5] Banners, posters , etc... Corporates pitching in are always welcome.

AND more ....Over the next few days things will fall into place.

2008 September 1 [Monday]

packaging 101@UDW

Ubuntu Developer Week is going on right now and Daniel Holbach kicked it off with a packaging 101, which i was attending at #ubuntu-classroom. I started to write this entry as he conducts the session. Here is the rephrased version of the live session, and if any important bits are omitted, please leave a comment to poke me.

Dholbach started off with walking us through the bare-bone structure of a source package (OT the .deb files/binary packages)>, the stuff that makes a package build and what one will encounter in almost all packages. Some links he gave:



Next, he asked folks to download a small sample package (devscripts package), which contains the tools needed for packaging. Then, used (dget http://daniel.holba.ch/motu/hello-debhelper_2.2-2.dsc ,command) to get the source package and saw a little about version's between Debian and Ubuntu, how ubuntu names the repackaged package from debian and pushes it upstream if any changes have been made and so on.

The orig.tar.gz is the original unmodified source code tarball that was released on the homepage of the upstream developers (software authors) and .diff.gz is the compressed patch we apply to make it build "our way" which means Ubuntu need to add a bunch of instructional files to be able to apply ONE build process to all kinds of source packages (no matter if they are python, PHP, C, C++, etc), which applies to most of the packages that use the auto tools (automake, autoconf, etc)

Running "dpkg-source -x hello-debhelper_2.2-2.dsc " command, extracts the tarball and apply the patch while the .dsc file is used to check the md5sum and so on (it contains a bit of meta-data about the source package).


Command : cd hello-debhelper-2.2 Debian/changelog has a very strict format to adhere to but there's the dch tool in devscripts that makes the task easier and each upload specifies: the name of the source package, the revision, the part of Ubuntu (or Debian) it is uploaded too, the changelog entry text itself and who made the particular upload, timestamp, etc... VERSION Looking at the topmost entry the upload has the revision number 2.2-2 and was uploaded to "unstable". The 2.2 (the part in front of the dash) means: this is the upstream release that was packaged.

Example : the hello-debhelper_2.2.orig.tar.gz which basically said: these are the unmodified changes that upstream released as 2.2 on their homepage. If you change a tiny bit in the package, upload 2.2-2ubuntu1, which means :

- 2.2 was released upstream,

- 2 revisions have been made in Debian,

- 1 in Ubuntu,

Then if Ubuntu packager forward the changes to the Debian maintainer, it will be incorporated in 2.2-3 to "sync" the package from Debian again.

Beware, "resetting the counter" in Ubuntu would mean "overwriting all Ubuntu changes with the changes that have happened in Debian" which is risky as one could drop other small bits that were important to Ubuntu users and might be a regression. In some cases where Ubuntu is not able to sync straight-away (different opinions of maintainers, upstream, etc) Ubuntu devels merge the changes.

Some version strings like "2:1.0~rc2-0ubuntu13" , where the "2:" is called "an epoch" and it allows you to use a lower version number again which the common use-case for reverting to an older version of the package.

Example : you maintain the package frobnicator in Ubuntu and shipped the safe but boring 2.0.0 version in hardy (say 2.0.0-0ubuntu1) but in intrepid you decide to update to 2.1.87 because the set of features sounds cool. This would change to 2.1.87-0ubuntu1 in intrepid but after getting lots and lots of bug reports from users that your software is broken you decide to go back to 2.0.0 again. Then you ship 1:2.0.0-0ubuntu1 in intrepid release and everybody would be happy again.

To summarize, the epoch should be used when upstream changes the versioning scheme and the epoch is also another way of making sure the version number is always increasing. Epochs are a nice feature, they just come with the problem that if Ubuntu decide to introduce one and the respective Debian maintainer decides to NOT use one, its a problem since new Debian revisions will always be smaller than ubuntu and we cannot "sync" any more.

DistroDiff: if you take a source from SuSE it would not work for Debian as the build process is different there.


Looking at the two stanzas, where first one is about the Source package, the following one(s) are about binary package(s). A source package needs a name, a section and a maintainer and Standards-Version gives us the clue which version of the Debian Policy (THE document to know about packaging rules) the package complies with in testing other bit: Build-Depends


Build-Depends, the bare min reqd to build packages and he explained how to extract the package, copy it into a minimal build environment (chroot containing build-essential which gives make, etc) and then install the build-depends.

He illustrated it with an Example : If dholbach uploaded a revision to the build daemons (soyuz), upstream will extract the package (just like Ubuntu did), copy it into a minimal build environment (chroot containing build-essential which gives make, etc), then install the build-depends. Having described the resulting binary packages (all files that are going to be installed into the package go into one package) he pointed out those with which have a package name and description (that turns up in synaptic, adept, etc) and has Architechture and Depends

Command: apt-cache show hello-debhelper | grep ^Depends

will return a "Depends: libc6 (= 2.5-0ubuntu1)" which means the hello-debhelper package that is in the archive needs libc6 to be installed. The build process will figure out which shared libraries the binaries (stuff in /usr/bin/ or /usr/lib/ etc) in our package are linked against and which package they are in. Dependencies anyone ???


Running out of time he moved on to copyrights and mentioned that debian/copyright is another critical part of the packaging process. Its critical for different reasons as it has little to do with the actual build process, but it makes sure each packager reflects all the copyright holders, copyrights and upstream authors in the package.

At times, there is proprietary content that can't be shipped because of licenses that forbid any changes. but one that must be paid close attention to (when you create a package from scratch) the source tarball which should ship the verbatim license texts all itself and you need to reiterate this.


Command : #!/usr/bin/make -f

This was the last part of the puzzle : it's a Makefile. If one has worked with makefiles, its easy to build targets called clean, install, build, binary-indep, binary-arch and so on. On those targets the upstream build system is "wrapped", ./configure is called, make is called, etc ...with different prefixes and in 'special' places. The dh_* scripts are all part of debhelper (remember, it's the package that is build-depended on), contains a huge set of very handy helpers to make common tasks like "install this .desktop file and register it in the right place" or "put this changelog in the right place and pretty please compress it" very very easy.

To avoid getting a piece of the source package all wrong, he recommended to start working on existing packages, fix small bugs first before moving on to other things.

Links : https://wiki.ubuntu.com/MOTU/GettingStarted for all the documentation and you can join #ubuntu-motu if you ever have any questions about packaging. After a lot of hugging JorgeCastro started his talk on "Upstream Bug Linkages" but that interesting topic belongs to another post.

2008 August 27 [Wednesday]

its live

On Monday, Abhas, Tania and me met at the Deeproot office  ...yeah I should have blogged earlier.... pfft. but I dislike writing reports. so here is Tania's summary of the meeting to the indichix list :

Though I went to the meeting mainly as an observant, I wanted to share with the list what I found was an important input to the project: the idea of setting up labs not only as technical learning environments, but as project learning environments in which women (and men, Vid, please react/correct me if this was not a point agreed or discussed with Abhas) can contribute to the development of social projects which would be  enhanced by the use of free software. The advantage is that that contribution becomes itself a way of learning about FLOSS for those who are joining the labs. It is a two way process!!! It is a colaborative learning environment, set up not just for the sake to participate in the FLOSS community, but to doing it so, as a way to help others, to enhance community building around FLOSS, a community that goes beyond expert users. WOW! sorry, I really think is a great idea and I believe it completely fits into LC philosophy.

Besides DeepRoot has already a network of nonprofit organisations that would work as a starting point for this (http://www.deeproot.co.in/deepofix/users).

Unfortunately I could not stay till the end of the meeting, perhaps I could say something more if I would have ... but anyway, I hope in the other cities this labs are opening up great opportunities for you girls to develop new understandings and possibilities of what LC is about in India, just like I felt it started to happened yesterday at DeepRoot.

Tania's very eloquent mail saved me the task of writing most of this blog entry :-P so now i return to worrying about the coming weekend activity : how many hours will i waste to drape this ? Am missing the experts so much now :(

2008 August 25 [Monday]

linuxchix bangalore meet-up

Abhas of DeepRoot Linux expressed an interest in hosting LC-labs at bangalore and we are having a meet-up at his office at 4pm today. This should give each woman an opportunity to discuss their individual interests, find out what options are available and how she can make the best use of the facilities at hand.

The Deeproot office is near Cantonment station which I hope is not very inconvenient and yet central for women to access. Here is the office address : #93/4, First Floor, Nandidurga Road, Bangalore - 560046 INDIA

See you there !!

2008 August 15 [Friday]

LC Labs sponsors

At any given point my draft box tends to overflow with half-finished entries, some of which i discard if i aint in the blogging mood. To maintaiin the semblance of a regular blogger, i finally got around to using the weasel method of auto publishing while away enjoying the Independence day weekend. Happy 15Aug !

In the libre community the easiest way to ensure the growth of an idea or project is to allow people wanting to participate to take it further. So at Pune we have Swatee Karpe (PLUG) sponsoring the labs for weekdays and weekends and if you are in Mumbai you can get in touch with Jayashree Pare and Warren Noronha :
Email: warren.noronha AT gmail.com
Blog: http://www.hyperionreactor.net
Phone: +1-415-620-8700
Phone: +91-989-280-6204

While these spaces are open to the public, its not a random walk-in audience-oriented space. Rather, it is an opportunity for women (and men who support them) who usually collaborate online to work together, in person, on specific tasks. If interested, get in touch with the person(s) listed above to find out the timings. They will be managing the whole show locally.

If you have and idea, space or want to donate machines, here is a list of people whom you can contact for the following cities :

1] Delhi : Hassath [hassath gmail com] and AjayKumar [ajuonline gmail com]
Requirements: Space + infrastructure

2] Bangalore : me [vid at this domain]
Requirements: Space + infrastructure

For Chennai, Hyderabad and Mangalore we have people interested in being mentors and mentees but since this is the Free/Libre community feel free to take the initiative to find sponsors for space and infrastructure. Here is the standard format I use for writing to prospective sponsors.

--------- Letter --------

Dear Sir/Madam,

[Here, add your name and intro, unless you know the person, inwhich case, not required]

As per our discussion, this is a formal request to [add the company name] to provide us with a small room for conducting mentoring
sessions on Libre software in your organisation.  LinuxChix is a community for women who like Linux, and for anyone who wants to support women in computing. We are an international group of Libre Software users and developers, founded in 1999 with the aim of "supporting women in Linux". We have several local chapters [0] across each continent.

[0] http://www.linuxchix.org/regional-chapters.html

Having LC labs is an experiment, mainly aimed at increasing women participation in Libre software communities. Since the number of women contributing to libre software is very low (~2% ) when compared to men. In contrast the proprietary ICT industry has 28% participation, further balanced at around 50% in India, but yet few Indian women volunteer with Free/Libre software. We are trying to bridge this skewed gender gap and experiment with possible solutions.

Due to low ICT adoption in India, especially Libre software, we would like to earmark a sponsored local space which will be open to women of any age, irrespective of their financial, social or educational background to use. Since Libre software is freely available anyone is free to learn to use and contribute to it.

Thus far, LinuxChix has largely been an online interaction experience via IRC and mailing lists. This effort is meant to provide women the opportunity for periodical meetings, arrange regular sessions and workshops to contribute to Libre software. Currently, for Mumbai planning and execution is underway with Pune being the second city to follow.  The focus is on contributing upstream (Debian, Ubuntu, Gentoo, etc... ) and our activities would mainly revolve around :

- learning to do packaging,
- learning the dependency cycle,
- creating patches,
- bug squashing,
- localisation/translation of libre s/w
- conducting hack sessions,
- etc....

The LinuxChix-India Chapter was also featured in the ET recently :


We have no age restrictions or qualification limits and any woman with a desire to learn is welcome. We hope [add company name]  can support us in this endevour and help us turn this into a successful experiment to inspire others to contribute and create Libre software and not limit it to Indians being mere consumers of Libre software.

Awaiting a positive reply !

Thanks for reading.


[add your name]
Team LinuxChix-India

2008 August 5 [Tuesday]

An idea grows

Besides the pleasant weather another way to recognise I am in Bangalore is when there is a powercut. And what timing, precisely when i am working on the machine or need to fix dinner. Nice try BESCOM. </end infrastructure rant>

So far the responses to yesterday's request have been good, got some mails and an interesting comment. There was a request for Indichix labs in Mangalore and Bangalore BUT I never knew it would be so tough to get space in Bangalore. That is a surprise for sure.

I also got an office space for Pune and found a mentor in Chennai, Sudarsan Santiappan, who's comment had pertinent questions which may help us evaluate things. My reply to his comment was so long that I think its best converted into another blog post as I was repeating most of the following in each individual mails. Am I lazy or wot ^_^ ?

So here goes...

SSudarsan: If I understand correctly, this is typically equivalent to setting up a company which would target to deliver OSS. In the process of delivery, the team gets matured as OSS contributors.

Yes, in a sense its comparable, but the differentiator is none would earn a salary as we are non-profit project :-)  Jokes apart, for example, the goal is NOT to learn/create an "Indian" or a "pink" distro. Instead mentors can teach about the dependency cycle, package management, packaging across platform, and help to improve/develop/maintain the existing distro's, bug squashing/patching, and so on... Since LinuxChix is distro-agnostic, any experienced volunteer from the Debian, Ubuntu, Kde, Gnome, Python, Suse, etc ... communities can conduct talks, demos, take live sessions to encourage IndiChix. Most importantly sharing and learning in a group is fun and we develop new skills besides the knowledge gained during the learning process, plus the peer recognition and meeting nice people. So coolness factor is high !!

SSudarsan: The best places to start such an endeavor are the following;
1. Houses that can accommodate few computers and people with Internet support.
2. Computer centers of Schools and Colleges, which can hired at subsidized cost.
3. Tie-ups with Software Learning centers.

Cafe Coffee Day is not exactly the best venue for meetings nor conducive to learning packaging. So if we can provide an environment where they can come during weekends to learn for a few hours it would be a worthwhile experiment. In a nutshell the challenges and pressures are different and yet similar across different Indian cities; Also we are not-for-profit and have no inflow of revenue so hiring is a long shot at the moment, unless we find a generous sponsor :)

SSudarsan: One needs to have the following but not limited to; to sustain such an endeavor are the following:
0. Understanding the Vision

Contribute upstream. To add and expand, the moot idea is to reduce the challenges, as the knowledge divide for women is higher. With this experiment we can try to bridge this with help from like-minded people. Unlike other developed nations, in India, we have a number of women working in the proprietary software industry, which may be equivalent to men, but yet we have few (maybe around 100+) giving back to the Libre community. I met many newbies who are confused about:

+ where to start contributing, how to start, etc...

+ self-doubts about being good enough,

+ lack of knowledge about existing projects, or

+ Even wonder what to do at projectA, does my skill set match, do i have enough experience, etc... 

SSudarsan: 0a. Are you going to do service ?

Service ---> "upstream"  projects.

SSudarsan: 0b. Are you going to develop free s/w for the community ?

Absolutely, YES. Creating islands of excellence seems counter-productive.

SSudarsan: 0c. Are you going to commercialize the s/w developed ?

Not sure I understand what you mean but ...; I am no lawyer but I suppose; the existing license of the upstream project will prevail. This may change depending on the project too. :-8

SSudarsan: 0d. Are you having enough money flow to sustain this operation ?

As mentioned earlier, we are not-for-profit and generating revenue is not exactly on the top of the list right now. Besides the legal implications there are enough challenges, as is, to solve :)

SSudarsan: 0e. Who are the beneficiaries ?

Any (wo)man interested in helping and contributing to IndiChix, upstream projects, sponsors (you get to evaluate potential dedicated, hardworking technically adept women).

SSudarsan: 1. A Business model to sustain software development. Preferably a revenue model for sustained operation covering inflow and outflow.
2. A team of mentors/managers to train contributors and execute projects.
3. A detailed plan for people, projects, revenue in terms of growth and prospects.

and more...

If such a system is setup in Chennai, I would be willing offer mentorship.

The revenue model is too early imho, as
We (are a not-for-profit org and it has legal implications. Currently we will have to find a way to survive on sponsors aka charity.  Thanks for offering to mentor in Chennai.

To subscribe to IndiChix list, visit the list http://mailman.linuxchix.org/mailman/listinfo/indichix

2008 August 4 [Monday]

libre labs for indichix

A few weeks ago I had asked if there was any IT firm in India willing to host Free Software Labs just for women ? Many people wrote and asked what it would entail and I had suggested:

#1. Requirements :
1.1 Libre computer labs equipped with machines and an Internet connection.
1.2 Centrally located within city limits.

#2. Goals :
2.1 These labs ensure a static space so women dont have to travel far or to lonely places for local meets.
2.2  It would enable local FSF/GNU volunteers to introduce and teach them packaging, translation, bug-squashing, etc...
2.3  Increase contribution to upstream projects like Debian, Ubuntu, Fedora, Gentoo, Suse, KDE, Gnome, etc...

#3. Do's and Dont's :
3.1 Not meant to be used for personal use (downloading movies/songs, chatting, etc...)
3.2 Currently restricted to women participants.

#4. Managing and growing the Idea :

Managing and decision making (how many days a week, who will talk, what talks, etc....) is left entirely to the women volunteers in the city.

4.1 Mumbai :  Although I had started out looking for space in Bangalore, I have an interesting proposal from an MNC in Mumbai who are willing to lend space, infrastructure etc). BUT at this point, I would like to know if chix in Mumbai are willing to take this further.I would not be able to do that from another city and neither am I interested in micro-managing things. I would prefer if local chix took initiative in this regard. So is anyone up to the challenge ?

4.2 Bangalore : Currently, machines are available but space is a challenge. At Mukt.in a few alternatives were suggested so let me see how things pan out.

4.3 Delhi : Not much except I found a committed volunteer (again at mukt.in) who is willing to help out with this. Any Delhi-chix interested ?

4.4 Other cities: Please reply to the list if you want a similar lab in your city.

The whole idea is centered around sharing and learning together. With a systematic effort we may reduce and hopefully eliminate the "how do I start" which is the common question every newcomer has.  That said,this needs your co-operation and depends entirely on your interest levels.

So I hope we pull this off as a team !!  Do add your thoughts /suggestions to improve it.


/end mail......................

That was the mail I had sent a little earlier to the Indichix mailing list. I just came back from Hyderabad today morning, where I was attending mukt.in from Friday. To my utter surprise things fell into place at and I have a lot to blog about, the event and the fun I had :-P

2008 July 16 [Wednesday]

launchpad re-launched

Rinchen just announced the new theme that LP has got. They have the nice new logo from the contest winner too :)  As i write this, I logged in once using an openid page and not the regular launchpad.net page.

The new theme is visible only to the beta testers so i cant blog much about what i like and dislike since that will keep changing too over time. But I noticed the favicon for the news page (see the url) has the old logo but the help page has the shiny new colored hexacon on the left, next to the url. So I filed a bug and its fixed (update). Now its time for some shuteye before the morning run.

2008 July 14 [Monday]

linuxchix-india in the news

Tweeting and denting helped this last month and now its back to blogging ?? .... dunno, but I have definitely been slow in blogging about LCIN being in the news. A few weeks ago Fred had written to the mailing list (along with a long questionnaire :-)) wanting to write an article on IndiChix (the Indian chapter of LC). His article on Indichix has now been syndicated in the Economic times and Siliconindia,and many other publications ...someone even dugg it. Nice, thanks Fred !!

Besides the other challenges that women face its no surprise that you will find access to infrastructure a real issue. This may be a common problem for a lot of women all across the world but in India its worse. Without getting into the reasons as I dont think they can be analysed, quantified and solved easily. Rather than dwell on the "why" I had suggested this idea on the list :

Ask IT MNC's in India as part of their CSR (corporate social activities) to sponsor small 'libre-learning-for-women-labs' in their office premises which should be open to any woman to use and learn about Gnu/Linux. These Libre computer labs should be equipped with machines and an Internet connection which would enable local FSF volunteers to introduce and teach them packaging, translation, bug-squashing, etc...

Is there any IT firm in India willing to host Free Software Labs just for women ??

2008 June 11 [Wednesday]

non-gpl hardware

Matthew has an interesting entry listing out all the non-gpl hardware components that we are still forced to use. I hope that catches the attention of Libre software proponents and gets them to redirect their energies, instead of wasting time dissing Ubuntu (no links, you can find the comments yourself) or griping about the other Libre software projects out there...

.....and no please dont say you only buy hardware that only supports GPL because the common folks on the street would not even know what is GPL and lesser still about binaries, codecs, embedded controllers, acpi, blah, blah...

For that matter it would be cool to have every electronic appliance around me run on GPL code ...hmm... ok, time to go back to reality now !

2008 May 22 [Thursday]

Freeze it

Touché, Craig ! At the Fridge we've been wanting to get all the loco's that had Ubuntu release parties and community events featured, but want to do that without treading on toes w.r.t. licence** issues. The team is working on some cool ideas at UDS and we want every loco team out there to send us articles, pictures, announcements, etc... of your local city-event on Ubuntu.

It does not matter if your event is small and was held in a college in foo-city/village/country. If it is Ubuntu related, it deserves to be on the Fridge and location does not matter. Frankly, a link from the Fridge can really drive traffic to your blog :)... [Caveat: make sure its a personal non-commercial blog and not related to your work-place/school/college or anything equally sticky... and puhleez no cheesy titles of 'Ubuntu with girl/boy-friends'. That would be the easiest way to not feature on the Fridge. You can do better.]

Go get creative folks! Submit of your stories (including pictures) should be sent to {fridge-devel (add@) lists (add.) ubuntu (add.) com}

** So does the CC cover issues like scrapers sponging off on your google juice? I've had issues with scrapers in the past, who according to SEO experts are parasites feeding on Adsense and dont deserve to sponge off me -- googling for the string "Vid" (my root, but its also a slang for 'video' in English) throws my blog within the first few hits, and thanks to both of them, my problem was solved. CC sounds good but apparently Google requires the authors copyright. 

2008 April 24 [Thursday]

no real name

Finally the real name policy (on LP beta testing team) has been done away with. In the past, there have been many discussions against the policy with zero outcome and not so nice things like people being kicked out for not following the "real name" policy. Last year, I was rejected for not agreeing to the RNpolicy and in Jan when the fridge was in transition mode, we editors were going to trial out the list via LP. Since I've felt the RN-policy was restrictive, I offered to leave the team rather than being forced to accept something that encroached on my individual/personal freedom of choice. That LP is not GPL'd is subject matter for another post.

I have always been a supporter of using nick's online and not necessarily because of gender and the accompanied harassment. If fame and recognition is what people want, they know how to get it, but in my case its a question of personal choice/freedom. That said, in the libre software community you are what you do/behave/act and one is not defined by name, age, nationality, colour, country, beliefs, etc...

.... Which brings me to policy making. Most times, on closer observation it is evident that policies are adhoc despite the good intentions behind it. If they lack the multi-dimensional view-point we wont be anywhere closer to a possible solution than when we started. Which will only leave us with procedures and processes which people will blindly follow (hint : the CoC signing, which needs a separate post too) because it exists and needs to be done with inorder to get to the next level of power. Wrapping a coat over the real issues does not get the desired positive results, if that is what the community wants to see happen....especially not if you are trying to solve a social problem with technical solutions. Does not work. Period.

So I am really glad that someone's been listening and finally got rid of the real name policy. Thanks, dil se :)

2008 April 3 [Thursday]

wrong path

Legitimizing monopolistic standards does not help create an open, free and transparent environment. Doing IT Wrong.

2008 April 1 [Tuesday]

libre laptop

Hmm... I've been lazy about bragging about this : The OS free laptop that I had helped load Ubuntu was sold within that week. How cool is that !!

I cant take any credit for the sale as it was the efforts of the sales person there, but knowing  that i contributed indirectly to the sale makes me feel warm inside. Breaking down pre-conceived mindsets was not easy and the sales guy did a good job of selling it. His manager informed me that they were pleased enough to pre-load all the machines with it. Now I need to mail him the Ubuntu-AMD cd's :)

I wish more machines would be sold with _linux-inside_ (tm?) in India. Go experiment, Be different!

2008 March 22 [Saturday]

holi and linux

Gone are the simple water-balloon days and what used to be a fun fest gets worse with each passing year. Ugh, who wants to walk around with purple-green hair... Holi is so much safer with just good friends N family, given that its de'riguer for strangers to pelt one with balloons filled with chemicals, or eggs, stones, paint (nope, not the fabric kind) and other assorted rubbish-filled balloons all through the week before Holi. On Holi day absolutely anything goes. Besides Holi, many friends will be celebrating Good Friday, Purim (Jews), Navroz (Parsis), Eid, and Magha Puja (Buddhist)... a lunar co-incidence of 6 different religions or what ? Happy festivities y'All :-)

Recently, I saw some laptops on sale/display sans any OS (had Free Dos) at a retail establishment. I asked for a demo and (as expected) he could not provide one. I asked if he would load any OS of my choice and he hesitated. He probably thought I might hand out a pirated Windows CD to him or something illegal so that was my cue to give him an primer on what Gnu/Linux, Ubuntu, GPL, etc... was all about and he smiled that all-knowing smile while listening and I knew it was a home run. Its a relief that awareness is getting higher, people actually know what piracy is all about and dont stare blankly when you say "Linux".

I happily provided him the Ubuntu (but ofcourse :-)) CD and the manager nodded approvingly as we had some good eye-candy for all to see. Since they had a number of models on sale sans the OS, I handed out some Ubuntu CD's to go with the other machines. To see a machine running an OS that is not Windows sitting pretty amongst others is quite nice. Even more fun to see the curiosity it evokes among casual passers-by. The practical touch-N-feel to see-it-work helps a lot more :-)

Btw, Bruce Perens is standing for board elections and needs your help. Viva Free Software !!

2008 January 23 [Wednesday]

indichix needs you

When it rains, it pours. How true ...

Starting week3 of the new year sick has echoes of the past which morphed into a crashed desktop disk and spiced things up with the Ubuntu kernel trouble on the lapy. Subtracted power last weekend for good measure and salted with patchy internet (/me being pro-active, changed it :)) when bestowed with power....boiled over to me wondering if i should have gone for it after all. Since i didnt, it was time for the IndiChix meetup last saturday with Ankita, Vikram and Balu (the Bangalore Mirror reporter) in attendance. Maybe its the location(*)... do we need to find a convenient, central venue in the city ? What the heck, i tend to go around in circles anyway. /eye roll.

Anyway the article that was supposed to be about women in Technology somehow landed up in the entertainment section of Bangalore Mirror. [/me cringes] So if anyone did read about us on Jan19 in the Bangalore Mirror, kindly fill in the blanks, since they dont have a website and Balu was not able to get a copy (sold out he said) that day.
Not that there was a deluge of applicants for this call ; which I announced today, making it easier to focus on stuff i really care about. I also posted the meet-up minutes to the list for further discussion. We had feedback that our website (which is a wiki) is very confusing for newcomers to navigate. Sheesh...... I have to agree that information is difficult to find but a wiki is always like that, in a constant state of flux. A static site is not inclusive and a wiki allows even a newbie to voice themselves. That is not an excuse, but the fact remains that none of the i'chix have ssh access to the private servers where the site is hosted (by Vaibhav) so we depend on him a lot at the moment, and cant keep demanding changes daily without proper planning. That is not practical in the long run. We still need to get the planet up and running, kwim ?
It makes more sense to get a team working right at the start (I understand when Sulamita talks about burn-out, time issues, etc..), something I'd rather not see happen with IndiChix. For this we have to increase the circle of trust and the faster we do it the better it is for the group. Also currently the women dont own the site domain which is ironical, being a grrls group and all that. Not sure about others but I find it absurd to call it a woman's group when women are playing second fiddle (read, scared of speaking their mind). Maybe women fear making mistakes (i know i do too) and being judged harshly on that prevents them from trying in the first place. In the technical world its almost rare to see women stepping up. Strangely, I rarely see men who commit -mistakes- blunders worrying about their image. i digress.

responsibility - authority == no show

One of the aim is to get women involved in every level in the community @ IndiChix, in which case we need to initiate open and transparent communication (which is very difficult as is, and almost impossible if one is constantly going to worry about inadvertently offending people) just like open source code.

Kick-starting that I mailed the IndiChix list (only subscribers can read archives) about the domain being transfered to atleast 2 grrls locally. Names suggested : Archana, Runa, Aneesha, Barkha, and Ankita. I guess responsibility without authority does not scale well in the free software community.... and since its a community it should be a community decision. So subscribe to the list and vote for any 2 grrls you prefer or if you are a 'chix, suggest your name and take over the responsibility. The third name I suggested was one of the TresChix, incase we local 'chix go MIA :)

Folks reading this, if you know grrls interested in web-development please ask them to join us and holler about themselves on the list and suggest ideas there.

(*) For most Bangalorean's distance is everything but here a commute of 15 km is a huge no-no, which is surprising for me. Well Mumbai has a reliable and efficient (albeit crowded) rail system, so people dont balk at travelling 68 km (incl. return trip/up-down) almost daily for work from Borivali to Churchgate (and back). But then folks there are the spirit of the city. There is no melting pot like it elsewhere.

2008 January 18 [Friday]

indichix meetup@blr

The meet-up is at 3 pm tomorrow (atlast :)) Since suggesting it last month, it was getting postponed, /me was sick and i almost thought it wont happen ...but it is gonna happen tomorrow at Christ College (and i still need to map out my way there...sheesh...if i am late means i am lost.). For tomorrow, I had almost convinced an upstream dev to agree to talk tech at the meetup and almost announced it on the list. Almost because as of now he has some other work so maybe next-time. Heck, I intend to keep bugging him till he agrees (and i know you are reading this :)) to talk about his project.

While i was wasting (a lot of) time googling for a solution to this issue earlier today, i saw a bounce in the mailbox from a journalist. Apparently, he had seen a blog about the meetup in bengaluru and wanted to give us publicity. Nice that mainstream media is taking an interest in technology :) Our little journalistic adventure is archived on the list since i had asked that a draft of the article/writeup be posted there. My assumption being : folks can quickly correct mistakes if any, as we have members from different timezones across the world, so responses will be quick (can i say 24/7 :)) and we can avoid wrong messages going in print. Recanting is always a waste of time and never really useful since the damage is already done. Well, there were not many corrections except crediting the appropriate projects.

Terminology is important and since most people will not know what GNU, GPL, FSF and FLOSS meant (egad....!) I sent him a bunch of links for the GNU and FSF projects and a wiki link on what FLOSS is all about. I hope he includes that in the article since that is the only way we can reach out and educate people. Even if one person takes the trouble to type www.fsf.org in their browser and read, we succeed and add to our ilk :) Let's see what happens tomorrow.
For those not in the know, Bangalore Mirror was formerly known as Vijay Times, a very popular daily providing local gup-shup until it was taken over by BCCL (aka TOI) sometime last year. Strangely they still dont have a website. Heck, even Mid-Day has an e-paper for Bangalore. Since i cant link BMirror here, i asked balu (the journalist) to bring 2-3 copies tomorrow when they attend our meet.
Talking of BCCL/TOI, Mint (an HT group publication) had an interesting article about them the other day. Some years ago i remember reading somewhere that most articles were paid for (as in, a company paid the print-media company to write about them, instead of buying plain visual 60x60 cm adverts, which few people glance at anyway). Check out the list of companies BCCL has invested in.

system down

i face a similar problem that neil williams has blogged about, here and here. Two days ago i updated the testing ubuntu system and the grub file was overwritten. That means when my system installs the updates and restarts, it wont be able to because of the annoying bcm43x driver issue crap. Arghhh..... So far i did try all the noapic nolapic permutations and combinations on this page, which ofcourse didnt solve my problem.

MJG explains some here and another here but frankly now i understand when people say Linux is not ready for the mainstream, add hardware that does not support free/libre software and you go down under. With no OS how the hell will they google for help. Thankfully i kept the dualboot on the lappy, so could use windows to google, which has not helped much but need to get this sorted asap. Using Windows the last 2 days has been well a test, but wth...

[update0-jan18] ram says the issue is with the filesystem (fuse), /home is in another partition and booting hangs whilst loading device drivers, does not even boot from the cd..... found a fuse problem, else may have to do a fresh install if nothing else works :(

- page 1 of 2