Converted pages to actually temp site.

[homepage.git] / blog / archive / 2011 / 07 / 07.rss

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries from July 2011</title>
                <description>Entries from July 2011</description>
                <link>http://www.hungry.com/~pere/blog/</link>

        
        <item>
                <title>What should start from /etc/rcS.d/ in Debian? - almost nothing</title>
                <link>http://www.hungry.com/~pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html</guid>
                <pubDate>Sat, 30 Jul 2011 14:00:00 +0200</pubDate>
                <description>&lt;p&gt;In the Debian boot system, several packages include scripts that
are started from /etc/rcS.d/.  In fact, there is a bite more of them
than make sense, and this causes a few problems.  What kind of
problems, you might ask.  There are at least two problems.  The first
is that it is not possible to recover a machine after switching to
runlevel 1.  One need to actually reboot to get the machine back to
the expected state.  The other is that single user boot will sometimes
run into problems because some of the subsystems are activated before
the root login is presented, causing problems when trying to recover a
machine from a problem in that subsystem.  A minor additional point is
that moving more scripts out of rcS.d/ and into the other rc#.d/
directories will increase the amount of scripts that can run in
parallel during boot, and thus decrease the boot time.&lt;/p&gt;

&lt;p&gt;So, which scripts should start from rcS.d/.  In short, only the
scripts that _have_ to execute before the root login prompt is
presented during a single user boot should go there.  Everything else
should go into the numeric runlevels.  This means things like
lm-sensors, fuse and x11-common should not run from rcS.d, but from
the numeric runlevels.  Today in Debian, there are around 115 init.d
scripts that are started from rcS.d/, and most of them should be moved
out.  Do your package have one of them?  Please help us make single
user and runlevel 1 better by moving it.&lt;/p&gt;

&lt;p&gt;Scripts setting up the screen, keyboard, system partitions
etc. should still be started from rcS.d/, but there is for example no
need to have the network enabled before the single user login prompt
is presented.&lt;/p&gt;

&lt;p&gt;As always, things are not so easy to fix as they sound.  To keep
Debian systems working while scripts migrate and during upgrades, the
scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency
order, ie the scripts that nothing in rcS.d/ depend on can be moved,
and the next ones can only be moved when their dependencies have been
moved first.  This migration must be done sequentially while we ensure
that the package system upgrade packages in the right order to keep
the system state correct.  This will require some coordination when it
comes to network related packages, but most of the packages with
scripts that should migrate do not have anything in rcS.d/ depending
on them.  Some packages have already been updated, like the sudo
package, while others are still left to do.  I wish I had time to work
on this myself, but real live constrains make it unlikely that I will
find time to push this forward.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>What is missing in the Debian desktop, or why my parents use Kubuntu</title>
                <link>http://www.hungry.com/~pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html</guid>
                <pubDate>Fri, 29 Jul 2011 08:10:00 +0200</pubDate>
                <description>&lt;p&gt;While at Debconf11, I have several times during discussions
mentioned the issues I believe should be improved in Debian for its
desktop to be useful for more people.  The use case for this is my
parents, which are currently running Kubuntu which solve the
issues.&lt;/p&gt;

&lt;p&gt;I suspect these four missing features are not very hard to
implement.  After all, they are present in Ubuntu, so if we wanted to
do this in Debian we would have a source.&lt;/p&gt;

&lt;ol&gt;

