Tag Archives: Debian

About to retire from Debian

I got involved with Debian development in, I think, 1998. In early 1999, I was accepted as a Debian developer. The next two or three years were a formative experience for me. I learned both software engineering and massively international collaboration; I also made two major contributions to Debian that are still around (of this, I am very proud). In consequence, being a Debian developer became a part of my identity. Even after my activity lessened more than a decade ago, after I no longer was a carefree student, it was very hard for me to let go. So I’ve hung on.

Until now. I created my 4096-bit GPG key (B00B474C) in 2010, but never got around to collecting signatures to it. I’ve seen other people send me their key transition statements, but I have not signed any keys based on them. It just troubles me to endorse a better secured key based on the fact that I once verified a less secure key and I have a key signature chain to it. For this reason, I have not made any transition statements of my own. I’ve been meaning to set up key signing meetings with Debian people in Finland. I never got around to that, either.

That, my friends, was my wakeup call. If I can’t be bothered to do that, what business do I have clinging on to my Debian identity? My conclusion is that there is none.

Therefore, I will be retiring from Debian. This is not a formal notice; I will be doing the formal stuff (including disposing of my packages) separately in the appropriate forums in the near future.

I agree with the sentiment that Joey Hess wrote elsewhere: “It’s become abundantly clear that this is no longer the project I originally joined”. Unlike Joey, I think that is a good thing. Debian has grown, a lot. It’s not perfect, but like my elementary-school teacher once said: “A thing that is perfect was not made by people.” Just remember to continue growing and getting better.

And keep making the Universal Operating System.

Thank you, all.

Licentiate Thesis is now publicly available

My recently accepted Licentiate Thesis, which I posted about a couple of days ago, is now available in JyX.

Here is the abstract again for reference:

Kaijanaho, Antti-Juhani
The extent of empirical evidence that could inform evidence-based design of programming languages. A systematic mapping study.
Jyväskylä: University of Jyväskylä, 2014, 243 p.
(Jyväskylä Licentiate Theses in Computing,
ISSN 1795-9713; 18)
ISBN 978-951-39-5790-2 (nid.)
ISBN 978-951-39-5791-9 (PDF)
Finnish summary

Background: Programming language design is not usually informed by empirical studies. In other fields similar problems have inspired an evidence-based paradigm of practice. Central to it are secondary studies summarizing and consolidating the research literature. Aims: This systematic mapping study looks for empirical research that could inform evidence-based design of programming languages. Method: Manual and keyword-based searches were performed, as was a single round of snowballing. There were 2056 potentially relevant publications, of which 180 were selected for inclusion, because they reported empirical evidence on the efficacy of potential design decisions and were published on or before 2012. A thematic synthesis was created. Results: Included studies span four decades, but activity has been sparse until the last five years or so. The form of conditional statements and loops, as well as the choice between static and dynamic typing have all been studied empirically for efficacy in at least five studies each. Error proneness, programming comprehension, and human effort are the most common forms of efficacy studied. Experimenting with programmer participants is the most popular method. Conclusions: There clearly are language design decisions for which empirical evidence regarding efficacy exists; they may be of some use to language designers, and several of them may be ripe for systematic reviewing. There is concern that the lack of interest generated by studies in this topic area until the recent surge of activity may indicate serious issues in their research approach.

Keywords: programming languages, programming language design, evidence-based paradigm, efficacy, research methods, systematic mapping study, thematic synthesis

A milestone toward a doctorate

Yesterday I received my official diploma for the degree of Licentiate of Philosophy. The degree lies between a Master’s degree and a doctorate, and is not required; it consists of the coursework required for a doctorate, and a Licentiate Thesis, “in which the student demonstrates good conversance with the field of research and the capability of independently and critically applying scientific research methods” (official translation of the Government decree on university degrees 794/2004, Section 23 Paragraph 2).

The title and abstract of my Licentiate Thesis follow:

Kaijanaho, Antti-Juhani
The extent of empirical evidence that could inform evidence-based design of programming languages. A systematic mapping study.
Jyväskylä: University of Jyväskylä, 2014, 243 p.
(Jyväskylä Licentiate Theses in Computing,
ISSN 1795-9713; 18)
ISBN 978-951-39-5790-2 (nid.)
ISBN 978-951-39-5791-9 (PDF)
Finnish summary

Background: Programming language design is not usually informed by empirical studies. In other fields similar problems have inspired an evidence-based paradigm of practice. Central to it are secondary studies summarizing and consolidating the research literature. Aims: This systematic mapping study looks for empirical research that could inform evidence-based design of programming languages. Method: Manual and keyword-based searches were performed, as was a single round of snowballing. There were 2056 potentially relevant publications, of which 180 were selected for inclusion, because they reported empirical evidence on the efficacy of potential design decisions and were published on or before 2012. A thematic synthesis was created. Results: Included studies span four decades, but activity has been sparse until the last five years or so. The form of conditional statements and loops, as well as the choice between static and dynamic typing have all been studied empirically for efficacy in at least five studies each. Error proneness, programming comprehension, and human effort are the most common forms of efficacy studied. Experimenting with programmer participants is the most popular method. Conclusions: There clearly are language design decisions for which empirical evidence regarding efficacy exists; they may be of some use to language designers, and several of them may be ripe for systematic reviewing. There is concern that the lack of interest generated by studies in this topic area until the recent surge of activity may indicate serious issues in their research approach.

Keywords: programming languages, programming language design, evidence-based paradigm, efficacy, research methods, systematic mapping study, thematic synthesis

A Licentiate Thesis is assessed by two examiners, usually drawn from outside of the home university; they write (either jointly or separately) a substantiated statement about the thesis, in which they suggest a grade. The final grade is almost always the one suggested by the examiners. I was very fortunate to have such prominent scientists as Dr. Stefan Hanenberg and Prof. Stein Krogdahl as the examiners of my thesis. They recommended, and I received, the grade “very good” (4 on a scale of 1–5).

The thesis has been accepted for publication published in our faculty’s licentiate thesis series and will in due course appear has appeared in our university’s electronic database (along with a very small number of printed copies). In the mean time, if anyone wants an electronic preprint, send me email at antti-juhani.kaijanaho@jyu.fi.

Figure 1 of the thesis: an overview of the mapping process
Figure 1 of the thesis: an overview of the mapping process

As you can imagine, the last couple of months in the spring were very stressful for me, as I pressed on to submit this thesis. After submission, it took me nearly two months to recover (which certain people who emailed me on Planet Haskell business during that period certainly noticed). It represents the fruit of almost four years of work (way more than normally is taken to complete a Licentiate Thesis, but never mind that), as I designed this study in Fall 2010.

Figure 8 of the thesis: Core studies per publication year
Figure 8 of the thesis: Core studies per publication year

Recently, I have been writing in my blog a series of posts in which I have been trying to clear my head about certain foundational issues that irritated me during the writing of the thesis. The thesis contains some of that, but that part of it is not very strong, as my examiners put it, for various reasons. The posts have been a deliberately non-academic attempt to shape the thoughts into words, to see what they look like fixed into a tangible form. (If you go read them, be warned: many of them are deliberately provocative, and many of them are intended as tentative in fact if not in phrasing; the series also is very incomplete at this time.)

I closed my previous post, the latest post in that series, as follows:

In fact, the whole of 20th Century philosophy of science is a big pile of failed attempts to explain science; not one explanation is fully satisfactory. [...] Most scientists enjoy not pondering it, for it’s a bit like being a cartoon character: so long as you don’t look down, you can walk on air.

I wrote my Master’s Thesis (PDF) in 2002. It was about the formal method called “B”; but I took a lot of time and pages to examine the history and content of formal logic. My supervisor was, understandably, exasperated, but I did receive the highest possible grade for it (which I never have fully accepted I deserved). The main reason for that digression: I looked down, and I just had to go poke the bridge I was standing on to make sure I was not, in fact, walking on air. In the many years since, I’ve taken a lot of time to study foundations, first of mathematics, and more recently of science. It is one reason it took me about eight years to come up with a doable doctoral project (and I am still amazed that my department kept employing me; but I suppose they like my teaching, as do I). The other reason was, it took me that long to realize how to study the design of programming languages without going where everyone has gone before.

Debian people, if any are still reading, may find it interesting that I found significant use for the dctrl-tools toolset I have been writing for Debian for about fifteen years: I stored my data collection as a big pile of dctrl-format files. I ended up making some changes to the existing tools (I should upload the new version soon, I suppose), and I wrote another toolset (unfortunately one that is not general purpose, like the dctrl-tools are) in the process.

For the Haskell people, I mainly have an apology for not attending to Planet Haskell duties in the summer; but I am back in business now. I also note, somewhat to my regret, that I found very few studies dealing with Haskell. I just checked; I mention Haskell several times in the background chapter, but it is not mentioned in the results chapter (because there were not studies worthy of special notice).

I am already working on extending this work into a doctoral thesis. I expect, and hope, to complete that one faster.

Dear Lazyweb: Does this software exist?

I’ve been wondering if the following kind of testing management software exists (preferably free software, of course).

It would allow one to specify a number of test cases. For each, one should be able to describe preconditions, testing instructions and expected outcome. Also, file attachments should be supported in case a test case needs a particular data set.

It would publish a web site describing each test case.

A tester (who in the free software world could be anyone) would take a test case, follow the instructions given and observe whatever outcome occurs. The tester would then file a test report with this software, either a terse success report or a more verbose failure report.

The software should maintain testing statistics so that testers could easily choose test cases that have a dearth of reports.

As a bonus, it would be nice if the software could submit a failure report as a bug report .

(Note that this would be useful for handling the sort of tests that cannot be automated. There are many good ways already to run automated test suites.)

dctrl-tools translations

dctrl-tools 1.14 (targeting squeeze) has the following incomplete translations (as of right now in git):

ca: 89 translated messages, 4 fuzzy translations, 18 untranslated messages.
cs: 108 translated messages, 1 fuzzy translation, 2 untranslated messages.
de: 111 translated messages.
en_GB: 89 translated messages, 4 fuzzy translations, 18 untranslated messages.
es: 89 translated messages, 4 fuzzy translations, 18 untranslated messages.
fi: 111 translated messages.
fr: 108 translated messages, 1 fuzzy translation, 2 untranslated messages.
it: 65 translated messages, 8 fuzzy translations, 38 untranslated messages.
ja: 89 translated messages, 4 fuzzy translations, 18 untranslated messages.
pl: 49 translated messages, 2 fuzzy translations, 60 untranslated messages.
pt_BR: 89 translated messages, 4 fuzzy translations, 18 untranslated messages.
ru: 108 translated messages, 1 fuzzy translation, 2 untranslated messages.
sv: 84 translated messages, 4 fuzzy translations, 23 untranslated messages.
vi: 89 translated messages, 4 fuzzy translations, 18 untranslated messages.

I have put the relevant pot and po files up. This is not an archival URI, but I’ll keep it available long enough for this.

Submissions through the BTS are accepted, as usual.

Debian developers and others with collab-maint access may, if they wish, push their updates directly to the Git repository. Please use the maint-2.14 branch and please read the README.

I will NOT be gathering translations from Rosetta.

All contributors and committers are asked to declare whether they can affirm the Developer’s Certificate of Origin. The commit tag Signed-off-by is, by convention, interpreted as an affirmation of that document by the person identified on that tag line.

New Netnews (Usenet) RFCs

The RFC editor has finally released

  • K. Murchison, Ed., C. Lindsey, D. Kohn: Netnews Article Format. RFC 5536, November 2009.
  • R. Allbery, Ed., C. Lindsey: Netnews Architecture and Protocols. RFC 5537, November 2009.

They obsolete the venerable RFC 1036 (Standard for Interchange of USENET Messages) from December 1987.

The new RFCs are the work of the IETF working group USEFOR, chartered November 1997 and concluded March 2009. I’ve heard it was not quite the longest lived IETF working group ever. (I personally missed the group by a couple of months, since I started following Netnews and NNTP standardization in April, due to Alue.)

