Mouais, il est aussi illicite de discriminer selon la couleur de peau ou la religion, mais pourtant l'annonce n'indique pas européen/africain/asiatique ni juif/musulman/athée/chrétien…
Moi je vois des problèmes très concrets avec une représentation interne qui suit exactement les spécifications du document XML. Ça veut dire que l'évolution du logiciel est totalement liée à l'évolution du standard—et donc, que l'indépendance vis-à-vis d'un standard concurrent est totale. Par ailleurs, je ne vois pas du tout dans ce cas comment supporter plusieurs standards, à moins d'avoir du code spécifique pour chacun des standards (autrement dit, quand on clique sur "gras", le bout de code appelé va être différent en fonction du type de fichier d'entrée).
De toutes manières, historiquement, LibreOffice/OpenOffice/StarOffice précède très largement l'idée même de document XML, c'est à dire que le format OpenOducment a probablement été défini à partir de la représentation interne des documents dans le code, et pas le contraire.
Du coup, j'ai l'impression que c'est injuste de reprocher à LibreOffice son manque de support d'OOXML. Il me semble évident que les logiciels qui ont été développés après la publication du standard OOXML ont pu calquer leur architecture sur le format, ce qui rend tout de suite la compatibilité plus facile. Je ne sais pas exactement comment LibreOffice gère les différents formats, mais aucune solution ne semble parfaite : soit on crée de moulinettes pour transformer l'OOXML en OpenDocument, puis OpenDocument vers OOXML, soit les deux formats sont importés dans la représentation interne de LibreOffice puis exportés (avec perte d'info pour les fonctionnalités d'OOXML non supportées), mais je dirais que les problèmes d'intercompatibilité sont principalement dûs à des contraintes d'architecture, et pas à une incompétence des developpeurs.
D'ailleurs, comment est-ce que OnlyOffice et al se débrouillent avec les documents odt?
Désolé de pourrir le fil avec une question idiote, mais je n'ai pas l'habitude des petites annonces, et je suis surpris par la mention "H/F": est-il réellement nécessaire de préciser quelque chose qui ne peut légalement pas être autrement? C'est un peu comme la mention "Sans colorants ni conservateurs conformément à la règlementation"?
duckduckgo par exemple, je l'utilise et j'en suis content, mais il faut se fier à leur bonne foi
Pas seulement, ddg est un méta-moteur de recherche, on peut éventuellement le voir comme une manière d'anonymiser ses recherches google, mais certainement pas comme une alternative à Google. Comme même les autres moteurs de recherche commerciaux vont sniffer Google, ça me parait compliqué de s'en passer.
Et puis, il faut bien réaliser que si Google souhaitait obtenir des infos sur vous, il pourrait même quand vous utilisez ddg. Pour des sites qui ne sont pas hyper-fréquentés, il suffit de croiser les remontées de Google analytics avec les réponses aux requêtes provenant de ddg.
Il faudrait analyser la gamme dans laquelle la fin de la chanson est jouée et se baser dessus.
Peut-être, mais je ne connais pas beaucoup de styles de musique occidentale où on n'a pas tendance à finir sur la tonalité du morceau, même quand ça module (et il n'y a pas beaucoup de modulation en pop, rock, etc), ça revient à la tonalité de départ sur la fin.
D'ailleurs, il faudrait peut-être que des spécialistes s'expriment là dessus, mais il me semble bien que classiquement, que si on ne termine pas par l'accord majeur de dominante, on n'enchaine pas forcément sur la nouvelle tonalité. Par exemple, dans les suites de Bach, on peut terminer sur une tierce picarde et enchainer sur une tonalité mineure ; inversement, les enchainements majeur/mineur se font sans transition particulière.
Ceci dit, la règle générale en musique classique reste de suivre les règles de la modulation pour enchainer les morceaux, les transitions se font entre tonalités proches, ou éventuellement entre mode majeur et mode mineur dans la même tonalité (ce qui s'entend pas mal quand même).
lol on doit pas du tout être de la même génération
C'est probablement insultant pour les gens de ta génération qui ont assez de maturité pour s'arrêter quand ils se rendent compte qu'ils ne comprennent rien à la discussion qu'ils ont lancée.
Parce que c'est bien connu, les autres industries sont tout à fait capables de se mettre d'accord sur des standards, de les implémenter, et de les respecter.
Quand tu changes des essuie-glaces, par exemple, tu choisis la taille… et tu te démerdes parce que les petits bitonios en plastique pour la fixation sont tous différents.
Quand tu achètes une cafetière à dosettes, bien entendu, elles utilisent toutes les mêmes dosettes et donnent toutes le même café.
Quand ton pot de peinture est terminé, bien entendu, tu peux acheter un pot d'une autre marque qui porte le même nom de couleur et tu auras exactement la même nuance.
La plupart du temps, il faut juste apprendre à vivre dans un monde imparfait. Il existe des normes, parfois les fabricants s'en foutent, parfois ils essayent de les implémenter, mais à moins d'avoir une très bonne raison pour le faire, il y a toujours des choses qui déconnent. Même quand le standard existe est est appliqué (par exemple les ampoules électriques), tu as la certitude que ton ampoule va rentrer dans le culot, mais parfois ça coince parce que le bulbe est trop gros, trop effilé, trop long ; et qu'à puissance égale tu peux avoir de grosses différences de température de couleur, ce qui fait que si tu veux un truc cohérent, il faut changer toutes tes ampoules en même temps.
S'il existait un organisme de vérification de conformité des navigateurs internet qui t'empêchait physiquement d'éditer un navigateur internet dans le monde entier tant qu'il ne passe pas un certain nombre de tests très stricts sur le respect des standards, alors peut-être qu'on aurait un peu plus de cohérence. Mais personne ne voudrait d'un truc aussi lourd et contraignant, c'est comme ça.
Imagine que ton éditeur ne comprend pas align. Ton utilisateur te demande de dupliquer la deuxième ligne du tableau. Tu vas faire quoi? 1) Dupliquer les attributs que tu ne comprends pas? Ou alors 2) créer une ligne sans attributs d'alignement?
Dans le cas 1), tu vas te mettre dans une situation où le document est potentiellement corrompu, invalide, ou ininterprétable par l'autre logiciel : par définition, les arguments que tu ne comprends pas, ils devraient peut être n'apparaitre qu'une fois, ou que dans un contexte particulier.
Dans le cas 2), tu es quasiment certain de produire une mise en page cassée. Dans ton logiciel qui n'aligne pas les tableaux, rien ne sera aligné, et le tableau sera cohérent. Mais dans un logiciel qui comprend tout le standard, alors la mise en page sera pétée. Au passage, rien ne te garantit que ton document sera valide, car il est possible que l'attribut que tu n'as pas compris n'ait de sens que s'il est présent dans toutes les lignes.
Et puis, encore une fois, je ne sais pas comment fonctionne LibreOffice ou les autres traitements de texte en interne, mais il est plus que probable que leur fonctionnement n'implique pas de lier toutes les opérations "en live" à la modification d'un arbre XML. Il me semble probable que le logiciel ait une représentation interne (sous forme de classes par exemple) des différents éléments, et que l'arbre XML soit créé à l'enregistrement du fichier—du coup, la représentation interne ne peut pas garder les nœuds incompris et les manipuler.
Tu peux aussi indiquer à l'utilisateur que tu ne comprends pas tout le document et qu'il va perdre de l'information…
Sous LibreOffice, c'est exactement ce qu'on te dit quand tu manipules des fichiers OOXML.
Il est tout à fait possible d'innover sur l'interface, l’ergonomie
Oui oui, comme les lessives qui innovent sur le colorant et le parfum. Je sais bien que la plupart des gens considèrent que c'est de l'innovation, mais il ne faut pas charrier : les logiciels de traitement de texte ont besoin d'innover sur bien plus que l'interface pour avoir un rendu acceptable.
contrairement à LO qui convertit le document dans son format interne et perd de l'information au passage…
Ça parait quand même très très compliqué de faire autrement, non? Bien sûr, tu peux créer un logiciel capable de modifier de manière marginale un document sans changer sa structure, mais dès que tu souhaites toucher à des choses fondamentales (mise en page, changement de structure du document…), je ne vois pas comment tu peux t'épargner l'étape de charger la totalité du fichier dans ton abstraction interne. Une fois à cette étape là, plus moyen de revenir en arrière… Bien sûr, tu peux imaginer un système qui essaye de remettre les nœuds incompris à peu près là où ils étaient, mais je ne vois pas quelle garantie tu peux avoir qu'ils aient toujours un sens…
la manip MSword -> Libreoffoce.writer -> MSword fait perdre de l'information de mise en page.
Ça ne prouve pas grand chose, ça peut être un bug dans LibreOffice ou dans MSWord, ou ça peut venir de l'existence de propriétés documentées dans OOXML qui ne sont pas prises en charge dans le format odt et/ou par Libreoffice.
De toutes manières, ces formats sont beaucoup trop complexes pour être interchangeables. Pour cela, il faudrait que toutes les possibilités d'OOXML se retrouvent dans OpenDocument et vice-versa, ET que les logiciels MS Word et Libre Office soient capables de gérer l'ensemble de ces possibilités. Le mieux qu'on puisse espérer, c'est que chaque logiciel soit capable de lire les deux formats, et d'importer le sous-ensemble commun entre les deux.
À la base, le principe même de la normalisation des formats est contradictoire avec la notion de format natif. Ça bloque l'évolution des fonctionnalités des logiciels, et ça empêche d'innover sur le fond par rapport à ses concurrents.
Parce que la présence d'une méthode virtuelle implique la génération d'une vtable, qui a un impact sur les performances.
Dans ce cas, le concept même de coder en C++ a un impact sur les performances. Parce que si tu n'utilises pas le polymorphisme, ni la STL, ni les exceptions, ni les templates et que tu préfères utiliser des pointeurs nus et des macros, alors ça ressemble furieusement à ce que certains appellelent du C/C++, qui n'est en fait ni du C ni du C++.
Au passage, la règle pourrait bien être que les destructeurs d'une classe qui a au moins une méthode virtuelle sont virtuels. Ou de définir un mot clé "nonvirtual" pour les 0.01% des cas où on veut explicitement éviter la création d'une vtable.
Portabilité & Compatibilité (oui, je sais) avec la famille execXY() standardisée par POSIX
Dans ce cas, je ne vois pas le problème à surcharger la fonction main, une en int main(int, char**) et une en bool main(vector<string>). Encore une fois, si tu veux faire du C/C++, tu peux utiliser la version C, le compilo peut bien voir quelle version tu utilises.
des gens qui n'ont rien à faire de la performance et de la portabilité, qui ne sont pas la cible première de C++?
On pourrait débattre indéfiniment sur la cible première du C++, mais la performance et la portabilité ne peuvent pas être les deux seuls critères ; autrement, les gens feraient du C. Le C++, c'est avant tout la POO, la programmation générique, l'encapsulation, la STL, et tous les petits trucs du C++ moderne (lambda, inférence de type, shared_pointers, etc). Je t'accorde qu'il existe des gens comme toi qui interprètent le langage en tant que C amélioré, et notamment qui pondèrent l'utilisation d'un certain nombre de fonctionnalités du langage par les coûts induits en temps d'exécution et en mémoire. Mais il faut aussi voir que pour une très vaste communauté, ces choses n'ont aucun intérêt par rapport aux avantages de l'encapsulation, de la gestion des erreurs, ou des vérifications de types faites à la compilation?
Honnêtement, je ne comprends pas à quelle catégorie d'erreur tu faisais allusion (dans quelle mesure est-ce que la critique de la non-gestion des modules est-elle obsolète?).
Tu as une manière "officielle" de gérer les en-têtes, c'est 1) d'inclure les fichiers .h à l'aide d'une directive du pré-compilateur, ce qui reste un procédé hyper-bourrin (en gros, un copié-collé du header, qui sera recompilé pour chaque .cpp), et 2) d'inclure "à la main" des directives du pré-compilateur pour s'assurer que le header ne sera inclus qu'une fois. Autant dire que les modules ne sont absolument pas gérés, il faut tout faire soi-même. Le langage ne sait même pas ce qu'est un module, la seule chose qu'il sait faire c'est d'acceper une déclaration dans le même fichier an amont de la définition. C'est tellement une limite du langage que les compilos ont développé des pragma (à l'origine absolument pas standard) pour faciliter un peu la vie.
À mes yeux, ta réponse confirme simplement ce que d'autres essayent de dire dans ce fil : en C++, la gestion des modules est quasi-inexistante, et repose sur un procédé obsolète et bancal. Les pragma once et autres sucres syntaxiques ne résolvent pas le problème, et tu ne fais qu'insister sur le fait qu'il s'agit de solutions techniquement bancales. Du coup, on est tous d'accord, j'ai juste l'impression que tu trouves le système par défaut acceptable (et, de facto, il l'est puisqu'on l'utilise tous). C'est juste un peu dommage que tu ne sembles pas voir l'intérêt d'un système de modules moderne.
Du coup, tu peux les corriger avec des faits? C'est plutôt ça qui serait utile.
En particulier, les choses qui étaient vraies et qui ne sont plus vraies, c'est tout à fait possible qu'on puisse ne pas être au courant. Une telle erreur peut être faite de bonne foi, et si tu as l'info permettant de la rectifier, je ne vois pas pourquoi te priver de répondre poliment.
Et puis le jour où il le découvre le gugus s'insurgera (à juste titre) et il tentera de commettre un meurtre et ira en prison
L'argument, c'est qu'il ne faut pas être méchant avec les trolls, parce qu'on ne sait jamais s'il ne vont pas pêter une diurite et buter des gens?
En fait, c'est un appel à la soumission, ton truc. Ton voisin est violent? Ne le contrarie pas, c'est un coup à prendre un bourre-pif. Ton patron te harcèle? Ne proteste pas, c'est un coup à te faire virer.
Je ne suis pas psychiatre. Je ne peux pas savoir si mon interlocuteur est violent ou non, s'il a pris ses médicaments, s'il utilise les forums comme thérapie ou au contraire si ça risque de renforcer sa névrose. Le plus sain, c'est d'essayer en douceur d'inciter les gens qui ont des problèmes à se faire soigner, et d'éviter au maximum qu'ils puissent interagir avec les gens qui veulent savoir pourquoi leur programme ne compile pas, et qui pourraiernt réagir d'une manière peu constructive.
Au passage, une certaine forme de névrose est quand même tolérée dans le milieu du libre. Par contre il faut coder comme un dieu pour se permettre d'insulter les gens.
Je pense que personne n'a jamais suggéré de mettre en place un test anti-névrosé et de leur interdire la lecture ou la contribution. C'est juste que quand un historique de contributions substantiel prouve que leurs contributions sont évaluées de manière très négative et qu'ils nuisent à la tenue des discussions, alors il faut protéger les contributeurs "normaux" aussi, parce que l'objectif du site n'est pas de fournir un espace de thérapie.
S’il y a effectivement du code qui peut être cassé à chaque évolution du langage, on est très loin de ce que tu décris et de la fréquence que tu sembles indiquer.
Les évolutions du langage, c'est tous les 2 ou 3 ans. Et ça m'arrive très souvent de passer du temps à rebricoler des trucs pour compiler du vieux code, simplement parce que les compilateurs corrigent des bugs d'implémentation de la norme (des trucs qui émettaient un warning et qui donnent une erreur, des syntaxes illicites qui passaient mais qui ne passent plus). Évidemment, pour un projet à soi, on s'en fout (une demi-journée tous les trois ans, ça n'est pas la mer à boire), mais pour l'ensemble de l'écosystème, c'est juste chiant. Et du coup, l'idée de compiler du vieux code non-trivial sans mettre les mains dans le cambouis, ça ne fonctionne pas. Alors un truc dégueu (genre goto) qui devient déprécié, ça gène qui exactement? Surtout que tu pourrais avoir une option du compilo pour dire "compile-moi ça quand même".
Le problème, c'est que C++ ne veut pas choisir entre la rétrocompatibilité C et le C with classes d'un côté, et un langage objet moderne de l'autre côté. Est-ce qu'on peut promouvoir indéfiniment ce modèle chimérique? Ça intéresse qui exactement de pouvoir faire un printf avec un argument template? Évidemment, tu peux lire des bouquins, des guidelines, des tutoriels, mais si le langage te transmets l'idée qu'il y a 75 manières de faire quelque chose et qu'il est neutre à ce sujet, il y a un problème. Si la cohérence du language tient au respect de quelques bonnes pratiques qui ne sont pas implémentées par défaut, alors il y a un problème (par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?).
Sur le fond, la question n'est pas sur la complexité de certaines techniques très poussées qui ne servent qu'à une toute petite fraction des développeurs. C'est peut-être cool de pouvoir surcharger "new" ou "*", personnellement je m'en fous. Par contre, il est anormal que cette souplesse s'accompagne de bizarreries historiques portant sur du code complètement courant (typiquement, les arguments de main), des syntaxes WTF, ou des subtilités pédantesques (personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser).
Par contre ce que tu appelles un gadget reste utile pour les contributeurs qui, sans être des trolls, ont parfois un comportement qui gène certains.
L'un n'empêche pas l'autre, bien sûr!
Et on n'est pas des machines non plus, quelqu'un comme Zenitram pourrait être artificiellement protégé de l'algo anti-spam, parce qu'il est énervant mais (parfois) constructif.
voir ce que j'ai dit ci-dessus. Et avec la pénurie d'IPV4, ça risque d'arriver de plus en plus souvent.
Je pense que tu as un peu de mal à évaluer les ordres de grandeur. Il y a environ 100 ouvertures de compte par mois. Même s'il n'y avait que dix millions d'adresses IP en France et que ça tournait tous les jours, la probabilité de se retrouver le jour de l'ouverture de compte avec la même IP que quelqu'un qui a ouvert un compte dans les 30 derniers jours serait de 0.000003. En moyenne, si mes calculs sont bons, une collison devrait arriver au rythme effréné d'une tous les 11000 mois, soit une fois tous les 926 ans.
Et donc, une fois tous les 926 ans, quelqu'un devra attendre le lendemain pour ouvrir un compte sur linuxfr. Y'a pas à dire, c'est problématique.
Loin de moi de douter de la popularité de Linuxfr, mais tu suggères réellement que tu crains de ne pas pouvoir créer de compte parce que tu risques d'avoir la malchance de récupérer aléatoirement l'IP de quelqu'un qui vient de se faire bannir?
Même derrière un proxy, la question n'est que de bloquer la création de compte pendant un certain délai (15 jours?) à partir de la dernière IP d'un compte banni. Les chances que ça gène quelqu'un sont quand même minces…
Je pense que c'est exactement pour éviter de telles situations que certains utilisateurs devraient être bannis. Le harcèlement par des trolls peut être très mal vécu, et on peut vouloir garantir un minimum de confort aux lecteurs réguliers.
D'un autre côté, un forum ouvert, c'est quand même un peu comme un match de rugby. Le principe, c'est quand même de prendre des gnons et de les rendre, tout en ne perdant pas de vue que ça n'est pas l'objectif. Si on se sent un peu fragile, c'est peut-être assez dangereux de se lancer sans protection dans une conversation trollifère sur les choix alimentaires.
C'est pas un problème que quelque chose d'aussi courant soit si complexe
Bien sûr que si, et je trouve qu'il y a un peu de mauvaise foi dans les réponses du type "ouhlalala, ça restreindrait la liberté de l'utilisateur et ça biaiserait la philosophie du langage si on faisait ça". La gestion des en-tête en C++ est assez ridicule, c'est au programmeur de bricoler des directives au pré-processeur tout ça parce que le langage n'est pas fichu de reconnaitre un fichier de header. Ça gênerait la liberté de qui exactement si le langage était capable de reconnaitre la stucture de 99.9999% des programmes en C++? Il y a des gens qui "#include" des trucs autres que des .h?.
Avec des raisonnements comme ça, on ne change jamais rien. La liberté de l'utilisateur a bon dos… Y compris dans la justification de la non-dépréciation de syntaxes obsolètes qui n'ont aucune justification (goto, void*, etc). Il y a du code de 40 ans qui compile grâce à ces trucs? Qu'est-ce qu'on s'en fout, il est en général indispensable d'adapter le code de l'année d'avant quand on change de version de gcc de toutes manières…
L'idée n'est pas forcément d'empêcher techniquement l'enquiquineur de venir, parce qu'en effet, c'est très compliqué. Mais d'expérience, si on arrive à lui mettre des bâtons dans les roues, il va se lâcher.
Une possibilité, par exemple, c'est qu'une fois atteint une limite de karma négatif, le compte est gelé et tous les messages notés négativement sont supprimés avec la mention ("compte fermé pour trollage") quand quelqu'un a répondu, et disparition totale quand personne n'a répondu. L'avantage, c'est que si le troll a exceptionnellement contribué de manière positive à une discussion, alors son message est conservé. C'est juste que tous ses messages "pourris" sont retirés.
Ensuite, il suffit de compliquer un peu la recréation de comptes. Par exemple, ne pas pouvoir recréer un compte avec la même adresse email, ou limiter la création de comptes à partir de la même IP. Bien sûr, techniquement, ça n'empêche pas la création de comptes, mais ça va demander au malandrin de passer du temps à se créer un email jetable, à trouver un moyen de changer d'IP, etc.
Mais bon, je pense que le plus efficace reste quand même la disparition des messages. Évidemment, ça ne peut fonctionner que si ça disparait pour tout le monde, et pas seulement de quelques utilisateurs qui usent d'un gadget. L'ultime but du troll est d'exister. S'il sévit une journée entière, qu'il se récolte un karma de -10000, et que le soir toutes ses contributions disparaissent, le gars aura perdu sa journée. On saura tous qu'il est inutile de lui répondre car il va disparaitre, il va donc parler tout seul. Un tel effacement numérique est probablement tellement insupportable pour un troll qu'il ne va pas rester longtemps : rien ne sert de gueuler contre la censure, contre les autres, contre les modérateurs, chaque jour, tout ce que le mec a fait disparait.
Le comble du bonheur serait à mon avis de ne pas fermer son compte par une procédure lourde. Juste faire en sorte que quand il se loggue, il voit ses messages comme si de rien n'était. Pour lui ça ne changerait rien, il continuerait à troller, vociférer, intervenir partout. Sauf que personne d'autre que lui ne voit ses messages.
[^] # Re: Question HS
Posté par arnaudus . En réponse au message Administrateur Système Linux Junior H/F. Évalué à 7.
Mouais, il est aussi illicite de discriminer selon la couleur de peau ou la religion, mais pourtant l'annonce n'indique pas européen/africain/asiatique ni juif/musulman/athée/chrétien…
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 3. Dernière modification le 24 octobre 2016 à 17:42.
Moi je vois des problèmes très concrets avec une représentation interne qui suit exactement les spécifications du document XML. Ça veut dire que l'évolution du logiciel est totalement liée à l'évolution du standard—et donc, que l'indépendance vis-à-vis d'un standard concurrent est totale. Par ailleurs, je ne vois pas du tout dans ce cas comment supporter plusieurs standards, à moins d'avoir du code spécifique pour chacun des standards (autrement dit, quand on clique sur "gras", le bout de code appelé va être différent en fonction du type de fichier d'entrée).
De toutes manières, historiquement, LibreOffice/OpenOffice/StarOffice précède très largement l'idée même de document XML, c'est à dire que le format OpenOducment a probablement été défini à partir de la représentation interne des documents dans le code, et pas le contraire.
Du coup, j'ai l'impression que c'est injuste de reprocher à LibreOffice son manque de support d'OOXML. Il me semble évident que les logiciels qui ont été développés après la publication du standard OOXML ont pu calquer leur architecture sur le format, ce qui rend tout de suite la compatibilité plus facile. Je ne sais pas exactement comment LibreOffice gère les différents formats, mais aucune solution ne semble parfaite : soit on crée de moulinettes pour transformer l'OOXML en OpenDocument, puis OpenDocument vers OOXML, soit les deux formats sont importés dans la représentation interne de LibreOffice puis exportés (avec perte d'info pour les fonctionnalités d'OOXML non supportées), mais je dirais que les problèmes d'intercompatibilité sont principalement dûs à des contraintes d'architecture, et pas à une incompétence des developpeurs.
D'ailleurs, comment est-ce que OnlyOffice et al se débrouillent avec les documents odt?
# Question HS
Posté par arnaudus . En réponse au message Administrateur Système Linux Junior H/F. Évalué à 0.
Désolé de pourrir le fil avec une question idiote, mais je n'ai pas l'habitude des petites annonces, et je suis surpris par la mention "H/F": est-il réellement nécessaire de préciser quelque chose qui ne peut légalement pas être autrement? C'est un peu comme la mention "Sans colorants ni conservateurs conformément à la règlementation"?
[^] # Re: Super
Posté par arnaudus . En réponse à la dépêche Six nouveaux services chez Framasoft (30 au total). Évalué à 2.
Pas seulement, ddg est un méta-moteur de recherche, on peut éventuellement le voir comme une manière d'anonymiser ses recherches google, mais certainement pas comme une alternative à Google. Comme même les autres moteurs de recherche commerciaux vont sniffer Google, ça me parait compliqué de s'en passer.
Et puis, il faut bien réaliser que si Google souhaitait obtenir des infos sur vous, il pourrait même quand vous utilisez ddg. Pour des sites qui ne sont pas hyper-fréquentés, il suffit de croiser les remontées de Google analytics avec les réponses aux requêtes provenant de ddg.
[^] # Re: Harmonie ?
Posté par arnaudus . En réponse à la dépêche Sortie de la bibliothèque d’analyse musicale Bliss 1.0. Évalué à 3.
Peut-être, mais je ne connais pas beaucoup de styles de musique occidentale où on n'a pas tendance à finir sur la tonalité du morceau, même quand ça module (et il n'y a pas beaucoup de modulation en pop, rock, etc), ça revient à la tonalité de départ sur la fin.
D'ailleurs, il faudrait peut-être que des spécialistes s'expriment là dessus, mais il me semble bien que classiquement, que si on ne termine pas par l'accord majeur de dominante, on n'enchaine pas forcément sur la nouvelle tonalité. Par exemple, dans les suites de Bach, on peut terminer sur une tierce picarde et enchainer sur une tonalité mineure ; inversement, les enchainements majeur/mineur se font sans transition particulière.
Ceci dit, la règle générale en musique classique reste de suivre les règles de la modulation pour enchainer les morceaux, les transitions se font entre tonalités proches, ou éventuellement entre mode majeur et mode mineur dans la même tonalité (ce qui s'entend pas mal quand même).
[^] # Re: Money makes the world go round
Posté par arnaudus . En réponse au journal Les routeurs Turris Omnia sont livrés. Évalué à 5.
Je ne suis pas certain que tu aies bien compris ce qu'était le travail :-)
[^] # Re: Money makes the world go round
Posté par arnaudus . En réponse au journal Les routeurs Turris Omnia sont livrés. Évalué à 7.
C'est probablement insultant pour les gens de ta génération qui ont assez de maturité pour s'arrêter quand ils se rendent compte qu'ils ne comprennent rien à la discussion qu'ils ont lancée.
[^] # Re: De la difficulté à obtenir un rendu [...] HTML, cohérent entre les différentes plateformes
Posté par arnaudus . En réponse au journal De la difficulté à obtenir un rendu SVG, voire HTML, cohérent entre les différentes plates‐formes. Évalué à 10.
Parce que c'est bien connu, les autres industries sont tout à fait capables de se mettre d'accord sur des standards, de les implémenter, et de les respecter.
Quand tu changes des essuie-glaces, par exemple, tu choisis la taille… et tu te démerdes parce que les petits bitonios en plastique pour la fixation sont tous différents.
Quand tu achètes une cafetière à dosettes, bien entendu, elles utilisent toutes les mêmes dosettes et donnent toutes le même café.
Quand ton pot de peinture est terminé, bien entendu, tu peux acheter un pot d'une autre marque qui porte le même nom de couleur et tu auras exactement la même nuance.
La plupart du temps, il faut juste apprendre à vivre dans un monde imparfait. Il existe des normes, parfois les fabricants s'en foutent, parfois ils essayent de les implémenter, mais à moins d'avoir une très bonne raison pour le faire, il y a toujours des choses qui déconnent. Même quand le standard existe est est appliqué (par exemple les ampoules électriques), tu as la certitude que ton ampoule va rentrer dans le culot, mais parfois ça coince parce que le bulbe est trop gros, trop effilé, trop long ; et qu'à puissance égale tu peux avoir de grosses différences de température de couleur, ce qui fait que si tu veux un truc cohérent, il faut changer toutes tes ampoules en même temps.
S'il existait un organisme de vérification de conformité des navigateurs internet qui t'empêchait physiquement d'éditer un navigateur internet dans le monde entier tant qu'il ne passe pas un certain nombre de tests très stricts sur le respect des standards, alors peut-être qu'on aurait un peu plus de cohérence. Mais personne ne voudrait d'un truc aussi lourd et contraignant, c'est comme ça.
[^] # Re: mon avis
Posté par arnaudus . En réponse au message Swap utilisé au réveil du PC. Évalué à 2.
Si c'est ce qu'il fait, ça n'est pas très intelligent. Ça veut dire que tu peux payer le coût de l'hibernation des heures après être sorti du sommeil.
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 8.
C'est peut-être ce que dit la théorie, mais en pratique, ça ne peut fonctionner que pour des modifs hyper-mineures. Prend au pif un tableau XHTML
Imagine que ton éditeur ne comprend pas align. Ton utilisateur te demande de dupliquer la deuxième ligne du tableau. Tu vas faire quoi? 1) Dupliquer les attributs que tu ne comprends pas? Ou alors 2) créer une ligne sans attributs d'alignement?
Dans le cas 1), tu vas te mettre dans une situation où le document est potentiellement corrompu, invalide, ou ininterprétable par l'autre logiciel : par définition, les arguments que tu ne comprends pas, ils devraient peut être n'apparaitre qu'une fois, ou que dans un contexte particulier.
Dans le cas 2), tu es quasiment certain de produire une mise en page cassée. Dans ton logiciel qui n'aligne pas les tableaux, rien ne sera aligné, et le tableau sera cohérent. Mais dans un logiciel qui comprend tout le standard, alors la mise en page sera pétée. Au passage, rien ne te garantit que ton document sera valide, car il est possible que l'attribut que tu n'as pas compris n'ait de sens que s'il est présent dans toutes les lignes.
Et puis, encore une fois, je ne sais pas comment fonctionne LibreOffice ou les autres traitements de texte en interne, mais il est plus que probable que leur fonctionnement n'implique pas de lier toutes les opérations "en live" à la modification d'un arbre XML. Il me semble probable que le logiciel ait une représentation interne (sous forme de classes par exemple) des différents éléments, et que l'arbre XML soit créé à l'enregistrement du fichier—du coup, la représentation interne ne peut pas garder les nœuds incompris et les manipuler.
Sous LibreOffice, c'est exactement ce qu'on te dit quand tu manipules des fichiers OOXML.
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 8.
Oui oui, comme les lessives qui innovent sur le colorant et le parfum. Je sais bien que la plupart des gens considèrent que c'est de l'innovation, mais il ne faut pas charrier : les logiciels de traitement de texte ont besoin d'innover sur bien plus que l'interface pour avoir un rendu acceptable.
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 7.
Ça parait quand même très très compliqué de faire autrement, non? Bien sûr, tu peux créer un logiciel capable de modifier de manière marginale un document sans changer sa structure, mais dès que tu souhaites toucher à des choses fondamentales (mise en page, changement de structure du document…), je ne vois pas comment tu peux t'épargner l'étape de charger la totalité du fichier dans ton abstraction interne. Une fois à cette étape là, plus moyen de revenir en arrière… Bien sûr, tu peux imaginer un système qui essaye de remettre les nœuds incompris à peu près là où ils étaient, mais je ne vois pas quelle garantie tu peux avoir qu'ils aient toujours un sens…
[^] # Re: Paradoxale ?
Posté par arnaudus . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 1.
Ça ne prouve pas grand chose, ça peut être un bug dans LibreOffice ou dans MSWord, ou ça peut venir de l'existence de propriétés documentées dans OOXML qui ne sont pas prises en charge dans le format odt et/ou par Libreoffice.
De toutes manières, ces formats sont beaucoup trop complexes pour être interchangeables. Pour cela, il faudrait que toutes les possibilités d'OOXML se retrouvent dans OpenDocument et vice-versa, ET que les logiciels MS Word et Libre Office soient capables de gérer l'ensemble de ces possibilités. Le mieux qu'on puisse espérer, c'est que chaque logiciel soit capable de lire les deux formats, et d'importer le sous-ensemble commun entre les deux.
À la base, le principe même de la normalisation des formats est contradictoire avec la notion de format natif. Ça bloque l'évolution des fonctionnalités des logiciels, et ça empêche d'innover sur le fond par rapport à ses concurrents.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
Dans ce cas, le concept même de coder en C++ a un impact sur les performances. Parce que si tu n'utilises pas le polymorphisme, ni la STL, ni les exceptions, ni les templates et que tu préfères utiliser des pointeurs nus et des macros, alors ça ressemble furieusement à ce que certains appellelent du C/C++, qui n'est en fait ni du C ni du C++.
Au passage, la règle pourrait bien être que les destructeurs d'une classe qui a au moins une méthode virtuelle sont virtuels. Ou de définir un mot clé "nonvirtual" pour les 0.01% des cas où on veut explicitement éviter la création d'une vtable.
Dans ce cas, je ne vois pas le problème à surcharger la fonction main, une en
int main(int, char**)et une enbool main(vector<string>). Encore une fois, si tu veux faire du C/C++, tu peux utiliser la version C, le compilo peut bien voir quelle version tu utilises.On pourrait débattre indéfiniment sur la cible première du C++, mais la performance et la portabilité ne peuvent pas être les deux seuls critères ; autrement, les gens feraient du C. Le C++, c'est avant tout la POO, la programmation générique, l'encapsulation, la STL, et tous les petits trucs du C++ moderne (lambda, inférence de type, shared_pointers, etc). Je t'accorde qu'il existe des gens comme toi qui interprètent le langage en tant que C amélioré, et notamment qui pondèrent l'utilisation d'un certain nombre de fonctionnalités du langage par les coûts induits en temps d'exécution et en mémoire. Mais il faut aussi voir que pour une très vaste communauté, ces choses n'ont aucun intérêt par rapport aux avantages de l'encapsulation, de la gestion des erreurs, ou des vérifications de types faites à la compilation?
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Honnêtement, je ne comprends pas à quelle catégorie d'erreur tu faisais allusion (dans quelle mesure est-ce que la critique de la non-gestion des modules est-elle obsolète?).
Tu as une manière "officielle" de gérer les en-têtes, c'est 1) d'inclure les fichiers .h à l'aide d'une directive du pré-compilateur, ce qui reste un procédé hyper-bourrin (en gros, un copié-collé du header, qui sera recompilé pour chaque .cpp), et 2) d'inclure "à la main" des directives du pré-compilateur pour s'assurer que le header ne sera inclus qu'une fois. Autant dire que les modules ne sont absolument pas gérés, il faut tout faire soi-même. Le langage ne sait même pas ce qu'est un module, la seule chose qu'il sait faire c'est d'acceper une déclaration dans le même fichier an amont de la définition. C'est tellement une limite du langage que les compilos ont développé des pragma (à l'origine absolument pas standard) pour faciliter un peu la vie.
À mes yeux, ta réponse confirme simplement ce que d'autres essayent de dire dans ce fil : en C++, la gestion des modules est quasi-inexistante, et repose sur un procédé obsolète et bancal. Les pragma once et autres sucres syntaxiques ne résolvent pas le problème, et tu ne fais qu'insister sur le fait qu'il s'agit de solutions techniquement bancales. Du coup, on est tous d'accord, j'ai juste l'impression que tu trouves le système par défaut acceptable (et, de facto, il l'est puisqu'on l'utilise tous). C'est juste un peu dommage que tu ne sembles pas voir l'intérêt d'un système de modules moderne.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
Du coup, tu peux les corriger avec des faits? C'est plutôt ça qui serait utile.
En particulier, les choses qui étaient vraies et qui ne sont plus vraies, c'est tout à fait possible qu'on puisse ne pas être au courant. Une telle erreur peut être faite de bonne foi, et si tu as l'info permettant de la rectifier, je ne vois pas pourquoi te priver de répondre poliment.
[^] # Re: Modération laxiste
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 4.
Peut-être, mais certains sont les imbéciles de beaucoup de gens, ce qui veut probablement dire beaucoup.
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 5. Dernière modification le 04 octobre 2016 à 18:01.
L'argument, c'est qu'il ne faut pas être méchant avec les trolls, parce qu'on ne sait jamais s'il ne vont pas pêter une diurite et buter des gens?
En fait, c'est un appel à la soumission, ton truc. Ton voisin est violent? Ne le contrarie pas, c'est un coup à prendre un bourre-pif. Ton patron te harcèle? Ne proteste pas, c'est un coup à te faire virer.
Je ne suis pas psychiatre. Je ne peux pas savoir si mon interlocuteur est violent ou non, s'il a pris ses médicaments, s'il utilise les forums comme thérapie ou au contraire si ça risque de renforcer sa névrose. Le plus sain, c'est d'essayer en douceur d'inciter les gens qui ont des problèmes à se faire soigner, et d'éviter au maximum qu'ils puissent interagir avec les gens qui veulent savoir pourquoi leur programme ne compile pas, et qui pourraiernt réagir d'une manière peu constructive.
Au passage, une certaine forme de névrose est quand même tolérée dans le milieu du libre. Par contre il faut coder comme un dieu pour se permettre d'insulter les gens.
Je pense que personne n'a jamais suggéré de mettre en place un test anti-névrosé et de leur interdire la lecture ou la contribution. C'est juste que quand un historique de contributions substantiel prouve que leurs contributions sont évaluées de manière très négative et qu'ils nuisent à la tenue des discussions, alors il faut protéger les contributeurs "normaux" aussi, parce que l'objectif du site n'est pas de fournir un espace de thérapie.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Les évolutions du langage, c'est tous les 2 ou 3 ans. Et ça m'arrive très souvent de passer du temps à rebricoler des trucs pour compiler du vieux code, simplement parce que les compilateurs corrigent des bugs d'implémentation de la norme (des trucs qui émettaient un warning et qui donnent une erreur, des syntaxes illicites qui passaient mais qui ne passent plus). Évidemment, pour un projet à soi, on s'en fout (une demi-journée tous les trois ans, ça n'est pas la mer à boire), mais pour l'ensemble de l'écosystème, c'est juste chiant. Et du coup, l'idée de compiler du vieux code non-trivial sans mettre les mains dans le cambouis, ça ne fonctionne pas. Alors un truc dégueu (genre goto) qui devient déprécié, ça gène qui exactement? Surtout que tu pourrais avoir une option du compilo pour dire "compile-moi ça quand même".
Le problème, c'est que C++ ne veut pas choisir entre la rétrocompatibilité C et le C with classes d'un côté, et un langage objet moderne de l'autre côté. Est-ce qu'on peut promouvoir indéfiniment ce modèle chimérique? Ça intéresse qui exactement de pouvoir faire un printf avec un argument template? Évidemment, tu peux lire des bouquins, des guidelines, des tutoriels, mais si le langage te transmets l'idée qu'il y a 75 manières de faire quelque chose et qu'il est neutre à ce sujet, il y a un problème. Si la cohérence du language tient au respect de quelques bonnes pratiques qui ne sont pas implémentées par défaut, alors il y a un problème (par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?).
Sur le fond, la question n'est pas sur la complexité de certaines techniques très poussées qui ne servent qu'à une toute petite fraction des développeurs. C'est peut-être cool de pouvoir surcharger "new" ou "*", personnellement je m'en fous. Par contre, il est anormal que cette souplesse s'accompagne de bizarreries historiques portant sur du code complètement courant (typiquement, les arguments de main), des syntaxes WTF, ou des subtilités pédantesques (personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser).
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 5.
L'un n'empêche pas l'autre, bien sûr!
Et on n'est pas des machines non plus, quelqu'un comme Zenitram pourrait être artificiellement protégé de l'algo anti-spam, parce qu'il est énervant mais (parfois) constructif.
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 10.
Je pense que tu as un peu de mal à évaluer les ordres de grandeur. Il y a environ 100 ouvertures de compte par mois. Même s'il n'y avait que dix millions d'adresses IP en France et que ça tournait tous les jours, la probabilité de se retrouver le jour de l'ouverture de compte avec la même IP que quelqu'un qui a ouvert un compte dans les 30 derniers jours serait de 0.000003. En moyenne, si mes calculs sont bons, une collison devrait arriver au rythme effréné d'une tous les 11000 mois, soit une fois tous les 926 ans.
Et donc, une fois tous les 926 ans, quelqu'un devra attendre le lendemain pour ouvrir un compte sur linuxfr. Y'a pas à dire, c'est problématique.
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 3.
Loin de moi de douter de la popularité de Linuxfr, mais tu suggères réellement que tu crains de ne pas pouvoir créer de compte parce que tu risques d'avoir la malchance de récupérer aléatoirement l'IP de quelqu'un qui vient de se faire bannir?
Même derrière un proxy, la question n'est que de bloquer la création de compte pendant un certain délai (15 jours?) à partir de la dernière IP d'un compte banni. Les chances que ça gène quelqu'un sont quand même minces…
[^] # Re: Modération laxiste
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 6.
Je pense que c'est exactement pour éviter de telles situations que certains utilisateurs devraient être bannis. Le harcèlement par des trolls peut être très mal vécu, et on peut vouloir garantir un minimum de confort aux lecteurs réguliers.
D'un autre côté, un forum ouvert, c'est quand même un peu comme un match de rugby. Le principe, c'est quand même de prendre des gnons et de les rendre, tout en ne perdant pas de vue que ça n'est pas l'objectif. Si on se sent un peu fragile, c'est peut-être assez dangereux de se lancer sans protection dans une conversation trollifère sur les choix alimentaires.
Non c'est sûr, c'est constructif.
[^] # Re: Donc pour résumer…
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Bien sûr que si, et je trouve qu'il y a un peu de mauvaise foi dans les réponses du type "ouhlalala, ça restreindrait la liberté de l'utilisateur et ça biaiserait la philosophie du langage si on faisait ça". La gestion des en-tête en C++ est assez ridicule, c'est au programmeur de bricoler des directives au pré-processeur tout ça parce que le langage n'est pas fichu de reconnaitre un fichier de header. Ça gênerait la liberté de qui exactement si le langage était capable de reconnaitre la stucture de 99.9999% des programmes en C++? Il y a des gens qui "#include" des trucs autres que des .h?.
Avec des raisonnements comme ça, on ne change jamais rien. La liberté de l'utilisateur a bon dos… Y compris dans la justification de la non-dépréciation de syntaxes obsolètes qui n'ont aucune justification (goto, void*, etc). Il y a du code de 40 ans qui compile grâce à ces trucs? Qu'est-ce qu'on s'en fout, il est en général indispensable d'adapter le code de l'année d'avant quand on change de version de gcc de toutes manières…
[^] # Re: Comptes à -10
Posté par arnaudus . En réponse au sondage La modération a posteriori des contenus et commentaires problématiques sur LinuxFr.org. Évalué à 5.
L'idée n'est pas forcément d'empêcher techniquement l'enquiquineur de venir, parce qu'en effet, c'est très compliqué. Mais d'expérience, si on arrive à lui mettre des bâtons dans les roues, il va se lâcher.
Une possibilité, par exemple, c'est qu'une fois atteint une limite de karma négatif, le compte est gelé et tous les messages notés négativement sont supprimés avec la mention ("compte fermé pour trollage") quand quelqu'un a répondu, et disparition totale quand personne n'a répondu. L'avantage, c'est que si le troll a exceptionnellement contribué de manière positive à une discussion, alors son message est conservé. C'est juste que tous ses messages "pourris" sont retirés.
Ensuite, il suffit de compliquer un peu la recréation de comptes. Par exemple, ne pas pouvoir recréer un compte avec la même adresse email, ou limiter la création de comptes à partir de la même IP. Bien sûr, techniquement, ça n'empêche pas la création de comptes, mais ça va demander au malandrin de passer du temps à se créer un email jetable, à trouver un moyen de changer d'IP, etc.
Mais bon, je pense que le plus efficace reste quand même la disparition des messages. Évidemment, ça ne peut fonctionner que si ça disparait pour tout le monde, et pas seulement de quelques utilisateurs qui usent d'un gadget. L'ultime but du troll est d'exister. S'il sévit une journée entière, qu'il se récolte un karma de -10000, et que le soir toutes ses contributions disparaissent, le gars aura perdu sa journée. On saura tous qu'il est inutile de lui répondre car il va disparaitre, il va donc parler tout seul. Un tel effacement numérique est probablement tellement insupportable pour un troll qu'il ne va pas rester longtemps : rien ne sert de gueuler contre la censure, contre les autres, contre les modérateurs, chaque jour, tout ce que le mec a fait disparait.
Le comble du bonheur serait à mon avis de ne pas fermer son compte par une procédure lourde. Juste faire en sorte que quand il se loggue, il voit ses messages comme si de rien n'était. Pour lui ça ne changerait rien, il continuerait à troller, vociférer, intervenir partout. Sauf que personne d'autre que lui ne voit ses messages.