jyes a écrit 906 commentaires

Mais quel est l'intéret d'avoir un service de gestion de contacts "dans le cloud" ?

Ça dépend, si c’est Dans Ton Cloud, c’est intéressant. Mais là, pour le coup, les distributions fournissent tous les outils libres pour le mettre en place, il y a même de multiples choix pour y parvenir (IMAP, CalDAV, SSHFS, et autres au gré de votre imagination) qui sont parfaitement supportés par les logiciels serveurs et clients libres.

Donc, quand fredix écrit :

Mais les desktop Linux avancent aussi puisqu'il utilise les services proprio des autres :)

je pense qu’il est d’une complète mauvaise foi, puisque la liberté est donnée aux utilisateurs à la fois côté client, et côté service. Par contre, c’est vrai, certains clients n’imposent pas de gérer soi-même son propre service et peuvent aussi utiliser des services proprios, mais je ne vois pas de quelle liberté prive le client dans ce cas là.

Sinon, j’aime bien le système des distributions Linux modernes. Ma Fedora au travail passe en revue les bibliothèques chargées avant chaque mise à jour, et si l’un d’elle est affectée par la mise à jour, j’ai une alerte qui propose de redémarrer le système ou la session au besoin (sans ultimatum de 4 heures).

les boites proposent rarement un salaire

Et qu’est-ce qui les en empêche, si ça peut les aider à trouver des candidats plutôt que de se plaindre de pénurie ?

je vous conseille juste de garder l'implémentation naïve

Ça, git le fait pour moi :-)

Merci de vos retours.

