Search Results: "ana"

17 March 2013

Soeren Sonnenburg: Shogun Toolbox Version 2.1.0 Released!

We have just released shogun 2.1.0. This release contains over 800 commits since 2.0.0 with a load of bugfixes, new features and improvements (see the changelog for details) that make Shogun more efficient, robust and versatile. In particular, Christian Montanari developed a first alpha version of a perl modular interface, Heiko Strathmann did add Linear Time MMD on Streaming Data, Viktor Gal wrote a new structured output solver and Sergey Lisitsyn added support for tapkee - a dimension reduction framework. Read more at http://www.shogun-toolbox.org

16 March 2013

Lucas Nussbaum: Ideas from the -vote@ DPL election discussions

After one week of campaign on -vote@, many subjects have been mentioned already. I m trying here to list the concrete, actionable ideas I found interesting (does not necessarily mean that I agree with all of them) and that may be worth further discussion at a less busy time. There s obviously some amount of subjectivity in such a list, and I m also slightly biased ;) . Feel free to point to missing ideas or references (when an idea appeared in several emails, I ve generally tried to use the first reference). On the campaign itself, and having general discussions inside Debian: On getting new users and contributors to Debian: Infrastructure, processes, releases: Relationships with upstreams/downstreams: This list could be moved to wiki.d.o if others find sufficiently useful to help maintaining it.

Clint Adams: Los pollitos dicen p o-p o, eternamente

A boy died. He knew he was dying. He tried to get help. We don't know if it occurred to him to switch off the modem and make a phone call, or if he was too weak to get up and do it. We know he sent an email. He didn't type perfect English at the best of times, and as his life slipped away from him, he misspelled many things. He misspelled ambulance . He may have misspelled diabetes . That was all fine the meaning was clear enough but the bit where it gets tragic is that he misspelled .net in the To: line. So instead of arriving at its destination, the NOC of his employer, where it would have opened up a ticket and been seen by a human at some point, the email bounced. We will never know whether they could have or would have done anything in time. We will never know if, had whoever been on postmaster duty at his ISP at the time been paying attention, he could have been saved. These things were debated angrily, by people struggling to make sense of something, but it changes nothing. The email bounced, and he died.

Russ Allbery: On (not) drinking

Captain Awkward, which is still the best advice column on the Internet, just posted an entry about someone being pestered to drink after saying that they don't drink. As another one of those people who just don't drink, but not for any specific reason that people seem to accept, I felt like blathering a bit more about that. This is mostly about me rather than about the thread over there, so I figured I'd do it on my own journal. First, I completely agree with the response that it's no one else's business why you do or don't drink, and people who persist in trying to get you to drink (or do anything else, no matter how innocuous) after you have clearly told them no are being rude and have forfeited the right to further conversation. But it also really frustrates me to see that people have to cope with that situation, particularly since I suspect it's gendered. My personal experience (as a man, and one who has a fairly firm way of expressing myself naturally) is that I say I don't drink and that's the end of it. Occasionally someone will ask me why. I've never had anyone pester me beyond that. I think the age of the letter writer (22) has something to do with this, but I suspect gender sadly also has something to do with this. People seem to be much more willing to tell women what to do and not take no for an answer. It's unbelievably rude when people do that. Don't do that. If you decide you can pester someone about their personal choices because of their gender (and, for that matter, their age, or any other reason), you deserve to get your head handed to you on a plate. Second, I wonder if some of the reason why I don't run into problems with this is that I work on a college campus. The latter means that there's a lot of surrounding culture around drinking and dealing with drinking, such as the university policy that any party have EANABs (Equally Attractive Non-Alcoholic Beverages) available as well. There's a bit of a cultural understanding that pushing people into drinking isn't okay. Third, since people do occasionally ask why I don't drink, or assume that anyone who doesn't drink is doing so for religious reasons or because they're an alcoholic, or might object to them drinking, here are a few reasons why I don't drink. It may be useful information in case you run into more people in the world like me. So, that's me. It makes no difference at all to me if other people drink. Enjoy! You won't offend me, there isn't any overtone to it, I'm not being judgemental when I say I don't drink, and it's not a dangerous topic or anything. There are probably others like me. If you run into us, all you have to say after "no thanks, I don't drink" is "oh, okay."

Russ Allbery: rra-c-util 4.8

This package is my collection of random utility functions, sort of like my version of Gnulib. (At some point, I do want to retire the bits that just duplicate Gnulib, which is less and less of it, and figure out how to properly use Gnulib for my packages as well.) The big changes in this package put the name somewhat to lie: I finally took the time to write some comprehensive infrastructure for integrating Perl tests. This is primarily in the form of three new modules and a bunch of tests that use them. The modules are Test::RRA, which provides some general facilities for handling maintainer-only tests and skipping tests when prerequisites are missing; Test::RRA::Config, which reads configuration from a separate file and allows me to use the same code verbatim in multiple packges; and Test::RRA::Automake, which provides a bunch of useful functions for intergrating tests written in Perl into packages that use Automake. Some of the test scripts were in the previous version, but they've now been overhauled to use the new modules, which makes them much simpler and more robust. But I also added a new perl/t directory, which holds all the test scripts that I use for Perl module testing, either standalone or embedded in a larger package. There are a variety of other changes, but they're minor or internal. It is worth noting, though, that all the code in rra-c-util now passes clang --analyze with clang 3.0. You can get the latest version from the rra-c-util distribution page.

15 March 2013

MJ Ray: Debian Project Leader 2013 election campaign links: part 1

This is basically a link-post to the Debian Project Leader election email discussions on GMANE s blog-style interface to debian-vote. After only 3 days of the 21, there s already a pageful, so if I don t start collecting links now, I ll probably miss some. Right or wrong, I ve grouped these into three topics: The Job
  1. Why do you think you are a good candidate for DPL (10 Mar 2013)
  2. How do you plan to represent Debian externally? (10 Mar 2013)
  3. about a DPL board (12 Mar 2013)
  4. DPL term duration (12 Mar 2013)
  5. Work balance and traveling (12 Mar 2013)
  6. trying to do awesome and risking to fail (11 Mar 2013)
  7. To Lucas: how do you plan to push your ideas (12 Mar 2013)
  8. All candidates quotes for the press if you win (13 Mar 2013)
Money
  1. using debian funds for Debian s hardware infrastru (12 Mar 2013)
  2. Usage of Debian s Money (12 Mar 2013)
  3. Debian s relationship with money and the economy (12 Mar 2013)
Project Management
  1. getting new people to Debian (10 Mar 2013)
  2. Free Software challenges and Debian role (11 Mar 2013)
  3. Development and technical issues and challenges (10 Mar 2013)
  4. Are there problematic infrastructure or processes in Debian? (12 Mar 2013)
  5. to Moray: encourage teams to take interns (11 Mar 2013)
So, what do you think are the key points or differences? Leave me a comment, or get involved in the discussions. Campaigning ends and voting begins 30/31 March.

14 March 2013

Don Armstrong: libravatar for the BTS (and boring encoding fixes)

While working on fixing a few encoding problems that I managed to introduce to the BTS almost half a year ago, I took a side bit of coding, and introduced libravatar support to the BTS. Every e-mail now has an avatar to the right which should correspond to the sender. Libravatar is a federated service, which means that if you control your domain, you can serve your own icons. It also automatically falls back to gravatar, so if you're using that service, things should "just work". Hopefully this will be primarily amusing, and people won't abuse it. More importantly, but much less fun, the double encoding problems (where mails would get double-encoded if any of the headers contained non-us-ascii text), and mojibake wontfix icon ( ) should be fixed now. If you see any additional cases of this, please report them to owner@bugs.debian.org.

Richard Hartmann: Gitify your life

sage@guug This January, I held an updated version of my "Gitify your life" talk at sage@guug, which is the Munich chapter of the German Unix User Group. Once again, it was quite successful and turnout was about three times that of normal attendance. Afterwards, I was asked if I would be willing to hold the same talk at the German Unix User Group's Spring Meeting in 2014 as the programme for 2013 has been finalized for quite some time, already. Obviously, I said I would be willing to do that and will submit the talk once registration opens. Open Source Days By the way, I am writing this post from a hotel room in Copenhagen. Tomorrow, there will be a world first... "Gitify your life" will not only be held as a talk, it will be expanded into a full three hour workshop (with the option of extending it if there's interest as the room will be free after my workshop). Having never held a workshop of this scope, I am really looking forward to this experience. Besides enabling me to get people up and running with their personal data, this will allow me to see where new users are having issues with vcsh. I keep hearing of people not getting their heads around the concept easily, but no matter how many promises of updates to my docs I get while helping them, no one really follows through with that promise once they know how to use vcsh. Maybe I will find someone willing to follow through and/or simply gather enough material for docs 2.0. Your place? As an aside, and I will probably try to put a real announcement together as well, if you know of a conference, user group or other place where a lightning talk, a full talk, or a workshop about one or all of these topics would fit, please let me know. I will gladly submit proposals to or accept invitations from most places as long as I can spread this message. Especially if the venue happens to be reasonably close to Southern Germany, covers travel cost, or if they can guarantee video recording of the talk. Joey Hess has speculated if the talk isn't really called "git naked" as I seem to keep on giving that particular talk at venues which don't have video recordings. Please help me make Joey happy... ...with a video recording, I mean.

Matthias Klumpp: Tanglu

Hi everyone! Today I make an announcement I thought I would never ever make. But things changed. Discussion about this has a long history, starting as a non-serious suggestion at DesktopSummit 2011, continued with people on IRC, but it was decided back then that it wouldn t be worth the effort. This has changed too, and a small team has formed to work on it. We hereby announce Tanglu, a new Debian-based-Linux distribution. A new logo?Why do we need another one? Let me explain the concepts of that distro: Tanglu will be based on Debian Testing and follow the Debian development closely. It will have a 6-months release-cycle and it s target audience are Linux desktop users. We will make installing and setting up the distro as easy as possible. Tanglu will be usable for both developers of upstream software and the average Linux user and Linux newbie. This is possible because in our opinion developers and users don t have different needs for a desktop system. Both kinds of users like a polished desktop which just works . We will, hwever, not apply any kind of fancy modification on upstream software, we will basically just distribute what upstream created, so users can get an almost pure GNOME and KDE experience. Tanglu is designed to be able to solve the issue that Debian is frozen for a long time and Debian Developers can t make new upstream versions available for testing easily. During a Debian freeze, DDs can upload their software to the current Tanglu development version and later start the new Debian cycle with already tested packages from Tanglu. The delta between Tanglu and Debian should be kept as minimal as possible. However, Tanglu is not meant as experimental distribution for Debian, so please upload experimental stuff to Experimental. Only packages good enough for a release should go into Tanglu. Ideally, Tanglu and Debian should be working well together in mixed environments, where you for example have Debian servers and multiple Tanglu desktops with the new software, targeted at desktop user. Since the differences between Tanglu and Debian should not be very high, administering both systems should be very easy (if you know Debian). Tanglu will be an open project, driven by community. At the beginning of each cycle, people can make suggestions for release goals they want to implement (similar to Fedora, but without FESCo). These proposals are discussed in public and are rejected if there are major technical concerns. If consensus about a certain proposal is lacking, a vote is done for it. The proposal can be accepted with absolute majority. If this does not happen, the proposal is postponed for the next release, where people can vote for it again. If nobody wants that function, it is rejected. In general, decisions made by Debian are superior and have to be followed. We don t think we know every package and every software better than the original upstream. That s why it makes much sense to rely on feedback from others and to have a community-based and peer-reviewed distribution, instead of secretly developing stuff and dumping it on the community. Tanglu will have a highly predictable set of features, defined at the beginning of a cycle, so you will know what you can expect from the next release as soon as possible and plan for it. Tanglu will make it easy to deploy applications for it. It will contain a software-center, similar to what Ubuntu has. We will also try to establish a solution for a Linux-AppCenter , a place for Linux applications, which will be open not only for Tanglu, but can be implemented in any other distribution too. Possible income will flow back into development of the platform. Now, let s answer the FQA (Future Questions Asked): Why don t you contribute to Debian directly and create yet another distribution? First of all, we contribute to Debian ;-) And for me, I can say that I will contribute to Debian even more. The point is that Debian can not cover all possible use-cases, and with Tanglu we want to make a distro which solves this. You might ask why we have to create a new distro for that, instead of creating improvements inside Debian? Creating a new distro allows us to do stuff we can never do in Debian. For example, we will include proprietary firmware in that distro, we will make installations of proprietary stuff possible easily (but don t ship with it by default) and we will have a time-based release cycle. These are already things which are a no-go for Debian, and that s fine. We don t want Debian to support these cases, as it is already a great distribution. We want to offer a distro as close to Debian as possible, but with a few modifications for use-cases which are not covered by Debian itself. Of course we will participate in DEX. If Debian Developers contribute to Tanglu, freezes will take even longer! This is an often-heard concern, it comes up on every mailinglist discussion about continuing development while freeze. I would disagree here, packaging new upstream stuff is not slowing down testing and improving of packages in Testing. Also, Tanglu is an offer for Debian developers to participate (we will sync privileges for their packages) we don t expect anyone to work on it, but as we think DDs know their packages best, we will make it possible for them to participate without extra barriers. We hope that Tanglu can add value to Debian and that Debian cycles can start with better-tested packages. You said you are a small team you cannot develop a whole distribution with it! Let s put that to the test! ;-) All people working on this are well aware of the issue that the project can not survive without much community-involvement on the long run. But we see a chance that many people are interested in it and that there is a high demand for it. At the beginning, we will just start with a small set of packages. We will also sync many packages from Ubuntu, to reduce workload. For example, it is planned to use the Ubuntu-Kernel and KDE packaging. By doing this, we keep the workload at the beginning low. We also reduce duplicate work with that. We even have some possible sponsors for the new distribution. But nothing is set in stone yet, so just wait for it to happen. :) Why not participate in Arch, OpenSUSE $other_distro? These are not Debian ;-) . I know, it sounds odd, but if you like the Debian way of doing things, you want to use a Debian-based distribution. There is nothing wrong with OpenSUSE. And Debian has issues too. But we want to be close to Debian and use it s tools and way of doing things. I hate you!!! You are doing it wrong!! The project is useless!
Well, that s fine. But there is no reason for hating us. If you dislike our idea, there are basically two options: First, you hate us but the project is successful. In that case, you have been wrong with hate, as there are definitely people who liked the project and contributed to it. Second, you hate us and we fail. In this case, there is no reason for hate, as the project will just vanish and you don t have to worry about it. So hating it would ve been just a big waste of energy. Also keep in mind that forking is a way to keep development healthy and to adapt software to new use-cases which it didn t target before. And we are not introducing incompatibilities here (like e.g. writing our own display server could). Instead, we want to stay close to Debian and reuse as much code as possible. Which desktop will you use? Everyone can add a new desktop to Tanglu, as long as the desktop-environment is present in Debian. Long term, we will have to offer Linux-newbies a default flavour, probably by setting a default download on the website. But as long as there is a community for a given desktop-environment, the desktop is considered as supported. At the beginning, we will focus on KDE, as many people have experience with it. But adding vanilla GNOME is planned too. Can you say something about the software used in Tanglu? Yes, but this is still in flow, so I can t promise final decisions here. On the server, side, we will try to use the Dak for repository management, as soon as we have enough server capacity. We will also use the standard Debian repository GUI and basically reuse most of the software there, to diverge less from Debian. The distribution itself will use a Linux Kernel from Ubuntu and systemd as the primary init system, as well as the login manager logind. It will be based on current Debian Testing with some fresh packages from Unstable and Experimental. We might also use the Ubuntu driver packages and KDE packaging. We expect to have a very rough start with the first release, but there will be enough time to polish Tanglu. Nice idea! How can I help? Well, you can help with basically anything at time from writing manuals, over designing logos and pages to administering a webserver and create packages. We are at an early stage of development at the moment, but we wanted to go public with it as soon as possible, to include the community and receive feedback so we can make that distro community-centric from the beginning. Most of the infrastructure is currently in progress too. So, if you want to get started with Tanglu, subscribe to our mailinglist tanglu-devel and write a mail to it, intruducing yourself. We can then include you in the loop. Generally, if you want to get access to our machines, a trusted GPG-signature will help a lot. If you want to talk to us, join #tanglu-devel or Freenode! Most discussions are currently happening there. And that s it! Tanglu will be awesome!

