exercism.io is a croud-sourced mentorship platform for learning to program. In my opinion, they do a lot of things right. In particular, an exercise on exercism.io consists of a descriptive README file and a set of test cases implemented in the target programming language. The tests have two positive sides: You learn to do test-driven development, which is good. And you also have an automated validation suite. Of course, a test can not give you feedback on your actual implementation, but at least it can give you an idea if you have managed to implement what was required of you. But that is not the end of it. Once you have submitted a solution to a particular exercise, other users of exercism.io can comment on your implementation. And you can, as soon as you have submitted the first implementation, look at the solutions that other people have submitted to that particular problem. So knowledge transfer can happen both ways from there on: You can learn new things from how other people have solved the same problem, and you can also tell other people about things they might have done in a different way. These comments are, somewhat appropriately, called nitpicks on exercism.io.
Now, exercism has recently gained a C++ track. That track is particularily fun, because it is based on C++11, Boost, and CMake. Things that are quite standard to C++ development these days. And the use of C++11 and Boost makes some solutions really shine.
After becoming a DM at Debconf12 in Managua, Nicaragua and entering the NM queue during Debconf13 in Vaumarcus, Switzerland I received the mail about 24 hours too late to officially become a DD during Debconf14 in Portland, USA. Nevertheless it was a very pleasant surprise to find the mail in my INBOX this morning confirming that my account had been created and that I was officially firstname.lastname@example.org. Thanks to everyone who helped/encouraged me along the way!
I don't imagine much will change in practice, I intend to remain involved in the kernel and Debian Installer efforts as well as continuing to contribute to the Xen packaging and to maintain qcontrol (both in Debian and upstream) and sunxi-tools. I suppose I also still maintain ivtv-utils and xserver-xorg-video-ivtv but they require so little in the way of updates that I'm not sure they count.
This is my monthly summary of my free software related activities. If you’re among the people who made a donation to support my work (65.55 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.Distro Tracker
Even though I was officially in vacation during 3 of the 4 weeks of August, I spent many nights working on Distro Tracker. I’m pleased to have managed to bring back Python 3 compatibility over all the (tested) code base. The full test suite now passes with Python 3.4 and Django 1.6 (or 1.7).
From now on, I’ll run “tox” on all code submitted to make sure that we won’t regress on this point. tox also runs flake8 for me so that I can easily detect when the submitted code doesn’t respect the PEP8 coding style. It also catches other interesting mistakes (like unused variable or too complex functions).
Getting the code to pass flake8 was also a major effort, it resulted in a huge commit (89 files changed, 1763 insertions, 1176 deletions).
Thanks to the extensive test suite, all those refactoring only resulted in two regressions that I fixed rather quickly.
Some statistics: 51 commits over the last month, 41 by me, 3 by Andrew Starr-Bochicchio, 3 by Christophe Siraut, 3 by Joseph Herlant and 1 by Simon Kainz. Thanks to all of them! Their contributions ported some features that were already available on the old PTS. The new PTS is now warning of upcoming auto-removals, is displaying problems with uptream URLs, includes a short package description in the page title, and provides a link to screenshots (if they exist on screenshots.debian.net).
We still have plenty of bugs to handle, so you can help too: check out https://tracker.debian.org/docs/contributing.html. I always leave easy bugs for others to handle, so grab one and get started! I’ll review your patch with pleasure.Tryton
I wasn’t able to attend this year but thanks to awesome work of the video team, I watched some videos (and I still have a bunch that I want to see). Some of them were put online the day after they had been recorded. Really amazing work!Django 1.7
After the initial bug reports, I got some feedback of maintainers who feared that it would be difficult to get their packages working with Django 1.7. I helped them as best as I can by providing some patches (for horizon, for django-restricted-resource, for django-testscenarios).
Since I expected many maintainers to be not very pro-active, I rebuilt all packages with Django 1.7 to detect at least those that would fail to build. I tagged as confirmed all the corresponding bug reports.
Looking at https://email@example.com;tag=django17, one can see that some progress has been made with 25 packages fixed. Still there are at least 25 others that are still problematic in sid and 35 that have not been investigated at all (except for the automatic rebuild that passed). Again your help is more than welcome!
It’s easy to install python-django 1.7 from experimental and they try to use/rebuild the packages from the above list.Dpkg translation
With the freeze approaching, I wanted to ensure that dpkg was fully translated in French. I thus pinged firstname.lastname@example.org and merged some translations that were done by volunteers. Unfortunately it looks like nobody really stepped up to maintain it in the long run… so I did myself the required update when dpkg 1.17.12 got uploaded.
Is there anyone willing to manage dpkg’s French translation? With the latest changes in 1.17.13, we have again a few untranslated strings:
$ for i in $(find . -name fr.po); do echo $i; msgfmt -c -o /dev/null --statistics $i; done
1083 translated messages, 4 fuzzy translations, 1 untranslated message.
268 translated messages, 3 fuzzy translations.
545 translated messages.
2277 translated messages, 8 fuzzy translations, 3 untranslated messages.
I made an xsane QA upload (it’s currently orphaned) to drop the (build-)dependency on liblcms1 and avoid getting it removed from Debian testing (see #745524). For the record, how-can-i-help warned me of this after one dist-upgrade.
With the Django 1.7 work and the need to open up an experimental branch, I decided to switch python-django’s packaging to git even though the current team policy is to use subversion. This triggered (once more) the discussion about a possible switch to git and I was pleased to see more enthusiasm this time around. Barry Warsaw tested a few workflows, shared his feeling and pushed toward a live discussion of the switch during Debconf. It looks like it might happen for good this time. I contributed my share in the discussions on the mailing list.Thanks
See you next month for a new summary of my activities.
Here is to clarify once and for all – I maintain 17 packages:
- clzip, lunzip, lzd, lzip, lziprecover, lzlib, pdlzip, plzip, zutils
- live-boot, live-build, live-config, live-images, live-manual, live-tools
Not more, not less, and I also do not intend to upload any new packages to Debian.
This time, for personal reasons I wasn’t able to attend the full DebConf, which started on the Saturday August 22nd. I arrived at Portland on the Tuesday the 26th by noon, at the 4th of the conference. Even though I would like to arrive earlier, the loss was alleviated by the work of the amazing DebConf video team. I was able to follow remotely most of the sessions I would like to attend if I were there already.
As I will say to everyone, DebConf is for sure the best conference I have ever attended. The technical and philosophical discussions that take place in talks, BoF sessions or even unplanned ad-hoc gathering are deep. The hacking moments where you have a chance to pair with fellow developers, with whom you usually only have contact remotely via IRC or email, are precious.
That is all great. But definitively, catching up with old friends, and making new ones, is what makes DebConf so special. Your old friends are your old friends, and meeting them again after so much time is always a pleasure. New friendships will already start with a powerful bond, which is being part of the Debian community.
Being only 4 hours behind my home time zone, jetlag wasn’t a big problem during the day. However, I was waking up too early in the morning and consequently getting tired very early at night, so I mostly didn’t go out after hacklabs were closed at 10PM.
Despite all of the discussion, being in the audience for several talks, other social interactions and whatnot, during this DebConf I have managed to do quite some useful work.debci and the Debian Continuous Integration project
I gave a talk where I discussed past, present, and future of debci and the Debian Continuous Integration project. The slides are available, as well as the video recording. One thing I want you to take away is that there is a difference between debci and the Debian Continuous Integration project:
- debci is a platform for Continuous Integration specifically tailored for the Debian repository and similar ones. If you work on a Debian derivative, or otherwise provides Debian packages in a repository, you can use debci to run tests for your stuff.
- a (very) few thinks in debci, though, are currently hardcoded for Debian. Other projects using it would be a nice and needed peer pressure to get rid of those.
- Debian Continuous Integration is Debian’s instance of debci, which currently runs tests for all packages in the unstable distribution that provide autopkgtest support. It will be expanded in the future to run tests on other suites and architectures.
A few days before DebConf, Cédric Boutillier managed to extract gem2deb-test-runner from gem2deb, so that autopkgtest tests can be run against any Ruby package that has tests by running gem2deb-test-runner --autopkgtest. gem2deb-test-runner will do the right thing, make sure that the tests don’t use code from the source package, but instead run them against the installed package.
Then, right after my talk I was glad to discover that the Perl team is also working on a similar tool that will automate running tests for their packages against the installed package. We agreed that they will send me a whitelist of packages in which we could just call that tool and have it do The Right Thing.
We might be talking here about getting autopkgtest support (and consequentially continuous integration) for free for almost 2000 packages. The missing bits for this to happen are:
- making debci use a whitelist of packages that, while not having the appropriate Testsuite: autopkgtest field in the Sources file, could be assumed to have autopkgtest support by calling the right tool (gem2deb-test-runner for Ruby, or the Perl team’s new tool for Perl packages).
- make the autopkgtest test runner assume a corresponding, implicit, debian/tests/control when it not exists in those packages
During a few days I have mentored Lucas Kanashiro, who also attended DebConf, on writing a patch to add support for email notifications in debci so maintainers can be pro-actively notified of status changes (pass/fail, fail/pass) in their packages.
I have also started hacking on the support for distributed workers, based on the initial work by Martin Pitt:
- updated the amqp branch against the code in the master branch.
- added a debci enqueue command that can be used to force test runs for packages given on the command line.
- I sent a patch for librabbitmq that adds support for limiting the number of messages the server will send to a connected client. With this patch applied, the debci workers were modified to request being sent only 1 message at a time, so late workers will start to receive packages to process as soon as they are up. Without this, a single connected worker would receive all messages right away, while a second worker that comes up 1 second later would sit idle until new packages are queued for testing.
I had some discusion with Christian about making Rubygems install to $HOME by default when the user is not root. We discussed a few implementation options, and while I don’t have a solution yet, we have a better understanding of the potential pitfalls.
The Ruby BoF session on Friday produced a few interesting discussions. Some take away point include, but are not limited to:
- Since the last DebConf, we were able to remove all obsolete Ruby interpreters, and now only have Ruby 2.1 in unstable. Ruby 2.1 will be the default version in Debian 8 (jessie).
- There is user interest is being able to run the interpreter from Debian, but install everything else from Rubygems.
- We are lacking in all the documentation-related goals for jessie that were proposed at the previous DebConf.
I was able to make Redmine work with the Rails 4 stack we currently have in unstable/testing. This required using a snapshot of the still unreleased version 3.0 based on the rails-4.1 branch in the upstream Subversion repository as source.
I am a little nervous about using a upstream snapshot, though. According to the "roadmap of the project ":http://www.redmine.org/projects/redmine/roadmap the only purpose of the 3.0 release will be to upgrade to Rails 4, but before that happens there should be a 2.6.0 release that is also not released yet. 3.0 should be equivalent to that 2.6.0 version both feature-wise and, specially, bug-wise. The only problem is that we don’t know what that 2.6.0 looks like yet. According to the roadmap it seems there is not much left in term of features for 2.6.0, though.
The updated package is not in unstable yet, but will be soon. It needs more testing, and a good update to the documentation. Those interested in helping to test Redmine on jessie before the freeze please get in touch with me.Noosfero
I gave a lighting talk on Noosfero, a platform for social networking websites I am upstream for. It is a Rails appplication licensed under the AGPLv3, and there are packages for wheezy. You can checkout the slides I used. Video recording is not available yet, but should be soon.
That’s it. I am looking forward to DebConf 15 at Heidelberg. :-)
- I should stop being childish, but I don't wanna.
- A few new examples were added or updated, including use of the fabulous new docopt package by Edwin de Jonge which makes command-line parsing a breeze.
- Other new examples show simple calls to help with sweave, knitr, roxygen2, Rcpp's attribute compilation, and more.
- We also wrote an entirely new webpage with usage example.
- A new option -d | --datastdin was added which will read stdin into a data.frame variable X.
- The repository has been move to this GitHub repo.
- With that, the build process was updated both throughout but also to reflect the current git commit at time of build.
Debconf14 was the first Debconf I attended. It was an awesome experience.
Debconf14 started with a Meet and Greet before the Welcome Talk. I got to meet people and find out what they do for Debian. I also got to meet other GSoC students that I had only previously interacted with online. During the Meet and Greet I also met one of my mentors for GSoC, Zack. Later in the conference I met another of my mentors, Piotr. Previously I only interacted with Zack and Piotr online.
On Monday we had the OpenPGP Keysigning. I got to meet people and exchange information so that we could later sign keys. Then on Tuesday I gave my talk about debmetrics as part of the larger GSoC talks.
During the conference I mostly attended talks. Then on Wednesday we had the daytrip. I went hiking at Multnomah Falls, had lunch at Rooster Rock State Park, and then went to Vista House.
Later in the conference, Zack and I did some work on debmetrics. We looked at the tests, which had some issues. I was able to fix most of the issues with the tests while I was there at Debconf. We also moved the debmetrics repository under the qa category of repositories. Previously it was a private repository.
Two of the main things I’ve been working on since I started at Xamarin are making it easier for people to try out the latest bleeding-edge Mono, and making it easier for people on older distributions to upgrade Mono without upgrading their entire OS.Public Jenkins packages
Every time anyone commits to Mono git master or MonoDevelop git master, our public Jenkins will try and turn those into packages, and add them to repositories. There’s a garbage collection policy – currently the 20 most recent builds are always kept, then the first build of the month for everything older than 20 builds.
Because we’re talking potentially broken packages here, I wrote a simple environment mangling script called mono-snapshot. When you install a Jenkins package, mono-snapshot will also be installed and configured. This allows you to have multiple Mono versions installed at once, for easy bug bisecting.
directhex@marceline:~$ mono --version Mono JIT compiler version 3.6.0 (tarball Wed Aug 20 13:05:36 UTC 2014) directhex@marceline:~$ . mono-snapshot mono [mono-20140828234844]directhex@marceline:~$ mono --version Mono JIT compiler version 3.8.1 (tarball Fri Aug 29 07:11:20 UTC 2014)
The instructions for setting up the Jenkins packages are on the new Mono web site, specifically here. The packages are built on CentOS 7 x64, Debian 7 x64, and Debian 7 i386 – they should work on most newer distributions or derivatives.Stable release packages
This has taken a bit longer to get working. The aim is to offer packages in our Apt/Yum repositories for every Mono release, in a timely fashion, more or less around the same time as the Mac installers are released. Info for setting this up is, again, on the new website.
Like the Jenkins packages, they are designed as far as I am able to cleanly integrate with different versions of major popular distributions – though there are a few instances of ABI breakage in there which I have opted to fix using one evil method rather than another evil method.
Please note that these are still at “preview” or “beta” quality, and shouldn’t be considered usable in major production environments until I get a bit more user feedback. The RPM packages especially are super new, and I haven’t tested them exhaustively at this point – I’d welcome feedback.
I hope to remove the “testing!!!” warning labels from these packages soon, but that relies on user feedback to my xamarin.com account preferably (jo.shields@)
Part 1 - Debconf 2014
This year I went to my first Debconf, which took place in Portland, OR during the last week of August 2014. All in all I have to rate my experience as very enlightening and in the end quite fun.
First of all, it was a little daunting to go to a conference in 1 - A city I’d never been to before; 2 - A conference with 300+ people, only 3 of which I knew and even then I only knew them virtually. Not to mention I was in the presence of some extremely brilliant and known contirbutors in the Debian community which was somewhat intimidating. Just to give you an idea, Linus Torvalds showed up for a Q&A session last Friday morning! Jealous? Actually I missed that too. It was kind of a last minute thing, booked for coincidentally the exact time I’d be flying out of Portland. I found out about it much too late. But luckily for me and maybe you, the session was filmed and can be seen here. Isn’t that a treat?
Point made, there are lots of really talented people there, both techies and non-techies. It’s easy to feel you’re out of league, at least I did. But I’d highly encourage you to ignore such feelings if you’re ever in the same situation. Debian has been built on for a long time now, but although a lot has been done, a lot still needs to be done. The Debian community is very welcoming of new contributors and users, regardless of the level of expertise. So far I haven’t been snubbed by anyone. To the contrary, all my interactions with the Debian community members has been extremely positive.
So go ahead and attend the meetings and presentations, even if you think it’s not your area of expertise. Debconf was organized (or at least this one was) as a series of talks, meet ups and ad hoc sessions, some of which occured simultaneously. The sessions were all about different components of the Debian universe, from presenting new features to overviews of accomplishments to discussing issues and how to fix them. A schedule with the location and description of each session was posted on the Debconf wiki. Sometimes none of the sessions at a certain time was on a topic I knew very much about. But I’d sit in anyways. There’s no rule to attending the sessions, no ‘minimum qualifications’ required. You’ll likely learn something new and you just might find out there is something you can do to contribute. There are also hackathons that are quite the thing or so I heard. Or you could walk about and meet new people, do some networking.
I have to say networking was the highlight of the Debconf for me. Remember I said I knew about 3 people who were at the conference? Well, I had actually just corresponded with those people. I didn’t really know them. So on my first day I spent quite some time shyly peeking at people’s name tags, trying to recognize someone I had ‘met’ over email or IRC. But with 300 or so people at the conference, I was unsuccessful. So I finally gave up on that strategy and walked up to a random person, stuck out my hand and said, “Hi. My name is Juliana. This is my first Debconf. What’s your name and what do you do for Debian?” This may not be according to protocol, but it worked for me. I got to meet lots of people that way, met some Debian contributos from my home country (Brazil), some from my current city (NYC), and yet others that had similar interests as I do who I might work with in the near future. For example, I love Machine Learning, I’m currently beginning my graduate studies on that track. Several Debian contributors offered to introduce me to a well known Machine Learning researcher and Debian contributor who is in NYC. Others had tried out JSCommunicator and had lots of suggestions for new features and fixes, or wanted to know more about the project and WebRTC in general. Also, not everyone there is a super experienced Debian contributor or user. There are a lot of newbies like me.
I got to do a quick 20-min presentation and demo of the work I had done on JSCommunicator during GSoC 2014. Oh my goodness that was nerve-wracking, but not half as painful as I expected. My mentor (Daniel Pocock) wisely suggested that when confronted with a question I didn’t know how to answer, to redirect the question to to the audience. Chances are, there is someone there that knows the answer. If not, it will at least spark a good discussion.
When meeting new people at Debian, a question almost everyone asked is “How did you start working with/for Debian?”. So I thought it would be a good topic to post about.
Part 2 - How I Became a Debian Contributor
Sometime in late October of 2013 (I think) I received an email from one of my professors at UNIRIO forwarding a description of the Outreach Program for Women. OPW is a program organized by the GNOME which endeavors to get more women involved in FOSS. OPW is similar to Google Summer of Code; you work remotely from home, guided by an assigned mentor. Debian was one of the 8 participating organizations that year. There was a list of project proposals which I perused, a few of them caught my eye and these projects were all Debian. I’d already been a fan of FOSS before. I had used the Ubuntu and Debian OS, I’d migrated to GIMP from Photoshop and Open Office from Microsoft Office, for example. I’d strongly advocated the use of some of my prefered open source apps and programs to my friends and family. But I hadn’t ever contributed to a FOSS project.
There’s no time like the present, so I reached out the the mentor responsible for one of the projects I was interested in, Daniel Pocock. Daniel guided me through making a small contribution to a FOSS project, which serves as a token demonstration of my abilities and is part of the application process. I added a small feature to JMXetric(https://github.com/ganglia/jmxetric) and suggested a fix for an issue in the xTuple project. Actually, I had forgotten about this. Recently I made another contribution to xTuple, it’s funny to see things come full circle. I also had to write a profile-ish description of my experience and how I intended on contributing during OPW on the Debian wiki, if you’d like you can check it out here.
I wouldn’t follow my example to a T, because in the end I didn’t make the OPW selection. Actually, I take that back. The fact I wasn’t chosen for OPW that year doesn’t mean I was incompetent or incapable of making a valuable contribution. OPW and GSoC do not have unlimited resources, they can’t include everyone they’d like to. They receive thousands of proposals from very talented engineers and not everyone can participate at a given moment. But even though I wasn’t selected, like I said, I could still pitch in. It’s good to keep in mind that people usually aren’t paid to contribute to FOSS. It’s usually volunteer based, which I think is one of the beauties of the FOSS community and in my opinion one of the causes of it’s success and great quality. People contribute because they want to, not because they have to.
I will say I was a little disappointed at not being chosen. But after being reassured that this ‘rejection’ wasn’t due to any lack on my part, I decided to continue contributing to the Debian project I’d applied to. I was begining the final semester of my undergraduate studies which included writing a thesis. To be able to focus on my thesis and graduate on time, I’d stopped working and was studying full time. But I didn’t want to lose practice and contributing to a FOSS project is a great way to stay in coding shape while doing something useful. So continue contributing I did.
It paid off. I gained experience, added value to a FOSS project and I think my previous contributions added weight to the application I later made for GSoC 2014. I passed this time. To be honest, I really wasn’t counting on it. Actually, I was certain I wouldn’t pass for some reason - insecure much? But with GSoC I wasn’t too anxious about it as I was with the OPW application because by then, I was already ‘hooked’. I’d learned about all the benefits of becoming a FOSS contributor and I wasn’t stopping anytime soon. I had every intention of still working on my FOSS project with or without GSoC. GSoC 2014 ended a week ago (August 18th 2014). There’s a list of things I still want to do with JSCommunicator and you can be sure I’ll keep working on them.
P.S. This is not to say that programs like OPW and GSoC aren’t amazing programs. Try it out if you can, it’s really a great experience.
Bug #750000 was reported as of May 31th: nearly exactly 3 months for 10,000 bugs. The bug rate increased a little bit during the last weeks, probably because of the freeze approaching.
We're therefore getting more clues about the time when bug #800000 for which we have bets. will be reported. At current rate, this should happen in one year. So, the current favorites are Knuth Posern or Kartik Mistry. Still, David Prévot, Andreas Tille, Elmar Heeb and Rafael Laboissiere have their chances, too, if the bug rate increases (I'll watch you guys: any MBF by one of you will be suspect...:-)).
This weekend I moved my blog to a different server. This meant I could:
- Enable IPv6
- Enable SSL
- Set up a pump.io profile
I've tested it, and it's working. I'm hoping that I can swap out the Node.js modules one-by-one for the Debian-packaged versions.
After the talk, various DebConf participants have approached me and started hacking on Debsources, which is awesome! As a result of their work, new shiny features will probably be announced shortly. Stay tuned.
When discussing with new contributors (hi Luciano, Raphael!), though, it quickly became clear that getting started with Debsources hacking wasn't particularly easy. In particular, doing a local deployment for testing purposes might be intimidating, due to the need of having a (partial) source mirror and whatnot. To fix that, I have now written a HACKING file for Debsources, which you can find at top-level in the Git repo.
Happy Debsources hacking!
By pure chance I was able to accept 237 packages, the same number as last month. 33 times I contacted the maintainer to ask a question about a package and 55 times I had to reject a package. The reject number increased a bit as I also worked on packages that already got a note but had not been fully processed. In contrast I only filed three serious bugs this month.
Currently there are about 200 packages still waiting in the NEW queue As the freeze for Jessie comes closer every day, I wonder whether all of them can be processed in time. So I don’t mind if every maintainer checks the package again and maybe uploads an improved version that can be processed faster.
All in all I got assigned a workload of 16.5h for August. I spent these hours to upload new versions of
- [DLA 32-1] nspr security update
- [DLA 34-1] libapache-mod-security security update
- [DLA 36-1] polarssl security update
- [DLA 37-1] krb5 security update
- [DLA 39-1] gpgme1.0 security update
- [DLA 41-1] python-imaging security update
As last month I prepared these uploads on the basis of the corresponding DSAs for Wheezy. For these packages backporting the Wheezy patches to Squeeze was rather easy.
I also had a look at python-django and eglibc. Although the python-django patches apply now, the package fails some tests and these issues need some further investigation. In case of eglibc, my small pbuilder didn’t have enough resources and trying to build the package resulted in a full disk after more than three hours of work.
For PHP5 Ondřej Surý (the real maintainer) suggested to use point releases of upstream instead of applying only patches. I am curious about how much effort is needed for this approach. Stay tuned, next month you will be told more details!
Anyway, this is still a lot of fun and I hope I can finish python-django, eglibc and php5 in September.
This month my meep packages plus mpb have been part of a small hdf5 transition. All five packages needed a small patch and a new upload. As the patch was already provided by Gilles Filippini, this was done rather quickly.
If you would like to support my Debian work you could either be part of the Freexian initiative (see above) or consider to send some bitcoins to 1JHnNpbgzxkoNexeXsTUGS6qUp5P88vHej. Contact me at email@example.com if you prefer another way to donate. Every kind of support is most appreciated.
apt-offline 1.4 has been released . This is a minor bug fix release. In fact, one feature, offline bug reports (--bug-reports), has been dropped for now.
The Debian BTS interface seems to have changed over time and the older debianbts.py module (that used the CGI interface) does not seem to work anymore. The current debbugs.py module seems to have switched to the SOAP interface.
There are a lot of changes going on personally, I just haven't had the time to spend. If anyone would like to help, please reach out to me. We need to use the new debbugs.py module. And it should be cross-platform.
Also, thanks to Hans-Christoph Steiner for providing the bash completion script.Categories:
Sociological Images has an interesting article making the case for phasing out the US $0.01 coin . The Australian $0.01 and $0.02 coins were worth much more when they were phased out.
Multiplicity is a board game that’s designed to address some of the failings of SimCity type games . I haven’t played it yet but the page describing it is interesting.
Adam Bryant wrote an interesting article for NY Times about Google’s experiments with big data and hiring . Among other things it seems that grades and test results have no correlation with job performance.
Jennifer Chesters from the University of Canberra wrote an insightful article about the results of Australian private schools . Her research indicates that kids who go to private schools are more likely to complete year 12 and university but they don’t end up earning more.
Wired has an interesting article about the Bittorrent Sync platform for distributing encrypted data . It’s apparently like Dropbox but encrypted and decentralised. Also it supports applications on top of it which can offer social networking functions among other things.
The AbbottsLies.com.au site catalogs the lies of Tony Abbott . There’s a lot of work in keeping up with that.
-  http://www.hezmatt.org/~mpalmer/blog/2014/06/29/adventures-in-dnssec.html
-  http://thesocietypages.org/socimages/2012/05/05/a-case-against-the-penny/
-  http://www.molleindustria.org/blog/multiplicity/
-  http://carlos.bueno.org/2014/06/mirrortocracy.html
-  http://tinyurl.com/mrxjuff
-  http://tinyurl.com/k6abj26
-  https://play.google.com/store/apps/details?id=org.kiwix.kiwixmobile
-  http://www.mamamia.com.au/news/world-congress-of-families-conference/
-  http://tinyurl.com/n7sczw4
-  http://tinyurl.com/k3k36sq
-  http://tinyurl.com/k3k36sq
-  http://tinyurl.com/l42mckp
-  http://www.abbottslies.com.au/
-  http://www.racialicious.com/2009/12/21/and-we-shall-call-this-moffs-law/
-  http://tinyurl.com/karyryk
-  http://tinyurl.com/puydo94
Today we have a little diversion to talk about the National Health Service. The NHS is the publicly funded healthcare system in the UK.
Actually there are four such services in the UK, only one of which has this name:
- The national health service (England)
- Health and Social Care in Northern Ireland.
- NHS Scotland.
- NHS Wales.
In theory this doesn't matter, if you're in the UK and you break your leg you get carried to a hospital and you get treated. There are differences in policies because different rules apply, but the basic stuff "free health care" applies to all locations.
(Differences? In Scotland you get eye-tests for free, in England you pay.)
My wife works as an accident & emergency doctor, and has recently changed jobs. Hearing her talk about her work is fascinating.
The hospitals she's worked in (Dundee, Perth, Kirkcaldy, Edinburgh, Livingstone) are interesting places. During the week things are usually reasonably quiet, and during the weekend things get significantly more busy. (This might mean there are 20 doctors to hand, versus three at quieter times.)
Weekends are busy largely because people fall down hills, get drunk and fight, and are at home rather than at work - where 90% of accidents occur.
Of course even a "quiet" week can be busy, because folk will have heart-attacks round the clock, and somebody somewhere will always be playing with a power tool, a ladder, or both!
So what was the point of this post? Well she's recently transferred to working for a childrens hospital (still in A&E) and the patiences are so very different.
I expected the injuries/patients she'd see to differ. Few 10 year olds will arrive drunk (though it does happen), and few adults fall out of trees, or eat washing machine detergent, but talking to her about her day when she returns home is fascinating how many things are completely different from how I expected.
Adults come to hospital mostly because they're sick, injured, or drunk.
Children come to hospital mostly because their parents are paranoid.
A child has a rash? Doctors are closed? Lets go to the emergency ward!
A child has fallen out of a tree and has a bruise, a lump, or complains of pain? Doctors are closed? Lets go to the emergency ward!
I've not kept statistics, though I wish I could, but it seems that she can go 3-5 days between seeing an actually injured or chronicly-sick child. It's the first-time-parents who bring kids in when they don't need to.
Understandable, completely understandable, but at the same time I'm sure it is more than a little frustrating for all involved.
Finally one thing I've learned, which seems completely stupid, is the NHS-Scotland approach to recruitment. You apply for a role, such as "A&E doctor" and after an interview, etc, you get told "You've been accepted - you will now work in Glasgow".
In short you apply for a post, and then get told where it will be based afterward. There's no ability to say "I'd like to be a Doctor in city X - where I live", you apply, and get told where it is post-acceptance. If it is 100+ miles away you either choose to commute, or decline and go through the process again.
This has lead to Kirsi working in hospitals with a radius of about 100km from the city we live in, and has meant she's had to turn down several posts.
And that is all I have to say about the NHS for the moment, except for the implicit pity for people who have to pay (inflated and life-changing) prices for things in other countries.
After an intensive evening of brainstorming by the 5th floor cabal, I am happy to release the very first version of the Debian Trivia, modeled after the famous TCP/IP Drinking Game. Only the questions are listed here — maybe they should go (with the answers) into a package? Anyone willing to co-maintain? Any suggestions for additional questions?
- what was the first release with an “and-a-half” release?
- Where were the first two DebConf held?
- what are Debian releases named after? Why?
- Give two names of girls that were originally part of the Debian Archive Kit (dak), that are still actively used today.
- Swirl on chin. Does it ring a bell?
- What was Dunc Tank about? Who was the DPL at the time? Who were the release managers during Dunc Tank?
- Cite 5 different valid values for a package’s urgency field. Are all of them different?
- When was the Debian Maintainers status created?
- What is the codename for experimental?
- Order correctly lenny, woody, etch, sarge
- Which one was the Dunc Tank release?
- Name three locations where Debian machines are hosted.
- What does the B in projectb stand for?
- What is the official card game at DebConf?
- Describe the Debian restricted use logo.
- One Debian release was frozen for more than a year. Which one?
- name the kernel version for sarge, etch, lenny, squeeze, wheezy. bonus for etch-n-half!
- What happened to Debian 1.0?
- Which DebConfs were held in a Nordic country?
- What does piuparts stand for?
- Name the first Debian release.
- Order correctly hamm, bo, potato, slink
- What are most Debian project machines named after?
Recently I was doing some work on the alioth infrastructure like fixing things or cleaning up things.
One of the more visible things I done was the switch from gitweb to cgit. cgit is a lot of faster and looks better than gitweb.
The list of repositories is generated every hour. The move also has the nice effect that user repositories are available via the cgit index again.
I don’t plan to disable the old gitweb, but I created a bunch of redirect rules that - hopefully - redirect most use cases of gitweb to the equivalent cgit url.
If I broke something, please tell me, if I missed a common use case, please tell me. You can usually reach me on #alioth@oftc or via mail (firstname.lastname@example.org)
People also asked me to upload my cgit package to Debian, the package is now waiting in NEW. Thanks to Nicolas Dandrimont (olasd) we also have a patch included that generates proper HTTP returncodes if repos doesn’t exist.