<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>
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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:</p>
+
+<p><blockquote>
+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.
+</blockquote></p>
+
+<p>Har ikke lykkes med å finne en god referanse for
+VT100-spesifikasjonen.</p>
+
+<p>Når det gjelder nettsider, så er det det HTML, CSS og
+JavaScript-spesifikasjonen til W3C som gjelder.</p>
+
+<p><blockquote>
+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.
+</blockquote></p>
+
+<p>Vil et slikt avsnitt være konkret nok til å få leverandørene til å
+lage nettsider som følger standardene og fungerer i flere
+nettlesere?</p>
+
+<p>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?</p>
+</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>
</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>
-<p>Jeg ble riktig fascinert av
-<a href="http://www.aftenposten.no/nyheter/iriks/article3800967.ece">en
-artikkel i Aftenposten</a> om hvor hardt Navteq jobber for å oppdatere
-kartene som brukes i navigasjons-GPSer, der det blant annet heter at
-"på grunn av teknikken tar det alt fra tre til tolv måneder før
-kartene er oppdatert". Når en kjenner hva slags oppdateringshastighet
-som er tilgjengelig på
-<a href="http://www.openstreetmap.org/">OpenStreetmap</a> som
-oppdateres på dugnad, blir det litt trist å se hva noe av det beste en
-kan kjøpe for penger får til.</p>
-
-<p>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 <a href="http://www.frikart.no/">Frikart.no</a>
-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.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff