<link></link>
<atom:link href="index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>No patch is not better than a useless patch</title>
+ <link>No_patch_is_not_better_than_a_useless_patch.html</link>
+ <guid isPermaLink="true">No_patch_is_not_better_than_a_useless_patch.html</guid>
+ <pubDate>Tue, 28 Apr 2009 09:30:00 +0200</pubDate>
+ <description>
+<p>Julien Blache
+<a href="http://blog.technologeek.org/2009/04/12/214">claim that no
+patch is better than a useless patch</a>. I completely disagree, as a
+patch allow one to discuss a concrete and proposed solution, and also
+prove that the issue at hand is important enough for someone to spent
+time on fixing it. No patch do not provide any of these positive
+properties.</p>
+</description>
+ </item>
+
+ <item>
+ <title>EU-parlamentet raner fellesskapet for musikk</title>
+ <link>EU_parlamentet_raner_fellesskapet_for_musikk.html</link>
+ <guid isPermaLink="true">EU_parlamentet_raner_fellesskapet_for_musikk.html</guid>
+ <pubDate>Sun, 26 Apr 2009 08:30:00 +0200</pubDate>
+ <description>
+<p>Slashdot melder at EU-parlamentet har vedtatt
+<a href="http://www.europarl.europa.eu/news/expert/infopress_page/058-54192-111-04-17-909-20090422IPR54191-21-04-2009-2009-false/default_en.htm">å
+øke vernetiden for musikkopptak fra 50 til 70 år</a>, og dermed rane
+fellesskapet for 20 år med musikk som ville vært tilgjengelig uten
+bruksbegresninger. Mon tro hvor mye musikk som vil gå tapt pga. at
+ingen tar vare på den (opphavsrettsinnehaver er forsvunnet), mens
+ingen andre har lov til å kopiere og distribuere den. Mon tro hvor
+mange musikkstykker som ikke kan brukes uten bruksbegresninger av
+folket, som skulle falt i det fri men som i stedet forblir under
+rettighetshavers monopol. Opphavsrettslovgivingen blir mer og mer
+urimelig. Tenke seg til at vernetiden startet i USA med 7 år og
+mulighet for forlengelse med 7 år. Nå er den 95 år der, og en stor
+mengde verk blir foreldreløse og umulig å få tak i. Har ikke lykkes
+med å finne ut hvor lang opphavsretten var i utgangspunktet i Norge.
+I dag er den 70 år.</p>
+
+<p>Jeg er glad det finnes <a href="http://www.jamendo.com/">så mye
+musikk tilgjengelig uten bruksbegresninger</a> at en kan klare seg
+uten musikk med bruksbegresninger.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Hvor flyter Microsofts penger?</title>
+ <link>Hvor_flyter_Microsofts_penger_.html</link>
+ <guid isPermaLink="true">Hvor_flyter_Microsofts_penger_.html</guid>
+ <pubDate>Fri, 24 Apr 2009 11:10:00 +0200</pubDate>
+ <description>
+<p>Dagens nyhet er at omsetningen til Microsoft for første gang er
+synkende. Ikke spesielt uventet med den generelle nedgangen i
+økonomien som vi ser verden over. Det fikk meg dog til å tenke på en
+ting fra noen år tilbake.</p>
+
+<p>Da jeg besøkte en kamerat i Beijing sommeren 2000, ble jeg fortalt
+at påstanden til Microsoft om at de brakte inn enorme pengesummer til
+USA nok var litt overdrevet, da de fleste inntektene fra lisenssalg
+rundt om i verden ble kanalisert inn til skatteparadiset
+<a href="http://en.wikipedia.org/wiki/Cayman_Islands">Cayman
+Island</a>. Jeg har aldri lykkes med å få bekreftet dette påstanden,
+men tok i dag en titt på hvilke selskaper som eier de norske delene av
+Microsoft som jeg kjenner til, dvs.
+<a href="http://www.proff.no/proff/search/companyRoles.c?freeText=microsoft&bc=0&c=Z001YP4Y&org=957485030">Microsoft
+Norge AS</a> og
+<a href="http://www.proff.no/proff/search/companyRoles.c?freeText=fast&bc=348&c=Z0HR5KDT&org=979158831">FAST,
+A Microsoft Subsidiary</a> (tidligere FAST Search & Transfer ASA).</p>
+
+<p>Førstnevnte er eid av "Microsoft International Holdings Spain
+S.R.L.", mens sistnevnte i følge Wikipedia nå eies av
+Microsoft-underselskapet "MACS Holdings Limited". Jeg har ikke klart
+å finne mer informasjon om noen av disse. Mon tro om noen av dem
+sender pengene til Cayman Island? Finner det jeg tror er
+<a href="http://www.informacion-empresas.com/Empresa_MICROSOFT-INTERNATIONAL-HOLDINGS-SPAIN.html">informasjon
+om spaniaselskapet på spansk</a>, men jeg kan ikke lese spansk. :(</p>
+</description>
+ </item>
+
<item>
<title>Hvorfor jeg ikke bruker eFaktura</title>
<link>Hvorfor_jeg_ikke_bruker_eFaktura.html</link>
</description>
</item>
- <item>
- <title>Standardize on protocols and formats, not vendors and applications</title>
- <link>Standardize_on_protocols_and_formats__not_vendors_and_applications.html</link>
- <guid isPermaLink="true">Standardize_on_protocols_and_formats__not_vendors_and_applications.html</guid>
- <pubDate>Mon, 30 Mar 2009 11:50:00 +0200</pubDate>
- <description>
-<p>Where I work at the University of Oslo, one decision stand out as a
-very good one to form a long lived computer infrastructure. It is the
-simple one, lost by many in todays computer industry: Standardize on
-open network protocols and open exchange/storage formats, not applications.
-Applications come and go, while protocols and files tend to stay, and
-thus one want to make it easy to change application and vendor, while
-avoiding conversion costs and locking users to a specific platform or
-application.</p>
-
-<p>This approach make it possible to replace the client applications
-independently of the server applications. One can even allow users to
-use several different applications as long as they handle the selected
-protocol and format. In the normal case, only one client application
-is recommended and users only get help if they choose to use this
-application, but those that want to deviate from the easy path are not
-blocked from doing so.</p>
-
-<p>It also allow us to replace the server side without forcing the
-users to replace their applications, and thus allow us to select the
-best server implementation at any moment, when scale and resouce
-requirements change.</p>
-
-<p>I strongly recommend standardizing - on open network protocols and
-open formats, but I would never recommend standardizing on a single
-application that do not use open network protocol or open formats.</p>
-</description>
- </item>
-
- <item>
- <title>Returning from Skolelinux developer gathering</title>
- <link>Returning_from_Skolelinux_developer_gathering.html</link>
- <guid isPermaLink="true">Returning_from_Skolelinux_developer_gathering.html</guid>
- <pubDate>Sun, 29 Mar 2009 21:00:00 +0200</pubDate>
- <description>
-<p>I'm sitting on the train going home from this weekends Debian
-Edu/Skolelinux development gathering. I got a bit done tuning the
-desktop, and looked into the dynamic service location protocol
-implementation avahi. It look like it could be useful for us. Almost
-30 people participated, and I believe it was a great environment to
-get to know the Skolelinux system. Walter Bender, involved in the
-development of the Sugar educational platform, presented his stuff and
-also helped me improve my OLPC installation. He also showed me that
-his Turtle Art application can be used in standalone mode, and we
-agreed that I would help getting it packaged for Debian. As a
-standalone application it would be great for Debian Edu. We also
-tried to get the video conferencing working with two OLPCs, but that
-proved to be too hard for us. The application seem to need more work
-before it is ready for me. I look forward to getting home and relax
-now. :)</p>
-</description>
- </item>
-
- <item>
- <title>Time for new LDAP schemas replacing RFC 2307?</title>
- <link>Time_for_new__LDAP_schemas_replacing_RFC_2307_.html</link>
- <guid isPermaLink="true">Time_for_new__LDAP_schemas_replacing_RFC_2307_.html</guid>
- <pubDate>Sun, 29 Mar 2009 20:30:00 +0200</pubDate>
- <description>
-<p>The state of standardized LDAP schemas on Linux is far from
-optimal. There is RFC 2307 documenting one way to store NIS maps in
-LDAP, and a modified version of this normally called RFC 2307bis, with
-some modifications to be compatible with Active Directory. The RFC
-specification handle the content of a lot of system databases, but do
-not handle DNS zones and DHCP configuration.</p>
-
-<p>In <a href="http://www.skolelinux.org/">Debian Edu/Skolelinux</a>,
-we would like to store information about users, SMB clients/hosts,
-filegroups, netgroups (users and hosts), DHCP and DNS configuration,
-and LTSP configuration in LDAP. These objects have a lot in common,
-but with the current LDAP schemas it is not possible to have one
-object per entity. For example, one need to have at least three LDAP
-objects for a given computer, one with the SMB related stuff, one with
-DNS information and another with DHCP information. The schemas
-provided for DNS and DHCP are impossible to combine into one LDAP
-object. In addition, it is impossible to implement quick queries for
-netgroup membership, because of the way NIS triples are implemented.
-It just do not scale. I believe it is time for a few RFC
-specifications to cleam up this mess.</p>
-
-<p>I would like to have one LDAP object representing each computer in
-the network, and this object can then keep the SMB (ie host key), DHCP
-(mac address/name) and DNS (name/IP address) settings in one place.
-It need to be efficently stored to make sure it scale well.</p>
-
-<p>I would also like to have a quick way to map from a user or
-computer and to the net group this user or computer is a member.</p>
-
-<p>Active Directory have done a better job than unix heads like myself
-in this regard, and the unix side need to catch up. Time to start a
-new IETF work group?</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff