Generated.

[homepage.git] / blog / index.rss

diff --git a/blog/index.rss b/blog/index.rss
index d57e3248ba098693d80fe45411fe833c59ceba57..16be48941c8aca93e22cb7c5da17fe9fca78a739 100644 (file)
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -6,6 +6,77 @@
                 <link>http://people.skolelinux.org/pere/blog/</link>
                 <atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
        
                 <link>http://people.skolelinux.org/pere/blog/</link>
                 <atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
        

+       <item>
+               <title>Standardkrav inn i anbudstekster?</title>
+               <link>http://people.skolelinux.org/pere/blog/Standardkrav_inn_i_anbudstekster_.html</link>
+               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Standardkrav_inn_i_anbudstekster_.html</guid>
+                <pubDate>Sun, 17 Oct 2010 19:30:00 +0200</pubDate>
+               <description>
+&lt;p&gt;Hvis det å følge standarder skal ha noen effekt overfor
+leverandører, så må slike krav og ønsker komme inn i anbudstekster når
+systemer kjøpes inn.  Har ikke sett noen slike formuleringer i anbud
+så langt, men har tenkt litt på hva som bør inn.  Her er noen ideer og
+forslag.  Min drøm er at en kan sette krav til slik støtte i
+anbudstekster, men så langt er det nok mer sannsynlig at en må nøye
+seg med å skrive at det er en fordel om slik støtte er tilstede i
+leveranser.&lt;/p&gt;
+
+&lt;p&gt;Som systemadministrator på Universitetet er det typisk to områder
+som er problematiske for meg.  Det ene er admin-grensesnittene på
+tjenermaskiner, som vi ønsker å bruke via ssh.  Det andre er nettsider
+som vi ønsker å bruke via en nettleser.  For begge deler er det viktig
+at protokollene og formatene som brukes følger standarder våre verktøy
+støtter.&lt;/p&gt;
+
+&lt;p&gt;De fleste har nå støtte for SSH som overføringsprotkoll for
+admin-grensesnittet, men det er ikke tilstrekkelig for å kunne stille
+inn f.eks BIOS og RAID-kontroller via ssh-forbindelsen.  Det er flere
+aktuelle protokoller for fremvisning av BIOS-oppsett og
+oppstartmeldinger, og min anbefaling ville være å kreve
+VT100-kompatibel protokoll, for å sikre at flest mulig
+terminalemulatorer kan forstå hva som kommer fra admin-grensesnittet
+via ssh.  Andre aktuelle alternativer er ANSI-terminalemulering og
+VT220.  Kanskje en formulering ala dette i anbudsutlysninger vil
+fungere:&lt;/p&gt;
+
+&lt;p&gt;&lt;blockquote&gt;
+BIOS og oppstartmeldinger i administrasjonsgrensesnittet til maskinen
+bør/skal være tilgjengelig via SSH-protokollen som definert av IETF
+(RFC 4251 mfl.) og følge terminalfremvisningprotokollen VT100 (ref?)
+når en kobler seg til oppstart via ssh.
+&lt;/blockquote&gt;&lt;/p&gt;
+
+&lt;p&gt;Har ikke lykkes med å finne en god referanse for
+VT100-spesifikasjonen.&lt;/p&gt;
+
+&lt;p&gt;Når det gjelder nettsider, så er det det HTML, CSS og
+JavaScript-spesifikasjonen til W3C som gjelder.&lt;/p&gt;
+
+&lt;p&gt;&lt;blockquote&gt;
+Alle systemets nettider bør/skal være i henhold til statens
+standardkatalogs krav om nettsider og følge HTML-standarden som
+definert av W3C, og validere uten feil hos W3Cs HTML-validator
+(http://validator.w3.org).  Hvis det brukes CSS så bør/skal denne
+validere uten feil hos W3Cs CSS-validator
+(http://jigsaw.w3.org/css-validator/).  Eventuelle JavaScript skal
+være i henhold til EcmaScript-standarden.  I tillegg til å følge de
+overnevnte standardene skal websidene fungere i nettleserne (fyll inn
+relevant liste for organisasjonen) Firefox 3.5, Internet Explorer 8,
+Opera 9, etc.
+&lt;/blockquote&gt;&lt;/p&gt;
+
+&lt;p&gt;Vil et slikt avsnitt være konkret nok til å få leverandørene til å
+lage nettsider som følger standardene og fungerer i flere
+nettlesere?&lt;/p&gt;
+
+&lt;p&gt;Tar svært gjerne imot innspill på dette temaet til aktive (at)
+nuug.no, og er spesielt interessert i hva andre skriver i sine anbud
+for å oppmuntre leverandører til å følge standardene.  Kanskje NUUG
+burde lage et dokument med forslag til standardformuleringer å ta med
+i anbudsutlysninger?&lt;/p&gt;
+</description>
+       </item>
+       

        <item>
                <title>Datatilsynet svarer om Bilkollektivets ønske om GPS-sporing</title>
                <link>http://people.skolelinux.org/pere/blog/Datatilsynet_svarer_om_Bilkollektivets___nske_om_GPS_sporing.html</link>
        <item>
                <title>Datatilsynet svarer om Bilkollektivets ønske om GPS-sporing</title>
                <link>http://people.skolelinux.org/pere/blog/Datatilsynet_svarer_om_Bilkollektivets___nske_om_GPS_sporing.html</link>


@@ -407,35 +478,5 @@ Theora&lt;/a&gt;, and avoid MPEG-4 and H.264 if you can.&lt;/p&gt;
 </description>
        </item>
        
 </description>
        </item>
        

-       <item>
-               <title>Navteq bruker 3-12 måneder, OpenStreetmap.org trenger noen dager</title>
-               <link>http://people.skolelinux.org/pere/blog/Navteq_bruker_3_12_m__neder__OpenStreetmap_org_trenger_noen_dager.html</link>
-               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Navteq_bruker_3_12_m__neder__OpenStreetmap_org_trenger_noen_dager.html</guid>
-                <pubDate>Tue, 7 Sep 2010 21:40:00 +0200</pubDate>
-               <description>
-&lt;p&gt;Jeg ble riktig fascinert av
-&lt;a href=&quot;http://www.aftenposten.no/nyheter/iriks/article3800967.ece&quot;&gt;en
-artikkel i Aftenposten&lt;/a&gt; om hvor hardt Navteq jobber for å oppdatere
-kartene som brukes i navigasjons-GPSer, der det blant annet heter at
-&quot;på grunn av teknikken tar det alt fra tre til tolv måneder før
-kartene er oppdatert&quot;.  Når en kjenner hva slags oppdateringshastighet
-som er tilgjengelig på
-&lt;a href=&quot;http://www.openstreetmap.org/&quot;&gt;OpenStreetmap&lt;/a&gt; som
-oppdateres på dugnad, blir det litt trist å se hva noe av det beste en
-kan kjøpe for penger får til.&lt;/p&gt;
-
-&lt;p&gt;Fra en endrer kartdataene i databasen til OpenStreetmap tar det
-ca. 15 minutter før endringen er synlig på kartet som alle kan se på
-web.  Dernest overføres det daglig til en kartdump som lastes ned av
-personen som lager Garmin-kart for Norge ca. en gang i uken.  Med
-OpenStreetmap.org og &lt;a href=&quot;http://www.frikart.no/&quot;&gt;Frikart.no&lt;/a&gt;
-kan en altså ha korreksjonene på plass i sin Garmin-GPS i løpet av en
-uke.  Det er også av tekniske årsaker at det tar så langt tid.
-Jobbene som tegner kartene, henter ut kartdumpene og konverterer til
-Garmin-format tar minutter og timer å gjennomføre, slik at de ikke
-gjøres kontinuerlig men kun regelmessing.&lt;/p&gt;
-</description>
-       </item>
-       

         </channel>
 </rss>
         </channel>
 </rss>