Matthieu Moy a écrit 3248 commentaires

Non, les processeurs font plein d'opérations en parallèle et ré-ordonne les instructions pour pouvoir les exécuter plus vite.

Bien sûr, mais le processeur ne peut pas exécuter une opération (par exemple "ADD x, y") quand il n'a pas les données correspondantes (x et y). On peut essayer de spéculer, mais sur un truc aussi bête qu'une addition, on ne va pas spéculer les additions possibles s'il manque un opérande … Techniquement, le ré-ordonnancement peut éviter les bulles dans le pipeline.

Bien sûr, tout dépend de l'architecture cible. Tous les processeurs ne réordonnent pas les instructions. Les processeurs Intel le font très bien sur mon exemple donc le compilateur x86 n'a pas besoin de se soucier de ce cas, mais tous les processeurs ne sont pas out-of-order comme ça il y a des tas d'architectures où c'est au compilateur de faire ce boulot.

En fait c'est le contraire: On utilise les opération atomique pour dire au compilateur d'introduire des barrières dans le code pour que le processeur ne ré-ordonne pas ces opérations.

Euh, pas compris le contraire de quoi. On dit la même chose là ;-).

Dans quel cas un tel réordonnancement se justifie-t-il ?

Le ré-ordonnancement est une optimisation importante du compilateur. Un truc important est de générer du code qui minimise les dépendances immédiates entre deux instructions. Par exemple (si R0 et R1 sont des registres) :

charger 12 dans R0
charger 42 dans R1
utiliser R0
utiliser R1

Ici l'instruction « charger 42 dans R1 » peut s'exécuter alors que « charger 12 dans R0 » n'est pas terminée (exécution pipelinée). Par contre, si on avait écrit :

charger 12 dans R0
utiliser R0
charger 42 dans R1
utiliser R1

alors le processeur serait obligé d'attendre la fin des instructions « charger » avant les instructions « utiliser » correspondantes. Les performances seraient moins bonnes pour le même comportement.

Personnellement j’apprécie justement les multiples façons de pouvoir utiliser les curseurs qui permettent aussi bien un usage précis que grossier.

Idem ici. Pour préciser, les possibilités avec dt sont :

• Clic à la souris à un endroit
• Molette
• Shift+molette ou Control+molette pour aller plus ou moins vite
• Clic droit + déplacement de souris pour jouer plus ou moins finement sur le curseur
• Clic droit + valeur entrée au clavier
• Double-clic pour revenir à une valeur par défaut

(J'en oublie peut-être)

Ça me paraît dur de faire mieux en fait ;-).

Il suffit de faire un programme qui passe de la base n à la base k, puis poser n=10 et k=4, ou l'inverse.

Si tu veux vraiment tester (reproduire et/ou vérifier qu'il a disparu) un bug spécifique Windows, tester sous wine a peu de chances d'être suffisant.

amener beaucoup d'utilisateurs et contribuer à l'amélioration de l'interface

Attention, la relation de cause à effet entre la qualité de l'interface et le nombre d'utilisateurs n'est pas si simple que ça. En simplifiant un peu, je dirais qu'il y a 3 catégories de gens liés à un logiciel libre : les développeurs, les utilisateurs passifs, et ce que j'appelle parfois les « utilisateurs coopérants », qui font des rapports de bugs bien faits, participent de manière constructive aux discussions, et pourquoi pas envoient un patch de temps en temps … La version Windows va vraisemblablement augmenter significativement le nombre de personnes de la deuxième catégorie, mais j'ai de gros doutes sur la troisième. Je ne suis pas trop la communauté GIMP, mais les retours que j'ai vu ont l'air de dire que la masse d'utilisateurs sous Windows est plus douée pour râler quand ça ne marche pas que pour être vraiment constructif.

Pour l'instant, j'ai vu beaucoup de monde arriver sur les forums en cherchant plus ou moins à faire pareil avec dt qu'avec LR (ce qui pour moi qui n'ai jamais utilisé LR n'est pas vraiment intéressant).

il manque un module permettant la sélection d'une zone et l'application de plusieurs corrections (exposition, teinte, contraste, détail, récupération des hautes lumières, récupération des ombres, etc.) en une seule fois.

Oui, tu dis à peu près la même chose à chaque fois qu'on parle de darktable. Perso, je n'ai jamais eu besoin de ça. Quand je veux faire une retouche, je sais quel module je vais utiliser et je commence par là, et je décide après comment je limite l'effet. C'est assez rare que j'utilise exactement le même masque pour plusieurs effets : même si je cible la même zone, pour certains modules je vais avoir une limite un peu tranchée, pour d'autres un affaiblissement plus progressif, … Je ne prétend pas que ma manière de bosser est forcément la bonne, mais inversement quand tu écris « Non, ce n'est pas du tout pratique. Il est bien plus logique et efficace de … », tu généralise trop vite ton cas : c'est plus pratique pour toi, OK (et du coup il y a peu de chance que tu sois heureux sous dt), mais un message qui démarre par une affirmation comme celle-là (avec laquelle tu sais pourtant que les développeurs sont en désaccord) a peu de chance d'être lu de manière constructive.

tout le monde en technique photo sait ce que fait un module de "correction du voile" (atmosphérique), je pense donc que le terme "correction de la brume" est mal choisi…

Ça a été discuté sur darktable.fr avec Pascal, qui contribue à la traduction française. C'est une traduction littérale de « haze removal », et je la trouve plutôt adaptée. OK, ce n'est pas le même nom que sous LR, mais le module de dt est vraiment bon pour supprimer la brume justement, et pas si bon pour enlever la teinte bleutée du voile atmosphérique.

Tss tss, et le deuxième « t » à mon prénom ? ;-).

Toujours un plaisir cette désormais tradition de découvrir et d'explorer les nouveautés de dt en écrivant une dépêche sur linuxfr :-).

Surtout last $user …

Le problème c'est que l'adresse mail apparaît sous la forme :

Où apparaît-elle comme ça ? Dans le mail que tu reçois ? Si oui, il s'est passé beaucoup de choses entre ton script et ce que tu observes … A priori, la syntaxe "\"$adresse\"" est bien celle que tu cherches, le guillemet a du disparaître ailleurs.

Mais pourquoi cherches-tu à faire ça ? Il n'y a pas de guillemets autour des adresses email. Au contraire, les guillemets sont là pour déliminer le nom dans "Prénom Nom" <prenom.nom@example.com>.

la fonction Do n’est pas définie, elle est seulement déclarée.

Attention, ce n'est pas une fonction déclarée mais indéfinie, c'est un pointeur de fonction initialisé à null (implicitement, car statique). Si la fonction était déclarée et non-définie, on aurait une erreur au link.

Ou alors, tu peux cliquer sur les liens et essayer de comprendre ce que sont Patreon et Tipeee …

Ceci dit, une paire de guillemets doubles autour de "$ARCHIVES" ne fait pas de mal ;-).

En principe le PHP est servi avec un utilisateur non-privilégié (genre www-data), donc une faille dans le code PHP ne permet de supprimer que les fichiers de cet utilisateur. @harlock974: tu peux vérifier si c'est bien le cas sur ton installation (et si cet utilisateur est bien différent de celui qui a perdu ses fichiers).

Après, il peut y avoir autre chose qui permet à l'attaquant de passer de l'utilisateur sous lequel tourne apache à celui dont les fichiers sont perdus, mais c'est peu probable que ça se soit fait sans passer root entre temps (donc c'est presque suspect qu'il n'y ait pas plus de dégâts).

Regarde si l'utilisateur en question n'a pas une crontab qui a pu exécuter un script buggé pendant le WE (crontab -l).

Un classique est d'écrire quelque chose comme

rm -fr $VAR1/$VAR2

avec $VAR1 et $VAR2 indéfinies.

Le $ est un caractère spécial pour sed -> échappe-le (\$).

Là c'est indépendant de docker : le script cherche à télécharger un truc, et l'URL en question n'est plus valide, il faut télécharger de la nouvelle URL (https://github.com/jemalloc/jemalloc/issues/1026).

Sous Debian :

• docker est le paquet pour le dock KDE. Rien à voir.

