Typo.

[homepage.git] / blog / archive / 2010 / 06 / 06.rss

diff --git a/blog/archive/2010/06/06.rss b/blog/archive/2010/06/06.rss
index 61e8511f3e5f2053789782a3c9dc867a7766e65e..6efe8063b9408184020711f27ad79b35fc32cecf 100644 (file)
--- a/blog/archive/2010/06/06.rss
+++ b/blog/archive/2010/06/06.rss
@@ -54,5 +54,111 @@ effekt på området der?</p>
 </description>
        </item>
        
+       <item>
+               <title>Sitesummary tip: Listing computer hardware models used at site</title>
+               <link>http://people.skolelinux.org/pere/blog/Sitesummary_tip__Listing_computer_hardware_models_used_at_site.html</link>        
+               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Sitesummary_tip__Listing_computer_hardware_models_used_at_site.html</guid>
+                <pubDate>Thu, 3 Jun 2010 12:05:00 +0200</pubDate>
+               <description>
+&lt;p&gt;When using sitesummary at a site to track machines, it is possible
+to get a list of the machine types in use thanks to the DMI
+information extracted from each machine.  The script to do so is
+included in the sitesummary package, and here is example output from
+the Skolelinux build servers:&lt;/p&gt;
+
+&lt;blockquote&gt;&lt;pre&gt;
+maintainer:~# /usr/lib/sitesummary/hardware-model-summary
+  vendor                    count
+  Dell Computer Corporation     1
+    PowerEdge 1750              1
+  IBM                           1
+    eserver xSeries 345 -[8670M1X]-     1
+  Intel                         2
+  [no-dmi-info]                 3
+maintainer:~#
+&lt;/pre&gt;&lt;/blockquote&gt;
+
+&lt;p&gt;The quality of the report depend on the quality of the DMI tables
+provided in each machine.  Here there are Intel machines without model
+information listed with Intel as vendor and mo model, and virtual Xen
+machines listed as [no-dmi-info].  One can add -l as a command line
+option to list the individual machines.&lt;/p&gt;
+
+&lt;p&gt;A larger list is
+&lt;a href=&quot;http://narvikskolen.no/sitesummary/&quot;&gt;available from the the
+city of Narvik&lt;/a&gt;, which uses Skolelinux on all their shools and also
+provide the basic sitesummary report publicly.  In their report there
+are ~1400 machines. I know they use both Ubuntu and Skolelinux on
+their machines, and as sitesummary is available in both distributions,
+it is trivial to get all of them to report to the same central
+collector.&lt;/p&gt;
+</description>
+       </item>
+       
+       <item>
+               <title>A manual for standards wars...</title>
+               <link>http://people.skolelinux.org/pere/blog/A_manual_for_standards_wars___.html</link>        
+               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/A_manual_for_standards_wars___.html</guid>
+                <pubDate>Sun, 6 Jun 2010 14:15:00 +0200</pubDate>
+               <description>
+&lt;p&gt;Via the
+&lt;a href=&quot;http://feedproxy.google.com/~r/robweir/antic-atom/~3/QzU4RgoAGMg/weekly-links-10.html&quot;&gt;blog
+of Rob Weir&lt;/a&gt; I came across the very interesting essay named
+&lt;a href=&quot;http://faculty.haas.berkeley.edu/shapiro/wars.pdf&quot;&gt;The Art of
+Standards Wars&lt;/a&gt; (PDF 25 pages).  I recommend it for everyone
+following the standards wars of today.&lt;/p&gt;
+</description>
+       </item>
+       
+       <item>
+               <title>Upstart or sysvinit - as init.d scripts see it</title>
+               <link>http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html</link>        
+               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html</guid>
+                <pubDate>Sun, 6 Jun 2010 23:55:00 +0200</pubDate>
+               <description>
+&lt;p&gt;If Debian is to migrate to upstart on Linux, I expect some init.d
+scripts to migrate (some of) their operations to upstart job while
+keeping the init.d for hurd and kfreebsd.  The packages with such
+needs will need a way to get their init.d scripts to behave
+differently when used with sysvinit and with upstart.  Because of
+this, I had a look at the environment variables set when a init.d
+script is running under upstart, and when it is not.&lt;/p&gt;
+
+&lt;p&gt;With upstart, I notice these environment variables are set when a
+script is started from rcS.d/ (ignoring some irrelevant ones like
+COLUMNS):&lt;/p&gt;
+
+&lt;blockquote&gt;&lt;pre&gt;
+DEFAULT_RUNLEVEL=2
+previous=N
+PREVLEVEL=
+RUNLEVEL=
+runlevel=S
+UPSTART_EVENTS=startup
+UPSTART_INSTANCE=
+UPSTART_JOB=rc-sysinit
+&lt;/pre&gt;&lt;/blockquote&gt;
+
+&lt;p&gt;With sysvinit, these environment variables are set for the same
+script.&lt;/p&gt;
+
+&lt;blockquote&gt;&lt;pre&gt;
+INIT_VERSION=sysvinit-2.88
+previous=N
+PREVLEVEL=N
+RUNLEVEL=S
+runlevel=S
+&lt;/pre&gt;&lt;/blockquote&gt;
+
+&lt;p&gt;The RUNLEVEL and PREVLEVEL environment variables passed on from
+sysvinit is not set by upstart.  Not sure if it is intentional or not
+to not be compatible with sysvinit in this regard.&lt;/p&gt;
+
+&lt;p&gt;For scripts needing to behave differently when upstart is used,
+looking for the UPSTART_JOB environment variable seem to be a good
+choice.&lt;/p&gt;
+</description>
+       </item>
+       
         </channel>
 </rss>