]> pere.pagekite.me Git - homepage.git/blobdiff - blog/index.rss
projects / homepage.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Generated.
[homepage.git] / blog / index.rss
diff --git a/blog/index.rss b/blog/index.rss
index 5b975768ba34c360475c069a4562b0a13898c83b..9580a6a0fe6c2d3c5957a1f77077985d8a3b7e96 100644 (file)
--- a/blog/index.rss
+++ b/blog/index.rss
@@ -6,6 +6,63 @@
                 <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>My first perl GUI application - controlling a Spykee robot</title>
+               <link>http://people.skolelinux.org/pere/blog/My_first_perl_GUI_application___controlling_a_Spykee_robot.html</link>
+               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/My_first_perl_GUI_application___controlling_a_Spykee_robot.html</guid>
+                <pubDate>Wed, 1 Sep 2010 21:00:00 +0200</pubDate>
+               <description>
+&lt;p&gt;This evening I made my first Perl GUI application.  The last few
+days I have worked on a Perl module for controlling my recently
+aquired Spykee robots, and the module is now getting complete enought
+that it is possible to use it to control the robot driving at least.
+It was now time to figure out how to use it to create some GUI to
+allow me to drive the robot around.  I picked PerlQt as I have had
+positive experiences with the Qt API before, and spent a few minutes
+browsing the web for examples.  Using Qt Designer seemed like a short
+cut, so I ended up writing the perl GUI using Qt Designer and
+compiling it into a perl program using the puic program from
+libqt-perl.  Nothing fancy yet, but it got buttons to connect and
+drive around.&lt;/p&gt;
+
+&lt;p&gt;The perl module I have written provide a object oriented API for
+controlling the robot.  Here is an small example on how to use it:&lt;/p&gt;
+
+&lt;p&gt;&lt;pre&gt;
+use Spykee;
+Spykee::discover(sub {$robot{$_[0]} = $_[1]});
+my $host = (keys %robot)[0];
+my $spykee = Spykee-&gt;new();
+$spykee-&gt;contact($host, &quot;admin&quot;, &quot;admin&quot;);
+$spykee-&gt;left();
+sleep 2;
+$spykee-&gt;right();
+sleep 2;
+$spykee-&gt;forward();
+sleep 2;
+$spykee-&gt;back();
+sleep 2;
+$spykee-&gt;stop();
+&lt;/pre&gt;&lt;/p&gt;
+
+&lt;p&gt;Thanks to the release of the source of the robot firmware, I could
+peek into the implementation at the other end to figure out how to
+implement the protocol used by the robot.  I&#39;ve implemented several of
+the commands the robot understand, but is still missing the camera
+support to make it possible to control the robot from remote.  First I
+want to implement support for uploading new firmware and configuring
+the wireless network, to make it possible to bootstrap a Spykee robot
+without the producers Windows and MacOSX software (I only have Linux,
+so I had to ask a friend to come over to get the robot testing
+going. :).&lt;/p&gt;
+
+&lt;p&gt;Will release the source to the public soon, but need to figure out
+where to make it available first.  I will add a link to 
+&lt;a href=&quot;http://wiki.nuug.no/grupper/robot/&quot;&gt;the NUUG wiki&lt;/a&gt; for
+those that want to check back later to find it.&lt;/p&gt;
+</description>
+       </item>
+       
        <item>
                <title>Forslag i stortinget om å stoppe elektronisk stemmegiving i Norge</title>
                <link>http://people.skolelinux.org/pere/blog/Forslag_i_stortinget_om____stoppe_elektronisk_stemmegiving_i_Norge.html</link>
        <item>
                <title>Forslag i stortinget om å stoppe elektronisk stemmegiving i Norge</title>
                <link>http://people.skolelinux.org/pere/blog/Forslag_i_stortinget_om____stoppe_elektronisk_stemmegiving_i_Norge.html</link>
@@ -369,130 +426,5 @@ long time.&lt;/p&gt;
 </description>
        </item>
        
 </description>
        </item>
        
