So, this morning, I did my first video call over XMPP between two N900.
However, so far, I failed to do an XMPP video call from an N900 to something else. When I try to call pidgin on my laptop, pidgin simply crashes, but of course that’s not a serious bug if people can DOS your pidgin instance since, according to the Debian bug:
Assuming your XMPP settings require that users must authenticate with you before being able to send you messages, only your authenticated users would be able to freeze your client, assuming they knew you were actually affected by this bug.
The upstream pidgin bug hasn’t seen a lot of activity lately. :-(
(Previous editions: 2005, 2006, 2007 and march 2008)
Here are my (almost) yearly stats about XMPP/Jabber clients (OK, the last one was 18 months ago).
1250 users were online on the Apinc Jabber server when I ran the poll, and 1192 clients answered. This year, I’ve also used Disco to poll the clients, allowing to detect Telepathy (thanks Sjoerd for the tip!).
- Pidgin 43% (2008: 27%)
- Gajim 19% (2008: 20%)
- Psi 9% (2008: 16%)
- Kopete 7% (2008: 14%)
- Adium 5% (2008: 6%)
- BitlBee 2% (2008: <=2%)
- Telepathy 2% (2008 unknown)
- Other clients with less than 2%: iChat, Pandion, Miranda, mcabber, Smack, meebo, Trillian. All other clients had less than 5 users online.
The systems and distributions stats are biased, because some clients don’t disclose that information, or worse, give wrong information (Psi reports running Debian when on Ubuntu).
- Unknown 57% (Pidgin doesn’t report the OS) (2008: 36%)
- GNU/Linux 24% (2008: 40%)
- Windows 15% (2008: 17%)
- MacOS 2% (2008: 5%)
- Others 0% (3 FreeBSD, 2 OpenBSD)
164 clients reported a Linux distribution (249 last year).
- Ubuntu 44% (2008: 45%)
- Debian 23% (2008: 36%)
- Arch Linux: 9% (2008: 1%)
- Gentoo: 9% (2008: 10%)
- Fedora: 7% (2008: 5%)
- Mandriva: 5% (2008: 3%)
- Slackware: 2% (2008: 1%)
- The top 5 clients are the same, in the same order, but Pidgin’s lead is increasing. Gajim stays stable at the second place, while the two Qt-based clients, Psi and Kopete, both lose a lot of market share.
- Apparently the Mac hype is gone, at least for Jabber users. Or it’s just that all Mac users use Pidgin, which doesn’t report the OS.
- Regarding Linux distributions, Arch Linux gained a lot of market share over the last year.
I’ve been a member of April, the french association for promotion and defense of Free Software, for a bit more than a year, and I often regret not becoming a member earlier. (I was feeling so guilty and shameful about not being a member that I actually postponed becoming a member.)
Stop feeling guilty and shameful, become an April member today!
Why Is becoming an April member so important?
- Clearly, April doesn’t address the same problems as your local LUG. April is a country-wide organization, and it works on country-wide problems. It’s the only group able to work on such problems at this scale (I’m not sure of the situation in other countries, but I think CCC shares a similar role in Germany for example).
- Each time I talk to people really involved in April (which I’m not), I’m amazed by how powerful they have become. They are able to talk to french or european deputies or ministers’ cabinets, and are considered important. They are doing a fantastic job spreading what matters to us to legislative and executive powers in France and Europe.
Some of the things they worked on recently (from the top of my head):
- Lobbying on :
- General announcements about politics (Plan France Numérique 2012, aka Plan Besson).
- European telecom package and HADOPI law (french graduated response) law, through Quadrature du net. (OK, it doesn’t have anything to do with April, but most of the people involved in Quadrature du Net are also involved in April :-)
- vente liée : the fact that it’s not possible to buy a computer without a Windows license. It’s illegal in French law, but still the de facto situation almost everywhere.
- Organization of a campaign where candidates to elections in France where asked questions, or asked to sign a declaration about Free Software. In 2007, 8 out of the 12 candidates of the french presidential election answered April’s questions.
So, really, become a member today. It’s only 10 EUR, and you already know they will be well used. April is trying to reach 5000 members by the end of 2008.
(Apparently, if you use that address, April will now that you came from me. No benefit for me at all.)
The strongly connected set of the GPG keys graph contains a bit more than 40000 keys now (yes, that’s a lot of geeks!). I wondered what was the biggest clique (complete subgraph) in that graph, and also of course the biggest clique I was in.
It’s easy to grab the whole web of trust there. Finding the maximum clique in a graph is NP-complete, but there are algorithms that work quite well for small instances (and you don’t need to consider all 40000 keys: to be in a clique of n keys, a key must have at least n-1 signatures, so it’s easy to simplify the graph — if you find a clique with 20 keys, you can remove all keys that have less than 19 signatures).
My first googling result pointed to Ashay Dharwadker’s solver implementation (which also proves P=NP ;). Googling further allowed me to find the solver provided with the DIMACS benchmarks. It’s clearly not the state of the art, but it was enough in my case (allowed to find the result almost immediately).
The biggest clique contains 47 keys. However, it looks like someone had fun, and injected a lot of bogus keys in the keyring. See the clique. So I ignored those keys, and re-ran the solver. And guess what’s the size of the biggest “real” clique? Yes. 42. Here are the winners:
CF3401A9 Elmar Hoffmann
AF260AB1 Florian Zumbiehl
454C864C Moritz Lapp
E6AB2957 Tilman Koschnick
A0ED982D Christian Brueffer
5A35FD42 Christoph Ulrich Scholler
514B3E7C Florian Ernst
AB0CB8C0 Frank Mohr
797EBFAB Enrico Zini
A521F8B5 Manuel Zeise
57E19B02 Thomas Glanzmann
3096372C Michael Fladerer
E63CD6D6 Daniel Hess
A244C858 Torsten Marek
82FB4EAD Timo Weingärtner
1EEF26F4 Christoph Ulrich Scholler
AAE6022E Karlheinz Geyer
EA2D2C41 Mattia Dongili
FCC5040F Stephan Beyer
6B79D401 Giunchedi Filippo
74B11360 Frank Mohr
94C09C7F Peter Palfrader
2274C4DA Andreas Priesz
3B443922 Mathias Rachor
C54BD798 Helmut Grohne
9DE1EEB1 Marc Brockschmidt
41CF0322 Christoph Reeg
218D18D7 Robert Schiele
0DCB0431 Daniel Hess
B84EF12A Mathias Rachor
FD6A8D9D Andreas Madsack
67007C30 Bernd Paysan
9978AF86 Christoph Probst
BD8B050D Roland Rosenfeld
E3DB4EA7 Christian Barth
E263FCD4 Kurt Gramlich
0E6D09CE Mathias Rachor
2A623F72 Christoph Probst
E05C21AF Sebastian Inacker
5D64F870 Martin Zobel-Helas
248AEB73 Rene Engelhard
9C67CD96 Torsten Veller
It’s likely that this happened thanks to a very successful key signing party somewhere in germany (looking at the email addresses). [Update: It was the LinuxTag 2005 KSP.] It might be a nice challenge to beat that clique during next Debconf ;)
And the biggest clique I’m in contains 23 keys. Not too bad.
After 2005, 2006 and 2007, I did it again. Here are my yearly stats about Jabber clients!
1244 users were online on the Apinc Jabber server when I ran the poll, and 1163 clients answered. Telepathy doesn’t seem to answer to jabber:iq:version, and it seems that a bug prevents Gajim from answering in some obscure cases (even when the “send info about OS” option is enabled).
- GNU/Linux 40%
- Unknown 36% (Pidgin doesn’t report the OS)
- Windows 17%
- MacOS 5%
- Others 0% (4 clients)
- Pidgin 27% (2007: gaim: 22%)
- Gajim 20% (2007: 22%)
- Psi 16% (2007: 24%)
- Kopete 14% (2007: 11%)
- libpurple (Adium) 6% (2007: 5%)
- iChat 4% (2007: 9%)
- Other clients with 2% or less: gajim, BitlBee, Miranda, Pandion, neos, pidgin (with ‘p’ instead of ‘P’), Trillian, Exodus, Coccinella, JabberLib, Tkabber, Gossip, Digsby Client, sim, Finch, JAJC, Bluejabb, Spark.
A few months ago, I asked a set of questions on development mailing lists of a few GNU/Linux distributions. This resulted in very interesting discussions. As promised back then, all the answers from all distros I contacted can be read on the web or as an mbox file.
Also, Freedesktop.org kindly agreed to host a mailing list to ease discussions between distributions, and act as a central point of contact. You can subscribe, and post to distributions at lists dot freedesktop dot org.
This mailing list is for people involved (or interested) in the development of distributions. Questions that are on-topic are both technical and social/organizational issues, like:
- How do you achieve graphical boot in your distro? Do you use some kind of dependancy-based or events-based boot?
- How do you package both ruby 1.8, ruby 1.9 and jruby, or handle KDE vs KDE4?
- Do you use a system that gives a limited set of rights to new contributors?
Off-topic stuff obviously include trolling about which distribution is the best one, or user support.
Don’t hesitate to forward this announcement to all interested parties. Let’s make this mailing list something useful together!
Also, I really apologize for procastinating announcing this list for sooo long. I’m really good at procastinating interesting stuff, it seems.
There’s an interesting discussion about Google Summer of Code going on debian-devel@. The question can be summarized as “Should we allow current Debian contributors to be students in GSOC?“?
The GSOC FAQ says:
Google Summer of Code has several goals:
- Get more open source code created and released for the benefit of all;
- Inspire young developers to begin participating in open source development;
- Help open source projects identify and bring in new developers and committers;
- Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think “flip bits, not burgers”);
- Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).
The problem is that those goals are clearly conflicting:
- If you think that “get useful code written” is more important than “get fresh blood in Debian”, it is stupid to choose students that are not existing contributors to Debian. It’s a much better idea to choose people that already know Debian very well, so they will be very efficient.
- If you think that “get fresh blood in Debian” is more important than “get useful code written”, it is stupid to choose students that are already contributing to Debian. You should choose outsiders, of course.
Another problem is that in the past, some students that were also debian contributors had problems organizing themselves: they used some of their GSOC time to work on their usual Debian tasks, leading to results that were a bit disappointing. But it’s possible that this is mainly a management problem (however, mentoring people takes a lot of time, and only students are paid, not their mentors).
How do you deal with that in your project?
The bad thing with fixing build failures with dash is that there are still a lot of open bugs. (Remember, the 0-day NMU policy applies to those, so it’s a good opportunity to improve your NMU karma. And I will sponsor your NMUs if you can’t upload!).
The good thing is that you sometimes run into funny code, like:
pushd docs ; $(MAKE) distclean || true ; popd
Since pushd/popd is a bashism, the Ubuntu patch changed this to:
cd docs ; $(MAKE) distclean || true ; cd $(CURDIR)
Which works, but is … interesting? :-)
This morning’s SuperComputing’07 keynote was a talk by Neil Gershenfeld, director of the Center for Bits and Atoms at the MIT. He mentioned the MIT Fab Labs, a project to bring “Personal Fabrication” to people around the around.
At our own level, that’s something I find very exciting with Free Software: it empowers people to do things with their computers that they couldn’t do if they were using proprietary software, simply because proprietary software is built to fit most people’s needs, not very specific goals some people could have. (and this is similar to the Long Tail stuff, in some ways)
Also, if you are at SC07 and reading this, feel free to ping me! I haven’t seen a lot of Debian/Ubuntuers here, even if the Free/Proprietary software ratio is very high.
Scientific papers always have a “related works” section, where the authors describe how the work they are presenting compares with what others did. In the Free Software world, this is nearly non-existent: in a way, it seems that many of us are thinking of their projects as competing products, fighting for market share. On a project web page, I would love to read something like:
This project is particularly well suited if you want XX. But if YY is more important to you, you might want to have a look at ZZ.
Or simply links to similar projects for other environments, etc. All in all, I think that the goal is to improve the global satisfaction. Not to win a few users, who won’t be totally happy, because the project doesn’t really suit their needs.
While some projects cooperate and share ideas, like I think desktop environments do inside freedesktop.org, most just ignore each other. I am both a Debian and an Ubuntu developer, and I’m sometimes amazed that Ubuntu discusses technical choices that were discussed (and solved) a few weeks earlier in Debian. And it’s even worse with the other big distros out there.
Couldn’t we try to improve this ? We could just create a mailing list, where developers from various distributions could present the way they do things. This would allow to discuss future developments (“We are planning to improve this, what are you doing about that ?“) or simply to improve people’s knowledge of the various distributions.
Of course, this could easily turn into flamefests, but they are technical ways to avoid that, like moderating posts from trollers…
Does something like that already exist ? Do you think that it would be interesting ? Would you like to contribute to such a forum ?
Some examples of things that could be discussed:
- How many packages do you have, and how do you support them ? Do you have several “classes” of packages ?
- How do you manage your releases ? Goal-based ? Time-based ? Bug-count-based ?
- Which kind of quality assurance do you do ?
- How many contributors do you have ? Are they split into different “classes” ? Who has “commit rights” ? Can you give out “commit rights” restricted to subsets of your packages ? A organized sponsorship system for people who don’t have commit rights ?
- etc, etc, etc.