Both RFCs are on the Standards Track, currenlty as Proposed Standards. In my opinion, they are a huge improvement over both RFC 1036 and son-of-1036 (which will probably be published as a Historic RFC real soon now).

Socialized vaccination – a narrative

Such was the scene I arrived at on Wednesday last week at the municipal health center at Kyllö, Jyväskylä, Finland. A queue extended a hundred meters beyond the door. It was not hard to guess what it was about, as it had been announced that the pandemic influenza A/H1N1 vaccine would be administered there to people in specific risk groups from 10 am to 3:30 pm.

I should explain here the Finnish health care setup. There are three parallel systems – a comprehensive public health care system maintained by the municipalities to standards set by the state, a network of private for-profit health care providers, and a national foundation dedicated to university student health care. Employers are required by law to provide a minimal level of health care to their employees, and most of them also provide, free of charge to the employees, access to near-comprehensive general-practice-level care; most employers buy this service from the for-profit providers. The public system suffers from resource starvation at the general-practice level but provides excellent care in the central hospitals that handle the difficult cases.

Anyway, the H1N1 vaccine is only available through the public system and through the foundation – free of charge if you qualify for the vaccine, and no amount of money buys it for you in this country if you don’t. Thus, I and many others, normally cared by the employee services, found ourselves queuing up at a public health care institute. And clearly, the public health care system was overwhelmed on that first day.

When I entered the queue, its tail was a traffic hazard. Fortunately, the queue moved faster than new people arrived thereafter, and the hazard ended. The queue moved surprisingly fast – it took me one hour to advance the 100 meters to the door. Even so, this was a failure in the system – there is no good reason to have people with underlying illnesses (and we all had them, to qualify for the vaccine) stand around in freezing cold weather for an hour!

Once, a nurse came and asked us if any of us was 63 years old or older. Apparently no-one was, since no-one was asked to leave (they will be vaccinated later). Later, another nurse asked everyone in the queue outside to show their KELA cards – KELA is the national health insurance system, and its card carries information about extra coverage one qualifies for due to underlying illnesses.

Eventually, I reached the door. Two guards stopped anyone who tried to enter directly, sidestepping the queue, and let in only those who had legitimate business other than vaccination. The main hall was full of people, and I quickly realized that the queue took a full circle inside the hall to reach the multiplexing point. It took me another hour to slowly advance my way though the hall. At the multiplexing point, I was asked to wait a bit, and then I was assigned a vaccination room and a waiting number.

Some twenty minutes later I was called in. The vaccination room I was assigned to was a nurse’s office. Two nurses were there, one who would administer the vaccine, and another at the computer, to keep a record. I gave them my KELA card, and shed my coat and my outer shirt, and bared my left shoulder. I was quickly given the pandemic vaccine; there was no question I was qualified for it, not with my obesity being obvious.

Then they asked what my diagnosis was. “Prmarily I’m here because of my obesity,” I said. “But I also have paroxysmal atrial fibrillation.”

“That’s not what your KELA card says,” accused the nurse at the computer.

“The diagnosis is so new,” I countered. “There has been no time to do the paperwork for KELA.” (And indeed, I later learned, it would come up in my next checkup in the spring.)

They stared at each other.

“I can show you my prescriptions,” I said, making no move for them.

Stares.

I stared back.

“Do you want the seasonal vaccine or not?” asked the nurse with the injectors.

I lauged briefly. “I might as well.” It had, honestly, never crossed my mind that I might qualify.

She injected me on my right shoulder. “You should stay in out there for ten minutes.”

I picked up my clothes and found the cafeteria with coffee and pastry.

Then the real fun started. Next day, I woke with horrible upper back pain. The thermometer showed mild fever; but since i didn’t have any respiratory symptoms, I decided to go to work. In the evening, turning in bed was excruciatingly painful. It took days for the pain to subside.

I left the building three hours after I arrived at the end of the queue. What? You think that’s excessive? So do I and many others; queuing feels so Soviet Union! But honestly, while it did take time, it worked. I am vaccinated; are you?