&lt;li&gt;&lt;strong&gt;Simple GUI based upgrade of packages.&lt;/strong&gt; When there
are new packages available for upgrades, a icon in the KDE status bar
indicate this, and clicking on it will activate the simple upgrade
tool to handle it.  I have no problem guiding both of my parents
through the process over the phone.  If a kernel reboot is required,
this too is indicated by the status bars and the upgrade tool.  Last
time I checked, nothing with the same features was working in KDE in
Debian.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;Simple handling of missing Firefox browser
plugins.&lt;/strong&gt; When the browser encounter a MIME type it do not
currently have a handler for, it will ask the user if the system
should search for a package that would add support for this MIME type,
and if the user say yes, the APT sources will be searched for packages
advertising the MIME type in their control file (visible in the
Packages file in the APT archive).  If one or more packages are found,
it is a simple click of the mouse to add support for the missing mime
type.  If the package require the user to accept some non-free
license, this is explained to the user.  The entire process make it
more clear to the user why something do not work in the browser, and
make the chances higher for the user to blame the web page authors and
not the browser for any missing features.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;Simple handling of missing multimedia codec/format
handlers.&lt;/strong&gt; When the media players encounter a format or codec
it is not supporting, a dialog pop up asking the user if the system
should search for a package that would add support for it.  This
happen with things like MP3, Windows Media or H.264.  The selection
and installation procedure is very similar to the Firefox browser
plugin handling.  This is as far as I know implemented using a
gstreamer hook.  The end result is that the user easily get access to
the codecs that are present from the APT archives available, while
explaining more on why a given format is unsupported by Ubuntu.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;Better browser handling of some MIME types.&lt;/strong&gt; When
displaying a text/plain file in my Debian browser, it will propose to
start emacs to show it.  If I remember correctly, when doing the same
in Kunbutu it show the file as a text file in the browser.  At least I
know Opera will show text files within the browser.  I much prefer the
latter behaviour.&lt;/li&gt;

&lt;/ol&gt; 

&lt;p&gt;There are other nice features as well, like the simplified suite
upgrader, but given that I am the one mostly doing the dist-upgrade,
it do not matter much.&lt;/p&gt;

&lt;p&gt;I really hope we could get these features in place for the next
Debian release.  It would require the coordinated effort of several
maintainers, but would make the end user experience a lot better.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Skolelinux-intervju: Frode Jemtland</title>
                <link>http://www.hungry.com/~pere/blog/Skolelinux_intervju__Frode_Jemtland.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Skolelinux_intervju__Frode_Jemtland.html</guid>
                <pubDate>Wed, 27 Jul 2011 08:50:00 +0200</pubDate>
                <description>&lt;p&gt;Neste mann ut i min serie med intervjuer av Skolelinux-relaterte
personer er en tidligere styreleder i
&lt;a href=&quot;http://www.friprogramvareiskolen.no/&quot;&gt;FRISK&lt;/a&gt; som var med
fra starten av
&lt;a href=&quot;http://www.skolelinux.org/&quot;&gt;Skolelinux&lt;/a&gt;-prosjektet.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Hvem er du, og hva driver du med til daglig?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Mitt navn er Frode Jemtland, og jeg jobber i Hedmark IKT, som er et
driftsselskap for Grue, Hamar, Kongsvinger, Løten, Nord-Odal og Stange
kommuner. Her er jeg leder for avdelingen Løsninger og Arkitektur. Vi
har i hovedansvar for servere, infrastruktur og løsninger som
helhet.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Hvordan kom du i kontakt med Skolelinux-prosjektet?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Jobbet i IBM fra 2000, og da spesielt med Linux. Dette var da et av
de mest tydelige linux prosjektene i Norge, og her ønsket jeg å
bidra. Var aktivt med i prosjektet i 4-5 år.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Hva er fordelene med Skolelinux slik du ser det?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Fordelene slik jeg ser det er den sentraliserte driftmodellen, og
alle de vel gjennomtenkte løsningene som er inkludert i denne
løsningen. Samtidig er det basert på en stabil, og godt kjent
plattform. Dette vil si at man har en løsning som skal være mye
tilgjengelig, og hvor det er relativt enkelt å få tak i personer som
kan mye om den grunnleggende plattformen.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Hva er ulempene med Skolelinux slik du ser det?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;De største utfordringene med en løsningen er at den er intensiv på f.eks
nettverk. I seg selv ikke et problem for en enkelt skole, men skal løsningen
kjøres i større skala, med sentraliserte servere, så gir dette noen
utfordringer.&lt;/p&gt;

&lt;p&gt;Utifra hva jeg har sett på større installasjoner så er det ikke så
enkelt å skjønne, hva som bør gjøres for at den skal skaleres opp, og
da ta godt vare på alle sider av dette, ikke bare mer server å fordele
last/trykk, men hvordan også beholde robustheten og fleksibiliteten i
løsningen.&lt;/p&gt;

