Enj0lras a écrit 250 commentaires

ça existe, et ça s'appelle ocaml-tls

Ça bouge chez vim aussi sous forme de fork avec neovim même si pour l'instant c'est du travail de fond peu visible pour l'utilisateur

Faut quand même ajouter que rust a aussi un point supplémentaire : c'est très compliqué, et la syntax est verbeuse. Je me retrouve de plus en plus à revenir à ocaml parce que ça me saoule de faire du rust.

C'est une question de tradeoff. Il me semble que les avantages de ld se retrouvent surtout sur les gros programmes en C++. Le principal but de binutils dans base est de compiler base, si tu veux utiliser gold tu peux l'installer avec les paquets. Donc, si gold te donne un gain de 2s au total sur la compilation de l'OS mais que compiler gold prend 10s, tu gagnes pas de temps : tu en perds.

Malheureusement, c'était aussi le point de vue de nombreux développeurs, mais la décision a étée prise de changer pour supporter NSS/LDAP.

D'un autre côté, il y a un initrd de rescue que tu peux démarer (ou auquel tu peux accéder dans /usr/share/initrd) avec tout les outils de /bin et certains de /usr/bin qui sont liés statiquements.

C'est bizarre, car la vue sur la tribune de rédaction était correcte.

J'ai du mal à comprendre le modèle de programmation de POE, vu que je connais pas perl, mais la force de Lwt c'est que ce n'est pas vraiment des callback. Ça en est sous le capot évidemment, mais l'idée c'est de programmer de la même manière que si c'était un thread avec une execution linéaire. C'est l'idées des futures/promises qu'on retrouve dans le nouveau standard javascript.

En tout cas, je remarque qu'il y a désormais ocaml. ça c'est cool ! j'ai envie de m'inscrire pour le coup. Enfin, quand j'aurai plus de temps.

L'indentation est là pour ça. Tu peux aussi mettre des { } autour de la section si tu préfères.

Je vois. En rust, on utilise en proxy. La méthode write() retourne une structure qui contient un pointeur vers le mutex. Le destructeur de cette structure deverouille le mutex. Ensuite, la magie du trait Deref/DerefMut entre en jeux. Cela revient à surcharger l'implémentation de * ou de ->. Ainsi, le compilateur va considérer cette structure comme une référence vers la valeur protégée par le mutex.

De plus, grace au lifetime, il est impossible de conserver une reference vers la valeur protégée après avoir dévérouillé le verrou, c'est garranti à la compilation. C'est assez malin. Je pense que tu peux faire ça en C++, sauf peut être la dernière garrantie car rien n'interdit en C++ de cloner des references.

Je suis plutôt d'accord avec ce point de vue, mais le problème c'est que parfois tu ne peux pas repenser l'architecture du code pour ne pas avoir d'état partagé à cause de contraintes externes.

C'est peut être un exemple de niche, mais c'est le premier qui me vient à l'esprit : l'api POSIX. Si tu veux implémenter un noyau respectant l'API POSIX, tu es quasiment obligé d'avoir des états partagés à beaucoup d'endroits (même si tu peux t'en passer la plus possible), parce que l'api a justement étée concue dans cette optique : le système de fichier est un espace global partagé.

Evidemment, tu peux inventer de nouveaux types de noyau, par exemple basés sur les capabilities, auquel tu peux appliqué le model acteur et organisé la cooperation des différents composants du système à l'aide de messages et d'états locaux en utilisant les capabilities comme noms vers un état conservé chez le processus distant, voire créer quelque chose de complétement stateless globalement ayant juste des états locaux par sous-système et par cpu par sous-système en utilisant des techniques de hashing pour répartir la charge.

Mais cela requiert souvent de modifier l'API que tu exportes. Encore une fois, les noyaux ne sont qu'un exemple, c'est aussi le cas pour des bibliothèques ancienne que tu voudrais mettre à jour pour en améliorer les performances sur les cpu modernes.

