When I get a new laptop, the battery life time at the start is OK.
-But this do not last. The last few laptops gave me a feeling that
-within a year, the life time is just a fraction of what it used to be,
-and it slowly become painful to use the laptop without power connected
-all the time. Because of this, when I got a new Thinkpad X230 laptop
-about two years ago, I decided to monitor its battery state to have
-more hard facts when the battery started to fail.
-
-

-
-
First I tried to find a sensible Debian package to record the
-battery status, assuming that this must be a problem already handled
-by someone else. I found
-battery-stats,
-which collects statistics from the battery, but it was completely
-broken. I sent a few suggestions to the maintainer, but decided to
-write my own collector as a shell script while I waited for feedback
-from him. Via
-a
-blog post about the battery development on a MacBook Air I also
-discovered
-batlog, not
-available in Debian.
-
-
I started my collector 2013-07-15, and it has been collecting
-battery stats ever since. Now my
-/var/log/hjemmenett-battery-status.log file contain around 115,000
-measurements, from the time the battery was working great until now,
-when it is unable to charge above 7% of original capacity. My
-collector shell script is quite simple and look like this:
-
-
-#!/bin/sh
-# Inspired by
-# http://www.ifweassume.com/2013/08/the-de-evolution-of-my-laptop-battery.html
-# See also
-# http://blog.sleeplessbeastie.eu/2013/01/02/debian-how-to-monitor-battery-capacity/
-logfile=/var/log/hjemmenett-battery-status.log
-
-files="manufacturer model_name technology serial_number \
- energy_full energy_full_design energy_now cycle_count status"
-
-if [ ! -e "$logfile" ] ; then
- (
- printf "timestamp,"
- for f in $files; do
- printf "%s," $f
- done
- echo
- ) > "$logfile"
-fi
-
-log_battery() {
- # Print complete message in one echo call, to avoid race condition
- # when several log processes run in parallel.
- msg=$(printf "%s," $(date +%s); \
- for f in $files; do \
- printf "%s," $(cat $f); \
- done)
- echo "$msg"
-}
-
-cd /sys/class/power_supply
-
-for bat in BAT*; do
- (cd $bat && log_battery >> "$logfile")
-done
-
-
-
The script is called when the power management system detect a
-change in the power status (power plug in or out), and when going into
-and out of hibernation and suspend. In addition, it collect a value
-every 10 minutes. This make it possible for me know when the battery
-is discharging, charging and how the maximum charge change over time.
-The code for the Debian package
-is now
-available on github.
-
-
The collected log file look like this:
-
-
-timestamp,manufacturer,model_name,technology,serial_number,energy_full,energy_full_design,energy_now,cycle_count,status,
-1376591133,LGC,45N1025,Li-ion,974,62800000,62160000,39050000,0,Discharging,
-[...]
-1443090528,LGC,45N1025,Li-ion,974,4900000,62160000,4900000,0,Full,
-1443090601,LGC,45N1025,Li-ion,974,4900000,62160000,4900000,0,Full,
-
-
-
I wrote a small script to create a graph of the charge development
-over time. This graph depicted above show the slow death of my laptop
-battery.
-
-
But why is this happening? Why are my laptop batteries always
-dying in a year or two, while the batteries of space probes and
-satellites keep working year after year. If we are to believe
-Battery
-University, the cause is me charging the battery whenever I have a
-chance, and the fix is to not charge the Lithium-ion batteries to 100%
-all the time, but to stay below 90% of full charge most of the time.
-I've been told that the Tesla electric cars
-limit
-the charge of their batteries to 80%, with the option to charge to
-100% when preparing for a longer trip (not that I would want a car
-like Tesla where rights to privacy is abandoned, but that is another
-story), which I guess is the option we should have for laptops on
-Linux too.
-
-
Is there a good and generic way with Linux to tell the battery to
-stop charging at 80%, unless requested to charge to 100% once in
-preparation for a longer trip? I found
-one
-recipe on askubuntu for Ubuntu to limit charging on Thinkpad to
-80%, but could not get it to work (kernel module refused to
-load).
-
-
I wonder why the battery capacity was reported to be more than 100%
-at the start. I also wonder why the "full capacity" increases some
-times, and if it is possible to repeat the process to get the battery
-back to design capacity. And I wonder if the discharge and charge
-speed change over time, or if this stay the same. I did not yet try
-to write a tool to calculate the derivative values of the battery
-level, but suspect some interesting insights might be learned from
-those.
-
-
Update 2015-09-24: I got a tip to install the packages
-acpi-call-dkms and tlp (unfortunately missing in Debian stable)
-packages instead of the tp-smapi-dkms package I had tried to use
-initially, and use 'tlp setcharge 40 80' to change when charging start
-and stop. I've done so now, but expect my existing battery is toast
-and need to be replaced. The proposal is unfortunately Thinkpad
-specific.
+
+
10th June 2017
+
I am very happy to report that the
+Nikita Noark 5
+core project tagged its second release today. The free software
+solution is an implementation of the Norwegian archive standard Noark
+5 used by government offices in Norway. These were the changes in
+version 0.1.1 since version 0.1.0 (from NEWS.md):
+
+
+
+ - Continued work on the angularjs GUI, including document upload.
+ - Implemented correspondencepartPerson, correspondencepartUnit and
+ correspondencepartInternal
+ - Applied for coverity coverage and started submitting code on
+ regualr basis.
+ - Started fixing bugs reported by coverity
+ - Corrected and completed HATEOAS links to make sure entire API is
+ available via URLs in _links.
+ - Corrected all relation URLs to use trailing slash.
+ - Add initial support for storing data in ElasticSearch.
+ - Now able to receive and store uploaded files in the archive.
+ - Changed JSON output for object lists to have relations in _links.
+ - Improve JSON output for empty object lists.
+ - Now uses correct MIME type application/vnd.noark5-v4+json.
+ - Added support for docker container images.
+ - Added simple API browser implemented in JavaScript/Angular.
+ - Started on archive client implemented in JavaScript/Angular.
+ - Started on prototype to show the public mail journal.
+ - Improved performance by disabling Sprint FileWatcher.
+ - Added support for 'arkivskaper', 'saksmappe' and 'journalpost'.
+ - Added support for some metadata codelists.
+ - Added support for Cross-origin resource sharing (CORS).
+ - Changed login method from Basic Auth to JSON Web Token (RFC 7519)
+ style.
+ - Added support for GET-ing ny-* URLs.
+ - Added support for modifying entities using PUT and eTag.
+ - Added support for returning XML output on request.
+ - Removed support for English field and class names, limiting ourself
+ to the official names.
+ - ...
+
+
+
+
If this sound interesting to you, please contact us on IRC (#nikita
+on irc.freenode.net) or email
+(nikita-noark
+mailing list).
@@ -334,56 +333,99 @@ specific.
-
-
3rd September 2015
-
Creating a good looking book cover proved harder than I expected.
-I wanted to create a cover looking similar to the original cover of
-the
-Free
-Culture book we are translating to Norwegian, and I wanted it in
-vector format for high resolution printing. But my inkscape knowledge
-were not nearly good enough to pull that off.
-
-
But thanks to the great inkscape community, I was able to wrap up
-the cover yesterday evening. I asked on the
-#inkscape IRC channel
-on Freenode for help and clues, and Marc Jeanmougin (Mc-) volunteered
-to try to recreate it based on the PDF of the cover from the HTML
-version. Not only did he create a
-SVG document with
-the original and his vector version side by side, he even provided
-an instruction
-video explaining how he did it. But the instruction video is
-not easy to follow for an untrained inkscape user. The video is a
-recording on how he did it, and he is obviously very experienced as
-the menu selections are very quick and he mentioned on IRC that he did
-use some keyboard shortcuts that can't be seen on the video, but it
-give a good idea about the inkscape operations to use to create the
-stripes with the embossed copyright sign in the center.
-
-
I took his SVG file, copied the vector image and re-sized it to fit
-on the cover I was drawing. I am happy with the end result, and the
-current english version look like this:
-
-

-
-
I am not quite sure about the text on the back, but guess it will
-do. I picked three quotes from the official site for the book, and
-hope it will work to trigger the interest of potential readers. The
-Norwegian cover will look the same, but with the texts and bar code
-replaced with the Norwegian version.
-
-
The book is very close to being ready for publication, and I expect
-to upload the final draft to Lulu in the next few days and order a
-final proof reading copy to verify that everything look like it should
-before allowing everyone to order their own copy of Free Culture, in
-English or Norwegian Bokmål. I'm waiting to give the the productive
-proof readers a chance to complete their work.
+
+
7th June 2017
+
This is a copy of
+an
+email I posted to the nikita-noark mailing list. Please follow up
+there if you would like to discuss this topic. The background is that
+we are making a free software archive system based on the Norwegian
+Noark
+5 standard for government archives.
+
+
I've been wondering a bit lately how trusted timestamps could be
+stored in Noark 5.
+Trusted
+timestamps can be used to verify that some information
+(document/file/checksum/metadata) have not been changed since a
+specific time in the past. This is useful to verify the integrity of
+the documents in the archive.
+
+
Then it occured to me, perhaps the trusted timestamps could be
+stored as dokument variants (ie dokumentobjekt referered to from
+dokumentbeskrivelse) with the filename set to the hash it is
+stamping?
+
+
Given a "dokumentbeskrivelse" with an associated "dokumentobjekt",
+a new dokumentobjekt is associated with "dokumentbeskrivelse" with the
+same attributes as the stamped dokumentobjekt except these
+attributes:
+
+
+
+- format -> "RFC3161"
+
- mimeType -> "application/timestamp-reply"
+
- formatDetaljer -> "<source URL for timestamp service>"
+
- filenavn -> "<sjekksum>.tsr"
+
+
+
+
This assume a service following
+IETF RFC 3161 is
+used, which specifiy the given MIME type for replies and the .tsr file
+ending for the content of such trusted timestamp. As far as I can
+tell from the Noark 5 specifications, it is OK to have several
+variants/renderings of a dokument attached to a given
+dokumentbeskrivelse objekt. It might be stretching it a bit to make
+some of these variants represent crypto-signatures useful for
+verifying the document integrity instead of representing the dokument
+itself.
+
+
Using the source of the service in formatDetaljer allow several
+timestamping services to be used. This is useful to spread the risk
+of key compromise over several organisations. It would only be a
+problem to trust the timestamps if all of the organisations are
+compromised.
+
+
The following oneliner on Linux can be used to generate the tsr
+file. $input is the path to the file to checksum, and $sha256 is the
+SHA-256 checksum of the file (ie the ".tsr" value mentioned
+above).
+
+
+openssl ts -query -data "$inputfile" -cert -sha256 -no_nonce \
+ | curl -s -H "Content-Type: application/timestamp-query" \
+ --data-binary "@-" http://zeitstempel.dfn.de > $sha256.tsr
+
+
+
To verify the timestamp, you first need to download the public key
+of the trusted timestamp service, for example using this command:
+
+
+wget -O ca-cert.txt \
+ https://pki.pca.dfn.de/global-services-ca/pub/cacert/chain.txt
+
+
+
Note, the public key should be stored alongside the timestamps in
+the archive to make sure it is also available 100 years from now. It
+is probably a good idea to standardise how and were to store such
+public keys, to make it easier to find for those trying to verify
+documents 100 or 1000 years from now. :)
+
+
The verification itself is a simple openssl command:
+
+
+openssl ts -verify -data $inputfile -in $sha256.tsr \
+ -CAfile ca-cert.txt -text
+
+
+
Is there any reason this approach would not work? Is it somehow against
+the Noark 5 specification?
@@ -391,37 +433,61 @@ proof readers a chance to complete their work.
-
-
19th August 2015
-
Today, finally, my first printed draft edition of the Norwegian
-translation of Free Culture I have been working on for the last few
-years arrived in the mail. I had to fake a cover to get the interior
-printed, and the exterior of the book look awful, but that is
-irrelevant at this point. I asked for a printed pocket book version
-to get an idea about the font sizes and paper format as well as how
-good the figures and images look in print, but also to test what the
-pocket book version would look like. After receiving the 500 page
-pocket book, it became obvious to me that that pocket book size is too
-small for this book. I believe the book is too thick, and several
-tables and figures do not look good in the size they get with that
-small page sizes. I believe I will go with the 5.5x8.5 inch size
-instead. A surprise discovery from the paper version was how bad the
-URLs look in print. They are very hard to read in the colophon page.
-The URLs are red in the PDF, but light gray on paper. I need to
-change the color of links somehow to look better. But there is a
-printed book in my hand, and it feels great. :)
-
-
Now I only need to fix the cover, wrap up the postscript with the
-store behind the book, and collect the last corrections from the proof
-readers before the book is ready for proper printing. Cover artists
-willing to work for free and create a Creative Commons licensed vector
-file looking similar to the original is most welcome, as my skills as
-a graphics designer are mostly missing.
+
+
3rd June 2017
+
Aftenposten
+melder i dag om feil i eksamensoppgavene for eksamen i politikk og
+menneskerettigheter, der teksten i bokmåls og nynorskutgaven ikke var
+like. Oppgaveteksten er gjengitt i artikkelen, og jeg ble nysgjerring
+på om den fri oversetterløsningen
+Apertium ville gjort en bedre
+jobb enn Utdanningsdirektoratet. Det kan se slik ut.
+
+
Her er bokmålsoppgaven fra eksamenen:
+
+
+Drøft utfordringene knyttet til nasjonalstatenes og andre aktørers
+rolle og muligheter til å håndtere internasjonale utfordringer, som
+for eksempel flykningekrisen.
+
+Vedlegge er eksempler på tekster som kan gi relevante perspektiver
+på temaet:
+
+- Flykningeregnskapet 2016, UNHCR og IDMC
+
- «Grenseløst Europa for fall» A-Magasinet, 26. november 2015
+
+
+
+
+
Dette oversetter Apertium slik:
+
+
+Drøft utfordringane knytte til nasjonalstatane sine og rolla til
+andre aktørar og høve til å handtera internasjonale utfordringar, som
+til dømes *flykningekrisen.
+
+Vedleggja er døme på tekster som kan gje relevante perspektiv på
+temaet:
+
+
+- *Flykningeregnskapet 2016, *UNHCR og *IDMC
+- «*Grenseløst Europa for fall» A-Magasinet, 26. november 2015
+
+
+
+
+
Ord som ikke ble forstått er markert med stjerne (*), og trenger
+ekstra språksjekk. Men ingen ord er forsvunnet, slik det var i
+oppgaven elevene fikk presentert på eksamen. Jeg mistenker dog at
+"andre aktørers rolle og muligheter til ..." burde vært oversatt til
+"rolla til andre aktørar og deira høve til ..." eller noe slikt, men
+det er kanskje flisespikking. Det understreker vel bare at det alltid
+trengs korrekturlesning etter automatisk oversettelse.
@@ -429,68 +495,67 @@ a graphics designer are mostly missing.
-
-
9th August 2015
-
Typesetting a book is harder than I hoped. As the translation is
-mostly done, and a volunteer proof reader was going to check the text
-on paper, it was time this summer to focus on formatting my translated
-docbook based version of the
-Free Culture book by Lawrence
-Lessig. I've been trying to get both docboox-xsl+fop and dblatex to
-give me a good looking PDF, but in the end I went with dblatex, because
-its Debian maintainer and upstream developer were responsive and very
-helpful in solving my formatting challenges.
-
-
Last night, I finally managed to create a PDF that no longer made
-Lulu.com complain after uploading,
-and I ordered a text version of the book on paper. It is lacking a
-proper book cover and is not tagged with the correct ISBN number, but
-should give me an idea what the finished book will look like.
-
-
Instead of using Lulu, I did consider printing the book using
-CreateSpace, but ended up
-using Lulu because it had smaller book size options (CreateSpace seem
-to lack pocket book with extended distribution). I looked for a
-similar service in Norway, but have not seen anything so far. Please
-let me know if I am missing out on something here.
-
-
But I still struggle to decide the book size. Should I go for
-pocket book (4.25x6.875 inches / 10.8x17.5 cm) with 556 pages, Digest
-(5.5x8.5 inches / 14x21.6 cm) with 323 pages or US Trade (6x8 inches /
-15.3x22.9 cm) with 280 pages? Fewer pager give a cheaper book, and a
-smaller book is easier to carry around. The test book I ordered was
-pocket book sized, to give me an idea how well that fit in my hand,
-but I suspect I will end up using a digest sized book in the end to
-bring the prize down further.
-
-
My biggest challenge at the moment is making nice cover art. My
-inkscape skills are not yet up to the task of replicating the original
-cover in SVG format. I also need to figure out what to write about
-the book on the back (will most likely use the same text as the
-description on web based book stores). I would love help with this,
-if you are willing to license the art source and final version using
-the same CC license as the book. My artistic skills are not really up
-to the task.
-
-
I plan to publish the book in both English and Norwegian and on
-paper, in PDF form as well as EPUB and MOBI format. The current
-status can as usual be found on
-github
-in the archive/ directory. So far I have spent all time on making the
-PDF version look good. Someone should probably do the same with the
-dbtoepub generated e-book. Help is definitely needed here, as I
-expect to run out of steem before I find time to improve the epub
-formatting.
-
-
Please let me know via github if you find typos in the book or
-discover translations that should be improved. The final proof
-reading is being done right now, and I expect to publish the finished
-result in a few months.
+
+
27th April 2017
+
I disse dager, med frist 1. mai, har Riksarkivaren ute en høring på
+sin forskrift. Som en kan se er det ikke mye tid igjen før fristen
+som går ut på søndag. Denne forskriften er det som lister opp hvilke
+formater det er greit å arkivere i
+Noark
+5-løsninger i Norge.
+
+
Jeg fant høringsdokumentene hos
+Norsk
+Arkivråd etter å ha blitt tipset på epostlisten til
+fri
+programvareprosjektet Nikita Noark5-Core, som lager et Noark 5
+Tjenestegresesnitt. Jeg er involvert i Nikita-prosjektet og takket
+være min interesse for tjenestegrensesnittsprosjektet har jeg lest en
+god del Noark 5-relaterte dokumenter, og til min overraskelse oppdaget
+at standard epost ikke er på listen over godkjente formater som kan
+arkiveres. Høringen med frist søndag er en glimrende mulighet til å
+forsøke å gjøre noe med det. Jeg holder på med
+egen
+høringsuttalelse, og lurer på om andre er interessert i å støtte
+forslaget om å tillate arkivering av epost som epost i arkivet.
+
+
Er du igang med å skrive egen høringsuttalelse allerede? I så fall
+kan du jo vurdere å ta med en formulering om epost-lagring. Jeg tror
+ikke det trengs så mye. Her et kort forslag til tekst:
+
+
+
+ Viser til høring sendt ut 2017-02-17 (Riksarkivarens referanse
+ 2016/9840 HELHJO), og tillater oss å sende inn noen innspill om
+ revisjon av Forskrift om utfyllende tekniske og arkivfaglige
+ bestemmelser om behandling av offentlige arkiver (Riksarkivarens
+ forskrift).
+
+ Svært mye av vår kommuikasjon foregår i dag på e-post. Vi
+ foreslår derfor at Internett-e-post, slik det er beskrevet i IETF
+ RFC 5322,
+ https://tools.ietf.org/html/rfc5322. bør
+ inn som godkjent dokumentformat. Vi foreslår at forskriftens
+ oversikt over godkjente dokumentformater ved innlevering i § 5-16
+ endres til å ta med Internett-e-post.
+
+
+
+
Som del av arbeidet med tjenestegrensesnitt har vi testet hvordan
+epost kan lagres i en Noark 5-struktur, og holder på å skrive et
+forslag om hvordan dette kan gjøres som vil bli sendt over til
+arkivverket så snart det er ferdig. De som er interesserte kan
+følge
+fremdriften på web.
+
+
Oppdatering 2017-04-28: I dag ble høringuttalelsen jeg skrev
+ sendt
+ inn av foreningen NUUG.
@@ -498,63 +563,52 @@ result in a few months.
-
-
16th July 2015
-
I'm still working on the Norwegian version of the
-Free Culture book by Lawrence
-Lessig, and is now working on the final typesetting and layout.
-One of the features I want to get the structure similar to the
-original book is to typeset the footnotes as endnotes in the notes
-chapter. Based on the
-feedback from the Debian
-maintainer and the dblatex developer, I came up with this recipe I
-would like to share with you. The proposal was to create a new LaTeX
-class file and add the LaTeX code there, but this is not always
-practical, when I want to be able to replace the class using a make
-file variable. So my proposal misuses the latex.begindocument XSL
-parameter value, to get a small fragment into the correct location in
-the generated LaTeX File.
-
-
First, decide where in the DocBook document to place the endnotes,
-and add this text there:
-
-
-<?latex \theendnotes ?>
-
-
-
Next, create a xsl stylesheet file dblatex-endnotes.xsl to add the
-code needed to add the endnote instructions in the preamble of the
-generated LaTeX document, with content like this:
-
-
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version='1.0'>
- <xsl:param name="latex.begindocument">
- <xsl:text>
-\usepackage{endnotes}
-\let\footnote=\endnote
-\def\enoteheading{\mbox{}\par\vskip-\baselineskip }
-\begin{document}
- </xsl:text>
- </xsl:param>
-</xsl:stylesheet>
-
-
-
Finally, load this xsl file when running dblatex, for example like
-this:
-
-
-dblatex --xsl-user=dblatex-endnotes.xsl freeculture.nb.xml
-
-
-
The end result can be seen on github, where
-my
-book project is located.
+
+
20th April 2017
+
Jeg oppdaget i dag at nettstedet som
+publiserer offentlige postjournaler fra statlige etater, OEP, har
+begynt å blokkerer enkelte typer webklienter fra å få tilgang. Vet
+ikke hvor mange det gjelder, men det gjelder i hvert fall libwww-perl
+og curl. For å teste selv, kjør følgende:
+
+
+% curl -v -s https://www.oep.no/pub/report.xhtml?reportId=3 2>&1 |grep '< HTTP'
+< HTTP/1.1 404 Not Found
+% curl -v -s --header 'User-Agent:Opera/12.0' https://www.oep.no/pub/report.xhtml?reportId=3 2>&1 |grep '< HTTP'
+< HTTP/1.1 200 OK
+%
+
+
+
Her kan en se at tjenesten gir «404 Not Found» for curl i
+standardoppsettet, mens den gir «200 OK» hvis curl hevder å være Opera
+versjon 12.0. Offentlig elektronisk postjournal startet blokkeringen
+2017-03-02.
+
+
Blokkeringen vil gjøre det litt vanskeligere å maskinelt hente
+informasjon fra oep.no. Kan blokkeringen være gjort for å hindre
+automatisert innsamling av informasjon fra OEP, slik Pressens
+Offentlighetsutvalg gjorde for å dokumentere hvordan departementene
+hindrer innsyn i
+rapporten
+«Slik hindrer departementer innsyn» som ble publiserte i januar
+2017. Det virker usannsynlig, da det jo er trivielt å bytte
+User-Agent til noe nytt.
+
+
Finnes det juridisk grunnlag for det offentlige å diskriminere
+webklienter slik det gjøres her? Der tilgang gis eller ikke alt etter
+hva klienten sier at den heter? Da OEP eies av DIFI og driftes av
+Basefarm, finnes det kanskje noen dokumenter sendt mellom disse to
+aktørene man kan be om innsyn i for å forstå hva som har skjedd. Men
+postjournalen
+til DIFI viser kun to dokumenter det siste året mellom DIFI og
+Basefarm.
+Mimes brønn neste,
+tenker jeg.
@@ -562,38 +616,101 @@ book project is located.
-
-
9th July 2015
-
I går fikk vi endelig lansert en norsk version av mySocietys
-WhatDoTheyKnow.
-Tjenesten heter Mimes brønn, og ble
-annonsert
-av NUUG via blogg, epost og twitter til NUUG-assosierte personer.
-Det har tatt noen år, men de siste dagene fikk vi endelig tid til å få
-på plass de siste bitene. Vi er to, Gorm og meg selv, som har vært
-primus motor for det hele, men vi har fått hjelp med oversettelser og
-oppsett fra mange flere. Jeg vil si tusen takk til hver og en av dem,
-og er veldig fornøyd med at vi klarte å få tjenesten opp å kjøre før
-ferietiden slo inn for fullt.
-
-
Vi er usikker på hvor mye belastning den virtuelle maskinen der
-tjenesten kjører klarer, så vi har lansert litt i det stille og ikke
-til for mange folk for å se hvordan maskinen klarer seg over sommeren,
-før vi går mer aktivt ut og annonserer til høsten. Ta en titt, og se
-om du kanskje har et spørsmål til det offentlige som er egnet å sende
-inn via Mimes brønn.
-
-
Hvis du lurer på hva i alle dager en slik tjenestes kan brukes til,
-anbefaler jeg deg å se
-TED-foredraget til
-Heather Brook om hvordan hun brukte WhatDoTheyKnow til å lære
-hvordan offentlige midler ble misbrukt. Det er en inspirerende
-historie.
+
+
19th March 2017
+
The Nikita
+Noark 5 core project is implementing the Norwegian standard for
+keeping an electronic archive of government documents.
+The
+Noark 5 standard document the requirement for data systems used by
+the archives in the Norwegian government, and the Noark 5 web interface
+specification document a REST web service for storing, searching and
+retrieving documents and metadata in such archive. I've been involved
+in the project since a few weeks before Christmas, when the Norwegian
+Unix User Group
+announced
+it supported the project. I believe this is an important project,
+and hope it can make it possible for the government archives in the
+future to use free software to keep the archives we citizens depend
+on. But as I do not hold such archive myself, personally my first use
+case is to store and analyse public mail journal metadata published
+from the government. I find it useful to have a clear use case in
+mind when developing, to make sure the system scratches one of my
+itches.
+
+
If you would like to help make sure there is a free software
+alternatives for the archives, please join our IRC channel
+(#nikita on
+irc.freenode.net) and
+the
+project mailing list.
+
+
When I got involved, the web service could store metadata about
+documents. But a few weeks ago, a new milestone was reached when it
+became possible to store full text documents too. Yesterday, I
+completed an implementation of a command line tool
+archive-pdf to upload a PDF file to the archive using this
+API. The tool is very simple at the moment, and find existing
+fonds, series and
+files while asking the user to select which one to use if more than
+one exist. Once a file is identified, the PDF is associated with the
+file and uploaded, using the title extracted from the PDF itself. The
+process is fairly similar to visiting the archive, opening a cabinet,
+locating a file and storing a piece of paper in the archive. Here is
+a test run directly after populating the database with test data using
+our API tester:
+
+
+~/src//noark5-tester$ ./archive-pdf mangelmelding/mangler.pdf
+using arkiv: Title of the test fonds created 2017-03-18T23:49:32.103446
+using arkivdel: Title of the test series created 2017-03-18T23:49:32.103446
+
+ 0 - Title of the test case file created 2017-03-18T23:49:32.103446
+ 1 - Title of the test file created 2017-03-18T23:49:32.103446
+Select which mappe you want (or search term): 0
+Uploading mangelmelding/mangler.pdf
+ PDF title: Mangler i spesifikasjonsdokumentet for NOARK 5 Tjenestegrensesnitt
+ File 2017/1: Title of the test case file created 2017-03-18T23:49:32.103446
+~/src//noark5-tester$
+
+
+
You can see here how the fonds (arkiv) and serie (arkivdel) only had
+one option, while the user need to choose which file (mappe) to use
+among the two created by the API tester. The archive-pdf
+tool can be found in the git repository for the API tester.
+
+
In the project, I have been mostly working on
+the API
+tester so far, while getting to know the code base. The API
+tester currently use
+the HATEOAS links
+to traverse the entire exposed service API and verify that the exposed
+operations and objects match the specification, as well as trying to
+create objects holding metadata and uploading a simple XML file to
+store. The tester has proved very useful for finding flaws in our
+implementation, as well as flaws in the reference site and the
+specification.
+
+
The test document I uploaded is a summary of all the specification
+defects we have collected so far while implementing the web service.
+There are several unclear and conflicting parts of the specification,
+and we have
+started
+writing down the questions we get from implementing it. We use a
+format inspired by how The
+Austin Group collect defect reports for the POSIX standard with
+their
+instructions for the MANTIS defect tracker system, in lack of an official way to structure defect reports for Noark 5 (our first submitted defect report was a request for a procedure for submitting defect reports :).
+
+
The Nikita project is implemented using Java and Spring, and is
+fairly easy to get up and running using Docker containers for those
+that want to test the current code base. The API tester is
+implemented in Python.
@@ -608,6 +725,54 @@ historie.
Archive