&lt;p&gt;En annen utfordring er at stadig flere produkter som skal brukes i
skoleløsningen ikke er laget til å kunne brukes i en
skolelinuxløsning. Det blir derfor fort mye skreddersøm i de
forskjellige installasjonene, for å få diverse pedagogiske programmer,
webløsninger, smartboards, m.m. til å fungere.  Man er også en for
liten kundebase til at leverandørene ønsker å gjøre noe med
utfordringen. Problemet overlates til oss.&lt;/p&gt;

&lt;p&gt;Det er også en kontinuerlig utfordring rundt problemet med å holde
programvare på stabile versjoner, kontra å få ny funksjonalitet. Dette
er jo en konflikt mellom oss som ønsker å drifte en stabil, og
kostnadseffektiv løsning, mot sluttbrukerne som ønsker seg funksjoner
det er vant med fra andre løsninger, eller som de må ha for at et
eller annet nytt produkt skal fungere i løsningen. Dette er en
utfordring også for andre plattformer.&lt;/p&gt;

&lt;p&gt;En siste utfordring som ikke har noe med løsningen å gjøre, men med
det omkringliggende miljøet denne skal kjøre i, er at de enhetene som
skal drifte dataløsninger for kommuner og fylkeskommuner begynner å
profesjonaliseres, og er da avhengig av å ha standard løsninger for å
drifte store brukermasser. MS er selvsagt klar over dette, og har jo
nå flere områder de begynner å bli veldig dominerende på. Den største,
og mest problematiske er katalogtjenesten.  Man får snart ikke tak i
større løsninger som ikke krever en AD. Når man da har store enheter
som drifter både kommunalt ansatte og skoler, så vil det være et
stordriftargument å standardisere på en katalog tjeneste, og da har
man ikke noe valg. Her er alle slike driftsenheter for små til å få
gjort om på dette. Her burde konkurransemyndighetene kommet på
banen. Men konkurransetilsynet i USA griper sjeldent (og ikke før det
har gått veldig lang tid) inn i monopolsituasjoner så lenge
monopolisten er et amerikansk firma, så da har vel ikke andre
myndigheter så mye de skulle ha sagt....&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Hvilken fri programvare bruker du til daglig?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Privat kjører jeg Debian på alle mine datamaskiner. Det gjør jeg
også på min jobbmaskin. Vi har også 15-20 linux servere av typene
SuSE, Debian, Redhat, CentOS m.m. Jeg bruker derfor mye fri
programvare. Av enkelt programmer kan sikkert masse nevnes. Hvis vi
skal begrense oss til daglig, så må jeg si: OpenOffice, Firefox,
Kontact, Kopete, Amarok,
&lt;a href=&quot;http://gramps-project.org/&quot;&gt;Gramps&lt;/a&gt;, Kate, ssh, bash,
rsync, backuppc m.m.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Hvilken strategi tror du er den rette å bruke for å få
skoler til å ta i bruk fri programvare?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Det er et godt spørsmål, som jeg har lurt på selv.&lt;/p&gt;

&lt;p&gt;Argumentene som ofte har vært brukt om at ting koster mindre holder
ikke mål når man ser på hva som faktisk koster penger. Det er de
ansatte som er en kostnadsdriver. Det vil si at hvis man har et system
som den ansatte kan, så vil en kostnad på dette systemet kunne
forsvares ganske mye ved at den ansatte gjør dette raskere og
effektivt. Også uten å måtte eventuelt leie inn folk.&lt;/p&gt;

&lt;p&gt;Jeg syns det er viktigere å fokusere på prinsippet med å velge fri
programvare, men det er også et felt hvor man fort møter lite
forståelse blant de ansatte i skolen.&lt;/p&gt;

&lt;p&gt;Her må nok strategien fortsette å være at de sentrale myndighetene
må sende tydelige signaler for hva de ønsker at offentlige enheter
skal gjøre. Det var mye positivt på gang ang. dette for et par år
siden. Både med eNorge og eKommune planene, men dette syns jeg har
stoppet opp. En del av dette kan jo kanskje være usikkerheten som
etter hvert har blitt, når man har sett kompleksiteten i de
prosjektene som har blitt igangsatt. Det har også blitt noe usikkerhet
i markedet ref. Sun, Oracle, Novell, Microsoft m.m.  Samtidig har jo
også de proprietære programleverandørene sørget for å endre sine
lisenser slik at man uansett ikke slipper unna kostnaden til deres
produkter, selv om man skulle velge alternativer. Da er det økonomiske
argumentet, som jeg nevnte tidligere, spilt ganske godt ut over
sidelinjen.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Perl modules used by FixMyStreet which are missing in Debian/Squeeze</title>
                <link>http://www.hungry.com/~pere/blog/Perl_modules_used_by_FixMyStreet_which_are_missing_in_Debian_Squeeze.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Perl_modules_used_by_FixMyStreet_which_are_missing_in_Debian_Squeeze.html</guid>
                <pubDate>Tue, 26 Jul 2011 12:25:00 +0200</pubDate>
                <description>&lt;p&gt;The Norwegian &lt;a href=&quot;http://www.fiksgatami.no/&quot;&gt;FiksGataMi&lt;/A&gt;
site is build on Debian/Squeeze, and this platform was chosen because
I am most familiar with Debian (being a Debian Developer for around 10
years) because it is the latest stable Debian release which should get
security support for a few years.&lt;/p&gt;

&lt;p&gt;The web service is written in Perl, and depend on some perl modules
that are missing in Debian at the moment.  It would be great if these
modules were added to the Debian archive, allowing anyone to set up
their own &lt;a href=&quot;http://www.fixmystreet.com&quot;&gt;FixMyStreet&lt;/a&gt; clone
in their own country using only Debian packages.  The list of modules
missing in Debian/Squeeze isn&#39;t very long, and I hope the perl group
will find time to package the 12 modules Catalyst::Plugin::SmartURI,
Catalyst::Plugin::Unicode::Encoding, Catalyst::View::TT, Devel::Hide,
Sort::Key, Statistics::Distributions, Template::Plugin::Comma,
Template::Plugin::DateTime::Format, Term::Size::Any, Term::Size::Perl,
URI::SmartURI and Web::Scraper to make the maintenance of FixMyStreet
easier in the future.&lt;/p&gt;

&lt;p&gt;Thanks to the great tools in Debian, getting the missing modules
installed on my server was a simple call to &#39;cpan2deb Module::Name&#39;
and &#39;dpkg -i&#39; to install the resulting package.  But this leave me
with the responsibility of tracking security problems, which I really
do not have time for.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Overvåkningslogikkens fallitt</title>
                <link>http://www.hungry.com/~pere/blog/Overv_kningslogikkens_fallitt.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Overv_kningslogikkens_fallitt.html</guid>
                <pubDate>Sat, 23 Jul 2011 10:45:00 +0200</pubDate>
                <description>&lt;p&gt;Det er vanskelig å få gjort noe fornuftig i dag, etter gårdagens
tragiske hendelse.  Tankene går til de som har mistet sine nærmeste.
Jeg kan ikke forstille meg hvor tungt de har det nå, og jeg håper alle
jeg kjenner har klart seg.&lt;/p&gt;

&lt;p&gt;Jeg undres på hva motivasjonen til de som står bak kan være?  Jeg
tror en må være ganske desperat for å ty til slike midler, og oppleve
at alle andre påvirkningsmuligheter er blokkert.  Mon tro om
Stortingets totalitære vedtak 4. april i år om å lovfeste massiv
overvåkning av hele befolkningen bidro?  Jeg undres også på om at
gårdagens bombing og massedrap er resultat av de fremmedfiendtlige
holdninger som har spredt seg i Norge i mange år, kombinert med
Stortingets og regjeringens villighet til å forlate de verdier som
vårt liberale demokrati er tuftet på (ved å legge opp til registrering
og overvåkning av borgere som _ikke_ er mistenkt for noe
kriminelt).&lt;/p&gt;

