RFH: dctrl-tools — Command-line tools to process Debian package information

I request assistance with maintaining the dctrl-tools package.

There are several tasks that could use more manpower (in no particular order):

  • Writing test cases
    One could mine the BTS for past bug reports and create regression tests for them.
    One could use standard black-box and white-box testing techniques to generate general tests.
  • Writing documentation
    The whole suite of tools could use a unified tutorial manual on how to best use it. The current documentation is reference material in the man pages.
  • Internationalise the man pages
    Use po4a?
  • Swatting the BTS wishlist entries
    I’ve kept the BTS clean of actual bugs pretty well, but there are a number of wishlist reports still outstanding.
  • Take over maintaining the debian/ directory
    If you commit to maintaining it (and I trust your judgment), you’ll get last say in that part of the package (including deciding what helper to use).
  • Whatever you wish :)
    Discuss on the dctrl-tools-devel mailing list first though.

Eventually I’d like to pass the package on to competent successors, but I have too much emotional attachment to the package to do that without a transitional period where I still retain a veto on what goes in the package. I also have some ideas for future tools that I’d like to be
able to concentrate on, and having co-maintainers might allow that.

The package is now under Git in collab-maint. See the new README.Debian for information and a push-access code of conduct.

It’s time to fix the ABI

SELinux is entirely correct about disallowing dynamic code generation, as it is a major security risk.

Disregarding Just-In-Time compilation, the main legitimate need for dynamic code generation is to support (downward) closures that are ABI-compatible with normal C functions. GCC’s local functions extension of C is one example, and many non-C languages need them badly in their foreign-function interfaces (Haskell is one, Ada I’m told is another).

A closure is a function pointer that refers to a function that is local to another function. That function has access to the local variables of the parent function, and this access is provided by having the caller give the callee a static link (a pointer to the parent function’s stack frame) as a hidden parameter. If the call is direct (that is, not through a function pointer), the caller knows the appropriate static link and can just pass it. The trouble comes with function pointers, as we need some way of including the static link in the function pointer.

The simplest way is to have function pointers be two words long; one of the words contains the classical function pointer (that is, the entry point address), and the other contains the static link. Unfortunately, the prevalent C ABIs, including the SYSV ABI used by GNU/Linux, mandate that function pointers are one word long. The only way I know to work around this is to dynamically generate, when the function pointer is created, a small snippet of code that loads the correct static link to the appropriate place and jumps to the actual code of the function, and use the address of this snippet (usually called a trampoline) as the function pointer. The snippet is generated on the stack or in the heap, and thus requires an executable stack or executable dynamic memory.

It’s time to fix the ABI to allow for proper two-word function pointers.

New C standard in 2012?

The C standards committee is apparently preparing to revise the C standard. The proposed C1x charter sets the goal of the committee draft’s completion in 2009, with publication of the new standard in 2012. The proposed charter adds security as a significant new goal for the standard:

Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities.

The proposed charter also sets the requirement that all new features must have a history in non-experimental compilers and be in common use.

The Dying Philosophers Problem

Reading a masters thesis draft that mentions the dining philosophers problem – a parable about the difficulties of process synchronization very well known in computer science – it occurred to me that it must not be a very good idea to eat just spaghetti (or just rice). I asked a nutritionist about it, and here is her answer. Even if they manage to avoid deadlock or livelock, dying of malnutrition is not going to be their first problem, go read the full story!

[Typos and thinkos corrected after initial publication]

Announcing darcs-monitor 0.3.1

Darcs-monitor will send email to a specified recipient about new changes added to a specific darcs repository. It can be run as an apply posthook (resulting in near-instantaneous “push” emails), or periodically from Cron, or occasionally by hand, whatever seems most convenient.

This new release (0.3) contains the following changes:

  • there is now support for the %CHANGES% and %SHORTREPO% substitutions in the template
  • a default template is now provided
  • ' and " entity references in darcs changes –xml is now supported
  • patches with just the author email address (no real name) are now handled correctly
  • when multiple emails are sent, they are now sent in chronological order
  • emails are announced to the user

The minor update 0.3.1 brings the documentation up to date.

Benja Fallenstein and Benjamin Franksen provided some of the features and bug fixes in this release. My thanks to them :)

You can get it by darcs at http://antti-juhani.kaijanaho.fi/darcs/darcs-monitor/ (darcsweb
available
), or as a tarball at http://antti-juhani.kaijanaho.fi/software/dist/. It depends on mtl and
HaXml and is written in Haskell, naturally. It has been tested only with GHC 6.6 so far. For installation and usage instructions, refer to the README at any of the locations above.

Please note that this software is very new and thus can be buggy. As with any email-sending software, bugs can result in major annoyance; user caution is warranted.

Debian, eräs Linux-versio eli miksi Debian on cool

(Tämä on aiemmin tänään pitämäni luennon käsikirjoitus. Itse luennossa käytin käsikirjoitusta vain tukena, en lukenut sitä ääneen.)

Minä olen Antti-Juhani Kaijanaho ja olen Debian-kehittäjä. (Hei, Antti-Juhani!) Tarkoituksenani on kertoa teille hieman Debianista. En aio näyttää teille, kuinka sitä käytetään tai kuinka se asennetaan, sillä Linux kuin Linux ei juuri toisesta eroa käyttäjän näkökulmasta. Sen sijaan aion tuoda esille, mikä tekee Debianista poikkeuksellisen. Väitän, että Debian on cool, käyttää sitä eli ei.

* * *

Tarina alkaa yli kaksikymmentä vuotta sitten Amerikan Yhdysvalloissa, Massachusettsin teknillisen korkeakoulun eli MIT:n tekoälylaboratoriossa. Eräänä päivänä heiltä hajosi laboratorion tulostimen ohjausohjelma. Tekoälylaboratorion työntekijät olivat kokeneita ohjelmoijia. Taitoa siis kyllä olisi löytynyt vian korjaamiseen, mutta ohjelman valmistaja kielsi. Tiedättehän, ohjelmaan sai laillisesti koskea vain sen valmistaja. Tietääkseni valmistaja ei pyynnöistä huolimatta koskaan korjannut vikaa. Tekoälylaboratoriossa jouduttiin tyytymään rampaan tulostusjärjestelmään.

Stallman aloitti 1980-luvun puolivälissä projektin, jonka tarkoituksena oli luoda ohjelmia, joita nämä ongelmat eivät koske. Hänen tarkoituksenaan oli luoda kokonainen käyttöjärjestelmä ja siinä toimivat hyötyohjelmat, jotka olisivat vapaasti käytettävissä ja muokattavissa. Hän antoi järjestelmälleen nimeksi GNU.

Vuonna 1991 GNU oli lähes valmis. Puuttui vain käyttöjärjestelmän ydin, se osa, jota pidettiin kaikkein haasteellisimpana. Samaan aikaan Helsingin yliopistossa alkoi leikkiä uudella PC:llään opiskelija nimeltään Linus Torvalds. Hän ei kuulunut GNU-projektiin, vaan hän alkoi rakentaa omaa käyttöjärjestelmän ydintään lähinnä kaiketi opiskelutarkoituksessa — niin, ja hauskanpitotarkoituksessa. Meillä nörteillä on omalaatuinen käsitys siitä, mikä on hauskaa.

Vallankumouksellista Linusin ytimessä, jota alettiin pian kutsua Linuxiksi, ei ole sen teknisiset ominaisuudet. Tuohon aikaan uskottiin, että laajat ja monimutkaiset tietokoneohjelmat on laadittava pienen porukan voimin; ajateltiin, että ohjelmistojen tekemisessä pätee vanha sananlasku kokkien määrästä ja keiton laadusta. Alan piireissä tätä sanotaan Brooksin laiksi[1]: “tekijöiden lisääminen myöhässä olevaan ohjelmistoprojektiin myöhästyttää sitä entisestään”, toisin sanoen ihmiset ja aika eivät ole tämän ajattelun mukaan vaihdettavissa toisikseen. Käyttöjärjestelmän ydin on mitä suurimmassa määrin monimutkainen ohjelma.

[1] Ks. Frederick P. Brooks: The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975. (20th anniversary edition: Addison-Wesley, 1995.)