Il y a un autre point important à prendre en compte à mon avis : même si je suis convaincu que ne pas partager d'état global est gagnant sur le long terme parce que cela simplifie beaucoup la manière de raisonner sur des bases de code assez larges, cela peu sembler beaucoup plus contraignant à court terme. En effet, je trouve qu'il y a un effort de reflexion supplémentaire pour créer une architecture basée sur des modules entièrement découplés, comparé à l'ajout de verrous un peu partout.

En pratique, les paradigmes de programmation principaux, que ça soit la programmation orientée objet ou la programmation fonctionnelle sont entièrement basés sur ce principe là et devrait conduire à des design qui se parallélise sans trop d'effort, mais force est de constater que ça reste de la responsabilité du programmeur d'archicturer le code proprement. No silver bullet, le langage ne te force jamais à faire les choses comme il faut, il fournit juste des abstractions pour le permettre.

C'est pas parfait mais ça aide déjà pas mal.

Je suis d'accord sur ce point, j'utilise aussi ce genre de construction en Ocaml par exemple, ou il est d'usage de faire cela avec des clotures, même sans construction dans le langage lui même:

   Lock.with_lock l (fun _ -> now_do; something )

permettent de visualiser qu'une instruction a un coût

Je ne comprends pas où tu veux en venir avec cette affirmation. Je ne connais pas vraiment de construction qui cache le verrouillage. Si tu opposes ça au RAII décrit plus haut, en rust tu écrirais :

 let locked_int = RWLock::new(42);
 let mut int_ref = locked_int.write();
 if int_ref < 12 {
    *int_ref = 12;
  }
 // Ici le verrou est relaché de manière implicite par le destructeur de `int_ref`

Je pense qu'en C++ la construction est similaire, le verrouillage (ce qui est vraiment couteux) est explicite, seul le déverouillage est implicite. Ce qui est un peu le cas avec "with" aussi, le deverouillage arrive à la fin du scope lexical du block with.

Absolument, la construction with est courante dans beaucoup de langages. Mais il y a quand même une différence notable, elle est optionnelle est requiert du code spécifique, ce n'est pas la méthode unique et par défaut qui empêche toute mauvaise utilisation.

Je suis d'accord avec le premier commentaire, la concurrence n'est pas réduite à la concurrence sur la mémoire. La définition du CNRTL que tu reproduis ici n'est d'ailleurs pas spécifique.

La concurrence, c'est le fait de partager des ressources, pas uniquement de la mémoire. Ça peut être du CPU (c'est d'ailleurs à mon avis ce que partagent le plus souvent les threads coopératifs), mais aussi une connection réseau (le pipelining HTTP est typiquement ce que j'ai envie d'appeler concurence).

Rust utilise aussi du RAII pour gérer les verrous. Je suis d'accord avec toi quec'est une variation d'un même concept théorique, mais dans la pratique, ça fait une différence énorme. En rust, il est par exemple impossible de lire ou de modifier la valeur protégèe sans verrouiller auparavant le verrou, et il est en outre impossible d'oublier de le déverouiller (sauf à créer une boucle infinie qui garde une référence sur la valeur protégée, mais dans ce cas, le problème est ailleurs).

Même si c'est théoriquement une variation, quand il s'agit de coder dans la vraie vie, ça fait une différence énorme.

J'ai des besoins extrêmement limité, je n'utilise un MTA que pour créer des addresses bidons pour les sites web qui demandent un compte, mon vrai mail est hebergé par gandi. Donc, je n'y connais pas grand chose et j'ai juste besoin de quelque chose qui travaille hors de la boite.

Au début, j'utilisais sendmail, fournit par défaut par l'OS, mais c'était trop compliqué. Ensuite, on m'a conseillé postfix, ça marchait plutôt pas mal, mais j'avais l'impression d'avoir quelque chose d'un peu overkill pour mes besoins.