-       <item>
-               <title>No hardcoded config on Debian Edu clients</title>
-               <link>http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html</link>
-               <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html</guid>
-                <pubDate>Mon, 9 Aug 2010 20:15:00 +0200</pubDate>
-               <description>
-&lt;p&gt;As reported earlier, the last few days I have looked at how Debian
-Edu clients are configured, and tried to get rid of all hardcoded
-configuration settings on the clients.  I believe the work to be
-mostly done, and the clients seem to work just fine with dynamically
-generated configuration.&lt;/p&gt;
-
-&lt;p&gt;What is the point, you might ask?  The point is to allow a Debian
-Edu desktop to integrate into an existing network infrastructure
-without any manual configuration.&lt;/p&gt;
-
-&lt;p&gt;This is what happens when installing a Debian Edu client here at
-the University of Oslo using PXE.  With the PXE installation, I am
-asked for language (Norwegian Bokmål), locality (Norway) and keyboard
-layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
-accept to reformat the hard drive (yes), if I want to submit info to
-popcon.debian.org (no) and root password (secret).  After answering
-these questions, the installer goes ahead and does its thing, and
-after around 50 minutes it is done.  I press enter to finish the
-installation, and the machine reboots into KDE.  When the machine is
-ready and kdm asks for login information, I enter my university
-username and password, am told by kdm that a local home directory has
-been created and that I must log in again, and finally log in with the
-same username and password to the KDE 4.4 desktop.  At no point during
-this process did it ask for university specific settings, and all the
-required configuration was dynamically detected using information
-fetched via DHCP and DNS.  The roaming workstation is now ready for
-use.&lt;/p&gt;
-
-&lt;p&gt;How was this done, you might wonder?  First of all, here is the
-list of things that need to be configured on the client to get it
-working properly out of the box:&lt;/p&gt;
-
-&lt;ul&gt;
-&lt;li&gt;IP address/netmask and DNS server.&lt;/li&gt;
-&lt;li&gt;Web proxy URL.&lt;/li&gt;
-&lt;li&gt;LDAP server for NSS directory information (user, group, etc).&lt;/li&gt;
-&lt;li&gt;Kerberos server for PAM password checking.&lt;/li&gt;
-&lt;li&gt;SMB mount point to access the network home directory. (*)&lt;/li&gt;
-&lt;li&gt;Central syslog server to send syslog messages to. (*)&lt;/li&gt;
-&lt;li&gt;Sitesummary collector URL to submit info to central server. (*)&lt;/li&gt;
-&lt;/ul&gt;
-
-&lt;p&gt;(Hm, did I forget anything?  Let me knew if I did.)&lt;/p&gt;
-
-&lt;p&gt;The points marked (*) are not required to be able to use the
-machine, but needed to provide central storage and allowing system
-administrators to track their machines.  Since yesterday, everything
-but the sitesummary collector URL is dynamically discovered at boot
-and installation time in the svn version of Debian Edu.&lt;/p&gt;
-
-&lt;p&gt;The IP and DNS setup is fetched during boot using DHCP as usual.
-When a DHCP update arrives, the proxy setup is updated by looking for
-http://wpat/wpad.dat and using the content of this WPAD file to
-configure the http and ftp proxy in /etc/environment and
-/etc/apt/apt.conf.  I decided to update the proxy setup using a DHCP
-hook to ensure that the client stops using the Debian Edu proxy when
-it is moved outside the Debian Edu network, and instead uses any local
-proxy present on the new network when it moves around.&lt;/p&gt;
-
-&lt;p&gt;The DNS names of the LDAP, Kerberos and syslog server and related
-configuration are generated using DNS information at boot.  First the
-installer looks for a host named ldap in the current DNS domain.  If
-not found, it looks for _ldap._tcp SRV records in DNS instead.  If an
-LDAP server is found, its root DSE entry is requested and the
-attributes namingContexts and defaultNamingContext are used to
-determine which LDAP base to use for NSS.  If there are several
-namingContexts attibutes and the defaultNamingContext is present, that
-LDAP subtree is used as the base.  If defaultNamingContext is missing,
-the subtrees listed as namingContexts are searched in sequence for any
-object with class posixAccount or posixGroup, and the first one with
-such an object is used as the LDAP base.  For Kerberos, a similar
-search is done by first looking for a host named kerberos, and then
-for the _kerberos._tcp SRV record.  I&#39;ve been unable to find a way to
-look up the Kerberos realm, so for this the upper case string of the
-current DNS domain is used.&lt;/p&gt;
-
-&lt;p&gt;For the syslog server, the hosts syslog and loghost are searched
-for, and the _syslog._udp SRV record is consulted if no such host is
-found.  This algorithm works for both Debian Edu and the University of
-Oslo.  A similar strategy would work for locating the sitesummary
-server, but have not been implemented yet.  I decided to fetch and
-save these settings during installation, to make sure moving to a
-different network does not change the set of users being allowed to
-log in nor the passwords required to log in.  Usernames and passwords
-will be cached by sssd when the user logs in on the Debian Edu
-network, and will not change as the laptop move around.  For a
-non-roaming machine, there is no caching, but given that it is
-supposed to stay in place it should not matter much.  Perhaps we
-should switch those to use sssd too?&lt;/p&gt;
-
-&lt;p&gt;The user&#39;s SMB mount point for the network home directory is
-located when the user logs in for the first time.  The LDAP server is
-consulted to look for the user&#39;s LDAP object and the sambaHomePath
-attribute is used if found.  If it isn&#39;t found, the home directory
-path fetched from NSS is used instead.  Assuming the path is of the
-form /site/server/directory/username, the second part is looked up in
-DNS and used to generate a SMB URL of the form
-smb://server.domain/username.  This algorithm works for both Debian
-edu and the University of Oslo.  Perhaps there are better attributes
-to use or a better algorithm that works for more sites, but this will
-do for now. :)&lt;/p&gt;
-
-&lt;p&gt;This work should make it easier to integrate the Debian Edu clients
-into any LDAP/Kerberos infrastructure, and make the current setup even
-more flexible than before.  I suspect it will also work for thin
-client servers, allowing one to easily set up LTSP and hook it into a
-existing network infrastructure, but I have not had time to test this
-yet.&lt;/p&gt;
-
-&lt;p&gt;If you want to help out with implementing these things for Debian
-Edu, please contact us on debian-edu@lists.debian.org.&lt;/p&gt;
-
-&lt;p&gt;Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to
-detect Kerberos realm from DNS, by looking for _kerberos TXT entries
-before falling back to the upper case DNS domain name.  Will have to
-implement it for Debian Edu. :)&lt;/p&gt;
-</description>
-       </item>
-       
         </channel>
 </rss>
         </channel>
 </rss>
Nettsider og blogg.