Comme j'apprécie ProjeQtOr, j'en profite pour en rajouter un peu.
On l'utilise depuis plusieurs mois dans mon département et c'est un très bon outil qui fait beaucoup beaucoup plus que de la simple planification. C'est d'ailleurs un petit peu déroutant au début en général (non, la planif ne se fait pas automatiquement, et oui, il faut assigner une ressource à une activité pour que du temps soit planifié,….). Mais c'est super souple, pour peu qu'on entre dans le modèle d'habilitation (le truc le moins simple je pense) et qu'on travaille un peu les workflows. Tout (ou presque) dans un projet est modifiable, les noms, les liens, la hiérarchie des projets et des activités, … et ProjeQtOr ne perd jamais la tête.
D'ailleurs il est en test maintenant dans des départements qui font des gros projets (nous c'est plutôt pleins de petits projets qui se phagocytes les uns les autres), et les retours sont la aussi plutôt très bons.
L'outil évolue super vite et en général dans le bon sens. Et on a pas encore basculé à la dernier version, la 5 (juste par manque de temps, parce que le passage aux versions supérieures se passe en général comme une lettre à la poste).
Les décideurs apprécient aussi la longue liste des rapports disponibles.
Il y a des manques bien sûr, mais rien de bien bloquant AMHA.
Je ne suis pas totalement d'accord avec Gniarf. Disons au préalable que j'ai fais beaucoup de Tcl dans les années 90, ayant même donné une petite dizaine de formation sur ce langage. Depuis que je suis passé totalement dans l'administration système, je fais du Perl avec beaucoup de plaisir.
Mon avis est que Tcl est et reste un très bon langage de colle pour monter au sein d'une même application des librairies métiers très différentes. Le résultat est beaucoup plus simple a appréhender que Perl, car c'est un langage que je qualifie de régulier. L'ensemble du langage tiens en 11 règles, le reste c'est juste des commandes. C'était le contenu de ma formation: à la fin de la première demi-journée (oui, bien demi-journée) le langage était connu par les élèves. Ensuite on ne faisait qu'avancer dans l'utilisation des commandes pour finir par monter une petite application complète en 3 jours.
C'est très bien pour un ingénieur non-informaticien ayant à résoudre un problème d'automatisation de processus par exemple. 90% de son temps est passé à faire autre chose que de la programmation. Le langage utilisé doit rester simple et surtout facile à se rappeler quand on s'y remet 3 mois après (je ne parle pas de reprendre un script, je parle de refaire de la programmation pendant 2 jours quand on a passé 3 mois à faire autre chose). Je ne parle même pas de Php. Reste Python et Ruby, mais l'orientation objet est loin d'être facile à maitriser pour quelqu'un qui ne fait pas de la programmation très régulièrement.
Disons que Tcl souffre à mon avis de 2 points noirs techniques à la base: le fait d'avoir comme terminaison d'instruction le retour-chariot en plus du point-virgule. Ca gêne beaucoup l'écriture et lui donne un aspect shell-like qui déplait à beaucoup. Ensuite et surtout de ne pas avoir à l'origine un type de données quelconque qui permet de construire facilement des structures complexes. En Perl, un scalaire peut être une référence quelconque, et les instructions se débrouillent très bien avec. Impossible avec Tcl de base.
Par la suite, l'introduction des namespaces a permis de faire des choses, mais la aussi il y a eut un ratage avec l'obligation d'utiliser les ::. Si le séparateur avait été l'espace, il aurait été facile de faire des objets et instances d'objets qui se comportent comme des références de données complexes, avec un mécanisme intégré au langage, et non pas apporté par une extension (IncrTcl).
Enfin, l'attitude d'Ousterhout a bloqué à mon avis les évolutions surtout de Tk, ce qui a diminué fortement l'intérêt des développeurs d'interface graphique portables. Dommage.
Mais sinon: dès 1996, Tcl/TK supportait Unicode, était complément portable sur Windows, Unix et Mac, il y avait un plugin complet pour Netscape 4, un mécanisme de Thread intégré, de sous-interpréteur avec "sand-boxing" et escalade des privilèges ou équivalents, des extensions objets, .... C'était quand même vachement bien pour l'époque, non ?
Je me demande: Piwan gérant des infos personnelles des membres des associations, et donc étant suceptible d'effectuer des traitements automatisés (c'est le but), ne faut-il pas avoir une déclaration CNIL dans ce cas ?
Et le trombinoscope, c'est du droit à l'image, non ? On ne peut pas faire n'importe quoi avec ça en France.
Est-ce Piwam (ou plutôt l'équipe) s'est penché sur ces sujets, ou pour l'instant c'est laissé tel quel aux utilisateurs ?
je met tout sous GPL, y compris pour la France, et ça suffit amplement sauf pour les administrations tatillonnes qui refusent d'acheter car ne savent pas lire l'anglais
Petit bémol: si ton code est un logiciel libre et gratuit sous GPL, tu n'as probablement pas besoin d'avoir une licence en français style CeCILL. Certaines études (du ministère de la justice il me semble) considère qu'un marché public étant un contrat portant paiement, les contraintes du code des marchés ne s'appliquent qu'à ce qui est payé. Le code des marchés obligent que l'ensemble des documents inscrits et payés par le marché soit rédigé en français, les licences comprises (merci M'sieur Toubon).
Donc si ton code est gratuitement fourni et sous licence libre quelconque d'ailleurs, il ne peut pas être compris dans le marché comme un élément de ce qui est payé, puisqu'il est gratuit! Donc tu n'as absolument pas besoin d'avoir une licence en français!
Par contre si tu es payé pour écrire du code au titre de ce marché et que tu veux le mettre sous GPL, alors la il faut négocier au préalable (dans le cadre de l'appel d'offre, mais des avenants restent toujours possibles surtout si ça ne change pas la nature et le montant global du marché) et probablement utiliser une double licence GPL+CeCILL pour respecter la loi.
En même temps, tout le monde s'en fout...jusqu'au jour ou il y aura un jugement...
J'ai pas lu le décret, mais je pense qu'on parle des AC Racines, ce qui permettra alors aux usagers de se connecter aux serveurs Web des administrations de manière sécurisée (comme chacun le sait), en les embêtant le moins possible.
Le but n'est certainement pas de faire une AC Racine pour délivrer des certificats à tout le monde, comme je pense que tu t'en doutes (vu tes précédantes remarques, tu sembles être bien dans le bain), mais d'éviter aux usagers de charger 36 AC Racines, juste en chargeant l'AC Racine nationale la 1ière fois.
Cette AC Racine va probablement servir a signer les nouvelles AC Racines des administrations, et à sursigner les existantes, aux exigences de sécurité de la DCSSI près bien sûr.
A noter qu'un usager est une personne accédant légitimement à un systèmes d'information d'une administration suivant ses droits et ses besoins pour y effectuer une action, sans pour autant faire partie de cette administration. Ainsi une personne qui effectue un paiement d'impôt en ligne est un usager. L'agent des impôt qui accédera à une application permettant de contrôler des éléments de cet usager est un utilisateur. Bien sûr cette notion est fluctuante: ainsi un usager d'une administration peut être aussi un utilisateur d'une autre.
Comme tu l'écris, les utilisateurs ne sont pas un problème réél, puisque leur environnement est à peu près maîtrisé. Ce qui n'est pas le cas des usagers.
> Cela dit il me semble qu'il a confié à un PME française le soin de développer un module de format ODF pour sa suite office.
Il me semble que ça ne concerne que la partie traitement de texte. Si j'ai juste, et qu'OpenXML n'est pas au RGI, Microsoft ne pourra pas répondre avec ça, la suite couvrant beaucoup plus de choses.
Ce n'est pas la notification d'un marché public, mais bien la validation par le secrétaire général d'un choix d'outil (OOo) et de format (OpenDocument) pour la suite bureautique du ministère de l'Agriculture. Il n'y a donc pas de SSLL la dedans.
Je pense que si une SSLL doit intervenir dans cette affaire, ce sera après que le comité de pilotage aura défini et validé des plannings et un processus de migration.
Le choix d'OOo au MAP s'accompagne d'un plan de formation conséquent ainsi que de recommendations concernant les usages d'une suite bureautique et donc aborde la question dles formats d'échanges, aussi bien vis à vis de l' interne que de l'externe.
> Un serveur d'envois n'est pas obligatoirement un serveur de
> reception. Et justement, c'est le cas chez les isp.
Oui, mais rien n'aurait empêcher de déclarer les serveurs d'envois
en MX avec un poid très faible (euh non, très fort), voir même de
refuser les connections entrantes dessus, et utiliser les RFCs déjà
existants pour mettre en place ce type de protection. Or ce n'est
pas le cas. Juste pour dire que SPF simplifie peut être ce qu'il
est déjà possible de faire, mais n'apporte apparement rien de
plus!
De plus, il faut quand même se rappeler qu'il n'y a pas que des
ISPs sur Internet, il y a aussi beaucoup d'entreprises connectées
en direct.
Tiens justement, comment fait-on avec SPF pour tester les MX
backups des ISPs et autres ? Supposons que j'ai un MX backup
chez quelqu'un qui me fournit aussi la connection Internet, mais
pas le relais SMTP. Si celui-ci (chez moi) tombe, le MX backup de
*mon* domaine va récupérer *tous* les messages. Quand je
relance mon serveur, le backup va m'envoyer tous les messages
sans être bien sûr déclarer dans le SPF des émetteurs. Comment
je vérifie ? En faisant juste confiance au MX backup ?
Conclusion: c'est bien, c'est mieux que l'existant équivalent, mais
comme ce n'est pas un saut significatif en avant, ça va pas être
suffisament utilisé, hélas!
> c'est un moyen de TE protéger contre l'utilisation de TON adresse
> par des spammeurs ou des virus.
Euh, non pas tout à fait, si j'ai bien compris: SPF permet aux autres
de protéger *mon* domaine, car la vérif se fait par les autres. C'est
juste une indication que *je* fourni. Ce n'est pas une protection
en soi.
Moi, je vérifie *déjà* qu'un message entrant dans mon domaine
n'est pas émis par une adresse externe qui se fait passer pour
quelqu'un de mon domaine, et je n'ais pas besoin de SPF.
C'est bien le problème de ce type de protection: on ne se protége
pas, on ne protége pas son domaine, on fourni suffisament
d'indications pour permettre aux autres de le faire à sa place.
C'est le point faible: ça ne marche que s'il y a suffisament (50,
60, 90%?) de domaines qui l'utilise.
D'autant plus qu'il existe déjà un moyen dans le DNS de
faire à peu prés la même chose: utiliser le MX pour vérifier
si le serveur émetteur est bien un MX pour le domaine.
Or si vous mettez ça en place, vous allez facilement éliminer
50% de messages valides tout simplement parce que les
champs ne sont pas renseignés.
Par exemple, il *faudrait* (je crois que c'est un SHOULD dans
un RFC) que les serveurs SMTP soient aussi enregistrés dans
le champ IN-ARPA.NET du DNS, celui qui permet de retrouver le
nom du serveur a partir de l'adresse IP. Il est possible de rejeter
les serveurs mal configurés, c'est à dire ceux dont il est impossible
de retrouver le nom.
Et la c'est probablement 80% des messages qui vont gicler.....
Conclusion: batir une stratégie de combat contre les SPAMs sur
la bonne volonté et/ou la bonne connaissance des admins (de
*tous* les admins potentiels) sur Internet est plus qu'illusoire.
Je crois qu'il existe une extension pour ThunderBird/FireBird
qui rajoute une entrée dans les menus des liens pour ouvrir
IE sur le lien au lieu du navigateur Mozilla (en fait, j'en suis
sûr mais j'ai pas les info sous la main).
Un p'tit gars de chez nous l'a adapté pas plus tard qu'il y
a 2 jours à Mozilla 1.4 (+franciser). Ca semble marcher même
si c'est pas encore validé.
Avec ça on contourne nous aussi le problème des Intranets
codés avec on se demande quoi (je reste poli pour mon premier
post ici :-), alors que *nous* on a choisi Mozilla comme client
de messagerie (nanananéreuh :-)
Normalement, je dois la tester lundi sur plusieurs WinOS avec
la 1.5 aussi. Je peux m'amuser avec la 1.6 aussi en plus.
Si ça marche, on devrait pouvoir retourner les modifs à l'auteur
et vous le faire savoir rapidement.
[^] # Re: Intéressant
Posté par Joël Saunier . En réponse à la dépêche Structuration de l'offre de services autour du gestionnaire libre de projets ProjeQtOr. Évalué à 1.
Comme j'apprécie ProjeQtOr, j'en profite pour en rajouter un peu.
On l'utilise depuis plusieurs mois dans mon département et c'est un très bon outil qui fait beaucoup beaucoup plus que de la simple planification. C'est d'ailleurs un petit peu déroutant au début en général (non, la planif ne se fait pas automatiquement, et oui, il faut assigner une ressource à une activité pour que du temps soit planifié,….). Mais c'est super souple, pour peu qu'on entre dans le modèle d'habilitation (le truc le moins simple je pense) et qu'on travaille un peu les workflows. Tout (ou presque) dans un projet est modifiable, les noms, les liens, la hiérarchie des projets et des activités, … et ProjeQtOr ne perd jamais la tête.
D'ailleurs il est en test maintenant dans des départements qui font des gros projets (nous c'est plutôt pleins de petits projets qui se phagocytes les uns les autres), et les retours sont la aussi plutôt très bons.
L'outil évolue super vite et en général dans le bon sens. Et on a pas encore basculé à la dernier version, la 5 (juste par manque de temps, parce que le passage aux versions supérieures se passe en général comme une lettre à la poste).
Les décideurs apprécient aussi la longue liste des rapports disponibles.
Il y a des manques bien sûr, mais rien de bien bloquant AMHA.
[^] # Re: Quel est l'avenir de tcl/tk ?
Posté par Joël Saunier . En réponse à la dépêche Conférence EuroTcl 2010. Évalué à 4.
Mon avis est que Tcl est et reste un très bon langage de colle pour monter au sein d'une même application des librairies métiers très différentes. Le résultat est beaucoup plus simple a appréhender que Perl, car c'est un langage que je qualifie de régulier. L'ensemble du langage tiens en 11 règles, le reste c'est juste des commandes. C'était le contenu de ma formation: à la fin de la première demi-journée (oui, bien demi-journée) le langage était connu par les élèves. Ensuite on ne faisait qu'avancer dans l'utilisation des commandes pour finir par monter une petite application complète en 3 jours.
C'est très bien pour un ingénieur non-informaticien ayant à résoudre un problème d'automatisation de processus par exemple. 90% de son temps est passé à faire autre chose que de la programmation. Le langage utilisé doit rester simple et surtout facile à se rappeler quand on s'y remet 3 mois après (je ne parle pas de reprendre un script, je parle de refaire de la programmation pendant 2 jours quand on a passé 3 mois à faire autre chose). Je ne parle même pas de Php. Reste Python et Ruby, mais l'orientation objet est loin d'être facile à maitriser pour quelqu'un qui ne fait pas de la programmation très régulièrement.
Disons que Tcl souffre à mon avis de 2 points noirs techniques à la base: le fait d'avoir comme terminaison d'instruction le retour-chariot en plus du point-virgule. Ca gêne beaucoup l'écriture et lui donne un aspect shell-like qui déplait à beaucoup. Ensuite et surtout de ne pas avoir à l'origine un type de données quelconque qui permet de construire facilement des structures complexes. En Perl, un scalaire peut être une référence quelconque, et les instructions se débrouillent très bien avec. Impossible avec Tcl de base.
Par la suite, l'introduction des namespaces a permis de faire des choses, mais la aussi il y a eut un ratage avec l'obligation d'utiliser les ::. Si le séparateur avait été l'espace, il aurait été facile de faire des objets et instances d'objets qui se comportent comme des références de données complexes, avec un mécanisme intégré au langage, et non pas apporté par une extension (IncrTcl).
Enfin, l'attitude d'Ousterhout a bloqué à mon avis les évolutions surtout de Tk, ce qui a diminué fortement l'intérêt des développeurs d'interface graphique portables. Dommage.
Mais sinon: dès 1996, Tcl/TK supportait Unicode, était complément portable sur Windows, Unix et Mac, il y avait un plugin complet pour Netscape 4, un mécanisme de Thread intégré, de sous-interpréteur avec "sand-boxing" et escalade des privilèges ou équivalents, des extensions objets, .... C'était quand même vachement bien pour l'époque, non ?
# Un question peut-être stupide, mais...
Posté par Joël Saunier . En réponse à la dépêche Piwam 1.1.2 disponible. Évalué à 1.
Et le trombinoscope, c'est du droit à l'image, non ? On ne peut pas faire n'importe quoi avec ça en France.
Est-ce Piwam (ou plutôt l'équipe) s'est penché sur ces sujets, ou pour l'instant c'est laissé tel quel aux utilisateurs ?
[^] # Re: genial... ou pas
Posté par Joël Saunier . En réponse à la dépêche Edu4 sanctionné pour avoir bafoué la licence GPL. Évalué à 3.
Petit bémol: si ton code est un logiciel libre et gratuit sous GPL, tu n'as probablement pas besoin d'avoir une licence en français style CeCILL. Certaines études (du ministère de la justice il me semble) considère qu'un marché public étant un contrat portant paiement, les contraintes du code des marchés ne s'appliquent qu'à ce qui est payé. Le code des marchés obligent que l'ensemble des documents inscrits et payés par le marché soit rédigé en français, les licences comprises (merci M'sieur Toubon).
Donc si ton code est gratuitement fourni et sous licence libre quelconque d'ailleurs, il ne peut pas être compris dans le marché comme un élément de ce qui est payé, puisqu'il est gratuit! Donc tu n'as absolument pas besoin d'avoir une licence en français!
Par contre si tu es payé pour écrire du code au titre de ce marché et que tu veux le mettre sous GPL, alors la il faut négocier au préalable (dans le cadre de l'appel d'offre, mais des avenants restent toujours possibles surtout si ça ne change pas la nature et le montant global du marché) et probablement utiliser une double licence GPL+CeCILL pour respecter la loi.
En même temps, tout le monde s'en fout...jusqu'au jour ou il y aura un jugement...
[^] # Re: Et les navigateurs ?
Posté par Joël Saunier . En réponse à la dépêche L'État français se dote d'une autorité de certification racine. Évalué à 2.
Le but n'est certainement pas de faire une AC Racine pour délivrer des certificats à tout le monde, comme je pense que tu t'en doutes (vu tes précédantes remarques, tu sembles être bien dans le bain), mais d'éviter aux usagers de charger 36 AC Racines, juste en chargeant l'AC Racine nationale la 1ière fois.
Cette AC Racine va probablement servir a signer les nouvelles AC Racines des administrations, et à sursigner les existantes, aux exigences de sécurité de la DCSSI près bien sûr.
A noter qu'un usager est une personne accédant légitimement à un systèmes d'information d'une administration suivant ses droits et ses besoins pour y effectuer une action, sans pour autant faire partie de cette administration. Ainsi une personne qui effectue un paiement d'impôt en ligne est un usager. L'agent des impôt qui accédera à une application permettant de contrôler des éléments de cet usager est un utilisateur. Bien sûr cette notion est fluctuante: ainsi un usager d'une administration peut être aussi un utilisateur d'une autre.
Comme tu l'écris, les utilisateurs ne sont pas un problème réél, puisque leur environnement est à peu près maîtrisé. Ce qui n'est pas le cas des usagers.
[^] # Re: Peur de radoter ...
Posté par Joël Saunier . En réponse à la dépêche RGI : Parution du décret au journal officiel. Évalué à 1.
Il me semble que ça ne concerne que la partie traitement de texte. Si j'ai juste, et qu'OpenXML n'est pas au RGI, Microsoft ne pourra pas répondre avec ça, la suite couvrant beaucoup plus de choses.
[^] # Re: Contrat SSLL
Posté par Joël Saunier . En réponse à la dépêche OpenOffice au ministère de l'agriculture et de la pêche : C'est fait !. Évalué à 3.
Je pense que si une SSLL doit intervenir dans cette affaire, ce sera après que le comité de pilotage aura défini et validé des plannings et un processus de migration.
[^] # Re: Top crédibilité
Posté par Joël Saunier . En réponse à la dépêche OpenOffice.org au Ministère de l'Agriculture et de la Pêche (MAP). Évalué à 3.
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par Joël Saunier . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à 1.
> reception. Et justement, c'est le cas chez les isp.
Oui, mais rien n'aurait empêcher de déclarer les serveurs d'envois
en MX avec un poid très faible (euh non, très fort), voir même de
refuser les connections entrantes dessus, et utiliser les RFCs déjà
existants pour mettre en place ce type de protection. Or ce n'est
pas le cas. Juste pour dire que SPF simplifie peut être ce qu'il
est déjà possible de faire, mais n'apporte apparement rien de
plus!
De plus, il faut quand même se rappeler qu'il n'y a pas que des
ISPs sur Internet, il y a aussi beaucoup d'entreprises connectées
en direct.
Tiens justement, comment fait-on avec SPF pour tester les MX
backups des ISPs et autres ? Supposons que j'ai un MX backup
chez quelqu'un qui me fournit aussi la connection Internet, mais
pas le relais SMTP. Si celui-ci (chez moi) tombe, le MX backup de
*mon* domaine va récupérer *tous* les messages. Quand je
relance mon serveur, le backup va m'envoyer tous les messages
sans être bien sûr déclarer dans le SPF des émetteurs. Comment
je vérifie ? En faisant juste confiance au MX backup ?
Conclusion: c'est bien, c'est mieux que l'existant équivalent, mais
comme ce n'est pas un saut significatif en avant, ça va pas être
suffisament utilisé, hélas!
Joël
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par Joël Saunier . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à 1.
> par des spammeurs ou des virus.
Euh, non pas tout à fait, si j'ai bien compris: SPF permet aux autres
de protéger *mon* domaine, car la vérif se fait par les autres. C'est
juste une indication que *je* fourni. Ce n'est pas une protection
en soi.
Moi, je vérifie *déjà* qu'un message entrant dans mon domaine
n'est pas émis par une adresse externe qui se fait passer pour
quelqu'un de mon domaine, et je n'ais pas besoin de SPF.
C'est bien le problème de ce type de protection: on ne se protége
pas, on ne protége pas son domaine, on fourni suffisament
d'indications pour permettre aux autres de le faire à sa place.
C'est le point faible: ça ne marche que s'il y a suffisament (50,
60, 90%?) de domaines qui l'utilise.
Joël
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par Joël Saunier . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à 0.
faire à peu prés la même chose: utiliser le MX pour vérifier
si le serveur émetteur est bien un MX pour le domaine.
Or si vous mettez ça en place, vous allez facilement éliminer
50% de messages valides tout simplement parce que les
champs ne sont pas renseignés.
Par exemple, il *faudrait* (je crois que c'est un SHOULD dans
un RFC) que les serveurs SMTP soient aussi enregistrés dans
le champ IN-ARPA.NET du DNS, celui qui permet de retrouver le
nom du serveur a partir de l'adresse IP. Il est possible de rejeter
les serveurs mal configurés, c'est à dire ceux dont il est impossible
de retrouver le nom.
Et la c'est probablement 80% des messages qui vont gicler.....
Conclusion: batir une stratégie de combat contre les SPAMs sur
la bonne volonté et/ou la bonne connaissance des admins (de
*tous* les admins potentiels) sur Internet est plus qu'illusoire.
Joel Saunier
[^] # Re: Mozilla 1.6 dans les bacs
Posté par Joël Saunier . En réponse à la dépêche Mozilla 1.6 dans les bacs. Évalué à 2.
qui rajoute une entrée dans les menus des liens pour ouvrir
IE sur le lien au lieu du navigateur Mozilla (en fait, j'en suis
sûr mais j'ai pas les info sous la main).
Un p'tit gars de chez nous l'a adapté pas plus tard qu'il y
a 2 jours à Mozilla 1.4 (+franciser). Ca semble marcher même
si c'est pas encore validé.
Avec ça on contourne nous aussi le problème des Intranets
codés avec on se demande quoi (je reste poli pour mon premier
post ici :-), alors que *nous* on a choisi Mozilla comme client
de messagerie (nanananéreuh :-)
Normalement, je dois la tester lundi sur plusieurs WinOS avec
la 1.5 aussi. Je peux m'amuser avec la 1.6 aussi en plus.
Si ça marche, on devrait pouvoir retourner les modifs à l'auteur
et vous le faire savoir rapidement.
Joël S.