<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>code on Silicone&#39;s web</title>
		<link>https://silicone.homelinux.org/tags/code/</link>
		<description>Recent content in code on Silicone&#39;s web</description>
		<generator>Hugo</generator>
		<language>fr</language>
		
		
		
		
			<lastBuildDate>Wed, 03 Oct 2018 21:30:22 +0100</lastBuildDate>
		
			<atom:link href="https://silicone.homelinux.org/tags/code/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Inside an Open Source BIOS</title>
				<link>https://silicone.homelinux.org/2018/04/11/inside-an-open-source-bios/</link>
				<pubDate>Wed, 11 Apr 2018 12:00:37 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2018/04/11/inside-an-open-source-bios/</guid>
				<description>&lt;p&gt;&lt;em&gt;This post was originally published as &lt;a title=&#34;A look from behind the Open Source Bios&#34; href=&#34;https://blog.online.net/2018/04/10/a-look-from-behind-the-open-source-bios/&#34; target=&#34;_blank&#34;&gt;A look from behind the Open Source Bios&lt;/a&gt; on Scaleway’s blog.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;This is a followup post of &lt;a href=&#34;http://silicone.homelinux.org/2018/03/16/open-source-bios-at-scale/&#34; title=&#34;Open Source Bios at Scale&#34;&gt;Open Source Bios at Scale&lt;/a&gt; so you might what to read it first as this post will get more into details.&lt;/p&gt;&#xA;&lt;p&gt;As explained in the previous post our BIOS is build with three main components: &lt;a href=&#34;https://www.coreboot.org/&#34; rel=&#34;nofollow&#34;&gt;coreboot&lt;/a&gt;, Intel FSP and &lt;a href=&#34;http://www.tianocore.org/&#34; rel=&#34;nofollow&#34;&gt;TianoCore&lt;/a&gt;. We will describe here how those three parts are fitting together.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Open Source Bios at Scale</title>
				<link>https://silicone.homelinux.org/2018/03/16/open-source-bios-at-scale/</link>
				<pubDate>Fri, 16 Mar 2018 12:00:02 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2018/03/16/open-source-bios-at-scale/</guid>
				<description>&lt;p&gt;&lt;em&gt;This post is a summary of &lt;a title=&#34;Open Source Bios at Scale&#34; href=&#34;https://fosdem.org/2018/schedule/event/hwenablement_open_source_bios_at_scale/&#34; target=&#34;_blank&#34;&gt;my talk at FOSDEM’18&lt;/a&gt; and was originally posted on &lt;a title=&#34;Open Source Bios at Scale&#34; href=&#34;https://blog.online.net/2018/03/15/open-source-bios-at-scale/&#34; target=&#34;_blank&#34;&gt;Scaleway’s blog&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;At &lt;a href=&#34;https://scaleway.com&#34; rel=&#34;nofollow&#34;&gt;Scaleway&lt;/a&gt; we started to design our servers with the &lt;a href=&#34;https://www.scaleway.com/baremetal-cloud-servers&#34; rel=&#34;nofollow&#34;&gt;ARM C1&lt;/a&gt;.&lt;br&gt;&#xA;Later we switched to a x86 architecture to provide the &lt;a href=&#34;https://www.scaleway.com/baremetal-cloud-servers/&#34; rel=&#34;nofollow&#34;&gt;C2&lt;/a&gt; and &lt;a href=&#34;https://www.online.net/fr/serveur-dedie/dedibox-sc&#34; rel=&#34;nofollow&#34; hreflang=&#34;fr&#34;&gt;Dedibox SC2016&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;On x86 a BIOS is required to start the server. BIOS software got many legacy and backward compatible software to ensure a reliable behavior across many boards. I was in charge of the BIOS development for our new generation of x86 servers.&lt;/p&gt;&#xA;&lt;p&gt;This article presents technical choices we used during our development.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Développement noyau sur e60</title>
				<link>https://silicone.homelinux.org/2011/04/03/developpement-noyau-sur-e60/</link>
				<pubDate>Sun, 03 Apr 2011 20:52:14 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2011/04/03/developpement-noyau-sur-e60/</guid>
				<description>&lt;p&gt;Comme j’ai accès à la &lt;a href=&#34;http://silicone.homelinux.org/2011/03/22/console-serie-sur-liseuse-samsung-e60/&#34;&gt;console série sur liseuse Samsung e60&lt;/a&gt; compilons un nouveau noyau linux.&lt;/p&gt;&#xA;&lt;p&gt;Le processeur de la liseuse e60 est un ARM, pour compiler le noyau pour ce processeur il nous faut une chaine de compilation croisée.&lt;br&gt;&#xA;La première option est d’utiliser celle fournie par samsung avec le reste des sources. A priori ça fonctionne mais utiliser des binaires de sources inconnue ne m’enchantait guerre.&lt;br&gt;&#xA;La seconde solution serait de recompiler la chaine nous même, c’est souvent la seule solutions pour des systèmes exotiques nécessitant quelques patchs.&lt;br&gt;&#xA;Ici, a bien regardé les fichiers de Samsung, les binutils viennent d’une version entre 2.17 et 2.18 (leur version est nommée 2.17.50 mais ne correspond pas tout à fait à se snapshot non plus…) mais il ne semble pas y avoir de patch ‘maison’. Quand a gcc j’ai pas pris le temps de vérifier.&lt;br&gt;&#xA;J’ai opté pour la &lt;a href=&#34;http://www.emdebian.org/crosstools.html&#34; hreflang=&#34;en&#34;&gt;chaine de compilation croisée du projet emdebian&lt;/a&gt; dans sa version lenny (Tout comme le propose &lt;a href=&#34;http://www.editions-diamond.com/opensilicium/index.php/edito-open-silicium-n%C2%B01&#34;&gt;le magazine Open Silicium n°1&lt;/a&gt; dans son article sur FriendlyARM).&lt;/p&gt;&#xA;&lt;h3 id=&#34;installation-de-la-chaine-de-compilation-croisée-sur-debian&#34;&gt;Installation de la chaine de compilation croisée sur debian&lt;/h3&gt;&#xA;&lt;p&gt;Tout d’abord les clef des l’archive:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&#xA;sudo apt-get install emdebian-archive-keyring&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Ensuite nous ajoutons un fichier &lt;code&gt;/etc/apt/sources.list.d/emdebian.list&lt;/code&gt; avec le contenu suivant:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&#xA;deb http://ftp.uk.debian.org/emdebian/toolchains lenny main&#xA;deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Puis une mise à jours des liste des paquets afin d’installer les paquets nécessaires:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&#xA;sudo apt-get update&#xA;sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Voila, nous disposons maintenant d’une chaine de compilation croisée installée avec des paquets, donc facile à mettre à jour ou à désinstaller.&lt;/p&gt;&#xA;&lt;h3 id=&#34;les-sources-du-noyau&#34;&gt;Les sources du noyau&lt;/h3&gt;&#xA;&lt;p&gt;Samsung fournit une version modifiée du 2.6.29.4, en récupérant &lt;a href=&#34;http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.29.y.git%3Ba%3Dsummary&#34;&gt;la branche git 2.6.29.y du noyau&lt;/a&gt;, j’ai rapidement vu que leur changement s’appliquait à la version 2.6.29.6 (dernière de cette branche).&lt;/p&gt;&#xA;&lt;p&gt;Afin de mieux trier les changements michel.s avait déjà séparé les changements de Samsung en plusieurs patchs (&lt;a href=&#34;http://code.google.com/p/e60-open/source/browse/#svn%2Fpatches%2Fkernel&#34;&gt;les patchs sur le projet e60-open&lt;/a&gt;). Après quelques essai j’ai concocté un fichier &lt;code&gt;series&lt;/code&gt; qui permet d’appliquer ces patchs avec &lt;code&gt;quilt&lt;/code&gt; ou mieux encore de des importer dans une branche git avec &lt;code&gt;git quiltimport&lt;/code&gt;. L’ordre que j’ai choisit permet en particulier de se débarrasser facilement des quelques patchs (les derniers).&lt;/p&gt;&#xA;&lt;p&gt;On notera dans ces patchs la présence de quelques fichiers binaires:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;code&gt;fs/rfs/*.o&lt;/code&gt; une couche de journalisation propriétaire sur la fat. Si vous voulez mon avis, elle n’est pas nécessaire, après tout nous disposons de systèmes de fichiers journalisé libre, et linux est capable de monter autre chose que de la FAT par USB…&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;drivers/usb/gadget/file_storage.o&lt;/code&gt; le fichier &lt;code&gt;.c&lt;/code&gt; correspondant a de plus été retiré, la licence BSD/GPL de l’original autorise une distribution binaire (toutefois, je n’ai pas vérifié si Alan Stern est cité dans la doc) mais j’aurais bien apprécié que Samsung fournisse le source.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;u-boot&#34;&gt;U-Boot&lt;/h3&gt;&#xA;&lt;p&gt;Avant de compiler le noyau, il nous faut l’utilitaire &lt;code&gt;mkimage&lt;/code&gt; fourni par U-Boot. Ici, pas de chichis, nous compilons la version de U-Boot fournie par Samsung, et nous copions &lt;code&gt;tools/mkimage&lt;/code&gt; dans notre path (c’est la seule méthode d’installation que j’ai pu trouver).&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&#xA;make smdkc100_config &#xA;make CROSS_COMPILE=arm-linux-gnueabi-&#xA;&#xA;cp tools/mkimage ~/bin/&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;h3 id=&#34;compilation-de-linux&#34;&gt;Compilation de linux&lt;/h3&gt;&#xA;&lt;p&gt;Pour la configuration un des patch fourni un &lt;code&gt;.config&lt;/code&gt; qui est une copie de &lt;code&gt;config_rfs&lt;/code&gt; donc même sans appliquer ce patch, nous pouvons récupérer la config de samsung.&lt;/p&gt;&#xA;&lt;p&gt;Ensuite, on compile enfin !&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&#xA;make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS=&amp;#34;-march=armv4t -mtune=cortex-a8&amp;#34; CXXFLAGS=&amp;#34;-march=armv4t -mtune=cortex-a8&amp;#34; ARCH=arm uImage&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Nous pouvons charger notre noyau en suivant &lt;a href=&#34;http://code.google.com/p/e60-open/wiki/HowToTestAKernel&#34; hreflang=&#34;en&#34;&gt;la procédure de test de noyau du projet e60-open&lt;/a&gt; la commande pour changer le noyau sera alors&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&#xA;sudo dnw arch/arm/boot/uImage&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Voila, ça marche ! Enfin presque, le noyau ne trouve pas ses modules. Ceux présents dans nos sources ne sont pas un vrai problème (mais le sujet d’un prochain article) en revanche les modules &lt;code&gt;/lib/modules/max14540.ko&lt;/code&gt; et &lt;code&gt;lib/modules/dhd.ko&lt;/code&gt; ne sont pas présent dans les sources alors qu’ils présentent une licence GPL au noyau.&lt;/p&gt;&#xA;&lt;h3 id=&#34;les-sources-manquants&#34;&gt;Les sources manquants&lt;/h3&gt;&#xA;&lt;p&gt;Le site &lt;a href=&#34;http://opensource.samsung.com/&#34; hreflang=&#34;en&#34;&gt;Samsung Open Source Release Center&lt;/a&gt; possède une interface pour les contacter, mais elle ne semble pas bien fonctionner (j’ai même booter mon netbook sous windows pour essayer avec IE8 sans succes!). En fouillant le &lt;a href=&#34;http://forum.hardware.fr/hfr/gsmgpspda/tablet/unique-samsung-ebook-sujet_22344_66.htm#para621535&#34;&gt;forum e60&lt;/a&gt; j’ai retrouvé leur adresse email et leur ai écrit, pas de réponse jusqu’à présent (pas même automatique…). Patience …&lt;/p&gt;&#xA;&lt;h3 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h3&gt;&#xA;&lt;p&gt;Nous pouvons compiler le noyau de la liseuse e60 sans utiliser la chaine de compilation fournie par Samsung.&lt;br&gt;&#xA;Il reste du travail pour le changement des modules car ceux présent sur la liseuses sont compilé pour la version 2.6.29.4 du noyau et notre noyau refuse de les charger. (J’ai déjà fait quelques tests mais ça sera le sujet d’un prochain article.)&lt;br&gt;&#xA;Et surtout sans les sources manquants nous allons avoir du mal a exploiter au mieux notre liseuse e60.&lt;/p&gt;&#xA;&lt;p&gt;Mise à jours: Je viens de recevoir une réponse de Samsung, ils ont mis a jours leur archive. Il faut encore que je test ça.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Premiers pas en développement noyau</title>
				<link>https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/</link>
				<pubDate>Tue, 08 Mar 2011 21:34:09 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/</guid>
				<description>&lt;p&gt;Je voulais me mettre au développement noyau, mais je ne savais pas par où commencer, alors un sage m’a dit: « pour apprendre rien de tel que de le faire: vous achetez un petit périphérique USB et vous en écrivez le driver. »&lt;br&gt;&#xA;Ma réponse a été: « effectivement, je n’y avais pas pensé, en général on utilise la libusb pour ce genre de choses. »&lt;/p&gt;&#xA;&lt;h3 id=&#34;un-périphérique-usb&#34;&gt;Un périphérique USB&lt;/h3&gt;&#xA;&lt;p&gt;Et voila que quelques jours après, sans avoir trouvé de périphérique sympa je me suis dit, mais pourquoi pas le faire aussi ?&lt;br&gt;&#xA;&lt;a href=&#34;http://silicone.homelinux.org/2010/02/03/ca-fait-un-bail/&#34;&gt;Comme je vous l’ai déjà raconté&lt;/a&gt;, j’ai déjà bricolé un périphérique USB: l’USBtinyISP, donc je suis allé rechercher le code original de &lt;a href=&#34;http://www.xs4all.nl/~dicks/avr/usbtiny/&#34;&gt;usbtiny&lt;/a&gt; et je me suis monté un petit prototype avec 4 LED et 2 boutons:&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_prototype.jpg&#34;&#xA;         srcset=&#34;https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_prototype.jpg 400w, https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_prototype-300x192.jpg 300w&#34;&#xA;         sizes=&#34;auto, (max-width: 400px) 100vw, 400px&#34;&#xA;         alt=&#34;Photo de mon prototype&#34; title=&#34;USB Gadget prototype&#34; width=&#34;400&#34; height=&#34;256&#34;&#xA;         class=&#34;alignnone size-full&#34;&#xA;         decoding=&#34;async&#34; fetchpriority=&#34;high&#34;&#xA;         loading=&#34;lazy&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;Bon plutôt que d’utiliser un ATtiny, j’ai pris un ATmega8 histoire d’avoir un peu de place pour y ajouter du code plus tard 😉 (l’ATtiny2313 est déjà super plein pour l’USBtinyISP).&lt;/p&gt;&#xA;&lt;p&gt;Et voila le schéma (en image, les sources gschem sont sous git dans le répertoire &lt;code&gt;sch&lt;/code&gt;):&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_schema.png&#34;&gt;&lt;img src=&#34;https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_schema-thumb.png&#34;&#xA;         srcset=&#34;https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_schema-thumb.png 400w, https://silicone.homelinux.org/2011/03/08/premiers-pas-en-developpement-noyau/usb_gadget_schema-thumb-300x214.png 300w&#34;&#xA;         sizes=&#34;auto, (max-width: 400px) 100vw, 400px&#34;&#xA;         alt=&#34;Le schéma&#34; title=&#34;USB Gadget&amp;#39;s schema&#34; width=&#34;400&#34; height=&#34;286&#34;&#xA;         class=&#34;alignnone size-full&#34;&#xA;         decoding=&#34;async&#34;&#xA;         loading=&#34;lazy&#34;&gt;&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;Une fois le montage prêt, quelques lignes de code basées sur l’exemple de tinyusb et hop un firmware pour l’ATmega (à la racine du projet).&lt;/p&gt;&#xA;&lt;p&gt;Qu’il a fallut tester, hop la première méthode évoquée plus haut, quelques lignes de code avec &lt;a href=&#34;http://www.libusb.org/&#34;&gt;libusb&lt;/a&gt;, disponible dans le répertoire &lt;code&gt;test&lt;/code&gt;, m’ont permis de parfaire le firmware 😉&lt;/p&gt;&#xA;&lt;p&gt;Voila, tout marche, on va pouvoir entrer dans le vif du sujet.&lt;/p&gt;&#xA;&lt;h3 id=&#34;le-gestionnaire-de-périphérique-linux&#34;&gt;Le gestionnaire de périphérique Linux&lt;/h3&gt;&#xA;&lt;p&gt;En fait j’ai tout simplement suivi et adapté les tutoriels suivants:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a href=&#34;http://linuxdevcenter.com/pub/a/linux/2007/07/05/devhelloworld-a-simple-introduction-to-device-drivers-under-linux.html&#34; hreflang=&#34;en&#34;&gt;/dev/hello_world: A Simple Introduction to Device Drivers under Linux&lt;/a&gt; par Valerie Henson&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;http://www.linuxjournal.com/article/7353&#34; hreflang=&#34;en&#34;&gt;Writing a Simple USB Driver&lt;/a&gt; de Greg Kroah-Hartman&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;En regardant la version de &lt;code&gt;usbled.c&lt;/code&gt; présente dans les sources de Linux afin de mettre à jour les derniers détails.&lt;/p&gt;&#xA;&lt;p&gt;Cela donne un driver qui ajoute les pseudo-fichiers &lt;code&gt;leds&lt;/code&gt; et &lt;code&gt;keys&lt;/code&gt; dans le répertoire du périphérique déjà créé dans &lt;code&gt;/sys/bus/usb/&lt;/code&gt; par le noyau Linux.&lt;/p&gt;&#xA;&lt;p&gt;Voila ! Vous je sais pas mais moi j’ai appris plein de choses ! 😉&lt;/p&gt;&#xA;&lt;p&gt;Tout le code est disponible sous GPL2 et GPL2+ sur mon gitweb: &lt;a href=&#34;http://silicone.homelinux.org/git/jvdg_usbgadget.git/&#34;&gt;jvdg_usbgadget.git&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;Pour le nom un peu égocentrique, c’était surtout pour éviter tout risque de conflit, comme de toutes façons ceci n’a pas vocation à être intégré dans Linux (le périphérique utilise un ID USB réservé aux prototypes, donc inutilisable en grande série…)&lt;/p&gt;</description>
			</item>
			<item>
				<title>Time to put back software on the front page</title>
				<link>https://silicone.homelinux.org/2010/10/27/time-to-put-back-software-on-the-front-page/</link>
				<pubDate>Wed, 27 Oct 2010 00:03:35 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2010/10/27/time-to-put-back-software-on-the-front-page/</guid>
				<description>&lt;p&gt;I’ve been more on software recently, and I didn’t blog much…&lt;/p&gt;&#xA;&lt;p&gt;I’m still maintaining &lt;a href=&#34;http://packages.qa.debian.org/x/xserver-xorg-video-openchrome.html&#34;&gt;openchrome Xorg driver&lt;/a&gt;, not much to do now that the latest upstream SVN version is on &lt;a href=&#34;http://autobuild.ikibiki.org/&#34;&gt;KiBi’s X autobuild system&lt;/a&gt;. Except waiting for the bugs to occur.&lt;/p&gt;&#xA;&lt;p&gt;I also just requested to become DM to release the X Strike Force of the task of sponsoring me…&lt;/p&gt;&#xA;&lt;p&gt;After a rather awkward first message (still sorry about that), I started working on &lt;a href=&#34;http://packages.qa.debian.org/w/webalizer.html&#34;&gt;webalizer’s debian package&lt;/a&gt;.&lt;br&gt;&#xA;Nothing’s published yet, but this will come.&lt;/p&gt;&#xA;&lt;p&gt;Finally I received an email from Axel Beckert about xrootconsole, well &lt;a href=&#34;http://noone.org/blog/English/Computer/X/New%20upstream%20versions%20of%20xrootconsole%20and%20keynav%20in%20Debian%20Experimental.html&#34;&gt;he already blogged about it&lt;/a&gt;, I accepted to co-maintain xrootconsole with him. More details on &lt;a href=&#34;https://silicone.homelinux.org/projects/xrootconsole/&#34;&gt;my xrootconsole page&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;To conclude, after some month following the debian community, I’m starting to feel part of it!&lt;/p&gt;</description>
			</item>
			<item>
				<title>netsed 1.00a released !</title>
				<link>https://silicone.homelinux.org/2010/07/16/netsed-1-00a-released/</link>
				<pubDate>Fri, 16 Jul 2010 14:07:19 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2010/07/16/netsed-1-00a-released/</guid>
				<description>&lt;p&gt;After some work here it is : &lt;a href=&#34;http://silicone.homelinux.org/release/netsed/netsed-1.00a.tar.gz&#34;&gt;netsed 1.00a&lt;/a&gt; !!&lt;/p&gt;&#xA;&lt;p&gt;Basically this version is an architecture rewrite to add UDP support and remove the use of &lt;code&gt;fork()&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;I’m pretty happy with the current feature set and code state so I think it will stay like that for a moment.&lt;/p&gt;&#xA;&lt;p&gt;However feel free to test it and report bugs.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;http://silicone.homelinux.org/release/netsed/&#34;&gt;netsed release page&lt;/a&gt;.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Trial and errors with git branches</title>
				<link>https://silicone.homelinux.org/2010/07/16/trial-and-errors-with-git-branches/</link>
				<pubDate>Fri, 16 Jul 2010 13:57:49 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2010/07/16/trial-and-errors-with-git-branches/</guid>
				<description>&lt;p&gt;I’ve recently learned to use git (for my xorg adapted packages) and used it later for netsed.&lt;/p&gt;&#xA;&lt;p&gt;In order to develop UDP in netsed, I had to try several stuff, my network programming experience in C is back to some school time, so this was really trial and errors. And here git really helps, all I had to do is create branches for each trial, so I don’t loose any tracks I’ve taken, then when I found the right way to do it, I could just merge or cherry pick from the branches (or even just copy past from gitk to my favorite editor gvim) and that was it !&lt;/p&gt;&#xA;&lt;p&gt;Of course I can now delete the trial branches, but those were really helpful during development time.&lt;/p&gt;&#xA;&lt;p&gt;This meant abusing of &lt;code&gt;git commit --amend&lt;/code&gt;, &lt;code&gt;git merge&lt;/code&gt; ( &lt;code&gt;--squash&lt;/code&gt; ) and &lt;code&gt;git cherry-pick&lt;/code&gt; commands, but well you cannot build a clean code without effort.&lt;/p&gt;&#xA;&lt;p&gt;I should probably give another look at &lt;code&gt;git stash&lt;/code&gt; which seams to fill similar needs.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Taking over Netsed</title>
				<link>https://silicone.homelinux.org/2010/06/21/taking-over-netsed/</link>
				<pubDate>Mon, 21 Jun 2010 15:57:15 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2010/06/21/taking-over-netsed/</guid>
				<description>&lt;p&gt;Netsed, the network packet stream editor, is a program originally written by Michal Zalewski .&lt;/p&gt;&#xA;&lt;p&gt;While the program idea is good, it’s implementation had some lack, and nobody seamed to care enough to fix it.&lt;/p&gt;&#xA;&lt;p&gt;I did already hack it some years ago, and it appeared that my changes was fixing a debian RC bug (&lt;a href=&#34;http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586037&#34;&gt;#586037&lt;/a&gt;) so I took netsed maintenance as one of my new projects!&lt;/p&gt;&#xA;&lt;p&gt;For now only my changes and patches proposed by Mats Erik Andersson are integrated.&lt;/p&gt;&#xA;&lt;p&gt;But I will start working on a test suite (still have to find the right tools for that, would ruby be nice ?), and of course implement UDP support.&lt;/p&gt;&#xA;&lt;p&gt;Also I’d like to really thank Mats Erik Andersson and Tim Retout for their answers and support.&lt;/p&gt;&#xA;&lt;p&gt;Resources:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a href=&#34;http://silicone.homelinux.org/git/netsed.git/&#34;&gt;git storage for netsed&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;http://silicone.homelinux.org/release/netsed/&#34;&gt;release page&lt;/a&gt;&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
			</item>
			<item>
				<title>Mises à jour de WordPress et des plugins</title>
				<link>https://silicone.homelinux.org/2010/02/03/mises-a-jour-de-wordpress-et-des-plugins/</link>
				<pubDate>Wed, 03 Feb 2010 23:23:43 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2010/02/03/mises-a-jour-de-wordpress-et-des-plugins/</guid>
				<description>&lt;p&gt;À la suite des déboires d’hier, je viens de mettre à jours tous mes plugins.&lt;/p&gt;&#xA;&lt;p&gt;Le changement des URI par le plugin Gengo, qui ajoutait les code des langues m’embarquait dans une redirection infinie (en ajoutant des fr+en/ à l’URI) j’ai du le désactiver. Mais ce faisant, j’ai cassé les URI existante de vos marque-pages (si vous en aviez) et surtout de Google…&lt;br&gt;&#xA;Donc &lt;a href=&#34;http://silicone.homelinux.org/trac/changeset/28&#34;&gt;j’ai encore modifié gengo&lt;/a&gt;, maintenant les URI qui se terminent par un code de langue sont redirigé vers l’URI sans.&lt;br&gt;&#xA;Une lecture récente: &lt;a href=&#34;http://www.w3.org/Provider/Style/URI&#34;&gt;Cool URIs don’t change&lt;/a&gt; exprime ce besoin de conserver les URI, ici je redirige, c’est mieux que rien et vous évite le 404 😉&lt;/p&gt;&#xA;&lt;p&gt;J’ai trouvé ce lien sur &lt;a href=&#34;http://petereisentraut.blogspot.com/&#34;&gt;le Blog de Peter Eisentraut&lt;/a&gt;. Je lisait sont article a propos de &lt;a href=&#34;http://petereisentraut.blogspot.com/2010/01/remove-and-purge.html&#34;&gt;Remove et Purge&lt;/a&gt;. Je fut séduit par l’idée, je l’ai même appliqué quelques jours. Puis j’ai lut les commentaires, j’en reste à la méthode &lt;code&gt;l~c&lt;/code&gt; pour crée une vue dans aptitude 😉 . Par le passé, j’utilisais synaptic pour purger les résidus restant…&lt;/p&gt;</description>
			</item>
			<item>
				<title>Hacking zenphoto for https admin</title>
				<link>https://silicone.homelinux.org/2009/11/10/hacking-zenphoto-for-https-admin/</link>
				<pubDate>Tue, 10 Nov 2009 02:56:04 +0100</pubDate>
				<guid>https://silicone.homelinux.org/2009/11/10/hacking-zenphoto-for-https-admin/</guid>
				<description>&lt;p&gt;Trying to use zenphoto I found it does not have an option to have the admin tasks in https and the gallery in regular http.&lt;/p&gt;&#xA;&lt;p&gt;WordPress is doing this and reading Rian’s article: &lt;a href=&#34;http://ryan.boren.me/2008/07/14/ssl-and-cookies-in-wordpress-26/&#34;&gt;SSL and Cookies in WordPress 2.6&lt;/a&gt; I had a better idea on how it works.&lt;/p&gt;&#xA;&lt;p&gt;Before coding, I also read &lt;a href=&#34;http://fscked.org/blog/how-properly-provide-mixed-http-and-https-support&#34;&gt;How to Properly Provide Mixed HTTP and HTTPS Support&lt;/a&gt; from mikeperry’s blog.&lt;/p&gt;&#xA;&lt;p&gt;And this is basically what I implemented.&lt;/p&gt;&#xA;&lt;p&gt;For once the result of my work is not hosted on my blog but directly on zenphoto’s trac : &lt;a href=&#34;http://www.zenphoto.org/trac/ticket/1302&#34;&gt;The ticket with zenphoto patch to allow both http and https&lt;/a&gt;.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