&lt;p&gt;En ting er ganske klart, dog.  Massiv kameraovervåkning bidrar ikke
til å hindre slik grotesk kriminalitet.  Regjeringskvartalet er et av
de mest kameraovervåkede områdene i Oslo, og hindret ikke at
sprengingen fant sted.  Registrering av posisjonen til alle
mobiltelefoner som politiet har hatt tilgang til i flere år nå ser
ikke ut til å ha hjulpet det heller.  De som tror at massiv
kommunikasjonskontroll av hele befolkningen vil hindre ekstremister i
å skade oss i Norge tror jeg tar feil.  Til det tror jeg det må mer
åpenhet, mindre kontroll og mer tillit til hver enkelt innbygger, da
jeg tror bidrar til å holde ekstreme holdninger i sjakk.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Bombing og skyting</title>
                <link>http://www.hungry.com/~pere/blog/Bombing_og_skyting.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Bombing_og_skyting.html</guid>
                <pubDate>Fri, 22 Jul 2011 21:55:00 +0200</pubDate>
                <description>&lt;p&gt;I dag har det blitt bombet i regjeringskvartalet og skutt på AUFs
sommerleir.  Hvem kan stå bak?  Hvem har fordeler av at dette har
skjedd?  Jeg håper de kriminelle som står bak blir funnet og straffet,
og at dette blir gjort på et måte som gjør at demokrati, de mistenktes
borgerrettigheter og samfunnets anstendighet blir ivaretatt.  Jeg
frykter dog at moralpanikk vil føre til at våre alles
borgerrettigheter og det norske demokratiet blir skadelidende.  Vi får
se.  Vi bør i passe oss for å gjøre det såkalte terrorister ønsker,
dvs.  å gjøre samfunnet vårt verre for innbyggerne.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Voteringsdata fra stortinget på plass, mye igjen</title>
                <link>http://www.hungry.com/~pere/blog/Voteringsdata_fra_stortinget_p__plass__mye_igjen.html</link>        
                <guid isPermaLink="true">http://www.hungry.com/~pere/blog/Voteringsdata_fra_stortinget_p__plass__mye_igjen.html</guid>
                <pubDate>Thu, 21 Jul 2011 12:10:00 +0200</pubDate>
                <description>&lt;p&gt;Arbeidet med et nettsted som viser frem hva hver enkelt av våre
folkevalgte har stemt går sakte fremover.  Det har gått to måneder
siden
&lt;a href=&quot;https://people.skolelinux.org/pere/blog/Hvem_stemte_hva_p__Stortinget_.html&quot;&gt;jeg
skrev om prosjektet&lt;/a&gt;.  Siden sist har vi fått kontakt med
organisasjonen &lt;a href=&quot;http://www.holderdeord.no&quot;&gt;Holder De Ord&lt;/a&gt;
som holder på med et lignende prosjekt, samt fått tilgang til endel
voteringsinformasjon fra Stortinget.&lt;/p&gt;

&lt;p&gt;Har fått tilgang til to datasett fra Stortinget.  Det ene er en CD
med voteringsdetaljer mellom 1990 og 2009, det andre er tilgang til
stortingets kommende data-API der en kan hente ut informasjon om
representanter, saker og voteringer.  Jeg har ikke rukket se nok på
noen av dem til å laste dem inn i min prototype, men jeg håper begge
datasettene kan brukes.&lt;/p&gt;

&lt;p&gt;Det første datasettet er kopiert og publisert
&lt;a href=&quot;http://www.nuug.no/pub/stortingsinnsyn/&quot;&gt;på NUUGs
filtjener&lt;/a&gt;, og består av to filer pr. votering.  En fil med
tidspunkt og hver enkelt stemme, og en annen med hvem som stemte og
hvilket parti og fylke de representerte.  Tegnsettet er så vidt jeg
kan se Codepage 865, og jeg håper det er enkelt å koble sammen person
og stemme.  Har ikke rukket forsøke dette ennå.  Jeg tror en god
strategi her er å parse råfilene fra Stortinget og sammenstille dem
med databasen over representanter, og ved hjelp av denne koble de
unike ID-ene til representantene med hver enkelt stemme og publisere
resultatet i XML-format.  Antar det er en par dagers programmering,
men har ikke funnet tid til det.&lt;/p&gt;

&lt;p&gt;Hvis du vil bidra, ta kontakt med meg på IRC (#nuug på
irc.freenode.net) eller bli med på epostlisten
&lt;a href=&quot;http://lists.nuug.no/mailman/listinfo/aktive&quot;&gt;aktive@nuug&lt;/a&gt;.
Det trengs både manne-timer for skraping og finansiering av
utviklingstimer for å en norsk portal på plass.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>