Petter Reinholdtsen

Back in 2010, Mike Gabriel showed up on the Debian Edu and Skolelinux mailing list. He quickly proved to be a valuable developer, and thanks to his tireless effort we now have Kerberos integrated into the Debian Edu Squeeze version.

Who are you, and how do you spend your days?

My name is Mike Gabriel, I am 38 years old and live near Kiel, Schleswig-Holstein, Germany. I live together with a wonderful partner (Angela Fuß) and two own children and two bonus children (contributed by Angela).

During the day I am part-time employed as a system administrator and part-time working as an IT consultant. The consultancy work touches free software topics wherever and whenever possible. During the nights I am a free software developer. In the gaps I also train in becoming an osteopath.

Starting in 2010 we (Andreas Buchholz, Angela Fuß, Mike Gabriel) have set up a free software project in the area of Kiel that aims at introducing free software into schools. The project's name is "IT-Zukunft Schule" (IT future for schools). The project links IT skills with communication skills.

How did you get in contact with the Skolelinux/Debian Edu project?

While preparing our own customised Linux distribution for "IT-Zukunft Schule" we were repeatedly asked if we really wanted to reinvent the wheel. What schools really need is already available, people said. From this impulse we started evaluating other Linux distributions that target being used for school networks.

At the end we short-listed two approaches and compared them: a commercial Linux distribution developed by a company in Bremen, Germany, and Skolelinux / Debian Edu. Between 12/2010 and 03/2011 we went to several events and met people being responsible for marketing and development of either of the distributions. Skolelinux / Debian Edu was by far much more convincing compared to the other product that got short-listed beforehand--across the full spectrum. What was most attractive for me personally: the perspective of collaboration within the developmental branch of the Debian Edu project itself.

In parallel with this, we talked to many local and not-so-local people. People teaching at schools, headmasters, politicians, data protection experts, other IT professionals.

We came to two conclusions:

First, a technical conclusion: What schools need is available in bits and pieces here and there, and none of the solutions really fit by 100%. Any school we have seen has a very individual IT setup whereas most of each school's requirements could mapped by a standard IT solution. The requirement to this IT solution is flexibility and customisability, so that individual adaptations here and there are possible. In terms of re-distributing and rolling out such a standardised IT system for schools (a system that is still to some degree customisable) there is still a lot of work to do here locally. Debian Edu / Skolelinux has been our choice as the starting point.

Second, a holistic conclusion: What schools need does not exist at all (or we missed it so far). There are several technical solutions for handling IT at schools that tend to make a good impression. What has been missing completely here in Germany, though, is the enrolment of people into using IT and teaching with IT. "IT-Zukunft Schule" tries to provide an approach for this.

Only some schools have some sort of a media concept which explains, defines and gives guidance on how to use IT in class. Most schools in Northern Germany do not have an IT service provider, the school's IT equipment is managed by one or (if the school is lucky) two (admin) teachers, most of the workload these admin teachers get done in there spare time.

We were surprised that only a very few admin teachers were networked with colleagues from other schools. Basically, every school here around has its individual approach of providing IT equipment to teachers and students and the exchange of ideas has been quasi non-existent until 2010/2011.

Quite some (non-admin) teachers try to avoid using IT technology in class as a learning medium completely. Several reasons for this avoidance do exist.

We discovered that no-one has ever taken a closer look at this social part of IT management in schools, so far. On our quest journey for a technical IT solution for schools, we discussed this issue with several teachers, headmasters, politicians, other IT professionals and they all confirmed: a holistic approach of considering IT management at schools, an approach that includes the people in place, will be new and probably a gain for all.

What do you see as the advantages of Skolelinux/Debian Edu?

There is a list of advantages: international context, openness to any kind of contributions, do-ocracy policy, the closeness to Debian, the different installation scenarios possible (from stand-alone workstation to complex multi-server sites), the transparency within project communication, honest communication within the group of developers, etc.

What do you see as the disadvantages of Skolelinux/Debian Edu?

Every coin has two sides:

Technically: BTS issue #311188, tricky upgradability of a Debian Edu main server, network client installations on top of a plain vanilla Debian installation should become possible sometime in the near future, one could think about splitting the very complex package debian-edu-config into several portions (to make it easier for new developers to contribute).

Another issue I see is that we (as Debian Edu developers) should find out more about the network of people who do the marketing for Debian Edu / Skolelinux. There is a very active group in Germany promoting Skolelinux on the bigger Linux Days within Germany. Are there other groups like that in other countries? How can we bring these marketing people together (marketing group A with group B and all of them with the group of Debian Edu developers)? During the last meeting of the German Skolelinux group, I got the impression of people there being rather disconnected from the development department of Debian Edu / Skolelinux.

Which free software do you use daily?

For my daily business, I do not use commercial software at all.

For normal stuff I use Iceweasel/Firefox, Libreoffice.org. For serious text writing I prefer LaTeX. I use gimp, inkscape, scribus for more artistic tasks. I run virtual machines in KVM and Virtualbox.

I am one of the upstream developers of X2Go. In 2010 I started the development of a Python based X2Go Client, called PyHoca-GUI. PyHoca-GUI has brought forth a Python X2Go Client API that currently is being integrated in Ubuntu's software center.

For communications I have my own Kolab server running using Horde as web-based groupware client. For IRC I love to use irssi, for Jabber I have several clients that I use, mostly pidgin, though. I am also the Debian maintainer of Coccinella, a Jabber-based interactive whiteboard.

My favourite terminal emulator is KDE's Yakuake.

Which strategy do you believe is the right one to use to get schools to use free software?

Communicate, communicate, communicate. Enrol people, enrol people, enrol people.

A few years ago I wrote how to extract support status for your Dell and HP servers. Recently I have learned from colleges here at the University of Oslo that Dell have made this even easier, by providing a SOAP based web service. Given the service tag, one can now query the Dell servers and get machine readable information about the support status. This perl code demonstrate how to do it:

use strict;
use warnings;
use SOAP::Lite;
use Data::Dumper;
my $GUID = '11111111-1111-1111-1111-111111111111';
my $App = 'test';
my $servicetag = $ARGV[0] or die "Please supply a servicetag. $!\n";
my ($deal, $latest, @dates);
my $s = SOAP::Lite
    -> uri('http://support.dell.com/WebServices/')
    -> on_action( sub { join '', @_ } )
    -> proxy('http://xserv.dell.com/services/assetservice.asmx')
    ;
my $a = $s->GetAssetInformation(
    SOAP::Data->name('guid')->value($GUID)->type(''),
    SOAP::Data->name('applicationName')->value($App)->type(''),
    SOAP::Data->name('serviceTags')->value($servicetag)->type(''),
);
print Dumper($a -> result) ;

The output can look like this:

$VAR1 = {
          'Asset' => {
                     'Entitlements' => {
                                       'EntitlementData' => [
                                                            {
                                                              'EntitlementType' => 'Expired',
                                                              'EndDate' => '2009-07-29T00:00:00',
                                                              'Provider' => '',
                                                              'StartDate' => '2006-07-29T00:00:00',
                                                              'DaysLeft' => '0'
                                                            },
                                                            {
                                                              'EntitlementType' => 'Expired',
                                                              'EndDate' => '2009-07-29T00:00:00',
                                                              'Provider' => '',
                                                              'StartDate' => '2006-07-29T00:00:00',
                                                              'DaysLeft' => '0'
                                                            },
                                                            {
                                                              'EntitlementType' => 'Expired',
                                                              'EndDate' => '2007-07-29T00:00:00',
                                                              'Provider' => '',
                                                              'StartDate' => '2006-07-29T00:00:00',
                                                              'DaysLeft' => '0'
                                                            }
                                                          ]
                                     },
                     'AssetHeaderData' => {
                                          'SystemModel' => 'GX620',
                                          'ServiceTag' => '8DSGD2J',
                                          'SystemShipDate' => '2006-07-29T19:00:00-05:00',
                                          'Buid' => '2323',
                                          'Region' => 'Europe',
                                          'SystemID' => 'PLX_GX620',
                                          'SystemType' => 'OptiPlex'
                                        }
                   }
        };