Some other projects of mine will develop a bit slower because I am now involved in Tanglu. But nothing will stop, and there is some pretty cool stuff coming for both GNOME and KDE (and I still have to implement DEP-11 for Debian). :)

Russ Allbery: Review: Higher Order Perl

Review: Higher Order Perl, by Mark Jason Dominus
Publisher: Morgan Kaufmann
Copyright: 2005
ISBN: 1-55860-701-3
Format: Trade paperback
Pages: 563
Disclaimer: The author and I both used to be (technically still are, but the newsgroup is dead) moderators of comp.lang.perl.moderated, and I knew him electronically from answering questions on the Perl Usenet newsgroups many years ago. Perl is, in general construction, a typical imperative language in the style of C, with object-oriented capabilities bolted (somewhat awkwardly) on. Most Perl code looks remarkably like C code with more powerful built-in data types and no memory management. A minority of Perl programs embrace object-oriented techniques and remind one of C++ or Java (or Python). But Perl also has powerful capabilities borrowed from functional programming languages and the Lisp tradition, even though many Perl programmers rarely use them and aren't familiar with them. Higher Order Perl focuses on those capabilities and how to use them effectively, starting with callbacks and uses of function pointers and moving into recursion and analysis of recursive functions, iterators, currying, and parsers. It concludes with a fully-worked example of constructing a declarative programming system using the techniques developed earlier in the book. Higher Order Perl is a programming book for an intermediate to advanced Perl programmer, already a rare topic. This is not a look at how to apply Perl to another area of programming, or a cookbook of techniques. It's an attempt to help a Perl programmer think about and use the language differently, and it follows through on that. It's refreshing and rare to read a programming technique book that's targeted at the practicing expert. (I think the size of the audience is often too small for publishers to target it.) Even the most experienced Perl programmer is probably going to learn something fundamental from this book, not just interesting trivia around the edges. On the negative side, though, I found the book a bit too focused on computer science and mathematics problems, particularly in the choice of examples and sample scripts. (And I say this as someone who has a master's degree in computer science with a software theory focus.) This is a bit hard to avoid for topics like recursion, where problems like computing Fibonacci numbers are classic, but throughout the book I struggled to focus past feelings of "but why would I ever do that"? The extended discussion of the Newton-Raphson method is the most memorable; I'm not sure that's a problem many Perl programmers would have and need a higher-order technique for. There's also a lot of discussion of recursion analysis and transformations between recursive and iterative expressions of problems, which is ground I remember well from my degree but which I've rarely had any practical use for in day-to-day programming. This is not a uniform problem, though, just a tendency. There are some great examples that I think are more in the mainstream of Perl problems, including a reinvention of File::Find that shows how to add more flexibility, a web spider, and a great discussion on how to construct a conventional queryable database on top of a flat file (a topic that's near and dear to my heart). And then there's the chapter on infinite streams. Dominus presents a method of using closures to create a version of an interator: a sort of infinite linked list that can keep generating additional elements. He presents this in several contexts, but one of them is log parsing, and that turned out to be exactly the solution that I needed for a problem I was working on while reading this book. I've written about this elsewhere, but this was a wonderful idea that helped me think about both Perl and a major application area in a completely new way, and I wrote an application using that knowledge that would have taken me much longer using different techniques and would have been much less fun. So, for me, this chapter was more than worth the entire book, and blankets the rest of it in a delighted feeling. Other people may or may not have that experience. I think it will depend on whether one of these techniques hits home for you the way that one did for me. This is a book with some idiosyncracies, and some sections that may drag. Having lots of fully-worked examples is a major plus, but some of those are so comprehensive that one can get a bit lost in the details. That particularly hit me with the last couple of chapters on parsing and on the example declarative programming application. Quite a bit of that text involved reinventing a recursive descent parser (another very computer science example), when I'm not quite sure why one wouldn't use one of the existing parser generators on CPAN for practical purposes, and inventing a lot of new syntax to try to make parser Perl code more readable. But one certainly can't complain that Dominus omits necessary details, and there is some appeal in watching an experienced programmer work through a problem from analysis to implementation. But, despite the idiosyncracies, I recommend this book to any experienced Perl programmer who wants to expand their view of the language. The techniques here closures, higher-order functions, iterators and streams, and formal parsers are powerful and underused in the Perl community. You may want to pick and choose which sections you pay close attention to, but I think everyone will find something of interest here. In the weeks since I read this book, my opinion of it has only grown. And I can't tell you just how much I loved the infinite stream concept. Rating: 8 out of 10

13 March 2013

Raphaël Hertzog: Kali Linux 1.0, a new Debian derivative

Today, during Blackhat Europe, Offensive Security announced the availability of Kali Linux 1.0, which aims to be the most advanced, robust, and stable penetration testing distribution to date. It is the successor of Backtrack Linux. kali Kali s choice of Debian Kali s release is a significant event in the security auditing and penetration testing field, and I m proud to see that Debian was retained as the best distribution to create this new product. Here s what Mati Aharoni of Offensive Security told me:
Debian provides a reliable base to build a new distribution and yet can easily be customized to add bleeding edge features, thanks to the unstable and experimental distributions.
Kali s development policies Even though Kali was prepared in secret, from now on Kali s development happens in the open in public git repositories. There are repositories for all the packages that have been created (or forked) as well as for the ISO images creation script. Debian packages are maintained with git-buildpackage, pristine-tar and the associated helper tools, making it easy to integrate the latest changes of Debian. Kali packaged several hundreds tools that relate to their field and they intend to contribute those which are DFSG-free back to Debian. Kali s technical infrastructure In the last year, I have been working within the Kali team to setup large parts of their infrastructure as a proper Debian derivative. Kali s main ISO images are built with live-build. All the bugfixes that I contributed to Debian Live were the direct result of my work for Kali. The git repositories are managed with gitolite. The package repositories are built with reprepro. The build daemons use rebuildd and sbuild. The (push) mirrors are synchronized with the same tools than Debian (based on rsync), but there s also a central server which redirects to a mirror close to you (and which is used by default everywhere). This one runs mirrorbrain (and not Rapha l Geissert s redirector). The ARM build daemons (armel/armhf) run on machines powered by Calxeda s Highbank (4 cores, 4 GB RAM) that work pretty well. Even better, Offensive Security is willing to dedicate one node of this cluster for Debian s own usage. The future This first release is not an end. It s only the start of a journey. Not all applications have been packaged yet and there s lot of work left to integrate everything in Debian. I m really looking forward to continue my collaboration with the Kali team as this has been one of the most interesting project I ever had as a Debian consultant. And also one of the few where I could really contribute something back to Debian.

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

Ian Campbell: Linaro Connect Asia 2013

I've just got back from Linaro Connect Asia 2013 in Hong Kong. This was my first time back in Hong Kong since 1995 when I left after living there for 10 years. It was really interesting to see how much the place had changed, as well as how much it hadn't! I started the week by giving a talk together with Stefano Stabellini Introducing Xen on ARM to a full house. The slides can be found on the event page or google docs. There is a video on youtube but due to the cameras being setup for a fish-bowl style panel it is unfortunately mostly of my backside. The reception was excellent and the talk seeded a large number of hallway track conversations with all the many folks who are interested in Xen on the ARM platform. The day after our talk Lars Kurth (Xen.org community manager) and Mark Heath (VP of XenServer Engineering, and my boss) gave a keynote (video) announced Citrix's intention to join the Linaro Enterprise Group (AKA "LEG") on the 1st of April. This is pretty exciting for me since it means I'll get to work much more closely with the Linaro and ARM communities and spend even more of my time hacking on Xen on ARM! At some point Stefano and myself were also video interviewed by Charbax of http://armdevices.net/ but it doesn't appear to have gone online yet. Lars and Mark also gave interviews which are online already. One nice thing about Connect is that the afternoons are left free of talks so I managed to find time in the hackrooms to implement SMP host support and 64-bit domain 0 support for Xen on ARM as well as getting multiarch cross building working for upstream Xen with Wookey's kind assistance (no patches for this yet since I still need to clean them up). It was also useful to catch up with the ARM kernel developers and KVM guys to see what they are up to and share ideas etc. Finally right at the end Stefano and myself showed Xen on ARM at Demo Friday. We had Xen running on the Arndale Board, ARM Chromebook and 64-bit ARMv8 using the emulators (no hardware being available yet). All in all I had an excellent (if tiring) week, there was loads of interest in Xen on ARM and in Citrix joining LEG and everyone was very welcoming. I'm really looking forward to the next Connect in Dublin. Outside of Connect I managed to find time to visit Sham Shui Po at look at all the gadgets but managed to resist buying anything (Stefano got a Thinkpad X230, which was enough retail therapy for both of us!). I caught up with my sister (who lives there again), her boyfriend and my parents (who happened to be visiting her that week). I also managed have some drinks with some old school friends, most of whom I've not seen for nearly twenty years, but it was just like old times ;-). I'm off again to Hong Kong next week with my family to visit my sister (yes, there was some bad planning involved here...). This time I plan to do all the toursity type stuff that I never did while I lived there. I've also got tickets for the Hong Kong Rubgy Sevens and hopefully I'll manage catch up with some more old friends. I probably won't be able to resist buying gadgets this time around though.

Russ Allbery: WebAuth 4.4.3

