Search Results: "ema"

16 March 2013

Stefano Zacchiroli: bits from the DPL for February 2013 and a half

Dear project members, here's another report of DPL activities, this time for a period longer than usual (February + 1st week of March), so that the next one will be at the very end of the current DPL term. Highlights Appointments DPL helpers Two more DPL helpers IRC meetings have happened, minutes and logs of both are available. Assets Events Past At the beginning of February, I've attended FOSDEM 2013, together with many other Debian people. I didn't have any specific talk this year, but it's been a chance to talk F2F about several ongoing issues (see logs), and help mediating in some conflicts. I've also accepted the invitation to participate in the GNOME Advisory Board meeting, together with Laurent Bigonville of our GNOME team. No report of that has been prepared as of yet (sorry about that), but we have both reported "live" to the rest of the team on IRC. Future Miscellaneous A couple of months ago I've mentioned that I had filed an application, as Debian representative, to participate in a working table to define software procurement rules for the Italian public administration. Good news: my application has been accepted, together with those of other well-known FOSS communities and organizations (e.g. KDE, FSFE). I'll keep you posted of how it goes. Let's go back to elect a new DPL and release Wheezy now,
Cheers.
PS the day-to-day activity logs for February and March 2013 are available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.20130 2,3

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."

15 March 2013

Richard Hartmann: Release Critical Bug report for Week 11

Current prediction remains at six weeks. This is a tad meh. The UDD bugs interface currently knows about the following release critical bugs: How do we compare to the Squeeze release cycle?
Week Squeeze Wheezy Diff
43 284 (213+71) 468 (332+136) +184 (+119/+65)
44 261 (201+60) 408 (265+143) +147 (+64/+83)
45 261 (205+56) 425 (291+134) +164 (+86/+78)
46 271 (200+71) 401 (258+143) +130 (+58/+72)
47 283 (209+74) 366 (221+145) +83 (+12/+71)
48 256 (177+79) 378 (230+148) +122 (+53/+69)
49 256 (180+76) 360 (216+155) +104 (+36/+79)
50 204 (148+56) 339 (195+144) +135 (+47/+90)
51 178 (124+54) 323 (190+133) +145 (+66/+79)
52 115 (78+37) 289 (190+99) +174 (+112/+62)
1 93 (60+33) 287 (171+116) +194 (+111/+83)
2 82 (46+36) 271 (162+109) +189 (+116/+73)
3 25 (15+10) 249 (165+84) +224 (+150/+74)
4 14 (8+6) 244 (176+68) +230 (+168/+62)
5 2 (0+2) 224 (132+92) +222 (+132/+90)
6 release! 212 (129+83) +212 (+129/+83)
7 release+1 194 (128+66) +194 (+128/+66)
8 release+2 206 (144+62) +206 (+144/+62)
9 release+3 174 (105+69) +174 (+105/+69)
10 release+4 120 (72+48) +120 (+72/+48)
11 release+5 115 (74+41) +115 (+74/+41)
12 release+6
13 release+7
14 release+8
15 release+9
16 release+10
17 release+11
18 release+12
Graphical overview of bug stats thanks to azhag:

Benjamin Mako Hill: Aaron Swartz MIT Memorial

On Tuesday, there was a memorial for Aaron Swartz held at the MIT Media Lab. Unfortunately, I am traveling this week and was unable to attend. As I wrote recently, I was close to Aaron. I am also, more obviously, close to MIT and the lab. It was important to me to participate in the memorial and I found a way to give a short talk with a video. I think the lab plans to post a recording of the whole event but I have put the video of my own remarks below (and online in WebM). If you prefer, you can also read the text of the remarks. <iframe allowfullscreen="" frameborder="0" height="315" src="http://www.youtube.com/embed/uYGoAJdE8jg" width="420"></iframe>

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

Richard Hartmann: The day the Reader died

...we stopped the singing. This may be irony:
No More Google Reader
from Google Operating System by Alex Chitu
via What's Hot in Google Reader

