lasher a écrit 2732 commentaires

Ben écoute, perso j'ai rien contre systemd, mais si j'ai compris l'intention derrière le truc (tout comme je comprends celle derrière la plupart des scripts d'init), effectivement, j'aurais ete bien incapable de correctement décrire les étapes de cette unité.

Je suis globalement d'accord avec toi. Cependant, autant je ne demande pas à un admin de savoir écrire du code C++ utilisant la méta-programmation, les lambda fonctions, le tout couplé à un runtime écrit en OCaml, autant qu'il sache ce qu'est la programmation structurée, et qu'il sache lire des scripts, ça me semble la moindre des choses.

Bon, je voulais éviter de tomber dedans, mais je vais le faire (un ch'tit peu). Perso j'ai absolument rien contre l’idée d'un système d'init plus moderne/modulaire/configurable/. Et oui, un système d'init qui se concentre sur l'OS pour lequel il est fait, ça me semble raisonnable.

Ceci étant dit, le problème n'est pas tant que systemd existe, mais que d'autres softs de plus haut niveau se basent uniquement dessus, rompant donc avec la portabilité POSIX/UNIX. Donc par exemple si GNOME décide de se baser sur systemd, mais sans offrir une couche de compatibilité "dégradée", je trouve ça extrêmement gênant, et ce, même si personnellement je n'ai plus touché de BSD depuis quelques années.

Quelle norme de Fortran ? Parce que Fortan > 77 est moderne, propose de la programmation structurée… ;)

Je ne vois pas de quoi tu parles. Dans LOo 4.1.3.2, si je clique sur la liste déroulante des styles, et ensuite que je clique sur « more », j'ai bien la fenêtre de styles indépendante qui apparaît.

En préambule : j'utilise Latex à 80%, et les derniers 20% se partagent entre MS-Word et LO-Writer plus ou moins indifféremment. Et oui, je suis d'accord avec toi Zenitram sur certains avantages de Word sur Writer:

• Les styles et templates par défaut ont réellement fait beaucoup de progrès (mais selon moi, c'est uniquement depuis Word 2010, avant, franchement, c'était pas tellement mieux)
• La hiérarchisation des styles dans Word (2010 au minimum) est réellement mieux fichue : on a les styles les plus utilisés en haut de la liste, là où dans LOo/OOo, il faut plus ou moins afficher la liste complète pour retrouver ses petits¹.
• Au moins sur Ubuntu, la création automatique de listes et puces a été désactivée par défaut, et c'est franchement relou, surtout que je n'ai vu aucun raccourci qui me permettrait d'éviter d'utiliser la souris.
• À moins d'avoir raté quelque chose, oui, Word a un correcteur grammatical et pas Writer. Je conçois que ça soit gênant pour une certaine partie des utilisateurs (étant un grammar nazi, et même si je continue de faire des fautes, la plupart du temps je les capte à la relecture).

Maintenant, la capacité d'insérer facilement une table des matières dans Word (via clic droit) il y a ~10 ans a été enlevée à ma connaissance, et que ce soit sous Writer ou sous Word, je trouve que c'est assez relou (sous LOo: insert → indexes & tables → indexes & tables). Je me souviens avoir BEAUCOUP cherché sous Word 2010 avant d'avoir trouvé comment faire².

Ceci étant dit, au moins sous LOo, toutes les tables générées automatiquement sont dans le même menu (table des matières, liste des tables et liste des figures, etc.). Je suis certain que Word a quelque chose d'équivalent, mais je n'ai pas eu à chercher pour le moment (la plupart du temps pour ce genre de choses j'utilise Latex).

Il y a sans doute d'autres trucs que j'ai ratés, mais ce sont les plus importants pour mon utilisation: écriture de rapports, avec insertion de figures et de tableaux, et utilisation cohérente de styles. Je n'ai aucun besoin de publipostage, de fusion de documents, etc. Lorsqu'il faut que je bosse avec un modèle de document, celui-ci est généralement déjà fourni (modèle de rapport pour un projet spécifique, ou bien lettre à entête, ou …), donc je n'ai pas à m'en occuper.

Bref, je suis d'accord avec pas mal de points soulevés ici « contre » Writer. Cependant, tu nous dis :

Le hic est que la réalité montre qu'en fait tu ne gagne pas de temps après (au pire, c'est pareil), tu as juste souffert pour rien au début.