WebAuth is the site-wide web authentication system that we use at Stanford. After a lot of time focusing on things at work other than coding, it's been my primary job for the past nine months or so, which has been a lovely change. I wasn't planning on doing another 4.4 release and instead focusing on 4.5.0 (which is well underway and adds significant new features to multifactor support), but I kept finding bugs, including several that were quite embarassing. So this is another bug-fix release, and hopefully the last one before 4.5.0. WebAuthTrustAuthzIdentity enabled WebAuthDoLogout in the same scope (ever since it was added in 4.4.0). It's horribly embarassing to have been writing C for more than 20 years and still manage to omit a break in a switch statement. Benjamin Coddington found another bug in authorization identity handling where if the user changed their authorization identity to match their authentication identity, their authentication would be rejected. We now detect that case and just discard the authorization identity if it's the same as the authentication identity. There are multiple fixes in the mod_webauth logging of bad app tokens: expired app tokens are now logged with a proper message (and at info level rather than error), empty app tokens (created internally and therefore seen by subqueries before fixup to delete expired app tokens) are now just ignored, and invalid app tokens don't result in spewing binary strings into the Apache error log. mod_webauthldap has, since the beginning, refused to add more than 127 values of a multivalued LDAP attribute to the environment. We ran into that limit with entitlements, so it's now been removed. This runs the risk of overflowing the environnment, but I did some calculations, and it looks like you're going to have to try really hard and have impressively large multivalued attributes to create that problem. If it actually becomes a problem for someone, I'll add a configuration option. There's also a syntax fix to the default WebLogin error template and a variety of minor bug fixes, mostly around error handling conditions, to correct problems caught by clang --analyze. (The current master branch gets a completely clean bill of health from clang --analyze using clang 3.0.) You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

Dirk Eddelbuettel: Rcpp master class in New York last weekend

On Saturday I had the opportunity to teach another one-day master class on Rcpp. The class had been organized by Jared Lander, and organized very well I might add. The weekend started with a slight disappointment. I had taken Friday off, and hoped to reach NY by early afternoon to join JJ there, and to spend the afternoon with the RStan team. However, the tail end of last week's snowstorm made it such that we both got to Columbia's stats department closer to 6pm rather than 1pm, and half the team had left. Dang. Very frustrating travel experience. We salvaged the evening by gabbing over a cold beverage or two, before sharing some sacred New York pizza with Wes McKinney and Jared. The class itself on Saturday went quite well. With JJ on deck, we were able to have every participant log into an EC2-hosted instance of RStudio Server, which worked very well for usage examples of Rcpp. It has been almost a year since I last taught the class, and many exciting things--such as Rcpp attributes, added by JJ himself--have appeared, which made it extra fun. Participants were rather kind with praise. Either they really liked it, or they really are hard-nosed New Yorkers who manage to lie to my face without me noticing. We ended the day with some hard-earned cold beverages, followed by some dinner at Sylvia's (as tweeted by Jared) followed by more drinks. Ended up a little past my usual bedtime, but I managed to get out and enjoy a lovely 6.5 miles run across Central Park the next morning before leaving town. All in all, a very nice weekend, the travel horror of Friday notwithstanding. And who know, maybe we'll just do it again another time...

12 March 2013

Eddy Petrișor: Herbalife, a detailed analysis

You might remember that a while ago I mentioned I got involved in skepticism to the point I even co-host a podcast, Skeptics in Romania (in Romanian).

Among the subjects we tackle there are claims about various miracle fruits, shady dietary advice, various nonscientific health products, and even scams. We try to inform or listeners about ways to identify themselves such dangerous/fake products and how they can inform themselves about the claims they might encounter, what questions they should ask before considering buying (into) such things.

One sensitive subject is the so called multilevel marketing, especially for people involved in such businesses.

This is a sensitive subject because many of these schemes are actually pyramidal schemes, also known as Ponzi schemes. These are illegal in many countries, since they are, in fact scams designed to lure people with supposed high profits and little work.

One such pyramidal system... well you can judge yourselves (note that the presentation contains many slides, but it's really captivating):

http://www.businessinsider.com/bill-ackmans-herbalife-presentation-2012-12?op=1j

Richard Hartmann: Gitify your life

These Open Source Days were kind of a mixed experience. The social part Things started off quite nicely; the speaker dinner was very pleasant and the people at my table interesting to talk with. The way back to the hotel and breakfast on Saturday were even more interesting; talking with Amelia Andersdotter, a member of the European Parliament for the Swedish Pirate Party, about anti-trust measures, privacy protection, lobbyists, and creating the right incentives for companies to actually protect user data was fun and engaging. My own claim to fame is that I told her that while Microsoft is willing to sign UEFI payloads for x86, they refuse to do so for ARM which she didn't know. From my understanding, their interpretation is that any anti-trust rulings apply to PCs only, and not general computing devices like tablets. It will be interesting to see how that plays out in the long run, especially once ARM processors start appearing in laptops and desktops as main CPUs where Microsoft clearly still has a near monopoly. It was fascinating to discuss all those issues with someone who's actively involved with legislation, mainly because her style of talking was markedly different from what I am used to. One point which she stressed repeatedly is that the most important skill within the context of political work in the EU is to be able to track down, read, and then reference all the content that's being produced in Brussels and Strasbourg. Maybe that tidbit is useful to people who want to try themselves at political activism. She nicely, and maybe unknowingly, emphasized that point by always referring to specific papers, directives, and studies after making any point. Statement of opinion, reference to supporting document. Statement of opinion, reference to supporting document. Statement of opinion, reference to supporting document. Rinse, repeat. It's no secret that I'm continuously disappointed by the political process in general and politicians in particular. Yet, I have to say that this encounter had a lasting and positive impression on me. Amelia has an incredible amount of energy and genuinely cares about the issues which too many other politicians ignore completely. It's good to know someone like this is on our side. If you're Swedish, please inform yourself about her and consider voting in her favour. Other than that, I met several other people, new and old. This year's OSD felt a lot more relaxed and there were more informal and spontaneous conversations going on in hallways and at tables. Even though I failed to have any intense discussion of Mercurial vs git this year, all those conversation were still really interesting. The "workshop" I already knew that the room assignment for my workshop on Saturday afternoon would be a last-minute thing. What I didn't expect was that the final confirmation by Copenhagen Business School would be given on Friday evening. Mixed with a very cumbersome process to update the slides of the CBS-owned and -operated information beamer in the lobby, this resulted in the official schedule showing my room as "Workshop" instead of "SP 214". The official schedule repeatedly stated that people had to pre-register for the workshop which was a left-over from last year where they actually had to plan the amount of hardware kits needed; the registration itself was was very well hidden behind a rather generic link you saw exactly once after purchasing your ticket. Add to this that my room was literally in the farthest corner of the building and on the top floor and things start to turn sour real quick. All other rooms were either close to the main entrance or on the ground floor. Helpers at the front desk had a lot of people asking where my room was and gave out directions, yet... ...the grand total of six people who arrived were all telling me how they couldn't find the room and almost gave up on finding it. As more people asked for directions than turned up at the workshop, this means that even with directions, the room was really hard to find. Myself, it took me two attempts to find the room after which I was led there by one of the helpers who wasn't completely sure we were going in the right direction, himself. Still, I managed to get everyone who had a laptop and access to a UNIX-based system set up with working mr and vcsh repositories they can work from as well as a demo git-annex repository to play with. Sadly, not everyone had a laptop, or access to UNIX, or the tools installed, or even an idea where to install them from, even though I had noted these "requirements" in the description. Next time I do this workshop, I will need to make sure to include information on what distributions have the relevant packages and how to find and install the software on Max OS X in the workshop description. Feedback from the very few people who actually managed to find me was very good and one of the attendants asked if I would be willing to hold the workshop again at another conference in Denmark. I am still awaiting details on this, but I would obviously enjoy having the chance to reach more people. At least I fared better than the guys who did the workshop on "Binary exploitation 101" in yet another room. Two guys held a workshop with a total attendance of... one... I know the organizers of OSD were really unhappy with how this turned out and I believe them when they say that something like this will never happen again. It's the second year that this team is running the conference, running conferences is an incredible amount of work, and things were smoother this year than last year. Iterate and improve, etc. The talk Saturday evening, Alex offered me the chance to hold a reparation talk on Sunday morning to compensate for the botched workshop. Said talk was scheduled for the first slot and not really announced (but the schedule on both www and the beamer was changed over night). Additionally, this was merely an updated and extended version of the talk which I already held at OSD 2012 so at least part of the visitors knew most of what I had to say, already. To be honest I didn't expect too much, but more than twenty people turned up which is a very decent turnout, all things considered. Same as with the workshop, feedback was extremely positive and I was told afterwards by Bryan that several people mentioned my talk as one of the highlights, or even the highlight, of OSD when he was talking to them. To make things even better this talk has, finally, been videotaped; I will update this blog with a link as soon as the video is online.

11 March 2013

Luca Falavigna: On participation

While reading the platforms for the upcoming DPL election, I read some statements about hearing from Project members about their experience within the Debian Project, so I took the chance to write some thoughts about my experience in one of our core teams, in which I have the privilege to be part of: the FTP Team. During NM process, my Application Manager asked me about some activities I could have involved into once I became a Debian Developer. I was fascinated by the hard work of the FTP folks when processing NEW packages (and I guess everybody reading these lines agree with me, remembering the happines of reading that wonderful ACCEPTED mail for their very first contribution to Debian, I still have it in my mailbox), so I decided I wanted to help out those folks to share a portion of their hard work. I committed errors, sometimes they were so silly I d be better to hide, but the team helped me to solve the mess I created. The thank you and kudos messages the FTP Team receives greatly overtake the frustration for my mistakes, and give the strength to keep up the good work :) FTP Team is just one of the dozens teams which do an awesome work for the Debian sake, every day. Don t be shy, or worried of being unsuitable or not skilled enough for the role. You ll never know until you try. And it could happen you really like the job, and you could feel sorry for have waited so long ;)