(il me semble qu'on imagine aisément qu'openMP fait N filaments pour traiter un segment, alors qu'en réalité il en fait au maximum N simultanément et qu'en permanence des filaments naissent vivent et meurent dans l'indifférence générale ;-)

Non. D’ailleurs dans le code que j’utilise, les filaments [0] sont créés une fois et synchronisés (le plus rarement possible) à coup de « barrier ». C’est à peu près ce que fait automatiquement le compilateur avec l’ordonnanceur « static », mais :

• le code est plus simple : moins encombré de directives OpenMP;
• plus facile à comprendre : synchronisation explicite là où elle est nécessaire, plutôt que de se poser toujours la question de l’usage ou non de la règle « nowait »;
• et plus souple : on peut décider de faire un partage déséquilibré du calcul entre filaments si l’on sait à l’avance que certains traitement seront plus longs que d’autres, sans pour autant compliquer le code avec un ordonnancement dynamique.

[0] Je ne connaissais pas cette traduction, elle me plaît bien, j’espère qu’elle est assez utilisée pour pouvoir l’adopter définitivement en restant compréhensible.

Au final, le résultat obtenu ressemble assez à une parallélisation MPI (avec le double avantage de la mémoire partagée et que le code peut toujours se compiler en séquentiel pour déboguer), c’est pourquoi la découpe des tableaux n’aurait pas été si difficile. Suivant vos conseils, je vais quand même me l’épargner si elle n’apporte rien.

Merci du conseil, c’est un peu le genre de remarque que j’attendais. Cependant, si je me pose la question, ce n’est pas vraiment pour gérer moi-même la mémoire avec des fonctions prenant en compte NUMA, c’est juste pour choisir la méthode de parallélisation la plus efficace, sans vraiment sortir des clous d’OpenMP.

À la lecture de l’ensemble des réponses, il semble que le meilleur compromis soit de ne pas me préoccuper de NUMA directement mais d’allouer un tableau de donnée par thread (façon MPI), en laissant au système d’exploitation le soin de gérer la proximité entre le stockage de ce tableau en mémoire et le thread associé. Un seul gros tableau ne pouvant être proche de tous les threads à la fois, il se retrouvera forcément loin d’un certain nombre d’entre eux. Au besoin, s’assurer que mon code accède bien la première fois à chaque espace mémoire depuis le bon thread (pour tenir compte du « first touch ») n’est pas bien compliqué.

on ne saurait trop vous recommander des tests de performance extensifs ; histoire d'éviter de vous échiner sur un faux problème

Effectuer de bons tests risque de me prendre autant de temps que de découper mes tableaux, j’en ferai mais ça ne me coûte pas grand chose d’envisager la méthode la plus efficace en amont de ces tests.

Merci à tous pour vos réponses utiles !

I personally have no problem with anyone studying it, modifying it, attempting to run it, etc

Donc il n’est pas question de redistribution, sauf si elle se cache dans le « etc » (et c’est vrai qu’un dépôt Git sans redistribution c’est étrange), mais je doute qu’Ubisoft cautionne ce dernier usage.

je peux pas te mettre mon point dans la gueule

Là, tu marques un poing.

le jour où j'en aurai besoin et que j'étudierai les solutions, PGP aura un gros point négatif "vérification manuelle lors de la première validation" dans le comparatif.

Note que tu as exactement le même problème avec X509, sauf que tu acceptes les certificats racine sans broncher. Avec PGP, tu pourrais très bien accepter n’importe quelle clé qui a été signée par un “pair de confiance”. L’ennui, c’est que dans la démarche de sécurité complète, il faudrait d’abord avoir confiance en la clef de ce pair, ce que tu ne fais pas en récupérant tes certificats racines avec ton Firefox téléchargé en HTTP (avec contrôle de la somme de hachage fournie sur la même page servie en HTTP).

La toile de confiance permet très bien de reproduire le schéma en arbre des certificats, c’est juste qu’à parti du moment où tu veux utiliser PGP, les documentations t’indiquent comme le faire de sorte à ce que tu aies vraiment de la sécurité. La « vérification manuelle » n’a rien d’indispensable sur le plan technique.

dans un (plusieurs !) coffre-fort(s).

Et même encore plus de coffres forts en n’y conservant qu’une clef partielle [0], comme ça même les coffres ne connaissent pas la clef.

[0] avec un truc comme « Shamir’s secret sharing scheme ».

Elle aura aussi confiance, mais elle se fera avoir : http://www.thoughtcrime.org/software/sslstrip/

Il semble bien que ce soit un problème dans la police. Cependant, tu remarqueras que c’est problématique uniquement en grande taille (vue en 11pt, ce problème de crénage ne saute pas aux yeux) et que pour les grandes tailles, la version Display n’en souffre pas.

Dès lors, je ne sais pas s’il s’agit d’un véritable problème ou d’un usage inapproprié de la police. Par exemple, je regarde mon CV qui utilise cette police et je ne vois pas de problème (à moins que XeTeX corrige le crénage et n’utilise pas les informations fournies par la police).

Je n’ai acheté que le premier, après l’« annonce » de libération des moteurs de plusieurs jeux. J’y ai joué un peu, mais ne suis de toute façon pas un gros joueur. Il n’a jamais été question de libérer quoi que ce soit dans les suivants et je ne les ai donc pas achetés. Si j’avais plus l’habitude de jouer, je ne sais pas si je me serais toutefois laissé tenter par les suivants : si j’avais des sous à dépenser pour soutenir des projets que je trouve intelligents, il y a déjà beaucoup de projets libres qui améliorent mon quotidien et qui méritent bien plus mon soutien que les Humble Bundles.

Du coup, j’ai voté Obiwan Kenobi parce-que la Force est avec le Logiciel Libre et qu’il n’y avait pas de réponse D.

Non, tu peux utiliser un gestionnaire de fenêtre et un compositeur indépendants (même si Mutter, Compiz et Kwin embarquent leur propre compositeur). Rien ne t’empêche d’utiliser Metacity avec xcompmgr.

Parce que beaucoup de gestionnaires de fenêtres embarquent leur propre compositeur (historiquement Compiz, puis Kwin, Mutter, etc), mais tu peux aussi trouver des compositeurs autonomes (xcompmgr, fbcompose, cairo-composer). Tu peux ainsi avoir un environnement « composité » avec fluxbox, openbox, window-maker, un tiling-wm ou n’importe quel gestionnaire qui ne dispose pas de son propre compositeur..

Personnellement, je ne sais pas comment ça fonctionne, mais je me sers tous les jours d’affichage déporté avec accélération graphique et ça marche ! C’est à dire que c’est la carte graphique de l’ordinateur qui affiche la fenêtre qui effectue le rendu. Cas typique d’utilisation, visualisation de résultats intermédiaires de simulation sans rapatrier les données, alors que la simulation tourne encore sur la machine de calcul.

Je ne vois pas comment Wayland pourra faire ça.

Après, peut-être que cette fonctionnalité n’est pas jugée primordiale, mais je ne vois pas l’intérêt d’enlever toutes les fonctionnalités de nos distributions Linux pour qu’elles ne fassent plus que ce que font les autres OS. Au début, j’étais très intéressé par Wayland, mais plus j’en apprends sur le projet, plus j’ai l’impression que ses concepteurs vont à contre-courant de ce que j’apprécie le plus au quotidien.

Autre exemple (pas une limitation forte de Wayland, mais ça montre l’état d’esprit de ses développeurs) : les décorations de fenêtres. Si ce sont aux fenêtres de dessiner elles-mêmes leur décoration, les différentes boites à outils graphiques produiront un résultat encore plus disparate à l’écran que le mélange FLTK/GTK/Qt d’il y a quelques années, dont l’allure générale était au moins unifiée par le gestionnaire de fenêtres. Et les fonctionnalités avancées de certains gestionnaires de fenêtres seront perdues aussi.

Ton LaTeX n’y changera rien, si la police change, c’est normal qu’un document qui l’utilise change aussi. J’ai eu le même problème avec mon CV fait avec LaTeX il y a peu. C’est sûr que vu l’évolution de la police Computer Modern, si tu te limites à celle-ci tu devrais éviter ce genre de soucis, mais tu peux aussi appliquer une politique très conservatrice vis-à-vis des polices sur ton système pour préserver la mise en forme avec LibreOffice.

LaTeX est excellent, mais le problème décrit ici est inévitable, quel que soit l’outil utilisé, puisqu’il se résume à : « si la mise en forme du document change (par le biais de la police utilisée) alors la mise en forme change ».

Il n’y a pas vraiment de raison d’être ironique sur ce point. Vim est loin d’être idéal pour traiter du XML car il n’a effectivement pas connaissance du schéma. Cela dit, même sans plugin particulier, le miens indique les balises qui ne sont pas refermées. De plus avec des trucs comme snipMate, il est assez simple de définir en même temps la partie ouvrante et la partie fermante de chaque balise.

Bon, maintenant, j’admets que j’ai un usage assez limité d’XML dans Vim, mais j’écris quand même mes transformations XSLT avec et m’en sors finalement. Pour répondre à la question du journal, les outils que j’utilise pour traiter le XML ensuite sont:

• xmlstarlet pour la validation et des fois plus. Il est très bien mais au final je l’utilise peu car beaucoup de ses fonctions sont redondantes avec les autres outils;
• xsltproc pour appliquer les transformations XSLT très rapidement et simplement;
• saxonb pour les transformations XSLT 2.0. Saxon B est libre mais relativement limité comparé à la version non-libre de Saxon. En pratique, Saxon B a toujours répondu à mon besoin quand xsltproc devenait insuffisant. Je n’ai jamais utilisé d’outils propriétaire car c’est mal et les outils libres sont de très bonne facture. Quand on l’utilise par un simple appel en ligne de commande, Saxon B présente néanmoins le défaut d’être en Java et de nécessiter un temps de chargement assez long relativement au temps de traitement des règles XSLT. En règle générale, je préfère donc xsltproc (ou pour un binaire, les libs qu’il utilise, soit libxml2 et libxslt1).

#!/bin/sh
# Utilisation du processeur XSLT Saxon B depuis la ligne de commande
CLASSPATH=/usr/share/java/saxonb.jar \
java net.sf.saxon.Transform -ext:off -s:$2 -xsl:$1 -o:$3

Note que par rapport au but de l’auteur, le miens va en sens inverse, j’utilise essentiellement les feuilles de style XSLT pour transformer du XML en LaTeX qui reste l’outil idéal pour produire de « beaux » documents finaux.

Je veux bien, mais je fais quoi du rpm qu'on m'a filé pour le logiciel que je voudrais mais qui est pas dans le repo officiel?

Tu le mets au même endroit que les .exe de ton OSX ou les .dmg de ton Windows. Moi aussi, je suis super deg’ de la segmentation, c’est nul micrapplesoft, je ne peux même pas y installer la toute dernière version de Claws-Mail sans le compiler moi-même ! [0]

[0] Et encore, je suis gentil, j’ai pris comme exemle un programme qui a une version pour Windows, mais elle est presque toujours en retard sur la version Debian.

Là j'ai l'impression de voir un certain à-priori typique Franco-Français du "qui est riche a forcément été et/ou est toujours un pourri!".

C’est un a priori car comme toutes les lois empiriques il souffre quelques limitations, cependant il me paraît difficile de nier la forte corrélation entre riche et pourri qui rend cet a priori finalement assez fiable. Ensuite, comme pour tous les modèles, il n’est valable qu’à un certain niveau de détail, quand on veut une meilleure distinction il faut passer à un autre modèle, plus fin.

Y'a pas de politburo qui juge "toi tu peux écrire, toi non".

eastwind☯ ne parle pas de choisir les auteurs, mais les articles, c’est ce qui distingue un magazine d’un blog : la politique éditoriale.

Parce que je fais [rien] et hop il lance inkscapce. [Rien] ou [rien] et hop je vais à la fenêtre en question.

Tout le monde n’a pas la chance d’avoir un ordinateur qui lit dans ses pensées (ou d’avoir son ghost dans le Gnome shell).

Non, il te parle de la réalité des choses, en l’état actuel.

Dans beaucoup de cas, derrière ce que tu appelles intuitivité, il y a ton habitude de l’univers Windows (ou OSX). Ce n’est pas lié à la discussion sur les manuels à lire ou non, mais à la critique selon laquelle si les logiciels libres n’attirent pas c’est qu’ils ne sont pas intuitifs. Ma grand-mère de 90 ans n’avait jamais vu Windows et s’est intéressée à « l’informatique » quand elle a vu que le clavier de mon portable ressemblait beaucoup à celui de sa machine à écrire dans sa jeunesse. Elle envoie désormais ses e-mails avec une Debian et un bureau Openbox qu’elle doit trouver bien plus « intuitifs » que ton Windows.

Il y aussi la voie 0 Install, disponible dans les distributions (zeroinstall-injector pour Debian). Cette solution aurait pu être prometteuse, mais la quasi-absence de logiciels distribués sous cette forme la rend difficilement utilisable en pratique… et, à mon avis, pour la plupart des usages, un gestionnaire de paquet classique est plus utile.

mais au détriment de quelques pertes (j'aimais bien le client irc intégré)

Et surtout, ça n’a rien allégé du tout. Maintenant Seamonkey est plus véloce que Firefox.