LupusMic a écrit 1481 commentaires

Non, une coupure de courant ne flingue rien. Et je ne comprend pas cette référence un secteur de 4k. Tout d'abord, les disques durs dont encore et toujours calibrés sur des blocs ridicule de 512ko. Il y a une nouvelle génération de disques durs avec des blocs plus gros, mais c'est tellement neuf que Linux a à peine intégré leur support il y a quelques mois.

Mais surtout, le disque dur peut dire que la donnée être écrite alors que c'est faux. Tout les disques durs ont une mémoire tampon, qui leur permet d'optimiser les IO. Si le disque dur dit à l'OS qu'il a écrit, l'OS n'a aucun moyen de s'assurer que c'est vrai.

mmap est simplement un appel système. Il ne peut aller au delà des limitations et fonctionnalités de l'OS, du matériel et des pilotes.

La morale c'est que si on veut garantir la fiabilité absolue, il faut répliquer et garantir la continuité du courant. C'est possible, à 100%. Mais comme toujours, c'est une question de prix.

Ah non, je n'ai pas dit que le hard peut tout. Au contraire, ce sont les limitations hardware qui font les limitations logicielles. Ceci dit, en blindant en considérant l'architecture dans l'ensemble, on peut se prémunir de la plupart des incidents. Ensuite, vouloir la fiabilité de sa base de données même sous le feu nucléaire, c'est illusoire :p

Chutt! Personne n'avait rien vu!

C'était ma première idée, et je me suis dit qu'on pouvait parler d'autres fenêtres ;)

« J'ai enfin eu le temps de tester sur mon serveur Debian GNU/Linux la dernière version d'un logiciel libre sous X Windows afin d'écrire un article pour ce site. »

Comme quoi tu parles vraiment de choses que tu ne connais pas. Le principe d'une transaction, c'est de garantir qu'une transaction réussie le soit atomiquement. une base de données peut garantir qu'en cas de crash, une récupération de la base de données sera cohérente. En aucun cas une base de données peut promettre de tout récupérer en cas de crash. Et ce dans la limite des promesses de l'OS. Une base de données SQL ce n'est pas magique.

Et puis les crash disque et les pannes de courant ne sont pas des événements que peuvent gérer des logiciels. C'est pour qu'on fait en sorte que ça n'arrive jamais (NAS, RAID, onduleurs redondés, etc).

Pour une application comme Farmville, on s'en cogne de la fiabilité des informations du jeu. Ce qui est important, c'est la réactivité du jeu, et que l'expérience soit agréable. Et pourtant, ils ont des données persistantes.

Tu as du mal à comprendre parce que tu n'as jamais dû avoir de cas concret à gérer. On ne peut rien garantir avec un logiciel. Par contre, avec une infrastructure et en mesurant ayant consciences des concessions que l'on fait, on peut assurer une certaine fiabilité et qualité de service.

Je ne parlait pas de code flottant. Je parlait des nombres float. Ces nombres sont des représentations de nombres réels. Ils en sont la plupart du temps une approximation. Cette approximation introduit une imprécision dans les calculs sur ces nombres. Lorsque cette imprécision n'est pas gênante, on peut utiliser des FPU performant (pour calculer le rendu d'une scène 3D par exemple). Par contre, stocker un montant financier dans un float est une erreur de débutant très répandue, qui rend les comptes faux. On aurait dû privilégier le type de données décimal, qui est lent mais fiable, sur le type float, rapide mais imprécis.
On peut appliquer ce raisonnement aux nombreux choix que l'on doit faire lorsqu'il s'agit de déployer une solution informatique : quels niveaux de rapidité et de fiabilité, pour quel coût ?

MongoDB prétend garantir l'atomicité sur certaines opérations.

