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 AirWatch er kontrollert -av et selskap i USA. I tillegg er det kjent at kan 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.
+ +Back in 2013 I proposed +a +way to make paper and PDF invoices easier to process electronically by +adding a QR code with the key information about the invoice. I +suggested using vCard field definition, to get some standard format +for name and address, but any format would work. I did not do +anything about the proposal, but hoped someone one day would make +something like it. It would make it possible to efficiently send +machine readable invoices directly between seller and buyer.
+ +This was the background when I came across a proposal and +specification from the web based accounting and invoicing supplier +Visma in Sweden called +UsingQR. Their PDF invoices contain +a QR code with the key information of the invoice in JSON format. +This is the typical content of a QR code following the UsingQR +specification (based on a real world example, some numbers replaced to +get a more bogus entry). I've reformatted the JSON to make it easier +to read. Normally this is all on one long line:
+ ++{ + "vh":500.00, + "vm":0, + "vl":0, + "uqr":1, + "tp":1, + "nme":"Din Leverandør", + "cc":"NO", + "cid":"997912345 MVA", + "iref":"12300001", + "idt":"20151022", + "ddt":"20151105", + "due":2500.0000, + "cur":"NOK", + "pt":"BBAN", + "acc":"17202612345", + "bc":"BIENNOK1", + "adr":"0313 OSLO" +} ++ +The interpretation of the fields can be found in the +format +specification (revision 2 from june 2014). The format seem to +have most of the information needed to handle accounting and payment +of invoices, at least the fields I have needed so far here in +Norway. + +
Unfortunately, the site and document do not mention anything about +the patent, trademark and copyright status of the format and the +specification. Because of this, I asked the people behind it back in +November to clarify. Ann-Christine Savlid (ann-christine.savlid (at) +visma.com) replied that Visma had not applied for patent or trademark +protection for this format, and that there were no copyright based +usage limitations for the format. I urged her to make sure this was +explicitly written on the web pages and in the specification, but +unfortunately this has not happened yet. So I guess if there is +submarine patents, hidden trademarks or a will to sue for copyright +infringements, those starting to use the UsingQR format might be at +risk, but if this happen there is some legal defense in the fact that +the people behind the format claimed it was safe to do so. At least +with patents, there is always +a +chance of getting sued...
+ +I also asked if they planned to maintain the format in an +independent standard organization to give others more confidence that +they would participate in the standardization process on equal terms +with Visma, but they had no immediate plans for this. Their plan was +to work with banks to try to get more users of the format, and +evaluate the way forward if the format proved to be popular. I hope +they conclude that using an open standard organisation like +IETF is the correct place to +maintain such specification.
+ +Update 2016-03-20: Via Twitter I became aware of +some comments +about this blog post that had several useful links and references to +similar systems. In the Czech republic, the Czech Banking Association +standard #26, with short name SPAYD, uses QR codes with payment +information. More information is available from the Wikipedia page on +Short +Payment Descriptor. And in Germany, there is a system named +BezahlCode, +(specification +v1.8 2013-12-05 available as PDF), which uses QR codes with +URL-like formatting using "bank:" as the URI schema/protocol to +provide the payment information. There is also the +ZUGFeRD +file format that perhaps could be transfered using QR codes, but I am +not sure if it is done already. Last, in Bolivia there are reports +that tax information since november 2014 need to be printed in QR +format on invoices. I have not been able to track down a +specification for this format, because of my limited language skill +sets.
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.
+ +Back in September, I blogged about +the +system I wrote to collect statistics about my laptop battery, and +how it showed the decay and death of this battery (now replaced). I +created a simple deb package to handle the collection and graphing, +but did not want to upload it to Debian as there were already +a battery-stats +package in Debian that should do the same thing, and I did not see +a point of uploading a competing package when battery-stats could be +fixed instead. I reported a few bugs about its non-function, and +hoped someone would step in and fix it. But no-one did.
+ +I got tired of waiting a few days ago, and took matters in my own +hands. The end result is that I am now the new upstream developer of +battery stats (available from github) and part of the team maintaining +battery-stats in Debian, and the package in Debian unstable is finally +able to collect battery status using the /sys/class/power_supply/ +information provided by the Linux kernel. If you install the +battery-stats package from unstable now, you will be able to get a +graph of the current battery fill level, to get some idea about the +status of the battery. The source package build and work just fine in +Debian testing and stable (and probably oldstable too, but I have not +tested). The default graph you get for that system look like this:
+ +My plans for the future is to merge my old scripts into the +battery-stats package, as my old scripts collected a lot more details +about the battery. The scripts are merged into the upstream +battery-stats git repository already, but I am not convinced they work +yet, as I changed a lot of paths along the way. Will have to test a +bit more before I make a new release.
+ +I will also consider changing the file format slightly, as I +suspect the way I combine several values into one field might make it +impossible to know the type of the value when using it for processing +and graphing.
+ +If you would like I would like to keep an close eye on your laptop +battery, check out the battery-stats package in +Debian and +on +github. +I would love some help to improve the system further.
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.
+ +Making packages for Debian requires quite a lot of attention to +details. And one of the details is the content of the +debian/copyright file, which should list all relevant licenses used by +the code in the package in question, preferably in +machine +readable DEP5 format.
+ +For large packages with lots of contributors it is hard to write +and update this file manually, and if you get some detail wrong, the +package is normally rejected by the ftpmasters. So getting it right +the first time around get the package into Debian faster, and save +both you and the ftpmasters some work.. Today, while trying to figure +out what was wrong with +the +zfsonlinux copyright file, I decided to spend some time on +figuring out the options for doing this job automatically, or at least +semi-automatically.
+ +Lucikly, there are at least two tools available for generating the +file based on the code in the source package, +debmake +and cme. I'm +not sure which one of them came first, but both seem to be able to +create a sensible draft file. As far as I can tell, none of them can +be trusted to get the result just right, so the content need to be +polished a bit before the file is OK to upload. I found the debmake +option in +a +blog posts from 2014. + +
To generate using debmake, use the -cc option: + +
+debmake -cc > debian/copyright ++ +
Note there are some problems with python and non-ASCII names, so +this might not be the best option.
+ +The cme option is based on a config parsing library, and I found +this approach in +a +blog post from 2015. To generate using cme, use the 'update +dpkg-copyright' option: + +
+cme update dpkg-copyright ++ +
This will create or update debian/copyright. The cme tool seem to +handle UTF-8 names better than debmake.
+ +When the copyright file is created, I would also like some help to +check if the file is correct. For this I found two good options, +debmake -k and license-reconcile. The former seem +to focus on license types and file matching, and is able to detect +ineffective blocks in the copyright file. The latter reports missing +copyright holders and years, but was confused by inconsistent license +names (like CDDL vs. CDDL-1.0). I suspect it is good to use both and +fix all issues reported by them before uploading. But I do not know +if the tools and the ftpmasters agree on what is important to fix in a +copyright file, so the package might still be rejected.
+ +The devscripts tool licensecheck deserve mentioning. It +will read through the source and try to find all copyright statements. +It is not comparing the result to the content of debian/copyright, but +can be useful when verifying the content of the copyright file.
+ +Are you aware of better tools in Debian to create and update +debian/copyright file. Please let me know, or blog about it on +planet.debian.org.
+ +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
+ +Update 2016-02-20: I got a tip from Mike Gabriel +on how to use licensecheck and cdbs to create a draft copyright file + +
+licensecheck --copyright -r `find * -type f` | \ + /usr/lib/cdbs/licensecheck2dep5 > debian/copyright.auto ++ +
He mentioned that he normally check the generated file into the +version control system to make it easier to discover license and +copyright changes in the upstream source. I will try to do the same +with my packages in the future.
+ +Update 2016-02-21: The cme author recommended +against using -quiet for new users, so I removed it from the proposed +command line.