Qqes autres commentaires, comme j'ai la chance d'être à SC|07 en ce moment ;)
Tout le monde s'intéresse de plus en plus au problème de la consommation électrique de ces beaux jouets. Mais la principale question et de trouver une manière fiable de la mesurer et de la comparer. Il faut une métrique qui veut dire qqchose : on ne peut évidemment pas simplement faire "puissance de calcul/puissance consommée" et trier les clusters comme ça ;)
Amusant: la NSA (dont les machines ne figurent pas dans le Top500, quel manque de transparence!) sature le réseau électrique de baltimore, et provoque des coupures de courant.
On devrait atteindre le petaflop l'année prochaine, avec une machine de Cray installée dans le Oak Ridge National Laboratory.
Grid'5000 est unique, comme plateforme pour des expériences en informatique. Il faut bien voir que la très grande majorité des machines du top500 sont utilisées pour des simulations en physique, biologie, etc, et que les informaticiens n'y ont en général pas accès, ou alors d'une manière extrèmement limitée, car leurs labos n'ont pas assez de sous pour leur payer les droits d'accès.
Ensuite, Grid'5000 est un ensemble de clusters, pas un cluster unique. Si on fait la somme de la puissance des clusters de Grid'5000 (ie: on prend tous les clusters de grid5000, et on les met dans la meme piece), on arrive à une machine qui rentrerait dans le top500: la derniere machine est un cluster de 1344 processeurs, alors que Grid'5000 a au total plus de 3000 processeurs.
Après, l'un des paramètres importants pour bien figurer avec le benchmark utilisé (LINPACK) est la latence. Or, avec une grosse dizaine de millisecondes entre Lille et Sophia-Antipolis, on est assez loin des perfs d'un réseau Infiniband. :)
> Par contre il semblerait qu'il y ait un problème avec ce paquet (bug #447053):
> le programme ario se bloque dès le début de l'exécution.
je peux reproduire le probleme dans un chroot sid. par contre, sur lenny, pas de problemes (en rebuildant le paquet). Donc c'est probablement un probleme lié à gtk 2.12. Fais toi un chroot sid pour tester :-)
> Je pense que je m'occuperai moi même d'Ubuntu une fois que le paquet Debian
> fonctionnera correctement.
Inutile, Ubuntu importe automatiquement tous les paquets de Debian.
Smolt, c'est bien pour receuillir des infos sur le pourcentage d'utilisateurs qui ont un matériel particulier. Mais ça ne te dit rien sur le nombre total d'utilisateurs, comme la participation est facultative et que tu ne sais pas quel pourcentage d'utilisateurs partipe.
Debian et Ubuntu ont un "popularity contest" qui permet de savoir quels sont les paquets les plus utilisés (respectivement sur http://popcon.debian.org et http://popcon.ubuntu.com ). Il y a 223000 participants sur popcon.u.c, contre 67000 sur popcon.d.o. Le problème, c'est qu'il me semble que la participation est activée par défaut sur Ubuntu, mais pas sur Debian (enfin il faudrait vérifier). Et puis même: on peut penser qu'il y a plus (en proportion) d'utilisateurs que ça ne dérangera pas d'activer un truc pas très utile sur Ubuntu que sur Debian.
> Après avoir suivi avec attention et impatience les courbes en attendant la
> sortie de debian Etch, je suis revenu sur cette page presque par hasard en
> faisant du ménage dans mes bookmarks :
> http://bugs.debian.org/release-critical/
Si tu suis ces courbes, tu apprécieras peut-etre ces versions là: http://qa.debian.org/~lucas/dograph/
graph-6m.png : courbe sur les 6 derniers mois
graph-2y.png : courbe sur les 2 dernieres années
graph-all.png : courbe depuis qu'elle existe, comme sur bugs.d.o/release-critical/
Le Bug Tracking System de Debian utilise une feature unique à ma connaissance: la possibilité de dire à quelles versions d'un paquet s'appliquent un bug.
Cela permet par exemple de dire que le bug #422476 a été trouvé dans la version 1.2.0-2 de openscenegraph, et qu'il a été corrigé dans les versions 1.2.0-4 d'un coté (version uploadée dans unstable), et 1.9.1-1 de l'autre (version uploadée dans experimental). Ce systeme lit les changelogs pour savoir sur quelle version une version est basée: on a donc un arbre généalogique du paquet.
Voir: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422476
et pour le joli dessin: http://bugs.debian.org/cgi-bin/version.cgi?package=openscene(...)
Du coup, c'est merveilleux: on peut savoir quels sont les bugs qui s'appliquent à la version stable de Debian: c'est tous les bugs qui ont été trouvés dans les versions présentes dans stable.
Oui, mais ... souvent, un bug n'est pas causé uniquement par un paquet, mais par un ensemble de paquets (ou par un changement dans un autre paquet). Prenons par exemple le bug #427463. Il a été trouvé dans la version 0.5-2 de libhpricot-ruby. Cette version est dans etch. Mais il est causé par un changement dans une de ses dépendances (ici ruby1.8 ou ruby1.9, je ne suis pas sûr) qui a eu lieu après la sortie de etch. Donc il est comptabilisé dans la liste des bugs critiques pour etch, mais il n'est pas présent dans etch.
La solution est de marquer ces bugs là avec les tags "sid" et "lenny", pour indiquer que le problème n'est pas présent dans etch. Mais c'est assez fastidieux, et peu utile, donc rarement fait.
> et pour gimp, si cela fonctionnait toujours, mais c'est bizarre de mettre à jour
> juste une partie du logiciel et pas le reste non ? La mise à jour devrait se faire
> pour l'ensemble de la version.
Pas forcément: si tu veux juste mettre à jour un paquet, il va faire le travail minimum pour te permettre de mettre ce paquet à jour.
> En fait je pense que si cela n'avait pas du tout compilé pour i386, le paquet
> pour 2.12 n'aurait pas du tout sorti, là cela ne passe que pour i386 et pas
> pour les autres mais la mise à jour s'est quand même faite sur les dépôts pour
> l'ensemble des architectures.
Non, car evolution-common est un paquet architecture: all, donc pas compilé sur chaque architecture. Mais encore une fois, vu les dépendances, je ne vois pas comment tu t'es débrouillé, car pour installer evolution-common 2.12, il faut forcément désinstaller evolution 2.10...
> Par contre je vais installer apt-listbugs, j'ai vu qu'ici certains conseillaient
> la sid avec ce paquet qui peut prévenir en cas de risque de casse...
Si le problème que tu rencontres n'a pas encore été signalé, ca ne va rien changer...
> même ici par exemple ils ne semblent pas conseiller testing :
on ne t'a jamais dit de ne pas croire tout ce que tu lis sur le net ? :-)
Comme dit plus haut, si tu ne sais pas résoudre ce genre de problèmes, il vaut mieux utiliser testing et de l'apt pinning pour récupérer dans unstable les versions de softs que tu veux absolument.
> Or, il y a quelques jours, en faisant la mise à jour, j'ai remarqué que
> quelque chose de bizarre s'était passé
Oui, le maintaineur d'evolution n'a pas mis une "build-dependancy" suffisamment stricte, du coup evolution ne compile pas sur la plupart des architectures. Cf http://packages.qa.debian.org/e/evolution.html
> c'est quel est l'intérêt de passer une dépendance critique comme
> evolution-data-server en 2.12 sur amd64
je ne vois pas où tu as vu cette dépendance. Chez moi, evolution dépend sur e-d-s >= 1.9.4.
> Pourquoi ne pas bloquer tout ce qui correspond à evolution à la 2.10 pour
> les architectures autres que i386 ?
Parce que pour savoir que ca ne marche pas ailleurs que sur i386, il faut bien essayer. Et que l'objectif d'une version de développement, c'est d'aller vers l'avant, parfois en cassant puis réparant des trucs.
> Pourquoi ne pas avoir laissé les paquets de 2.10 dans les bases de
> téléchargement si la nouvelle version est cassée ?
Car un paquet source ne peut exister qu'en une seule version dans une suite (stable, testing, unstable) donnée. C'est déjà assez compliqué comme ça.
> Sinon savez-vous s'il est possible de vraiment revenir facilement à la
> version précédente en attendant ?
Oui, rajoute les sources pour testing, puis:
apt-get install evolution/testing evolution-data-server/testing (+ les autres paquets que tu veux downgrader).
Attention, cette manip n'est pas supposée être supportée.
> Je présume que c'est pour gagner de la place sur les serveurs vis à vis des
> architectures moins courantes, ce qui peut être une bonne chose, mais il
> faudrait trouver un solution lorsque c'est cassé.
C'est juste que le paquet n'a pas pû être compilé sur une architecture. Si tu mets à jour à coups de apt-get upgrade (et pas de apt-get dist-upgrade), normalement, tu vas attendre sagement que le paquet soit disponible. Je ne comprends pas bien comment tu as réussi à te mettre dans cette situation.
> De plus, c'est très souvent que si on demande la mise à jour du meta
> paquet (genre wine, gimp etc), les dépendances nécessaires ne sont pas
> mises à jour automatiquement, il faut le faire à la main.
C'est parce que tu ne demandes pas la mise à jour d'un paquet, mais l'installation de la nouvelle version d'un paquet. Si les paquets actuellement installés sont suffisants pour satisfaire les dépendances déclarées par le paquet, pourquoi les mettre à jour ?
Après, si les dépendances déclarées par le paquet sont fausses, c'est un bug. As-tu un exemple où tu as installé une nouvelle version de gimp, où il n'a pas installé de nouvelle version de libgimp2.0, et où après, gimp ne fonctionnait plus ?
> C'est la première fois où j'ai un tel problème avec Sid
T'as eu de la chance jusqu'à maintenant :-) Comme je le disais: testing + apt pinning sont tes amis.
D'un autre côté, si j'ai bien compris, le compilo est sous GPLv3 également. Et pas sûr qu'il ait une exception sur ce qu'il génère (cf mon commentaire/question un peu plus haut).
En fait, je ne suis même pas sûr que la qualité intrinsèque du langage compte tant que ça.
Regarde PHP, beaucoup de monde sait programmer en PHP, alors que c'est un langage qui a toujours été en retard sur beaucoup de concepts, et que presque personne de "cultivé" ne peut trouver "beau".
Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.
Attention: je ne remets pas en cause l'intérêt pour la recherche et l'innovation de Lisaac. Je trouve juste votre manière de communiquer un peu curieuse. Comme je l'ai dit plus haut, il y a des dizaines de langages de recherche, tous très innovants dans un domaine particulier. Et il y a aussi des centaines de projets de recherche très innovants qui ne sont pas des langages. :-) Pourtant, il n'y a que sur Lisaac qu'on a régulièrement des dépêches DLFP. Bon, on m'a dit que si une dépêche est bien rédigée en français, et parle de libre, pas de problème pour la passer en première page. OK. J'en prends note.
Maintenant, des questions constructives:
Sur Wikipédia, Lisaac est mis à côté de langages qui ont été utilisés pour des centaines de softs. Peux-tu donner quelques exemples de logiciels écrits en Lisaac ?
Il y a un problème courant de licence avec les compilateurs. Puisqu'en général, ils recopient une partie de leur code dans les fichiers générés, il faut utiliser une exception pour que les fichiers générés ne soient pas soumises à la même licence. C'est le cas de GCC ou de flex: GCC est sous GPL, mais cela n'a pas d'incidence sur les programmes compilés avec GCC. Est-ce qu'une exception similaire est présente dans Lisaac ? Ce qui permettrait à qqun de réimplémenter la bibliothèque (qui elle, est sous GPL, c'est sûr) sous une autre licence ?
A chaque fois qu'une dépeche sur Lissac passe sur DLFP, je me demande ce qu'elle fait là. Alors cette fois-ci, j'exprime mes doutes.
Il me semble que Lissac est juste un language de recherche parmi énormément d'autres. Je ne remets pas en doute son côté innovant, mais pourquoi publier cette dépêche sur DLFP ? Surtout en première page ? Est-ce que ça veut dire que tous les projets de recherche publiés sous licence libre vont avoir droit à une dépêche de premiere page sur DLFP ?
De plus, qui est cet "Ontologia", dont la page perso est celle du projet Isaac ? Quelle est sa relation avec Benjamin Sonntag et avec les modérateurs de DLFP ? A noter que la page Wikipédia de Lisaac[1] est également écrite par lui, et qu'elle provoque également des interrogations[2,3].
D'un autre côté, il souhaite identifier "blabla" et "plop". Je vois pas trop l'intérêt d'utiliser des expressions régulières pour ça. Meme (bla){2,2} ca utilise plus de caractères que "blabla"...
Y a une date limite connue pour les réservations des chambres ?
Parce que bon, le programme a l'air d'être bourré de confs pour spécialistes, sans qu'il y ait assez de choses qui m'intéressent pour aller perdre 5 jours aux RMLL ...
Il suffirait d'empécher les paquets de migrer vers Testing.
c'est le cas. Les paquets ont besoin d'une autorisation des release managers pour passer de unstable à testing.
Parceque pendant ce temps, les paquets qui pourraient être dans Unstable seraient utilisés et donc débogués.
Il y aura tout le temps pour ça après la sortie de etch. En attendant, si les versions dans unstable et testing sont les mêmes, ca permet aux utilisateurs d'unstable de trouver des bugs qui s'appliquent aussi à testing, et qui pourront donc etre corrigés dans etch.
Ca va faire un sacré bazard lors de la sortie de Etch tous ces nouveaux paquets (depuis le temps que c'est freezé) dans Unstable.
Oui, c'est pour ça que ça s'appelle Unstable, d'ailleurs.
Il y a un truc que je n'ai pas saisi: pourquoi Unstable est freezée elle aussi ?
Elle n'est pas freezée, mais il est demandé de ne pas uploader dans unstable des versions qui ne sont pas destinées à aller dans testing. Sinon, si la version dans testing a besoin d'être mise à jour, c'est la merde.
Number concerning the next release (excluding ignored and not-in-testing): 68
Cette version là de "bugscan" ne comprend pas le "version-tracking", qui permet d'indiquer dans le bug tracking system qu'un bug est présent/résolu (ou pas) dans une certaine version d'un paquet. Du coup, des bugs présents seulement dans unstable sont comptés.
Et puis de toute facon, on ne peut pas regarder que le nombre. Certains bugs concernent des paquets vraiment peu importants qui pourraient être supprimés, d'autres sont en passe d'être résolus, et enfin, certains ne méritent peut-etre pas d'être considérés comme des bugs RC...
# autres commentaires
Posté par Lucas . En réponse à la dépêche Le Top500 nouveau est arrivé. Évalué à 4.
Tout le monde s'intéresse de plus en plus au problème de la consommation électrique de ces beaux jouets. Mais la principale question et de trouver une manière fiable de la mesurer et de la comparer. Il faut une métrique qui veut dire qqchose : on ne peut évidemment pas simplement faire "puissance de calcul/puissance consommée" et trier les clusters comme ça ;)
Amusant: la NSA (dont les machines ne figurent pas dans le Top500, quel manque de transparence!) sature le réseau électrique de baltimore, et provoque des coupures de courant.
On devrait atteindre le petaflop l'année prochaine, avec une machine de Cray installée dans le Oak Ridge National Laboratory.
[^] # Re: <mode humour/>
Posté par Lucas . En réponse à la dépêche Le Top500 nouveau est arrivé. Évalué à 4.
Grid'5000 est unique, comme plateforme pour des expériences en informatique. Il faut bien voir que la très grande majorité des machines du top500 sont utilisées pour des simulations en physique, biologie, etc, et que les informaticiens n'y ont en général pas accès, ou alors d'une manière extrèmement limitée, car leurs labos n'ont pas assez de sous pour leur payer les droits d'accès.
Ensuite, Grid'5000 est un ensemble de clusters, pas un cluster unique. Si on fait la somme de la puissance des clusters de Grid'5000 (ie: on prend tous les clusters de grid5000, et on les met dans la meme piece), on arrive à une machine qui rentrerait dans le top500: la derniere machine est un cluster de 1344 processeurs, alors que Grid'5000 a au total plus de 3000 processeurs.
Après, l'un des paramètres importants pour bien figurer avec le benchmark utilisé (LINPACK) est la latence. Or, avec une grosse dizaine de millisecondes entre Lille et Sophia-Antipolis, on est assez loin des perfs d'un réseau Infiniband. :)
# bug #447053
Posté par Lucas . En réponse au journal Ario 0.2 is out. Évalué à 4.
> le programme ario se bloque dès le début de l'exécution.
je peux reproduire le probleme dans un chroot sid. par contre, sur lenny, pas de problemes (en rebuildant le paquet). Donc c'est probablement un probleme lié à gtk 2.12. Fais toi un chroot sid pour tester :-)
> Je pense que je m'occuperai moi même d'Ubuntu une fois que le paquet Debian
> fonctionnera correctement.
Inutile, Ubuntu importe automatiquement tous les paquets de Debian.
[^] # Re: mouais
Posté par Lucas . En réponse au journal De l'importance d'avoir des statisques fiables. Évalué à 2.
# mouais
Posté par Lucas . En réponse au journal De l'importance d'avoir des statisques fiables. Évalué à 2.
Debian et Ubuntu ont un "popularity contest" qui permet de savoir quels sont les paquets les plus utilisés (respectivement sur http://popcon.debian.org et http://popcon.ubuntu.com ). Il y a 223000 participants sur popcon.u.c, contre 67000 sur popcon.d.o. Le problème, c'est qu'il me semble que la participation est activée par défaut sur Ubuntu, mais pas sur Debian (enfin il faudrait vérifier). Et puis même: on peut penser qu'il y a plus (en proportion) d'utilisateurs que ça ne dérangera pas d'activer un truc pas très utile sur Ubuntu que sur Debian.
# courbes plus lisibles
Posté par Lucas . En réponse au journal It's ready when it's ready, hum..... Évalué à 5.
> sortie de debian Etch, je suis revenu sur cette page presque par hasard en
> faisant du ménage dans mes bookmarks :
> http://bugs.debian.org/release-critical/
Si tu suis ces courbes, tu apprécieras peut-etre ces versions là:
http://qa.debian.org/~lucas/dograph/
graph-6m.png : courbe sur les 6 derniers mois
graph-2y.png : courbe sur les 2 dernieres années
graph-all.png : courbe depuis qu'elle existe, comme sur bugs.d.o/release-critical/
# c'est normal.
Posté par Lucas . En réponse au journal It's ready when it's ready, hum..... Évalué à 10.
Cela permet par exemple de dire que le bug #422476 a été trouvé dans la version 1.2.0-2 de openscenegraph, et qu'il a été corrigé dans les versions 1.2.0-4 d'un coté (version uploadée dans unstable), et 1.9.1-1 de l'autre (version uploadée dans experimental). Ce systeme lit les changelogs pour savoir sur quelle version une version est basée: on a donc un arbre généalogique du paquet.
Voir:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422476
et pour le joli dessin:
http://bugs.debian.org/cgi-bin/version.cgi?package=openscene(...)
Du coup, c'est merveilleux: on peut savoir quels sont les bugs qui s'appliquent à la version stable de Debian: c'est tous les bugs qui ont été trouvés dans les versions présentes dans stable.
Oui, mais ... souvent, un bug n'est pas causé uniquement par un paquet, mais par un ensemble de paquets (ou par un changement dans un autre paquet). Prenons par exemple le bug #427463. Il a été trouvé dans la version 0.5-2 de libhpricot-ruby. Cette version est dans etch. Mais il est causé par un changement dans une de ses dépendances (ici ruby1.8 ou ruby1.9, je ne suis pas sûr) qui a eu lieu après la sortie de etch. Donc il est comptabilisé dans la liste des bugs critiques pour etch, mais il n'est pas présent dans etch.
La solution est de marquer ces bugs là avec les tags "sid" et "lenny", pour indiquer que le problème n'est pas présent dans etch. Mais c'est assez fastidieux, et peu utile, donc rarement fait.
[^] # Re: utilise testing et de l'apt pinning ...
Posté par Lucas . En réponse au journal Evolution cassé sur AMD64, comment revenir avant ?. Évalué à 2.
> juste une partie du logiciel et pas le reste non ? La mise à jour devrait se faire
> pour l'ensemble de la version.
Pas forcément: si tu veux juste mettre à jour un paquet, il va faire le travail minimum pour te permettre de mettre ce paquet à jour.
> En fait je pense que si cela n'avait pas du tout compilé pour i386, le paquet
> pour 2.12 n'aurait pas du tout sorti, là cela ne passe que pour i386 et pas
> pour les autres mais la mise à jour s'est quand même faite sur les dépôts pour
> l'ensemble des architectures.
Non, car evolution-common est un paquet architecture: all, donc pas compilé sur chaque architecture. Mais encore une fois, vu les dépendances, je ne vois pas comment tu t'es débrouillé, car pour installer evolution-common 2.12, il faut forcément désinstaller evolution 2.10...
[^] # Re: C'est pour ça que...
Posté par Lucas . En réponse au journal Evolution cassé sur AMD64, comment revenir avant ?. Évalué à 2.
> la sid avec ce paquet qui peut prévenir en cas de risque de casse...
Si le problème que tu rencontres n'a pas encore été signalé, ca ne va rien changer...
> même ici par exemple ils ne semblent pas conseiller testing :
on ne t'a jamais dit de ne pas croire tout ce que tu lis sur le net ? :-)
# utilise testing et de l'apt pinning ...
Posté par Lucas . En réponse au journal Evolution cassé sur AMD64, comment revenir avant ?. Évalué à 6.
> Or, il y a quelques jours, en faisant la mise à jour, j'ai remarqué que
> quelque chose de bizarre s'était passé
Oui, le maintaineur d'evolution n'a pas mis une "build-dependancy" suffisamment stricte, du coup evolution ne compile pas sur la plupart des architectures. Cf http://packages.qa.debian.org/e/evolution.html
> c'est quel est l'intérêt de passer une dépendance critique comme
> evolution-data-server en 2.12 sur amd64
je ne vois pas où tu as vu cette dépendance. Chez moi, evolution dépend sur e-d-s >= 1.9.4.
> Pourquoi ne pas bloquer tout ce qui correspond à evolution à la 2.10 pour
> les architectures autres que i386 ?
Parce que pour savoir que ca ne marche pas ailleurs que sur i386, il faut bien essayer. Et que l'objectif d'une version de développement, c'est d'aller vers l'avant, parfois en cassant puis réparant des trucs.
> Pourquoi ne pas avoir laissé les paquets de 2.10 dans les bases de
> téléchargement si la nouvelle version est cassée ?
Car un paquet source ne peut exister qu'en une seule version dans une suite (stable, testing, unstable) donnée. C'est déjà assez compliqué comme ça.
> Sinon savez-vous s'il est possible de vraiment revenir facilement à la
> version précédente en attendant ?
Oui, rajoute les sources pour testing, puis:
apt-get install evolution/testing evolution-data-server/testing (+ les autres paquets que tu veux downgrader).
Attention, cette manip n'est pas supposée être supportée.
> Je présume que c'est pour gagner de la place sur les serveurs vis à vis des
> architectures moins courantes, ce qui peut être une bonne chose, mais il
> faudrait trouver un solution lorsque c'est cassé.
C'est juste que le paquet n'a pas pû être compilé sur une architecture. Si tu mets à jour à coups de apt-get upgrade (et pas de apt-get dist-upgrade), normalement, tu vas attendre sagement que le paquet soit disponible. Je ne comprends pas bien comment tu as réussi à te mettre dans cette situation.
> De plus, c'est très souvent que si on demande la mise à jour du meta
> paquet (genre wine, gimp etc), les dépendances nécessaires ne sont pas
> mises à jour automatiquement, il faut le faire à la main.
C'est parce que tu ne demandes pas la mise à jour d'un paquet, mais l'installation de la nouvelle version d'un paquet. Si les paquets actuellement installés sont suffisants pour satisfaire les dépendances déclarées par le paquet, pourquoi les mettre à jour ?
Après, si les dépendances déclarées par le paquet sont fausses, c'est un bug. As-tu un exemple où tu as installé une nouvelle version de gimp, où il n'a pas installé de nouvelle version de libgimp2.0, et où après, gimp ne fonctionnait plus ?
> C'est la première fois où j'ai un tel problème avec Sid
T'as eu de la chance jusqu'à maintenant :-) Comme je le disais: testing + apt pinning sont tes amis.
[^] # Re: Vaccination
Posté par Lucas . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
[^] # Re: Vaccination
Posté par Lucas . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
[^] # Re: sonntag
Posté par Lucas . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Regarde PHP, beaucoup de monde sait programmer en PHP, alors que c'est un langage qui a toujours été en retard sur beaucoup de concepts, et que presque personne de "cultivé" ne peut trouver "beau".
Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.
[^] # Re: Pertinence de cette dépeche ?
Posté par Lucas . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 6.
Maintenant, des questions constructives:
Sur Wikipédia, Lisaac est mis à côté de langages qui ont été utilisés pour des centaines de softs. Peux-tu donner quelques exemples de logiciels écrits en Lisaac ?
Il y a un problème courant de licence avec les compilateurs. Puisqu'en général, ils recopient une partie de leur code dans les fichiers générés, il faut utiliser une exception pour que les fichiers générés ne soient pas soumises à la même licence. C'est le cas de GCC ou de flex: GCC est sous GPL, mais cela n'a pas d'incidence sur les programmes compilés avec GCC. Est-ce qu'une exception similaire est présente dans Lisaac ? Ce qui permettrait à qqun de réimplémenter la bibliothèque (qui elle, est sous GPL, c'est sûr) sous une autre licence ?
# Pertinence de cette dépeche ?
Posté par Lucas . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à -6.
Il me semble que Lissac est juste un language de recherche parmi énormément d'autres. Je ne remets pas en doute son côté innovant, mais pourquoi publier cette dépêche sur DLFP ? Surtout en première page ? Est-ce que ça veut dire que tous les projets de recherche publiés sous licence libre vont avoir droit à une dépêche de premiere page sur DLFP ?
De plus, qui est cet "Ontologia", dont la page perso est celle du projet Isaac ? Quelle est sa relation avec Benjamin Sonntag et avec les modérateurs de DLFP ? A noter que la page Wikipédia de Lisaac[1] est également écrite par lui, et qu'elle provoque également des interrogations[2,3].
[1] http://fr.wikipedia.org/wiki/Lisaac
[2] http://fr.wikipedia.org/wiki/Discuter:Lisaac
[3] http://fr.wikipedia.org/wiki/Utilisateur:Ontologiae
[^] # Re: http://www.chezmoicamarche.com/
Posté par Lucas . En réponse au journal eurosport player sous linux ?. Évalué à 1.
[^] # Re: http://www.chezmoicamarche.com/
Posté par Lucas . En réponse au journal eurosport player sous linux ?. Évalué à 1.
[^] # Re: 5 minutes de windows n'ont jamais tué personne.
Posté par Lucas . En réponse au journal eurosport player sous linux ?. Évalué à 7.
euh ... non ?
[^] # Re: mauvaise question
Posté par Lucas . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 3.
[^] # Re: "Identifier des chaînes" = regexp
Posté par Lucas . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 1.
# mauvaise question
Posté par Lucas . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 9.
> * Sélectionner/Effacer toutes les lignes où "blabla" n'apparait pas
grep -v blabla fichier
> * L'inverse
grep blabla fichier
> * Effacer le contenu de chaque ligne après le 15ème caractère
cut -c 1-15 fichier
> * Ne garder que les lignes où "blabla" et "plop" apparaissent
grep blabla fichier | grep plop
si l'ordre est important (blabla avant plop):
grep "blabla.*plop" fichier
# date limite de réservation ?
Posté par Lucas . En réponse à la dépêche RMLL 2007 : Ouverture des inscriptions et réservations. Évalué à 3.
Parce que bon, le programme a l'air d'être bourré de confs pour spécialistes, sans qu'il y ait assez de choses qui m'intéressent pour aller perdre 5 jours aux RMLL ...
[^] # Re: Vivement qu'elle sorte !
Posté par Lucas . En réponse au journal Debian Etch RC2. Évalué à 9.
c'est le cas. Les paquets ont besoin d'une autorisation des release managers pour passer de unstable à testing.
Parceque pendant ce temps, les paquets qui pourraient être dans Unstable seraient utilisés et donc débogués.
Il y aura tout le temps pour ça après la sortie de etch. En attendant, si les versions dans unstable et testing sont les mêmes, ca permet aux utilisateurs d'unstable de trouver des bugs qui s'appliquent aussi à testing, et qui pourront donc etre corrigés dans etch.
Ca va faire un sacré bazard lors de la sortie de Etch tous ces nouveaux paquets (depuis le temps que c'est freezé) dans Unstable.
Oui, c'est pour ça que ça s'appelle Unstable, d'ailleurs.
[^] # Re: Vivement qu'elle sorte !
Posté par Lucas . En réponse au journal Debian Etch RC2. Évalué à 2.
Elle n'est pas freezée, mais il est demandé de ne pas uploader dans unstable des versions qui ne sont pas destinées à aller dans testing. Sinon, si la version dans testing a besoin d'être mise à jour, c'est la merde.
[^] # Re: et la ligne du temps...
Posté par Lucas . En réponse au journal Debian Etch RC2. Évalué à 5.
Cette version là de "bugscan" ne comprend pas le "version-tracking", qui permet d'indiquer dans le bug tracking system qu'un bug est présent/résolu (ou pas) dans une certaine version d'un paquet. Du coup, des bugs présents seulement dans unstable sont comptés.
En réalité, il vaut mieux regarder http://people.debian.org/~sesse/bugscan/ (qui donne 40 bugs RC) ou http://bts.turmzimmer.net/details.php?bydist=etch (qui donne 35 bugs RC).
Et puis de toute facon, on ne peut pas regarder que le nombre. Certains bugs concernent des paquets vraiment peu importants qui pourraient être supprimés, d'autres sont en passe d'être résolus, et enfin, certains ne méritent peut-etre pas d'être considérés comme des bugs RC...