but the topic at hand remains serious. This is a stark reminder of why it's important to be able to get your data out of cloud services at a moment's notice and why you should always keep local backups of important data. Thankfully, Google is quite fair about this, as opposed to a lot of other large players. (As a side note, export of full data should be doable, but come with another layer of security like a grace period, password confirmation, verification email, or other means. Imagine someone gains temporary access to your account and exports all your digital life at once. And yes, I know how that relates to IMAP.) Google Reader has felt like a second class citizen for quite some time now, the removal of features to push Google+ and the slow updates for Android were two signs that didn't forebode well (Vim's spelling correction does not know "forbode", how weird is that)(turns out I'm simply stupid, see comments; thanks Jim). I can see how this move may make sense from Google's POV even though I am sad to see an old companion go. Anyway, the stats page of two of my accounts show how sadly I will miss Google Reader in two simple lines:
Since January 24, 2010 you have read a total of 59,253 items.
Since February 20, 2011 you have read a total of 215,285 items.

Farewell, my friend. PS: Maybe those petitions will sway them, but I won't get my hopes up. PS: Speaking of Google, I found this gem today; TMI.

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

Raphael Geissert: A bashism a week: assigning to variables and special built-ins

Assigning a value to a variable when executing a command is a way to populate the command's environment, without the variable assignment persisting after the command completes. This is not true, however, when a special built-in is the command being executed.

POSIX:2001 states that "Variable assignments specified with special built-in utilities remain in effect after the built-in completes".

Not only this is tricky because it depends on whether a utility is a special built-in or not, but the bash interpreter does not respect that behaviour of the POSIX standard. That is, special built-ins are not so "special" to the bash interpreter.

This leaves two things to take into account when assigning to a variable when executing a command: whether the command is a special built-in, and whether bash is interpreting the script.

Now, the list of special built-ins is rather short and it would be a bit unusual to perform variable assignments when calling them, except for some cases: "exec", "eval", "." (dot), and ":" (colon).

It is important to note that ":" and "true" differ in this regard; the former is a special built-in, the latter is just a utility. Watch out for this kind of differences when using ":" or "true" to nullify a command. E.g.

Compare
$ dash -c '
method=sed
# some condition or user setting ends up making:
method=true
# later:
foo=bar $method
echo foo: $foo'
foo:
To (redacted for brevity):
$ dash -c '
method=:
foo=bar $method
echo foo: $foo'
foo: bar

12 March 2013

Russ Allbery: Review: Commitment Hour

Review: Commitment Hour, by James Alan Gardner
Series: League of Peoples #2
Publisher: Eos
Copyright: April 1998
ISBN: 0-380-79827-1
Format: Mass market
Pages: 343
This is the second book in Gardner's League of Peoples universe, following Expendable, but it is largely unrelated to that novel apart from taking place in the same universe. Expendable follows the portion of humanity that has left Earth and embraced the universe and the advanced technology of the League. Committment Hour is set on Earth, in one of the remaining low-tech settlements that have become a backwater of humanity. Earth is governed by the Spark Lords, who appear to be a sort of scientific artistocracy empowered by the League of Peoples (Gardner gets into this more in later books in the series), but the community in this book is largely left alone. The protagonist of Committment Hour is Fullin, a resident of Tober Cove. The Tober Cove community has a very unusual interaction with gender. Every year, all inhabitants under the age of twenty (starting at the age of two) are taken away by what are viewed locally as gods. When they return, they have the opposite gender. They live their childhoods alternating gender every year, including a mandatory pregnancy (created on one of those trips by the gods) and childbirth. Then, at the age of twenty, rather than being gender-swapped like the other children, they choose the gender that they'll live with for the rest of their life. Fullin is (at least at the start of this book) currently male, but as the book opens on the eve of the day of his final gender committment, he's still undecided on what gender he'll choose. A review of this sort of book immediately requires a significant caveat: this story is all about social constructions of gender and about the implications of one specific transgender scenario. As a cisgender man who fits comfortably within society's normal gender construction, I'm not going to do the best job of judging how well it deals with those issues. It was on the long list for the Tiptree Award, which is a fairly good sign that it does okay, and a quick Internet search didn't uncover any significant dislike, but it's quite possible that I would miss places where it fell short. That said, I found Gardner's presentation of gender fascinating, in large part because Committment Hour is told from deeply inside Fullin's perspective and Gardner treats the Tober Cove gender swapping mostly as the unremarked normal. Fullin and the other inhabitants are quite aware that gender doesn't work for them the way that it does for everyone else, but they consider their gender process entirely sensible and can't imagine how weird life would be without the chance to experience both genders and to have carried a child. And Gardner has several aces up his sleeve that let him, by the end of the book, position Tobin Cove's experience as a very specific and local experience that would not necessarily generalize to gender in society at large, which I thought was an ingenious way to avoid overreaching and excessive generalization. This is not a gender utopia; Fullin's world is rather patriarchal and strongly gender essentialist. The village was, in the past, ruled by a sort of religious fantatic who laid down very firm rules about the roles of men and women, and the village largely stuck to them, but since anyone can choose which gender they want to become, the gender essentialism is also undermined in an interesting way. It becomes more akin to a choice of careers rather than an innate quality, albeit with only two choices and with a permanent decision at the age of 20. Gardner complicates the situation further by introducing a neuter gender (at least that's what the characters call it; by physical description, hermaphrodite would be a more accurate description). People actually have three choices on their twentieth birthday, and although the Patriarch who ruled Tober Cove outlawed and banished all "neuts," it's still a choice. Near the start of Committment Hour one of those who chose the "neut" gender returns to Tober Cove in the company of a Spark Lord (thus making "it" the pronoun used by the natives untouchable and somewhat immune to the normal local prejudice). Committment Hour follows Fullin and his close friend and possible future wife or husband through their last day before their committment hour, a day complicated by the incessant curiosity of the observing Spark Lord and his companion. Gardner has some rather neat world building and some revelations in store; this is the sort of book where, by the end, the curtain has been fully pulled back and the audience gets to peer into the machinery. But most of the book is about the social and societal structure of Tober Cove, about how it feels to swap back and forth between genders (and how specific that is to Tober Cove's unique situation), and how this complicates interpersonal interactions. It's an immersive sort of book that puts the reader in Fullin's head and shows his (and her) comfort with the Tober Cove culture and discomfort with the life choices that he faces as part of committment. As with everything by him I've read, Gardner's tone in writing is unique and can take a bit of getting used to. His stories tend to have a light, almost flippant attitude with frequent touches of absurdist humor, which can give the erroneous impression that he isn't taking his story seriously. But there is depth beneath that tone. Fullin may treat some questions flippantly, but he gives them serious thought and works through the consequences. And I was delighted by how Fullin completely scuttled the Spark Lord's arrogant assumption of superiority around his scientific understanding of things Fullin treats as mythological. Committment Hour is different fare than the typical SF novel, with a lot of focus on an unusual domesticity and small village politics. The technology and the world building are mostly saved for the climax, although are quite satisfying when they finally come. It's primarily a thought-provoking treatment of gender that avoids overreaching by grounding the story in a specific situation. I found it a bit slow in places, and occasionally wanted the characters to stop being stupid and stop dithering, but I ended up enjoying it rather more than I expected. Mildly recommended. Rating: 7 out of 10

11 March 2013

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

Axel Beckert: Rendering Markdown, Asciidoc and Friends automatically while Editing

Partially because of Markdown being Github s markup format of choice, I enjoy writing documents in simple markup formats more and more. There s though one common annoyance with these formats compared to writing plain HTML The Annoyance They need to be rendered (i.e. more or less compiled) before you can view your outpourings rendered, e.g. in the web browser. So the workflow usually is:
  1. Saving the current file in your favourite editor
  2. Switch to terminal with commandline
  3. Cursor up, Enter
  4. Switch to your favourite web browser
  5. Hit the reload button
Using a Specialized Editor with Live Preview One choice would be to use a specific editor with live rendering. The one I know in Debian (from Wheezy on) is ReText (Debian package retext). It supports Markdown and reStructuredText. But as with most simple GUI editors, I miss there many of the advanced editing commands possible with Emacs. Using Emacs Markdown Mode Then there is the Markdown Mode for Emacs (part of Debian s emacs-goodies-el package), where you can get a preview by pressing C-c C-c p. But for some reason this takes several seconds, opens a new buffer and window with the rendered HTML code and then starts (hardcoded) Firefox (which is not my preferred web browser). And if you do that a second time without closing Firefox first, it won t just reload the file but will open a new tab. You might think that just hitting reload should suffice. But no, the new tab has a different file name, so reload doesn t help. Additionally it may not use my preferred Markdown implementation. Meh. Well, I probably could fix all those issues with Markdown Mode, it s only Emacs Lisp. Heck, the called command is even configurable. But fixing at least four issues to fix one workflow annoyance? Maybe some other time, but not as long there are other nice choices Using inotifywait to Render on Write So everytime you save the currently edited file, you immediately want to rerender the same HTML file from it. This can be easily automated by using Linux inotify kernel subsystem which notices changes to the filesystem, and reports those to applications which ask for it. One such tool is inotifywait which can either output all or just specific events, or just exit if the first requested event occurs. With the latter it s easy to write a while loop on the commandline which regenerates a file after every write access. I use either Pandoc or Asciidoc for that since both generate full HTML pages including header and footer, but you can use that also with Markdown to render just the HTML body. Most browsers render it correctly anyway:
while inotifywait -q -e modify index.md; do pandoc -s -f markdown -t html -o index.html index.md; done
while inotifywait -q -e modify index.txt; do asciidoc index.txt; done
while inotifywait -q -e modify index.md; do markdown index.md > index.html; done
This solution is even editor- and build-system-agnostic (But not operating-system-agnostic.) inotifywait is part of inotify-tools, a useful set of commandline tools to interface with inotify. They re packaged in Debian as inotify-tools, too. Using mdpress for Markdown plus Impress.js based Slides The ruby-written mdpress is a special case of the previous case. It s a commandline tool to convert Markdown into Impress.js based slide shows and it has an option named --automatic which causes it to keep running and automatically update the presentation as soon as changes are made to the Markdown file. mdpress is not yet in Debian, but there s an ITP for it and Impress.js itself recently entered Debian as libjs-impress. Nevertheless, two dependencies (highlight.js, ITP ed, ruby-launchy, ITP ed) are still missing in Debian.

9 March 2013

Francesca Ciceri: Female participation in Debian (reloaded)

This dent by M nica Ram rez Arceda finally gave me the energy to update the statistics about female participation in Debian, first published by Margarita Manterola back in 2010. So, here the new graph updated to February 2013. Female participation in Debian graph The necessary caveat is that is not easy (at least for me) to tell the gender just based on first names, so the actual numbers may be higher. In addition, you should be warned that there are some contributions not easily traceable: it's the case of translators, graphic artists and documentation writers, as well as event organizers. For instance, Beatrice Torracca doesn't appear in these stats, and she is the co-coordinator of the Italian translation team and a long term Debian (and free software in general) contributor. There was a proposal to better track non packaging contributors, but no news on that front yet (at least that I'm aware of). Sources: You can find the data used as well as the updated graph here. TODO:

8 March 2013

Michael Stapelberg: Replying to Debian BTS messages in notmuch

Previously, my workflow regarding replying to bugreports outside my own packages was very uncomfortable: I first downloaded the mbox archive from the BTS, then imported that in claws-mail, hit reply all, remove submit@, add bugnumber@, then send the email. Therefore, I decided to hack up a little elisp function to automate this process for notmuch. It first downloads the message from the BTS, adds it to the notmuch database, then calls notmuch-mua-reply on the message and fixes the To: header:
;; Removes submit@bugs.debian.org from the recipients of a reply-all message.
(defun debian-remove-submit (recipients)
  (delq nil
	(mapcar (lambda (recipient)
		  (and (not (string-equal (nth 1 recipient) "submit@bugs.debian.org"))
		       recipient))
		recipients)))
(defun debian-add-bugrecipient (recipients bugnumber)
  (let* ((bugaddress (concat bugnumber "@bugs.debian.org"))
	 (addresses (mapcar (lambda (x) (nth 1 x)) recipients))
	 (exists (member bugaddress addresses)))
    (if exists
	recipients
      (append (list (list (concat "Bug " bugnumber) bugaddress)) recipients))))
;; TODO: msg should be made optional and it should default to the latest message in the bugreport.
;; NB: bugnumber and msg are both strings.
(defun debian-bts-reply (bugnumber msg)
  ;; Download the message to ~/mail-copy-fs/imported.
  (let ((msgpath (format "~/mail-copy-fs/imported/bts_%s_msg_%s.msg" bugnumber msg)))
    (let* ((url (format "http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=%s;mbox=yes;bug=%s" msg bugnumber))
	   (download-buffer (url-retrieve-synchronously url)))
      (save-excursion
	(set-buffer download-buffer)
	(goto-char (point-min)) ; just to be safe
	(if (not (string-equal
		  (buffer-substring (point) (line-end-position))
		  "HTTP/1.1 200 OK"))
	    (error "Could not download the message from the Debian BTS"))
	;; Delete the HTTP headers and the first "From" line (in order to
	;; make this a message, not an mbox).
	(re-search-forward "^$" nil 'move)
	(forward-char)
	(forward-line 1)
	(delete-region (point-min) (point))
	;; Store the message on disk.
	(write-file msgpath)
	(kill-buffer)))
    ;; Import the mail into the notmuch database.
    (let ((msgid (with-temp-buffer
		   (call-process "~/.local/bin/notmuch-import.py" nil t nil (expand-file-name msgpath))
		   (buffer-string))))
      (notmuch-mua-reply (concat "id:" msgid) "Michael Stapelberg <stapelberg@debian.org>" t)
      ;; Remove submit@bugs.debian.org, add <bugnumber>@bugs.debian.org.
      (let* ((to (message-fetch-field "To"))
	     (recipients (mail-extract-address-components to t))
	     (recipients (debian-remove-submit recipients))
	     (recipients (debian-add-bugrecipient recipients bugnumber))
	     (recipients-str (mapconcat (lambda (x) (concat (nth 0 x) " <" (nth 1 x) ">")) recipients ", ")))
	(save-excursion
	  (message-goto-to)
	  (message-delete-line)
	  (insert "To: " recipients-str "\n")))
      ;; Our modifications don t count as modifications.
      (set-buffer-modified-p nil))))
In case you want to get updates, you can find the latest version of this code in my configfiles git repository. To add a single message to the notmuch database and get its message ID, I have written this simple python script (using python-notmuch), located in ~/.local/bin/python-import.py:
#!/usr/bin/env python
# vim:ts=4:sw=4:et
import notmuch
import sys
if len(sys.argv) < 2:
    print "Syntax: notmuch-import.py <filename>"
    sys.exit(0)
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
(msg, status) = db.add_message(sys.argv[1])
print msg.get_message_id()
If you have any improvements, I d love to hear about it. If it s useful for you, enjoy.

Sylvain Le Gall: Always test your HD first

I just received a WD 500GB Blue, to replace the hard drive of my wife's computer. First thing after unpacking: start to test. And I was right to do it... there are bad blocks on it. WD 500GB DOA The story: I tend to do proactive replacement of hard drive, to avoid losing too much data or be in hurry when the current one fails. There are two ways to monitor a hard drive: Logcheck is pretty straightforward to install. It scans your log every two hours and send you a report of what is happening. It is not a very precise tool and you have to tune it a little bit to just send you what is relevant (install extra rules to ignore what you know is not of interest). Whenever you start to see log entry like that:
Jan 24 18:16:08 foo kernel: [ 1965.343980] ata5.00: exception Emask 0x50 SAct 0x39 SErr 0x800 action 0x6 frozen
Jan 24 18:16:08 foo kernel: [ 1965.343991] ata5.00: irq_stat 0x08000000, interface fatal error
Jan 24 18:16:08 foo kernel: [ 1965.344001] ata5: SError:   HostInt  
Jan 24 18:16:08 foo kernel: [ 1965.344036] ata5.00: failed command: READ FPDMA QUEUED
Jan 24 18:16:08 foo kernel: [ 1965.344055] ata5.00: cmd 60/08:00:18:31:44/00:00:1a:00:00/40 tag 0 ncq 4096 in
Jan 24 18:16:08 foo kernel: [ 1965.344059]          res 40/00:2c:e6:c2:fd/00:00:26:00:00/40 Emask 0x50 (ATA bus error)
Jan 24 18:16:08 foo kernel: [ 1965.344071] ata5.00: status:   DRDY  
Jan 24 18:16:08 foo kernel: [ 1965.344081] ata5.00: failed command: WRITE FPDMA QUEUED
It is a good time to think about changing your hardrive -- but it is maybe too late. Smartmontools (aka smartd) is dedicated tool to monitor hard drives and do a good job. I think it is not installed by default in Debian, but it should be. It scans your hard drive for SMART capabilities and monitor the health of the HD using internal tools. In the case of bad blocks, you will start to see entry like that:
Feb 17 14:05:17 bar smartd[1268]: Device: /dev/sda [SAT], 1 Currently unreadable (pending) sectors
Feb 17 14:35:17 bar smartd[1268]: Device: /dev/sda [SAT], 1 Currently unreadable (pending) sectors
Obviously when you see this log, it is also a good time to change your hard drive. In the case of my wife's HD, I just got data from logcheck. It means that the error is not that important (transient failure, something is wrong but the HD can cope with it). But I still decided to get a new one for my wife. Whenever, I receive a new drive, the first thing I do is to check it for errors. You can do that using the program badblocks in write mode. It takes ages to test (count up to 1 day for 1TB on USB), but at the end you know that you have a good candidate -- where it is worth install your data. You just have to follow this procedure
  1. dmesg grep sd
  2. try to find what drive is the one you want to test in the output of 1.
  3. cfdisk /dev/sdX, sdX being the drive you want to test
  4. check that what you see in cfdisk is what you expect to test: right name and capacity for the drive
  5. sudo badblocks -wvs /dev/sdX
  6. run sudo tail -f /var/log/syslog in parallel just in case
  7. wait
If some errors appears in /var/log/syslog, you know something bad is happening. Whenever you have a single failing block, don't think it is ok. It is NOT ok for a HD to start its life with failing blocks. In this case, repack the drive and send it for replacement ASAP. In the case of my hard drive: smartd mail:
The following warning/error was logged by the smartd daemon:
Device: /dev/sda [SAT], 15 Currently unreadable (pending) sectors
syslog entries:
Mar  2 20:52:57 foo kernel: [ 8317.419715] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar  2 20:52:57 foo kernel: [ 8317.419724] ata4.00: irq_stat 0x40000008
Mar  2 20:52:57 foo kernel: [ 8317.419732] ata4.00: failed command: READ FPDMA QUEUED
Mar  2 20:52:57 foo kernel: [ 8317.419747] ata4.00: cmd 60/80:00:00:af:08/00:00:28:00:00/40 tag 0 ncq 65536 in
Mar  2 20:52:57 foo kernel: [ 8317.419750]          res 41/40:00:65:af:08/00:00:28:00:00/40 Emask 0x409 (media error) <F>
Mar  2 20:52:57 foo kernel: [ 8317.419758] ata4.00: status:   DRDY ERR  
Mar  2 20:52:57 foo kernel: [ 8317.419764] ata4.00: error:   UNC  
Mar  2 20:52:57 foo kernel: [ 8317.423959] ata4.00: configured for UDMA/133
I am not blaming any particular brand (like Western Digital), all computer parts I have ever bought had to follow the same procedure and it is a known fact that computer parts as a non-zero percentage of chance to be DOA (dead on arrival) or after a few weeks. But as a consumer you should be aware of that and take action to avoid spending 10h configuring your computer to see it failing after a week... The waste of time to test is a win on the long term.

Petter Reinholdtsen: First Skolelinux / Debian Edu Squeeze update released

Last Sunday, 2013-03-03,, Holger Levsen announced the first update of Skolelinux / Debian Edu based on Debian Squeeze. This is the first update since the initial release 2012-03-11. This is the release announcement email from Holger:
Hi, it's my pleasure to announce the immediate availability of Debian Edu 6.0.7+r1 ("Debian Edu Squeeze"). Debian Edu 6.0.7+r1 is an incremental update to Debian Edu 6.0.4+r0, containing all the changes between Debian 6.0.4 and 6.0.7 as well Debian Edu specific bugfixes and enhancements. See below (in this mail) for the full list of (edu) changes. Please see http://www.debian.org/News/2012/20120311 for more information on "Debian Edu Squeeze". Images are available for download at http://ftp.skolelinux.org/skolelinux-cd/ md5sums:
1fe79eb4f0f9ae1c58fc318e26cc1e2e debian-edu-6.0.7+r1-CD.iso
a6ddd924a8bd9a1b5ca122e8fe1c34ec debian-edu-6.0.7+r1-DVD.iso
ac6c72cd7925ccec51bfbf58e2a7c69c debian-edu-6.0.7+r1-source-DVD.iso sha1sums:
a4b58233b672a99c7df8dc24fb6de3327654a5c3 debian-edu-6.0.7+r1-CD.iso
9b524915e0ff2aa793f13d93123e5bd2bab2dbaa debian-edu-6.0.7+r1-DVD.iso
43997614893fc5e9e59ad6ce066b05d07fd836fa debian-edu-6.0.7+r1-source-DVD.iso These images are suitable for amd64+i386. Changes for Debian Edu 6.0.7+r1 Codename "Squeeze", released 2013-03-03:
  • sitesummary was updated from 0.1.3 to 0.1.8
    • Make Nagios configuration more robust and efficient
    • Comply with 3.X kernel
  • debian-edu-doc from 1.4~20120310~6.0.4+r0 to 1.4~20130228~6.0.7+r1
    • Minor updates from the wiki
    • Danish translation now complete
  • debian-edu-config from 1.453 to 1.455
    • Fix /etc/hosts for LTSP diskless workstations. Closes: #699880
    • Make ltsp_local_mount script work for multiple devices.
    • Correct Kerberos user policy: don't expire password after 2 days. Closes: #664596
    • Handle '#' characters in the root or first users password. Closes: #664976
    • Fixes for gosa-sync:
      • Don't fail if password contains "
      • Don't disclose new password string in syslog
    • Fixes for gosa-create:
      • Invalidate libnss cache before applying changes
      • Multiple failures during mass user import into GOsa
      • gosa-netgroups plugin: don't erase entries of attribute type "memberNisNetgroup". Closes: #687256
      • First user now uses the same Kerberos policy as all other users
    • Add Danish web page
  • debian-edu-install from 1.528 to 1.530
    • Improve preseeding support and documentation
End-user documentation in English is available at http://wiki.debian.org/DebianEdu/Documentation/Squeeze/ - translations to French, Italian, Danish and German are available in the debian-edu-doc package. (Other languages could use your help!) If you want to contribute to Debian Edu, please join our mailinglist debian-edu@lists.debian.org!
I am very happy to see the fruits of a year of hard work. :)

7 March 2013

Vincent Sanders: Man cannot discover new oceans unless he has the courage to lose sight of the shore

Continuing with my whirlwind introduction to NetSurf Development now is the time to start examining the code, how its arranged and how to interact with the existing developers.

The way the NetSurf source is structured is around the idea of the frontends each being a native browser. While this implies that there are nine separate browsers that happen to share a common code base the separation is not quite that well defined.

Each frontend provides the OS entry point (the main() function in a c program) and calls out to standard browser initialisation entry function netsurf_init() and then starts running the browsers main dispatch loop with netsurf_main_loop() when that exits the frontend cleans up with netsurf_exit().

The frontends provide a large selection of functions which are called from the core code. These routines run from running the event scheduler through to rendering graphics and text.
Finding your way aroundThe browsers directory layout is fairly shallow consisting of some Makefiles, the nine frontend directories and eleven others.

The Makefiles are GNU make and represent a pretty straightforward linear build system. We do not use recursive make or autotools. There are plans to use the core buildsystem that all the other components use.

The frontend directories contain the code for the frontend and the makefile fragments to build them which are included by the top level Makefile.

In addition there is:
desktop
This contains the non frontend specific code that actually behaves like a browser. For example desktop/netsurf.c contains the three primary functions we outlined in the introduction. You will also find much of the function and data structures interfaces the frontend must provide. It is unlikely someone new to the project will need to change anything in here (there be dragons) but is an important set of routines.
utils
Here you will find the utility and compatibility interfaces, things like url handling, logging, user messages, base64 handling. These are utility interfaces that do not justify splitting out their functionality to a separate library but are useful everywhere. Changing an interface in here would likely result in a major refactor.
For example one quirk is the logging macro was created before varadic C preprocessor macros were universal so it must be called as LOG(("hello %s world", world_type)) e.g. with double brackets. Fixing this and perhaps improving the logging functionality would be "nice" but the changes would be massive and potentially conflict with ongoing work.
content
This contains all the core code to handle contents i.e. html, css, javascript, images. The handling includes retrieval of the resources from URI , correct caching of the received objects and managing the objects state. It should be explicitly stated that the content handlers are separate and use this core functionality. The actual content handlers to deal with object contents such as the routines to decode image files or render html are elsewhere.
image
This is where the content handlers for the various image types are kept. The majority of these image types (jpeg, png, webp, gif, bmp) use a standard library to perform the actual decode (libjpeg, libpng etc.). One special feature used by most image handlers is that of a decoded image cache which is distinct and separate from the content cache.
The decoded image cache manages decoding of the source images (the jpegs and pngs) into frontend specific "render" bitmaps. For example the gtk frontend keeps the decoded images as a cairo surface ready for immediate plotting.
The cache uses a demand based (when the browser actually displays the image) just in time strategy which has been carefully balanced, with real world input, to reduce the overhead of unnecessary image decoding and processing against memory usage for the render bitmaps.
css
The css content handlers provide for the processing of css source text and use the NetSurf libcss library to process into a bytecode suitable for applying style selection at render time.
javascript
The javascript handlers (strictly speaking this should be named the "script" directory as all types of script are handled here) provide basic functionality to bind a javascript engine to the rest of the browser, principally the Document Object Model (DOM) accessed with libdom. The only engine that currently has bindings is Spidermonkey from the Mozilla foundation.
render
This is the heart of the browser containing the content handler for html (and plain text). This handler deals with:
  • Acquiring the html.
  • Running the base parser as data arrives which generates the DOM and hence DOM events from which additional resource (stylesheets etc.) fetches are started.
  • Deal with script loading
  • Constructing the box model used for layout
  • Performing the Layout and rendering of the document.
Because this module has so many jobs to do it has inevitably become very complex and involved, it is also the principle area of core development . Currently NetSurf lacks a dynamic renderer so changes made by scripts post document load event are not visible. This also has the side effect that the render is only started after the DOM has finished construction and all the resources on a page have completed their fetch which can lead to undesirable display latency.
Docs
Documentation about building and using NetSurf. If anyone wants a place to start improving NetSurf, this is it, it is very incomplete. It must be noted this is not where dynamically generated documentation is found. For the current Doxygen output the best place to look is the most recent build on the Continuous Integration system.
resources
These are runtime resources which are common to all frontends. To be strictly correct they may be the sources which get converted into runtime resources e.g. The FatMessages file which is teh message text for all frontends in all languages, this gets processed at build time into separate files ready.
!NetSurf
This is another resources directory and technically the resources for the riscos frontend. The naming and reliance on this directory are historical. To allow the RISC OS frontend to be run directly from the source directory and an inability of RISC OS to process symbolic links most common runtime resources end up in here and linked to from elsewhere.
test
These are some basic canned test programs and files, principally to test elements of the utils and perform specific exercise of various javascript components.
Getting started
Once a developer has a checked out working build environment and can run the executable for their chosen frontend (and maybe done some web browsing :-) it is time to look at contributing.

If a developer does not have a feature or bug in mind when they begin the best way to get started is often to go bug hunting. The NetSurf bugtacker has lots to choose from unfortunately. Do remember to talk to us (IRC is the best bet if you are bug hunting) about what you are up to but do not be impatient. Some of those bugs are dirty great Shelob types and are not being fixed because even the core developers are stumped!

When first getting going I cannot recommend reading the code enough, this seems to be a skill that many inexperienced open source developers have yet to acquire, especially if they are from a predominately proprietary development background. One wonderful feature of open source software is you get to see all of it, all the elegant nice code and all the "what the hell were they thinking" code too.

One important point is to use your tools well the source is in git, if you learn how to use git well you will gain a skill that is readily portable, not just for NetSurf. And not just revision control tools, learn to use your debugger well and tools like valgrind. Those skills will replay the time spent learning them themselves many times over.

When using git one thing to remember is commit early and often, it does not matter if you have lots of junk commits and dead ends, once you have something viable you can use
git rebase --interactive
and rewrite it all into a single sensible set of commits. Also please do remember to develop on a branch, or if you did not
git pull --rebase
is your friend to avoid unnecessary merges.
Playing nicely with othersThe NetSurf community is a small band of unpaid volunteers. On average we manage to collectively put in, perhaps, ten hours a week with the occasional developer weekend where we often manage over twenty hours each.

The result is that developer time is exceptionally valuable, add in a mature codebase with its fair share of technical debt and you get a group who, when they get to work on NetSurf, are incredibly busy. To be fair we are just like every other small open source project in that respect.

What this means to a new contributor is that they should try and do their homework before asking the obvious questions. The documentation is there for a reason and in spite of its obvious shortcomings please read it!

When asking questions it should be noted that currently the majority of active contributors are in the Europe so if you visit the IRC channel or post questions to lists the time difference is something to keep in mind.

I carefully said contributor above and not developer, users trying the CI builds and reporting results are welcome...as long as they report useful bugs to the bug tracker. Simon Tatham has produced an excellent resource on this subject.

Also we are always happy to receive translations to new languages (diff against the FatMessages file would be outstandingly useful but anything is welcome), artwork, documentation. Just recall what I mentioned about busy developers. Surest way to get us to see something is the development mailing list, you will probably get a reply, though I will not promise how fast!

Some of the more common mistakes when interacting with the community are:
In conclusion
Hopefully this has been of some use although I had hoped to cover more and provide deeper insights and advice on the codebase but there is only so much generalisation to be done before it is just easier for the developer to go read the code for themselves.

I look forward to lots of new contributions :-) though I fear this may all end up as more of a crib sheet for next time we do GSOC, time will tell.

5 March 2013

Russell Coker: Kogan Mobile

Kogan Mobile is the newest virtual telco in Australia [1]. They resell Telstra 3G (not NextG or LTE) and while their coverage isn t as good as the full Telstra service it s more than adequate for my needs as they provide 3G coverage to 97% of the population and 2G+3G coverage to 98.5%. Their coverage is probably a lot better than Three who had the worst record of network coverage in Australia yet managed to always provide coverage where I wanted it I was a happy Three customer for more than 6 years. Kogan s main selling point is that they offer unlimited calls to Australian mobile phones and land-lines and unlimited SMS for a pre-paid fee of only $300 per annum ($25 per month on average). My parents have been getting unpleasantly large phone bills which have considerably more than $25 of calls to mobile phones every month so an obvious solution for them is to sign up for a Kogan mobile phone and use it for all such calls. There are other ways my parents could save money on calls (such as VOIP) but a mobile phone is easiest and offers other benefits such as running Android apps (when compared to using a non-smart phone). 6G of Data! Kogan also offers 6G of data per month, the down-side to this is that they bill in 1MB increments per session . I was worried that this might be per TCP connection or something else silly but I decided to sign my parents up for it as they aren t going to use a lot of data (they claim that they don t want to use the Internet on their phone but I know better). I ve done some tests on the SIM I got for my parents. For testing purposes I installed the Kogan SIM in my wife s new Nexus 4 and had it provide Wifi net access to my phone while we were playing Ingress. So far after 2 days which involved a reasonable amount of Ingress (I reached level 7) as well as all the usual stuff that happens in the background for two phones (checking email, news, weather, etc) Kogan considers that 177MB have been used out of the 6144MB for the month, which means that even with what is an unusual amount of traffic for us the account in question still isn t going to use half the quota for the month. Now that 10 days have elapsed with less intense usage Kogan considers that a total of 1373MB have been used.
days received sent Kogan
2 127.24 41.54 177
10 959.39 299.6 1373
Kogan also don t seem to mention whether they bill for transmitted data. I used the 3G Watchdog app to measure the amount data transferred, the above table has the amounts of data that 3G Watchdog considers were sent and received along with the amount that is listed by the Kogan Android app. My past experience with 3G Watchdog and Virgin Mobile is that it s usually quite accurate but has been over-reporting the data transfers recently (I think that Virgin is only billing me for downloads while 3G Watchdog counts uploads). So the relatively small difference between the 3G Watchdog report and what Kogan thinks I ve done means that either rounding the session up to the nearest meg doesn t make any significant difference (which would imply that a session can be a long time) or that Kogan isn t counting uploaded data and the session rounding up only adds about 40% to the total recorded transfer. My current plan with Virgin Mobile gives me 1.5G per month of quota, so as long as Kogan s rounding doesn t increase the recorded data transfer by a factor of 4 I will still be able to transfer more data with Kogan while paying less. One disadvantage of using Kogan is that I might have to tweak programs like my email program to poll less frequently to avoid excessive session charges (a program polling every 5 minutes would use up the 6G quota in 21 days if each poll counted as a session) although current tests indicate that this won t be necessary. But the up-side is that there are no extra fees with Kogan, they merely restrict data access for my use and that of most people I know it s better to have data access cut off than to receive a large bill. The Kogan Android App Kogan has an Android app that will give the status of your account and allow you to change the plan etc. This is quite nice but one major disadvantage is that it s also a sales app for the Kogan online store. This is bad for the user as some aspects of what I consider the core functionality are limited (for example there s no way to force a poll of the data usage count or determine how current the data is). But there s an obvious advantage to Kogan in providing a way to sell their goods that is going to be used by every customer of Kogan Mobile. The sales part of the app isn t very functional IMHO, it doesn t seem to have basic functionality such as sorting a list of items by price. Benefits of Kogan 6G of data is a lot! $300 per annum is quite cheap, anyone who makes any serious use of phones will be paying more than that in Australia. Lack of extra fees means that there is little need to restrict net access. I can risk getting cut off near the end of the month but I can t risk the potential for hundreds of dollars in excess fees. The Kogan app shows me the data used so I will probably uninstall 3G Watchdog, having one less program running is a good thing. You get a free SIM (value $5) when you buy a phone from Kogan. Disadvantages of Kogan They are new to the Telco business and admit that their customer service is lacking due to unexpected demand. If you order a SIM now they state that it will arrive in April. Apparently they are deliberately delaying orders because they can t cope with demand. The included call quota doesn t include international calls. While unlimited free calls in Australia is great if you make many international calls then this could end up costing you more. Other mobile telcos such as Lebara offer good deals for International calls, it could be an option to use a Lebara SIM with an old non-smart phone while using Kogan for your smart phone. I am concerned about the lack of detail about how data is accounted. If the definition of a session changes then 6G could turn out not to be enough. As Kogan is reselling a Telstra service it is possible that Telstra could change the deal without Kogan being able to stop them. Conclusion I will move my phone and my wife s phone to Kogan ASAP. My general idea is to sign us up for Kogan about 2 weeks apart, so if one phone runs out of the 6G data quota then the other phone can be used as a Wifi access point for 2 weeks. If the phones don t both have their quota end at the same time then there is less chance of both phones running out during a high traffic month.

4 March 2013

Robert Collins: subunit version 2 progress

Subunit V2 is coming along very well. Current status: Remaining things to do:

Next.

Previous.