Rémi Duraffort a écrit 84 commentaires

Merci pour ton retour.
Pour répondre à tes 2 questions :
* pour le nom de famille, je n'en ai effectivement pas forcément besoin (tant que le prénom est enregistré).
* le format de la date est effectivement invalide quand la langue est positionnée sur l'anglais. Je vais corriger cela. (https://github.com/ivoire/RandoAmisSecours/issues/44)

Je suis tout à fait d'accord : la seule chose qui compte c'est de toujours indiquer à une (voir deux) personne de confiance votre itinéraire.
R.A.S. n'est qu'un moyen parmi d'autre de le faire.
Si je bosse sur R.A.S. c'est par ce que je pense que cela peut-être utile pour certains.

De plus je vais essayer (vus mon niveau en Appli Android ça risque de prendre du temps :)), de créer une appli Android permettant d'envoyer (sur demande de l'utilisateur uniquement) des relevé de positions GPS durant la balade. Ces données ne seront accessible qu'aux amis et ce uniquement en cas de retard de la personne.

Effectivement CDE permet de faire à peu près la même chose que CARE (pour être honnête, CARE est arrivé après CDE).
Par contre (et c'est très important), CDE a 2 gros inconvénients par rapport à CARE :
- CDE n'est plus vraiment maintenu
- CED est plus un prototype qu'un programme bullet proof

Ce qui veux dire que :
- sur un noyaux/glibc récent, CED ne fonctionne pas à cause de certains sycalls non pris en charge
- nous avons beaucoup d'exemple sur lesquels CDE ne marche pas (re-exécution non fonctionnelle), alors que CARE fonctionne correctement
- CDE est beaucoup moins portable que CARE

Sur la portabilité de CARE il sera possible d'écrire un article entier. Pour faire simple :
- CARE est compilé statiquement afin de ne dépendre d'aucune libraires externe (facile à faire avec CDE)
- CARE n'utilise aucun syscall qui n'était pas présent sur le noyaux 2.6.0 (un peu plus technique à faire avec CDE)
- Si le noyaux sur lequel est tourné la re-exécution ne supporte pas certains sycalls demandé par l'application re-exécuté, CARE émulera les syscalls en question, suivant ce qui est disponible sur le noyaux de la machine effectuant la re-exécution (beaucoup plus difficile)

CARE va créer une archive contenant l'intégralité des fichiers accédé, donc y compris :
- ld-linux.so (dans lib/x86_64-linux-gnu pour moi)
- libc.so.6
- tous les fichiers de conf
- les scripts lancés par l'application (par exemple python pour gimp)
- les fichiers de cache utilisés (par exemple /var/cache/fontconfig/…)

Je viens de tester avec Gimp et j'ai une archive de 101Mo.

A propos du temps pour faire un test, il suffit de faire

care -o archive.bin ma_commande
./archive.bin
./archive/re-execute.sh

C'est exactement cela.
CARE a pour but de permettre de re-exécuter une application de la même manière sur plusieurs systèmes différents.

Si je reprends l'exemple de mon application django. Si je fait une archive CARE du serveur servant l'application, je ne pourrais accéder qu'aux pages auxquelles j'ai accédé lors de la première exécution.

CARE n'est pas magique, il ne fait qu'observer le programme afin de détecter les fichiers utilisés et de les archiver. Si les fichiers ne sont pas accédés lors de la première exécution, CARE ne pourra donc pas les archiver. En même temps cela veux dire que tu n'en as pas eu besoin lors de la première exécution et donc que tu n'en aura pas besoin lors de la re-exécution.
Cela permet donc de ne pas créer une archive inutilement volumineuse.

Si tu veux statifier un programme, il faut prendre le temps de faire tous les cas d'utilisations dont tu as besoin après. Souvent ça ne demande pas beaucoup de travail (en tout cas pour les cas que nous avons essayé).

Le but de CARE est de permettre la re-exécution d'une première exécution de l'application.
Il faut donc effectivement que lors de la première exécution, l'ensemble des actions que tu souhaite être capable de re-exécutées soit au moins exécutées une fois. Permettant à CARE de voir passer les fichiers correspondant.

CARE est un outils d'analyser dynamique (raison pour laquelle il marche sur un large panel de cas d'usage) et comme pour valgrind, il faut que la première exécution couvre les cas d'usage de la re-exécution.

Je m'en suis par exemple servie pour archiver un serveur web (le serveur de test de django). Celui-ci n'est alors capable, lors de la re-exécution, que de servir les pages déjà servies lors de la première exécution.

CARE va uniquement archiver les fichier accédés et relancer le programme en l'isolant dans l'archive ainsi crée. CARE n'enregistre ni ne rejoue les syscalls de l'application mais laisse l'application s'exécuter normalement (hormis l'isolation dans l'archive).
CARE ne garantit donc pas la reproduction d'un événement purement aléatoire.

Si l'application utilise un élément présent dans /dev, CARE laissera l'application y accéder (afin que celle-ci fonctionner correctement). Le générateur de nombre aléatoire sera donc celui de la machine faisant tourner l'application.

Est-ce que cela réponds à ta question ?

C'est exactement cela.
CARE va archiver l'ensemble des fichiers (et donc aussi le loader ELF et les librairies dynamiques) que le programme aura accédé. Donc si lors de la premier exécution, les librairies dynamique en question sont utilisées, elles seront présente dans l'archive.
Lors de la re-exécution, le programme n'aura accès qu'à ces fichiers. Il utilisera donc le même loader ELF et les même librairies dynamiques.

Cela dépends de ce que tu souhaite faire avec ta Red Hat. Si tu as besoin de logiciel non complètement obsolète, c'est juste impossible.
Voir ce commentaire sur reddit :
http://www.reddit.com/r/linux/comments/1r5q79/red_hat_enterprise_linux_65_released_brings_new/cdkfqwa

Non c'est unqiuement que l'on en a marre de se faire insulter par des imbéciles qui ne comprennent pas que tourner en root a un impact non négligeable sur le système. Sachant que les personnes en questions ne lisent évidement ni la doc ni les rapports d'erreur.
Donc si ils souhaitent faire tourner vlc en tant que root je les invite à faire un ./configure --enable-run-as-root && make install (et à ne plus se plaindre quand le système crash).

La question est de savoir pourquoi vlc fait ce genre de check.

Peut-être que recevoir des mails d'insultes comme quoi faire tourner vlc en root perturbe le système est une première réponse. En effet, jouer sur la priorité des threads est une bonne chose en tant qu'utilisateur normale mais peux poser problème de gros problème lorsque l'on tourne en root. Ce n'est évidement qu'une partie de la réponse.
Les utilisateurs ne lisant malheureusement pas souvent ni les messages d'erreur ni la doc.

Oui il est possible d'installer des paquets via apt-get sans être root. Il faut par contre ruser un petit peu car apt-get vérifie l'uid puis tente d'écrire dans des répertoire où seul root peux écrire.

Je te conseil de regarder du côté de PRoot. En utilisant PRoot, tu peux faire croire à apt-get que tu est root (proot -0) et rediriger les accès au file système.
Pour me faire un peu d'auto-pub, j'ai fait un bref tuto sur mon blog : PRoot sorcery

En fait pas du tout.

Android fait tourner chaque application dans une VM Java avec un user par application. L'OS est par contre partagé par les applications ainsi que toutes les libraries de rendu (graphique, son, …)

L'intérêt de QubeOS est d'isoler chaque application dans une VM (et donc avec un noyau par application). Il est donc très difficile de contaminer une application depuis une autre application. Sous Android il "suffirait" de passer par les différent namespaces partagés par les applications.

Une erreur de ma pars. Je devais le corriger avant la 0.1 et j'ai oublié !!

J'ai ajouté la demande d'acceptation de l'ajout à la liste d'amis.
On peux dnc envoyer une demande et l'annuler. Le destinataire peux accepter ou refuser la demande.
Ce n'est pas encore possible de supprimer un contact (bientôt)

Je vais rajouter cela (https://github.com/ivoire/RandoAmisSecours/issues/26).

En attendant, je peux supprimer directement dans l'interface d'administration si besoin :) (par mail perso si besoin).

Oui et non car je préfère que R.A.S. n'ait pas besoin d'envoyer de message d'alerte, car tout le monde est rentré sain et sauf.

je suis tout à fait d'accord que R.A.S. ne doit absoluement pas remplacer une bonne préparation ni le fait de donner notre itinéraire à un ou des amis avant de partir. Le but étant uniquement de simplifier cette démarche et de la rendre systématique.

Merci pour les retours je vais essayer de répondre à tous :

Ne peuvent être alertés que des membres de R.A.S
Tu es le second à le signaler donc je vais me pencher dessus prochainement :
https://github.com/ivoire/RandoAmisSecours/issues/23

Par contre aucune confirmation n'est demandé au membre lorsqu'on l'ajoute à sa liste d'amis

