L'erreur est humaine et les tests unitaires ne sont (presque) jamais exhaustifs, il existe fort heureusement d'autres approches.
LA PREUVE DE PROGRAMME !
Il est sans doute intéressant de rappeler comment le gars qui a trouvé la faille SSL a procédé :
Le gars a utilisé Coq un puissant assistant de preuve (mathématiques) pour "révéler" le bug.
La méthode qu'il a employée est tout simplement fantastique : http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html#how-did-i-discover-the-bug
Clairement c'est le genre de gars qui ouvre la voie pour démocratiser la démonstration de programme.
Pour ceux que çà intéresse un cours bien fait sur le sujet (orienté Coq) : http://fuscia.inrialpes.fr/cours/coq/
Bien sûr il est irréaliste de vouloir développer un programme d'envergure en Coq mais ces techniques commence à être disponibles sur des langages "mainstream".
Leon (http://lara.epfl.ch/w/leon) par exemple est très prometteur pour démontrer du code en Scala.
C'est précisément l'un des intérêts majeurs de ScalaLab cité un peu plus haut.
ScalaLab utilise et encourage l'approche fonctionnelle. C'est une volonté de l'auteur.
Ceci est possible puisque Scala intègre également le paradigme de programmation fonctionnelle que ScalaLab utilise et étend.
Il est vrai que tous les benchs sont à prendre avec des pincettes mais avez vous lu le document ?
We should note also that although our benchmarks involve rather small computation times, they are accurate. Indeed by increasing two times the number of points for Henon map, we have on all systems about two times increase in delay also.
Le bundle contient d'autres benchs pour vous faire une idée.
En pratique on constate que le langage de script utilisé par ScalaLab est la plupart du temps effectivement plus rapide que le script Matlab équivalent.
Il y a des raisons mécaniques à cela qui sont décrites dans le chapitre "Scala and Groovy" du document ...
Sans vouloir faire du prosélytisme à outrance, on peut presque considérer ScalaLab comme un démonstrateur des possibilités de Scala.
Pour ne parler que de la vitesse d'exécution, ScalaLab laisse Scilab et Matlab loin derrière : un bench ici
Mais ScalaLab a bien d'autres atouts.
KVM finira par faire sa place.
Je l'utilise déjà tous les jours sans le moindre soucis jusqu'ici.
C'est simple et efficace. Ca manque juste un peu d'outillage.
CAS qui l'air de rien et sans FUD aucun est devenu une solution mature et efficace pour implémenter sans frais un WEB SSO local.
La "cassification" des applications consiste simplement à déléguer l'authentification au serveur CAS centralisé et avec les bilbiothèques fournies c'est trés simple et propre quelque soit le language utilisé.
Dans le cas d'applications JAVA il est même possible de "cassifier" l'application sans la modifier en agissant uniquement au niveau du filtre de servlet.
Les commentaires montrent que le sujet "fédération d'identité" demande à être démystifié.
La méconnaissance du sujet conduit visiblement à des amalgames ...
La question de Champi me semble importante et la réponse un peu laconique pour une personne soucieuse de passer de la théorie à la pratique.
Shibboleth précise clairement qu'il ne fournit pas de mécanisme SSO mais qu'il s'appuie sur CAS par exemple. Ainsi lors de la mise en oeuvre les applications sont d'abord "casifiées" pour le SSO local et Shibboleth intervient alors pour fédérer des SSO locaux.
Quand est-il pour liberty alliance ? N'est-il pas un peu cavalier de prétendre fournir un service SSO si celui ne pourrait-être utilisé qu'avec des applications compatible liberty.
Comment rendre les applications existantes compatibles liberty ?
Que faire avec mon parc d'applis en PHP, Perl, Python, JAVA , ... ?
Quelle est l'équivalent de la "casification" ?
Comment une application casifiée s'intégre elle dans liberty alliance ?
Avec SAML 2.0 plus personne ne doute de l'interopérabilité prochaine de liberty alliance et de Shibboleth mais comment développer aujourd'hui une application capable de s'intégrer avec l'une ou l'autre de ces technologies et comment migrer les applications existantes ?
Les réponses a ses questions permettront sans doute de démystifier (un peu) la fédération d'identité ...
Probablement pas non ou alors de façon vraiment trés maladroite.
Myfaces est une excellente implémentation de JSF et la pertinence des logs est même globalement meilleure que celle de SUN.
Le fait de jouer avec les deux implémentations m'a permi d'élucider quelques problèmes sioux sur des projets JSF complexes.
Au final c'est la version avec Myfaces qui a été retenue pour l'ensemble des projets JSF. Et personne ne s'en plaint :-)
L'expérience montre toutefois qu'au fils des versions des specs les interprétations inévitables vont créer des implémentations incompatibles et qu'il sera impossible de basculer un projet d'une implémentation à l'autre comme j'ai pu le faire assez facilement jusqu'ici.
Reste à espérer au contraire que ces 2 implémentations permettront d'affiner les points délicats dans les SPECS ... Soyons optimiste.
L'ouverture d'un code est toujours une bonne nouvelle.
Il faut arrêter de chercher la petite bête.
Vous ne semblez pas saisir les enjeux.
Il ne s'agit pas de bannir les paquets non-free mais simplement de les distinguer clairement.
Ce n'est pas de la masturbation intellectuelle mais au contraire un objectif tout à fait louable.
L'amalgame avec la sortie de SARGE est désolant.
Il faut plus y voir une provocation pour attirer l'attention qu'autre chose.
En fait bien peu ont vu la portée de leur acte en votant pour la modification du contrat social Debian.
Je renvoie les âmes égarés aux propos de RMS et consorts expliquant pourquoi l'utilisation des paquets non-free peut soulever des problèmes à la communauté du Logiciel Libre.
Il s'agit de clarifier la situtation alors pourquoi crier à l'intégrisme ?
[^] # Re: Inspiration
Posté par newca (site web personnel) . En réponse à la dépêche Sortie de Miam-Player 0.7.2. Évalué à 1.
Un début de réponse sous la forme d'un constat.
La conso CPU avec OSX est bien plus faible avec MiamPlayer qu'avec Clementine.
https://github.com/clementine-player/Clementine/issues/4733
# Une autre approche est possible
Posté par newca (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 9. Dernière modification le 14 janvier 2015 à 23:22.
L'erreur est humaine et les tests unitaires ne sont (presque) jamais exhaustifs, il existe fort heureusement d'autres approches.
LA PREUVE DE PROGRAMME !
Il est sans doute intéressant de rappeler comment le gars qui a trouvé la faille SSL a procédé :
Le gars a utilisé Coq un puissant assistant de preuve (mathématiques) pour "révéler" le bug.
La méthode qu'il a employée est tout simplement fantastique : http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html#how-did-i-discover-the-bug
Clairement c'est le genre de gars qui ouvre la voie pour démocratiser la démonstration de programme.
Pour ceux que çà intéresse un cours bien fait sur le sujet (orienté Coq) : http://fuscia.inrialpes.fr/cours/coq/
Bien sûr il est irréaliste de vouloir développer un programme d'envergure en Coq mais ces techniques commence à être disponibles sur des langages "mainstream".
Leon (http://lara.epfl.ch/w/leon) par exemple est très prometteur pour démontrer du code en Scala.
Mais il existe tout un tas d'outils et d'approches pour vérifier/démontrer qu'un programme est correct : https://github.com/johnyf/tool_lists/blob/master/verification_synthesis.md
IMHO c'est çà l'avenir de l'informatique et c'est par ce biais que ce fera la jonction (naturelle) avec les mathématiques !
Tous les développeurs devraient s'intéresser à la preuve de programme et pas seulement les universitaires ou les boites spécialisées.
[^] # Re: Langage fonctionnel ?
Posté par newca (site web personnel) . En réponse à la dépêche Petite actu des outils d’analyse numérique. Évalué à 1.
C'est précisément l'un des intérêts majeurs de ScalaLab cité un peu plus haut.
ScalaLab utilise et encourage l'approche fonctionnelle. C'est une volonté de l'auteur.
Ceci est possible puisque Scala intègre également le paradigme de programmation fonctionnelle que ScalaLab utilise et étend.
[^] # Re: Et aussi ScalaLab !
Posté par newca (site web personnel) . En réponse à la dépêche Petite actu des outils d’analyse numérique. Évalué à 2.
Il est vrai que tous les benchs sont à prendre avec des pincettes mais avez vous lu le document ?
Le bundle contient d'autres benchs pour vous faire une idée.
En pratique on constate que le langage de script utilisé par ScalaLab est la plupart du temps effectivement plus rapide que le script Matlab équivalent.
Il y a des raisons mécaniques à cela qui sont décrites dans le chapitre "Scala and Groovy" du document ...
# Et aussi ScalaLab !
Posté par newca (site web personnel) . En réponse à la dépêche Petite actu des outils d’analyse numérique. Évalué à 2.
ScalaLab est plus que prometteur.
Sans vouloir faire du prosélytisme à outrance, on peut presque considérer ScalaLab comme un démonstrateur des possibilités de Scala.
Pour ne parler que de la vitesse d'exécution, ScalaLab laisse Scilab et Matlab loin derrière : un bench ici
Mais ScalaLab a bien d'autres atouts.
Pour les pythoneux sceptiques sur les languages statiques, l'avis de Bruce Eckel sur Scala mérite le détour.
The Static Language that Feels Dynamic
# Bon à savoir
Posté par newca (site web personnel) . En réponse à la dépêche Citrix Systems Inc. achète la société XenSource Inc.. Évalué à 6.
KVM finira par faire sa place.
Je l'utilise déjà tous les jours sans le moindre soucis jusqu'ici.
C'est simple et efficace. Ca manque juste un peu d'outillage.
http://kvm.qumranet.com/kvmwiki
[^] # Re: Serveur CAS
Posté par newca (site web personnel) . En réponse à la dépêche Sortie de Lasso 0.6.5. Évalué à 1.
http://www.ja-sig.org/products/cas/index.html
CAS qui l'air de rien et sans FUD aucun est devenu une solution mature et efficace pour implémenter sans frais un WEB SSO local.
La "cassification" des applications consiste simplement à déléguer l'authentification au serveur CAS centralisé et avec les bilbiothèques fournies c'est trés simple et propre quelque soit le language utilisé.
Dans le cas d'applications JAVA il est même possible de "cassifier" l'application sans la modifier en agissant uniquement au niveau du filtre de servlet.
# De la théorie à la pratique
Posté par newca (site web personnel) . En réponse à la dépêche Sortie d'Authentic 0.5. Évalué à 3.
La méconnaissance du sujet conduit visiblement à des amalgames ...
La question de Champi me semble importante et la réponse un peu laconique pour une personne soucieuse de passer de la théorie à la pratique.
Shibboleth précise clairement qu'il ne fournit pas de mécanisme SSO mais qu'il s'appuie sur CAS par exemple. Ainsi lors de la mise en oeuvre les applications sont d'abord "casifiées" pour le SSO local et Shibboleth intervient alors pour fédérer des SSO locaux.
Quand est-il pour liberty alliance ? N'est-il pas un peu cavalier de prétendre fournir un service SSO si celui ne pourrait-être utilisé qu'avec des applications compatible liberty.
Comment rendre les applications existantes compatibles liberty ?
Que faire avec mon parc d'applis en PHP, Perl, Python, JAVA , ... ?
Quelle est l'équivalent de la "casification" ?
Comment une application casifiée s'intégre elle dans liberty alliance ?
Avec SAML 2.0 plus personne ne doute de l'interopérabilité prochaine de liberty alliance et de Shibboleth mais comment développer aujourd'hui une application capable de s'intégrer avec l'une ou l'autre de ces technologies et comment migrer les applications existantes ?
Les réponses a ses questions permettront sans doute de démystifier (un peu) la fédération d'identité ...
[^] # Re: MyFaces
Posté par newca (site web personnel) . En réponse à la dépêche Sun ouvre le code de son implémentation de JSF (Java Server Faces). Évalué à 1.
Myfaces est une excellente implémentation de JSF et la pertinence des logs est même globalement meilleure que celle de SUN.
Le fait de jouer avec les deux implémentations m'a permi d'élucider quelques problèmes sioux sur des projets JSF complexes.
Au final c'est la version avec Myfaces qui a été retenue pour l'ensemble des projets JSF. Et personne ne s'en plaint :-)
L'expérience montre toutefois qu'au fils des versions des specs les interprétations inévitables vont créer des implémentations incompatibles et qu'il sera impossible de basculer un projet d'une implémentation à l'autre comme j'ai pu le faire assez facilement jusqu'ici.
Reste à espérer au contraire que ces 2 implémentations permettront d'affiner les points délicats dans les SPECS ... Soyons optimiste.
L'ouverture d'un code est toujours une bonne nouvelle.
Il faut arrêter de chercher la petite bête.
# Re: La sortie de la prochaine Debian menacée ?
Posté par newca (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 3.
Il ne s'agit pas de bannir les paquets non-free mais simplement de les distinguer clairement.
Ce n'est pas de la masturbation intellectuelle mais au contraire un objectif tout à fait louable.
L'amalgame avec la sortie de SARGE est désolant.
Il faut plus y voir une provocation pour attirer l'attention qu'autre chose.
En fait bien peu ont vu la portée de leur acte en votant pour la modification du contrat social Debian.
Je renvoie les âmes égarés aux propos de RMS et consorts expliquant pourquoi l'utilisation des paquets non-free peut soulever des problèmes à la communauté du Logiciel Libre.
Il s'agit de clarifier la situtation alors pourquoi crier à l'intégrisme ?