Je me permets donc de citer la "propagande" qu'ils sont allé faire chez microsoft: <<Plutôt sévère après six ans d'expérience, le bilan du spécialiste du commerce électronique de matériel informatique LDLC sur l'open source est sans appel. La société fait table rase de son existant et adopte à cette occasion la plate-forme Windows de Microsoft afin de gagner en réactivité, en indépendance et en coûts.>>
Alors oui, ça fait marrer parce que pour leur indépendance, les faits montrent qu'il s n'en ont aucune (c'est pas notre faute c'est Siemens ...), en la réactivité elle a plus été chez les clients (qui se sont barrés) que chez eux.
Quand on ne veut pas faire les choses simplement mais qu'on veut faire de la propagande et qu'on se prends les pieds dans le tapis, on passe forcément au bétisier de la fin de l'année et on est ridicule.
je m'apperçois avec stupeur (lire: énervement) que sans rien me demander, l'install utilise les sources de la testing au lieu de la stable !!!! C'est quoi ce délire ? Ca sert à quoi de faire des impages iso d'install de la *sarge* si c'est pour installer une etsting sans rien dire à l'utilisateur ?
En modifiant le source.list et en cherchant les packages stable, ça fonctionne beaucoup mieux.
En effet, il faut avoir une curieuse conception du débat et de la liberté d'expression pour moinsser un commentaire sans connotation mauvaise (ie méchante, raciste, etc.). Mais qui sont ils pour vouloir priver les autres des commentaires que eux ont pu lire ? C'est d'autant plus intrigant sur un site qui se veut un relais du logiciel _libre_
<<et pendant ce temps, (pratiquement) aucun hébergeur n'est encore passé en apache2...>>
Il faut savoir qu'il n'y a pas que Apache lui même qui est important, mais également les modules chargés. Un exemple concret :
les auteurs de mod_php ont longtemps déconseillé l'utilisation de Apache en version 2 car le multithreading pouvait poser des problèmes (contrairement à apache 1.x qui utilisait le fork). Les problèmes en questions ne viennent pas forcément du module mod_php lui même, mais plutôt des dll qui peuvent être chargés par lui, et qui n'ont pas forcément été compilées avec des options compatibles avec une utilisation en multithread.
Je ne connais pas le statut de ceci car je n'utilise pas Apache comme peuvent le faire les hébergeurs, mais c'est un argument fort et important. Jeter la pierre trop vite il ne faut pas ...
<<mais s'accélère proportionellement à la force des contributions>>
Au contraire, il faut éspérer qu'il ne dépende pas de la force des contributions vu qu'il ne peut pas y en avoir (code fermé !).
Ca fait un peu peur ce que tu dis, car on peut voir la situation ainsi:
- c'est une techno très avancée
- mais c'est un compilo tellement compliqué que quasiment personne ne peut apporter de contributions interressantes
- et le principal contributeur n'est même pas sûr de pouvoir continuer à travailler dessus ( et si celui ci, dont je ne doute ni de la qualité ni de l'intégrité, n'arrive jamais, vous faites quoi ? ).
Ca fait froid dans le dos, et surtout ça *exclu* toute utilisation dans un monde industriel, sachant qu'il n'existe a priori pas d'autres compilateurs pour ce langage. De plus, tu dis toi même que << La licence actuelle permet au moins à quiconque de l'utiliser librement à condition de ne pas utiliser le compilateur pour produire un code à des fins commerciales.>>.
Si je n'ai pas le droit de l'utiliser au boulot, je ne pourrai pas justifier quelques heures (de travail) pour évaluer cet outil puisque, en l'état, je n'aurrai pas le droit de m'en servir par la suite !
<< 1/Je n'imagine pas Dominique Colnet arrêter son bébé : la question est quelque peu étonnante.>>
Alors je m'explique:
- c'est dans le même labo
- ça utilise quand même plus ou moins les mêmes concepts, sauf que Lisaac va encore plus loin que Eiffel
- c'est utilisé pour une techno que l'INRIA espère faire fructifier
- les utilisateurs de Eiffel/SmartEiffel ne courrent pas les rues, d'ailleurs il me semble que même son enseignement à l'école attenante (l'ésial) a été remplacé presque totalement par le java
- à la vue du point précédent, je ne vois pas ce qu'espère l'INRIA avec le compilo SmartEiffel alors qu'il y a des perspectives pour Lisaac,
Avoue que pour qq1 qui voit ça de l'exterieur, on peut se demander pourquoi ne pas reporter les efforts consacrés au compilateur SmartEiffel sur le compilateur Lisaac, puisqu'il reste du travail à faire.
D'un point de vue budgétaire, ça parait plus logique.
D'un point de vue recherche, à moins que des points particuliers ne puissent pas être explorés avec Lisaac mais avec SmartEiffel, quel est l'interêt de SmartEiffel ?
Que D. Colnet veuille continuer son travail sur son 'bébé', je comprends, mais comment justifier le financement de ce travail ?
Note que je n'ai rien contre le fait de protéger un tant soit peu ses technos, mais quand ça vient du monde 'propriétaire', on s'étrangle, y compris qand il s'agit de techniques de compilation: cf les brevets qui empechent l'intégration de certaines techniques dans gcc 4.0, comme évoqué ici: http://linuxfr.org/comments/565456.html#565456
On peut donc s'étonner de voir ta dépêche ailleurs que dans un journal, même si elle n'en reste pas moins interessante car elle nous apprend l'existence de la techno.
Note qu'ici c'est normal puisque le compilateur produit du code C ! C'est ce qu'ils font aussi avec SmartEiffel. Et c'est très pratique car du coup, ton code peut être utilisé sur toute plateforme avec un compilo C, autant dire quasiment toutes les plateformes existantes.
Mais à propos des performances, une question:
Je constate que comme Eiffel, Lisaac est un langage à contrats. J'image que ici encore on doit pouvoir 'débrayer' les évaluations des contrats. Si oui, les performances annoncées ont elles été obtenues avec vérification de tous les contrats ? Une partie seulement ? Pas de contrats du tout ?
Enfin une autre question: de quelles optimisations impossibles à faire en C parles tu ?
Je vais me faire l'avocat du diable, mais pourquoi publier ici la sortie d'un logiciel non libre et à code sous fermé ? Un journal n'aurait-il pas suffit ? Ca sort de l'INRIA et ça suffit ? Ca serait sortit de chez Microsoft que tout le monde aurait hurlé ...
Quitte à poster un commentaire, j'en profite quand même pour poser des questions sur ce langage.
1. Si ce langage est franchement mieux que Eiffel (langage que j'apprécie beaucoup) , pourquoi D. Colnet continue-t-il le développement du compilateur SmartEiffel? Et ce d'autant que la lecture de la ML semble révéler quelques tensions entre les devs (certains sont à l'INRIA et les autres sont bénévoles) et les utilisateurs, qui ne semblent pas se bousculer au portillon. Quel intêret reste-il à Eiffel si Lisaac permet de faire tout ce que permet de faire Eiffel, et plus encore ?
2. C'est une avancée par rapport à SmartEiffel qui se borne à une analyse syntaxique du code.
T'es sûr de toi . C'est en contradiction avec ce qui est dit sur http://smarteiffel.loria.fr/papers/papers.html
De toute façon, un compilateur ne peut pas se borner à de l'analyse syntaxique, il faut au moins un peu d'analyse sémantique . J'ai raté qqchose ?
3. <<il a été conçu au sein du laboratoire où a été écrit GNU/SmartEiffel>>
[Note: je ne mets pas en doute *ton* interêt pour l'open source.]
Il y a bien SmartEiffel, qui est à la fois un langage et un compilateur [1], et qui est présenté comme "the GNU Eiffel Compiler", mais GNU/SmartEiffel n'existe pas. Mais est-ce une simple confusion ? Je commence en effet à me poser des questions sur l'utilisation de l'Open Source dans ce labo :
- certains fichiers livrés avec le compilateur SmartEiffel ne contiennent même pas le nom de leur auteur, mais le copyright du 'noyau dur des developpeurs'.
- on nous parle de RMS pour un projet qui est pour le moment tout ce qu'il y a de plus fermé. J'aimerais comprendre ...
[1] Eiffel est un fabuleux langage qui n'a malheureusement jamais été normalisé (une version qui nous vient de Mars vient de l'être à l'ECMA, mais personne ne l'implémente), et chaque compilateur utilise son propre jargon du langage. Et depuis un an, c'est de pire en pire.
cf http://en.wikipedia.org/wiki/Eiffel_programming_language#Spe(...)
Heu tu peux donner des examples?
il y en a pas mal des exemples. Pour en citer 2:
(1) ya pas mal de matos télécom par exemple dont les drivers n'existent encore que pour les noyaux 2.4, parce que c'est un peu plus compliqué (et donc plus long *et* couteux) de réécrire pour des noyaux 2.6.
(2) Si tu prends presque n'importe quel package de ta distib d'il y a 2 ans, essaye de voir si tu peux l'installer aujourd'hui. Bah non parce que y'a plus aucune dépendance qui est satisfaite ! A commencer par la libc, la libstdc++ et la libpthread ( merci les export LD_ASSUME_KERNEL degeu). Donc soit les créateurs de packages sont des truffes (et font ça pour pourrir la vie des utilisateurs?), soit les interfaces ont changé.
Car write n'a pas de pas de manuel autrement, j'ai du tapper dans la section 2 des manuels.
Farce ? au contraire, si tu dois faire 'man 2 write', c'est justement parce que généralement il y a aussi un 'write' dans la section 1 des pages de manuel. La commande man parcours l'ensemble des pages de manuel section par section, et séléctionne la première page qui correspond.
Dans le même genre:
$ man printf -> manuel de printf du shell
$ man 3 printf -> manuel de printf du langage C
pour t'en convaincre, et si c'est installé sur ta machine: xman, qui est une GUI au pages de manuel.
Même si c'est du vent, il n'empêche que cela a le mérite de faire poser des questions.
Par exemple, qu'il existe ou qu'il n'existe pas, le langague Sing# dont il est question semble vraiment attrayant, et rien d'utilisable ne s'en rapproche vraiment aujourd'hui. On peut penser à Eiffel et sa programmation par contrats, mais c'est plus le nom d'un principe que d'un langage (chaque compilateur a son propre dialecte, et la seule version normalisée récemment à l'ECMA n'a même pas d'implémentation).
Ensuite, qu'il y ait implémentation ou pas, il y a quand même des publications qui sortent de ces labos et qui sont accessibles à tous ; ce n'est donc pas du vent. Ce n'est pas forcément parce que c'est microsoft que c'est mal.
[^] # Re: ...
Posté par left . En réponse au journal LDLC : retour de baton. Évalué à 10.
<<Plutôt sévère après six ans d'expérience, le bilan du spécialiste du commerce électronique de matériel informatique LDLC sur l'open source est sans appel. La société fait table rase de son existant et adopte à cette occasion la plate-forme Windows de Microsoft afin de gagner en réactivité, en indépendance et en coûts.>>
Alors oui, ça fait marrer parce que pour leur indépendance, les faits montrent qu'il s n'en ont aucune (c'est pas notre faute c'est Siemens ...), en la réactivité elle a plus été chez les clients (qui se sont barrés) que chez eux.
Quand on ne veut pas faire les choses simplement mais qu'on veut faire de la propagande et qu'on se prends les pieds dans le tapis, on passe forcément au bétisier de la fin de l'année et on est ridicule.
[^] # Re: s/testing/stable/
Posté par left . En réponse au message installation sarge qui foire (netinstall). Évalué à 2.
# s/testing/stable/
Posté par left . En réponse au message installation sarge qui foire (netinstall). Évalué à 2.
En modifiant le source.list et en cherchant les packages stable, ça fonctionne beaucoup mieux.
[^] # Re: Effet pervers du support non-officiel ?
Posté par left . En réponse au journal Drivers AirPort Extreme.. Évalué à 4.
[^] # Re: Bravo
Posté par left . En réponse à la dépêche Sortie de Apache 2.2.0. Évalué à 5.
Il faut savoir qu'il n'y a pas que Apache lui même qui est important, mais également les modules chargés. Un exemple concret :
les auteurs de mod_php ont longtemps déconseillé l'utilisation de Apache en version 2 car le multithreading pouvait poser des problèmes (contrairement à apache 1.x qui utilisait le fork). Les problèmes en questions ne viennent pas forcément du module mod_php lui même, mais plutôt des dll qui peuvent être chargés par lui, et qui n'ont pas forcément été compilées avec des options compatibles avec une utilisation en multithread.
Je ne connais pas le statut de ceci car je n'utilise pas Apache comme peuvent le faire les hébergeurs, mais c'est un argument fort et important. Jeter la pierre trop vite il ne faut pas ...
[^] # Re: Isaac ?
Posté par left . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 1.
Au contraire, il faut éspérer qu'il ne dépende pas de la force des contributions vu qu'il ne peut pas y en avoir (code fermé !).
[^] # Re: Protection par l'obscurantisme
Posté par left . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 3.
- c'est une techno très avancée
- mais c'est un compilo tellement compliqué que quasiment personne ne peut apporter de contributions interressantes
- et le principal contributeur n'est même pas sûr de pouvoir continuer à travailler dessus ( et si celui ci, dont je ne doute ni de la qualité ni de l'intégrité, n'arrive jamais, vous faites quoi ? ).
Ca fait froid dans le dos, et surtout ça *exclu* toute utilisation dans un monde industriel, sachant qu'il n'existe a priori pas d'autres compilateurs pour ce langage. De plus, tu dis toi même que << La licence actuelle permet au moins à quiconque de l'utiliser librement à condition de ne pas utiliser le compilateur pour produire un code à des fins commerciales.>>.
Si je n'ai pas le droit de l'utiliser au boulot, je ne pourrai pas justifier quelques heures (de travail) pour évaluer cet outil puisque, en l'état, je n'aurrai pas le droit de m'en servir par la suite !
Vous ésperez quoi, en fait ?
[^] # Re: licence ?
Posté par left . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 2.
Alors je m'explique:
- c'est dans le même labo
- ça utilise quand même plus ou moins les mêmes concepts, sauf que Lisaac va encore plus loin que Eiffel
- c'est utilisé pour une techno que l'INRIA espère faire fructifier
- les utilisateurs de Eiffel/SmartEiffel ne courrent pas les rues, d'ailleurs il me semble que même son enseignement à l'école attenante (l'ésial) a été remplacé presque totalement par le java
- à la vue du point précédent, je ne vois pas ce qu'espère l'INRIA avec le compilo SmartEiffel alors qu'il y a des perspectives pour Lisaac,
Avoue que pour qq1 qui voit ça de l'exterieur, on peut se demander pourquoi ne pas reporter les efforts consacrés au compilateur SmartEiffel sur le compilateur Lisaac, puisqu'il reste du travail à faire.
D'un point de vue budgétaire, ça parait plus logique.
D'un point de vue recherche, à moins que des points particuliers ne puissent pas être explorés avec Lisaac mais avec SmartEiffel, quel est l'interêt de SmartEiffel ?
Que D. Colnet veuille continuer son travail sur son 'bébé', je comprends, mais comment justifier le financement de ce travail ?
<<J'ai déjà dit ce qu'il y a dire sur l'INRIA>>
pour ceux qui n'ont pas suivi: https://linuxfr.org/comments/651950.html#651950 et https://linuxfr.org/comments/652076.html#652076
Note que je n'ai rien contre le fait de protéger un tant soit peu ses technos, mais quand ça vient du monde 'propriétaire', on s'étrangle, y compris qand il s'agit de techniques de compilation: cf les brevets qui empechent l'intégration de certaines techniques dans gcc 4.0, comme évoqué ici: http://linuxfr.org/comments/565456.html#565456
On peut donc s'étonner de voir ta dépêche ailleurs que dans un journal, même si elle n'en reste pas moins interessante car elle nous apprend l'existence de la techno.
[^] # Re: Benchmarks
Posté par left . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 5.
Mais à propos des performances, une question:
Je constate que comme Eiffel, Lisaac est un langage à contrats. J'image que ici encore on doit pouvoir 'débrayer' les évaluations des contrats. Si oui, les performances annoncées ont elles été obtenues avec vérification de tous les contrats ? Une partie seulement ? Pas de contrats du tout ?
Enfin une autre question: de quelles optimisations impossibles à faire en C parles tu ?
# licence ?
Posté par left . En réponse à la dépêche Lisaac 0.84 est sorti. Évalué à 10.
Quitte à poster un commentaire, j'en profite quand même pour poser des questions sur ce langage.
1. Si ce langage est franchement mieux que Eiffel (langage que j'apprécie beaucoup) , pourquoi D. Colnet continue-t-il le développement du compilateur SmartEiffel? Et ce d'autant que la lecture de la ML semble révéler quelques tensions entre les devs (certains sont à l'INRIA et les autres sont bénévoles) et les utilisateurs, qui ne semblent pas se bousculer au portillon. Quel intêret reste-il à Eiffel si Lisaac permet de faire tout ce que permet de faire Eiffel, et plus encore ?
2. C'est une avancée par rapport à SmartEiffel qui se borne à une analyse syntaxique du code.
T'es sûr de toi . C'est en contradiction avec ce qui est dit sur http://smarteiffel.loria.fr/papers/papers.html
De toute façon, un compilateur ne peut pas se borner à de l'analyse syntaxique, il faut au moins un peu d'analyse sémantique . J'ai raté qqchose ?
3. <<il a été conçu au sein du laboratoire où a été écrit GNU/SmartEiffel>>
[Note: je ne mets pas en doute *ton* interêt pour l'open source.]
Il y a bien SmartEiffel, qui est à la fois un langage et un compilateur [1], et qui est présenté comme "the GNU Eiffel Compiler", mais GNU/SmartEiffel n'existe pas. Mais est-ce une simple confusion ? Je commence en effet à me poser des questions sur l'utilisation de l'Open Source dans ce labo :
- certains fichiers livrés avec le compilateur SmartEiffel ne contiennent même pas le nom de leur auteur, mais le copyright du 'noyau dur des developpeurs'.
- on nous parle de RMS pour un projet qui est pour le moment tout ce qu'il y a de plus fermé. J'aimerais comprendre ...
[1] Eiffel est un fabuleux langage qui n'a malheureusement jamais été normalisé (une version qui nous vient de Mars vient de l'être à l'ECMA, mais personne ne l'implémente), et chaque compilateur utilise son propre jargon du langage. Et depuis un an, c'est de pire en pire.
cf http://en.wikipedia.org/wiki/Eiffel_programming_language#Spe(...)
[^] # Re: ...
Posté par left . En réponse à la dépêche TomTom, fabricant de GPS, contribue au libre. Évalué à 5.
il y en a pas mal des exemples. Pour en citer 2:
(1) ya pas mal de matos télécom par exemple dont les drivers n'existent encore que pour les noyaux 2.4, parce que c'est un peu plus compliqué (et donc plus long *et* couteux) de réécrire pour des noyaux 2.6.
(2) Si tu prends presque n'importe quel package de ta distib d'il y a 2 ans, essaye de voir si tu peux l'installer aujourd'hui. Bah non parce que y'a plus aucune dépendance qui est satisfaite ! A commencer par la libc, la libstdc++ et la libpthread ( merci les export LD_ASSUME_KERNEL degeu). Donc soit les créateurs de packages sont des truffes (et font ça pour pourrir la vie des utilisateurs?), soit les interfaces ont changé.
[^] # Re: man
Posté par left . En réponse au message fwrite vs write. Évalué à 3.
Farce ? au contraire, si tu dois faire 'man 2 write', c'est justement parce que généralement il y a aussi un 'write' dans la section 1 des pages de manuel. La commande man parcours l'ensemble des pages de manuel section par section, et séléctionne la première page qui correspond.
Dans le même genre:
$ man printf -> manuel de printf du shell
$ man 3 printf -> manuel de printf du langage C
pour t'en convaincre, et si c'est installé sur ta machine: xman, qui est une GUI au pages de manuel.
[^] # Re: Troll
Posté par left . En réponse au journal Singularity - OS. Évalué à 1.
[^] # Re: Ne pas oublier...
Posté par left . En réponse au journal Singularity - OS. Évalué à 5.
Par exemple, qu'il existe ou qu'il n'existe pas, le langague Sing# dont il est question semble vraiment attrayant, et rien d'utilisable ne s'en rapproche vraiment aujourd'hui. On peut penser à Eiffel et sa programmation par contrats, mais c'est plus le nom d'un principe que d'un langage (chaque compilateur a son propre dialecte, et la seule version normalisée récemment à l'ECMA n'a même pas d'implémentation).
Ensuite, qu'il y ait implémentation ou pas, il y a quand même des publications qui sortent de ces labos et qui sont accessibles à tous ; ce n'est donc pas du vent. Ce n'est pas forcément parce que c'est microsoft que c'est mal.