FantastIX a écrit 1338 commentaires

J'ai vu ou lu quelque part (peut-être dans un Linux Magazine) qu'il y avait aussi un réglage pour un composant appelé “ascenseur” (elevator?) dans le cadenceur d'entrées/sorties (IO scheduler). Dans le cas des SSD, on peut le régler sur "noop" pour éviter tout l'algorithme d'ordonancement. Je ne connais pas l'impact chiffré de ses effets par contre.

… c'est quand l'interface d'administration du CMS sera réellement séparée du site, évitant enfin que www-data soit le propriétaire de tous les fichiers du site. Est-ce le cas ici?

Ok, du coup effectivement pour des partitions qui ne servent que tous les 36 du mois ça peut peut-être valoir le coup…

Voilà. Genre les clés USB, les disques externes, tous les périphériques qu'on branche en sachant très bien qu'on va s'en servir tout de suite…

Merci!

Ton commentaire et cet article m'ont enfin permis de mettre un nom sur une impression persistente: pourquoi le libre est-il si délaissé alors que je l'ai adopté par conviction? Comment se fait-il que je sois le seul à l'avoir perçu? Pourquoi devrait-ce être moi qui ai l'esprit fermé? Comment se fait-il que personne ne semble comprendre d'où me viennent mes convictions? Pourquoi ai-je tant de mal à transmettre ou faire partager ce qui pour moi est d'une évidence solaire? (Et en particulier à ceux qui font le même métier que moi)… etc etc bref, toutes les questions existentielles qui te viennent sur ce sujet particulier.

L'article de Zylabon et ton commentaire ne sont pas incompatibles pour moi. On a d'un côté la réflexion du libriste convaincu, sans compromis, de l'autre le pragmatique qui a compris comment «les autres» fonctionnent, si je puis résumer ainsi.

Je constate aussi dans la plupart des cas que les gens n'ont rien à faire de la liberté [dans le logiciel au moins]. Quant aux explications, tu en as donnés d'excellentes alors que je n'arrêtais pas de me demander pourquoi. Je pense en effet que l'informatique est une chose abstraite pour la plupart des gens, qui n'ont aucune envie ni besoin de comprendre — combien de fois entends-je des incongruités du genre « ce sont les mystères de l'informatique » … Par contre je ne sais si c'est le besoin de rêver ou les sirènes de l'ignorance qui les maintient dans cette torpeur confortable. (« Ignorance is bliss »…)

Mais au final, ce qui est rassurant, c'est que le monde — je veux dire l'intégralité des utilisateurs de l'outil informatique quel qu'il soit — devra d'abord faire sa révolution copernicienne avant de commencer à s'intéresser sérieusement à ces questions philosophiques qui nous occupent depuis longtemps, nous les «geeks», «sociopathes» et «névrosés»; et ça confirme en substance ce que je pense depuis le début: notre devoir est de continuer sans relâche à éduquer, informer et répéter inlassablement, jusqu'à ce que le déclic se fasse. Ce passage est incontournable.

Je n'ai plus la référence en tête mais il me semblait pourtant que Damn Small Linux avait sorti une nouvelle version récemment… Quelqu'un peut confirmer? ou pas?

Je suis passé à des environnements plus légers pour plusieurs raisons. D'abord j'utilise Gentoo depuis le début (2004) et la compilation de KDE est énorme par défaut; il m'aurait fallu passer un temps non négligeable à ne sélectionner que les paquets dont j'avais besoin. Mais je débutais et, assez paradoxalement, je voulais aussi découvrir. Je n'avais juste pas assez de temps pour tout faire. Aussi plusieurs applications ne me donnaient pas entière satisfaction dont la messagerie (avec KMail si j'ai bonne mémoire). J'ai commencé par installer des applications GTK, qui sont devenues mes applications récurrentes par la suite.

C'était à la naissance de KDE 4, je n'avais pas envie d'attendre que les bugs soient corrigés et que KDE 4 soit stable. Et comme ça me paraissait un peu trop de maintenir deux ensembles de bibliothèques, je suis passé à GTK seul. Je reconnais que QT et tout l'environnement KDE représente un travail magnifique et mérite une position de choix. Mais sous Gentoo, c'est trop lourd pour moi et je préfère une distro à compiler, mon choix est fait ;) .

Les points forts de KDE, que j'ai toujours admirés, étaient notamment les mises à niveau: elles m'ont rarement (voire presque jamais) occasionné de purger mon profil et de recommencer le paramétrage de tout mon environnement de bureau (je crois avoir gardé mon profil initial de KDE 3.2 à KDE 3.5, dans les grandes lignes). Ce n'était pas le cas avec les mises à niveau de Gnome qui, invariablement, provoquaient des erreurs au démarrage de ma session, me forçant, par dépit, à purger les répertoires cache et config. Mais bon, ça, c'était avant KDE :D . Aujourd'hui j'ai Xfce, il me fait moins d'histoires.

