Vincent Danjean a écrit 143 commentaires

J'ai installé phpcompta (enfin noalyss) il y a moins d'une semaine dans une VM pour tenter de tenir la comptabilité d'une copropriété. Je vais profiter de cette news pour faire quelques retours (certains mériteront probablement des bugreport quand j'aurai un peu de temps).

Points forts

D'abord, quelques points forts qui m'ont fait choisir ce logiciel pour l'instant :

• libre (pas simplement gratuit comme d'autres logiciels pour copro/syndic)
• multi-utilisateurs et en réseau (appli web). Ça permet à d'autres personnes de consulter et/ou de participer.
• très bonne séparation entre les fichiers php publiques (dans html de mémoire) et ceux privés/de bibliothèques (dans include/ de mémoire)

Points que j'aimerais voir amélioré

Quelques limitations du logiciel/manque dans la doc/… :

sécurité

• droits d'écriture : par défaut, et dans la plupart des tutoriaux, www-data doit pouvoir écrire presque partout. Pourquoi ? Le fichier de config (dans include/) pourrait être à télécharger et déposer dans le répertoire par exemple. En tout cas, j'ai supprimé les droits d'écriture dans include/ pour www-data une fois l'installation finie et je n'ai pas eu d'erreurs. Idem pour html/ (sauf html/tmp/ que j'ai laissé en écriture)
• le login 'phpcompta' semble codé en dur : il marche mais on ne voit pas d'utilisateur de ce nom. Pour le "désactiver" après avoir créé mes propres utilisateurs, j'ai créé un utilisateur avec ce login et j'ai mis à jour le mot de passe. Ainsi, phpcompta/phpcompta ne marche plus.
• mon firewall bloquait au début les connexions sortantes ce qui introduisait des délais importants (genre une minute) à la connexion. Il faudra que je creuse ça, mais il y a donc des connexions sortantes émises par ce logiciel. Pour quoi faire ?

documentation

• la relation entre phpcompta et noalyss pourrait être plus visible sur le site (le temps que noalyss soit un peu mieux connu en tout cas)
• le login/pass initial (cf plus haut) n'est pas facilement visible dans la doc de base (README, …), ni la méthode 'officielle' pour le désactiver
• l'installation de plugin demande des manip vraiment non intuitives (il faut l'enregistrer en mettant des codes, .. puis le valider, puis l'installer dans les menus (au moins des autres utilisateurs))
• j'ai trouvé dans la doc un plan comptable pour les copro (apparemment principalement des commandes SQL), je n'ai pas encore trouvé comment le faire charger
• il me manque encore une vue globale du logiciel. Je me la construis petit à petit en testant mais ça signifie que la prise en main est longue.

Ceci dit, pour l'instant, ce logiciel me plaît et je vais tenter de l'exploiter correctement.

La tablette Samsung Galaxy Tab 3 10.1 (au moins) fonctionne avec un processeur x86 et elle est livrée avec un Android. Je ne sais pas qui a fait le portage (google pour la version interne ? Samsung ?) mais j'ai découvert que cyanogenmod n'était pas compilable pour tablet x86. Il y a quelques messages récents qui font penser que ça pourrait changer (aide d'Intel à des développeurs de cyanogenmod).

J'ai pu rooter la tablet : CWM existe pour x86. À ce propos, Odin (à travers une machine virtuelle kvm) a marché alors que heimdall n'a pas fonctionné (problème d'architecture dans le protocole ?) pour transférer CWM dans la partition de recovery. SuperUser puis SuperSU se sont alors installé sans problème.

Mouais, alors MPI et fortran sur 1000 noeuds, je demande à voir en condition réelle. Parce qu'avec 1000 noeuds, tu as besoin d'un programme vraiment très parallèle. Fortran ayant une gestion pour le moins limité de la dynamicité (allocation dynamique, ...), si tu veux un programme efficace, il faut que ces tâches parallèles soient très régulières. Il doit y avoir quelques applis qui respectent ce cahier des charges (algèbre linéaire pleine par exemple), mais ça ne coure pas les rues.

Si c'était ça que je cherchais, je l'aurai trouvé il y a longtemps.
Ce que je cherche à faire, c'est de faire calculer à CMake ce qu'il faudra dans le biblio.pc en fonction des bibliothèques trouvées sur le système (avec un .pc ou directement avec les flags -l.. -L.., -I...) et en fonction de la façon dont je l'utiliserai (CMake ne peut pas savoir si, en créant ma bibliothèque, il doit mettre les bibliothèques dans la partie private (ie nécessaire uniquement pour le link static) ou public (nécessaire dans tous les cas) donc, si, dans la solution proposée, je n'ai pas à fournir cette info, c'est que ce n'est pas ce que je cherche).

Pour les autotools, j'ai fait ça :
http://git.ligforge.imag.fr/?p=users/vdanjean/tools/autolibs(...)
Pour CMake, je ne vois pas comment faire si on veut garder les routines existantes de CMake pour la détection des bibliothèques (et si on les remplace, ça n'a aucun intérêt par rapport aux autotools)

Ayant dû choisir une système de compilation pour créer des bibliothèques C/C++, on a évalué CMake et les autotools. On est resté aux autotools finalement. Ça m'a sidéré qu'un truc récent comme CMake n'était pas capable de gérer correctement par défaut les compilations statiques/dynamiques (la liste de lib est la même dans les deux cas !). D'ailleurs, si quelqu'un sait comment faire générer à CMake un fichier bibliotheque.pc dont le contenu dépend de ce qu'a trouvé CMake, ça m'intéresse grandement.

Make/autotools est un outil complexe à prendre en main (si on s'écarte des cas de base) mais il est assez puissant pour faire à peu près tout ce qu'on veut. Après, c'est comme partout : on peut écrire du code propre ou pas (je parle du code Makefile et m4).

C'est ce que propose free et c'est pourquoi je ne l'utilise pas du tout. J'ai à la place un tunnel SixXS. Ben oui, chez moi, j'ai différents réseaux (wifi peu sécurisé mais filtré, réseau filaire, DMZ pour mon serveur web, ...) Si je veux utiliser ce que propose Free, j'ai le choix entre :
- ne faire qu'un seul réseau pour l'IPv6 (pas de firewall sauf un à l'entrée au mieux)
- ne pas pouvoir utiliser l'autoconfiguration d'IPv6 (l'autoconfiguration demande un /64 si je ne m'abuse)

Et comme il n'y a pas de NAT avec IPv6, je trouve que c'est vraiment abuser que de ne donner qu'un /64 au client final. L'important ici n'est pas le nombre de machines connectables sur ce réseau, mais le nombre de réseaux autoconfigurés que l'on peut mettre en place.

Pour la recherche, les chercheurs français ont la chance de pouvoir expérimenter pas mal de chose avec la plate-forme Grid5000. Pour ma part, on a fait tourner dans notre équipe des codes de calcul parallèle sur l'intégralité de la plate-forme Grid5000 couplée à une plate-forme similaire (mais moins grande) japonaise. De mémoire, il y avait au total un peu moins de 4000 coeurs disponibles. On avait obtenu une efficacité très bonne.
Bien sûr, quand on veut obtenir des efficacités correctes avec un si grand nombre de coeurs, il est nécessaire d'utiliser des paradigmes de programmation adaptés (pas de serveur central, pas de maître/esclave, privilégier les communications locales, ...) Dans notre équipe, on utilise des techniques basées sur le vol de travail. Ça permet d'écrire des programmes qui passent très bien à l'échelle même avec un très grand nombre de coeurs. (Attention : je n'ai pas dit que tous les problèmes pouvaient s'écrire et tourner efficacement avec ce genre de programmation)

Je ne sais pas pourquoi ce commentaire a été moinsé. J'allais ajouter le lien vers le blog de Maître Éolas avant de voir qu'il était dans ce commentaire. Je vous conseille de le suivre : il décortique le décret. C'est savoureux.

Je n'ai pas trop compris ces histoires de « variables conditionnelles avec des mutex PI », mais je pense qu'au final ça va améliorer la réactivité des processus utilisant beaucoup de processus légers

Ça dépend, je pense que la plupart des gens n'utilisent pas les options de priorité des mutex POSIX


Les histoires de « variables conditionnelles avec des mutex PI » ne vont pas améliorer les programmes avec beaucoup de threads mais ils vont améliorer les programmes qui utilisent à la fois des threads et des priorités. L'exemple le plus classique est jack (le système de son). Mais je pense que, maintenant que ces fonctionnalités (PI) sont dispo et vraiment utilisables (ce n'a pas été le cas jusqu'à très récemment), on risque de voir plus de programmes les utiliser et en profiter. Les programmes cibles sont ceux qui ont des tâches prioritaires à faire (maintenir une cadence d'affichage, de transfert, ...) ainsi que d'autres tâches moins prioritaires (gérer une interface graphique, ...)

Mais je dois alors reconfigurer rsync pour qu'il utilise le tunnel (au lieu de lui mettre un nom), non ? Tu as un exemple ? Comment se passe l'allocation de port pour joindre la machine cible ? C'est toujours le même ou ça dépend de l'invocation de bélier ? Comment ça s'intègre dans un script ?
Quant au système de partition chiffré, j'en ai un pour les données que je veux protéger. Ce sont aussi des données auxquelles je n'accède pas régulièrement : j'ai eu assez de pb de filesystem pour ne pas vouloir crypter mon /home en entier (ben oui, j'aime bien tester des noyaux nouveaux donc pas toujours encore très stables) et je n'ai pas envie que ce système soit monté en permanence (en général j'utilise le suspend-to-disk)
Et encore une fois, je n'ai toujours pas compris l'intérêt de bélier par rapport à une config correcte de mon client ssh. Je dois passer à côté de quelque chose.

Exemple classique : ensemble de machines dans le domaine toto.fr accessibles en passant par le firewall access.toto.fr

.ssh/config :
========
Host toto
Hostname access.toto.fr
User mylogin

Host *.toto
ProxyCommand ssh toto "tcpconnect `basename %h .toto` %p"
User mylogin
========

Et ça permet des trucs du genre

rsync fichier interne.toto:/tmp

pour transférer vers la machine interne.toto.fr en passant par access.toto.fr. Que m'apporterait bélier ?

Je n'ai pas essayé bélier, j'ai juste regardé rapidement les exemples à cause de cette dépêche. Et bien, pour l'instant, je ne suis absolument pas convaincu.
Le reproche principal : les mots de passe en clair dans la config (ie inutilisable depuis un portable qui a des risques non négligeables d'être volé un jour ou l'autre)

J'ai aussi depuis longtemps des connections à faire à travers des machines intermédiaires. J'ai toujours réglé ça par une config correcte de mon .ssh/config. Les rebonds sont pris en charge directement par ssh, ce que fait que je peux alors utiliser tous les outils basés sur ssh (scp, rsync, ...) sans m'occuper du tout des machines intermédiaires (et avec des clés publiques/privées pour éviter les passwords même si ce n'est pas obligatoire). J'ai l'impression que, si on veut utiliser bélier avec rsync (par exemple), il faudrait modifier au minimum modifier la config de rsync. Bref, la dépêche ne me montre pas l'intérêt de bélier ici.

Vu tout ce que Koha utilise comme modules Perl, je ne pense pas que PHP soit aussi riche (ni ne le devienne dans un avenir proche) :-)

Sinon, a propos des dépendance de Koha 3.0 dans Debian, il y a tout dans lenny sauf quelques modules Perl (ajoutée trop tard dans Koha pour passer avant le freeze de lenny) et idzebra. Ces modules et idzebra sont dans unstable (et seront dans backports.org quand lenny sera sortie) [idzebra a été accepté par ftpmaster hier :-) ]

Le packaging de koha est assez bien avancé (visible dans un repo git du projet collab-maint d'alioth) mais il me manque quelques infos sur les divers scripts fournis ainsi que sur les fichiers de config. J'en discute tranquillement avec les gens de biblibre donc ça devrait se terminer assez rapidement (sauf que j'ai un peu moins de temps libre en ce moment)

Je n'ai pas encore eu le temps de me pencher dessus mais on m'a signalé qu'il y avait maintenant un mode parallèle expérimental pour la STL. Je ne sais pas non plus à quel point ça dépend de gcc 4.3 (ou pas) mais en tout cas, ça m'a l'air d'un truc intéressant à suivre.

http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

Dans les entreprises, institutions, ... le mail est rarement émis par le poste de travail directement mais plutôt par un serveur mail. De même, le mail reçu l'est par un serveur (évenruellement le même) qui sotcke les messages et donne un accès par IMAP(S) (voire POP(S)).
Dans ces conditions, avoir un antivirus au niveau de ces serveurs permet d'éviter d'envoyer et/ou recevoir trop de virus. Et ce, quelque soit l'OS des postes de travail.

Autre exemple : si on fournit une redirection de mail (une série d'alias sans stockage de mail), il est important de filtrer les mails transitant par le serveur du domaine relayé sinon ce serveur risque de se faire marquer comme spammeur par les serveur SMTP auxquels il relaie ses mails.

Bref, il y a tout plein de raisons d'avoir un antivirus (pour toutes les plateformes) fonctionnant sous linux.

Le langage naturel est plus compliqué que la logique booléenne (sinon, les correcteurs syntaxiques seraient déjà là...).
Bref, même en laissant le sens booléen à l'élément de langage 'et' (sens "les deux"), la phrase "vous pouvez A et B" peut très bien être interprétée par "(vous pouvez A) et (vous pouvez B)" et non pas comme "vous pouvez (A et B)" Cette élision du langage naturel (supprimer le deuxième "vous pouvez") est très courante et c'est, il me semble, le sens classique que l'on donne à "vous pouvez A et B". Et je pense que c'est le sens que retiendrait le juge.

Quand tu indiques de commenter les deux lignes dans /usr/bin/test-windows-key, il faut aussi commenter le 'if' ... 'fi' ou bien
mettre une autre commande (':' par exemple).
En effet, bash n'accepte pas un then (ou un else) vide :

vdanjean@cayuga:~$ if test -x t ; then fi
bash: syntax error near unexpected token `fi'
vdanjean@cayuga:~$ if test -x t ; then ; fi
bash: syntax error near unexpected token `;'

Dernière petite chose : je ne connais pas d'implémentation de MPI qui soit threadsafe ET performante. Si quelqu'un en connaît une, ça m'intéresse.

Marcel+Madeleine+mpich=http://runtime.futurs.inria.fr/mpi/

Tu as testé ? Si tu as rencontré des cas pathologiques, ils seront intéressés par les infos. Et passe le bonjour de ma part à Marc ;-)

Pour geoffroy, "threadsafe ET performante" ça veut dire ne pas faire du tout d'attente active, recouvrir correctement calcul et comm, faire progresser les comm MPI pendant que les autres threads calculs, ...
A priori, LAM et Open MPI étaient assez décevants quand les processus avaient quelques centaines de threads de calcul... Ça peut-être changé, ça fait un moment que je n'ai pas regardé.

J'ai l'impression qu'il peut maintenant tracer la surface 3D d'un champ de données qui ne serait pas positionné sur une grille en x, y

C'est avec quoi que tu fais ça ?

Par ailleurs, est-ce que gnuplot peut maintenant faire des barres 3D ? Je ne sais pas si 'barre' est le bon terme, mais ayant des coordonnées x et y quelconques (pas sur une grille), je cherche à tracer à ces coordonnées des parallélépipèdes de hauteur z (en gros des immeubles de hauteur choisie à des coordonnées choisies).
Je me demande si le mode 'vectors' va (enfin) me permettre de faire ça.

Pour utiliser des CPU (ou coeurs) différent, il faut que le flot d'exécution soit géré par le noyau. C'est le cas des programmes classiques (monothreadés) ainsi que, pour le programmes multithreadés, des threads dits de niveau noyau. La bibliothèque de threads de linux ne propose que des threads de niveau noyau. Donc linux est capable d'assigner aux différents processeurs (ou coeurs) indifféremment un processus classique (monothreadé) ou un thread d'un processus multithreadé.

on a tous plusieurs dixaines de programmes qui tournent sur une machine donc un proc multi-coeurs va - de toute façon - accélérer le tout.

Regarde bien l'occupation de ton processeur (il y a plein d'applets pour ça). Tu verras qu'il passe une très grande partie de son temps à ne rien faire. Tu as beau avoir plein de processus 'qui tournent', ces processus sont généralement en attente d'événements (clic, touche clavier, timer, ...) et ils n'ont alors pas besoin du processeur.
Et quand ton processeur est vraiment occupé, il n'y a généralement alors qu'un seul programme qui en a besoin à ce moment (par exemple gcc peut facilement occuper 100% du CPU). Et pour accélérer ce programme (et te faire l'impression que ta machine va plus vite), alors il faut que ce programme utilise des threads. Il y a rarement plusieurs programmes qui tournent (au sens utilisent vraiment le CPU) systématiquement en même temps.

L'exception la plus classique est le serveur X qui doit répondre en même temps que tes applications quand ces dernières ont des choses à faire. Dans ce cas, avoir deux CPU permet effectivement au noyau de répartir ces deux tâches (l'application et le serveur X). On aura alors l'impression d'une amélioration beaucoup plus grande entre le passage de 1 à 2 CPU que de 2 à 4.
Avoir des CPU supplémentaires peut aussi être utile si tu as des programmes en tâche de fond qui consomment vraiment du CPU (lecteur mp3/divx, encodage mp3/divx, indexation automatique des documents de ta machine, ...)

Moralité, on n'optimise pas un programme pour ce truc, on le conçoit aux petits oignons ... c'est pour ça que tu n'est pas près d'en avoir un chez toi !

Ça dépend de quoi tu parles. Si c'est du programme applicatif, celui qui fait les calculs (calculs d'écoulement de fluides autour d'une voiture ou d'un avion, calculs de propagation d'ondes, ...), alors généralement non. Le but de ces programmes (écrits par les grosses entreprises) est d'avoir un code qui tournera pendant 20 ans. Donc on ne l'optimise pas pour une architecture particulière. Mais on l'écrira de manière à ce qu'il puisse être parallélisé facilement/efficacement.

On l'écrira donc en utilisant des couches de portabilité sur des environnements plus ou moins standards et/ou libres comme MPI ou PM2 ( http://runtime.futurs.inria.fr/pm2/ ). Et ces environnement là seront effectivement optimisés pour l'architecture ciblée.

Et ne peut-on pas imaginer que le compilo puisse s'occuper seul de la parallèlisation?
La réponse est non si on veut que la parallélisation soit efficace.
Il y a eu beaucoup (BEAUCOUP) de travaux de recherche sur ce thème. Je ne connais pas une seule équipe qui soutient encore que la parallélisation peut être faite entièrement automatiquement.

Par contre, il est certain que le compilateur et/ou le runtime peuvent aider grandement le programmeur en lui fournissant des outils ou des analyses partielles. La plupart des travaux de recherche sur le parallélisme que je connais vont dans cette direction.

Un programmeur a trop l'habitude d'une exécution séquentielle et d'une mémoire partagée pour qu'un outil puisse extraire automatiquement une version parallèle efficace de son programme en respectant exactement la sémantique du code séquentiel. Dès que le programmeur commence à mettre des annotations (ie dans cette fonction, je ne touche pas à l'état globale, je me contente de lire sans écrire ces variables, ...), une parallélisation automatique devient beaucoup plus envisageable.

Le compilo restera très utile pour détecter le parallélisme au niveau instruction (et remplir correctement les différentes unités de calcul du processeur ciblé). Mais il ne sera pas capable de paralléliser efficacement sans aide un programme 'classique'.

Athapascan1 n'est qu'une interface (simplifiée) de Kaapi maintenant.
La référence officielle est désormais cette page :
http://kaapi.gforge.inria.fr/
[la page du site d'www-id sera bientôt une redirection là bas]
Une nouvelle release de kaapi devrait être faite d'ici quelques semaines.
L'idée de kaapi/athapascan est que le programmeur décrit les dépendances entre les fonctions/modules de son programme. Le runtime kaapi s'occupe ensuite tout seul de l'exécuter en parallèle sur la ou les machines à sa disposition. Évidemment, c'est destiner à paralléliser des programmes de calcul. Si on veut des affichages graphiques (ou tout autre E/S sur une machine particulière), ça marchera moins bien (kaapi ne pourra pas déporter ces parties du calcul). Et bien sûr, kaapi ne trouvera pas de parallélisme s'il n'y en a pas dans le programme (ie dans la description des dépendances entre tâches).

Je n'ai pas encore vu le numéro en question, mais je vais probablement l'acheter. Si 01 informatique voit ses ventes augmenter avec un tel numéro, ça les incitera peut-être à parler plus souvent du LL.

FreeDOS n'a pas besoin de Linux pour tourner. On peut très bien booter (par D7, USBKey, CDROM, ...) sur un freeDOS pour lancer une mise à jour de BIOS.

Si tu veux qu'on regarde ton paquet, c'est le .dsc, le .orig.tar.gz et le .diff.gz qu'il faut fournir... Le .deb a peu d'intérêt (pour le packageur, c'est différent pour l'utilisateur)