Une erreur de ma pars. Je devais le corriger avant la 0.1 et j'ai oublié !! Désolé.
J'ai désactivé cela le temps de rajouter la confirmation (ce soir normalement).

Contrairement à ce qui est indiqué sur la page d'accueil du site, tout le monde (même les visiteurs non identifiés) peuvent voir les sorties en cours ou terminées !
Humhum. Je me suis posé pas mal de question à ce sujet. Une autre possibilité serai de ne monter que ses propres sorties et celle de ses amis. Cela permettrai en même temps de ne pas avoir besoin d'aller dans le profile pour voir ses propres sorties. Qu'en pense-tu ?

Le mail reçu ne comporte pas la description texte de la sortie, ni l'heure de retour prévue.

https://github.com/ivoire/RandoAmisSecours/issues/24

Dans la description, les liens http ne sont pas actifs
Pour l'instant c'est uniquement du texte pure. Il faut que je trouve la lib qui fait cela toute seule. Conseils bienvenus :)
https://github.com/ivoire/RandoAmisSecours/issues/25

L'idéal serait de pouvoir choisir les "amis" auquel on souhaite donner l'alerte
Donc faire des groupes d'amis ou simplement la notion de permissions pour chaque amis ?

La liste de ses sorties, en cours ou terminée ou autre, se trouve dans le profile.
Voir la réponse sur les sorties visible à tous.

J'ai mis un peu de temps à comprendre ce que signifiait la "confirmation" d'une sortie

Cela veux dire que l'alerte en orange dans lorsqu'une sortie est crée (et donc non confirmé) n'est pas du tout lisible ni compréhensible.
Tout simplement je peux mettre toutes les sortie en confirmé par défaut (et supprimé les brouillons).
Ou sinon confirmer automatiquement les sorties à la date de début ?

Je n'ai pas compris à quoi servait le bouton "en retard", qui ne fait rien
Pas encore implémenté : tout simplement pour dire que l'on sait que l'on aura h heures de retard et donc décaler les alertes.

Tu as tout à fait raison de signalé cela.

Je vais rajouter un point dans la FAQ que je dois faire bientôt.

Je n'ai pas trouvé comment ajouter des contacts qui ne sont pas inscrits sur le site

Ce n'est pas possible pour le moment mais c'est une idée intéressante. Il faudrat par contre faire attention au spam (ie ne pas transformer R.A.S. en relais de spam).
https://github.com/ivoire/RandoAmisSecours/issues/23

Par ailleurs, quel est le contenu de l'email ?

le template est ici :
https://github.com/ivoire/RandoAmisSecours/blob/master/RandoAmisSecours/management/commands/alert.py#L90

C'est donc uniquement : le nom de la personne et le liens vers la page de la sortie.

Une autre fonctionnalité ++ qui pourrait être intéressante serait de pouvoir tracer son parcours.

C'est une très bonne idée, je ne sais pas par contre comment la mettre en place concrètement.

C'est exactement cela, juste avec une interface web autour.

Ce n'est par contre pas du tout spécifique à la Rando : il n'y a pas de restriction sur l'activité pratiqué. Moi je ne m'en sert que pour la montagne mais si certaines personnes trouvent d'autres utilisations, je suis intéressé.

Je ne suis pas du tout d'accord avec le fait d'avoir "assez de main d'oeuvre pour [...] Windows et OSX" : ce sont deux targets pour lesquelles tu n'as juste pas le choix :
1/ si tu ne le fais pas, personne ne le fera
2/ ces deux targets représentent la plus grande part de marché

Tout est une question de choix au final. Soit tu préfère que les (très) peu nombreux dev de VLC bossent sur le packaging, soit tu préfèrent qu'ils corrigent des bugs et ajoutent des fonctionnalitées.
Sachant que faire le packaging ne demande pas du tout les même compétences/connaissances que développer/corriger des bugs. Ce sont deux métiers très différents (et souvent appréciés par des personnes différentes).

Si tu veux tester le port android, les sources de l'UI sont sur le git de VideoLAN : http://git.videolan.org/?p=vlc-ports/android.git;a=summary

Si j'ai bien compris, tu cherche en fait un système de fichiers distribué qui fonctionne avec des nœuds étant connecté par intermittence. Bonne nouvelle ça existe, par contre il va te falloir chercher sur internet parce que je n'arrive pas à retrouver le nom.

Tu peux le faire avec la version de développement de VLC sans avoir à dumper le bluray sur le disque (ce que semble conseiller la page ubuntu).