thoasm a écrit 9446 commentaires

Je vois pas le rapport, tu peux être intransigeant si tu veux sur les principes, là on parle de communication et de transmissions des idées, et de manière correcte de le faire.

Tu peux transmettre les principes du logiciel libre sans insulter les autres parce qu'ils ne sont pas complètement d'accord, c'est l'idée je pense.

Ah ok je crois comprendre, tu veux un compteur local par thread et un compteur global qui compte le nombre de threads qui ont au moins une référence ?

J'ai oublié de préciser un truc dans mon exemple : les deux threads référencent la même zone mémoire, le même objet.

Dans ce cas tu ne peux avoir de compteur purement local, puisque plusieurs threads accèdent à la même zone mémoire. Dans ce cas il faut faire très attention dans la manipulation du compteur.

Euh non, là il s'agit de mémoire partagée entre plusieurs threads, je pense. Du coup tu as un compteur "global" qui compte le nombre d'utilisations dans tous les threads.

L'opération atomique doit se faire sur ce compteur global.

Par exemple, imagine qu'un thread prenne une référence à un objet qui a déja 10 références: on doit incrémenter le compteur et le passer à 11. Manque de bol le thread est interrompu pendant l'opération, un aute thread prend le relai et incrémente le compteur. L'opération de l'autre thread n'est pas finie et le compteur est toujours à 10 en RAM par exemple ... il passe à 11.

Retour au thread précédent : il est en pleine incrémentation du 10 à 11 et termine : il passe le compteur à 11.

Oups, on a donc 12 référence avec un compteur à 11. On doit absolument garantir que l'incrémentation ne soit pas interruptible en cours de route, c'est ce qu'on appelle une instruction atomique.

Tu me fais dire un truc que je n'ai pas dit :) Sinon tu peux directement t'adresser aux interlocuteurs concernés plutôt que dans le vent.

De ce que je vois il y a eu deux choses avant la chute de la boite : le changement du modèle commercial et de capitalisation. Tu sautes tout de suite sur la deuxième cause pour expliquer l'échec. Ma question du coup : qu'en est-il de la première ?

Un niveau en quoi ?

La boucle serait juste pour donner l'occasion à l'appli de répondre au "ping". L'envoyeur n'est évidemment pas l'appli elle même. C'est wayland lui même qui poserait la question dans mon hypothèse.

la boucle non bien sur, mais le serveur graphique qui envoie son message pour savoir si l'appli est vivante ressemble plus à du polling ... "t'es vivante ?"->oui ... "t'es vivante ?"->oui ... "t'es vivante ?" -> oui. Il faut se débrouiller pour pas poller en permanence.

Je vois pas spécialement comment tu peux faire du pur réactif événementiel, sauf à avoir une action de l'utilisateur comme actuellementt.

et quand elle est dans un état inactif pour cause d'attente d'événement neuf il y a plus forcément de raison de la "poller" pour voir si elle est active, si le serveur a connaissance de cet état.

Ce serait jute un événement parmi d'autres que le serveur envoie, avec les I/O et autres, rien de très différent et qui ahma s'intègrerait très naturellement et presque gratuitement. Si c'est pas totalement gratuitement par rapport à l'existant, faudrait voir comment ça marche aujourd'hui dans le détail.

Les applis graphiques ont toutes une boucle pour gérer les évènements, il suffit d'intégrer ce traitement dans la boucle. Et ça permet de prévenir l'utilisateur qu'une appli a plantée, je vois pas ce qu'il y a d'horrible.

En même temps il doit y avoir d'autres solutions à ce problème, genre "pinger" régulièrement l'appli. Plus sur mais il me semble que sous OSX par exemple, voire sous linux avec compiz les fenêtres se grisent quand l'appli répond pas. Et je ne pense pas qu'il y ait besoin d'interraction utilisateur pour faire ça. Dans ce cas il suffirait de proposer de tuer l'appli au lieux de simplement la griser.

Quitte à refaire un nouveau système graphique autant penser ce genre de chose à la conception.

Absurde, je sais pas, mais j'ai une objection à cet argument.

Si je devais prendre une analogie (foireuse, comme toutes les analogies), ce serait de refuser d'utiliser un logiciel parce que tu n'en connais pas le code ou qu'il est trop compliqué (le code) pour toi, alors qu'un juriste (ou un collègue informaticien) pourrait t'en expliquer les subtilités.

Ça me fait penser à cet argument dans les troll libres "oui, bon d'accord je maîtrise pas le code de tous les lociciels que j'utilise, mais le code est disponible et il est possible d'y jeter un coup d'oeil".

Bref c'est tout à fait dans l'esprit "par des geeks pour des geeks" de certains BSDiens, mais pour le coup ça fait très fermé à l'intérieur de cet esprit.

T'as pas vraiment l'air de vouloir discuter en fait ... Tu veux en venir ou exactement ?

Je parlai de la recherche institutionnelle. Évidemment qu'un fabriquant de bougie peut embaucher un chercheur pour faire de la R&D si elle sait motiver le chercheur et lui fournir un challenge intéressant pour lui ou si il a des idées dans le domaine.

Après si tu lui dis "fais des bougies thérapeutiques" ça va peut être pas marcher, peut être parce que c'est simplement une mauvaise idée. D'ailleurs le marketting n'a pas nécessairement besoin de vrai résultats pour vendre des bougies "thérapeutiques" :)

C'est pas en cherchant à faire de meilleures bougies qu'on a inventé l'ampoule électrique ... Laisser une marge de liberté aux chercheurs est nécessaire pour pas rechercher, peut être efficacement, dans une voie qui ne mène à terme à rien ou qui sera potentiellement rendue obsolète.

On sait pas forcément complètement ou on va.

Et c'est justement ça qui fait plaisir ! Tu as réunis effectivement à peu prêt énormément de ficelle "classique" du cinéma, des références à des tas de genre de film (SF, horreur, films "de gosse", ... ), tout ça c'est fait exprès, en rapport au thème du film (Super 8). J'ai pris ça comme un hommage au cinéma à grand spectacle.

http://imgs.xkcd.com/comics/googleplus.png

http://xkcd.com/918/

Lasher a quand même un peu répondu à ta question : aux US, pas de petites boutiques et prix sensiblement identiques.

Donc il n'y a pas d'intérêt à laisser mourir les petites boutiques qui apportent simplement un choix possible à leurs amateurs, et pas spécialement d'inconvénients aux Zenitram.

Exactement, c'était mon point. Peut être qu'à l'usage le programmeur C il serait content dans certaines circonstances de même pas avoir besoin de tapert man et chercher ce qu'il cherche dans la manpage.

J'ajouterai qu'avec cette argumentation, on a limite pas besoin de man au delà de la premère vision puisque le programmeur C sait déja ce qu'il fait. Dans ce cas il est effectivement compréhensible qu'il n'ait jamais besoin d'aide mémoire :p

Rien n'empêche de donner aussi la description générale avec les détails à porté de vue aussi. Et d'autre part pour utiliser fork, il faut déja la connaître un minimum, ne serait-ce que son existence. Et finalement, si il n'y avait que des fonctions sans paramètres dans la libc, ça se saurait.

Non, on a clairement fait mieux, et on peux carrément faire mieux et plus moderne que bash.

D'ailleurs on peut s'en rendre compte en regardant comment est implémenté l'autocomplete, amha.