À propos de DeadBeef, ça a l'air vraiment intéressant. La lecture gapless est un des quelques points faibles de Exaile. (Du moins pour le moment, je n'ai pas vérifié la toute dernière version.) Il ne se trouve pas dans Portage mais je vois qu'il existe un overlay pour lui. Je l'essaierais bien, ça me tente.

J'ai découvert Amarok du temps où KDE 3.5 était installé sur ma machine. Ça fait quelques années que je n'utilise plus KDE mais Amarok reste le lecteur Audio de mes favoris, en d'autres termes, aucun autre lecteur [audio] ne m'a autant satisfait que celui-là. [ Hors-sujet: N'utilisant que des applications GTK aujourd'hui, j'ai décidé de me contenter d'Exaile, qui me rappelle cet excellent lecteur et, pour mes propres besoins, est un assez bon compromis. Il a juste besoin d'un peu d'amour ;-). ]

Je tente une transposition dans le langage de programmation C.

Cette transposition est inappropriée. Je parle du langage textuel utilisé par la syntaxe. Tu ne peux comparer des symboles (+, -, *, /, =) avec du langage textuel (insert, update, set) car la compréhension et l'appréhension des deux ne repose pas sur les mêmes bases. On n'aborde pas un symbole et un mot de la même manière.

C'est peut-être plus clair quand on connait le principe sous-jacent.

Et c'est précisément là mon opposition: la syntaxe est intuitive si elle se suffit à comprendre les effets d'une opération (au sens général). Si "c'est plus clair en connaissant les principes sous-jacents" c'est précisément que la syntaxe n'est pas intuitive.

Toute mon argumentation repose sur le simple fait que l'auteur de la démo s'attendait à ce qu'il y ait confusion, c-à-d à ce que la fonction update() n'est pas intuitive. Et je ne fais qu'expliquer en quoi elle ne l'est pas.

Je te suggère de lire (si ce n'est déjà fait) mes commentaires plus bas et celui de lothiraldan.

Par contre, le fait qu'on remplace le document quand on ne met de modifier n'est pas des plus intuitif, on est d'accord

Bien :-) .

Mais il ne faut pas oublier qu'il n'y a pas que $set qu'on peut utiliser avec update, ya aussi tout celà : http://www.mongodb.org/display/DOCS/Updating#Updating-ModifierOperations.

Je me doutais effectivement qu'il ne devait pas y avoir que $set mais, si on y réfléchit, il aurait été tout aussi simple, peut-être même plus, de définir inc(), set(), unset(), push(), etc en tant que fonctions, non? genre db.unicorns( {name: 'mathusalem'} ).set( {age: 'unknown'} ) . N'est-ce pas plus simple?

Et comme on peut les combiner entre eut (on peut mettre un $inc et un $set dans la même requête), ça permet d'avoir une api cohérente je trouve.

L'API est sans doute cohérente avec elle-même mais pas nécessairement intuitive. Si on sait que les modificateurs renvoient tous le document sur lequel ils agissent, pourquoi pas

    db.unicorns( {name: 'mathusalem'} ).set( {weight: 'unknown'} ).inc( {age: 900} )

