- <div class="title"><a href="http://people.skolelinux.org/pere/blog/The_life_and_death_of_a_laptop_battery.html">The life and death of a laptop battery</a></div>
- <div class="date">24th September 2015</div>
- <div class="body"><p>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.</p>
-
-<img src="http://people.skolelinux.org/pere/blog/images/2015-09-24-laptop-battery-graph.png"/>
-
-<p>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
-<a href="https://tracker.debian.org/pkg/battery-stats">battery-stats</a>,
-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 href="http://www.ifweassume.com/2013/08/the-de-evolution-of-my-laptop-battery.html">a
-blog post about the battery development on a MacBook Air</a> I also
-discovered
-<a href="https://github.com/jradavenport/batlog.git">batlog</a>, not
-available in Debian.</p>
-
-<p>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:</p>
-
-<pre>
-#!/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
-</pre>
-
-<p>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
-<a href="https://github.com/petterreinholdtsen/battery-status">is now
-available on github</a>.</p>
-
-<p>The collected log file look like this:</p>
-
-<pre>
-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,
-</pre>
-
-<p>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.</p>
-
-<p>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
-<a href="http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries">Battery
-University</a>, 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
-<a href="http://my.teslamotors.com/de_CH/forum/forums/battery-charge-limit">limit
-the charge of their batteries to 80%</a>, 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.</p>
-
-<p>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
-<a href="http://askubuntu.com/questions/34452/how-can-i-limit-battery-charging-to-80-capacity">one
-recipe on askubuntu for Ubuntu to limit charging on Thinkpad to
-80%</a>, but could not get it to work (kernel module refused to
-load).</p>
-
-<p>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.</p>
-
-<p>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.</p>
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Free_software_archive_system_Nikita_now_able_to_store_documents.html">Free software archive system Nikita now able to store documents</a></div>
+ <div class="date">19th March 2017</div>
+ <div class="body"><p>The <a href="https://github.com/hiOA-ABI/nikita-noark5-core">Nikita
+Noark 5 core project</a> is implementing the Norwegian standard for
+keeping an electronic archive of government documents.
+<a href="http://www.arkivverket.no/arkivverket/Offentlig-forvaltning/Noark/Noark-5/English-version">The
+Noark 5 standard</a> 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
+<a href="https://www.nuug.no/news/NOARK5_kjerne_som_fri_programvare_f_r_epostliste_hos_NUUG.shtml">announced
+it supported the project</a>. 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.</p>
+
+<p>If you would like to help make sure there is a free software
+alternatives for the archives, please join our IRC channel
+(<a href="irc://irc.freenode.net/%23nikita"">#nikita on
+irc.freenode.net</a>) and
+<a href="https://lists.nuug.no/mailman/listinfo/nikita-noark">the
+project mailing list</a>.</p>
+
+<p>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
+<tt>archive-pdf</tt> to upload a PDF file to the archive using this
+API. The tool is very simple at the moment, and find existing
+<a href="https://en.wikipedia.org/wiki/Fonds">fonds</a>, 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:</p>
+
+<p><blockquote><pre>
+~/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$
+</pre></blockquote></p>
+
+<p>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 <tt>archive-pdf</tt>
+tool can be found in the git repository for the API tester.</p>
+
+<p>In the project, I have been mostly working on
+<a href="https://github.com/petterreinholdtsen/noark5-tester">the API
+tester</a> so far, while getting to know the code base. The API
+tester currently use
+<a href="https://en.wikipedia.org/wiki/HATEOAS">the HATEOAS links</a>
+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.</p>
+
+<p>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
+<a href="https://github.com/petterreinholdtsen/noark5-tester/tree/master/mangelmelding">started
+writing down</a> the questions we get from implementing it. We use a
+format inspired by how <a href="http://www.opengroup.org/austin/">The
+Austin Group</a> collect defect reports for the POSIX standard with
+<a href="http://www.opengroup.org/austin/mantis.html">their
+instructions for the MANTIS defect tracker system</a>, in lack of an official way to structure defect reports for Noark 5 (our first submitted defect report was a <a href="https://github.com/petterreinholdtsen/noark5-tester/blob/master/mangelmelding/sendt/2017-03-15-mangel-prosess.md">request for a procedure for submitting defect reports</a> :).
+
+<p>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.</p>
projects / homepage.git / blobdiff