Last year, US president candidate -in the Democratic Party Lawrence interviewed Edward Snowden. The -one hour interview was -published by -Harvard Law School 2014-10-23 on Youtube, and the meeting took -place 2014-10-20.
- -The questions are very good, and there is lots of useful -information to be learned and very interesting issues to think about -being raised. Please check it out.
- - - -I find it especially interesting to hear again that Snowden did try -to bring up his reservations through the official channels without any -luck. It is in sharp contrast to the answers made 2013-11-06 by the -Norwegian prime minister Erna Solberg to the Norwegian Parliament, -claiming -Snowden is no Whistle-Blower because he should have taken up his -concerns internally and using official channels. It make me sad -that this is the political leadership we have here in Norway.
+ +When I set out a few weeks ago to figure out +which +multimedia player in Debian claimed to support most file formats / +MIME types, I was a bit surprised how varied the sets of MIME types +the various players claimed support for. The range was from 55 to 130 +MIME types. I suspect most media formats are supported by all +players, but this is not really reflected in the MimeTypes values in +their desktop files. There are probably also some bogus MIME types +listed, but it is hard to identify which one this is.
+ +Anyway, in the mean time I got in touch with upstream for some of +the players suggesting to add more MIME types to their desktop files, +and decided to spend some time myself improving the situation for my +favorite media player VLC. The fixes for VLC entered Debian unstable +yesterday. The complete list of MIME types can be seen on the +Multimedia +player MIME type support status Debian wiki page.
+ +The new "best" multimedia player in Debian? It is VLC, followed by +totem, parole, kplayer, gnome-mpv, mpv, smplayer, mplayer-gui and +kmplayer. I am sure some of the other players desktop files support +several of the formats currently listed as working only with vlc, +toten and parole.
+ +A sad observation is that only 14 MIME types are listed as +supported by all the tested multimedia players in Debian in their +desktop files: audio/mpeg, audio/vnd.rn-realaudio, audio/x-mpegurl, +audio/x-ms-wma, audio/x-scpls, audio/x-wav, video/mp4, video/mpeg, +video/quicktime, video/vnd.rn-realvideo, video/x-matroska, +video/x-ms-asf, video/x-ms-wmv and video/x-msvideo. Personally I find +it sad that video/ogg and video/webm is not supported by all the media +players in Debian. As far as I can tell, all of them can handle both +formats.
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. Aaron 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.
+ +Many years ago, when koffice was fresh and with few users, I +decided to test its presentation tool when making the slides for a +talk I was giving for NUUG on Japhar, a free Java virtual machine. I +wrote the first draft of the slides, saved the result and went to bed +the day before I would give the talk. The next day I took a plane to +the location where the meeting should take place, and on the plane I +started up koffice again to polish the talk a bit, only to discover +that kpresenter refused to load its own data file. I cursed a bit and +started making the slides again from memory, to have something to +present when I arrived. I tested that the saved files could be +loaded, and the day seemed to be rescued. I continued to polish the +slides until I suddenly discovered that the saved file could no longer +be loaded into kpresenter. In the end I had to rewrite the slides +three times, condensing the content until the talk became shorter and +shorter. After the talk I was able to pinpoint the problem – +kpresenter wrote inline images in a way itself could not understand. +Eventually that bug was fixed and kpresenter ended up being a great +program to make slides. The point I'm trying to make is that we +expect a program to be able to load its own data files, and it is +embarrassing to its developers if it can't.
+ +Did you ever experience a program failing to load its own data +files from the desktop file browser? It is not a uncommon problem. A +while back I discovered that the screencast recorder +gtk-recordmydesktop would save an Ogg Theora video file the KDE file +browser would refuse to open. No video player claimed to understand +such file. I tracked down the cause being file --mime-type +returning the application/ogg MIME type, which no video player I had +installed listed as a MIME type they would understand. I asked for +file to change its +behavour and use the MIME type video/ogg instead. I also asked +several video players to add video/ogg to their desktop files, to give +the file browser an idea what to do about Ogg Theora files. After a +while, the desktop file browsers in Debian started to handle the +output from gtk-recordmydesktop properly.
+ +But history repeats itself. A few days ago I tested the music +system Rosegarden again, and I discovered that the KDE and xfce file +browsers did not know what to do with the Rosegarden project files +(*.rg). I've reported the +rosegarden problem to BTS and a fix is commited to git and will be +included in the next upload. To increase the chance of me remembering +how to fix the problem next time some program fail to load its files +from the file browser, here are some notes on how to fix it.
+ +The file browsers in Debian in general operates on MIME types. +There are two sources for the MIME type of a given file. The output from +file --mime-type mentioned above, and the content of the +shared MIME type registry (under /usr/share/mime/). The file MIME +type is mapped to programs supporting the MIME type, and this +information is collected from +the +desktop files available in /usr/share/applications/. If there is +one desktop file claiming support for the MIME type of the file, it is +activated when asking to open a given file. If there are more, one +can normally select which one to use by right-clicking on the file and +selecting the wanted one using 'Open with' or similar. In general +this work well. But it depend on each program picking a good MIME +type (preferably +a +MIME type registered with IANA), file and/or the shared MIME +registry recognizing the file and the desktop file to list the MIME +type in its list of supported MIME types.
+ +The /usr/share/mime/packages/rosegarden.xml entry for +the +Shared MIME database look like this:
+ ++ ++<?xml version="1.0" encoding="UTF-8"?> +<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info"> + <mime-type type="audio/x-rosegarden"> + <sub-class-of type="application/x-gzip"/> + <comment>Rosegarden project file</comment> + <glob pattern="*.rg"/> + </mime-type> +</mime-info> +
This states that audio/x-rosegarden is a kind of application/x-gzip +(it is a gzipped XML file). Note, it is much better to use an +official MIME type registered with IANA than it is to make up ones own +unofficial ones like the x-rosegarden type used by rosegarden.
+ +The desktop file of the rosegarden program failed to list +audio/x-rosegarden in its list of supported MIME types, causing the +file browsers to have no idea what to do with *.rg files:
+ ++ ++% grep Mime /usr/share/applications/rosegarden.desktop +MimeType=audio/x-rosegarden-composition;audio/x-rosegarden-device;audio/x-rosegarden-project;audio/x-rosegarden-template;audio/midi; +X-KDE-NativeMimeType=audio/x-rosegarden-composition +% +
The fix was to add "audio/x-rosegarden;" at the end of the +MimeType= line.
+ +If you run into a file which fail to open the correct program when +selected from the file browser, please check out the output from +file --mime-type for the file, ensure the file ending and +MIME type is registered somewhere under /usr/share/mime/ and check +that some desktop file under /usr/share/applications/ is claiming +support for this MIME type. If not, please report a bug to have it +fixed. :)
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.
+ +A little more than 11 years ago, one of the creators of Tor, and +the current President of the Tor +project, Roger Dingledine, gave a talk for the members of the +Norwegian Unix User group (NUUG). A +video of the talk was recorded, and today, thanks to the great help +from David Noble, I finally was able to publish the video of the talk +on Frikanalen, the Norwegian open channel TV station where NUUG +currently publishes its talks. You can +watch the live stream using a web +browser with WebM support, or check out the recording on the video +on demand page for the talk +"Tor: Anonymous +communication for the US Department of Defence...and you.".
+ +Here is the video included for those of you using browsers with +HTML video and Ogg Theora support:
+ + + +I guess the gist of the talk can be summarised quite simply: If you +want to help the military in USA (and everyone else), use Tor. :)
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.
+ +The isenkram +system is a user-focused solution in Debian for handling hardware +related packages. The idea is to have a database of mappings between +hardware and packages, and pop up a dialog suggesting for the user to +install the packages to use a given hardware dongle. Some use cases +are when you insert a Yubikey, it proposes to install the software +needed to control it; when you insert a braille reader list it +proposes to install the packages needed to send text to the reader; +and when you insert a ColorHug screen calibrator it suggests to +install the driver for it. The system work well, and even have a few +command line tools to install firmware packages and packages for the +hardware already in the machine (as opposed to hotpluggable hardware).
+ +The system was initially written using aptdaemon, because I found +good documentation and example code on how to use it. But aptdaemon +is going away and is generally being replaced by +PackageKit, +so Isenkram needed a rewrite. And today, thanks to the great patch +from my college Sunil Mohan Adapa in the FreedomBox project, the +rewrite finally took place. I've just uploaded a new version of +Isenkram into Debian Unstable with the patch included, and the default +for the background daemon is now to use PackageKit. To check it out, +install the isenkram package and insert some hardware dongle +and see if it is recognised.
+ +If you want to know what kind of packages isenkram would propose for +the machine it is running on, you can check out the isenkram-lookup +program. This is what it look like on a Thinkpad X230:
+ ++ ++% isenkram-lookup +bluez +cheese +fprintd +fprintd-demo +gkrellm-thinkbat +hdapsd +libpam-fprintd +pidgin-blinklight +thinkfan +tleds +tp-smapi-dkms +tp-smapi-source +tpb +%p +
The hardware mappings come from several places. The preferred way +is for packages to announce their hardware support using +the +cross distribution appstream system. +See +previous +blog posts about isenkram to learn how to do that.
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.
+ +Yesterday I updated the +battery-stats +package in Debian with a few patches sent to me by skilled and +enterprising users. There were some nice user and visible changes. +First of all, both desktop menu entries now work. A design flaw in +one of the script made the history graph fail to show up (its PNG was +dumped in ~/.xsession-errors) if no controlling TTY was available. +The script worked when called from the command line, but not when +called from the desktop menu. I changed this to look for a DISPLAY +variable or a TTY before deciding where to draw the graph, and now the +graph window pop up as expected.
+ +The next new feature is a discharge rate estimator in one of the +graphs (the one showing the last few hours). New is also the user of +colours showing charging in blue and discharge in red. The percentages +of this graph is relative to last full charge, not battery design +capacity.
+ +The other graph show the entire history of the collected battery +statistics, comparing it to the design capacity of the battery to +visualise how the battery life time get shorter over time. The red +line in this graph is what the previous graph considers 100 percent: + +
In this graph you can see that I only charge the battery to 80 +percent of last full capacity, and how the capacity of the battery is +shrinking. :(
+ +The last new feature is in the collector, which now will handle +more hardware models. On some hardware, Linux power supply +information is stored in /sys/class/power_supply/ACAD/, while the +collector previously only looked in /sys/class/power_supply/AC/. Now +both are checked to figure if there is power connected to the +machine.
+ +If you are interested in how your laptop battery is doing, please +check out the +battery-stats +in Debian unstable, or rebuild it on Jessie to get it working on +Debian stable. :) The upstream source is available from github. +Patches are very welcome.
+ +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.