Linuxissa hämmästyttävää on ollut se, että sen laatu ja kehityksen nopeus on parantunut sitä mukaa kun sitä kehittämään on tullut lisää ihmisiä. Kun Linus antoi sen ensimmäistä kertaa julkiseen jakeluun vuonna 1991, ei sillä tehnyt juuri mitään. Kolme vuotta myöhemmin se oli saavuttanut 1.0-version, joka oli jo aika käyttökelpoinen. Tässä vaiheessa Linuxia oli ollut kehittämässä 80 ihmistä. Tällä hetkellä uusin versio on 2.6.21, johon mennessä kehittäjiä on ollut yhteensä 482. Silti sen laatu on parantunut eikä sen kehitys ole lamaantunut!

Selitys tälle ihmeelle löytyy siitä, että Linuxissa on paljon erilaisia osa-alueita, joita voidaan kehittää toisistaan erillään ilman, että ne kovin pahasti haittaavat toisiaan, kun järjestelmällä on arkkitehtuuri, joka määrittelee näiden osa-alueiden väliset rajat selkeästi. Linuxin arkkitehti on Linus Torvalds, joka määrää, missä on kaapin paikka.

Internetillä oli myös asiassa merkittävä rooli, sillä sen ansiosta ensimmäistä kertaa ihmiskunnan historiassa oli mahdollista siirtää dataa suhteellisen halvalla maailman toiselle puolelle ja käydä keskusteluja ympäri maailmaa asuvien ihmisten kesken. Linuxa ei olisi voinut olla ilman Internetiä.

Linuxin ympärille oli suhteellisen helppo koota muilta osin täysin valmis GNU. Tämä helppous on toki aika suhteellista, sillä erillisistä paloista piti kaikesta huolimatta koota kokonaisuus, mikä ei ole aivan helppoa, kun otetaan huomioon, että palat on laadittu toisistaan melko riippumatta ja ilman keskitettyä koordinaatiota.

Linuxin ja GNU:n yhdistäminen toimivaksi järjestelmäksi oli itse asiassa aika vaivalloista, ja vain omistautuneimmat harrastajat sen jaksoivat tehdä. Se piti vieläpä tehdä joka koneella erikseen. Aika pian ymmärrettiin, että järjestelmän kokoaminen tapahtuu oikeastaan aika lailla samalla tavalla eri koneilla. Luonnollinen seuraus tästä ajatuksesta on, että jotkut ihmiset alkoivat laatia asennuspaketteja eli jakeluita, joissa tuo järjestelmän kokoaminen on tehty valmiiksi.

Varhaisissa asennuspaketeissa osat oli ikään kuin sulautettu yhteen niin, että niitä ei ollut enää kovin helppo erottaa toisistaan tai huoltaa erikseen. Lisäksi ne olivat usein yhden ihmisen showeja ja yleensä kaupallisia yrityksiä.

Ian Murdock perusti vuonna 1993 uuden asennuspakettiprojektin, joka oli kahdella tavalla vallankumouksellinen[2]:

[2] Ian Murdock: The Debian Manifesto, päivitetty 6. tammikuuta 1994.

Sen kehitystyö olisi avointa ja yhteisöllistä, kuten Linuxin ja GNU:n. Debianilla tulisi olemaan runsaasti yhteistyössä toimivia kehittäjiä.

Sen kehitystyö tapahtuisi voittoa tavoittelemattomana vapaaehtoistyönä kuten Linuxin ja GNU:n, mutta se silti olisi tarpeeksi laadukas kilpaillakseen kaupallisten yritysten kanssa.

Molemmat tavoitteet toteutuivat.

Murdock nimesi projektin yhdistämällä oman etunimensä tyttöystävänsä (nykyisen vaimonsa) etunimen kanssa: Deb ja Ian — Debian. Virallisesti projektin tuote on alkuajoista asti tunnettu nimellä Debian GNU/Linux, minkä tarkoituksena on korostaa sitä, että kyseessä on GNU:n ja Linuxin yhteenliitos.

Debianin ensimmäinen virallinen julkaisu oli versio 1.1, koodinimeltään Buzz, joka julkaistiin kesäkuussa 1995. Versiota 1.0 ei koskaan julkaistu harmillisen sekaannuksen johdosta: eräs CD-ROM-myyjä valmisti ja myi erehdyksessä keskeneräistä versiota väittäen sitä 1.0:ksi. Tämän sattumuksen takia jokainen Debianin versio tunnetaan ensisijaisesti Toy Story -elokuvasta otetuilla koodinimillä, ja versionumero julkaisulle annetaan vasta viime hetkillä.

