Left to right: Me, Stefano Zacchiroli (Debian Project Leader), Moray Allan and Holger Levsen.
Photo by Robert "Blars" Larson.
Cineast and Free Culture activist Nina Paley wrote some days ago a rantifesto on why the FSF has a double standard: Why are the Freedoms guaranteed for Free Software not guaranteed for Free Culture?, by not following its own very strict rules on software when it comes to culture as a whole. Her post was widely circulated, and got (at least) one reply by fellow Debian Developer Wouter Verhelst, largely agreeing with her, and an anti-rantifesto by Joe Brockmeier — Which was promptly answered again by Wouter with a very fun and inspired post, written from the right angle: From the viewpoint of a person who is both a programmer and a musician, and understands the concepts at hand.
I'd love to write a longer, better thought post — But I'm tired and frankly stressed by many things, so I am just echoing their very interesting discussion to other people who might want to read it.
I have been thinking and writing bits on that subject over the last couple of months. An example of that was the talk I gave at the Senate ~6 weeks ago. Following that talk, I wrote a short article for Revista Zócalo (a widely circulated magazine mainly dealing with Mexican politics and social issues) called simply Software libre, cultura libre (full text available, but in Spanish only — You can try reading an automated translation if it suits you). I wrote the article, mind you, with very limited time, and I'll be the first to recognize the prose was quite poor this time :(
Anyway — My point is that our nature is to share culture, to build it in a collaborative fashion, and having the Internet as a practically zero-cost, zero loss medium with which we can interchange our creativity with other like-minded people will naturally boost creativity. Free Software emerged before other Free Culture groups just because programmers had privileged access to Internet in the 80s and early 90s; as network access –and digital creation tools– have got to more people, it's just natural for all kinds of free culture to grow.
Software is just a form of knowledge. Code is just a notation for a certain kind of ideas, just as the mathematical or musical notations. I believe (and hope) it's just unavoidable for us all to eventually switch to a mainly free cultural creation system.
We are few weeks away from the start of DebConf11. Excitement runs high in Debian-land. The two most worthy weeks of the year, every year, loom close. Our Bosnian friends have done a great job of finding and defending an amazing proposal, and are now facing the hard work and permanent adrenaline levels of being in charge of the closest I have seen to a herd of (well-behaved but wild and untamable) cats.
I have organized DebConf in my country. It was hellish, but at the same time, it's one of my most cherished experiences. And I'm sure the same will be said by the leaders of each successive bid — It is one of the most rewarding experiences you can imagine.
Next year, DebConf will be held in tropical Managua, Nicaragua. But, where will we meet in 2013? Well, that depends on you, my dear reader! Do you want to work your ass off for Debian and have utter fun? Do you want to show and share your country with this huge family of developers? Start thinking about pushing for a DebConf13 bid!
Do you have to be at Banja Luka to propose your bid? No. You can proxy via somebody — I'd suggest to do it via somebody who knows the location you are suggesting, but basically, choose a friend that you trust that trusts you. Of course, you can participate in the presentation session via IRC.
Do you have to be a Debian Developer to propose a bid? No. For DebConf9, none of the Cáceres guys was a DD; for DebConf10, some of the people most involved from the local New Yorkers were not DDs. For DC11, none of our dear and overworked hosts in Bosnia are DDs. And for DC12, the Nicaraguan crew is also made from people interested in getting closer to the Debian project, but not DDs.
Do you have to decide now? No. This is just a call for a first presentation, but the decision regarding DC13 will be taken probably around March 2012. However, giving a nice presentation at DebConf helps a lot, gives you visibility, and will get the ball rolling.
Is there a geographical bias? Slight. So far, and since the second DebConf, we have kept the tradition not to repeat continents on two successive DebConfs. This is not a hard condition, however!
What do you need to start thinking about? Go visit our prospective location checklist at http://wiki.debconf.org/wiki/LocationCheckList. You can also look at what other teams have historically presented. Finally, I just learnt about the existence of http://wiki.debconf.org/wiki/DebConf13 — Register there, even if you are just in the early phases of finding data.
We will be holding a DebConf13 bids presentation session, most probably (the schedule is close to being presented officially!) on 30-07-2011, at 17:00.
As others have started posting in Planet Debian, I'll do my part: Yesterday I finished booking our flights, so if everything goes as planned, Reg and me will be arriving to Zagreb (Croatia) at 21:30, Monday July 18, to take part of the 12th Debian development conference, DebConf11, in Banja Luka, Bosnia & Herzegovina!
Of course, reiterating this will never hurt: Do you want to support a global-scale, well-recognized, community-based Free Software project development? Be a sponsor for DebConf11!"
Ok, so finally it is official!
If you are curious on the decision process: We held it over two IRC channels — The moderated #debconf-team channel, where only the five members of the decision committee (Marga Manterola, Andrew McMillan, Jeremiah Foster, Holger Levsen, Moray Allan) and two members from each of the bids (Marco Túlio Gontijo e Silva and Rafael Cunha de Almeida from Brazil; Leonardo Gómez and Eduardo Rosales from Nicaragua) had voices, and the open #dc12-discuss channel where we had an open discussion. Of course, you can get the full conversation logs in those links.
I have to thank and congratulate the Brazilian team as they did a great work... The decision was very tight. It was so tight, in fact, that towards the end of the winning all of the committee members were too shy to state the results - so I kidnapped the process by announcing the winner ;-) (I hope that does not cast a shadow of illegitimacy over it)
And, very much worth noting, both teams were also very professional: In previous years, we have seen such decisions degenerate into personal attacks and very ugly situations. That has always been painful and unfortunate. And although the Brazilians will not be able to go celebrate tonight, the decision was received with civility, knowing it was a decision among equals, and a decision well carried out.
Well, that's it — I am very much looking forward for that peculiar two weeks when the whole Debian family meets, this year to be held in Banja Luka, Bosnia-Herzegovina, and I am very eager towards meeting in 2012 in Managua, Nicaragua!
Once again, a polemic regarding how to properly integrate the Ruby language and libraries with the Debian distribution has been ignited. Similar arguments were presented in November and December 2008 and September 2010 — And excuse me for just refering to my own blog, but there are links to some other posts from there... and there will surely be many others I just missed. There were even nice collaboration attempts (such as DebGem, announced in January 2009... But which apparently never stuck on, as it is still listed as in its public Beta period and lists only support for Debian 4.0 and Ubuntu 8.04 and 8.10).
Some days ago, while I was on vacation, I received a mail from Lucas Nussbaum expressing the burnout he had been suffering from this situation. Some days after that, he posted a corresponding blog post - Giving up on Ruby packaging. The comments following his post are most interesting — The one comment I'd like to highlight (noting I skimmed a whole deal of them) is by Paul Brannan, one of the original RubyGems authors. Yes, possibly the design criteria for Gems included some mutually-conflicting goals, and they cover some of Debian's goals. Unfortunately, this conflicting criteria... Was resolved to the opposite way we would have wanted (specifically, that a sysadmin should be able to install software with the same tools he was already familiar with). And of course, there are deeper disagreements, which are rightly stemmed from different priorities: Debian (+derivatives) is meant to make user's and sysadmin's lifes simpler. Gems are meant to make developers' lifes simpler. And while all developers are some sort of users, and sysadminsthe reverse is (obviously) not so.
A developer maintaining several different codebases will surely suffer (well, this particular developer has surely suffered) if he has to maintain them all using coherent versions of system libraries. When a system is programmed, its developers want to use the greatest, latest tools to offer the best experience and functionality. And it's natural for libraries to evolve over time. However, any sysadmin will grind their teeth at the prospect of having many different versions of libraries, as the Gem model proposes. Why? Well, I was bitten by a minor example of it — Bug fixes do not get backported. Of course, if simple bugs are not backported, security and stability of the system as a whole suffers. Often, new software versions will not only add functionality, but improve on how things are done. Not only bugs get corrected, but we get better response times, better memory handling, etc.
It might sound harsh to say this, and even more, as a developer it feels I am talking against myself — But while development time should be minimized during the system design/implementation, once systems are in production, it should be used to allow for friendlier sysadmin relations.
I have to wear both hats at my real-life job. So, what is my take on this? Of course, blaming myself for choosing the wrong version is a no-go. When evaluating a library before using it in my projects, I try to look at its history and API-stability. APIs that change often speak about immature libraries which are still trying to get the right way to implement their functionality; just-started projects might be great and revolutionary, but they do not yet show any kind of long-term committment... And can lead (and have often led me) to painful rewrites when the Next Big Thing is reached.
As for the users: Even if your favorite language has the best and friendliest distribution method, users just do not care about what language was a particular piece of software implemented in. Users want to be able to install and uninstall with their system's usual tools. Directly using Gems, CPAN, PEAR and whatnot is just unnatural for users, however convenient they are for developers. Distributions offer a non-technical advantage in this regard as well: A human filter. As an example, as I write this there are 19392 Ruby Gems and 19092 Perl modules in CPAN (note that CPAN stores some older versions but discourages authors from keeping too many - So no, they are still very different in size). Debian has around 30,000 packages. Why is that? Because all Debian packages _must_ be human-generated, human-reviewed, human-submitted. This means, a person must think each packaged piece of code is worth packaging, is stable enough and provides value to users as it is, and is fit for being part of a stable release. I am not saying with this that 90% of CPAN and Gems are crap — I am saying that they are probably early implementations, to be installed, tested and improved by developers, and still not apt for general public use. Or maybe not interesting enough to be packaged as a service for the non-techie public at large.
Oh, and one last point: Ruby is not a new language anymore. It is a mature, powerful language with different implementations, every time more stable... But it is a language deeply affected by the (not so new anymore either) the appearance of Rails. Why do I say this? Because although the language is in no way tied to Web development, many of its strongest uses are Web-oriented. How does this affect the current discussion? Well, because many people argue that users are no longer needed to install the software. Web systems are installed by sysadmins and used via a Web browser, and sysadmins are expected be more skilled than casual users. Still, in Debian (and in other distributions, surely) we try to make sysadmin's lives simpler — I have (again, talking out of personal experience) installed several webapps (and system tools, and whatnot) for which I never followed any instructions besides aptitude install foo — Using different languages, frameworks, and so on. Can I troubleshoot their installs? Probably, as there is a common logic for how the distribution I have chosen and specialized in works. Can I find causes for bugs in them? Possibly, although there are some languages and frameworks I dare not touch. Can I get help on getting them out of a tight spot? Surely, as there is a central bug tracking system for my distribution — And one of the maintainer's tasks is to separate the problems related to the distribution (packaging, installing, simple user questions and misconceptions) to those derived from real bugs upstream.
Anyway — I am not saying that our way is the best way. No, by a long shot. Again, developers should have an easy, convenient way for installing whatever they want to play with. And to publish it without jumping through hoops. With this post, I'm only trying to express –again– why Debian works the way it does. And hope for better cooperation in the future.
And as for several comments of what I read in Lucas' post, I think that there is interest for this synergy among some of the most committed Ruby people.
I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for — Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions.
The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in – They should only care that it works. We, as packagers, should take care of all the infrastructural stuff.
And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application".
As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years.
That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post – This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work.
And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains.
PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/
This morning, my laptop was stolen from my parked car while I was jogging. I do not want to make a big deal out of it.
Still, even though I am sure it was not targetted at my data (three other people at least were reporting similar facts in the same area), and the laptop's disk will probably just be reformatted, I am trying to limit the possible impact of my cryptographic identification being in somebody else's hands.
GPG makes it easy: I had on that machine just my old 1024D key, so it is just matter of generating a revocation certificate. I have done that, and uploaded it to the SKS keyservers - Anyway, here is my revocation certificate:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: A revocation certificate should follow iHIEIBEIADIFAkyaOZwrHQJBIGNvbXB1dGVyIGNvbnRhaW5pbmcgdGhpcyBrZXkg d2FzIHN0b2xlbgAKCRDYDvNai7UnrzWAAKC34eF76JQjxrZqSjNwcC0dU/5VbACg gMIMmYg91Sl3y8KsZXdGj/rV7UE= =rdlT -----END PGP PUBLIC KEY BLOCK-----
But… What worries me more is access to the computers my ssh key works for. Yes, the ssh key uses a nontrivial passphrase, but still — SSH keys cannot be revoked (and this makes sense, as SSH should not add the delay, or potential impossibility, to check with a remote infrastructure whenever you want to start a session).
So, I generated a new key (and stored it at ~/.ssh/id_rsa.new / ~/.ssh/id_rsa.new.pub) and came up with this snippet:
- $ OLDKEY=xyHywJuHD3nsfLh03G1TqUEBKSj6NlzMfB1T759haoAQ
- $ for host in $(cat .ssh/known_hosts | cut -f 1 -d \ |cut -f 1 -d , |
- sort | uniq); do
- echo == $host
- ssh-copy-id -i .ssh/id_rsa.new.pub $host &&
- ssh $host "perl -n -i -e 'next if /$OLDKEY/;print' .ssh/authorized_keys"
Points about it you might scratch your head about:
- .ssh/known_hosts' lines start with the server's name (or names, if more than one, comma-separated), followed by the key algorithm and the key fingerprint (space-separated). That's the reason for the double cut – It could probably be better using a regex-enabled thingy understanding
/[, ]/, but... I didn't think of that. Besides, the savings would be just for academic purposes ;-)
- I thought about not having the ssh line conditionally depend on ssh-copy-id. But OTOH, this makes sure I only try to remove the old key from the servers it is present on, and that I don't start sending my new key everywhere just for the sake of it.
- my $OLDKEY (declared in Shell, and only literally interpolated in the Perl one-liner below) contains the final bits of my old key. It is long enough for me not to think I'm risking collision with any other key. Why did I choose that particular length? Oh, it was a mouse motion.
- perl -n -i -e is one of my favorite ways to invoke perl. -i means in-line editing, it allows me to modify a file on the fly. This line just skips (removes) any keys containing $OLDKEY; -n tells it to loop all the lines over the provided program (and very similarly, -p would add a print at the end – Which in this particular ocassion, I prefer not to have). It is a sed lookalike, if you wish, but with a full Perl behind.
- This assumes you have set HashKnownHosts: no in your .ssh/config. It is a tradeoff, after all – I use a lot tab-expansion (via bash_completion) for hostnames, so I do have the fully parseable list of hosts I have used on each of my computers.
- I have always requested my account names to be gwolf. If you use more than one username... well, you will have to probably do more than one run of it connecting to foo@$host instead.
- Although most multiuser servers stick to the usual port 22, many people change the ports (me included) either because they perceive concealing them gives extra security, or (as in my case) because they are fed up with random connection attempts. Those hosts are stored as [hostname]:port (i.e. [foo.gwolf.org]:22000). Of course, a little refinement takes care of it all.,/li>
- Oh, I am not storing results... I should, so for successive runs I won't try to connect to a system I already did, or that already denied me access. Why would I want to? Because some computers are not currently turned on. So I'll run this script at least a couple of times.
Oh, by the way: If you noticed me knocking on your SSH ports... please disregard. Possibly at some point I connected to that machine to do something, or it landed in my .ssh/known_hosts for some reason. I currently have 144 hosts registered. I am sure I triggered at least one raised eyebrow.
And I will do it from a couple of different computers, to make it less probable that I miss some I have never connected from while at the particular computer I am sitting at right now.
So... Any ideas on how to make this better?
Asheesh posted When "free software" got a new name, which mentions about the transition period where the Free Software movement started its quest towards being understood by non-geeks, and when people started finding terms better suited for general (and specifically, business-minded) audiences.
We are talking about facts that reached concretion 12 years ago, when the term Open Source was coined and divulgated. That is already far in the past to try and change it – Still, during DebConf I was talking with several friends about it. In my opinion, there was never really the need to choose such an ambiguous name – In English, the word Liberty unambiguously refers to free as in freedom, with no conceptual links to gratuity. Liberty is also a concept held dear by the values of the USA society (which is the birthplace of our ideological movement, so it's specially important). Jimmy Kaplowitz pointed out a reason: Liberty is an incomplete word. You could translate what Asheesh's post mentions, Freed Software → Liberated Software, but libertydoes not exist as an adjective by itself, only when used as contrasting with an earlier more restricted situation. We can say some piece of software was liberated if it was born unfree, but what about things that were libre since the beginning?
So, yes, as beautiful as Liberty is, and as advantageous as such a concept would have been for us... Liberty seems to be too imperfect to be able to represent our movement.
Just echoing what happens in Planet Debian for people who follow my blog (or any other planet where it is syndicated) and is interested in DebConf processes — I'm specially thinking about people interested in preparing a bid for hosting a future DebConf, as well as people organizing hacking conferences who are interesed in understanding how DebConf works:
Richard Darst, a.k.a. our very invaluable MrBeige, started a series of posts describing various processes of DebConf organization. He explicitly asked me for comments while this series was still in planning/wiki stage, but I failed miserably at doing so ;-) So at least I'll publicize his work, linking from here:
- DebConf and Debian: Introductory message, basically outlining (Richard's view on) the relation between Debian and DebConf. This is not yet a clear thing — It seems we are converging on the fact that DebConf *is* part of Debian, but there are several things to clear before it is viewed as a done deal.
- Timeline of a DebConf: Running a DebConf as a local team is not (just) becoming crazy for two weeks, leaving life behind ans working hard for having your friends and peers in your hometown. It is an interesting full two year process, with different phases and aspects for the work. Richard has been involved as an organizer for the last two years, and he summarizes the main periods here.
- What is the DebConf team?: We talk about the localteam and the globalteam as if those terms make any sense. Then again, we have had people as part of localteam who live in different countries... What does this mean? What are the tasks of the teams? How do you join? What kind of work is expected from you? What is the real difference between the teams, if there is any?
- The DebConf selection process: How does the next year's venue selected? How is this "contest" held? When do you have to submit your proposal? How is it ranked/judged/decided? As I have told several people, the first document you should check is always the location checklist (also linked from Richard's text), but having this timeline will surely help you know what to expect.
- How DebConf manages money?: How should the DebConf fundraising process be, and how it actually is; what is the money relation with the whole Debian project... and a couple of points where you can step in and help, as managing money is really difficult
- DebConf budgeting for a single conference: A bit further details on how fundraising, negotiations and money spending was handled for DebConf 10
- The DebConf registration process: What are the parts of our registration process? When does it open/close? Why are the deadlines set so early? How has this been determined in the past? What is corporate and professional attendance?
- DebConf Fundraising (this text by Pablo Duboe): If you want to host a DebConf, an important part of the job is to get money. How should you do it? Who should you ask, what can we show to potential sponsors, how can we approach them?
- How DebCamp relates to DebConf: What is DebCamp? What are the terms for participation? what can you expect to have (and to lack)?
- The DebConf travel sponsorship process (this text by Michael Schultheiss): How is the money for travel sponsorship (travel fare only, lodging and food not included here) awarded to the people requesting it? How does the team reviewing this work decide on whom to grant to? What are the decision criteria?
I don't know if MrBeige is planning further parts for this series; if the past four were interesting, you should check on his weblog. Update: Yes, he is planned, and he has delivered. Adding them to the list as they flow...
This Monday, Debian celebrated its 17th birthday. Yay!
I was invited to celebrate the birthday at HacklabZAM, but could not make it due to the time (17:00-19:00, and I was just leaving work by 19:00), but still, had some beers with long-time geekish friends Iván Chavero, Rolando Cedillo, Manuel Rabade and Odín Mojica. Nice hanging around, good beer+pizza time, and explicit congratulations to Debian.
On the Debian front, Margarita Manterola, Maximiliano Curia, Valessio Brito and Raphael Geissert came up with a very fun Debian appreciation day page. It even included a (slight) hijacking of the bug tracking system's Web interface, showing happy fun balloons! Guys, thanks for a good laugh, and thanks for providing a vehicle for getting the users' thanks to the project!
All in all, that was a great reminder to what we have been repeating as a mantram throughout the last years: Lets keep Debian fun!
So, DebConf time is over once again. The two weeks worth of fifty weeks waiting are left behind once again, and it's back to get back to normal. DebConf was great — Yes, it always is, and that's what we are all saying, but hey - Seriously! Being in the same building than 300 crazed developers is always fun, and it's always better than last year's fun. A good highlight this year is that, given the number of Free Software and Free Culture groups that exist in USA's north-eastern coast, we had the opportunity to join a large crowd which has never been part of DebConf. Also, I must agree that the USA bid for DebConf was aiming to attract as many Debian people (developers, maintainers, or just happy users) which had not yet been to a DebConf before as possible. And it was a great success! I finally met several people I have long read in the mailing lists, in blogs or in IRC. A much higher proportion than usual, I'd venture to say. Another interesting phenomenon /methinks is that this year's DebCamp started much more staffed than usual: I arrived on the first day, Sunday 25, and there were ~40 people there already; I don't have the actual numbers, but we quickly grew, and the number started to stabilize past mid-week, only to (sharply) rise in the weekend, in time for DebianDay and DebConf start. Great time!
But, they say, nobody can go to the USA without buying some sweet toys, right?
Well, being the proud owner of six very hairy cats, I have thought into entering the looming and weaving industry... But cat hair, while abundant, I have heard is untreadable... Maybe due to the indisciplined, natural and independent personality of the cats (catonality should I say?)...
So I had two choices: Clean up my home quite often, or live in a –literally– hairy mess.
Enter choice #3: The Roomba!
I had been waiting to buy this thing for several years, as they refuse to send to Mexico or charge Mexican cards. So, I walked across Manhattan and got my very own robot cleaner!
For my further surprise, although I have not yet tried it (I don't even have a suitable cable yet), I found this:
Yay, the Roomba is actually hackable (via a 7 pin miniDIN serial port)! Wikipedia says that:
Roomba comes with a Mini-DIN TTL serial interface, which is incompatible with standard PC/Mac serial ports and cables, both electrically and physically. However, third-party adapters are available to access the Roomba's computer via Bluetooth, USB, or RS-232 (PC/Mac serial). New, 500-series, and 410/420 series Roombas upgraded with the OSMO hacker device allow the user to monitor Roomba's many sensors and modify its behavior. The Roomba Open Interface (formerly "Roomba Serial Command Interface") API allows programmers and roboticists to create their own enhancements to Roomba. (…)
My first impressions? Well, the Roomba lazily charged its battery throughout the day today, and was hungry and ready when I arrived home. It is a but louder than what I expected, and –of course– my cats were not thrilled by the presence of a eighth animated and apparently sentient being at home. Their initial reaction was –of course– to be verrry alert of the thing. Twelve eyes were constantly pointing at the Roomba while mine alternated between them. As they measured the thing's speed and (I guess) inferred its movement patterns, they started escaping upstairs – A flat, round thing with no legs to be seen will not likely be able to climb the stairs. And they were completely right. At first, only Chupchic remained downstairs. After a bit, I went up to show them the Roomba didn't jump on us to eat our brains, and after a bit, Santa and Macusa joined. The Roomba roombed for maybe 90 minutes (this space is large, and decided it was enough... And slowly, the rest of them started coming down.
I would not say Roomba's cleaning is perfect, of course. Its room discovery algorithm is funny, and it even seems it's based on the mere chance of covering most (never all) of the space it has to clean. I had, of course, not fully studied it (after a single run, how could I?). It does make a honestly good attempt at cleaning under coaches, chairs and tables. It collected a fair amount of dust (on a house that seemed quite clean to me, I cannot imagine what would happen on a messy one). I have not yet played with the virtual walls (infrared transmitters which limit rooms as if a door was closed), but given the size of this house (and that I don't want it to clean around the cats' designated bathroom area), I guess I will end up using them regularly.
During DebConf, I heard one bad (stupid useless noisy thing) and two very good (it has radically changed my life) comments on the Roomba. I hope to shift the balance towards 3/4 and not towards 2/2!
Anyways... Thanks to each and every one of you. DebConf is great. Always great. Always a success. I cannot even thank specific teams. Debian Rules, and DebConf Rocks!
If you have seen me anywhere near my computer at DebConf, you probably have seen the face of a hurried, worried developer. Still, if you monitor my Debian-related activity, you will notice it is still quite low, even given my (much needed and very much enjoyed) vacations pre-DebConf. Yes, orga-team work is very time consuming, even if my role is far from central this year. And yes, DebCamp+DebConf are known for sucking time into social interaction, which is great but not so (formally) productive. And yes, I even took 1.5 days off to visit my family and a friend who live in the area...
Still, I managed to release! \☺/
I have been working with Pooka for the last ~2 years on the Seminary on Collaborative Knowledge Construction. We assembled a group of ~10 speakers/authors, each of whom prepared a chapter for a book meant for publication. Pooka and me coordinated the work, which took a long time because it was also an interaction experiment (and because we both did it only in our free time).
After the coordination work started fading, I took up the task of coming up with a way to translate it all into LaTeX (and fix a host of conversion bugs, and play with the available packages, and... Hey, I'm after all just a LaTeX newbie, and had to learn to tame the beast!), I stumbled upon that precious fact that makes so many projects release.
I stumbled upon a deadline.
We want to publish the book under the seal of IIEc-UNAM. Besides my workplace, it is a very well regarded university, and having its seal in our work is definitively a big plus. And the Publications Committee of my Institute is meeting this week - So I had to send our final manuscript by today.
Having a deadline overlapping with DebConf sucks. But somehow, I managed to do the needed work to my complete satisfaction. The work is now in the Committee's hands, and I expect to have more news soon(ish).
Oh, and where can you get our work? Well, if you register in our site, you will be able to read the whole contents. And once the book is approved and published, the whole work will be published online under a free (CC-BY-SA) license.
BTW, that probably means I will have more time to fix my Debian bugs and pending stuff! \☻/
If Tim can report his movements around New York, so can I! ;-) Sadly, due to Nokia deprecating my still-quite-new N95 phone by not allowing me to use their service anymore, I won't be able to share my routes with you – But anyway…
This morning I decided to take a quick run to start off the day on Riverside Park (the park where we had dinner yesterday). I went South for about 3Km and headed back (for, you guessed right, a grand total of 6Km), and decided that 45 minutes of exercising are enough to declare my day started - As I started at ~8:15, it was getting warm (specially when running under the sun). I am quite heath-intolerant; it's not unpleasant at all, but I will try to run earlier on future days.
Riverside is a long and narrow park. I ran Southwards by the lower trail, in the park itself, but ran Northwards by the upper trail, in the wide sidewalk between the street and the park. The way South was also way flatter, while the way back goes up and down repeatedly.
I don't think I will run on a daily basis, but that will be determined by my mood when I open my eyes in the morning ;-) Anyway, riverside is a very nice run, and I expect to head North. I still am not back to running ~10Km, so I won't do the Central Park trail Tim did - But I'll surely go run there as well a bit. And rent a bike one of this days for a ~2hr morning ride, of course!
I spent the past three weeks away from basically any kind of usual contact. I took a three week vacation in Argentina (Buenos Aires, Entre Ríos, Tucumán, Salta, Jujuy, Córdoba), got my first snow experience and enjoyed a real lot... But got completely disconnected from all of my usual activities... and responsabilities :-}
Anyway, yesterday afternoon I landed in New York. Arrived to Columbia around 2PM, and spent most of the day zombying around with the Debian crew. And today it starts feeling like the real job is starting.
As always, there is a lot of excitement when DebConf starts. I have many items I want to work on, and most are even Debian related ;-) So, lets get work flowing!