I have not been able to find any documentation from Dell about this service outside the inline documentation, and according to one comment it can have stability issues, but it is a lot better than scraping HTML pages. :)

Wonder if HP and other server vendors have a similar service. If you know of one, drop me an email. :)

På onsdag rakk jeg såvidt innom Oslo Open Data Forums møte, og fikk lagt hendene mine på DIFIs helt nye veileder "Åpne data. Del og skap verdier. Veileder i tilgjengeliggjøring av offentlig data" (også tilgjengelig som PDF fra DIFI).

Veilederen er veldig bra, og nevner viktige problemstillinger og skisserer f.eks. både verdiskapningspotensialet og formatmulighetene som en bør ha i bakhodet når en publiserer offentlig informasjon på maskinlesbart format. Kildekoden til veilederen er tilgjengelig via github, og en kan rapportere tilbakemeldinger og forslag til forbedringer der (eller via epost og twitter for de som ønsker det).

Det eneste jeg virkelig savnet i veilederen var omtale av w3cs stjerneklassifisering av åpne datakilder, som jeg tror ville være nyttige mentale knagger for de som vurderer å publisere sin informasjon på som åpne data. Jeg har rapportert en github-bug om dette, så får vi se hvordan den blir behandlet.

Det slo meg at det var veldig lite konkret i veilederen om valg av bruksvilkår ved publisering (aka lisens), men jeg er ikke sikker på om det hører hjemme der, da det er et vanskelig tema som kanskje heller hører hjemme i sin egen veileder. Uansett, anbefaler alle å ta en titt på veilederen og sikre at alle offentlige etater en har kontakt med får en kopi.

A few days ago my color calibration gadget ColorHug arrived in the mail, and I've had a few days to test it. As all my machines are running Debian Squeeze, where the calibration software is missing (it is present in Wheezy and Sid), I ran the calibration using the Fedora based live CD. This worked just fine. So far I have only done the quick calibration. It was slow enough for me, so I will leave the more extensive calibration for another day.

After calibration, I get a ICC color profile file that can be passed to programs understanding such tools. KDE do not seem to understand it out of the box, so I searched for command line tools to use to load the color profile into X. xcalib was the first one I found, and it seem to work fine for single monitor setups. But for my video player, a laptop with a flat screen attached, it was unable to load the color profile for the correct monitor. After searching a bit, I discovered that the dispwin tool from the argyll package would do what I wanted, and a simple

dispwin -d 1 profile.icc

later I had the color profile loaded for the correct monitor. The result was a bit more pink than I expected. I guess I picked the wrong monitor type for the "led" monitor I got, but the result is good enough for now.

Det finnes i følge de som har talt ca. 1600 bensinstasjoner i Norge. Daglig innsamling av informasjon fra alle disse vil antagelig kreve noen tusen frivillige. Dugnadsbasert innsamling av bensinpriser for å gjøre det enklere å sammenligne priser og dermed bedre konkurransen i bensinmarkedet er en idé som mange har gjennomført de siste årene. Her er et forsøk på en oversikt over de som finnes i dag.

Dinside.no nettside

Nettavisen dinside startet for noen år siden en dugnad for å samle inn drivstoffpriser. Tjenesten samler inn med et nettsideskjema der en må registrere seg for å delta. En SMS-tjeneste har visst eksistert tidligere, men er ute av drift 2012-05-31. Listen over bensinstasjoner er kun tilgjengelig for registrerte brukere, og mangler geografiske koordinater for fremvisning på kart. Listen over innsamlede bensinpriser er tilgjengelig som nettside i litt over 24 timer etter registrering. Antall innsamlede priser pr. dag ligger i området 10-35, og jeg har startet på en database over de publiserte prisene hos Scraperwiki.

Bitfactorys mobilapp

I fjor lanserte selskapet Bitfactory sin landsdekkende mobilapp (først for iphone, siden også for Android) for å samle inn drivstoffpriser og gjøre det enkelt å finne billigste stasjon i nærområdet ved hjelp av smarttelefon. Den innsamlede informasjonen er ikke publisert på web, men dagens priser kan hentes ut ved hjelp av et web-API som jeg har dokumentert med reversutvikling. Stasjonslisten inneholder geografiske koordinater for fremvisning på kart. Antall innsamlede priser pr. dag ser ut til å ligge rundt 200.

NAF Bergens nettside og iphone-app

I år lanserte NAF Bergen en landsdekkende iphone-app koblet til NAF Bergens tjeneste for å samle inn og varsle brukerne om bensinpriser. Nettstedet har publisert listen over bensinstasjoner, men ikke en komplett oversikt over innsamlede priser. De har interessant statistikk over prisutviklingen som går tilbake til 2009.

bensinpris.net

Nettside med prisinformasjon for Trondheimsområdet. Informasjonen registreres via web og SMS, og krever ikke registrering. Nettsiden viser de tre siste prisene registret for bensin og disel. Har liste over kjente stasjoner tilgjengelig. Svært lite oppdatert for tiden.

I tillegg er jeg kjent med drivstoffguiden.no som ser ut til å være nedlagt, og at SSB som del av beregningen av konsumprisindeksen samler inn driftstoffpriser hver måned og legger dem ut i PDF-format.

Det jeg ikke forstår er hvorfor det stadig opprettes nye nett- og mobiltjenester for å samle inn bensinpriser, i stedet for å samarbeide med de eksisterende løsninger for å gjøre de gode nok til nye bruksområder. Jobben med å samle inn priser er formidabel, og hvis målet er bedre konkurranse på bensinmarkedet ville jeg tro det beste var om kundene samlet seg om _ett_ nettsted og samlet alle prisene der, i stedet for å spre innsatsen på mange nettsteder. Jeg mistenker årsaken ligger i at de aktørene som har satt opp tjenester så langt ikke har lagt opp til deling og samarbeid på like vilkår med andre aktører, og dermed gjort det vanskelig å legge til funksjonalitet som presentasjon på kart, statistisk analyse eller kvalitetssikring av bensinstasjonslisten og prisinformasjonen.

Dinside mangler dugnadsbasert kvalitetssikring av stasjonslista, georeferert informasjon og API for innlegging og uthenting av informasjon. Bitfactory mangler publisering av all innsamlet informasjon, dugnadsbasert kvalitetssikring av stasjonslista og dokumentert API for innlegging og uthenting av informasjon. NAFs løsning mangler publisering av all innsamlet informasjon og API for innlegging og uthenting av informasjon.

Jeg har nylig spurt folkene bak dinside.nos oversikt og drivstoffpriser.no om de er villige til å gi ut sine innsamlede data uten bruksbegresninger og tilby et dokumentert og publisert API for å legge inn og hente ut informasjon. Så får vi se hva de sier.

En god og offentlig kilde til bensinpriser i Norge er dinside.no sin prisoversikt samlet inn på dugnad fra frivillige over hele landet. Den har ikke like mange priser rapportert inn som Bitfactorys mobil-app, men informasjonen som samles inn er enkelt offentlig tilgjengelig på web. Dessverre forsvinner prisene fra web etter noen dager, så for å kunne lage analyser og se trender må en lage en database ved å hente ut informasjon fra dinside.no sine nettsider over en lengre periode. Jeg startet for litt over en uke siden en innsamlingstjeneste som gjør nettopp dette. Jeg har de siste ukene lært meg å bruke Scraperwiki, et nytt og nyttig verktøy for å hente ut og strukturere informasjon tilgjengelig fra nettsider, PDF-er og andre kilder og som trenger strukturering. Hvis du vil se hvordan prisene har utviklet seg, ta en titt på scraperwiki-siden med databasen over bensinpriser. Den henter ned priser fra dinside.no hver time. Hvis du vil bidra til å bedre oversikt over bensinprisene i Norge registrer deg hos dinside.no og legg inn prisene fra dine lokale bensinstasjoner.

Jeg har kun gjort dette med informasjonen fra dinside.no og ikke informasjonen fra Bitfactory pga. bekymring rundt opphavsrettslige problemstillinger. Faktainformasjonen samlet inn av brukerene av dinside.no nettsider er åpenbart publisert offentlig, mens jeg mistenker det er en juridisk gråsone om det samme gjelder informasjonen samlet inn av brukerne av bitfactorys mobilapp. Derfor bidrar jeg med å samle inn priser hos dinside.no, og anbefaler andre å gjøre det samme. Jeg prioriterer å bidra hos de som forstår verdien av å dele informasjon med andre uten bruksbegresninger.

I fjor lanserte Bitfactory en mobilapp for å få tilgang til bensinpriser på landets bensinstasjoner ved å samle inn prisene på dugnad ved hjelp av mobilapp-ens brukere. Informasjonen app-ens brukere har samlet inn har så langt kun vært tilgjengelig for brukerne av app-ene, og API for å hente ut informasjonen fra andre plattformer har ikke vært publisert. Da løsningen kom spurte jeg utviklerne om de kunne publisere API-dokumentasjon og de skulle se på saken, men det har ikke skjedd så langt. Jeg antar de har vært for travelt opptatt til å publisere API-dokumentasjon.

Utrolig nok er det i følge Dagens Næringsliv og Finnmark Dagblad bensinstasjoner som nekter å oppgi prisene sine på telefon, slik at det ikke finnes en fornuftig måte å få tak i prisene på uten å samle dem inn på stedet. Flere har dugnader på gang for å samle inn prisinformasjon om bensin, men så vidt jeg kan se er det kun dinside.no og Bitfactorys App som får regelmessige oppdateringer. Dinsides oversikt er tilgjengelig på web for de som vil følge med, mens bitfactorys informasjon ikke er like enkelt tilgjengelig.

Jeg tok meg derfor litt tid for å revers-utvikle protokollen for Bitfactorys mobilapp for å gjøre den innsamlede informasjonen mer tilgjengelig for flere. Protokollen bruker HTTP og normal forms-notasjon for POST. Jeg lot en telefon koble seg til mitt trådløsnett, og satte opp tcpdump til å samle all trafikken mot www.bitfactory.no, og deretter tittet på alle HTTP-kallene ved hjelp av wireshark. Her er API-kallene jeg har identifisert så langt.

stasjonsDatabaseUpdateStamp

GET http://www.bitfactory.no/Bensin/ver1.1.stasjonsDatabaseUpdateStamp

Vet ikke helt hva dette API-kallet gjør, men navnet gjør at jeg tror den rapporterer når listen over stasjoner sist ble endret. Returverdien er et tall som pr. 2011-12-09 er 1319145491 og pr. 2012-05-28 er 1336420693. Mitt gjett er at dette er sekunder siden 1. januar 1970 ala det en finner på Linux, som kan konverteres til en leselig dato med perl -e 'print scalar(localtime(1319145491)), "\n"'. Den første verdien konverterer da til "Thu Oct 20 23:18:11 2011", mens den andre konverteres til "Mon May 7 21:58:13 2012".

GetXMLDatabase

echo password=XYZXYZXYZXYZX | POST http://www.bitfactory.no/Bensin/GetXMLDatabase.php

Henter ned listen med stasjoner på XML-format. Argumentet er password som muligens følger med i programpakken og eventuelt genereres av app-en. Nedlasting med samme passord flere ganger ser ikke ut til å fungere. Innholdet er ca. 1600 stasjoner, men manglet bensinstasjonen i min hjemkommune Ballangen da jeg sjekket, så den er ikke komplett. Formatet på selve listen ser slik ut (klippet):

<?xml version="1.0" encoding="UTF-8"?>
<STASJONSDATABASE>
<STASJON>
<NAME></NAME>
<ADDRESS></ADDRESS>
<ID>0</ID>
<LATITUDE>0.000000</LATITUDE>
<LONGITUDE>0.000000</LONGITUDE>
<COMPANY></COMPANY>
</STASJON>
<STASJON>
<NAME>Statoil Best Eidsvoll Verk</NAME>
<ADDRESS>Gamle Trondheimsvei 339 2074 Eidsvoll Verk</ADDRESS>
<ID>1</ID>
<LATITUDE>60.303902</LATITUDE>
<LONGITUDE>11.168100</LONGITUDE>
<COMPANY>Best</COMPANY>
</STASJON>
[...]
<STASJON>
<NAME>Esso Andenes</NAME>
<ADDRESS>Falcksgate 9, 8480 Andenes</ADDRESS>
<ID>1822</ID>
<LATITUDE>69.320999</LATITUDE>
<LONGITUDE>16.118700</LONGITUDE>
<COMPANY>Esso</COMPANY>
</STASJON>
</STASJONSDATABASE>

GetBanStatus

echo UDID=Android-123456789012345 | POST http://www.bitfactory.no/Bensin/ver1.1.GetBanStatus.php

Vet heller ikke helt hva dette API-kallet gjør. Navnet gjør at jeg tror den rapporterer om telefonen med UDID oppgitt som argument er bannlyst fra tjenesten. Bannlysning gjør antagelig at telefonen ikke kan brukes til å registrere bensinpriser, men det er også mulig det blokkerer for å se på priser. Eneste POST-argument er UDID, som ser ut til å være den unike ID-en til en mobil-enhet. Returnverdi er 'NO' for alle UDID-verdier jeg har testet. Gjetter på at alternativ returverdi er 'YES', men har ikke sett en slik verdi så langt.

PriserVedStasjoner

echo 'stasjoner=810,364&day=0' | POST http://www.bitfactory.no/Bensin/ver1.1.PriserVedStasjoner.php

Dette kallet henter ut priser registrert på en eller flere bensinstasjoner. Den tar to POST-argumenter, "stasjoner" som er kommaseparert liste over stasjons-IDer (numeriske), og "day" som bør settes til "0" for å få ut informasjon om priser. Usikker på hva day-tallet betyr, men mistenker det har med hvor langt tilbake i tid det skal hentes ut informasjon.

Resultatet som kommer tilbake er en kommaseparert liste for hver enkelt stasjon, med <br> som skillemarkør mellom hver stasjon. Ikke helt sikker på hva alle feltene er. Her er mine gjett:

En stasjonsoppføring består dermed av av bensinstasjons-ID og deretter tre blokker for 95-oktan bensin, 98-oktan bensin og disel.

PriserVedStasjon

echo 'id=736&day=0' | POST http://www.bitfactory.no/Bensin/ver1.1.PriserVedStasjon.php

Ser ut til å returnere informasjon for en enkelt bensinstasjon. Formatet er dato på formen "08_12_2011" for 2011-12-08, og noe som ser ut som samme format som fra PriserVedStasjoner. For stasjoner der intet er registrert returnerer den "NO RESULTS".

AllePriser

echo day=0 | POST http://www.bitfactory.no/Bensin/ver1.1.AllePriser.php

Returnere liste med av alle stasjoner det er registrert oppdaterte priser på siste 24 timer (eller er det fra ca. midnatt dagen før?). Returnerer "NO RESULTS" når listen er tom. Ellers returnerer den en dato på formen "Thursday_09_12_2011" fulgt av <br> og deretter en liste med stasjoner på samme format som PriserVedStasjoner.

In 2003, a German teacher showed up on the Debian Edu and Skolelinux mailing list with interesting problems and reports proving he setting up Linux for a (for us at the time) lot of pupils. His name was Ralf Gesellensetter, and he has been an important tester and contributor since then, helping to make sure the Debian Edu Squeeze release became as good as it is..

Who are you, and how do you spend your days?

I am a teacher from Germany, and my subjects are Geography, Mathematics, and Computer Science ("Informatik"). During the past 12 years (since 2000), I have been working for a comprehensive (and soon, also inclusive) school leading to all kind of general levels, such as O- or A-level ("Abitur"). For quite as long, I've been taking care of our computer network.

Now, in my early 40s, I enjoy the privilege of spending a lot of my spare time together with my wife, our son (3 years) and our daughter (4 months).

How did you get in contact with the Skolelinux/Debian Edu project?

We had tried different Linux based school servers, when members of my local Linux User Group (LUG OWL) detected Skolelinux. I remember very well, being part of a party celebrating the Linux New Media Award ("Best Newcomer Distribution", also nominated: Ubuntu) that was given to Skolelinux at Linux World Exposition in Frankfurt, 2005 (IIRC). Few months later, I had the chance to join a developer meeting in Ulsrud (Oslo) and to hand out the award to Knut Yrvin and others. For more than 7 years, Skolelinux is part of our schools infrastructure, namely our main server (tjener), one LTSP (today without thin clients), and approximately 50 work stations. Most of these have the option to boot a locally installed Skolelinux image. As a consequence, I joined quite a few events dealing with free software or Linux, and met many Debian (Edu) developers. All of them seemed quite nice and competent to me, one more reason to stick to Skolelinux.

What do you see as the advantages of Skolelinux/Debian Edu?

Debian driven, you are given all the advantages of a community project including well maintained updates. Once, you are familiar with the network layout, you can easily roll out an entire educational computer infrastructure, from just one installation media. As only free software (FOSS) is used, that supports even elderly hardware, up-sizing your IT equipment is only limited by space (i.e. available labs). Especially if you run a LTSP thin client server, your administration costs tend towards zero.

What do you see as the disadvantages of Skolelinux/Debian Edu?

While Debian's stability has loads of advantages for servers, this might be different in some cases for clients: Schools with unlimited budget might buy new hardware with components that are not yet supported by Debian stable, or wish to use more recent versions of office packages or desktop environments. These schools have the option to run Debian testing or other distributions - if they have the capacity to do so. Another issue is that Debian release cycles include a wide range of changes; therefor a high percentage of human power seems to be absorbed by just keeping the features of Skolelinux within the new setting of the version to come. During this process, the cogs of Debian Edu are getting more and more professional, i.e. harder to understand for novices.

Which free software do you use daily?

LibreOffice, Wikipedia, Openstreetmap, Iceweasel (Mozilla Firefox), KMail, Gimp, Inkscape - and of course the Linux Kernel (not only on PC, Laptop, Mobile, but also our SAT receiver)

Which strategy do you believe is the right one to use to get schools to use free software?

1. Support computer science as regular subject in schools to make people really "own" their hardware, to make them understand the difference between proprietary software products, and free software developing.
2. Make budget baskets corresponding: In Germany's public schools there are more or less fixed budgets for IT equipment (including licenses), so schools won't benefit from any savings here. This privilege is left to private schools which have consequently a large share among German Skolelinux schools.
3. Get free software in the seminars where would-be teachers are trained. In many cases, teachers' software customs are respected by decision makers rather than the expertise of any IT experts.
4. Don't limit ourself to free software run natively. Everybody uses free software or free licenses (for instance Wikipedia), and this general concept should get expanded to free educational content to be shared world wide (school books e.g.).
5. Make clear where ever you can that the market share of free (libre) office suites is much above 20 p.c. today, and that you pupils don't need to know the "ribbon menu" in order to get employed.
6. Talk about the difference between freeware and free software.
7. Spread free software, or even collections of portable free apps for USB pen drives. Endorse students to get a legal copy of Libreoffice rather than accepting them to use illegal serials. And keep sending documents in ODF formats.

I just come across a blog post from Glyn Moody reporting the claimed cost from Microsoft on requiring ODF to be used by the UK government. I just sent him an email to let him know that his assumption are most likely wrong. Sharing it here in case some of my blog readers have seem the same numbers float around in the UK.

Hi. I just noted your http://blogs.computerworlduk.com/open-enterprise/2012/04/does-microsoft-office-lock-in-cost-the-uk-government-500-million/index.htm comment:

"They're all in Danish, not unreasonably, but even with the help of Google Translate I can't find any figures about the savings of "moving to a flexible two standard" as claimed by the Microsoft email. But I assume it is backed up somewhere, so let's take it, and the £500 million figure for the UK, on trust."

I can tell you that the Danish reports are inflated. I believe it is the same reports that were used in the Norwegian debate around 2007, and Gisle Hannemyr (a well known IT commentator in Norway) had a look at the content. In short, the reason it is claimed that using ODF will be so costly, is based on the assumption that this mean every existing document need to be converted from one of the MS Office formats to ODF, transferred to the receiver, and converted back from ODF to one of the MS Office formats, and that the conversion will cost 10 minutes of work time for both the sender and the receiver. In reality the sender would have a tool capable of saving to ODF, and the receiver would have a tool capable of reading it, and the time spent would at most be a few seconds for saving and loading, not 20 minutes of wasted effort.

Microsoft claimed all these costs were saved by allowing people to transfer the original files from MS Office instead of spending 10 minutes converting to ODF. :)

See http://hannemyr.com/no/ms12_vl02.php and http://hannemyr.com/no/ms12.php for background information. Norwegian only, sorry. :)

De siste dagene har høringsuttalelsene om DIFIs forslag til standardkatalog v3.1 blitt publisert på DIFIs nettside, og jeg kunne der glede meg over at NUUGs uttalelse er kommet med. En uttalelse som overrasker og forvirrer meg er den fra Norges Blindeforbund, som 5 år etter at Klaus Knopper sammen med sin blinde kone blant annet demonstrerte høyttalende OpenOffice.org på nynorsk for blinde på et NUUG-møte.

Norges Blindeforbund skriver følgende, som for meg virker å være formulert på sviktende grunnlag:

Bruk av fri programvare

I FRIPROGSENTERET, RAPPORT 2009-02: Universell utforming http://www.kunnskapsbazaren.no/filer/Friprogsenteret-Rapport-Universell_utforming.pdf sies det "Det finnes i dag ikke mange fri programvare-rammeverk eller generelle løsninger som støtter tilgjengelighet eller som er universelt utformet."

Til tross for at det gjennom prinsippene i fri programvare åpnes for større frihet til selv å påvirke programvareløsninger i retning av universell utforming viser praksis at virkeligheten er en annen. Mange av de mest alminnelige frie programvarepakkene mangler delvis eller fullstendig tilgjengelighet for mennesker med nedsatt syn. Eksempler på dette er OpenOffice og LibreOffice m.fl.

En annen utfordring ved bruk av fri programvare kan være manglende kundestøtte og muligheter til opplæring i bruk av løsningen. Svaksynte og blinde har et høyere behov for denne typen støtte enn andre brukere ettersom mange av dem har behov for tilleggsprogramvare som skal fungere sammen med den opprinnelige programvaren, og ettersom man ikke har de samme muligheter for overblikk over grensesnittet som en seende bruker. I tillegg til dette kommer de mer tilgjengelighetstekniske utfordringene som ofte må løses i samarbeid med programvareleverandør/produsent.

Fri programvare er ikke på samme måte underlagt lovgivning gjennom for eksempel diskriminerings og tilgjengelighetsloven ettersom det ikke alltid finnes en produsent/tilbyder av tjenesten eller produktet.

Norges Blindeforbund krever at universell utforming og brukskvalitet tas med som viktige hensyn i utredninger som ligger til grunn for valg av standarder som primært leder brukeren mot fri programvare. Et eksempel på dette er bruk av dokumentformatet ODF som leder brukeren i retning av OpenOffice, som er helt eller delvis utilgjengelig for svaksynte og blinde – noe avhengig av plattform og hjelpemiddelprogramvare.

Jeg håper noen involvert i OpenOffice.org og/eller LibreOffice tar kontakt med Norges Blindeforbund og oppklarer det som for meg virker å være en misforståelse, i og med at OpenOffice.org så vidt jeg vet fungerer fint også for blinde.

Jeg ble minnet på problemstillingen da jeg leste Slashdot-saken om "The State of Linux Accessibility", som også hevder at Linux fungerer utmerket for blinde.