Puis il y a 2ans, je suis passé à opensmtpd, attiré par la configuration "à la pf" et le support de privsep. J'ai une conf de 5 lignes, ça s'intègre automatiquement et par défaut avec les mails du système, et ça marche bien. Du coup j'en suis très content et je le conseille à tout les gens qui veulent mettre en place un petit serveur mail. (Non que je le déconseille à celles et ceux qui voudraient mettre en place un gros serveur mail, mais je n'ai pas de conseils à donner à ce sujet)

Oui, mais pas forcément sous n’importe quelle forme. Sous la forme du logiciel original et sans modifications (ajout d’autres programmes notamment) il n’y aurait pas de problèmes.

Si j'ai bien compris, c'est l'installateur qui est modifié, pas le logiciel lui même. Est il sous GPLv3 lui aussi ?

Et sinon, est ce que le copyleft s'applique aussi à l'installateur ? Je dirais à premiere vue que non, sinon on ne pourrait pas utiliser du code de windows dans l'installateur d'un logiciel GPLv3 ?

Je pense qu'on peu tous s'accorder que ça n'est clairement pas une pratique très morale, mais toutefois, est ce vraiment illegal ?

Le nom gimp est il déposé par exemple ? Que prévois la license du logiciel, la license du logo ? Par exemple, la license BSD mentionne explicitement qu'il est interdit de reprendre le nom des développeurs, mais j'ai tendance à dire qu'une license moins restrictive ne violerait pas la paternité si sf propose quelque chose comme "download the sourforge Installer for The gimp", sur un compte "the gimp".

Après, la GPL prévoit probablement de redistribuer les sources de l'installateur modifié. Mais pour le reste, je ne sais pas répondre à ces questions.

Evidemment… J'ai parlé trop vite et juste après avoir posté je me rends compte d'un bug. Un thread crée une chaine, la modifie, envoit la copie à un autre thread, qui modifie la copie alors que l'ancienne version n'a pas étée flushée : boum.

En fait c'est intéressant parce que j'ai l'impression que c'est encore un truc qui s'implémente simplement en rust et pas en C++. Si on peut garrantir qu'il n'y a pas de mémoire partagée et que la copie est faite que depuis le même thread que celui qui possède la copie initiale, alors il suffit d'insérer une memory fence lors de la copie quand le refcount est 1.

Je voudrais préciser un peu l'implémentation du COW et son coût, il me semble que l'utilisation de memory barrier peut être évitée, mais comme il est tard je me trompe peut être :

• share path : atomic_add sur le refcount, memory order relaxed.
• destruct path: : actomic_fetch_add, si la valeur fetch est 1, alors libérer la mémoire.
• modify path : atomic_load avec order relaxed. Si le refcount est 1, modifier les données. Sinon, copier les données dans une nouvelle chaine, changer le pointer, puis release path.

Dans les 3 cas, il n'y a pas besoin d'utiliser des memory barrier, l'ordre relaxed est utilisable, parce que la chaine elle même est toujours immutable et sera réallouée puis copiée en cas de modification, sauf si le thread courant est l'unique propriétaire des données.

Evidemment, le côut de l'order Relaxed diffère selon l'archi.

Le problème n'est pas de savoir lire un script mais de se rappeler une syntaxe valide pour ln quand tu veux la taper dans ton shell. Pour ça, ça fait son job.

Ça n'a rien à voir, mais comme je fais quasiment toujours des liens symboliques, un jour j'ai remarqué que -s c'est un peu source, donc ln -s source destination.

Ouai par exemple on peut faire un petit script javascript qui vérifie que javascript est activé et s'il ne l'est pas redirige vers une page noscript.

Bein oui tout les OS ne sont pas linux avec 600 développeurs réguliers.

Et le mieux dans tout ça c'est qu'ils arrivent quand même à être un des environnements les mieux supporté sur les *BSD.