L'API actuelle apporte du bruit inutile; pourquoi imposer l'utilisation d'une méthode update() alors qu'on sait très bien (ou devrait savoir) quel sera l'effet du modificateur, surtout si ce modificateur a un nom suffisamment intuitif, ce qui a l'air d'être le cas. Au final, update() ne sert qu'à rappeler qu'on va faire une modification mais dont la portée ou la signification est déterminée par le modificateur qu'on lui passe, ce qui ajoute encore à la confusion possible. Donc éliminer update() (qui n'apporte rien) et convertir les modificateurs en fonctions serait plus logique et donnerait une syntaxe plus claire et facile à appréhender, selon moi.

Ah oui, je préfère aussi mais alors nettement ça

    db.unicorns( {name: 'mathusalem'} ).unset( [age, weight] )

à ceci

    db.unicorns( {name: 'mathusalem'} ).unset( {age: 1, weight: 1} )

Le ": 1" est du bruit inutile, {age: 0} n'a pas plus de sens que {age: 42}; cette syntaxe devrait être simplifiée.

Une petite analogie, pour se détendre?

MongoDB: J'ai mis à jour le verre de Canada Dry par du Whisky.
FantastIX: Non, tu as remplacé le Canada Dry par du Whisky, je me fous du verre!
MongoDB: Mais non! J'ai mis à jour le Canada Dry par du Whisky.
Le client: Sont devenus zinzins, m'en vais voir au café d'en face!

Ensuite concernant la méthode update, je vois pas trop de quoi tu parle.

db.test.update({'a': 'a'}, {$set: {'b': 'd'}})

J'ai omis de préciser que c'est justement cet argument "$set" qui me pose ce problème de sémantique.

Update a besoin d'un argument supplémentaire, $set, pour qu'on se ramène à ce que je conçois intuitivement d'une mise à jour, c-à-d la modification partielle des propriétés du document. Pour dire comme Coluche: «c'est plus long, faut faire le nœud!»

J'irais même jusqu'à dire que l'usage de "update()" et "set$" conjointement remplissent des fonctions dont la signification intuitive de l'une est la mise en oeuvre de l'autre, à savoir update() = mise à jour partielle et $set = remplacement. De plus update( …. {property1: value} ) — donc sans l'argument $set — est, dans les faits, un remplacement du document. Bref…

Considérons la situation suivante:

• update( doc_id, array_of_properties ) met à jour les propriétés correspondantes du document. Si certaines propriétés de array n'existent pas dans le document, elles sont ajoutées. C'est l'équivalent d'une fusion entre les deux collections de propriétés, celles du document et l'argument.

• replace( doc_id, array_of_properties ) remplace le[s propriétés du] document par les propriétés indiquées dans l'argument.

Ces deux fonctions sont intuitives, parlent d'elles-mêmes, sans ambiguïté et n'ont pas besoin du degré de complexité (support de la fonction $set) pour correspondre à l'idée dont on s'en fait. Et là, je suis satisfait car je ne découvre pas de comportement caché ou implicite. (Et, surtout, j'ai pas besoin de lire la doc pour me rendre compte qu'on ne m'a pas tout dit à propos d'Henry^Wupdate()!)

D'après la démo:

db.unicorns.update( {_id: ObjectId('503f73fb563d8a0d850007b3')}, {weight: 55} )
Well, something's not right, we lost the name, gender and vampire kill counter
Ah, right, it turns out that update updates the entire document with the new value

D'abord, il conviendrait de dire « it turns out that update replaces the entire document with the new value ». Le comportement décrit n'est pas une mise à jour mais un remplacement!

Mon point de vue est que update, avec ses deux arguments, devrait se limiter à mettre à jour les propriétés qu'on lui demande. C'est d'ailleurs la définition d'une mise à jour.

Allez, honnêtement, que signifie db.unicorns.update( {_id: ObjectId('503f73fb563d8a0d850007b3')}, {weight: 55} ) de manière intuitive, si l'on s'en tient uniquement à ce qu'on lit? «Mets-moi à jour ces propriétés-là dans le document dont l'ID est 503f73fb563d8a0d850007b3 avec ces valeurs-là.» L'élimination des autres propriétés est un comportement auquel on ne s'attend pas de manière naturelle. La preuve, puisque la démo l'affirme: « Ah, right, it turns out that update updates (replaces) the entire document with the new value »!

Je pense pouvoir être difficilement plus explicite.

[…] la raison pour laquelle, à mon avis, toutes les requêtes ne fonctionnent pas avec des callbacks écrites en js, c'est que le js est à priori lent comparé au reste du code mongo en c++.

Je comprends. Mais n'est-il pas possible d'optimiser l'exécution de telles fonctions, d'une manière ou d'une autre, de faire en sorte qu'elles n'aient qu'un impact limité sur les performances? C'est juste une question de curiosité.

Quand tu update quelque chose, c'est forcement le document dans son ensemble.

Ce n'est qu'une manière trop hâtive AMHA de modéliser ce concept. Si je mets un document à jour, je le remplace rarement (jamais?) dans son intégralité! Ça, c'est le logiciel qui le fait. Quand je mets un document à jour, je modifie quelques phrases ou paragraphes mais jamais tout d'un coup. Jamais, dans aucun système informatique que j'aie eu l'occasion de [bien] connaître le concept de "mise à jour" ne correspond au remplacement intégral du système, ce qui s'apparente à une réinstallation. Pourquoi ce concept devrait-il être modifié dès lors qu'on s'adresse à des documents.

D'ailleurs si la démo en ligne ajoute cet indice quant à l'utilisation de la commande update, c'est justement que ses concepteurs se sont préparés à ce qu'il y ait confusion, ce qui confirme en substance mon argumentation! Si c'était limpide dans leur réflexion, alors pourquoi persister dans cette direction, qu'ils savaient pertinemment source de confusion? (poil aux arpions.)

Penser que tu ne mets a jour que les champs spécifiés montre que tu penses encore en termes de tables relationnelles…

(Faudrait vraiment être dans ma tête pour affirmer ça! Allez, encore un petit effort…)

Que nenni, je me réfère à tout ce que je connais, où le concept "mise à jour" est le remplacement d'une partie du système ou de l'objet auquel s'applique la mise à jour. Pas l'objet dans son intégralité, auquel cas un autre terme que "mise à jour" doit être envisagé.

Et de toutes façons, "update" est un terme beaucoup trop généraliste pour être compris de manière irréfutable comme les concepteurs l'entendent. Plus évident à appréhender: "update_properties()", "update_metadata()", "update_document_descriptor()" ou encore "replace_document()". Ce sont juste des suggestions à brûle-pourpoint, pas nécessairement appropriées, mais qui veulent illustrer à quel point la précision des termes utilisés réduit le doute quant à la compréhension de leur nature et de leur mise en oeuvre.

Un système est intuitif s'il se base sur des concepts connus et maîtrisés, par exemple le langage. Demander à ce qu'on considère qu'une mise à jour est un remplacement est une erreur. Demander aux utilisateurs et aux développeurs de donner une définition intuitivement contradictoire à des termes bien connus et dont la signification est bien maîtrisée, bien assimilée est une erreur.

Je pense que ton problème avec "update" se résout de lui même une fois que tu intègre bien que MongoDB est une DB orientée document .

(La bonne vieille rengaine du "changement de paradigme", si j'ai bien compris?)

Je répète: faudrait vraiment être dans ma tête pour affirmer ça. Que je ne sois pas d'accord avec un concept ou une mise en œuvre ne signifie absolument pas que je ne l'ai pas… intégré, compris ou quelqu'autre forme de limitation intellectuelle dont je pourrais être affublé.

Je suis arrivé à la leçon 13 de MongoDB et je ne suis déjà pas d'accord avec au moins deux principes. D'abord les opérateurs de comparaison: le style find( … {name: {$gt: …}} ne me plaît pas du tout. Puisqu'il s'agit de Javascript, je me serais attendu à passer un argument de type fonction ou callback.

Je ne suis pas non plus d'accord avec le principe de fonctionnement de la méthode update (ou avec son nom), qui en réalité remplace un document par l'argument. Le nom de la fonction ne correspond donc pas à sa mise en oeuvre. Ça éviterait le loin-d'être-intuitif opérateur $set, un peu trop pour moi. Intuitivement, d'ailleurs la démo le montre, on s'attend à ce que les arguments de update ne mettent à jour que les propriétés spécifiées par l'argument. Donc soit le nom "update" est très mal choisi (auquel cas "replace" conviendrait bien mieux), soit sa mise en oeuvre devrait ne mettre à jour que les propriétés spécifiées.

Sinon MongoDB est en effet très intuitif, en tous cas pour ce que j'en ai essayé.

Impressionnant le juré dit qu'il a été vraiment convaincu et que le verdict n'a pas été tiré à pile ou face. Je propose aussi de demandé à la juge si elle été vraiment impartiale, à Apple s'ils ont mérité de gagner ce procès et à Samsung si les brevet Apple sont valide comme ça on aura plein d'avis super objectifs.

Ouais. Vraiment pommage qu'ils aient pas eu la même juge que celle qui a présidé l'affaire Samsung vs Apple: «Je comprends pas qu'on peut se battre là-dessus!» (j'ai plus les références par contre.)

C'que je peux être con parfois. On peut pas, y a antériorité. On est foutu.

En même temps, vu qu'il y a un brevet dessus, c'est un peu normal.

Ah ben voilà la solution: suffit qu'une grosse société enregistre un brevet logiciel intitulé "Intenter un procès pour violation de brevet logiciel" et du coup y en aura plus!

«Pour des raisons d'économies de budget, dans la séquence qui suit, le bruitage sera entièrement fait à la bouche…»

C'est d'autant plus aberrant et horripilant que les brevets dit violés n'ont rien de logiciel!

Prenez un chewing-gum, Émile!…

C'est dingue les expressions à la con qu'on peut utiliser… (con-con, je sais…)

C'est absolument hors-sujet mais ça m'a fait marrer! Je n'ai jamais vu ce film en fait. Je note… ;-)

C'est à cause d'apple que gnome est en train de faire la même chose et de se tirer une balle dans pied(et pour gnome, c'est quand même un comble)

Vu la gueule du pied du logo de Gnome, c'était prémonitoire…

Ne serait-ce pas

    &X == &(X.a) - &(((struct x *)0)->a);

au lieu de

    &X == &(X.a) - ((struct x *)0)->a;

?

Tu connais une distribution ou un package avec lequel l'ensemble smtp, imap, webmail, serveur de calendrier et de contacts s'installe facilement, marche out of the box avec une configuration minimale et une bonne sécurité?

Ce genre de souhait est irréaliste. Même les produits propriétaires les plus réputés ont besoin d'un minimum de configuration et d'adaptation.