Russ Allbery: Small non-fiction haul

Long time no write. A variety of things, including getting sick with a particularly bad cold (I'm still coughing up phlegm), led to my schedule and general life organization getting turned on its head, and I'm only slowly recovering. Work gets top priority (including a security release of OpenAFS), so I'm afraid non-work things such as reviews and journal posts (and Debian, and non-work-related software development, and conversations with friends...) have been getting second shrift. Hopefully this is finally starting to improve, and I have a block of time for working remotely coming up that should help. In the meantime, more books have, of course, been acquired. This particular order was mostly to get one book (The Making of the Indebted Man), which I'm going to read and discuss as part of a surprisingly fun political discussion about basic income guarantee and, somewhat by extension, Marxist analysis of capitalism. But it's impossible to buy just one book, similar to how it's impossible to eat just one potato chip: Neil Barofsky Bailout (non-fiction)
E. Gabriella Coleman Coding Freedom (non-fiction)
Joshua Foer Moonwalking with Einstein (non-fiction)
Maurizio Lazzarato The Making of the Indebted Man (non-fiction)
Isabel Wilkerson The Warmth of Other Suns (non-fiction) I of course preordered Coding Freedom and am quite looking forward to reading it, although it will surprise no one to hear that I have rather a long queue. The Warmth of Other Suns I picked up based on a recommendation by Ta-Nehisi Coates, whose writing for The Atlantic I wholeheartedly recommend. I have such a large pile of books that I've read but not yet reviewed that I cringe to think about it. But no progress will be made on that this evening (damn you, Benjamin Franklin! *shakes fist*). More tomorrow if I survive five and a half hours of scheduled forced social interaction.

10 March 2013

Gergely Nagy: DPL platform

Last year, I invited you all to walk the plank with me, to follow me on a road, a road that even I was unsure where it led. I had a vision, I had ideas, but I had little to show for a plan. Even worse, some of my ideas, some of the things I've thought I knew, turned out to be wrong this past year. While my original plan was to pursue the goals I set out in my previous platform, I did none of that, and before I get to the meat of the platform, I owe you an explanation why: After walking the plank last year, I spent some time swimming to the shore, determined that no matter what, I will get things done. But how shall I do that? And when, with whom? Those questions needed an answer, therefore I took on a coat of an ordinary hacker, and started a journey to find the answers.That is how the past year's been spent: looking and learning. I was - and still am - following every major Debian list, I'm on IRC, absorbing all the information that fits into my tiny mind. I see now, that there's a lot more to be done than I thought last year, that some of the assumptions I made then, were wrong. And having spent a long time learning, it is my hope, that I did learn, and that this time, the plans I came up with will serve the same goal I had last year, better.That goal is as simple as growing Debian from a community of mostly technical folk to something much bigger, a community of enthusiastic, bright-eyed people who all want to do their part of making the world a better place. Big words, big task.The problemOne of the most fundamental problems with the project is that it is old, and hasn't grown up yet. We're still very focused on technical merit - don't get me wrong, that is important too, but there's much more we can do than that! We have tremendous amounts of talent, but pretty much every team is suffering from lack of people, and we seem to be slow and ineffective in recruiting new contributors (either from within the project, or outside of it), and even worse at keeping them motivated. This is not new, I worried about it last year, and I'm not the only one to see things this way, respectable members of the project expressed their pessimism publicly too.This is our biggest issue. We can be excellent at the technical level, but not being able to keep people motivated, failing to find new contributors is hurting us more and more, and it is my firm belief that without quick improvement in these areas, it won't be just me virtually walking the plank.On the flip side, we have every tool in our possession to steer ourselves into a better, brighter direction. We have excellent hackers, we have people who are terrific at communication, we have people who inspire others (just see the pattern on the dpl-game!), we have everything we need. Read on then, dear reader, and see my plan!Dancing on a tightropeTo tread on a path we have not taken so consciously before, we need to have a vision to strive for. A vision for the project as a whole, and a vision for ourselves, to see where we'd like to be a few years from now.As Stefano put it so well in his platform last year, Debian is a very unique member of the larger Free Software ecosystem - go and read his description, it can hardly be written better. This is the same vision I share, where Debian grows up to be much more than hundreds of talented people putting together a distribution. I want to see Debian becoming more than that, something that attracts not only the technical geniuses, but those who wield the power of speech and inspiration too, for these traits rarely go together.I envision a project, where people recognise each other's strengths, and make use of these strengths; where we can - and will - turn to each other, and work closely together, to achieve such good balance of skills of all kinds, as we already achieved in creating and maintaining the distribution itself.Let's dance!But alas, a vision is useless without a plan. That is a mistake I made last year, one that I will not repeat again. The approaches I choose may seem strange, or weird at first, but rest assured, they were carefully considered, and most of them tried out in a smaller setting. CommunicationWhat I've seen and experienced over the past year (and thinking back, far more than that - I just didn't know where to put the experience at that time) is that written communication is rarely the best medium to reach out to people. In this age we live in, written text reaches those who were already curious, it rarely reaches those who're still waiting for enlightenment. And even if it does, more often than not, there is no direct channel between the writer and the reader, which hurts not only the latency of the communication, but the quality too. Not to mention, that - however sad it may sound - the recipient is often too shy to engage.What does help, is face to face time. Events, where we can reach out to people, and receive immediate feedback, where we can notice the shy ones, and help them. Where we can immediately adapt to expectations.For this reason, I feel it necessary to encourage and help local teams in every possible way, to organise hackfests, code retreats, and all kinds of events that they feel will attract the bright-eyed youth (be them 20 or 80, it's the spirit that counts) we so direly need. These events need not be technical at all: a session about Debian publicity, about representing the project in press or on conferences is just as useful (if not more). Along with hackfests, we could - and should - have events focused on improving communication, for that is just as important.With strong focus placed on non-technical matters, I believe we can step on a path of rapid progress: my experience shows that techies and non-techies can inspire one another very well, much more than two techies would. With a focus on areas we are lacking in, we are indirectly improving those we are already good at. Inspiration & motivationBut finding new contributors, be them technically-sawwy or not is only part of the task, and the easier one too. It is much harder to keep people interested and motivated over a long period of time, than to find them once.On one hand, I would like to rely on those members of our community, who we all hold in high esteem (including, but not limited to those mentioned during the dpl-game). They know what keeps them going, they know what drives them away, we need to learn from that. I'd like to hear them speak more often, on conferences, if possible, as they are, I believe, a much more credible source than any elected official, at least in some situations.I'd also like to hear everyone's voice, from old members to the newest ones, I'd like to read - and if so need be, conduct - interviews with people who recently became Debian Developers, to hear about their experience, to learn what they think is good or bad, because a fresh view is just as important as a decade long experience.On the other hand, we need to act on the issues discovered too. We already know that quite a lot of trouble stems from lack of time, overburden and eventually burn out. We know the solution to this: recruit more people, and utilise the resources we do have better. Part of that can be solved by expanding our numbers, but for the other part, we may need deeper changes. What those may be, I cannot tell yet, there simply wasn't enough time to dig deeper, and I'm likely not the best person to undertake the task, either. I am, however, confident that we'll discover the solution as we travel along.The first step is gaining knowledge, without this, no further plans can be made. RecruitmentI already touched the recruitment part earlier, at least the how of the approach. What I'd like to expand on is the why, in particular: why encourage recruiting non-packaging contributors, when we are building a distribution, and we're lacking packaging manpower too?Let me answer those questions separately.First of all, I still like to think - but perhaps I am wrong - that we have an unbelievable amount of packaging manpower, which we fail to use to its full extent. We can use more, we always will be able to. But it also helps if we manage to put our existing resources to better use.And that is where non-packaging contributions come in. If we improve our skills in areas we're lacking in, that in turn, will improve the general quality of the project, which in turns improves morale, and a vibrant, well functioning, welcoming community attracts even more people, and keeps us motivated in the long run too.Mouse on the tightropeWith all that out, you may be wondering who I may be, and why you have not seen my name over the mailing lists in recent years. I'm not a terribly vocal person anymore, not a hot-headed teen I used to be some ten years ago. Most who know me, know me by my online nick name, algernon, and in most cases, I prefer that in real life too, for silly reasons I'd rather not dive into (but the primary one being that people have a hard time correctly pronouncing my name, and I have a hard time recognising my name unless pronounced the way I learnt it). Nevertheless, my name is Gergely Nagy, and I'm a recovering hacker, who intends to become a bachelor of (hungarian) arts, by majoring in Hungarian grammar & literature sometime in the next three to five years.Over the course of the past year, I also strived to observe and learn from exceptional leaders at my day job, because there, I have the advantage of meeting with them face to face, to interact with them on a daily basis. Fortunately for me, there are people among them from whom I learned a great deal about not only motivation, but about behind-the-scenes politics too - both a valuable lesson.And while I still have a tremendous amount of things to learn, I like to believe that I can do that. I know I can learn technical things extremely quickly (my day job depends on that, I would be out of a job if I failed at that), I'm positive that I can do the same in other areas as well, at least as long as it doesn't involve extreme amounts of economics. That proved to be a major barrier in the past.But back to the more important point: my organising, presentation and leading skills. I'm a co-organiser of the Budapest Clojure User Group meetups, I started to encourage GSoC participation at my day job last year (we participated thanks to OpenSUSE who gave us a slot), and I'm driving it this year, aiming to become a mentoring organisation of our own. I'm doing regular talks and presentations, participate in code retreats, meetups and other similar events where I can both practice and learn the art of interacting with people, and the fine art of organising events.

Gergely Nagy: DPL platform

Last year, I invited you all to walk the plank with me, to follow me on a road, a road that even I was unsure where it led. I had a vision, I had ideas, but I had little to show for a plan. Even worse, some of my ideas, some of the things I've thought I knew, turned out to be wrong this past year. While my original plan was to pursue the goals I set out in my previous platform, I did none of that, and before I get to the meat of the platform, I owe you an explanation why: After walking the plank last year, I spent some time swimming to the shore, determined that no matter what, I will get things done. But how shall I do that? And when, with whom? Those questions needed an answer, therefore I took on a coat of an ordinary hacker, and started a journey to find the answers.That is how the past year's been spent: looking and learning. I was - and still am - following every major Debian list, I'm on IRC, absorbing all the information that fits into my tiny mind. I see now, that there's a lot more to be done than I thought last year, that some of the assumptions I made then, were wrong. And having spent a long time learning, it is my hope, that I did learn, and that this time, the plans I came up with will serve the same goal I had last year, better.That goal is as simple as growing Debian from a community of mostly technical folk to something much bigger, a community of enthusiastic, bright-eyed people who all want to do their part of making the world a better place. Big words, big task.The problemOne of the most fundamental problems with the project is that it is old, and hasn't grown up yet. We're still very focused on technical merit - don't get me wrong, that is important too, but there's much more we can do than that! We have tremendous amounts of talent, but pretty much every team is suffering from lack of people, and we seem to be slow and ineffective in recruiting new contributors (either from within the project, or outside of it), and even worse at keeping them motivated. This is not new, I worried about it last year, and I'm not the only one to see things this way, respectable members of the project expressed their pessimism publicly too.This is our biggest issue. We can be excellent at the technical level, but not being able to keep people motivated, failing to find new contributors is hurting us more and more, and it is my firm belief that without quick improvement in these areas, it won't be just me virtually walking the plank.On the flip side, we have every tool in our possession to steer ourselves into a better, brighter direction. We have excellent hackers, we have people who are terrific at communication, we have people who inspire others (just see the pattern on the dpl-game!), we have everything we need. Read on then, dear reader, and see my plan!Dancing on a tightropeTo tread on a path we have not taken so consciously before, we need to have a vision to strive for. A vision for the project as a whole, and a vision for ourselves, to see where we'd like to be a few years from now.As Stefano put it so well in his platform last year, Debian is a very unique member of the larger Free Software ecosystem - go and read his description, it can hardly be written better. This is the same vision I share, where Debian grows up to be much more than hundreds of talented people putting together a distribution. I want to see Debian becoming more than that, something that attracts not only the technical geniuses, but those who wield the power of speech and inspiration too, for these traits rarely go together.I envision a project, where people recognise each other's strengths, and make use of these strengths; where we can - and will - turn to each other, and work closely together, to achieve such good balance of skills of all kinds, as we already achieved in creating and maintaining the distribution itself.Let's dance!But alas, a vision is useless without a plan. That is a mistake I made last year, one that I will not repeat again. The approaches I choose may seem strange, or weird at first, but rest assured, they were carefully considered, and most of them tried out in a smaller setting. CommunicationWhat I've seen and experienced over the past year (and thinking back, far more than that - I just didn't know where to put the experience at that time) is that written communication is rarely the best medium to reach out to people. In this age we live in, written text reaches those who were already curious, it rarely reaches those who're still waiting for enlightenment. And even if it does, more often than not, there is no direct channel between the writer and the reader, which hurts not only the latency of the communication, but the quality too. Not to mention, that - however sad it may sound - the recipient is often too shy to engage.What does help, is face to face time. Events, where we can reach out to people, and receive immediate feedback, where we can notice the shy ones, and help them. Where we can immediately adapt to expectations.For this reason, I feel it necessary to encourage and help local teams in every possible way, to organise hackfests, code retreats, and all kinds of events that they feel will attract the bright-eyed youth (be them 20 or 80, it's the spirit that counts) we so direly need. These events need not be technical at all: a session about Debian publicity, about representing the project in press or on conferences is just as useful (if not more). Along with hackfests, we could - and should - have events focused on improving communication, for that is just as important.With strong focus placed on non-technical matters, I believe we can step on a path of rapid progress: my experience shows that techies and non-techies can inspire one another very well, much more than two techies would. With a focus on areas we are lacking in, we are indirectly improving those we are already good at. Inspiration & motivationBut finding new contributors, be them technically-sawwy or not is only part of the task, and the easier one too. It is much harder to keep people interested and motivated over a long period of time, than to find them once.On one hand, I would like to rely on those members of our community, who we all hold in high esteem (including, but not limited to those mentioned during the dpl-game). They know what keeps them going, they know what drives them away, we need to learn from that. I'd like to hear them speak more often, on conferences, if possible, as they are, I believe, a much more credible source than any elected official, at least in some situations.I'd also like to hear everyone's voice, from old members to the newest ones, I'd like to read - and if so need be, conduct - interviews with people who recently became Debian Developers, to hear about their experience, to learn what they think is good or bad, because a fresh view is just as important as a decade long experience.On the other hand, we need to act on the issues discovered too. We already know that quite a lot of trouble stems from lack of time, overburden and eventually burn out. We know the solution to this: recruit more people, and utilise the resources we do have better. Part of that can be solved by expanding our numbers, but for the other part, we may need deeper changes. What those may be, I cannot tell yet, there simply wasn't enough time to dig deeper, and I'm likely not the best person to undertake the task, either. I am, however, confident that we'll discover the solution as we travel along.The first step is gaining knowledge, without this, no further plans can be made. RecruitmentI already touched the recruitment part earlier, at least the how of the approach. What I'd like to expand on is the why, in particular: why encourage recruiting non-packaging contributors, when we are building a distribution, and we're lacking packaging manpower too?Let me answer those questions separately.First of all, I still like to think - but perhaps I am wrong - that we have an unbelievable amount of packaging manpower, which we fail to use to its full extent. We can use more, we always will be able to. But it also helps if we manage to put our existing resources to better use.And that is where non-packaging contributions come in. If we improve our skills in areas we're lacking in, that in turn, will improve the general quality of the project, which in turns improves morale, and a vibrant, well functioning, welcoming community attracts even more people, and keeps us motivated in the long run too.Mouse on the tightropeWith all that out, you may be wondering who I may be, and why you have not seen my name over the mailing lists in recent years. I'm not a terribly vocal person anymore, not a hot-headed teen I used to be some ten years ago. Most who know me, know me by my online nick name, algernon, and in most cases, I prefer that in real life too, for silly reasons I'd rather not dive into (but the primary one being that people have a hard time correctly pronouncing my name, and I have a hard time recognising my name unless pronounced the way I learnt it). Nevertheless, my name is Gergely Nagy, and I'm a recovering hacker, who intends to become a bachelor of (hungarian) arts, by majoring in Hungarian grammar & literature sometime in the next three to five years.Over the course of the past year, I also strived to observe and learn from exceptional leaders at my day job, because there, I have the advantage of meeting with them face to face, to interact with them on a daily basis. Fortunately for me, there are people among them from whom I learned a great deal about not only motivation, but about behind-the-scenes politics too - both a valuable lesson.And while I still have a tremendous amount of things to learn, I like to believe that I can do that. I know I can learn technical things extremely quickly (my day job depends on that, I would be out of a job if I failed at that), I'm positive that I can do the same in other areas as well, at least as long as it doesn't involve extreme amounts of economics. That proved to be a major barrier in the past.But back to the more important point: my organising, presentation and leading skills. I'm a co-organiser of the Budapest Clojure User Group meetups, I started to encourage GSoC participation at my day job last year (we participated thanks to OpenSUSE who gave us a slot), and I'm driving it this year, aiming to become a mentoring organisation of our own. I'm doing regular talks and presentations, participate in code retreats, meetups and other similar events where I can both practice and learn the art of interacting with people, and the fine art of organising events.

Next.

Previous.