Foutaises. Si si. Ta « réalité » tient principalement au fait que MS Word/Office est largement distribué. Ça ne lui enlève pas ses qualités (qui sont indéniables, tout comme certains défauts de la suite au sens global), mais si on parle réellement d'une utilisation productive d'Office ou de LOo, alors selon mon avis (bien perso hein, tout comme la réalité que tu clames être sortie du champ de ton expérience personnelle), pour les besoins de la majorité de la population, elles sont équivalentes.

Ton opinion me fait penser à ceux qui affirment dur comme fer que manipuler la souris est facile, et qui oublient un peu trop facilement justement les dizaines voire centaines d'heures passées en tant que gamin/ado/adulte à manipuler la souris pour comprendre comment efficacement l'utiliser. Alors qu'au contraire, passer par le clavier est (ou en tout cas était pendant de nombreuses années) en réalité la première chose que beaucoup de gens essayaient, car comme ça ils pouvaient tenter de « parler » au PC (et bien entendu ils échouaient, puisque ce dernier parlait un Anglais en mode SMS: cd, dir, ls etc.).

Il y a clairement une différence d'ergonomie entre Word et Writer. Ça ne veut pas dire que l'un est meilleur que l'autre si on se base sur cette seule différence — le côté « avoir de jolis documents tout de suite » est selon moi un bien meilleur argument.

[1] Note: sur une version récente d'Ubuntu (13.10) en créant un nouveau document, j'ai bien une hiérarchisation des styles aussi (« Default », « text body », « quotation », puis « Title », « Subtitle », « Heading 1 », suivi de 2 et 3). Ce n'était pas le cas pour LOo dans Ubuntu 13.04.
[2] Pour être honnête, vu qu'on ne génère ces tables qu'une fois, tant que les trouver reste logique (sous LOo en tout cas j'ai trouvé que ça l'était parfaitement), c'est un moindre mal.

Concernant l'utilisation de la POO dans ce contexte:

1. Dans le cadre de ton test, effectivement, le procédural convient parfaitement, et faire plus juste parce que l'objet c'est bôôôôôô, c'est ridicule
2. En règle générale, dans les langages interprétés (Perl, Ruby, PHP, etc.), l'utilisation d'objets a réellement un impact négatif sur les performances

De plus, et ça ce n'est que mon opinion, critiquer la façon de coder (objet, procédural, fonctionnel, blah) à tout prix est ridicule, surtout si on n'est pas impliqué dans le développement en lui-même. L'important c'est que le boulot soit fait. C'est la première règle. Une règle optionnelle, c'est que le boulot soit bien fait, et donc qu'on puisse le reprendre facilement. La POO peut aider, mais ce n'est pas toujours le cas, car écrire correctement un programme orienté objet nécessite de ne pas perdre la boule et ajouter 2000 classes juste parce qu'on suit un dogme « POO partout » (et potentiellement, performance nulle part…).

Bref.

Déjà, sur ton smartphone, tu dois penser à tout désactiver. Le GPS. Le bluetooth. Le wifi. La 3G. Tu dois aussi faire gaffe aux applis sur ton mobile qui pourraient consommer du CPU dans ton dos.

Bon, le seul truc vaguement chiant à configurer, c'est désactiver la 4g sur mon téléphone (faut aller dans le menu de config). Le reste (GPS, bluetooth, wifi) est vraiment facilement accessible et désactivable (et en fait, par défaut je désactive tout par exemple).

Concernant les trucs « cachés » : sur mon spyphone (Samsung Galaxy II), mis à part lorsque j'active l'écran physiquement (en utilisant le bouton qui va bien), l'écran reste éteint. Et oui, il se rallume à la fin d'une conversation téléphonique, soit à peu près ~10 secondes grand max.

Lorsque je reviens en France, j'utilise le même téléphone mais sans tous les bidules data/3-4g, du coup, sauf lorsque j'active le wifi, aucun des softs qui réagissent à des événements de type « push » ne me bouffent la batterie (que ce soit des trucs genre gmail, facebook, ou autres). Et j'ai bien grande autonomie dans ce cas.

On se prend un Nokia d'il y a 4/5 ans, de base (type flotte), et je te le fais tenir 2 semaines SANS RIEN TOUCHER.

Bah moi il faut que je touche le smartphone, que je le transforme en « dumbphone », et ça marchera aussi. Et ce n'est pas tricher : tu es en train de dire « si j'utilise un téléphone qui a 1/10 des fonctionnalités d'un smartphone [en étant généreux], je tiens facile 2 semaines ». Moi je dis que pour tenir autant de temps, il faut effectivement que fasse quelques manips pour réduire les fonctionnalités en question. Mais lorsque la durée de vie de la batterie ne sera pas un enjeu majeur, je pourrai réactiver le tout. Essaie de faire ça avec un mobile d'il y a 4/5 ans.

Pour le coup, je croyais que de nombreuses études montraient que (par exemple) dues aux conditions de vie épouvantables des mineurs jusqu'au début du XXè siècle, les personnes pratiquant ce genre de métier avaient tendance à être moins grandes. c'était en partie à cause du fait qu'on utilisait des enfants pour servir d'éclaireurs, ou pour aller dans les galeries difficiles d'accès.

Donc il me semblait établi que les gens dont les métiers imposaient de fortes contraintes sur le corps, et qui pratiquaient ce métier depuis tout jeune avaient des problèmes de croissance. Un peu comme lorsqu'on dit aux ados d'y aller mollo sur la muscu.

J'ai peut-être rêvé tout ça, cela dit. :-)

Quels sont les ports de Python qui sont des implémentations qui continuent d'évoluer ? C'est une vraie question. J'ai en tête les distributions suivantes:

• Python / POSIX
• IronPython (.Net)
• Active Python
• Pypy?

J'ai entendu parler d'autres implémentations, mais qui semblent évoluer peu ou pas du tout :

• CPython
• Jython
• Cython
• D'autres que j'ai ratés, sans doute.

Je me plante complètement ?

De l'autre côté, niveau front-ends pour C++, je dénombre (sans trop me prendre la tête):

• GNU C++
• MS Visual C++
• Intel C++
• Sun/Oracle Studio
• Digital Mars C++
• IBM C++
• Clang++
• HP C++

(Note qu'à part g++, clang++, et peut-être icc, je ne crois pas que la plupart de ces compilos gèrent correctement C++11)

La différence c'est que C++ c'est une norme, et pas seulement un standard. Donc il faut que tous les membres du comité de normalisation soient d'accord, et donc on se retrouve avec des gens de Microsoft par exemple qui ont certains usages courants et des extensions qu'ils voudraient voir normalisés; idem pour les autres participants. Python, Perl, Ruby, Java, etc., même s'ils demandent leur avis aux utilisateurs, restent principalement une implémentation « unique ». Oui je sais, il existe plusieurs implém de Ruby, Python, Java, etc. La différence (selon moi), c'est que globalement il y a une version qui continue d'évoluer en permanence, là où en C ou C++, on se retrouve avec 12000 compilateurs (Sun CC, Intel CC, Gnu CC, Clang+LLVM, etc.). Bien qu'il existe des trucs du genre « Iron{Python,Ruby} » ou même des implémentations alternatives de Java, c'est ultra minoritaire en pratique.

On n'a clairement pas bossé dans les mêmes boites. :-) En stage de fin d'étude vers 2005, ma machine de développement c'était un Céléron ou un Duron à 600MHz, et 512Mio de RAM. En milieu de stage, on nous a royalement doublé la RAM (1Gio, WOUHOU!). Mon environnement de travail c'était à l'époque : Eclipse, Hibernate, JBoss, SVN. Le tout sous Windows 2000. Alors certes je bossais pour une startup, etc., et certes je parle d'il y a 8 ans et des cacahuètes et pas 7 ans, mais c'est pour dire que 4Gio il y a 7 ans, c'était clairement pas une config. standard dans beaucoup de boites.

Tout comme Linux et sa cryptographie à base de GPG ultra-dangereuse. Si ça sonne exagéré, c'est parce que ça l'est. Cependant, ce genre de discours était plus ou moins suivi par un certain nombre de personnes qui n'aimaient pas l'idée que la crypto soit utilisée ailleurs que chez les militaires ou les banques.

Je n'ai aucun avis sur bitcoin en lui-même (j'ai pas investi, et je ne suis que vaguement entre autres grâce à LinuxFR), mais dire qu'une technologie ou un concept peut servir à faire le mal n'invalide pas le bien (potentiel) qui peut aussi en résulter. Par exemple : une tronçonneuse peut couper des arbres, mais aussi des ch'tits n'enfants; libpcap peut servir à diagnostiquer des problèmes réseau mais aussi à écouter sur un hub et récupérer des couples {login, mots de passe}¹; bitcoin peut servir à transférer de l'argent sans frais d'un bout à l'autre de la planète, mais aussi à blanchir de l'argent issu du crime organiser; etc.

[1] Oui je sais mon exemple est daté.

Par contre existe-t-il des « frais de change » pour convertir des €/$/£/blah en bitcoins?

J'ai renoncé à utiliser gViM sous Windows à cause d'une gestion extrêmement bizarre de la sélection à la souris (et du copier-coller), et du fait qu'involontairement je pouvais effacer du texte sélectionné là où sous Linux/UNIX ça ne m'arrivait jamais. Du coup lorsque je dois bosser sous Windows, j'utilise Notepad++.

66K BR ~ 28KS. Je ne connais pas le salaire moyen d'un (bon) développeur au Brésil, et c'est l'information qui manque pour savoir si c'est complètement disproportionné ou pas.

Je ne connais absolument pas les GPU Intel, et je suppose que ce que tu me dis s'y applique aussi. Pour le MIC, il s'agit de « bêtes » x86 avec AVX + 4 hyperthreads, le tout avec un système de caches cohérents (c'est l'ancien Larrabee). Donc ma question sur le MIC était sans doute hors sujet vu que c'est surtout censé servir d'accélérateur pour le calcul (mais après tout, si l'accélérateur se retrouve sur le même die, ça peut p'tet servir à faire du « rendu via CPU » ;-) ), et il aurait fallu plutôt la poser à proposer des GPU intégrés sur Ivy Bridge/Sandy Bridge…

(Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait).

C'est vrai aussi sur les archis de type Fusion d'AMD? Ou bien sur les prochains processeurs d'Intel qui auront le MIC/Xeon Phi et les multicœurs sur le même die ?

Malgré tout, Intel a libéré TBB (Threading Building Blocks), et récemment ils ont aussi libéré leur bibliothèque pour OpenMP. Et au moins pour ce qui est du boulot que je fais avec eux en termes de recherche, notre boulot sera libéré sous GPL.

Je trouve qu'ils ne sont pas si mal. Après, il est évident qu'il est dans leur intérêt de garder le matos relativement fermé, étant donné la position qu'ils occupent sur le marché des processeurs.

La seule chose qui m'énerve pas mal chez Intel, c'est la concurrence déloyale faite aux autres fabricants de x86 quand il s'agit de compiler avec icc ou d'utiliser la MKL (ils sous-optimisent volontairement lorsque le code ne tourne pas sur un processeur Intel).

C'est oublier la partie « pré-med ». Bref, il ne faut pas oublier le bachelor à avoir avant d'entrer en fac de médecine, à savoir ~4 ans.

Concernant la MKL: entre 10 et 20% est écrite en ASM. Le reste est du C « de base » (car le compilateur peut correctement générer du code de bonne qualité), compilé en plusieurs versions (avec/sans OpenMP, ILP32 ou ILP64, etc.).

Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique

Pas d'accord. Enfin pas tout à fait. J'ai besoin d'avoir accès à un physicien/mathématicien lorsqu'il s'agit d'optimiser un code et de vérifier que je ne mets pas en danger la stabilité numérique ou la convergence d'un algo (dans le cas d'une méthode itérative). Mais s'il est toujours utile de connaître un minimum le domaine d'application d'un programme (e.g. éléments finis, etc.), dans 90% des cas, ce que je dois savoir en tant qu'infoteux bas-niveau, c'est comment sont représentés les flottants « normalisés » (IEEE 754) en 32, 64, et 80 bits et « dénormalisés » (spécifiques à l'archi, et souvent lents). Le reste, c'est purement un problème de compilation/optimisation largement à ma portée.

Tu as raison de dire que le temps est limité pour un ingé/scientifique, et qu'il faut donc faire des choix. Mais le problème est que les physiciens/matheux/bla ont eu à « devenir » programmeurs d'un côté pour pouvoir coder leurs modèles (ce qui est très bien), mais aussi à se préoccuper de la machine en dessous (ce qu'ils ne devraient JAMAIS avoir à faire dans l'idéal).

Il existe tout un tas d'efforts en ce moment pour correctement procéder à la séparation de rôles (« separation of concerns », je ne sais pas bien comment le traduire) : d'un côté le physicien/mathématicien qui code son modèle (le langage importe peu), et de l'autre le « tuning expert » qui connaît la machine cible et sait comment correctement causer au compilateur et à la machine en règle générale. Par exemple, il existe les Concurrent Collections (CnC), création dans un labo d'Intel à la base pour le langage C++, mais dont la spécification a donné lieu à des implémentations en Python, Java, etc. Le principe est simple : on écrit son code par « étapes » (steps). Chaque étape doit être une fonction_pure (i.e. le résultat doit être le même à chaque fois que la fonction doit traiter des données identiques, et qui n'a pas d'effet de bord). Le programmeur d'application doit ensuite écrire comment les différentes étapes sont coordonnées, en exprimant explicitement les relations de dépendance de contrôle et de données entre étapes.

J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.

Là-dessus je te rejoins parfaitement. Le meilleur langage pour programmer quelque chose, c'est celui où tu te sens à l'aise. N'ayant eu que des codes F77 ou F90 "non objet" me passer sous les yeux, je t'avoue que j'ai versé quelques larmes de sang, mais c'était loin d'être aussi terrible que ce qu'on m'avait décrit (bon, les boucles avec étiquettes numériques en F77, ou les blocs COMMON, je m'en serais bien passé).

Histoire de répondre en vrac :

SUPERZAP, SystemTap, etc. sont tous des outils très intéressants. Ayant indirectement bossé sur MAQAO et directement avec (quand la plupart de ses modules étaient éclatés en divers endroits), j'ai eu l'occasion parler avec la plupart des gens qui y ont bossé entre ~2005 et ~2010. Pour prendre l'exemple du module MADRAS (qui s'occuper de « décompiler » les binaires, rajouter des trampolines où il faut, puis recompiler le tout), son auteur avait cherché un peu partout s'il n'existait pas déjà des bibliothèques ou exécutables qui feraient l'affaire. La réponse a été non : soit on avait des trucs de type objdump/gdb/etc. fait pour le debug, soit on avait des trucs type IDA Pro pour le reverse engineering, mais ce que cherchait l'auteur de MADRAS, c'était un moyen de facilement patcher des bouts de binaires sans avoir à se taper l'intégralité de l'assembleur, pour mieux instrumenter les parties chaudes qui devront être plus tard optimisées. Bref, tout plein d'outils faisaient « presque » l'affaire, mais pas vraiment ce qu'il voulait. De plus, l'idée était déjà à l'époque d'unifier dans un même framework tous les outils utilisés pour analyser/mesurer la performance de codes de calcul intensif.

Le « front-end » de MAQAO (Sylvain ne te gène pas pour me contredire si ça a changé et que je dis des bêtises) est censé bouffer de l'assembleur (ou du binaire décompilé) de la partie chaude de l'exécutable, puis à l'aide d'un modèle machine codé en interne (obtenu à grands coups de micro-benchmarking pour savoir quel est l'effet réel d'instructions SIMD/SSE, en fonction du flux, de l'occupation des ports de décodage du front-end pour processeurs Intel¹, etc. Cette information est statique (MAQAO recrée le graphe de dépendances de données ainsi que le graphe de flot de contrôle à partir de l'asm). Du coup, on obtient des informations « optimistes » de la meilleure performance possible. Par exemple, même si le code n'est pas vectorisé, si MAQAO déduit que statiquement il y a bien trop de chargements mémoire comparé aux instructions arithmétiques, il le rapportera dans son diagnostic.

Ensuite, si la performance mesurée s'écarte grandement de ce qu'on promet « au mieux », on peut utiliser différentes techniques, comme l'analyse décrémentale (DECAN), qui consiste à patcher le binaire de la boucle chaude, et retirer petit à petit des instructions (en suivant un pattern précis, ou bien « aléatoirement », etc.). L'idée est de repérer quel est le « deliquent load/store » (la lecture ou écriture mémoire qui rend le code lent). On retire une ou plusieurs instructions, on réinstrumente la portion de code, et on itère.

Il y a tout plein d'autres trucs que MAQAO sait faire, mais il faut garder à l'esprit que les codes visés sont généralement assez réguliers en terme de flot de contrôle. Si le code passe sont temps dans des constructions de type if-else, MAQAO ne pourra sans doute rien pour aider le programmeur.

[1] Je ne sais pas comment c'est obtenu maintenant, mais à l'époque, c'était l'affaire de quelques minutes/heures, à faire tourner tout plein de micro-benchmarks avec à peu près toutes les instructions « utiles » en calcul haute performance imaginables, et vérifier que les latences et le débit étaient ceux promis par Intel. On se servait pas mal des manuels de Agner pour vérifier que nous avions les mêmes nombres — et je dirais que 90-95% du temps, c'était le cas.

Et si la personne a perdu tout ses logins/pass, on joue avec les adresse postales physiques (courrier avec l'adresse enregistrée sur le compte, donc pas de fausse adresse).

Pour GoDaddy je pourrais presque comprendre (presque), mais dans le cas de PayPal, ils sont assimilés à un organisme bancaire. Je ne conçois même pas qu'au téléphone on réponde à ce genre de choses (numéro de carte, etc.). Si une banque « normale » donnait des infos perso au téléphone, elle aurait de gros problèmes s'il y avait une plainte. J'ai bossé en tant que guichetier pour une banque en France il y a plus de 10 ans, et il était interdit de répondre à toute demande d'info, même si on reconnaissait la voix du client au téléphone.

On ne demande pas de renseignement confidentiel à une banque ou un organisme de crédit au téléphone, même si c'est un service en ligne à la base, point.

Surtout qu'aux États-Unis (par exemple) ils ont tendance à pas mal pratiquer l'enregistrement des appels des clients « for quality reasons » (c'est censé être fait aléatoirement). Du coup il y a souvent des preuves que les employés ont merdé.

Les fondations sont libres, mais pas l'interface graphique. Un peu comme il existe/existait des implémentations de X non libres. Ça ne fait pas de Darwin un OS non libre.