Ubuntu developpe Upstart depuis 2006, il est utilisé par Chrome Os et Red-Hat.
Plus pour très longtemps. Redhat a annoncé qu'il passait à systemd, comme on pouvait s'y attendre. Pour Chrome OS, seul Google sait ce qu'il en adviendra.
Indépendamment des qualités techniques des deux projets, et des qualités humaines des intervenants, l'orientation générale est très clairement défavorable à upstart. Il suffit de regarder les choix des principales distributions pour voir qu'Ubuntu sera bien seul. Le constat de Lennart Pottering me semble donc juste (indépendamment de la forme).
Debian avait envisagé d'adopter upstart en 2009, mais aujourd'hui le paquet n'est plus maintenu (même en unstable, on a la v0.6.6 d'il y a un an). Le paquet de la dernière version de Systemd est par contre bien présent.
Fedora a abandonné Upstart pour systemd.
OpenSUSE a essayé Upstart avant de passer à systemd.
ArchLinux ne propose pas Upstart, mais systemd.
Idem pour Gentoo.
RedHat (et donc CentOS) a annoncé sa migration vers systemd.
Je suis désolé de faire mon chieur, mais ton avatar en 1920x1200 pour être finalement affiché en 64x64 me choque.
Moi c'est le principe même des ces images qui me gêne. Ça prend de la place et ça détourne le regard pour un intérêt presque nul.
Dans mon navigateur, j'ai ajouté la CSS suivante au site linuxfr.org :
A ma connaissance, il n'existe qu'une implémentation de ce Browser-to-Browser : Opera Unite. Grosso modo, c'est un serveur web léger embarqué dans le navigateur web, pour une diffusion au cas par cas.
J'ai eu du mal à trouver l'URL pour cloner le dépôt Git. Dans le wiki, on trouve un lien vers la FAQ, et la 6e question donne le lien. C'est beaucoup trop caché à mon goût — j'avais cherché ce lien pendant 2 minutes sans trouver avant de tomber dessus par hasard.
Sinon, un petit bug : dfc -t -udev ne masque pas les montages de type "udev". Ça marche avec "tmpfs" et "rootfs", même combinés en "-tmpfs,rootfs". Debian testing amd64.
Je sais que j'aurais dû créer un ticket dans la forge, mais j'ai la flemme de me créer un compte à usage unique.
Le terme "application" sous-entend aussi qu'il permet à l'utilisateur de faire qqch. Un logiciel est plus précis et peut être invisible de l'utilisateur (un serveur web est un logiciel mais n'est pas une application). Un application peut elle être en fait un ensemble de logiciels.
C'est amusant, je suis d'accord sur la distinction d'objectif, mais j'en tire une conclusion contraire. Pour moi, les applications sont un cas particulier de logiciel, donc le terme "application" est d'une certaine façon plus précis. En fait, ce mot n'est pas apparu par hasard. On parlait initialement de logiciel applicatif ou logiciel d'application, et on a enlevé le mot logiciel quand l'informatique est devenue plus familière. On pourrait faire un parallèle avec le glissement de « e-mail » vers « mail ».
Si on pense à un logiciel d'application chaque fois que l'on voit le mot application, alors la distinction de sens est claire. Au fait, aujourd'hui on ne dit plus logiciel d'exploitation, mais toujours système d'exploitation. Une influence anglo-saxonne, sans doute.
Il y a une vingtaine d'années, tout le monde se serait moqué d'un titre comme « Avancées dans l'ergonomie des applications ». Pourquoi ?
Si vous pensiez à « ergonomie » ou « application » c'est perdu ! Le mot « avancée », bien que très à la mode aujourd'hui est une création récente dans ce sens. Il a complètement remplacé le mot « progrès » qui avait sans doute un trop forte connotation intellectuelle et historique. Dans les années 70, les journalistes ont commencé à parler d'avancées, non pas de toits, ni de troupes napoléoniennes, mais dans un dialogue avec la hiérarchie. Par exemple, dans des négociations entre les syndicats et l'État. C'était alors un simple sens figuré du sens militaire classique, et c'est ce qui figure dans mon Petit Robert — papier, bien sûr ! Aujourd'hui, on l'emploie partout en remplacement de « progrès », un peu à la façon de « énorme » qui sous l'influence des journalistes sportifs se substitue progressivement à « magnifique, éblouissant, splendide, impressionnant, grandiose, magistral, sublime » et tous ces termes trop difficiles aux subtiles variations sémantiques.
Pour en revenir au passage de « logiciel » à « application » je pense que cela illustre l'intégration de l'informatique dans la vie quotidienne. Le mot « logiciel » a une connotation technique, et maintenant que beaucoup d'utilisateurs sont totalement immergés dans l'informatique via des centaines de logiciels sur leur PC, leur "smartphone", au boulot comme à la maison, le terme semble un peu trop rébarbatif, trop technique. On lui préfère un terme plus vague mais plus habituel (peut-être sous une influence commerciale). Le second facteur que je vois, c'est l'irruption des « applications web » qui ont perturbé le concept du logiciel qu'on installe sur son ordinateur.
Réfléchir sur des choses sans importance est un passe-temps fabuleux.
Moi aussi, j'aime beaucoup. Je crois même que ces choses sans importance sont importantes pour moi !
mysqlnd est une bibliothèque "maison" (issue du projet PHP si je comprend bien) contrairement à la bibliothèque officielle.
La biblio mysqlnd a principalement été développé par MySQL-AB, tout comme la bibliothèque C. Le chef de projet, Andrey Hristov1, est, comme pas mal de développeurs MySQL, un programmeur venu de l'Est, et les autres sont aussi encartés chez MySQL AB : Georg Richter, Ulf Wendel et Johannes Schlueter.
En cherchant qui sont les développeurs de mysqlnd, je viens de trouver une citation de leur forge à l'appui de mes propos :
mysqlnd is licensed under the PHP license and it is tightly integrated into PHP on the C-level. For example, mysqlnd is using the PHP memory management functions and network streams. Due to the close integration, it is difficult for other C programs but PHP to use the library. Any other C program that tries to use mysqlnd would need to link against large parts of PHP. Maybe this explains what “native” and “for PHP” means.
Tout le problème vient du sens que l'on donne à bibliothèque native. Le lien donné plus haut vers la page "code natif" de Wikipedia est très peu adapté, je vais tenter une définition.
Tout d'abord, l'expression est reprise de l'anglais. Une traduction littérale serait plutôt "bibliothèque indigène". Cela explique la page Wikipedia sus-citée, c'est-à-dire pourquoi le "code machine" est du "code natif" : il dépend de l'architecture d'exécution, il n'est pas portable. Ainsi une "bibliothèque native" est une bibliothèque spécialement conçue pour un environnement "natif".
A mes yeux, "libmysql" est native en C, mais pas en PHP. Par contre, dans le contexte de PHP, "mysqlnd" est bien native, contrairement à "libmysql".
Bof. Ça fait longtemps que Perl n'est plus un concurrent de Python.
Tu as déjà entendu parler d'administration système ?
Je ne vais pas m'amuser à faire de la psychologie de bazar avec les pythonistes, mais il semblerait que beaucoup soient un peu perturbés. Ce besoin de crier "la mienne est plus grosse, et puis les perlistes en ont une toute petite", c'est presque pathologique. J'espère que toute la communauté n'est pas atteinte du même virus. En tout cas, je préfère éviter de fréquenter les pythoneux, au cas où ce serait contagieux. Je vais me contenter de la communauté des haskelliens, surtout… que c'est eux qui ont la plus grosse !
Pour reprendre la formule de F. Bayrou d'aujourd'hui, il me semble qu'à la simple évocation de Perl, beaucoup de gentils internautes font "exploser le déconnomètre". En particulier parmi les zélotes de Python.
Pour les plus agressifs, obstinés, ou incultes, je propose une FAQ :
Perl 6 et Perl 5 sont deux langages différents, avec une légère ressemblance. Comparer avec le passage de Python 2 à 3 n'a pas de sens.
Le terme "Perl" désigne toujours Perl 5.
Perl a beaucoup évolué. Par exemple, la syntaxe POO avec Moose.
Python et Perl sont deux langages différents, et l'un n'est pas le successeur de l'autre. On peut préférer l'un ou l'autre selon le contexte, et selon ses goûts personnels.
Pour ceux qui n'apprécient que la provocation : la conception de Python3 a commencé en 2005, et aujourd'hui il toujours pas capable de faire tourner les applis majeures comme le framework web Django. Un langage mal conçu et qui n'arrive pas à s'amender proprement.
Je ne pense pas ce que je viens d'écrire, je tenais juste à rappeler qu'il est facile de traîner dans la boue, surtout quand on prend ses aises avec la réalité. Amis pythoniens, pas d'injective envers vos concurrents, vous en sortirez grandis.
Je vais décrire la tambouille que j'utilise pour le versionnage des fichiers locaux. Certains points ont déjà été traités par d'autres commentateurs, désolé pour les doublons.
Dans le dépôt central, les fichiers de configuration sont nommés différemment, par exemple tralala.conf.dist ou config-dist.php. Dans certains cas, il vaut mieux garder l'extension du fichier au cas où il contiendrait des infos sensibles.
Dans les dépôts de travail, ces fichiers sont copiés en tralalaconf ou config.php. Ils sont alors versionnés dans une branche locale :
hg branch modifslocales
# ... crée les fichiers de conf
hg addremove
hg ci -m "config locale"
Ensuite, si des modifs sont effectuées sur le dépôt central, je rebase ma branche locale sur le "tip":
hg pull -u
hg rebase -d tip # d'autres syntaxes sont possibles
Le cas le plus complexe est quand j'ai modifié une de ces instances locales, mais que je veux l'enregistrer dans le dépôt central. Autrement dit, j'ai fait une modif dans une branche, mais je veux la commiter dans la branche "default". Dans ce cas, j'utilise l'extension "shelve" :
hg shelve -a # met en réserve le diff et rétablit les fichiers d'origine
hg up default # passe dans la branche centrale
hg unshelve # applique le diff mis de côté
hg ci -m "modif globale" # commite
hg push # propage
hg up modifslocales # retourne dans la branche locale
hg rebase -d tip # synchronise la branche locale avec le dernier changement
Si quelqu'un a une solution plus simple, avec git ou hg, cela m'intéresse.
Là où le système est perfectible, c'est que git ne te prévient qu'au moment du push. Résultat, tu te retrouves avec un dépôt local en vrac qui ne peut plus faire de push/pull mais qui contient tout de même de nouveau commits. On peut s'en sortir avec un nouveau clone et un peu de cueillette de cerises, mais se serait plus simple si git nous prévenait au moment du rebase.
Au passage, je ne suis pas sûr que git râle tout le temps quand on veut propager un historique modifié, par exemple si on a fait un rebase interactif ou un de ces trucs d'édition poussée de l'historique. J'ai le souvenir du contraire, mais peut-être que ma mémoire me joue des tours. Ou alors git a amélioré cela ces derniers temps.
En fait, ces extensions de mercurial sont inspirées de choses que propose git...
Tu peux expliquer un peu ? À ma connaissance, il n'y a pas ce genre de garde-fous dans git.
Par exemple, il m'est déjà arrivé avec git de faire un rebase sur du code déjà propagé. Je passe sur la galère qui avait suivi.
Et je ne suis pas le seul, puisque Linus a déjà signalé ce genre d'embrouilles dans son dépôt du noyau.
Un détail : tu écris "ces extensions de mercurial" alors que la dépêche explique clairement que le mécanisme des phases fait partie du cœur de l'application. Ensuite, toutes les extensions doivent s'y plier, en particulier "rebase" qui est une extension livrée par défaut.
s/(import)(s?)\b/\1ation\2/ ou plutôt s/(import)(s?)\b/$1ation$2/ avec la notation recommandée par PCRE (Perl Compatible Regular Expressions).
Sinon "importer" deviendrait "importationer".
C'est beau, une expression rationnelle qui se promène paisiblement dans un forum de linuxfr. Mais quand on veut l'accoupler à un texte en langage naturel, elle se défend férocement !
Je ne suis pas d'accord. import est un anglicisme. Le terme français est bien importation.
Dans le dictionnaire universitaire de référence du français moderne, le Trésor de la Langue Française, le mot import est absent, même si l'expression import-export est présente. Bien sûr, le mot import ne figure pas non plus dans les dictionnaire plus anciens comme le Littré.
Le site web de Grisbi n'est pas mis à jour, et il ne faut pas faire confiance aux informations (contradictoires) qu'il contient. C'est vraiment dommage pour lui !
Par exemple :
Le lien vers les sources stables pointe vers la 0.8.8 alors que la 0.8.9 est stable et postérieure.
La liste des nouveautés oublie la plupart des versions stables (seule la 0.8.1 est citée après la 0.6.0).
Le changelog s'arrête à la version 0.6 alors que la version 0.9.5 existe.
Les liens vers les paquets Debian font référence à la oldstable de 2006, franchement antique pour ce genre d'appli.
Aucun paquet deb pour les versions v>6.... Y'a plus de mainteneur debian ?
Je suis aussi sous Debian, et j'utilise aussi Grisbi. Par contre, je suis en testing et j'ai des mises à jour régulières de Grisbi.
Si tu es en stable, alors rien de nouveau.
Pour préciser, la version 0.8.9 était installé sur mon PC avant que je ne lise cette dépêche :
Pour voir la liste des versions publiées par Debian, c'est dans la rubrique centrale "News" de la page http://packages.qa.debian.org/g/grisbi.html
On peut constater que des versions postérieures à la 0.6.0 ont été publiées régulièrement en unstable et testing.
Une bonne piste pour réaliser un sandboxing performant en php, c'est d'utiliser php-fpm.
Au niveau des performances, c'est apparemment meilleur que mod_php. Chaque spool php peut être lancé par un utilisateur différent, pas besoin de suexec et compagnie. Au passage, cela permet aussi de résoudre les problèmes d'exécution infinie évoqués plus haut. A mon sens, on a donc une solution optimale, et j'avais d'ailleurs été très satisfait de mes premiers tests.
Seul bémol, ce mode php-fpm n'a été intégré qu'en PHP 5.3.3, avec le statut "expérimental". Il sera déclaré stable en version 5.4, laquelle n'est encore qu'à l'état de RC.
Je me demande si PHP ne va pas encourager ceci pour remplacer mod_php, un peu à la façon dont wsgi a remplacé mod_python.
Le mieux serait de savoir comment rogo a pris vos remarques; après tout c'est le premier concerné.
Très bien merci. Je dois être un peu naïf, je n'ai pas vu de moquerie et encore moins d'agressivité dans ces messages.
Et puis j'ai assez de bouteille (sans être un vieux gauchiste) pour ne pas être trop susceptible sur internet.
Ce qui me désole dans l'affaire, c'est que ceux qui ne connaissent pas Georges Marchais n'ont donc jamais écouté Pierre Desproges. Et ça, c'est vraiment dommage pour eux !
La cohérence, ils s'en balancent. Honnêtement, je crois que c'est vraiment un souci archi minoritaire parmi les développeurs PHP. On peut apprécier ou pas, mais leurs objectifs sont ailleurs. Il n'y a aucun projet de réformer le langage en profondeur. À la limite, le seul changement prévu qui aurait un impact universel en PHP, c'est le support d'UTF-8.
Certes la syntaxe de PHP est bordélique (sensible à la casse sur les variables mais pas sur les fonctions), le nommage interne est incohérent (fetchAll() ou get_file_contents() ? strtolower() ou ip2long() ?), la jungle des fonctions de tri est hideuse, etc, etc. Mais est-ce essentiel ? Pour les langues humaines, le corpus est souvent plus important que la cohérence grammaticale. La langue française, même s'il est difficile de maîtriser parfaitement ce fouillis, a des atouts face à un esperanto très raisonné. Pour la plupart des incongruités, nous y sommes tellement habitués qu'elles deviennent normales. Est-ce que des réformes de l'orthographe sont nécessaires pour donner plus de cohérence à notre langue ?
Une comparaison plus technique : Scala est un langage magnifique. Moderne, riche, cohérent et même élégant. Ce fut un vrai bonheur d'apprendre le langage, et j'ai toujours plaisir à programmer avec. Sauf que peu à peu, j'ai déchanté en me confrontant à son environnement. Par exemple, le "build system" usuel est SBT qui m'a semblé un vrai calvaire, surtout depuis le changement (incompatible) de version. Du coup, beaucoup utilisent Maven, un outil Java qui peut s'adapter au monde Scala. Tout ça est très pénible à mettre en place, mais nécessaire pour certaines applis. Je ne dis pas que SBT ou Maven sont mauvais, c'est juste qu'ils sont lourds et difficiles à maîtriser. Ça colle assez bien à l'état d'esprit Java/Scala, mais c'est plutôt éloigné des objectifs de PHP.
[^] # Re: systemd vs upstart
Posté par rogo . En réponse à la dépêche Ubuntu 12.04 Precise Pangolin est sortie. Évalué à 10.
Plus pour très longtemps. Redhat a annoncé qu'il passait à systemd, comme on pouvait s'y attendre. Pour Chrome OS, seul Google sait ce qu'il en adviendra.
Indépendamment des qualités techniques des deux projets, et des qualités humaines des intervenants, l'orientation générale est très clairement défavorable à upstart. Il suffit de regarder les choix des principales distributions pour voir qu'Ubuntu sera bien seul. Le constat de Lennart Pottering me semble donc juste (indépendamment de la forme).
[^] # Re: Je suis désolé…
Posté par rogo . En réponse à la dépêche Intel Ivy Bridge et Linux : ça juste marche. Évalué à 4.
Moi c'est le principe même des ces images qui me gêne. Ça prend de la place et ça détourne le regard pour un intérêt presque nul.
Dans mon navigateur, j'ai ajouté la CSS suivante au site linuxfr.org :
[^] # Re: ahahah copain
Posté par rogo . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 1.
A ma connaissance, il n'existe qu'une implémentation de ce Browser-to-Browser : Opera Unite. Grosso modo, c'est un serveur web léger embarqué dans le navigateur web, pour une diffusion au cas par cas.
[^] # Re: Git, bug
Posté par rogo . En réponse à la dépêche dfc(1): une alternative à df(1) apportant couleur et graphe. Évalué à 2.
Un dernier bug pour la route : les colonnes se recouvrent parfois.
[^] # Re: Git, bug
Posté par rogo . En réponse à la dépêche dfc(1): une alternative à df(1) apportant couleur et graphe. Évalué à 2.
Autre bug, plus gênant : dfc tronque les chemins de montage.
# Git, bug
Posté par rogo . En réponse à la dépêche dfc(1): une alternative à df(1) apportant couleur et graphe. Évalué à 1.
J'ai eu du mal à trouver l'URL pour cloner le dépôt Git. Dans le wiki, on trouve un lien vers la FAQ, et la 6e question donne le lien. C'est beaucoup trop caché à mon goût — j'avais cherché ce lien pendant 2 minutes sans trouver avant de tomber dessus par hasard.
Sinon, un petit bug :
dfc -t -udevne masque pas les montages de type "udev". Ça marche avec "tmpfs" et "rootfs", même combinés en "-tmpfs,rootfs". Debian testing amd64.Je sais que j'aurais dû créer un ticket dans la forge, mais j'ai la flemme de me créer un compte à usage unique.
[^] # Re: Sémantique
Posté par rogo . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 1.
C'est amusant, je suis d'accord sur la distinction d'objectif, mais j'en tire une conclusion contraire. Pour moi, les applications sont un cas particulier de logiciel, donc le terme "application" est d'une certaine façon plus précis. En fait, ce mot n'est pas apparu par hasard. On parlait initialement de logiciel applicatif ou logiciel d'application, et on a enlevé le mot logiciel quand l'informatique est devenue plus familière. On pourrait faire un parallèle avec le glissement de « e-mail » vers « mail ».
Si on pense à un logiciel d'application chaque fois que l'on voit le mot application, alors la distinction de sens est claire. Au fait, aujourd'hui on ne dit plus logiciel d'exploitation, mais toujours système d'exploitation. Une influence anglo-saxonne, sans doute.
[^] # Re: Sémantique
Posté par rogo . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 9.
Il y a une vingtaine d'années, tout le monde se serait moqué d'un titre comme « Avancées dans l'ergonomie des applications ». Pourquoi ?
Si vous pensiez à « ergonomie » ou « application » c'est perdu ! Le mot « avancée », bien que très à la mode aujourd'hui est une création récente dans ce sens. Il a complètement remplacé le mot « progrès » qui avait sans doute un trop forte connotation intellectuelle et historique. Dans les années 70, les journalistes ont commencé à parler d'avancées, non pas de toits, ni de troupes napoléoniennes, mais dans un dialogue avec la hiérarchie. Par exemple, dans des négociations entre les syndicats et l'État. C'était alors un simple sens figuré du sens militaire classique, et c'est ce qui figure dans mon Petit Robert — papier, bien sûr ! Aujourd'hui, on l'emploie partout en remplacement de « progrès », un peu à la façon de « énorme » qui sous l'influence des journalistes sportifs se substitue progressivement à « magnifique, éblouissant, splendide, impressionnant, grandiose, magistral, sublime » et tous ces termes trop difficiles aux subtiles variations sémantiques.
Pour en revenir au passage de « logiciel » à « application » je pense que cela illustre l'intégration de l'informatique dans la vie quotidienne. Le mot « logiciel » a une connotation technique, et maintenant que beaucoup d'utilisateurs sont totalement immergés dans l'informatique via des centaines de logiciels sur leur PC, leur "smartphone", au boulot comme à la maison, le terme semble un peu trop rébarbatif, trop technique. On lui préfère un terme plus vague mais plus habituel (peut-être sous une influence commerciale). Le second facteur que je vois, c'est l'irruption des « applications web » qui ont perturbé le concept du logiciel qu'on installe sur son ordinateur.
Moi aussi, j'aime beaucoup. Je crois même que ces choses sans importance sont importantes pour moi !
[^] # Re: Historique et marque-pages
Posté par rogo . En réponse à la dépêche Firefox 11. Évalué à 0.
Je confirme que la fonctionnalité de synchronisation est présente dans Opera depuis 2007 : http://techcrunch.com/2007/10/25/synchronize-your-browsing-habits-with-opera-link/
[^] # Re: mysqlnd
Posté par rogo . En réponse à la dépêche Sortie de PHP 5.4. Évalué à 3.
La biblio mysqlnd a principalement été développé par MySQL-AB, tout comme la bibliothèque C. Le chef de projet, Andrey Hristov1, est, comme pas mal de développeurs MySQL, un programmeur venu de l'Est, et les autres sont aussi encartés chez MySQL AB : Georg Richter, Ulf Wendel et Johannes Schlueter.
[^] # Re: mysqlnd
Posté par rogo . En réponse à la dépêche Sortie de PHP 5.4. Évalué à 10.
En cherchant qui sont les développeurs de mysqlnd, je viens de trouver une citation de leur forge à l'appui de mes propos :
Extrait de http://forge.mysql.com/wiki/PHP_MYSQLND (qui contient aussi un historique et toutes sortes d'explication sur le lien PHP-MySQL).
[^] # Re: mysqlnd
Posté par rogo . En réponse à la dépêche Sortie de PHP 5.4. Évalué à 0.
Tout le problème vient du sens que l'on donne à bibliothèque native. Le lien donné plus haut vers la page "code natif" de Wikipedia est très peu adapté, je vais tenter une définition.
Tout d'abord, l'expression est reprise de l'anglais. Une traduction littérale serait plutôt "bibliothèque indigène". Cela explique la page Wikipedia sus-citée, c'est-à-dire pourquoi le "code machine" est du "code natif" : il dépend de l'architecture d'exécution, il n'est pas portable. Ainsi une "bibliothèque native" est une bibliothèque spécialement conçue pour un environnement "natif".
A mes yeux, "libmysql" est native en C, mais pas en PHP. Par contre, dans le contexte de PHP, "mysqlnd" est bien native, contrairement à "libmysql".
[^] # Re: Court terme, toussa ...
Posté par rogo . En réponse à la dépêche Le support de Redhat Enterprise Linux passe à 10 ans. Évalué à 1.
Je signale juste qu'Oracle a 2 SGDB célèbres : l'éponyme et MySQL.
[^] # Re: Perl et le déconnomètre
Posté par rogo . En réponse à la dépêche Conférences « Perl, fun again! » le 5 mars 2012 à Paris. Évalué à 1.
Tu as déjà entendu parler d'administration système ?
Je ne vais pas m'amuser à faire de la psychologie de bazar avec les pythonistes, mais il semblerait que beaucoup soient un peu perturbés. Ce besoin de crier "la mienne est plus grosse, et puis les perlistes en ont une toute petite", c'est presque pathologique. J'espère que toute la communauté n'est pas atteinte du même virus. En tout cas, je préfère éviter de fréquenter les pythoneux, au cas où ce serait contagieux. Je vais me contenter de la communauté des haskelliens, surtout… que c'est eux qui ont la plus grosse !
# Perl et le déconnomètre
Posté par rogo . En réponse à la dépêche Conférences « Perl, fun again! » le 5 mars 2012 à Paris. Évalué à 10.
Pour reprendre la formule de F. Bayrou d'aujourd'hui, il me semble qu'à la simple évocation de Perl, beaucoup de gentils internautes font "exploser le déconnomètre". En particulier parmi les zélotes de Python.
Pour les plus agressifs, obstinés, ou incultes, je propose une FAQ :
Pour ceux qui n'apprécient que la provocation : la conception de Python3 a commencé en 2005, et aujourd'hui il toujours pas capable de faire tourner les applis majeures comme le framework web Django. Un langage mal conçu et qui n'arrive pas à s'amender proprement.
Je ne pense pas ce que je viens d'écrire, je tenais juste à rappeler qu'il est facile de traîner dans la boue, surtout quand on prend ses aises avec la réalité. Amis pythoniens, pas d'injective envers vos concurrents, vous en sortirez grandis.
[^] # Re: Versionnage de fichier de conf privé possible ?
Posté par rogo . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 1.
Je vais décrire la tambouille que j'utilise pour le versionnage des fichiers locaux. Certains points ont déjà été traités par d'autres commentateurs, désolé pour les doublons.
Dans le dépôt central, les fichiers de configuration sont nommés différemment, par exemple
tralala.conf.distouconfig-dist.php. Dans certains cas, il vaut mieux garder l'extension du fichier au cas où il contiendrait des infos sensibles.Dans les dépôts de travail, ces fichiers sont copiés en
tralalaconfouconfig.php. Ils sont alors versionnés dans une branche locale :Ensuite, si des modifs sont effectuées sur le dépôt central, je rebase ma branche locale sur le "tip":
Le cas le plus complexe est quand j'ai modifié une de ces instances locales, mais que je veux l'enregistrer dans le dépôt central. Autrement dit, j'ai fait une modif dans une branche, mais je veux la commiter dans la branche "default". Dans ce cas, j'utilise l'extension "shelve" :
Si quelqu'un a une solution plus simple, avec git ou hg, cela m'intéresse.
[^] # Re: M'étonnerait que ça arrive dans git.
Posté par rogo . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 1.
Là où le système est perfectible, c'est que git ne te prévient qu'au moment du push. Résultat, tu te retrouves avec un dépôt local en vrac qui ne peut plus faire de push/pull mais qui contient tout de même de nouveau commits. On peut s'en sortir avec un nouveau clone et un peu de cueillette de cerises, mais se serait plus simple si git nous prévenait au moment du rebase.
Au passage, je ne suis pas sûr que git râle tout le temps quand on veut propager un historique modifié, par exemple si on a fait un rebase interactif ou un de ces trucs d'édition poussée de l'historique. J'ai le souvenir du contraire, mais peut-être que ma mémoire me joue des tours. Ou alors git a amélioré cela ces derniers temps.
[^] # Re: M'étonnerait que ça arrive dans git.
Posté par rogo . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 3.
Tu peux expliquer un peu ? À ma connaissance, il n'y a pas ce genre de garde-fous dans git.
Par exemple, il m'est déjà arrivé avec git de faire un rebase sur du code déjà propagé. Je passe sur la galère qui avait suivi.
Et je ne suis pas le seul, puisque Linus a déjà signalé ce genre d'embrouilles dans son dépôt du noyau.
Un détail : tu écris "ces extensions de mercurial" alors que la dépêche explique clairement que le mécanisme des phases fait partie du cœur de l'application. Ensuite, toutes les extensions doivent s'y plier, en particulier "rebase" qui est une extension livrée par défaut.
[^] # Re: Petites remarques…
Posté par rogo . En réponse à la dépêche LibreOffice 3.5 est disponible. Évalué à 5.
s/(import)(s?)\b/\1ation\2/ou plutôts/(import)(s?)\b/$1ation$2/avec la notation recommandée par PCRE (Perl Compatible Regular Expressions).Sinon "importer" deviendrait "importationer".
C'est beau, une expression rationnelle qui se promène paisiblement dans un forum de linuxfr. Mais quand on veut l'accoupler à un texte en langage naturel, elle se défend férocement !
[^] # Re: Petites remarques…
Posté par rogo . En réponse à la dépêche LibreOffice 3.5 est disponible. Évalué à 7.
Je ne suis pas d'accord. import est un anglicisme. Le terme français est bien importation.
Dans le dictionnaire universitaire de référence du français moderne, le Trésor de la Langue Française, le mot import est absent, même si l'expression import-export est présente. Bien sûr, le mot import ne figure pas non plus dans les dictionnaire plus anciens comme le Littré.
# Un mauvais site web est nuisible
Posté par rogo . En réponse à la dépêche Grisbi : nouvelle version du manuel, la 0.6.0 est en ligne. Évalué à 5.
Le site web de Grisbi n'est pas mis à jour, et il ne faut pas faire confiance aux informations (contradictoires) qu'il contient. C'est vraiment dommage pour lui !
Par exemple :
[^] # Re: Version 0.8.9 ?
Posté par rogo . En réponse à la dépêche Grisbi : nouvelle version du manuel, la 0.6.0 est en ligne. Évalué à 1.
Je suis aussi sous Debian, et j'utilise aussi Grisbi. Par contre, je suis en testing et j'ai des mises à jour régulières de Grisbi.
Si tu es en stable, alors rien de nouveau.
Pour préciser, la version 0.8.9 était installé sur mon PC avant que je ne lise cette dépêche :
Pour voir la liste des versions publiées par Debian, c'est dans la rubrique centrale "News" de la page http://packages.qa.debian.org/g/grisbi.html
On peut constater que des versions postérieures à la 0.6.0 ont été publiées régulièrement en unstable et testing.
[^] # Re: Pour compléter...
Posté par rogo . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 5.
Une bonne piste pour réaliser un sandboxing performant en php, c'est d'utiliser php-fpm.
Au niveau des performances, c'est apparemment meilleur que mod_php. Chaque spool php peut être lancé par un utilisateur différent, pas besoin de suexec et compagnie. Au passage, cela permet aussi de résoudre les problèmes d'exécution infinie évoqués plus haut. A mon sens, on a donc une solution optimale, et j'avais d'ailleurs été très satisfait de mes premiers tests.
Seul bémol, ce mode php-fpm n'a été intégré qu'en PHP 5.3.3, avec le statut "expérimental". Il sera déclaré stable en version 5.4, laquelle n'est encore qu'à l'état de RC.
Je me demande si PHP ne va pas encourager ceci pour remplacer mod_php, un peu à la façon dont wsgi a remplacé mod_python.
[^] # Re: Encore et toujours...
Posté par rogo . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 10.
Très bien merci. Je dois être un peu naïf, je n'ai pas vu de moquerie et encore moins d'agressivité dans ces messages.
Et puis j'ai assez de bouteille (sans être un vieux gauchiste) pour ne pas être trop susceptible sur internet.
Ce qui me désole dans l'affaire, c'est que ceux qui ne connaissent pas Georges Marchais n'ont donc jamais écouté Pierre Desproges. Et ça, c'est vraiment dommage pour eux !
[^] # Re: Pour compléter...
Posté par rogo . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 7.
La cohérence, ils s'en balancent. Honnêtement, je crois que c'est vraiment un souci archi minoritaire parmi les développeurs PHP. On peut apprécier ou pas, mais leurs objectifs sont ailleurs. Il n'y a aucun projet de réformer le langage en profondeur. À la limite, le seul changement prévu qui aurait un impact universel en PHP, c'est le support d'UTF-8.
Certes la syntaxe de PHP est bordélique (sensible à la casse sur les variables mais pas sur les fonctions), le nommage interne est incohérent (
fetchAll()ouget_file_contents()?strtolower()ouip2long()?), la jungle des fonctions de tri est hideuse, etc, etc. Mais est-ce essentiel ? Pour les langues humaines, le corpus est souvent plus important que la cohérence grammaticale. La langue française, même s'il est difficile de maîtriser parfaitement ce fouillis, a des atouts face à un esperanto très raisonné. Pour la plupart des incongruités, nous y sommes tellement habitués qu'elles deviennent normales. Est-ce que des réformes de l'orthographe sont nécessaires pour donner plus de cohérence à notre langue ?Une comparaison plus technique : Scala est un langage magnifique. Moderne, riche, cohérent et même élégant. Ce fut un vrai bonheur d'apprendre le langage, et j'ai toujours plaisir à programmer avec. Sauf que peu à peu, j'ai déchanté en me confrontant à son environnement. Par exemple, le "build system" usuel est SBT qui m'a semblé un vrai calvaire, surtout depuis le changement (incompatible) de version. Du coup, beaucoup utilisent Maven, un outil Java qui peut s'adapter au monde Scala. Tout ça est très pénible à mettre en place, mais nécessaire pour certaines applis. Je ne dis pas que SBT ou Maven sont mauvais, c'est juste qu'ils sont lourds et difficiles à maîtriser. Ça colle assez bien à l'état d'esprit Java/Scala, mais c'est plutôt éloigné des objectifs de PHP.