• docker.io est le paquet fourni par Debian

• docker-ce est le paquet fourni par Docker. Il faut ajouter un dépôt APT externe et ça permet d'avoir une version plus récente.

Ce que tu cherches est "docker build".

Sauver l'état du conteur : docker commit.

Mais si tu as mis toutes les étapes dans un Dockerfile, c'est juste "docker build" qui s'occupe de tout.

Tu as toutes les explications (et pas trop de blabla inutile pour toi) là : https://docs.docker.com/get-started/part2/#pull-and-run-the-image-from-the-remote-repository

Effectivement, les noms de packages n'existent pas sous Ubuntu. Par exemple, pour la lib gomp, le nom du package est libgomp1.

Le package lib64gomp1 existe sous Debian par contre : https://packages.debian.org/search?keywords=lib64gomp1, mais les instructions d'install échouent sur Jessie et Stretch avec des packages manquants différents à chaque fois :-(.

Est-ce possible d'installer une base de ubuntu 16.04 puis toutes les dépendances et ainsi compiler le prgramme dans l'environnement ubuntu-docker, pour finalement en faire une image docker que l'on pourrait distribuer et ainsi figer le soft ?

Sur le principe, oui c'est bien le genre de choses qu'on fait avec Docker. En gros tu vas faire un Dockerfile qui ressemble à :

    FROM ubuntu:xenial
    MAINTAINER Toi <ton.mail@example.com>
    RUN apt-get update -q && apt-get install -qy \
        les \
        dependances \
        de ton \
        outil
    RUN script-d-install.sh

et lancer docker build dessus.

Après, la difficulté est de faire communiquer ton conteneur avec le reste du monde. Y'a plusieurs options :

• Le classique chez les utilisateurs de Docker: ton appli est une appli web, tu lui parles par le réseau.

• Les volumes Docker, i.e. un répertoire partagé entre la machine hote et le conteneur. Ça peut s'activer par exemple avec docker run -v /repertoire/local:/point/de/montage/dans/le/conteneur. Un bel exemple est là : https://github.com/blang/latex-docker, c'est une image qui contient une install latex et qui permet de compiler du code sur le host en utilisant un pdflatex dans le conteneur.

Un gros défaut de Docker pour distribuer un outil comme ça : la personne qui lance l'outil doit grosso-modo être root pour pouvoir l'exécuter. L'application s'exécute dans un conteneur, mais le lancement demande au moins d'être dans le groupe docker (et quelqu'un qui est dans le groupe docker peut facilement passer root).

Bah non justement : SCHED_DEADLINE est dispo depuis Linux 3.14. Et ce n'est pas vraiment un nouveau scheduler, mais une nouvelle classe, qui vient compléter (et non remplacer) SCHED_RR et SCHED_FIFO dans les ordonnancements temps réel, et le SCHED_OTHER pour les processus non temps réel.

J'ai peut être loupé quelque chose, mais je n'ai rien trouvé qui dise que ça deviendrait la classe par défaut un jour, et en fait je ne vois pas quel sens ça aurait (SCHED_DEADLINE n'est pertinent que dans les contextes où on connaît les deadlines…).

Je n'ai pas de solution parfaite (sur le principe, ddd est effectivement très bien, mais il vieillit très mal …).

Une possibilité : gdbtui (text user interface), ou gdb -tui, ou encore Control-x o depuis un gdb textuel. Ça reste assez spartiate mais c'est plus utilisable que gdb de base, et l'intérêt est que c'est installé plus ou moins partout (en particulier sur la machine exotique de l'étudiant, sur laquelle ton futur outil préféré ne s'installera pas, loi de Murphy oblige).

La syntaxe {...,...} est un bashisme non-POSIX. Visiblement, chez toi make n'utilise pas bash (du point de vue du Makefile, une action n'est qu'une chaîne de caractère, c'est un shell qui s'occupe de la découper proprement selon les espaces, et d'expanser les noms de fichiers comme *.ext et ton {...,...}).

Quelque chose comme

SHELL=/bin/bash

en début de Makefile devrait régler ça.

Dans le même genre, il y a libgmp :

https://gmplib.org/