<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>Hvordan vurderer regjeringen H.264-patentutfordringen?</title>
+ <link>http://people.skolelinux.org/pere/blog/Hvordan_vurderer_regjeringen_H_264_patentutfordringen_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Hvordan_vurderer_regjeringen_H_264_patentutfordringen_.html</guid>
+ <pubDate>Sun, 16 Nov 2014 10:30:00 +0100</pubDate>
+ <description><p>For en stund tilbake spurte jeg Fornyingsdepartementet om hvilke
+juridiske vurderinger rundt patentproblemstillingen som var gjort da
+H.264 ble tatt inn i <a href="http://standard.difi.no/">statens
+referansekatalog over standarder</a>. Stig Hornnes i FAD tipset meg
+om følgende som står i oppsumeringen til høringen om
+referansekatalogen versjon 2.0, som jeg siden ved hjelp av en
+innsynsforespørsel fikk tak i
+<a href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&do=get&target=kongelig-resolusjon.pdf">PDF-utgaven av</a>
+datert 2009-06-03 (saksnummer 200803291, saksbehandler Henrik
+Linnestad).</p>
+
+<p>Der står det følgende om problemstillingen:</p>
+
+<p><blockquote>
+<strong>4.4 Patentproblematikk</strong>
+
+<p>NUUG og Opera ser det som særlig viktig at forslagene knyttet til
+lyd og video baserer seg på de royalty-frie standardene Vorbis, Theora
+og FLAC.</p>
+
+<p>Kommentarene relaterer seg til at enkelte standarder er åpne, men
+inneholder tekniske prosedyrer som det i USA (og noen andre land som
+Japan) er gitt patentrettigheter til. I vårt tilfelle berører dette
+spesielt standardene Mp3 og H.264, selv om Politidirektoratet peker på
+at det muligens kan være tilsvarende problematikk også for Theora og
+Vorbis. Dette medfører at det i USA kan kreves royalties for bruk av
+tekniske løsninger knyttet til standardene, et krav som også
+håndheves. Patenter kan imidlertid bare hevdes i de landene hvor
+patentet er gitt, så amerikanske patenter gjelder ikke andre steder
+enn USA.</p>
+
+<p>Spesielt for utvikling av fri programvare er patenter
+problematisk. GPL, en "grunnleggende" lisens for distribusjon av fri
+programvare, avviser at programvare kan distribueres under denne
+lisensen hvis det inneholder referanser til patenterte rutiner som
+utløser krav om royalties. Det er imidlertid uproblematisk å
+distribuere fri programvareløsninger under GPL som benytter de
+aktuelle standardene innen eller mellom land som ikke anerkjenner
+patentene. Derfor finner vi også flere implementeringer av Mp3 og
+H.264 som er fri programvare, lisensiert under GPL.</p>
+
+<p>I Norge og EU er patentlovgivningen langt mer restriktiv enn i USA,
+men det er også her mulig å få patentert metoder for løsning av et
+problem som relaterer seg til databehandling. Det er AIF bekjent ikke
+relevante patenter i EU eller Norge hva gjelder H.264 og Mp3, men
+muligheten for at det finnes patenter uten at det er gjort krav om
+royalties eller at det senere vil gis slike patenter kan ikke helt
+avvises.</p>
+
+<p>AIF mener det er et behov for å gi offentlige virksomheter mulighet
+til å benytte antatt royaltyfrie åpne standarder som et likeverdig
+alternativ eller i tillegg til de markedsledende åpne standardene.</p>
+
+</blockquote></p>
+
+<p>Det ser dermed ikke ut til at de har vurdert patentspørsmålet i
+sammenheng med opphavsrettsvilkår slik de er formulert for f.eks.
+Apple Final Cut Pro, Adobe Premiere Pro, Avid og Sorenson-verktøyene,
+der det kreves brukstillatelse for patenter som ikke er gyldige i
+Norge for å bruke disse verktøyene til annet en personlig og ikke
+kommersiell aktivitet når det gjelder H.264-video. Jeg må nok lete
+videre etter svar på det spørsmålet.</p>
+</description>
+ </item>
+
+ <item>
+ <title>A Debian package for SMTP via Tor (aka SMTorP) using exim4</title>
+ <link>http://people.skolelinux.org/pere/blog/A_Debian_package_for_SMTP_via_Tor__aka_SMTorP__using_exim4.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/A_Debian_package_for_SMTP_via_Tor__aka_SMTorP__using_exim4.html</guid>
+ <pubDate>Mon, 10 Nov 2014 13:40:00 +0100</pubDate>
+ <description><p>The right to communicate with your friends and family in private,
+without anyone snooping, is a right every citicen have in a liberal
+democracy. But this right is under serious attack these days.</p>
+
+<p>A while back it occurred to me that one way to make the dragnet
+surveillance conducted by NSA, GCHQ, FRA and others (and confirmed by
+the whisleblower Snowden) more expensive for Internet email,
+is to deliver all email using SMTP via Tor. Such SMTP option would be
+a nice addition to the FreedomBox project if we could send email
+between FreedomBox machines without leaking metadata about the emails
+to the people peeking on the wire. I
+<a href="http://lists.alioth.debian.org/pipermail/freedombox-discuss/2014-October/006493.html">proposed
+this on the FreedomBox project mailing list in October</a> and got a
+lot of useful feedback and suggestions. It also became obvious to me
+that this was not a novel idea, as the same idea was tested and
+documented by Johannes Berg as early as 2006, and both
+<a href="https://github.com/pagekite/Mailpile/wiki/SMTorP">the
+Mailpile</a> and <a href="http://dee.su/cables">the Cables</a> systems
+propose a similar method / protocol to pass emails between users.</p>
+
+<p>To implement such system one need to set up a Tor hidden service
+providing the SMTP protocol on port 25, and use email addresses
+looking like username@hidden-service-name.onion. With such addresses
+the connections to port 25 on hidden-service-name.onion using Tor will
+go to the correct SMTP server. To do this, one need to configure the
+Tor daemon to provide the hidden service and the mail server to accept
+emails for this .onion domain. To learn more about Exim configuration
+in Debian and test the design provided by Johannes Berg in his FAQ, I
+set out yesterday to create a Debian package for making it trivial to
+set up such SMTP over Tor service based on Debian. Getting it to work
+were fairly easy, and
+<a href="https://github.com/petterreinholdtsen/exim4-smtorp">the
+source code for the Debian package</a> is available from github. I
+plan to move it into Debian if further testing prove this to be a
+useful approach.</p>
+
+<p>If you want to test this, set up a blank Debian machine without any
+mail system installed (or run <tt>apt-get purge exim4-config</tt> to
+get rid of exim4). Install tor, clone the git repository mentioned
+above, build the deb and install it on the machine. Next, run
+<tt>/usr/lib/exim4-smtorp/setup-exim-hidden-service</tt> and follow
+the instructions to get the service up and running. Restart tor and
+exim when it is done, and test mail delivery using swaks like
+this:</p>
+
+<p><blockquote><pre>
+torsocks swaks --server dutlqrrmjhtfa3vp.onion \
+ --to fbx@dutlqrrmjhtfa3vp.onion
+</pre></blockquote></p>
+
+<p>This will test the SMTP delivery using tor. Replace the email
+address with your own address to test your server. :)</p>
+
+<p>The setup procedure is still to complex, and I hope it can be made
+easier and more automatic. Especially the tor setup need more work.
+Also, the package include a tor-smtp tool written in C, but its task
+should probably be rewritten in some script language to make the deb
+architecture independent. It would probably also make the code easier
+to review. The tor-smtp tool currently need to listen on a socket for
+exim to talk to it and is started using xinetd. It would be better if
+no daemon and no socket is needed. I suspect it is possible to get
+exim to run a command line tool for delivery instead of talking to a
+socket, and hope to figure out how in a future version of this
+system.</p>
+
+<p>Until I wipe my test machine, I can be reached using the
+<tt>fbx@dutlqrrmjhtfa3vp.onion</tt> mail address, deliverable over
+SMTorP. :)</p>
+</description>
+ </item>
+
<item>
<title>First Jessie based Debian Edu released (alpha0)</title>
<link>http://people.skolelinux.org/pere/blog/First_Jessie_based_Debian_Edu_released__alpha0_.html</link>
</description>
</item>
- <item>
- <title>Hva henger under skibrua over E16 på Sollihøgda?</title>
- <link>http://people.skolelinux.org/pere/blog/Hva_henger_under_skibrua_over_E16_p__Sollih_gda_.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Hva_henger_under_skibrua_over_E16_p__Sollih_gda_.html</guid>
- <pubDate>Sun, 21 Sep 2014 09:50:00 +0200</pubDate>
- <description><p>Rundt omkring i Oslo og Østlandsområdet henger det bokser over
-veiene som jeg har lurt på hva gjør. De har ut fra plassering og
-vinkling sett ut som bokser som sniffer ut et eller annet fra
-forbipasserende trafikk, men det har vært uklart for meg hva det er de
-leser av. Her om dagen tok jeg bilde av en slik boks som henger under
-<a href="http://www.openstreetmap.no/?zoom=19&mlat=59.96396&mlon=10.34443&layers=B00000">ei
-skibru på Sollihøgda</a>:</p>
-
-<p align="center"><img width="60%" src="http://people.skolelinux.org/pere/blog/images/2014-09-13-kapsch-sollihogda-crop.jpeg"></p>
-
-<p>Boksen er tydelig merket «Kapsch >>>», logoen til
-<a href="http://www.kapsch.net/">det sveitsiske selskapet Kapsch</a> som
-blant annet lager sensorsystemer for veitrafikk. Men de lager mye
-forskjellig, og jeg kjente ikke igjen boksen på utseendet etter en
-kjapp titt på produktlista til selskapet.</p>
-
-<p>I og med at boksen henger over veien E16, en riksvei vedlikeholdt
-av Statens Vegvesen, så antok jeg at det burde være mulig å bruke
-REST-API-et som gir tilgang til vegvesenets database over veier,
-skilter og annet veirelatert til å finne ut hva i alle dager dette
-kunne være. De har både
-<a href="https://www.vegvesen.no/nvdb/api/dokumentasjon/datakatalog">en
-datakatalog</a> og
-<a href="https://www.vegvesen.no/nvdb/api/dokumentasjon/sok">et
-søk</a>, der en kan søke etter ulike typer oppføringer innen for et
-gitt geografisk område. Jeg laget et enkelt shell-script for å hente
-ut antall av en gitt type innenfor området skibrua dekker, og listet
-opp navnet på typene som ble funnet. Orket ikke slå opp hvordan
-URL-koding av aktuelle strenger kunne gjøres mer generisk, og brukte
-en stygg sed-linje i stedet.</p>
-
-<blockquote><pre>
-#!/bin/sh
-urlmap() {
- sed \
- -e 's/ / /g' -e 's/{/%7B/g' \
- -e 's/}/%7D/g' -e 's/\[/%5B/g' \
- -e 's/\]/%5D/g' -e 's/ /%20/g' \
- -e 's/,/%2C/g' -e 's/\"/%22/g' \
- -e 's/:/%3A/g'
-}
-
-lookup() {
- url="$1"
- curl -s -H 'Accept: application/vnd.vegvesen.nvdb-v1+xml' \
- "https://www.vegvesen.no/nvdb/api$url" | xmllint --format -
-}
-
-for id in $(seq 1 874) ; do
- search="{
- lokasjon: {
- bbox: \"10.34425,59.96386,10.34458,59.96409\",
- srid: \"WGS84\"
- },
- objektTyper: [{
- id: $id, antall: 10
- }]
-}"
-
- query=/sok?kriterie=$(echo $search | urlmap)
- if lookup "$query" |
- grep -q '&lt;totaltAntallReturnert>0&lt;'
- then
- :
- else
- echo $id
- lookup "/datakatalog/objekttyper/$id" |grep '^ &lt;navn>'
- fi
-done
-
-exit 0
-</pre></blockquote>
-
-Aktuelt ID-område 1-874 var riktig i datakatalogen da jeg laget
-scriptet. Det vil endre seg over tid. Skriptet listet så opp
-aktuelle typer i og rundt skibrua:
-
-<blockquote><pre>
-5
- &lt;navn>Rekkverk&lt;/navn>
-14
- &lt;navn>Rekkverksende&lt;/navn>
-47
- &lt;navn>Trafikklomme&lt;/navn>
-49
- &lt;navn>Trafikkøy&lt;/navn>
-60
- &lt;navn>Bru&lt;/navn>
-79
- &lt;navn>Stikkrenne/Kulvert&lt;/navn>
-80
- &lt;navn>Grøft, åpen&lt;/navn>
-86
- &lt;navn>Belysningsstrekning&lt;/navn>
-95
- &lt;navn>Skiltpunkt&lt;/navn>
-96
- &lt;navn>Skiltplate&lt;/navn>
-98
- &lt;navn>Referansestolpe&lt;/navn>
-99
- &lt;navn>Vegoppmerking, langsgående&lt;/navn>
-105
- &lt;navn>Fartsgrense&lt;/navn>
-106
- &lt;navn>Vinterdriftsstrategi&lt;/navn>
-172
- &lt;navn>Trafikkdeler&lt;/navn>
-241
- &lt;navn>Vegdekke&lt;/navn>
-293
- &lt;navn>Breddemåling&lt;/navn>
-301
- &lt;navn>Kantklippareal&lt;/navn>
-318
- &lt;navn>Snø-/isrydding&lt;/navn>
-445
- &lt;navn>Skred&lt;/navn>
-446
- &lt;navn>Dokumentasjon&lt;/navn>
-452
- &lt;navn>Undergang&lt;/navn>
-528
- &lt;navn>Tverrprofil&lt;/navn>
-532
- &lt;navn>Vegreferanse&lt;/navn>
-534
- &lt;navn>Region&lt;/navn>
-535
- &lt;navn>Fylke&lt;/navn>
-536
- &lt;navn>Kommune&lt;/navn>
-538
- &lt;navn>Gate&lt;/navn>
-539
- &lt;navn>Transportlenke&lt;/navn>
-540
- &lt;navn>Trafikkmengde&lt;/navn>
-570
- &lt;navn>Trafikkulykke&lt;/navn>
-571
- &lt;navn>Ulykkesinvolvert enhet&lt;/navn>
-572
- &lt;navn>Ulykkesinvolvert person&lt;/navn>
-579
- &lt;navn>Politidistrikt&lt;/navn>
-583
- &lt;navn>Vegbredde&lt;/navn>
-591
- &lt;navn>Høydebegrensning&lt;/navn>
-592
- &lt;navn>Nedbøyningsmåling&lt;/navn>
-597
- &lt;navn>Støy-luft, Strekningsdata&lt;/navn>
-601
- &lt;navn>Oppgravingsdata&lt;/navn>
-602
- &lt;navn>Oppgravingslag&lt;/navn>
-603
- &lt;navn>PMS-parsell&lt;/navn>
-604
- &lt;navn>Vegnormalstrekning&lt;/navn>
-605
- &lt;navn>Værrelatert strekning&lt;/navn>
-616
- &lt;navn>Feltstrekning&lt;/navn>
-617
- &lt;navn>Adressepunkt&lt;/navn>
-626
- &lt;navn>Friksjonsmåleserie&lt;/navn>
-629
- &lt;navn>Vegdekke, flatelapping&lt;/navn>
-639
- &lt;navn>Kurvatur, horisontalelement&lt;/navn>
-640
- &lt;navn>Kurvatur, vertikalelement&lt;/navn>
-642
- &lt;navn>Kurvatur, vertikalpunkt&lt;/navn>
-643
- &lt;navn>Statistikk, trafikkmengde&lt;/navn>
-647
- &lt;navn>Statistikk, vegbredde&lt;/navn>
-774
- &lt;navn>Nedbøyningsmåleserie&lt;/navn>
-775
- &lt;navn>ATK, influensstrekning&lt;/navn>
-794
- &lt;navn>Systemobjekt&lt;/navn>
-810
- &lt;navn>Vinterdriftsklasse&lt;/navn>
-821
- &lt;navn>Funksjonell vegklasse&lt;/navn>
-825
- &lt;navn>Kurvatur, stigning&lt;/navn>
-838
- &lt;navn>Vegbredde, beregnet&lt;/navn>
-862
- &lt;navn>Reisetidsregistreringspunkt&lt;/navn>
-871
- &lt;navn>Bruksklasse&lt;/navn>
-</pre></blockquote>
-
-<p>Av disse ser ID 775 og 862 mest relevant ut. ID 775 antar jeg
-refererer til fotoboksen som står like ved brua, mens
-«Reisetidsregistreringspunkt» kanskje kan være boksen som henger der.
-Hvordan finner jeg så ut hva dette kan være for noe. En titt på
-<a href="http://labs.vegdata.no/nvdb-datakatalog/862-Reisetidsregistreringspunkt/">datakatalogsiden
-for ID 862/Reisetidsregistreringspunkt</a> viser at det er finnes 53
-slike målere i Norge, og hvor de er plassert, men gir ellers få
-detaljer. Det er plassert 40 på østlandet og 13 i Trondheimsregionen.
-Men siden nevner «AutoPASS», og hvis en slår opp oppføringen på
-Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det
-være snakk om
-<a href="http://www.proff.no/selskap/ciber-norge-as/oslo/internettdesign-og-programmering/Z0I3KMF4/">Ciber
-Norge AS</a>, et selskap eid av Ciber Europe Bv?) Et nettsøk på
- «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i
- 2013 med tittel
-«<a href="http://www.nrk.no/trondelag/sjekk-dette-hvis-du-vil-unnga-ko-1.11327947">Sjekk
-dette hvis du vil unngå kø</a>». Artikkelen henviser til vegvesenets
-nettside
-<a href="http://www.reisetider.no/reisetid/forside.html">reisetider.no</a>
-som har en
-<a href="http://www.reisetider.no/reisetid/omrade.html?omrade=5">kartside
-for Østlandet</a> som viser at det måles mellom Sandvika og Sollihøgda.
-Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.</p>
-
-<p>Hvis det stemmer, så er dette bokser som leser av AutoPASS-ID-en
-til alle passerende biler med AutoPASS-brikke, og dermed gjør det mulig
-for de som kontrollerer boksene å holde rede på hvor en gitt bil er
-når den passerte et slikt målepunkt. NRK-artikkelen forteller at
-denne informasjonen i dag kun brukes til å koble to
-AutoPASS-brikkepasseringer passeringer sammen for å beregne
-reisetiden, og at bruken er godkjent av Datatilsynet. Det er desverre
-ikke mulig for en sjåfør som passerer under en slik boks å kontrollere
-at AutoPASS-ID-en kun brukes til dette i dag og i fremtiden.</p>
-
-<p>I tillegg til denne type AutoPASS-sniffere vet jeg at det også
-finnes mange automatiske stasjoner som tar betalt pr. passering (aka
-bomstasjoner), og der lagres informasjon om tid, sted og bilnummer i
-10 år. Finnes det andre slike sniffere plassert ut på veiene?</p>
-
-<p>Personlig har jeg valgt å ikke bruke AutoPASS-brikke, for å gjøre
-det vanskeligere og mer kostbart for de som vil invadere privatsfæren
-og holde rede på hvor bilen min beveger seg til enhver tid. Jeg håper
-flere vil gjøre det samme, selv om det gir litt høyere private
-utgifter (dyrere bompassering). Vern om privatsfæren koster i disse
-dager.</p>
-
-<p>Takk til Jan Kristian Jensen i Statens Vegvesen for tips om
-dokumentasjon på vegvesenets REST-API.</p>
-</description>
- </item>
-
- <item>
- <title>Speeding up the Debian installer using eatmydata and dpkg-divert</title>
- <link>http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Speeding_up_the_Debian_installer_using_eatmydata_and_dpkg_divert.html</guid>
- <pubDate>Tue, 16 Sep 2014 14:00:00 +0200</pubDate>
- <description><p>The <a href="https://www.debian.org/">Debian</a> installer could be
-a lot quicker. When we install more than 2000 packages in
-<a href="http://www.skolelinux.org/">Skolelinux / Debian Edu</a> using
-tasksel in the installer, unpacking the binary packages take forever.
-A part of the slow I/O issue was discussed in
-<a href="https://bugs.debian.org/613428">bug #613428</a> about too
-much file system sync-ing done by dpkg, which is the package
-responsible for unpacking the binary packages. Other parts (like code
-executed by postinst scripts) might also sync to disk during
-installation. All this sync-ing to disk do not really make sense to
-me. If the machine crash half-way through, I start over, I do not try
-to salvage the half installed system. So the failure sync-ing is
-supposed to protect against, hardware or system crash, is not really
-relevant while the installer is running.</p>
-
-<p>A few days ago, I thought of a way to get rid of all the file
-system sync()-ing in a fairly non-intrusive way, without the need to
-change the code in several packages. The idea is not new, but I have
-not heard anyone propose the approach using dpkg-divert before. It
-depend on the small and clever package
-<a href="https://packages.qa.debian.org/eatmydata">eatmydata</a>, which
-uses LD_PRELOAD to replace the system functions for syncing data to
-disk with functions doing nothing, thus allowing programs to live
-dangerous while speeding up disk I/O significantly. Instead of
-modifying the implementation of dpkg, apt and tasksel (which are the
-packages responsible for selecting, fetching and installing packages),
-it occurred to me that we could just divert the programs away, replace
-them with a simple shell wrapper calling
-"eatmydata&nbsp;$program&nbsp;$@", to get the same effect.
-Two days ago I decided to test the idea, and wrapped up a simple
-implementation for the Debian Edu udeb.</p>
-
-<p>The effect was stunning. In my first test it reduced the running
-time of the pkgsel step (installing tasks) from 64 to less than 44
-minutes (20 minutes shaved off the installation) on an old Dell
-Latitude D505 machine. I am not quite sure what the optimised time
-would have been, as I messed up the testing a bit, causing the debconf
-priority to get low enough for two questions to pop up during
-installation. As soon as I saw the questions I moved the installation
-along, but do not know how long the question were holding up the
-installation. I did some more measurements using Debian Edu Jessie,
-and got these results. The time measured is the time stamp in
-/var/log/syslog between the "pkgsel: starting tasksel" and the
-"pkgsel: finishing up" lines, if you want to do the same measurement
-yourself. In Debian Edu, the tasksel dialog do not show up, and the
-timing thus do not depend on how quickly the user handle the tasksel
-dialog.</p>
-
-<p><table>
-
-<tr>
-<th>Machine/setup</th>
-<th>Original tasksel</th>
-<th>Optimised tasksel</th>
-<th>Reduction</th>
-</tr>
-
-<tr>
-<td>Latitude D505 Main+LTSP LXDE</td>
-<td>64 min (07:46-08:50)</td>
-<td><44 min (11:27-12:11)</td>
-<td>>20 min 18%</td>
-</tr>
-
-<tr>
-<td>Latitude D505 Roaming LXDE</td>
-<td>57 min (08:48-09:45)</td>
-<td>34 min (07:43-08:17)</td>
-<td>23 min 40%</td>
-</tr>
-
-<tr>
-<td>Latitude D505 Minimal</td>
-<td>22 min (10:37-10:59)</td>
-<td>11 min (11:16-11:27)</td>
-<td>11 min 50%</td>
-</tr>
-
-<tr>
-<td>Thinkpad X200 Minimal</td>
-<td>6 min (08:19-08:25)</td>
-<td>4 min (08:04-08:08)</td>
-<td>2 min 33%</td>
-</tr>
-
-<tr>
-<td>Thinkpad X200 Roaming KDE</td>
-<td>19 min (09:21-09:40)</td>
-<td>15 min (10:25-10:40)</td>
-<td>4 min 21%</td>
-</tr>
-
-</table></p>
-
-<p>The test is done using a netinst ISO on a USB stick, so some of the
-time is spent downloading packages. The connection to the Internet
-was 100Mbit/s during testing, so downloading should not be a
-significant factor in the measurement. Download typically took a few
-seconds to a few minutes, depending on the amount of packages being
-installed.</p>
-
-<p>The speedup is implemented by using two hooks in
-<a href="https://www.debian.org/devel/debian-installer/">Debian
-Installer</a>, the pre-pkgsel.d hook to set up the diverts, and the
-finish-install.d hook to remove the divert at the end of the
-installation. I picked the pre-pkgsel.d hook instead of the
-post-base-installer.d hook because I test using an ISO without the
-eatmydata package included, and the post-base-installer.d hook in
-Debian Edu can only operate on packages included in the ISO. The
-negative effect of this is that I am unable to activate this
-optimization for the kernel installation step in d-i. If the code is
-moved to the post-base-installer.d hook, the speedup would be larger
-for the entire installation.</p>
-
-<p>I've implemented this in the
-<a href="https://packages.qa.debian.org/debian-edu-install">debian-edu-install</a>
-git repository, and plan to provide the optimization as part of the
-Debian Edu installation. If you want to test this yourself, you can
-create two files in the installer (or in an udeb). One shell script
-need do go into /usr/lib/pre-pkgsel.d/, with content like this:</p>
-
-<p><blockquote><pre>
-#!/bin/sh
-set -e
-. /usr/share/debconf/confmodule
-info() {
- logger -t my-pkgsel "info: $*"
-}
-error() {
- logger -t my-pkgsel "error: $*"
-}
-override_install() {
- apt-install eatmydata || true
- if [ -x /target/usr/bin/eatmydata ] ; then
- for bin in dpkg apt-get aptitude tasksel ; do
- file=/usr/bin/$bin
- # Test that the file exist and have not been diverted already.
- if [ -f /target$file ] ; then
- info "diverting $file using eatmydata"
- printf "#!/bin/sh\neatmydata $bin.distrib \"\$@\"\n" \
- > /target$file.edu
- chmod 755 /target$file.edu
- in-target dpkg-divert --package debian-edu-config \
- --rename --quiet --add $file
- ln -sf ./$bin.edu /target$file
- else
- error "unable to divert $file, as it is missing."
- fi
- done
- else
- error "unable to find /usr/bin/eatmydata after installing the eatmydata pacage"
- fi
-}
-
-override_install
-</pre></blockquote></p>
-
-<p>To clean up, another shell script should go into
-/usr/lib/finish-install.d/ with code like this:
-
-<p><blockquote><pre>
-#! /bin/sh -e
-. /usr/share/debconf/confmodule
-error() {
- logger -t my-finish-install "error: $@"
-}
-remove_install_override() {
- for bin in dpkg apt-get aptitude tasksel ; do
- file=/usr/bin/$bin
- if [ -x /target$file.edu ] ; then
- rm /target$file
- in-target dpkg-divert --package debian-edu-config \
- --rename --quiet --remove $file
- rm /target$file.edu
- else
- error "Missing divert for $file."
- fi
- done
- sync # Flush file buffers before continuing
-}
-
-remove_install_override
-</pre></blockquote></p>
-
-<p>In Debian Edu, I placed both code fragments in a separate script
-edu-eatmydata-install and call it from the pre-pkgsel.d and
-finish-install.d scripts.</p>
-
-<p>By now you might ask if this change should get into the normal
-Debian installer too? I suspect it should, but am not sure the
-current debian-installer coordinators find it useful enough. It also
-depend on the side effects of the change. I'm not aware of any, but I
-guess we will see if the change is safe after some more testing.
-Perhaps there is some package in Debian depending on sync() and
-fsync() having effect? Perhaps it should go into its own udeb, to
-allow those of us wanting to enable it to do so without affecting
-everyone.</p>
-
-<p>Update 2014-09-24: Since a few days ago, enabling this optimization
-will break installation of all programs using gnutls because of
-<a href="https://bugs.debian.org/702711">bug #702711</a>. An updated
-eatmydata package in Debian will solve it.</p>
-
-<p>Update 2014-10-17: The bug mentioned above is fixed in testing and
-the optimization work again. And I have discovered that the
-dpkg-divert trick is not really needed and implemented a slightly
-simpler approach as part of the debian-edu-install package. See
-tools/edu-eatmydata-install in the source package.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff