plietar a écrit 12 commentaires

Merci pour ce journal très intéressant.
Je suis moi-même en train de faire de la rétro-ingénierie du protocole d'un grand service de streaming audio Suédois.
Ce sont de longues séances de lecture d'assembleur, avec quelques maux de tête à la clé, mais la satisfaction quand mon implémentation se comporte comme la référence n'a pas de prix.
Je devrais faire un journal là dessus un jour.

Par contre je ne sais pas vraiment ce qu'il en est du coté légal.

Et est-ce mieux ? C'est plus rapide ? Dans le cas de mon script on s'en fout mais je demande par curiosité.

Certains shells ont une limite sur la longueur des commandes. xargs sépare en plusieurs invocations de façon à garder un nombre raisonnable d'arguments.
Je ne pense pas que bash ait ce problème, mais c'est plus propre. Par contre c'est plus lent car apt peux être invoqué plusieurs fois, et il prend du temps à charger.

Le pare-feu sous linux est fait de plusieurs composants, le framework Netfilter qui intercepte et manipule les paquets, ip_tables, le module, qui s'insère dans Netfilter et décrit les règles de filtrages, et iptables l'outil en userspace qui transmet les règles à ip_tables, le module.

Ca m'étonnerait que systemd est l'intention de toucher aux de premiers (quoi que on sait jamais où ils s'arrêtent, c'est uniquement l'outil iptables qui est remplacé, celui étant assez simpliste. D'ailleurs quand on utilise ufw ou autre, il se passe la même chose.

nftables a pour but de remplacer le module et l'outil. Le module nftables pourrait donc être utilisé par systemd, ils sont complémentaires, pas opposés.

Après on peut débattre de la pertinence d'un gestionnaire de pare-feu dans systemd (même si pour l'instant ça semble se limiter à du NAT)

Il n'y a pas de raison pour que paperwork recommande tesseract-oct-fra plutôt que tesseract-oct-jpn/ita/… La taille des paquets étant significative, je ne voudrait pas tous les mettre en recommandation.

Par contre c'est vrai que la doc devrait le mentionner, voire la fenêtre de sélection de langue pourrait expliquer comment en ajouter plus. Je note ça sur ma TODO-list.

Merci du retour.

A noter aussi que j'ai fini d'empaqueter Paperwork pour debian.
Les paquets sont disponible sur mon depot, je vais maintenant me pencher sur l'inclusion dans les depots officiels

echo "deb http://deb.lietar.net sid main" > /etc/apt/sources.list.d/paperwork.list
apt-get update
apt-get install paperwork

J'ai envoyé plus de details sur la mailing-list : https://groups.google.com/forum/#!topic/paperwork-gui/j0O5LEqZfVU

il y a des gens qui ont une expérience de dev d'application mobile multi-platforme Android/iOS/Windows avec Qt ?

Un petit peu. C'est fonctionnel, mais autant sur desktop le style est proche d'applications natives, autant sur mobile les widgets ont un style très différents des widgets natif.

Bonjour,
Je suis volontaire pour conquérir le monde avec toi maintenir Paperwork. Je suis un peu occupé jusque fin aout (vacances obligent) mais à partir de septembre j'aurai plus de temps.
J'ai pas mal d'éxperience en python, en revanche pour ce qui est de Debian je n'ai jamais été que utilisateur, mais je serai ravi d'apprendre.

Paul

Les protocoles sont développés dans weston, et une fois stables ils passent dans wayland.

C'est ce qui c'est passé pour le protocole subsurface. Ajouté ici dans wayland, retiré là dans weston.

Après certains protocoles sont vraiment spécifiques à weston et n'ont pas vocation à migrer vers wayland, mais je ne crois pas que ce soit le cas de xdg-shell. Il y a même déjà un protocole rudimentaire wl_shell que xdg-shell viendra remplacer.

Entre simple dépôts git, ou avec des services différents, l'interaction serait compliquée voir impossible au delà du simple "fork". Pas de Pull/Merge Request, pas de lien automatique vers les issues, … Autant faire un "git pull", "git remote add" et "git push" en console.

Pour gitlab par contre, ce serait intéressant. Il y a eu une demande, mais je ne trouve pas les merge requests mentionnées.

En lisant ce journal, je me rends compte que Gitlab s'autoheberge depuis peu, un must pour toute forge.
Sinon Gitlab ça a l'air sympa, mais mon raspberry pi n'a jamais réussi a tenir la charge.

Pour l’intégration avec docker, ils ne fournissent qu'un Dockerfile (fichier qui décrit comment construire une image). Gitlab est-il capable de lancer un nouveau conteneur à chaque build, où doit-on les lancer avant, au quel cas ils sont réutilisés, et donc on perd l’environnement propre.
Le mieux est à mon avis d'écrire un ficher Dockerfile pour le projet, et de créer une image à chaque build et de lancer les tests dedans. Pas besoin d’intégration particulière avec le système de CI.

Tu te retrouve avec du polling massif, et si l'utilisateur éteint son ordinateur, plus personne n'a accès aux messages.

Le système de templating HTML / CSS basé sur Smarty rend la personnalisation graphique très souple.

Smarty, c'est pas un moteur de template open source par hasard ?