arnaudus a écrit 4657 commentaires

… mais il est d'usage ici de ne pas répondre aux questions contenant le mot "Urgent" (netiquette de base). La même question sans le "urgent", et précisant en quoi les réponses fournies par Google ne sont pas satisfaisantes devrait pouvoir attirer beaucoup plus de réponses constructives.

Une reprise ou une inspiration n'est pas pareil qu'un clone. L'objectif de beaucoup de jeux libres est de cloner un jeu propriétaire afin d'y jouer gratuitement et sous linux. Il est évident qu'il n'existe pas vraiment de plus-value associée à ce type de projet…

L'ADN (en solution aqueuse) se présente la plupart du temps sous forme de double hélice constituée de deux brins complémentaires entrelacés. Les deux brins contiennent exactement la même information, l'un en positif, l'autre en négatif. L'unité d'information est donc la «paire de bases», une paire de bases étant constituée d'un nucléotide (monomère d'ADN) et de son complémentaire sur l'autre brin. C'est cette complémentarité qui permet la réplication fidèle de l'ADN : on sépare la double hélice en deux parties, et chaque partie garde la totalité de l'information (un peu comme si on avait deux disques durs, l'un étant l'image de l'autre avec tous les bits inversés: on prend n'importe quel disque, on le met dans un autre PC et on le resynchronise avec un autre disque vierge).

D'ailleurs, en toute logique, on devrait dire «paire de nucléotides» et pas «paire de bases». Un nucléotide est constitué d'un phosphate (qui assure la liaison des nucléotides entre eux quand l'ADN est polymérisé), d'un sucre (le désoxyribose), et d'une base azotée (la partie variable du nucléotide). Le tout reste une sorte de gros Lego constitué de briques assemblées les unes aux autres.

Ça serait totalement inutile, il faut beaucoup moins d'information que ça pour donner un sens de lecture. La réponse est au dessus, ils se servent de la redondance pour maintenir une structure de l'ADN compatible avec la lecture et la copie sans trop d'erreurs. Ça reste tout de même très sous-optimal.

Pour la lecture, on peut le calculer. Les tout derniers séquenceurs peuvent se faire un génome humain (3 Gbp) en une journée, ce qui fait du 35 kbp/s. Ça progresse plus vite que la loi de Moore, dans quelques années, ça sera probablement instantané.

Pour la copie, la DNA polymérase fait du 50 bp/s à 1000 bp/s, mais bien sûr on va stocker sur plusieurs molécules d'ADN, un peu comme si on parallélisait (au final, la copie est beaucoup plus rapide que la lecture). La vitesse dépend de la polymérase, c'est un compromis vitesse / fidélité.

L'«écriture» est beaucoup plus compliquée. J'imagine que c'est l'étape bloquante du système.

Mouaip, mais c'est un chouilla plus compliqué quand même. Tu as de nombreuses structures à éviter :
* Les régions trop riches en A/T ou en G/C. Il faut donc, sur une fenêtre glissante de taille donnée, maintenir un ratio (A+T)/(A+T+G+C) dans une fourchette acceptable, probablement entre 30 et 70%, quelque chose comme ça.
* Les séquences répétées, qui sont mutagènes: AAAAAAA, AGAGAGAGAGAG, ATTATTATTATT, par exemple, auront beaucoup plus d'erreurs lors de la copie.
* Les palindromes, qui forment des structures secondaires (par exemple, ACTAGTXX..XXACTAGT peut facilement destabiliser la double hélice d'ADN)
Du coup, en général, aucune séquence n'est parfaite. Pour une séquence donnée, tu peux calculer une sorte de score avec un algorithme heuristique, et j'imagine que l'objectif serait de compresser au maximum l'information tout en gardant une lisibilité acceptable.

Ceci dit, je reste convaincu que la compression de 200% décrite dans l'article est largement sous-optimale—ce n'était pas le but de la manip. J'imagine même qu'il y aurait moyen de réaliser en même temps la compression (informatique) des données numériques et l'optimisation de la séquence, plutôt que de zipper d'abord puis de bricoler la suite binaire pour minimiser le nombre de nucléotides requis.

OK, j'aurais dû lire l'article. Ils ont donc choisi de rendre l'information redondante pour améliorer la fiabilité.

Le truc, c'est qu'évidemment chaque nucléotide contient bien deux bits d'information, mais que pour des raisons pragmatiques, ils préfèrent n'en coder qu'un. Cependant, si leur méthode pouvait trouver de vraies applications, il sera tout à fait possible de mieux compresser tout en préservant la fiabilité de la lecture et de l'écriture, par exemple en compressant sur des mots de 4 ou 6 nucléotides, voire plus.

Lorsque les deux brins sont ensembles, A est toujours associé à T et C à G : logiquement, A et T codent donc pour la même information.

Non, c'est faux. Je veux dire que A et T sont toujours associés, mais on ne lit qu'un seul des deux brins. Par conséquent, des séquences comme TTA et ATT sont différentes, et un nucléotide contient bien 2 bits d'information.

Et pour résumer : c'est cher, pas pratique à lire/écrire (le 0 binaire doit être codé en A ou C, comme on veut, et le 1 binaire en G ou T), mais a un taux de d'erreur de 2 par million de bits.

Pas très performant : mieux vaut coder 2 bits par nucléotide (A=00, C=01, T=10, G=11), on en stocke deux fois plus.

Eh eh, ma manière de lire cette courbe, c'est "plus le temps passe et plus il y a de bugs dans les nouvelles versions" :-)

Le rasoir d'Occam promeut la simplicité dans la conception et le développement des théories (philosophiques, physiques, ce que tu veux).

La simplicité et la parcimonie sont deux notions distinctes. Ce qui est simple n'est pas nécessairement parcimonieux, et vice-versa. D'où ma remarque : ça n'a pas grand à voir.

Le KISS s'applique au départ au développement, pas à l'interface utilisateur, comme tu le supposes avec l'exemple de ton volant. Cf Arch.

Je ne vois pas pourquoi le KISS s'appliquerait au développement en priorité, il s'applique au design en général (Wikipédia mentionne la naissance du concept dans le domaine de l'aviation). Mais justement, je suis d'accord avec ton exemple, c'était exactement mon objectif avec l'exemple du volant de voiture : il est tout à fait légitime de privilégier l'ergonomie à la simplicité, et donc de rejeter le principe du KISS.

De toutes manières, à mon avis, personne ne fait exprès d'obfusquer quelque chose. Les choses deviennent complexes parce qu'elles sont construites sur l'existant, parce qu'on a essayé de faire simple sans y arriver, parce que ce qui parait simple pour quelqu'un ne l'est pas pour quelqu'un d'autre, ou simplement parce qu'un algo efficace n'est pas forcément simple. C'est bien beau de gueuler KISS!, mais qu'est-ce que c'est qu'un code simple? Est-ce que function DoThis(); function DoThat() est plus simple que function Do(doThis = TRUE) ? Est-ce que déporter tous les algos dans des fonctions bien cachées dans internal.cpp pour ne garder que la structure du programme quand on lit le code est plus simple que de programmer gentiment en explicitant les instructions?

Je maintiens : ça n'a rien à voir. Mon commentaire était peut-être succinct, mais le KISS est un principe de minimalisme (appliqué à la conception d'artefacts), alors que le rasoir d'Occam est un principe de parcimonie (adapté à la conception de modèles explicatifs). Le rasoir d'Occam est un axiome de la logique scientifique, il ne peut pas être remis en cause. Le KISS est un concept de design vaguement fumeux, qui utilise la notion de "simplicité" sans vraiment la définir, et il peut évidemment être remis en cause—c'est un choix, une convention de développement.

Le seul point commun entre les deux repose sur l'idée qu'un système simple est plus élégant et plus facile à manipuler (en gros, ça exclut certains concepts artistiques), mais ça s'arrête là. L'assimilation du KISS avec le rasoir d'Occam est trompeuse, car elle pourrait faire croire que, par exemple, les choix de développement de Gnome sont plus rationnels que ceux de KDE, ce qui est profondément stupide.

En particulier, on peut très bien défendre le point de vue que l'ergonomie d'un artefact se doit d'être intuitive, et pas simple. Parfois, une interface simple est intuitive, mais souvent, elle ne l'est pas. Un bon exemple est celui du volant pour diriger un véhicule. Étonamment, c'est assez intuitif de tourner le volant pour tourner les roues, mais le dispositif mécanique sous-jacent est terriblement complexe, et nécessite de transformer un mouvement circulaire en mouvement linéaire grâce à une crémaillère. Clairement, ce n'est pas KISS du tout. Un autre exemple, plus près de l'informatique, est la pratique assez étrange d'allumer un ordinateur grâce à un interrupteur, et de l'éteindre de manière purement "informatique". Ça a l'air assez intuitif pourtant, même les grand-mères trouvent "normal" de ne pas utiliser le même bouton pour allumer et éteindre un ordinateur, mais là encore, ça n'est pas KISS : le principe du KISS demanderait qu'il y ait une unique interface, et que la seule manière d'éteindre un ordinateur serait d'appuyer sur le même interrupteur que pour l'allumer.

Le rasoir d'Occam consiste à préférer une explication simple à une explication complexe. Par exemple, je clique sur "éteindre mon ordinateur", et l'ordinateur s'éteint. On peut se demander si mon action a entrainé l'extinction de l'ordinateur, ou s'il s'est éteint parce qu'il y a eu une panne d'électricité au même moment. Si je n'ai pas moyen de répliquer l'expérience, le rasoir d'Occam impose de choisir la première solution, qui ne fait pas intervenir de cause extérieure (la panne d'électricité). La rasoir est un critère de décision, il ne précise rien quant au design d'une interface.

D'ailleurs, il y a des cas où le KISS et le rasoir d'Occam sont en contradiction dans la construction d'un modèle. Par exemple, un pot de fleur tombe de ma fenêtre, et 2 secondes plus tard, je l'entends se briser par terre. À la question "à quelle distance du sol le pot était-il 1 seconde après le début de sa chute", le KISS et le rasoir d'Occam imposent deux résultats différents. Le KISS impose un modèle simple, probablement un modèle linéaire. Occam impose un modèle avec le moins de causes possibles, typiquement, un modèle d'accélération constante sans frottement. On voit bien que la diminution du nombre de causes ne mène pas nécessairement à un modèle plus simple.

Voir aussi : rien à voir.

Quand l'humour est tellement puissant que personne ne le comprend, ça s'appelle «un bide». Ici, c'est un peu trop bien fait : pas de ponctuation, pas de majuscules, pas de culture, pas de réflexion ; on est un peu trop dans le kikoolol, c'est un peu trop caricatural. Sans compter que je pense que même le plus profond des neuneus sait plus ou moins ce qu'est la TVA, donc la blague n'est pas très crédible…

Je pense que c'est déja ce qu'il fait. Je pense qu'il veut un truc pour afficher le tarif en temps réel, pour que le client sache à chaque instant à combien il en est.

Et voila, ça a l'air d'être un bug "chaud" avec plusieurs duplicats: https://bugs.kde.org/show_bug.cgi?id=295212. Et, surprise, c'est un bug KDE. LibreOffice n'y est pour rien, apparemment. Mais en tout cas, il s'en est pris plein la tronche dans ce journal, le monde est injuste.

Je viens d'enregistrer et de rouvrir un fichier testœøÀΔ.odt avec LibreOffice 3.5.3 sur mon Ubuntu. Donc, la description du problème est fausse, et tu ne donnes pas d'exemple reproductible. Je suppute qu'il y a un gros bug dans l'interface chaise-clavier.

Dans tous les cas, ça me semble absurde de changer de logiciel parce qu'il ne sait pas ouvrir un fichier avec des caractères spéciaux. Il suffit de renommer le fichier, voire de faire un lien symbolique, ce qui permet de gérer le problème de manière totalement transparente. À mon avis, ce que tu fais s'apparente à envoyer ta voiture à la casse parce que tu as toi-même monté les essuie-glaces à l'envers.

Sur le fond, oui, je sais, les pauvres chinois, ils ont le droit de mettre des caractères cabalistiques dans leurs noms de fichier. Les chinois ils font ce qu'ils veulent, mais personnellement je ne mets jamais de caractères non-ASCII dans les noms de fichier : ça n'a aucun intérêt, il serait stupide d'avoir des noms de fichiers qui ne diffèrent que par un accent ou un espace insécable, etc. Donc, quelque part, même si c'est un bug, c'est un bug généré par une demande (à mon avis) non-pertinente de l'utilisateur. Après, si le système l'autorise, alors ça doit marcher, j'avoue.

Oui, j'ajouterai même que R est devenu un véritable langage de programmation; on peut carrément exécuter des scripts en #!/usr/bin/env Rscript , il y a un générateur de bytecode pour les fonctions les plus gourmandes à interpréter, et de quoi jouer avec la programmation parallèle. On peu ajouter la capacité native à générer des graphes de très haute qualité directement dans le format souhaité (bitmap ou pdf), et 4000 paquets contribués. R est devenu incontournable en biologie, et je pense que ce n'est pas près de retomber (en 2012, R se classe 28e dans le classement des langages populaires, devant COBOL, Eiffel, D et Erlang…).

En plus, le langage S est assez esthétique et élégant, en plus d'être très concis. Je pense que c'est un excellent outil pour l'apprentissage de la programmation.

R n'a rien à voir avec un tableur, je doute que la comparaison ait un sens.

"pas compatible avec OOo" est mentionne comme inconvenient d'Office et "compatible avec Office" est mentionne comme avantage d'OpenOffice, bref une contradiction totale

Je ne vois pas où est la contradiction. OOo sait lire et produire (pas parfaitement) les documents MS Office, alors que MSO ne sait lire et produire que ses propres documents, et pas ceux générés par OOo. Ça me semble être limpide, question logique…

Ton commentaire est tellement biaise (tiens, il n'y a pas les accents sous Windows?) et incomplete (tiens, encore?) que c'en est franchement risible. Ca (tiens, pas de Ç non plus) manque tres tres serieusement d'objectivite. (L'objectivite, c'est comme la conjonctivite?).

Dans le document, inconvénients de MS Office: prix des licences, format de fichier propriétaire avec les problèmes de compatibilité qui vont avec, problèmes de sécurité avec les macros, mises à jour peu fréquentes. Je ne vois pas où est le problème, ça me semble assez objectif (même si pour les mises à jour, le compromis entre la fréquence peut être discuté, c'est pratique de mettre à jour souvent sur un poste perso, moins en production.

Avantages OpenOffice: interface unifiée (OK, je suis d'accord, c'est moyen comme argument), Licence libre, format ouvert XML (en 2005 ça n'était pas le cas pour MS Office), export natif en PDF (à l'époque, c'était une fonctionnalité très originale), compatible avec MS Office (argument à double tranchant), moins sensible aux virus (c'est factuel, même si on peut toujours balancer l'argument de la fréquence d'utilisation, qui n'est pas démontrable tant que les PDM ne bougent pas plus), multiplateforme.

Bref, c'est une liste d'avantages/inconvénients destinés à un public d'utilisateurs qui, comme presque tout le monde, n'utilise qu'une partie négligeable des fonctionnalités d'une suite bureautique, mais je ne vois rien de particulièrement faux ou choquant.

"Ça manque d'objectivité" est l'argument parfait pour ceux qui ont de la merde dans les yeux : pas besoin d'argumenter, on sait mieux que tout le monde (argumentum ad potentiam). J'aimerais bien connaitre les arguments objectifs que MS utilise pour refourguer MS Office, histoire d'être impressionnés par l'"objectivite".

Je crois que c'est toi.

Certes, mais si c'était vaible, ça serait fait depuis longtemps. Tu vas à Carrefour et à Auchan, tu ne trouves que des machines assemblées sous Windows. Pourquoi des grands groupes comme ça n'ont pas les moyens de vendre des PC avec une distrib Linux maison, 100€ moins cher que les PC Windows? C'est quelque chose que je n'ai jamais compris, et j'imagine qu'il y a une raison, c'est juste qu'elle m'échappe. Une piste serait peut-être que les PC sont vendus à prix coûtant, et que les marges sont faites principalement sur la logithèque (10 ou 15€ pour des softs qui impriment des cartes de visite ou d'autres trucs aussi inutiles). Sous Linux, la plupart de ces trucs existent déja; et en tout cas, on n'en achèterait plus en magasin. Ça serait cynique, mais les grandes enseignes ne sont pas à ça près…

Bah, il me semble que le deal évident, c'est que si tu administres ta machine, tu assumes, et tu corriges les boulettes (et tu réinstalles ta distrib si tu as tout pété).

Le problème, c'est qu'en recherche, tu as tout le temps besoin de faire des trucs sales : récupérer un programme écrit par des chinois, le compiler, l'exécuter, le modifier, le coller sur un serveur de calcul, et tout faire péter avec une fuite mémoire, par exemple, et le tout dans une seule journée. C'est la procédure normale, et toute autre procédure va simplement arriver au même résultat, sauf que ça prendra plus longtemps.

Dans mon cas, le service info me laisse gérer mon serveur de calcul et ma machine perso, plus les machines des étudiants. Je n'ai donc qu'à administrer un seul serveur, et j'ai déja l'impression de passer pas mal de temps à installer des trucs : des libs, des python-machin, des perl-machin, le même python-machin mais pas la même version, et des milliers de paquets pour R… ça ne s'arrête jamais, et ça peut être bloquant si tu en as besoin le vendredi soir. Et encore, on a imposé que les programmes perso ou non-packagés soient exécutés dans le /home , quitte à les dupliquer entre utilisateurs, de manière à n'avoir que les paquets de la distrib en root, sans /opt ni /usr/local. Franchement, je ne vois pas comment on peut réussir à gérer un parc de plusieurs dizaines de machines en production si on ne délègue pas ce genre de trucs. La seule solution serait de dire aux utilisateurs d'arrêter de faire des trucs crades, mais dans un labo de recherche, faire des trucs crades est justement ce pour quoi les gens sont payés.

Après, ça dépend aussi de l'environnement. Autant je trouve normal dans un environnement de production de ne pas laisser les utilisateurs jouer avec les ordinateurs, autant c'est assez contraignant dans un centre de recherche. Il y a quelques années, un service informatique m'avait «menacé» de m'installer une RedHat entreprise sur mon poste, sans les droits root—politique de l'université, je ne sais pas quoi. Je leur avais répondu que je les tiendrai pour responsables de ma perte de productivité sur le temps perdu à rootkiter ma propre machine. Résultat, ils m'ont laissé installer mon Ubuntu perso (mais pas Debian, les voies du Seigneur sont toujours aussi impénétrables).