Sauf que tu place la base de données ne peut pas faire de miracle. Si le système lui dit que les données sont enregistrées, elle doit l'accepter. Mais nous savons qu'en réalité ce n'est pas le cas. C'est pourquoi la base de données ne doit pas être le seul élément à considérer dans la mise en place d'un système assurant l'intégrité du systèmes. Des logiciels au matériels, en ne se contentant pas de juste considérer les serveurs, mais aussi en prenant en compte l'infrastructure, les risques physiques et les infrastructures annexes.

Utiliser une base de données SQL, c'est souhaiter disposer de certaines fonctionnalités te permettant de décrire l'intégrité des données, dans un langage initialement standardisé. Mais l'intégrité ne fait pas tout, il y a aussi les performances et les fonctionnalités qui entrent en jeu dans le choix d'une technologie.

Parfois, la rapidité d'obtention d'une donnée est plus importante que sa fiabilité ou son exactitude. L'exemple des nombres float et des décimaux est un exemple très parlant.

Bref, c'est une question de compromis.

Dans les disques compatibles sATA, ce n'est pas encore très répandu. Mais il est vrai que je ne sais pas ce qu'il en est dans les disques embarqués dans les téléphones mobiles.

On qualifie de quotidien une chose dont la fréquence est le jour.
On qualifie de journalier ce qui est rapporté au jour.

Quotidiennement, on peut percevoir son salaire journalier.

Une tâche journalière n'est pas une tâche quotidienne, et inversement.

Dans ce cas, aucune base de données ne peut garantir ce que tu espère, sans avoir accès directement au disque dur. Et là encore, il y aura un gros problème de performances.

DRY ne s'applique pas dans ce cas là, puisqu'ils ne répètent pas eux-même. Ils appliquent plutôt le DIY ;)

Quel est le rapport avec ce que je dis ?

Sous certaines latitudes, la nuit commence bien tôt. Sous d'autres elle dure même bien longtemps.

Encore un qui n'est pas abonné à GLMF :p Ça dépend du firmware du lecteur flash, mais il n'y a pas de garanti que le mapper s'occupe réellement de répartir les écritures. Donc oui, il y a de la place pour les systèmes de fichier spécialisés.

Une carte de la région dans laquelle tu es perdu, qui garde le nord est une bonne application de la rotation à 360°. Pas d'un coup, hein, progressivement pour suivre le Nord. Histoire qu'en tournant en rond, on en perde pas le Nord.

« pour produire des versions journalières »

Quotidienne.

Tu aurais pu attendre demain.

J'ai bien parlé de la libc, pas de la glibc. Ce n'est pas du tout la même chose.

Non, ça c'est une primitive système.

C'est un peu la raison pour laquelle on a inventé le DNS :)

man gethostbyname

C'est un appel POSIX, on peut donc l'assimiler au système. Et ça ne fait pas partie de la libc. La libc c'est la norme ANSI, pas POSIX.

Ceci dit, l'application ne devrait pas faire la résolution de nom à sa sauce, mais toujours demander au système une correspondance. Dans le cas contraire, on va commencer à s'arracher les cheveux sur des conflits de configuration.

Vive le vendredi :)

Et je n'y pense que maintenant, mais quid des sites qui sont sur 0.0.0.0 dans mon /etc/hosts ? :D Sans compter que le proxy peut être en erreur, que ce n'est pas forcément mon FAI mais mon employeur qui bloque le flux.

« Ensuite, elle demande au serveur si cette URL est effectivement inexistante ou si cela provient de la connexion du visiteur. Enfin, l'utilisateur peut envoyer l'adresse à CensorCheap qui immédiatement après la répertorie en ligne. »

En fait, lorsque l'extension demande au serveur si l'adresse est réellement censurée, l'adresse est déjà envoyé, et donc le serveur peut en faire ce qu'elle veut.

L'intention est louable, mais l'architecture ne sera pas pérenne en raison de l'aspet centralisée de la solution. Il faudrait réfléchir à une vérification en p2p. Parce qu'en plus, le serveur central, qui sert de référent, voit aussi l'Internet au travers du prism de son FAI.