Generated.

[homepage.git] / blog / index.rss

diff --git a/blog/index.rss b/blog/index.rss
index 0a36c793af3b1fac911e8b82feff28c279583cec..636b125548c73e28c9af7c0ed76af250401f4d37 100644 (file)
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -6,6 +6,37 @@
                 <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>KDM fail at boot with NVidia cards - and no one try to fix it?</title>
+               <link>http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</link>
+               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</guid>
+                <pubDate>Tue, 1 Jun 2010 17:05:00 +0200</pubDate>
+               <description>
+&lt;p&gt;It is strange to watch how a bug in Debian causing KDM to fail to
+start at boot when an NVidia video card is used.  The problem seem to
+be that the nvidia X.org driver uses a long time to initialize, and
+this duration is longer than kdm is configured to wait.&lt;/p&gt;
+
+&lt;p&gt;I came across two bugs related to this issue,
+&lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;#583312&lt;/a&gt; initially filed
+against initscripts and passed on to nvidia-glx when it became obvious
+that the nvidia drivers were involved, and
+&lt;a href=&quot;http://bugs.debian.org/524751&quot;&gt;#524751&lt;/a&gt; initially filed against
+kdm and passed on to src:nvidia-graphics-drivers for unknown reasons.&lt;/p&gt;
+
+&lt;p&gt;To me, it seem that no-one is interested in actually solving the
+problem nvidia video card owners experience and make sure the Debian
+distribution work out of the box for these users.  The nvidia driver
+maintainers expect kdm to be set up to wait longer, while kdm expect
+the nvidia driver maintainers to fix the driver start faster, and
+while they wait for each other I guess the users end up switching to a
+distribution that work for them.  I have no idea what the solution is,
+but I am pretty sure that waiting for each other is not it.&lt;/p&gt;
+
+&lt;p&gt;I wonder why we end up handling bugs this way.&lt;/p&gt;
+</description>
+       </item>
+       

        <item>
                <title>Parallellized boot seem to hold up well in Debian/testing</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</link>
        <item>
                <title>Parallellized boot seem to hold up well in Debian/testing</title>
                <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</link>


@@ -460,79 +491,5 @@ change.&lt;/p&gt;
 </description>
        </item>
        
 </description>
        </item>
        

-       <item>
-               <title>Thoughts on roaming laptop setup for Debian Edu</title>
-               <link>http://people.skolelinux.org/pere/blog/Thoughts_on_roaming_laptop_setup_for_Debian_Edu.html</link>
-               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Thoughts_on_roaming_laptop_setup_for_Debian_Edu.html</guid>
-                <pubDate>Wed, 28 Apr 2010 20:40:00 +0200</pubDate>
-               <description>
-&lt;p&gt;For some years now, I have wondered how we should handle laptops in
-Debian Edu.  The Debian Edu infrastructure is mostly designed to
-handle stationary computers, and less suited for computers that come
-and go.&lt;/p&gt;
-
-&lt;p&gt;Now I finally believe I have an sensible idea on how to adjust
-Debian Edu for laptops, by introducing a new profile for them, for
-example called Roaming Workstations.  Here are my thought on this.
-The setup would consist of the following:&lt;/p&gt;
-
-&lt;ul&gt;
-
- &lt;li&gt;During installation, the user name of the owner / primary user of
-   the laptop is requested and a local home directory is set up for
-   the user, with uid and gid information fetched from the LDAP
-   server.  This allow the user to work also when offline.  The
-   central home directory can be available in a subdirectory on
-   request, for example mounted via CIFS.  It could be mounted
-   automatically when a user log in while on the Debian Edu network,
-   and unmounted when the machine is taken away (network down,
-   hibernate, etc), it can be set up to do automatic mounting on
-   request (using autofs), or perhaps some GUI button on the desktop
-   can be used to access it when needed.  Perhaps it is enough to use
-   the fish protocol in KDE?&lt;/li&gt;
-
- &lt;li&gt;Password checking is set up to use LDAP or Kerberos
-   authentication when the machine is on the Debian Edu network, and
-   to cache the password for offline checking when the machine unable
-   to reach the LDAP or Kerberos server.  This can be done using
-   &lt;a href=&quot;http://www.padl.com/OSS/pam_ccreds.html&quot;&gt;libpam-ccreds&lt;/a&gt;
-   or the Fedora developed
-   &lt;a href=&quot;https://fedoraproject.org/wiki/Features/SSSD&quot;&gt;System
-   Security Services Daemon&lt;/a&gt; packages.&lt;/li&gt;
-
- &lt;li&gt;File synchronisation with the central home directory is set up
-   using a shared directory in both the local and the central home
-   directory, using unison.&lt;/li&gt;
-
- &lt;li&gt;Printing should be set up to print to all printers broadcasting
-   their existence on the local network, and should then work out of
-   the box with CUPS.  For sites needing accurate printer quotas, some
-   system with Kerberos authentication or printing via ssh could be
-   implemented.&lt;/li&gt;
-
- &lt;li&gt;For users that should have local root access to their laptop,
-   sudo should be used to allow this to the local user.&lt;/li&gt;
-
- &lt;li&gt;It would be nice if user and group information from LDAP is
-   cached on the client, but given that there are entries for the
-   local user and primary group in /etc/, it should not be needed.&lt;/li&gt;
-
-&lt;/ul&gt;
-
-&lt;p&gt;I believe all the pieces to implement this are in Debian/testing at
-the moment.  If we work quickly, we should be able to get this ready
-in time for the Squeeze release to freeze.  Some of the pieces need
-tweaking, like libpam-ccreds should get support for pam-auth-update
-(&lt;a href=&quot;http://bugs.debian.org/566718&quot;&gt;#566718&lt;/a&gt;) and nslcd (or
-perhaps debian-edu-config) should get some integration code to stop
-its daemon when the LDAP server is unavailable to avoid long timeouts
-when disconnected from the net.  If we get Kerberos enabled, we need
-to make sure we avoid long timeouts there too.&lt;/p&gt;
-
-&lt;p&gt;If you want to help out with implementing this for Debian Edu,
-please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
-</description>
-       </item>
-       

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