J'ai moi aussi du mal à comprendre l'intérêt de ce langage, mais pour des raisons indépendantes de sa syntaxe.
Un langage créé par Mozilla pour développer un navigateur de Mozilla, il y a peu de chance qu'il attire une large communauté. Surtout quand l'offre en langages de programmation est déjà pléthorique. J'imagine que ce sera plutôt une barrière à l'entrée de ce nouveau navigateur web : si vous voulez collaborer, il faut d'abord apprendre le langage maison. Ça risque d'en refroidir plus d'un. Moi en tout cas je ne propose des patches que dans les langages que je connais déjà.
Mais surtout, j'ai des doutes sur la pérennité de ce choix. La dépêche met en avant des impératifs de sécurité et de performance. Ce sont des domaines qui requièrent des experts. Est-ce que la fondation Mozilla disposera toujours de plusieurs experts en compilateurs ? Quand je vois sa position sur XUL ou Thunderbird, je suis d'autant plus dubitatif.
Je me demande s'il n'aurait pas été possible d'adopter un langage déjà présent, avec une communauté déjà formée et si possible des experts déjà au travail sur l'implémentation. Je pense bien sûr à Go qui a beaucoup de points communs avec Rust, et sur lequel Google apporte une certaine garantie de qualité et de pérennité. Est-ce qu'un fork du compilateur accompagné de quelques bibliothèques n'aurait pas suffit ? Idem avec OCaml, D, ou Scala, voire Haskell. Malheureusement, je ne suis pas assez compétent pour répondre à mon interrogation.
Bref, j'ai un peu peur que Mozilla soit victime du syndrome "Not Invented Here".
Aïe, à mon tour de me faire taper sur les doigts. Effectivement, je ne pensais pas à Boris Vian et son Arrache-cœur, mais au truc écrit par Salinger.
Par contre, que l'on ne soit pas d'accord sur tout ne me surprend pas. Certains aiment vi, d'autres emacs, d'autres aucun, etc. Il y a des logiciels, des livres et des films qui ne sont pas pour moi, mais que d'autres savent apprécier. Je résiste à la tentation de continuer ici une critique littéraire sauvage, ce n'est pas le lieu.
Tu cherches à te faire des copains cinéphiles, c'est ça ?
Je reconnais que c'était une provocation gratuite. Mais assumée.
J'espère que tous les cinéphiles ne sont pas des fanatiques de "Citizen Kane". Moi qui me sens plutôt "littérophile", je déteste allègrement certains chefs d'œuvre. Par exemple, je trouve "Salambô" de Flaubert plus pénible et plus ridicule que les plus ratés des romans de Victor Hugo. Et je m'ennuie profondément dans beaucoup de romans modernes acclamés par la critique, de "Sur la route" jusqu'à "De sang-froid" en passant par "L'arrache-cœur". Ce qui ne m'empêche pas d'adorer certains auteurs classiques, par exemple Shakespeare ou Rabelais.
De 1984 au meilleur des mondes
Pour en revenir au sujet initial, c'est-à-dire le rôle de "Big Brother" que prend Cisco aujourd'hui, mon cauchemar serait plutôt du côté du "Meilleur des mondes". Chacun se satisferait de sa situation : « j'ai une petite vie sans problème, je peux consommer librement, je peux baiser librement, je peux regarder la télé, tout va bien et je ne vais pas me casser la tête avec des problèmes moraux ou des réflexions politiques ; il y a des professionnels formés pour ça, heureusement que je n'ai pas à m'en occuper ». Plus que la surveillance, c'est ce conditionnement mental qui me fait peur, cette flemme intellectuelle et ce dédain de toute politique au sens large. Heureusement qu'il reste des gens pour réfléchir et râler, ici et ailleurs.
Juste pour remettre les noms en place : "1984", c'est l'œuvre de George Orwell.
Je le confonds parfois avec H. G. Wells ("L'île du docteur Moreau", "La guerre des mondes", etc) mais jamais avec Orson Welles (et son film prétentieux "Citizen Kane" au fameux "rosebud").
Dans la série, y'a aussi "Fargo Wells", mais je dérive…
Cette histoire de South Park ressemble énormément à un film de 1951, The Man in the White Suit (en français, L'Homme au complet blanc) : un jeune chimiste invente un tissu très résistant et peu salissant. Les industriels et les politiques s'allient alors avec les syndicats pour faire disparaître cette invention, de gré ou de force. C'est un classique du cinéma, mais je ne pense pas qu'il ait été le premier à traiter ce sujet.
Je me trompe peut-être, mais je suppose que les affrontements internes aux développeurs de MPlayer ont retardé la sortie d'une version officiellement stable. Je ne me souviens pas des détails, mais en 2004 certains avaient évoqué un coup d'État pour éliminer les fondateurs. Je ne prends pas partie dans ce vieux conflit, je ne connais pas les faits, et les détails ne m'intéressent pas.
Par ailleurs, il existe un fork plutôt actif, MPlayer2. Il est distribué dans Debian (ou avec git si on est prêt à installer les nombreuses dépendances). Je l'avais adopté à un moment où le trunk du MPlayer officiel ne compilait plus chez moi depuis plusieurs semaines. Le site de MPlayer2 contient une liste des différences.
Et s'il y a des employés Français qui espionnent des Ethiopiens, tu vas leur demander quoi? Qu'ils démissionnent par conviction? Parce que bien entendu, tu sais, toi, que eux sont conscients de la nature profonde de la chaine dont ils sont un maillon. Tu connais aussi leur vie et leur situation familiale, leurs antécédents professionnels. Prenons un exemple cliché: tu trouves un mec qui fait ce boulot alors qu'ils a une femme et 2 enfants à nourrir et qu'il sort tout juste de 5ans de chômage. Tu vas sérieusement aller lui demander de démissionner?
Si mes grand-parents avaient demandé à ceux qui ont planifié le transport, à ceux qui les ont fait monter dans le train, à ceux qui les ont conduits, à ceux qui les ont fait descendre, à ceux qui administraient le camp : "pourquoi faîtes-vous ça ?" j'imagine qu'une minorité aurait répondu "par conviction". Les autres auraient tenu le même discours que ci-dessus, à la façon d'un Eichmann. A chacun de placer le curseur de sa morale suivant la situation et ses convictions.
Il est d'ailleurs intéressant de voir que ce juge sait programmer. Ce n'est clairement pas un juriste classique.
Le juge n'avait jamais programmé auparavant, mais il s'est mis à la programmation en Java pour préparer le procès. Pour une procédure portant sur des milliards de dollars, qui plus est bien médiatisée, il n'est pas étonnant que le juge prépare à fond le dossier. C'est donc un juriste classique, et probablement un professionnel consciencieux.
J'ai du mal à comprendre pourquoi, aujourd'hui encore, beaucoup de personnes ne peuvent imaginer les Variations Goldberg sans Glenn Gould.
Personnellement, je préfère de très loin l'enregistrement d'Evgueni Koroliov. D'ailleurs, parmi les 3 prises de Glenn Gould, je n'apprécie que celle de 81. Il chante un peu trop fort, il force parfois un peu trop le trait à mon goût, mais dans la prise de 55 on a vraiment l'impression qu'il a un train à prendre dès la sortie du studio, ou qu'il a fait un pari stupide.
J'ai aussi une certaine tendresse pour la version de Lifschitz. Parmi les pianistes en exercice, Xiao-Mei est intéressante sur cette œuvre. Si on veut entendre une interprétation plus originale, Martin Stadtfeld est une curiosité pas désagréable à mes oreilles.
J'espère que ceux qui ne connaissent que Glenn Gould auront l'occasion de découvrir d'autres interprétations parmi la myriade disponible.
J'ai plutôt apprécié cette nouvelle version. Le son est excellent. Globalement, je trouve l'interprétation un peu trop sage, et certains tempos m'ont déplu (par exemple, la variation 5 est bien trop lente à mon goût), mais je la préfère tout de même à certains de mes enregistrements "commerciaux".
Posté par rogo .
En réponse à la dépêche Perl 5.16.0.
Évalué à 3.
Je ne comprends vraiment pas ça. De ce que j'en ai vu Perl6 c'est du perl en mieux, d'ailleurs des fonctionnalités de perl6 ont étaient backportées dans perl5.
J'ai l'impression que cette idée que perl6 n'est pas le même langage est juste pour contrer les trolls sur le temps qu'il met à sortir.
Tout dépend de la perception de chacun. Pour moi, c'est un nouveau langage, inspiré de Perl5.
Quelques exemples simples, extraits de Perl5 to Perl6 :
my Int $x = 3;
$x = "foo"; # error
# Tableaux
say "@array[1]"; # same sigil for array values
my @c = @b.map({$_ * 2 }); # map is also a method, yes
# Hashes
my %drinks = France => 'Wine', USA => 'Coke';
say "The people in France love ", %drinks{'France'};
say %drinks<Bavaria>;
Je ne vois pas où est le problème.
De façon générale, quand on intègre une nouvelle pièce, je ne vois comment on pourrait éliminer le débat technique. Il est normal que la communauté des développeurs du noyau critique ou soutienne un patch intrusif. Et convaincre un groupe hétéroclite est souvent difficile. Cela m'inquiéterait beaucoup si un module de ce genre pouvait entrer dans Linux comme une lettre à la poste, juste avec l'accord d'un ou deux mandataires Linux.
Dans ce cas particulier, je vois encore moins pourquoi ils se seraient pressés. Pour les distributions ou les installations à fort besoin en sécurité, SELinux et consorts sont là et YAMA n'apporte alors rien de neuf. Pour les autres, le patch était dispo s'ils voulaient ce petit surplus de sécurité, et certaines distrib ont fait ce choix sans attendre l'intégration officielle.
Personnellement je suis un peu dégouté je viens de passer toutes mes installations à 3.3.6 ce week end…
Je suis peut-être parano, mais je ne passe jamais aux nouvelles versions majeures du noyau. En tout cas pas sur les machines dont la stabilité est importante pour moi. Je crois que la 3.3.6 est plus fiable que la 3.4 dont les nouvelles fonctionnalités n'ont pas été testées à très grande échelle. Alors si aucune des nouveautés ne me semble immédiatement utile, en particulier en terme de support matériel, j'attends que de nouvelles versions mineures sortent.
L'exemple de modèle que tu donnes me paraît justement le cas où un SGBD relationnel s'en sort bien en général.
Pourtant, tout ce que tu as écrit me conforte dans ma position. Pour rappel, elle est de séparer les bases de stockage et de recherche.
Tu dis qu'il faudrait changer de moteur de SGDBR, tester plusieurs syntaxes SQL en fonction d'une multitude de paramètres, et qu'alors on trouvera sans doute une requête plus rapide (avec en exemple une requête qui prenait quelques minutes). Or justement j'écrivais : « On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel. »
La requête optimale pour un cas particulier ne m'intéresse pas souvent. En général, j'ai un formulaire de recherche (web, ou dans un client lourd, voire des paramètres CLI) et je dois générer la requête automatiquement. Oh, rien de bien méchant, ce ne sont souvent que 2 ou 3 champs de recherche textuelle, et 5 ou 6 filtres sur des paramètres numériques. Du genre : les posts contenant les mots [A], avec un tag dans [B], mais sans tag parmi [C], et publiés dans une des catégories [D] mais pas [E], etc, etc. Générer le SQL optimal (en supposant qu'on a déjà les bons indexes et tous les paramètres optimaux du serveur) ne sera pas une mince affaire, surtout si on veut une réponse dans la seconde. Alors que si on stocke les données "cherchables" dans une base NoSQL dénormalisée dédiée à la recherche, type Lucene ou Sphinx Search, la requête sera triviale à construire, et quelques millions d'attributs n'empêcheront pas une réponse en une fraction de seconde.
Ta requête a une coquille (il y a une jointure en trop. Pour ma seconde j'avoue y être allé un peu vite. Le principe c'est de créer 2 ensembles dans le FROM un avec les postes qui ont un tag « linux » et un avec tout les identifiants qui ont le tag « sql », puis on fait des opérations ensemblistes entre.
Effectivement, la seconde jointure est inutile pour la recherche. En fait, je l'avais ajoutée pour pouvoir récupérer la liste des tags par un "GROUP_CONCAT", comme je le faisais dans mon premier commentaire. Et après je me suis mélangé les pinceaux.
Je viens de tester sur un serveur MySQL avec une table de relations de 600k lignes. La requête prend 0.8s. Avec les mêmes critères et sur les mêmes données (dénormalisées), Sphinx me répond en 0,01 s. (avec une syntaxe simplissime).
Je rappelle que le fond de ma remarque n'était pas de critiquer SQL, mais de montrer qu'un stockage relationnel fiable et cohérent n'était pas toujours adapté à la recherche des données.
Les vues matérialisées ou les tables mises à jour par cron peuvent être une solution, mais on n'atteindra pas la puissance d'une solution de recherche dédiée. Il me semble plus "rentable", pour opitmiser la recherche, de greffer Sphinx Search sur sa base relationnelle plutôt que de la partitionner.
Quant aux requêtes proposées, la première n'est pas possible en MySQL (pas de "MINUS"). Je doute qu'elle soit efficace, mais j'admets que je me base sur une impression.
Pour la seconde, AMHA elle me semble complètement fausse en l'état. Ce qui prouverait que la requête nécessaire est complexe. J'aurais écris qqchose comme :
Exemple en MySQL, en prenant des tags d'id 22 et 33. La requête suivante est simple, mais fausse :
SELECT DISTINCT p.*, GROUP_CONCAT(pt1.tag_id) AS tags_id
FROM Post AS p
JOIN Post_Tag AS pt1 ON (p.id = pt1.post_id)
JOIN Post_Tag AS pt2 ON (p.id = pt2.post_id)
WHERE pt1.tag_id = 22
AND pt2.tag_id != 33 -- cette dernière condition sera toujours remplie si la précédente l'est
On peut s'en sortir avec :
SELECT p.*, GROUP_CONCAT(pt.tag_id) AS tags_id
FROM Post AS p
JOIN Post_Tag AS pt ON (p.id = pt.post_id)
GROUP BY p.id
HAVING MAX(pt.tag_id = 22) = 1 AND MAX(pt.tag_id = 33) = 0
S'il y a plus simple et plus efficace, je suis preneur.
Je n'ai pas testé ces requêtes, je ne garantis pas l'absence de fautes de syntaxe, mais le principe est que les règles "SAUF" sont difficiles sur du many2many.
De mémoire, les tailles de "Post" et "Post_Tag" étaient respectivement de l'ordre de 500k et 800k lignes et le temps de réponse de 4 secondes.
On peut aussi imaginer utiliser une base relationnelle et y stocker les données en vrac.
Suite au grand ramdam sur le NoSQL, beaucoup ont eu l'idée d'utiliser les moteurs de stockage des bases relationnelles pour en faire des SGBD non-relationnels de type clé-valeur. Par exemple, PostgreSQL Hstore et son pendant MySQL.
Après des années d'utilisation des SGBD (en fait, surtout MySQL et SQLite avec un peu de PostGreSQL), j'étais convaincu de leurs capacités, mais frustré de leurs limitations. Deux exemples simples :
On a une relation many2many ("Post"—"Tag") et on recherche les "posts" qui ont le tag "linux" mais pas celui "sql". On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel.
On gère une liste ordonnée (de "Tag") que l'utilisateur peut réordonner à sa guise. En mode relationnel, cela implique de gérer une table relationnelle où chaque enregistrement a une position numérique qu'il faut recalculer globalement en cas de modification locale. C'est là aussi un calvaire.
Autre besoin fréquent, la recherche en texte entier. Les SGDBR sus-cités y ont fait de gros progrès, mais cela reste limité par rapport aux outils spécialisés. J'ai cherché du côté des bases NoSQL orientées documents qui permettent effectivement de résoudre les problèmes ci-dessus. Mais, en plus des problèmes de maturité et de confiance, la perte du modèle relationnel est parfois très pénible pour des données qui suivent bien ce modèle. Et (avant l'apparition d'Elasticsearch) aucune de ces bases NoSQL ne permettait la recherche en texte intégral.
Finalement, j'ai adopté une solution qui me satisfait (presque) totalement :
séparer la base de stockage (normalisée) de la base de recherche (dénormalisée),
sérialiser certaines données stockées.
Pour sérialiser, PostGres propose un type "array". On peut aussi utiliser un texte JSON qui est portable et plus simple à gérer en amont. C'est très pratique à manipuler dans le langage applicatif. On ne peut plus trop faire de recherche SQL dessus, mais ce n'est pas un problème puisque seules les recherches basiques restent en SQL.
Pour la base de recherche, on a le choix entre Lucene/Solr, Sphinx search, Xapian, etc.
La seule difficulté, c'est de gérer l'indexation, c'est-à-dire l'extraction des données stockées pour les indexer, et surtout la synchronisation des données.
Effectivement, Elastic Search est assez comparable à MongoDB, avec en plus la recherche en texte intégral. Je l'aurais plutôt compaté à CouchDB qui a lui aussi une interface REST.
Par contre, en terme de légèreté et de consommation mémoire, ils ne sont pas dans la même catégorie. Le premier, ES, est une surcouche Java sur Lucene (Java) avec une API REST. Le second, MongoDB, est en C++ avec une API native. En pratique, même avec des petits jeux de données, ES est à l'étroit dans un VPS avec 1 Go de RAM.
A noter que MongoDB prévoit d'ajouter des index en texte intégral en 2012. https://jira.mongodb.org/browse/SERVER-380 : le ticket est dans le "Bucket A" qui désigne les fonctionnalités prévues pour la prochaine version majeure.
On commence nier avoir écrit que "l'annulaire puisse servir à quelque chose d'autre qu'à se gratter l'orreille" et on finit par déclarer devant 18 millions de personnes qu'on n'est jamais allé collecter des fonds au Carlton, malgré les vidéos qui prouvent le contraire. Heureusement qu'on sait maintenant détecter scientifiquement les délinquants dès la maternelle, la police pourra bientôt se dire en légitime défense d'office pour les éliminer à la vraie perpétuité afin qu'ils ne gênent pas les vrais travailleurs.
Hmm, je crois que cette élection me fait un peu péter les plombs…
Ou alors… Est-ce que les développeurs sont sur MAC? (donc n'ont pas encore réussi à se faire à à l'idée que l'annulaire puisse servir à quelque chose d'autre qu'à se gratter l'orreille… :-) )
Erreur fatale. Confusion de l'annulaire avec l'auriculaire.
Bien sûr, certains mettent des anneaux aux oreilles, qu'ils appellent alors "boucles" pour leur donner un air capillaire, mais le doigt de l'anneau ne doit pas être confondu avec le doigt de l'oreille, sinon c'est le bordel et on n'est plus du tout crédible pour signaler des "bestioles" à Gimp ;-)
Une suggestion pour le site FlossManuals : les versions HTML pourraient déclarer les pages suivantes et précédentes. Cela simplifierait beaucoup la lecture puisque la plupart des navigateurs passe à la page suivante avec Alt-droite ou Espace en fin de page (ou une mouse gesture si on navigue à la souris). Cf http://www.w3.org/TR/html401/struct/links.html#h-12.1.2.
Posté par rogo .
En réponse à la dépêche Xfce 4.10 est disponible !.
Évalué à 2.
Dernière modification le 01 mai 2012 à 13:18.
Moi aussi, je suis un utilisateur très satisfait de XFCE depuis des années. Je ne vois qu'un seul changement qui m'intéresse, c'est l'intégration de gnome-keyring. Actuellement, j'ai très souvent des messages d'erreurs comme quoi gnome-keyring ne trouve pas certains fichiers temporaires. J'avais vu dans le bug Debian que c'était parce qu'XFCE ne le cajolait pas assez. Si j'en crois le changelog, ça devrait changer.
Sinon, je n'essaierai pas le "panel" sur le côté, car j'ai adopté une organisation qui me plaît bien.
une barre des tâches auto-masquée, sur tout le bas de l'écran ;
un panneau auto-masqué de lanceurs d'applications et de bureaux, sur une portion du haut de l'écran ;
des onglets latéraux dans le navigateur web (jusqu'à 38 onglets aux titres biens lisibles, un peu moins s'il y a des groupes d'onglets).
Je ne maîtrise ni lighttpd ni nginx, mais ma faible expérience me fait préférer sans hésiter nginx qui me semble bien plus riche en fonctionnalités, en étant au moins égal sur tous les autres points (simplicité de config, performance, etc).
J'avais un petit serveur perso avec lighttpd qui servait des fichiers statiques. J'ai eu besoin d'y greffer une application python, avec le protocole uwsgi. Dans lighttpd, il fallait passer par un module externe, à compiler soi-même (il est maintenant en Debian testing). Dans nginx, c'était fourni d'entrée dans le paquet Debian. Du coup, j'ai migré. J'en ai ensuite profité pour ajouter à nginx un comportement de reverse-proxy devant Apache, ce qui fut étonnamment simple.
Je n'utilise ni Windows ni awesome, donc je ne sais pas ce que tu entends par du "tiling à la Windows 7" opposé au "tiling complet". Si j'en crois le descriptif lu en diagonale, la fonctionnalité imitait Windows 7 et KDE avant de diverger un peu. Grosso modo, cela maximise la fenêtre verticalement ou horizontalement, mais sans tenir compte des fenêtres pré-existantes. Cf le ticket qui introduit ce patch : https://bugzilla.xfce.org/show_bug.cgi?id=6648
Le gouvernement hongrois qui soutient l'ODF est à peine plus respectable que le furent ceux de Moubarak ou Berlusconi. Il s'est mis l'Europe à dos pour avoir fait voté des lois et une modification de la constitution qui restreignent les libertés individuelles, la liberté de la presse et les contre-pouvoirs de l'opposition. Le président hongrois et sa majorité sont mis en cause dans plusieurs scandales de corruption et d'expropriations abusives. Je passe sur les dérapages xénophobes, ce n'est pas très original. Plusieurs journalistes ont montré que les proches du pouvoir récupéraient la plupart des marchés publics via des sociétés-écrans. Une entreprise américaine vient de porter plainte après qu'on lui a retiré ses deux licences de radio en hongrie : elle affirme qu'elle a été expulsée car elle avait refusé de payer un pot-de-vin aux politiques.
Certes, tout cela n'a rien à voir avec le logiciel libre, mais cela me rend dubitatif sur la destination réelle de l'argent promis par le gouvernement hongrois. Ça me gêne aussi de me dire que le principal soutien d'ODF en Europe est le gouvernement le moins démocratique. Je fais du logiciel libre aussi par conviction éthique, donc difficile d'ignorer ce contexte non-technique.
[^] # Re: avantage ?
Posté par rogo . En réponse à la dépêche Sortie de Rust en version 0.3. Évalué à 10.
J'ai moi aussi du mal à comprendre l'intérêt de ce langage, mais pour des raisons indépendantes de sa syntaxe.
Un langage créé par Mozilla pour développer un navigateur de Mozilla, il y a peu de chance qu'il attire une large communauté. Surtout quand l'offre en langages de programmation est déjà pléthorique. J'imagine que ce sera plutôt une barrière à l'entrée de ce nouveau navigateur web : si vous voulez collaborer, il faut d'abord apprendre le langage maison. Ça risque d'en refroidir plus d'un. Moi en tout cas je ne propose des patches que dans les langages que je connais déjà.
Mais surtout, j'ai des doutes sur la pérennité de ce choix. La dépêche met en avant des impératifs de sécurité et de performance. Ce sont des domaines qui requièrent des experts. Est-ce que la fondation Mozilla disposera toujours de plusieurs experts en compilateurs ? Quand je vois sa position sur XUL ou Thunderbird, je suis d'autant plus dubitatif.
Je me demande s'il n'aurait pas été possible d'adopter un langage déjà présent, avec une communauté déjà formée et si possible des experts déjà au travail sur l'implémentation. Je pense bien sûr à Go qui a beaucoup de points communs avec Rust, et sur lequel Google apporte une certaine garantie de qualité et de pérennité. Est-ce qu'un fork du compilateur accompagné de quelques bibliothèques n'aurait pas suffit ? Idem avec OCaml, D, ou Scala, voire Haskell. Malheureusement, je ne suis pas assez compétent pour répondre à mon interrogation.
Bref, j'ai un peu peur que Mozilla soit victime du syndrome "Not Invented Here".
[^] # Re: Orson Wells l'avait presque prédit !
Posté par rogo . En réponse à la dépêche Nuageuse mise à jour des routeurs Cisco et premiers grondements. Évalué à 2.
Aïe, à mon tour de me faire taper sur les doigts. Effectivement, je ne pensais pas à Boris Vian et son Arrache-cœur, mais au truc écrit par Salinger.
Par contre, que l'on ne soit pas d'accord sur tout ne me surprend pas. Certains aiment vi, d'autres emacs, d'autres aucun, etc. Il y a des logiciels, des livres et des films qui ne sont pas pour moi, mais que d'autres savent apprécier. Je résiste à la tentation de continuer ici une critique littéraire sauvage, ce n'est pas le lieu.
[^] # Re: Orson Wells l'avait presque prédit !
Posté par rogo . En réponse à la dépêche Nuageuse mise à jour des routeurs Cisco et premiers grondements. Évalué à 8.
Je reconnais que c'était une provocation gratuite. Mais assumée.
J'espère que tous les cinéphiles ne sont pas des fanatiques de "Citizen Kane". Moi qui me sens plutôt "littérophile", je déteste allègrement certains chefs d'œuvre. Par exemple, je trouve "Salambô" de Flaubert plus pénible et plus ridicule que les plus ratés des romans de Victor Hugo. Et je m'ennuie profondément dans beaucoup de romans modernes acclamés par la critique, de "Sur la route" jusqu'à "De sang-froid" en passant par "L'arrache-cœur". Ce qui ne m'empêche pas d'adorer certains auteurs classiques, par exemple Shakespeare ou Rabelais.
De 1984 au meilleur des mondes
Pour en revenir au sujet initial, c'est-à-dire le rôle de "Big Brother" que prend Cisco aujourd'hui, mon cauchemar serait plutôt du côté du "Meilleur des mondes". Chacun se satisferait de sa situation : « j'ai une petite vie sans problème, je peux consommer librement, je peux baiser librement, je peux regarder la télé, tout va bien et je ne vais pas me casser la tête avec des problèmes moraux ou des réflexions politiques ; il y a des professionnels formés pour ça, heureusement que je n'ai pas à m'en occuper ». Plus que la surveillance, c'est ce conditionnement mental qui me fait peur, cette flemme intellectuelle et ce dédain de toute politique au sens large. Heureusement qu'il reste des gens pour réfléchir et râler, ici et ailleurs.
[^] # Re: Orson Wells l'avait presque prédit !
Posté par rogo . En réponse à la dépêche Nuageuse mise à jour des routeurs Cisco et premiers grondements. Évalué à 9.
Juste pour remettre les noms en place : "1984", c'est l'œuvre de George Orwell.
Je le confonds parfois avec H. G. Wells ("L'île du docteur Moreau", "La guerre des mondes", etc) mais jamais avec Orson Welles (et son film prétentieux "Citizen Kane" au fameux "rosebud").
Dans la série, y'a aussi "Fargo Wells", mais je dérive…
[^] # Re: Encore une référence
Posté par rogo . En réponse au journal Arnaud Montebourg se sarkozyse (la free telecom song).. Évalué à 6.
Cette histoire de South Park ressemble énormément à un film de 1951, The Man in the White Suit (en français, L'Homme au complet blanc) : un jeune chimiste invente un tissu très résistant et peu salissant. Les industriels et les politiques s'allient alors avec les syndicats pour faire disparaître cette invention, de gré ou de force. C'est un classique du cinéma, mais je ne pense pas qu'il ait été le premier à traiter ce sujet.
# Guerres picrocholines
Posté par rogo . En réponse à la dépêche MPlayer saute la version 1.0 et nous livre la 1.1. Évalué à 3.
Je me trompe peut-être, mais je suppose que les affrontements internes aux développeurs de MPlayer ont retardé la sortie d'une version officiellement stable. Je ne me souviens pas des détails, mais en 2004 certains avaient évoqué un coup d'État pour éliminer les fondateurs. Je ne prends pas partie dans ce vieux conflit, je ne connais pas les faits, et les détails ne m'intéressent pas.
Par ailleurs, il existe un fork plutôt actif, MPlayer2. Il est distribué dans Debian (ou avec git si on est prêt à installer les nombreuses dépendances). Je l'avais adopté à un moment où le trunk du MPlayer officiel ne compilait plus chez moi depuis plusieurs semaines. Le site de MPlayer2 contient une liste des différences.
[^] # Re: Encore une fois...
Posté par rogo . En réponse à la dépêche Nouvelles technologies à l’assaut de la démocratie éthiopienne. Évalué à 2.
Si mes grand-parents avaient demandé à ceux qui ont planifié le transport, à ceux qui les ont fait monter dans le train, à ceux qui les ont conduits, à ceux qui les ont fait descendre, à ceux qui administraient le camp : "pourquoi faîtes-vous ça ?" j'imagine qu'une minorité aurait répondu "par conviction". Les autres auraient tenu le même discours que ci-dessus, à la façon d'un Eichmann. A chacun de placer le curseur de sa morale suivant la situation et ses convictions.
# Du classicisme du juge
Posté par rogo . En réponse à la dépêche Oracle riche de plusieurs milliards de zero !. Évalué à 3.
Le juge n'avait jamais programmé auparavant, mais il s'est mis à la programmation en Java pour préparer le procès. Pour une procédure portant sur des milliards de dollars, qui plus est bien médiatisée, il n'est pas étonnant que le juge prépare à fond le dossier. C'est donc un juriste classique, et probablement un professionnel consciencieux.
Je ne sais plus où j'avais lu ça, mais on retrouve l'info sur Wired : http://www.wired.com/wiredenterprise/2012/05/oracle-google-judge-dismiss/
[^] # Re: Il y a Bach sans Gould et Bach avec Gould...
Posté par rogo . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 10. Dernière modification le 30 mai 2012 à 14:31.
J'ai du mal à comprendre pourquoi, aujourd'hui encore, beaucoup de personnes ne peuvent imaginer les Variations Goldberg sans Glenn Gould.
Personnellement, je préfère de très loin l'enregistrement d'Evgueni Koroliov. D'ailleurs, parmi les 3 prises de Glenn Gould, je n'apprécie que celle de 81. Il chante un peu trop fort, il force parfois un peu trop le trait à mon goût, mais dans la prise de 55 on a vraiment l'impression qu'il a un train à prendre dès la sortie du studio, ou qu'il a fait un pari stupide.
J'ai aussi une certaine tendresse pour la version de Lifschitz. Parmi les pianistes en exercice, Xiao-Mei est intéressante sur cette œuvre. Si on veut entendre une interprétation plus originale, Martin Stadtfeld est une curiosité pas désagréable à mes oreilles.
J'espère que ceux qui ne connaissent que Glenn Gould auront l'occasion de découvrir d'autres interprétations parmi la myriade disponible.
J'ai plutôt apprécié cette nouvelle version. Le son est excellent. Globalement, je trouve l'interprétation un peu trop sage, et certains tempos m'ont déplu (par exemple, la variation 5 est bien trop lente à mon goût), mais je la préfère tout de même à certains de mes enregistrements "commerciaux".
[^] # Re: Perl 6
Posté par rogo . En réponse à la dépêche Perl 5.16.0. Évalué à 3.
Tout dépend de la perception de chacun. Pour moi, c'est un nouveau langage, inspiré de Perl5.
Quelques exemples simples, extraits de Perl5 to Perl6 :
Des exemples plus complexes :
[^] # Re: YAMA
Posté par rogo . En réponse à la dépêche Sortie officielle du noyau Linux 3.4. Évalué à 10.
Je ne vois pas où est le problème.
De façon générale, quand on intègre une nouvelle pièce, je ne vois comment on pourrait éliminer le débat technique. Il est normal que la communauté des développeurs du noyau critique ou soutienne un patch intrusif. Et convaincre un groupe hétéroclite est souvent difficile. Cela m'inquiéterait beaucoup si un module de ce genre pouvait entrer dans Linux comme une lettre à la poste, juste avec l'accord d'un ou deux mandataires Linux.
Dans ce cas particulier, je vois encore moins pourquoi ils se seraient pressés. Pour les distributions ou les installations à fort besoin en sécurité, SELinux et consorts sont là et YAMA n'apporte alors rien de neuf. Pour les autres, le patch était dispo s'ils voulaient ce petit surplus de sécurité, et certaines distrib ont fait ce choix sans attendre l'intégration officielle.
Je suis peut-être parano, mais je ne passe jamais aux nouvelles versions majeures du noyau. En tout cas pas sur les machines dont la stabilité est importante pour moi. Je crois que la 3.3.6 est plus fiable que la 3.4 dont les nouvelles fonctionnalités n'ont pas été testées à très grande échelle. Alors si aucune des nouveautés ne me semble immédiatement utile, en particulier en terme de support matériel, j'attends que de nouvelles versions mineures sortent.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 1.
Pourtant, tout ce que tu as écrit me conforte dans ma position. Pour rappel, elle est de séparer les bases de stockage et de recherche.
Tu dis qu'il faudrait changer de moteur de SGDBR, tester plusieurs syntaxes SQL en fonction d'une multitude de paramètres, et qu'alors on trouvera sans doute une requête plus rapide (avec en exemple une requête qui prenait quelques minutes). Or justement j'écrivais : « On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel. »
La requête optimale pour un cas particulier ne m'intéresse pas souvent. En général, j'ai un formulaire de recherche (web, ou dans un client lourd, voire des paramètres CLI) et je dois générer la requête automatiquement. Oh, rien de bien méchant, ce ne sont souvent que 2 ou 3 champs de recherche textuelle, et 5 ou 6 filtres sur des paramètres numériques. Du genre : les posts contenant les mots [A], avec un tag dans [B], mais sans tag parmi [C], et publiés dans une des catégories [D] mais pas [E], etc, etc. Générer le SQL optimal (en supposant qu'on a déjà les bons indexes et tous les paramètres optimaux du serveur) ne sera pas une mince affaire, surtout si on veut une réponse dans la seconde. Alors que si on stocke les données "cherchables" dans une base NoSQL dénormalisée dédiée à la recherche, type Lucene ou Sphinx Search, la requête sera triviale à construire, et quelques millions d'attributs n'empêcheront pas une réponse en une fraction de seconde.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 2.
Effectivement, la seconde jointure est inutile pour la recherche. En fait, je l'avais ajoutée pour pouvoir récupérer la liste des tags par un "GROUP_CONCAT", comme je le faisais dans mon premier commentaire. Et après je me suis mélangé les pinceaux.
Je viens de tester sur un serveur MySQL avec une table de relations de 600k lignes. La requête prend 0.8s. Avec les mêmes critères et sur les mêmes données (dénormalisées), Sphinx me répond en 0,01 s. (avec une syntaxe simplissime).
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 3. Dernière modification le 09 mai 2012 à 14:17.
Je rappelle que le fond de ma remarque n'était pas de critiquer SQL, mais de montrer qu'un stockage relationnel fiable et cohérent n'était pas toujours adapté à la recherche des données.
Les vues matérialisées ou les tables mises à jour par cron peuvent être une solution, mais on n'atteindra pas la puissance d'une solution de recherche dédiée. Il me semble plus "rentable", pour opitmiser la recherche, de greffer Sphinx Search sur sa base relationnelle plutôt que de la partitionner.
Quant aux requêtes proposées, la première n'est pas possible en MySQL (pas de "MINUS"). Je doute qu'elle soit efficace, mais j'admets que je me base sur une impression.
Pour la seconde, AMHA elle me semble complètement fausse en l'état. Ce qui prouverait que la requête nécessaire est complexe. J'aurais écris qqchose comme :
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 2.
Exemple en MySQL, en prenant des tags d'id 22 et 33. La requête suivante est simple, mais fausse :
On peut s'en sortir avec :
S'il y a plus simple et plus efficace, je suis preneur.
Je n'ai pas testé ces requêtes, je ne garantis pas l'absence de fautes de syntaxe, mais le principe est que les règles "SAUF" sont difficiles sur du many2many.
De mémoire, les tailles de "Post" et "Post_Tag" étaient respectivement de l'ordre de 500k et 800k lignes et le temps de réponse de 4 secondes.
[^] # Re: Intervalle entre SQL et NoSQL
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 5.
Suite au grand ramdam sur le NoSQL, beaucoup ont eu l'idée d'utiliser les moteurs de stockage des bases relationnelles pour en faire des SGBD non-relationnels de type clé-valeur. Par exemple, PostgreSQL Hstore et son pendant MySQL.
# Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 9.
Après des années d'utilisation des SGBD (en fait, surtout MySQL et SQLite avec un peu de PostGreSQL), j'étais convaincu de leurs capacités, mais frustré de leurs limitations. Deux exemples simples :
Autre besoin fréquent, la recherche en texte entier. Les SGDBR sus-cités y ont fait de gros progrès, mais cela reste limité par rapport aux outils spécialisés. J'ai cherché du côté des bases NoSQL orientées documents qui permettent effectivement de résoudre les problèmes ci-dessus. Mais, en plus des problèmes de maturité et de confiance, la perte du modèle relationnel est parfois très pénible pour des données qui suivent bien ce modèle. Et (avant l'apparition d'Elasticsearch) aucune de ces bases NoSQL ne permettait la recherche en texte intégral.
Finalement, j'ai adopté une solution qui me satisfait (presque) totalement :
Pour sérialiser, PostGres propose un type "array". On peut aussi utiliser un texte JSON qui est portable et plus simple à gérer en amont. C'est très pratique à manipuler dans le langage applicatif. On ne peut plus trop faire de recherche SQL dessus, mais ce n'est pas un problème puisque seules les recherches basiques restent en SQL.
Pour la base de recherche, on a le choix entre Lucene/Solr, Sphinx search, Xapian, etc.
La seule difficulté, c'est de gérer l'indexation, c'est-à-dire l'extraction des données stockées pour les indexer, et surtout la synchronisation des données.
[^] # Re: Elasticsearch
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 2.
Effectivement, Elastic Search est assez comparable à MongoDB, avec en plus la recherche en texte intégral. Je l'aurais plutôt compaté à CouchDB qui a lui aussi une interface REST.
Par contre, en terme de légèreté et de consommation mémoire, ils ne sont pas dans la même catégorie. Le premier, ES, est une surcouche Java sur Lucene (Java) avec une API REST. Le second, MongoDB, est en C++ avec une API native. En pratique, même avec des petits jeux de données, ES est à l'étroit dans un VPS avec 1 Go de RAM.
A noter que MongoDB prévoit d'ajouter des index en texte intégral en 2012. https://jira.mongodb.org/browse/SERVER-380 : le ticket est dans le "Bucket A" qui désigne les fonctionnalités prévues pour la prochaine version majeure.
[^] # Re: Quand le clic droit servira-t-il à quelque chose?...
Posté par rogo . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 9.
On commence nier avoir écrit que "l'annulaire puisse servir à quelque chose d'autre qu'à se gratter l'orreille" et on finit par déclarer devant 18 millions de personnes qu'on n'est jamais allé collecter des fonds au Carlton, malgré les vidéos qui prouvent le contraire. Heureusement qu'on sait maintenant détecter scientifiquement les délinquants dès la maternelle, la police pourra bientôt se dire en légitime défense d'office pour les éliminer à la vraie perpétuité afin qu'ils ne gênent pas les vrais travailleurs.
Hmm, je crois que cette élection me fait un peu péter les plombs…
[^] # Re: Quand le clic droit servira-t-il à quelque chose?...
Posté par rogo . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 4.
Erreur fatale. Confusion de l'annulaire avec l'auriculaire.
Bien sûr, certains mettent des anneaux aux oreilles, qu'ils appellent alors "boucles" pour leur donner un air capillaire, mais le doigt de l'anneau ne doit pas être confondu avec le doigt de l'oreille, sinon c'est le bordel et on n'est plus du tout crédible pour signaler des "bestioles" à Gimp ;-)
# Suggestion
Posté par rogo . En réponse à la dépêche Manuel sur les fontes libres enfin publié. Évalué à 5.
Une suggestion pour le site FlossManuals : les versions HTML pourraient déclarer les pages suivantes et précédentes. Cela simplifierait beaucoup la lecture puisque la plupart des navigateurs passe à la page suivante avec Alt-droite ou Espace en fin de page (ou une mouse gesture si on navigue à la souris). Cf http://www.w3.org/TR/html401/struct/links.html#h-12.1.2.
J'ai essayé de faire cette suggestion sur le site, page http://fr.flossmanuals.net/faq-floss-manuals-francophone/ mais j'ai eu droit à un plantage avec le texte "failed to create folder: ../../data/comments/faq-floss-manuals-francophone" sur la page http://fr.flossmanuals.net/widgets/comments/add.php.
[^] # Re: Un environnement utilisable dans un monde de brutes
Posté par rogo . En réponse à la dépêche Xfce 4.10 est disponible !. Évalué à 2. Dernière modification le 01 mai 2012 à 13:18.
Moi aussi, je suis un utilisateur très satisfait de XFCE depuis des années. Je ne vois qu'un seul changement qui m'intéresse, c'est l'intégration de gnome-keyring. Actuellement, j'ai très souvent des messages d'erreurs comme quoi gnome-keyring ne trouve pas certains fichiers temporaires. J'avais vu dans le bug Debian que c'était parce qu'XFCE ne le cajolait pas assez. Si j'en crois le changelog, ça devrait changer.
Sinon, je n'essaierai pas le "panel" sur le côté, car j'ai adopté une organisation qui me plaît bien.
[^] # Re: NginX & lighttpd
Posté par rogo . En réponse à la dépêche Nginx 1.2, des progrès sur le code et les parts de marché. Évalué à 5. Dernière modification le 01 mai 2012 à 13:03.
Je ne maîtrise ni lighttpd ni nginx, mais ma faible expérience me fait préférer sans hésiter nginx qui me semble bien plus riche en fonctionnalités, en étant au moins égal sur tous les autres points (simplicité de config, performance, etc).
J'avais un petit serveur perso avec lighttpd qui servait des fichiers statiques. J'ai eu besoin d'y greffer une application python, avec le protocole uwsgi. Dans lighttpd, il fallait passer par un module externe, à compiler soi-même (il est maintenant en Debian testing). Dans nginx, c'était fourni d'entrée dans le paquet Debian. Du coup, j'ai migré. J'en ai ensuite profité pour ajouter à nginx un comportement de reverse-proxy devant Apache, ce qui fut étonnamment simple.
Au passage, la doc de nginx est très riche en exemples. Par exemple http://wiki.nginx.org/Configuration
[^] # Re: Tiling
Posté par rogo . En réponse à la dépêche Xfce 4.10 est disponible !. Évalué à 1.
Je n'utilise ni Windows ni awesome, donc je ne sais pas ce que tu entends par du "tiling à la Windows 7" opposé au "tiling complet". Si j'en crois le descriptif lu en diagonale, la fonctionnalité imitait Windows 7 et KDE avant de diverger un peu. Grosso modo, cela maximise la fenêtre verticalement ou horizontalement, mais sans tenir compte des fenêtres pré-existantes. Cf le ticket qui introduit ce patch : https://bugzilla.xfce.org/show_bug.cgi?id=6648
# Des soutiens embarrassants
Posté par rogo . En réponse à la dépêche Petites brêves : ODF et Cassandra. Évalué à 10. Dernière modification le 29 avril 2012 à 23:01.
Le gouvernement hongrois qui soutient l'ODF est à peine plus respectable que le furent ceux de Moubarak ou Berlusconi. Il s'est mis l'Europe à dos pour avoir fait voté des lois et une modification de la constitution qui restreignent les libertés individuelles, la liberté de la presse et les contre-pouvoirs de l'opposition. Le président hongrois et sa majorité sont mis en cause dans plusieurs scandales de corruption et d'expropriations abusives. Je passe sur les dérapages xénophobes, ce n'est pas très original. Plusieurs journalistes ont montré que les proches du pouvoir récupéraient la plupart des marchés publics via des sociétés-écrans. Une entreprise américaine vient de porter plainte après qu'on lui a retiré ses deux licences de radio en hongrie : elle affirme qu'elle a été expulsée car elle avait refusé de payer un pot-de-vin aux politiques.
Certes, tout cela n'a rien à voir avec le logiciel libre, mais cela me rend dubitatif sur la destination réelle de l'argent promis par le gouvernement hongrois. Ça me gêne aussi de me dire que le principal soutien d'ODF en Europe est le gouvernement le moins démocratique. Je fais du logiciel libre aussi par conviction éthique, donc difficile d'ignorer ce contexte non-technique.