The movie "The -Internet's Own Boy: The Story of Aaron Swartz" is both inspiring -and depressing at the same time. The work of Aaron Swartz has -inspired me in my work, and I am grateful of all the improvements he -was able to initiate or complete. I wish I am able to do as much good -in my life as he did in his. Every minute of this 1:45 long movie is -inspiring in documenting how much impact a single person can have on -improving the society and this world. And it is depressing in -documenting how the law enforcement of USA (and other countries) is -corrupted to a point where they can push a bright kid to his death for -downloading too many scientific articles. Aron is dead. Let us all -weep.
- -The movie is also available on -Youtube. I -wish there were Norwegian subtitles available, so I could show it to -my parents.
+ +On friday, I came across an interesting article in the Norwegian +web based ICT news magazine digi.no on +how +to collect the IMSI numbers of nearby cell phones using the cheap +DVB-T software defined radios. The article refered to instructions +and a recipe by +Keld Norman on Youtube on how to make a simple $7 IMSI Catcher, and I decided to test them out.
+ +The instructions said to use Ubuntu, install pip using apt (to +bypass apt), use pip to install pybombs (to bypass both apt and pip), +and the ask pybombs to fetch and build everything you need from +scratch. I wanted to see if I could do the same on the most recent +Debian packages, but this did not work because pybombs tried to build +stuff that no longer build with the most recent openssl library or +some other version skew problem. While trying to get this recipe +working, I learned that the apt->pip->pybombs route was a long detour, +and the only piece of software dependency missing in Debian was the +gr-gsm package. I also found out that the lead upstream developer of +gr-gsm (the name stand for GNU Radio GSM) project already had a set of +Debian packages provided in an Ubuntu PPA repository. All I needed to +do was to dget the Debian source package and built it.
+ +The IMSI collector is a python script listening for packages on the +loopback network device and printing to the terminal some specific GSM +packages with IMSI numbers in them. The code is fairly short and easy +to understand. The reason this work is because gr-gsm include a tool +to read GSM data from a software defined radio like a DVB-T USB stick +and other software defined radios, decode them and inject them into a +network device on your Linux machine (using the loopback device by +default). This proved to work just fine, and I've been testing the +collector for a few days now.
+ +The updated and simpler recipe is thus to
+ +-
+
+
- start with a Debian machine running Stretch or newer, + +
- build and install the gr-gsm package available from +http://ppa.launchpad.net/ptrkrysik/gr-gsm/ubuntu/pool/main/g/gr-gsm/, + +
- clone the git repostory from https://github.com/Oros42/IMSI-catcher, + +
- run grgsm_livemon and adjust the frequency until the terminal +where it was started is filled with a stream of text (meaning you +found a GSM station). + +
- go into the IMSI-catcher directory and run 'sudo python simple_IMSI-catcher.py' to extract the IMSI numbers. + +
To make it even easier in the future to get this sniffer up and +running, I decided to package +the gr-gsm project +for Debian (WNPP +#871055), and the package was uploaded into the NEW queue today. +Luckily the gnuradio maintainer has promised to help me, as I do not +know much about gnuradio stuff yet.
+ +I doubt this "IMSI cacher" is anywhere near as powerfull as +commercial tools like +The +Spy Phone Portable IMSI / IMEI Catcher or the +Harris +Stingray, but I hope the existance of cheap alternatives can make +more people realise how their whereabouts when carrying a cell phone +is easily tracked. Seeing the data flow on the screen, realizing that +I live close to a police station and knowing that the police is also +wearing cell phones, I wonder how hard it would be for criminals to +track the position of the police officers to discover when there are +police near by, or for foreign military forces to track the location +of the Norwegian military forces, or for anyone to track the location +of government officials...
+ +It is worth noting that the data reported by the IMSI-catcher +script mentioned above is only a fraction of the data broadcasted on +the GSM network. It will only collect one frequency at the time, +while a typical phone will be using several frequencies, and not all +phones will be using the frequencies tracked by the grgsm_livemod +program. Also, there is a lot of radio chatter being ignored by the +simple_IMSI-catcher script, which would be collected by extending the +parser code. I wonder if gr-gsm can be set up to listen to more than +one frequency?
Jeg lot meg fascinere av -en -artikkel i Aftenposten der det fortelles at «over 600 telefoner som -benyttes av stortingsrepresentanter, rådgivere og ansatte på -Stortinget, kan «fjernstyres» ved hjelp av -programvaren -Airwatch, et såkalte MDM-program (Mobile Device Managment)». Det -hele bagatelliseres av Stortingets IT-stab, men det er i hovedsak på -grunn av at journalisten ikke stiller de relevante spørsmålene. For -meg er det relevante spørsmålet hvem som har lovlig tilgang (i henhold -til lokal lovgiving, dvs. i hvert fall i Norge, Sverige, UK og USA) -til informasjon om og på telefonene, og hvor enkelt det er å skaffe -seg tilgang til hvor mobilene befinner seg og informasjon som befinner -seg på telefonene ved hjelp av utro tjenere, trusler, innbrudd og -andre ulovlige metoder.
- -Bruken av AirWatch betyr i realiteten at USAs etteretning og -politimyndigheter har full tilgang til stortingets mobiltelefoner, -inkludert posisjon og innhold, takket være -FISAAA-loven -og -"National -Security Letters" og det enkle faktum at selskapet -AirWatch er kontrollert av et -selskap i USA. I tillegg er det kjent at flere lands -etterretningstjenester kan lytte på trafikken når den passerer -landegrensene.
- -Jeg har bedt om mer informasjon -fra -Stortinget om bruken av AirWatch via Mimes brønn så får vi se hva -de har å fortelle om saken. Fant ingenting om 'airwatch' i -postjournalen til Stortinget, så jeg trenger hjelp før jeg kan be om -innsyn i konkrete dokumenter.
- -Oppdatering 2015-10-07: Jeg er blitt spurt hvorfor jeg antar at -AirWatch-agenten rapporterer til USA og ikke direkte til Stortingets -egen infrastruktur. Det stemmer at det er teknisk mulig å sette -opp mobiltelefonene til å rapportere til datamaskiner som eies av -Stortinget. Jeg antar det rapporteres til AirWatch sine sentrale -tjenester basert på det jeg leste fra beskrivelsen av -Mobile -Device Management på AirWatch sine egne nettsider, koblet med at -det brukes en standard app som kan hentes fra "app-butikkene" for å få -tilgang. Enten må app-en settes opp individuelt hos Stortinget, eller -så får den beskjed fra AirWatch i USA om hvor den skal koble seg opp. -I det første tilfellet vil den ikke rapportere direkte til USA, men -til programvare utviklet av AirWatch som kjører på en maskin under -Stortingets kontroll. Det er litt bedre, men fortsatt vil det være -umulig for Stortinget å være sikker på hva programvaren som tar imot -forbindelser gjør. Jeg ser fra beskrivelsen av -Enterprice -Integration hos AirWatch at det er mulig å ha lokal installasjon, -og håper innsynsforespørsler mot Stortinget kan fortelle mer om -hvordan ting konkret fungerer der.
+ +I finally received a copy of the Norwegian Bokmål edition of +"The Debian Administrator's +Handbook". This test copy arrived in the mail a few days ago, and +I am very happy to hold the result in my hand. We spent around one and a half year translating it. This paperbook edition +is available +from lulu.com. If you buy it quickly, you save 25% on the list +price. The book is also available for download in electronic form as +PDF, EPUB and Mobipocket, as can be +read online +as a web page.
+ +This is the second book I publish (the first was the book +"Free Culture" by Lawrence Lessig +in +English, +French +and +Norwegian +Bokmål), and I am very excited to finally wrap up this +project. I hope +"Håndbok +for Debian-administratoren" will be well received.
As I wrap up the Norwegian version of -Free -Culture book by Lawrence Lessig (still waiting for my final proof -reading copy to arrive in the mail), my great -dblatex helper and -developer of the dblatex docbook processor, Benoît Guillon, decided a -to try to create a French version of the book. He started with the -French translation available from the -Wikilivres wiki -pages, and wrote a program to convert it into a PO file, allowing -the translation to be integrated into the po4a based framework I use -to create the Norwegian translation from the English edition. We meet -on the #dblatex IRC -channel to discuss the work. If you want to help create a French -edition, check out -his git -repository and join us on IRC. If the French edition look good, -we might publish it as a paper book on lulu.com. A French version of -the drawings and the cover need to be provided for this to happen.
+ +Jeg kom over teksten +«Killing +car privacy by federal mandate» av Leonid Reyzin på Freedom to +Tinker i dag, og det gleder meg å se en god gjennomgang om hvorfor det +er et urimelig inngrep i privatsfæren å la alle biler kringkaste sin +posisjon og bevegelse via radio. Det omtalte forslaget basert på +Dedicated Short Range Communication (DSRC) kalles Basic Safety Message +(BSM) i USA og Cooperative Awareness Message (CAM) i Europa, og det +norske Vegvesenet er en av de som ser ut til å kunne tenke seg å +pålegge alle biler å fjerne nok en bit av innbyggernes privatsfære. +Anbefaler alle å lese det som står der. + +
Mens jeg tittet litt på DSRC på biler i Norge kom jeg over et sitat +jeg synes er illustrativt for hvordan det offentlige Norge håndterer +problemstillinger rundt innbyggernes privatsfære i SINTEF-rapporten +«Informasjonssikkerhet +i AutoPASS-brikker» av Trond Foss:
+ ++«Rapporten ser ikke på informasjonssikkerhet knyttet til personlig + integritet.» ++ +
SÃ¥ enkelt kan det tydeligvis gjøres nÃ¥r en vurderer +informasjonssikkerheten. Det holder vel at folkene pÃ¥ toppen kan si +at «Personvernet er ivaretatt», som jo er den populære intetsigende +frasen som gjør at mange tror enkeltindividers integritet tas vare pÃ¥. +Sitatet fikk meg til Ã¥ undres pÃ¥ hvor ofte samme tilnærming, Ã¥ bare se +bort fra behovet for personlig itegritet, blir valgt nÃ¥r en velger Ã¥ +legge til rette for nok et inngrep i privatsfæren til personer i +Norge. Det er jo sjelden det fÃ¥r reaksjoner. Historien om +reaksjonene pÃ¥ Helse Sør-Ãsts tjenesteutsetting er jo sørgelig nok et +unntak og toppen av isfjellet, desverre. Tror jeg fortsatt takker nei +til bÃ¥de AutoPASS og holder meg sÃ¥ langt unna det norske helsevesenet +som jeg kan, inntil de har demonstrert og dokumentert at de verdsetter +individets privatsfære og personlige integritet høyere enn kortsiktig +gevist og samfunnsnytte.
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.
+ +It is pleasing to see that the work we put down in publishing new +editions of the classic Free +Culture book by the founder of the Creative Commons movement, +Lawrence Lessig, is still being appreciated. I had a look at the +latest sales numbers for the paper edition today. Not too impressive, +but happy to see some buyers still exist. All the revenue from the +books is sent to the Creative +Commons Corporation, and they receive the largest cut if you buy +directly from Lulu. Most books are sold via Amazon, with Ingram +second and only a small fraction directly from Lulu. The ebook +edition is available for free from +Github.
+ +Title / language | Quantity | ||
---|---|---|---|
2016 jan-jun | 2016 jul-dec | 2017 jan-may | |
Culture Libre / French | +3 | +6 | +15 | +
Fri kultur / Norwegian | +7 | +1 | +0 | +
Free Culture / English | +14 | +27 | +16 | +
Total | +24 | +34 | +31 | +
A bit sad to see the low sales number on the Norwegian edition, and +a bit surprising the English edition still selling so well.
+ +If you would like to translate and publish the book in your native +language, I would be happy to help make it happen. Please get in +touch.
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.
+ +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).
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.
+ +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 "
+ ++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?
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.
+ +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.
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.
+ +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.
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.
+ +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.
After asking the Norwegian Broadcasting Company (NRK) -why -they can broadcast and stream H.264 video without an agreement with -the MPEG LA, I was wiser, but still confused. So I asked MPEG LA -if their understanding matched that of NRK. As far as I can tell, it -does not.
- -I started by asking for more information about the various -licensing classes and what exactly is covered by the "Internet -Broadcast AVC Video" class that NRK pointed me at to explain why NRK -did not need a license for streaming H.264 video: - -
+ +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.
+