Tällä hetkellä Debianiin kuuluu toista tuhatta äänivaltaista kehittäjää sekä runsaslukuinen joukko äänivallattomia kehittäjiä. Viimeisin virallinen julkaisu on versio 4.0 koodinimeltään Etch, julkaistu huhtikuussa 2007.


[Debianin julkaisujen ajankohdat kuvana]

Alkuperäinen kuva: Martin F. Krafft; muokatun kuvan lähdetiedosto timeline.fig.

* * *

Debian kutsuu itseään “universaaliksi käyttöjärjestelmäksi”. Tälle nimelle on kolme keskeistä perustetta:

Debian toimii hyvin monessa erilaisessa tietokoneessa PC:istä eräisiin kämmentietokoneisiin sekä eräisiin supertietokoneisiin. Se lienee Linux-jakeluista laaja-alaisin tällä kriteerillä arvioituna.

Debianissa on (lähes) kaikki vapaat ohjelmistot: useimmilla käyttäjillä ei ole mitään tarvetta hakea ohjelmia muualta, sillä kaikki tarvittava tulee Debianin mukana.

Debian toimii myös varsin monen muun Linux-jakelun “emona”: nämä muut jakelut ottavat Debianin pohjakseen ja muokkaavat sitä eri tavoin omien tavoitteittensa mukaiseksi. Tunnetuin Debianin lapsijakelu on Ubuntu.

Debianin kehitystyö keskitttyy niin sanottujen pakettien ympärille. Paketti on Debianin kehitystyön yksikkö, yksi paketti sisältää tyypillisesti yhden sovellusohjelman tai yhden ohjelmakirjaston, ja jokaisella paketilla on yksi tai useampi vastuuhenkilö, jotka yhdessä päättävät, mitä paketille tapahtuu. Monet paketit ovat täysin riippumattomia toisistaan, joten niitä voidaan kehittää täysin toisistaan erillään. Tämän takia Debian on onnistuneesti kasvanut varsin suureksi.

On hyvin tyypillistä, että Debian ei ota jotain uutta toimintoa käyttöön, ennen kuin sille on löytynyt laadukas toteutustapa. Tämän ansiosta Debianilla on maine erittäin luotettavana käyttöjärjestelmän koostajana:

Look, this is Debian. They don’t release things until you have to fire rockets at the thing to stop it working ;)
nimimerkki MrNemesis 14.7.2004

Mainio esimerkki tästä on Debianin pakettienhallintajärjestelmä. Debian oli mahdollisesti ensimmäinen Linux-jakelu, jossa oli ohjelmistotuki pakettien asentamiselle, päivittämiselle ja poistamiselle toisistaan riippumatta. Debian oli kiistatta ensimmäinen Linux-jakelu, jolla oli puoliautomaattinen, älykäs pakettienhallinta (“apt”), joka osaa hakea asennuksen ja päivityksen aikana tarvittavat apupaketit käyttäjän puolesta ja joka osaa päivittää järjestelmän uuteen versioon lennossa, usein jopa ilman tarvetta käynnistää järjestelmä uudelleen. Sittemmin Debianin kehittämä Apt-järjestelmä on otettu käyttöön joko sellaisenaan, pienin muutoksin tai kloonattuna lähes kaikissa muissakin Linux-jakeluissa.

Debianin laatu perustuu myös paljolti siihen, että käytännössä kaikki Debianiin asennettavissa olevat ohjelmat löytyvät Debianista itsestään. Tällöin nimittäin ne kaikki noudattavat yhteistä linjaa (“Debian Policy”), joka Debianin tapauksessa on erikseen dokumentoitu (ja josta joskus käydään varsin kiivaitakin keskusteluja).

Debian oli ensimmäinen Linux-jakelua laativa organisaatio, joka antoi yksipuolisen lupauksen vapaan ohjelmiston ideologian kunnioittamisesta. Tämä Debianin yhteiskuntasopimuksena (“Social Contract”) tunnettu lupaus sisältää muiden muassa lupauksen sisällyttää jakeluun pelkästään vapaita ohjelmistoja sekä lupauksen pitää kaikki ongelmat julkisina. Harva Linux-jakelu on tässä seurannut Debianin jalanjälkiä.

Debianin yhteiskuntasopimus sisältää liitteen nimeltä “Debianin vapaiden ohjelmistojen ohjeisto” (“Debian Free Software Guidelines”), joka esittelee erään määritelmän sille, mitä vapaalta ohjelmistolta vaaditaan. Tästä dokumentista on pienellä muokkauksella synnytetty avoimen lähdekoodin määritelmä (“Open Source Definition”), ja se on edelleen yksi merkittävimmistä vapaiden ohjelmistojen määritelmistä.

Debianin kehitystyö on puhdasta kolmannen sektorin toimintaa. Debian itse ei maksa palkkaa kenellekään, ja valtaosa Debianin kehittäjistä tekevät sitä harrastuksenaan. Osa kehittäjistä toimii Debianissa ulkopuolisten tahojen palkkaamana.

* * *

Debianilla on maine hitaasta toiminnasta. Maine on pitkälti ansaittu: koska asioita ei yleensä tehdä hutiloiden, voi niiden aikaansaamisessa kestää vuosia. Viimeistä edellinen virallinen julkaisu, esimerkiksi, oli työn alla kolmisen vuotta, kun tavoite on tämän puolikas.

Pitkälti edelliseen liittyen Debianilla on myös maine vanhentuneiden ohjelmistojen julkaisemisesta. On totta, että usein Debianin julkaisuhetkellä ohjelmista on jo tehty uudempia versioita, mutta toisaalta näiden uusien versioiden toimivuus ei ole lainkaan taattua. Sen sijaan Debianin virallinen julkaisu yleensä toimii mainiosti, ja tämä saadaan aikaiseksi testaamalla julkaistavaa versiota kuukausikaupalla.

Debiania on myös haukuttu hankalasti asennettavaksi. Tämä piti paikkaansa vielä puolisen vuosikymmentä sitten, mutta Debianin nykyinen virallinen julkaisu on varsin helppo asentaa.

* * *

En väitä, että Debian olisi aina se ainoa oikea valinta. Useimpien käyttäjien näkökulmasta Linux-jakelut eivät juuri eroa toisistaan, ja valitsee sitten Debianin tai jonkin muun valtavirtajakelun, ei tällä ole suurta merkitystä. Sen sijaan ohjelmistokehittäjien ja asianharrastajien kannalta Debianilla on runsaasti etuja, joita olen edellä pyrkinyt käsittelemään.

Väitän kuitenkin, että Debian on cool.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 1.0 Finland License.

Serendipity breaks an important Internet standard – and is proud of it

Originally posted on 2006-04-16.

Clarification 2006-04-19: The misfeature discussed below applies to feeds only, as far as I know, not to regular HTML serving.

Update 2007-05-06: I have just learned that the option in question is Activate strict RFC2616 RSS-Feed compliance. I have no idea when it was added.

While investigating (wearing my hat as the Planet Haskell editor/technician) John Goerzen‘s Planet floods, I stumbled on a very strange misfeature in Serendipity. A HTTP/1.1 client can ask a server to send a file over only if the file has been modified since some date. What Serendipity does is send only those entries dated after the provided timestamp. Now, this might seem like a triviality, but it isn’t. The HTTP/1.1 feature is there to make proxy caching work. It is very important for caching that the file sent is the same, regardless whether the request is “since this timestamp”, or a regular request. Serendipity’s behaviour breaks this very important caching invariant!

What’s more is that Serendipity’s developers seem rather proud of this misfeature. While the feature this misuse of HTTP/1.1 is intended to create is certainly useful, it should be implemented as a separate mechanism, and not by misusing HTTP/1.1 caching! (A separate protocol is probably necessary, perhaps specifying a URI query syntax for this is enough; obviously, one needs to get the aggregators to support this.)

Serendipity will apparently have a configuration option to fix this, but it will be off by default. Serendipity users, upgrade (as soon as it is possible) and mark that option On, to remain compatible with the rest of the Internet.