Informatique
Monday, 24 January 2011
|
Écrit par
Grégory Soutadé

En ayant marre de construire manuellement les tarballs binaires de KissCount, j'ai décidé de confier cette tâche à mon petit serveur (c'est le premier pas vers le packaging). Petit problème : le SheevaPlug tourne sur un processeur ARM, processeur encore peu répandu sur le "desktop" (ordinateur personnel/de bureau). En effet la majorité totalité de ces ordinateurs ont un processeur x86 (Intel/AMD). Mais pas de panique, il suffit de créer une chaîne de compilation croisée (cross toolchain) pour produire nos binaires x86 à partir d'une plateforme ARM !

Trêve bavardage, on récupère la dernière version de crosstool-ng (j'aurais pu en choisir un autre, mais celui là a l'air bien et surtout je n'avais pas envie de la construire "à la main"). Je me bats un peu en essayant d'utiliser la eglibc (Embedded Glibc, notamment utilisée par le projet Debian) ... échec. Par dépit je prends une configuration d'exemple légèrement modifiée. Une petite chose qui manque : la possibilité, par défaut, de faire un restart (obligé d'activer l'option dans debug).

Ce petit exercice va donc permettre de faire une comparaison entre les deux architectures. Bien sûr la comparaison est un peu biaisée car ce ne sont pas des gammes équivalentes, mais essayons quand même. La compilation est un exercice qui met en jeu beaucoup de composants systèmes :

  • Lecture/Écriture de fichiers (système de fichier, noyau via les caches, disque, DMA)
  • Mémoire/Calculs (processeur, bus interne, cache processeur, compilateur)


Les chiffres bruts :
Temps de compilation sur le SheevaPlug : 8h
Temps de compilation sur le DELL : 1h

 

 

Vu comme cela on se dirait : ARM, c'est naze. Mais regardons de plus près :

DELL OptiPlex 360

  • Intel(R) Core(TM)2 Duo E7500 @ 2.93GHz 3Mo de cache, FSB 1066Mhz : un seul des deux cœurs a été utilisé
  • 4 Go de mémoire vive bicanale type DDR2 SDRAM non ECC (800 MHz)
  • Disque dur 320 Go en SATA II avec un système de fichier Ext4, le tout à 7500rpm
  • Ubuntu 10.4 64 bits
  • Noyau Linux 2.6.32

SheevaPlug

  • ARM (9, v5 te) Marvell Kirkwood (Feroceon 88FR131 rev 1 (v5l)) 1Ghz, 16KB de cache L1, 256KB de cache L2 @500Mhz
  • 512 Mo DDR2 SDRAM 16 bits
  • Clé USB Toshiba 16Go en Ext2
  • Debian stable (4 / Lenny) 32 bits
  • Noyau Linux 2.6.32

 

Il y a un facteur 8 entre les deux systèmes qui peut s'expliquer par : le cache de l'ARM est ridicule (ça coûte cher), la fréquence du bus est deux fois moins importante, la taille du bus est divisée par 4, le système de fichier de la clé USB est relativement lent en écriture (4.7 Go nécessaires pour la compilation et 141 Mo la toolchain finale). En partant de là je trouve que les performances sont tout à fait correctes, surtout que même avec 8h de compilation on est gagnant niveau consommation électrique ! J'espère réellement que cette architecture va débarquer sur PC une fois qu'elle sera un peu plus musclé ! C'est ce qu'on verra avec les nouveaux Cortex A5/A8/A9 qui font déjà des merveilles sur smartphone (même s'il y a beaucoup d'accélérateurs autour). Et puis Microsoft a décidé de faire une version ARM de Windows, ce n'est pas pour rien ;)

 

Configuration toolchain 32 bits
Configuration toolchain 64 bits

Tuesday, 21 December 2010
|
Écrit par
Grégory Soutadé



Un peu de pub pour un petit outil dont on ne peut plus se passer une fois qu'on y a goûté. Quand on est développeur et qu'on utilise régulièrement la ligne de commande (projets, compilation, gestion de version ...) on se retrouve souvent dans les même dossiers (projetX, build, etc ...) et il n'est pas rare que ces chemins soient lointains les uns des autres. Joel Schaerer a donc humblement développé autojump. "humblement" car c'est un petit outil, mais qui remplit pleinement sa fonction (et en plus l'auteur est Français).

La version vanilla d'autojump mémorise sa position dans le système de fichiers à chaque commande, permettant ainsi de faire des statistiques sur les endroits où l'on se trouve le plus souvent, mais surtout de pouvoir sauter d'un endroit à un autre grâce à la commande "j" qui analyse son paramètre et essais de le faire correspondre à un chemin connu (les plus utilisés seront les premiers). Autojump supporte bien évidement l'auto-complétion par tabulation !

Exemple : Si le chemin "/home/soutade/Projets_Perso/KissCount" est enregistré dans autojump, il suffit d'entrer "j kiss" pour sauter directement à cet endroit, ce qui est un gain de temps considérable.

Autojump supporte plusieurs paramètres : "j greg kiss" saute sur "/home/greg/Projets_Perso/KissCount"

En cas de conflit on peut utiliser tab et choisir le chemin le plus approprié :

cd v2__[tab]
v2__1__/home/soutade/Projets/v2-helium-greg
v2__2__/home/soutade/Projets/v2-helium

La commande "jumpstat" permet d'avoir un aperçu de la base

...
54.5:  /home/shared/musique
60.0:  /home/joel/workspace/coolstuff/glandu
83.0:  /home/joel/workspace/abs_user/autojump
96.9:  /home/joel/workspace/autojump
141.8: /home/joel/workspace/vv
161.7: /home/joel
Total key weight: 1077


D'autres alternatives existent comme apparix, wcd ou kcd mais je les trouve moins élégantes (nécessite de scanner le système de fichier, utilisation moins transparente ...).

Le code d'autojump est disponible ici : https://github.com/joelthelion/autojump/wiki

Une démonstration (en) est disponible sur youtube : http://www.youtube.com/watch?v=tnNyoMGnbKg

Une fois installé, c'est adopté. Néanmoins en réfléchissant deux secondes je trouvais dommage qu'autojump soit appelé à chaque commande. En effet quand je suis dans un répertoire et que je fait cd .. je n'ai pas forcément envie que ce soit répertorié. J'ai donc retroussé mes manches et modifié le comportement du logiciel (https://github.com/soutade/autojump/tree/v2).

Sur ma version "cd" devient un alias d'autojump. Elle permet donc à la fois de sauter à un endroit et d'enregistrer un chemin dans la base de façon transparente. Si un dossier n'est pas trouvé dans la base ou qu'il est dans le répertoire courant, c'est la complétion normale de bash qui s'applique.

Il y a donc deux modes : manuel (il faut faire cd -a "chemin" pour enregistrer un chemin) ou automatique (chemin enregistré à chaque commande cd). Tout ceci est paramétrable dans le autojump.bash.

Par effet de bord on peut indifféremment manipuler la base avec la commande autojump ou cd.

En plus de cette modification j'ai aussi rajouté la commande "autojump/cd --remove key" qui permet de supprimer une entrée dans la base (la complétion pour key est effective), ainsi que la commande "cd/autojump --purge num" qui permet de supprimer toutes les entrées dont le nombre est inférieur ou égal à num.

En résumé, quelle que soit la version utilisée, il faut absolument essayer cet outil !

La version 2 d'Autojump est disponible

Monday, 06 December 2010
|
Écrit par
Grégory Soutadé

L'auto hébergement, qu'est ce que c'est ? Et bien tout d'abord, ce n'est pas l'hébergement de voitures ! C'est tout simplement le fait d'héberger des données chez soi et de les rendre accessible depuis l'Internet. En fait c'est le but premier d'Internet : interconnecter des machines sur un réseau mondial. L'auto hébergement, donc l'Internet, est pourtant quelque chose qui se perd. En effet les internautes choisissent la plupart du temps de confier leurs données à des sites tiers (mails, photos, blogs ...). Pourquoi donc ? Les principales raisons sont techniques : jusqu'à présent un internaute avec une connexion moyenne n'avait ni la bande passante nécessaire ni les connaissances techniques pour la création d'un "serveur", du coup il est plus simple de confier ses données à un tiers qui possède les compétences et le matériel permettant un hébergement efficace.


Oui, mais ! Les choses ont évoluées depuis l'ère du 56k limité à 50h. D'une part la bande passante des utilisateurs a énormément augmentée, de nos jours même une connexion de mauvaise qualité est suffisante. D'autre part les connaissances techniques nécessaires pour la création d'un "serveur" sont bien moins importantes. Il existe des solutions prêtes à fonctionner en dehors de la boîte (Apache, Joomla! ...). Dans l'esprit commun un "serveur" reste une grosse machine très puissante, alors qu'en réalité un serveur est juste un ordinateur qui va répondre à des requêtes. Les requêtes les plus connues sont les requêtes HTTP (http://...), mais il y a aussi le mail, l'accès distant comme SSH, des serveurs de jeu ... Il suffit donc d'un simple PC connecté au réseau pour pouvoir répondre aux requêtes de l'Internet.


Vous me direz : quel est l'intérêt de posséder ses données chez soi plutôt que dans un gros serveur ? Et bien l'intérêt principal est de conserver une partie de sa vie privée. Les photos, vidéos, écrits sont et restent la propriété de la personne qui les héberge (et dont il est l'auteur). Elles sont disponibles et peuvent être modifiées à n'importe quel moment par l'administrateur du serveur. Si je choisis de confier ces données à un tiers, il peut potentiellement en faire ce qu'il veut. Bien sûr il ne faut pas être trop paranoïaque, la plupart des fournisseurs de support respectent un minimum de confidentialité quant à ces données. Et c'est tout dans leurs intérêts car cela génère de la publicité (ciblée ou non) donc des revenus. Un service qui ne le respecterait pas suffisamment se verrait déserté rapidement.

Néanmoins il ne faut pas se leurrer, réaliser un serveur n'est pas trivial du moment qu'on dépasse le simple serveur web. Mais il y a plein de personnes qui ont eu cette problématique et tout le monde (informaticien ou non) possède un ami qui s'appelle Google qui lui connait toutes les personnes qui ont eu des problèmes et qui ont des solutions à apporter. Il suffit d'être un tout petit peu curieux. Les utilisateurs de GNU/Linux seront naturellement avantagés car l'installation et la configuration d'un serveur Apache sur ce dernier système est vraiment aisée. Reste l'aspect consommation : avoir un PC qui tourne 24h/24h, 7j/7j ça coûte. Personnellement j'ai adopté la solution d'un SheevaPlug qui est un "mini PC" à très faible consommation (5W), ce qui représente une consommation d'environ 5€/an (allumé 24h/24 7j/7). Il suffit donc de le brancher à la *box,(FreeBox, LiveBox, NeufBox, AliceBox ...), de le configurer une première fois, puis on l'oublie, on se contente juste d'ajouter des données (photos, vidéos ...) le moment voulu par l'interface web (et aussi de faire les mises à jours logicielles).

Seuls deux points peuvent être bloquant :

  • La sauvegarde des données n'est de base pas assurée. On peut utiliser le réseau, le port eSata ou USB, mais il faut mettre en place une solution de sauvegarde (manuelle ou automatique).
  • Si le serveur ou la connexion internet tombe, les services hébergés ne sont plus accessibles (ce qui peut être gênant pour le mail, mais reste acceptable pour un serveur web).


Parmi les outils permettant de monter un serveur on trouve :

  • Serveur web : Apache2 ou IIS
  • Gestionnaire de contenus (CMS, le site web pour résumer) : Wordpress, Joomla!
  • Serveur FTP
  • Serveur mail : Postfix, Dovecot
  • Serveur SSH (accès distant)
  • Serveur de base de données : MySQL, PostgreSQL
  • Serveur de gestion de version : Subversion, Mercurial, Git
  • Forges logicielle : Trac, inDefero, Redmine ...
  • Serveur de chat : IRC, Jabber
  • Serveur de jeu : Quake, Counter-Strike, Unreal, Wow


Le composant fondamental est le serveur web. A partir de là on peut héberger les services web classiques : photos, vidéos, blog ... Le reste étant réservé à une utilisation avancée.

Pour ceux qui auraient un peu de temps, il y a une conférence de Benjamin Bayart aux RM2L de 2007 qui est la conférence référence : Internet ou Minitel 2.0.
Ici un wiki en français sur la marche à suivre pour l'installation et la configuration du serveur : http://wiki.auto-hebergement.fr/

Thursday, 11 November 2010
|
Écrit par
Grégory Soutadé

La version 0.2 est sortie !

Après 6 mois d'intense développement, voici la version 0.1 de KissCount. Tout a commencé par une simple feuille de calcul pour noter les dépenses d'un budget modeste (donc qui nécessite de l'attention), puis sont apparues les couleurs pour différencier les opérations, les lignes de démarcation entre les semaines, les graphiques ... Au fur et à mesure, des fonctionnalités de plus en plus complexes se sont ajoutées. Ne voulant pas me lancer dans de la programmation sous OOo, le projet KissCount est né !

L'objectif est simple : arriver à retrouver la simplicité d'une feuille calcul tout en automatisant le plus possible les manipulations et les calculs. Il faut pouvoir visualiser en un seul écran : les opérations courantes, l'état des comptes et la répartition des dépenses (statistiques). L'objectif initial était même de faire tenir toutes ces informations dans un écran d'une résolution de 1024x768.

Bien sûr il existe des dizaines d'autres logiciels de comptabilité personnelle : libres, gratuits ou payants. Mais après une recherche rapide je me suis rendu compte qu'ils avaient tous les mêmes fonctionnalités et la même ergonomie, ce qui ne répond absolument pas à MON besoin : ouvrir le logiciel, rentrer les opérations, voir l'état des comptes, fermer le logiciel. En effet la plupart des autres logiciels de comptabilité partent sur une base financière et essaient de modéliser le maximum de détails, hors pour une utilisation "normale" on n'a besoin que de 20% des fonctionnalités proposées. De plus ils se transforment souvent en cliquodromes insupportables pour réaliser de simples opérations.

Par exemple : les champs "date de valeur", "date d'opération", "numéro de chèque", "destinataire", "devise", "type de l'opération" (chèque, espèces, carte bleue) sont inutiles. Ils prennent de la place à l'écran et ralentissent la saisie.
Dans KissCount on considère que :

  • la "date de valeur" est équivalente à la "date de l'opération" : Si un chèque n'est encaissé que 6 mois plus tard on le considère pendant 6 mois comme déjà encaissé (ça évite de le dépenser) mais on a la possibilité de ne pas le prendre en compte lors du rapprochement mensuel
  • "Numéro de chèque" et "destinataire" : Ils peuvent être inclus dans la description de l'opération, le montant du chèque suffit souvent à l'identifier
  • "Devise" : Le logiciel considère que tout est dans la même devise, le change entre devises est exceptionnel dans la vie courante donc il n'est pas nécessaire de rajouter des mentions inutiles pour le supporter. Si l'utilisateur a à manipuler régulièrement différentes devises il peut se tourner vers d'autres logiciels
  • "Type de l'opération" : inutile car à part les espèces dont le montant est faible (il y a peu de personnes qui se promènent avec 1000€ en liquide sur eux) toutes les autres opérations se font à partir de ou vers un compte bancaire. Il suffit alors d'indiquer une opération de retrait (libre à la personne de gérer ce retrait comme elle l'entend).


Ce sont des exemples de la philosophie du logiciel qui se veut KISS avant tout.

KissCount v0.1

Petite mise au point pour ceux qui ne feraient que regarder les images : il y a deux types d'opérations dans KissCount, les opérations en jaune sont les opérations récurrentes (salaire, loyer ...) qui sont automatiquement reportées d'un mois sur l'autre et les opérations en vert sont les opérations du mois en cours (les couleurs et la police de caractère sont paramétrables pour chaque catégorie).

Actuellement les fonctionnalités suivantes sont implémentées :

  • Gestion des opérations, catégories, comptes bancaires
  • Grouper/Dégrouper des opérations
  • Lorsqu'une description est réutilisée pour une nouvelle opération, le logiciel remplit automatiquement la catégorie et le compte bancaire
  • Statistiques de répartition des dépenses (pratique pour analyser son budget)
  • Mode rapprochement (uniquement les opérations sélectionnées sont prises en compte)
  • Possibilité d'insérer des formules à la place de valeurs numériques
  • Fonction de recherche (avec édition des résultats)
  • Gestion des comptes partagés
  • Affichage des opérations de manière croissante ou décroissante
  • Traduction Français/Anglais
  • Support multi utilisateurs
  • Mini site web pour visualiser ses données en ligne (nécessite un serveur web)


Le logiciel n'a donc pas la prétention de détrôner les concurrents déjà en places mais simplement d'apporter une nouvelle vision innovante en partant du besoin réel de l'utilisateur.
A partir de maintenant le développement sera ralenti car toutes les fonctionnalités importantes ont été implémentées, ça ne veux pas dire que le projet est abandonné : s'il manque une fonctionnalité ou qu'il y a (encore) des bugs il y aura de l'activité.

Pour l'aspect technique : il est développé en C++ sur un modèle MVC avec wxWidgets comme boîte à outils graphique et un peu de PHP pour la partie web. Les données sont stockées dans une base SQLite3.

Pour le moment le principal défaut est que l'interface graphique est mal gérée au niveau des layouts, quelques graphiques plus sympa et des traductions seraient les bienvenues !
Le projet est hébergé sur une forge inDefero : http://indefero.soutade.fr/p/kisscount/
Des captures d'écran sont disponibles dans la documentation française et anglaise

Wednesday, 27 October 2010
|
Écrit par
Grégory Soutadé

C'est rare mais les gars du projet Debian se sont planté. Peut être que j'ai loupé un truc, mais après avoir redémarrer suite à la mise à jour de mon SheevaPlug vers le noyau 2.6.32-5-kirkwood, le système sortait en kernel panic lors de l'initialisation du réseau. Pas pratique ...

Une petite recherche sur le web m'indique le liens suivant : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597302#35
Le problème vient du fait que la commande flash-kernel n'est pas appellée après la mise à jour du noyau. La marche à suivre est de rajouter l'option ipv6.disable=1 à la ligne de commande (setenv bootargs ipv6.disable=1) lors du boot. Evidement chez moi ça ne fonctionne pas.

Bref un système inutilisable (puisqu'il plante avant le boot). Ma configuration est la suivante :
- Ubuntu d'origine dans la mémoire flash intégrée
- Debian installée sur la clé USB avec les partitions suivantes :
/dev/sda1    /boot
/dev/sda2    /
/dev/sda3    swap
/dev/sda4    /home

Heureusement on a accès à la clé USB depuis l'Ubuntu d'origine, cela va permettre de remettre en marche tout ça. Il faut d'abord démarrer sous Ubuntu (sortir le cable USB pour accéder à l'interface RS232 via putty ou screen), monter la clé, se chrooter (c'est donc "comme" si on avait booté sur la clé). Hélàs /dev/sdaX n'est pas automatiquement détecté par udev (les événements ne lui sont pas envoyé pour qu'il crée les périphériques), on va donc le faire à la main avec mknod. Puis on monte /boot et /proc avant de pouvoir lancer flash-kernel. On revient sous Ubuntu, un petit fsck sur les partitions modifiées et on peut enfin redémarrer normalement sur notre ancien système !

mount -t ext2 /dev/sda2 /media chroot /media mknod /dev/sda1 b 8 1            # 8 2 pour /dev/sda2, 8 3 pour /dev/sda3 ... mount -t ext2 /dev/sda1 /boot mount -t proc /proc /proc flash-kernel exit reboot

redémarrer sous Ubuntu

fsck /dev/sda1 fsck /dev/sda2 reboot

J'ai remarqué que lorsqu'on débranche brutalement l'alimentation, il ne boote plus sur la clé USB. L'astuce consiste à démarrer sur l'Ubuntu d'origine, monter la partition, faire un ls, démonter la partition, faire les fsck sur les partitions modifiées (sinon il va le faire au boot de la clé et comme le système a été modifié va redémarrer ...), puis redémarrer le Sheeva (via un reboot).

mount -t ext2 /dev/sda2 /media ls /media umount /media fsck /dev/sda2 reboot

L'idéal est de créer un script et de le rajouter dans le crontab d'Ubuntu pour qu'il s'exécute toutes les 10 minutes. Comme ça si le redémarrage intervient pendant la nuit ou quand on n'a pas accès au SheevaPlug il revient tout seul sur Debian. Les 10 minutes permettent de désactiver le crontab quand on a des choses à faire sous Ubuntu (comme un flash-kernel par exemple ...).