Thomas Douillard a écrit 9167 commentaires

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.

Tu dis ça parce que le shell est vieillissant et pas à la hauteur. Dans l'absolu rien n'empêche de le rendre aussi malin que les IDE ou aussi introspectif que l'interpréteur python sur ses commandes.

À mon avis les pages de man sont assez pauvres en annotations sémantiques, t'es un peu obligé de les parser pour extraire les paramètres d'une fonction ou d'une page de man, ou de récupérer le texte de description d'une option. Informations qui sont utiles pour présenter la bonne info au bon moment plutôt que la page de man en entier.

Enfin c'est mon impression, je connais pas le langage qui permet de les écrire. Dans tous les cas effectivement rien n'empêche de regénèrer des pages de man par la suite, mais l'intérêt des pages elles même / de la commande n'est plus vraiment primordial.

La documentation est évidemment utile, après les outils modernes l'intègrent avantageusement (à mon avis) directement dans l'environnement de dev. Ça peut se faire à la volée, éventuellement à porté de clic ou de raccourcis clavier si tu veux des exemples ... Ce dont tu pourrais avoir besoin est dans la plupart des cas déja là, t'as pas à faire l'effort d'aller chercher l'info dont tu pourrais avoir besoin dans les pages de man relativement pauvres d'informations sémantiques à part les différentes rubriques.

Pareil pour naviguer dans une doc, une fois la doc lancée, les hyperliens sont quand même carrément plus pratique que de devoir recharger une page de man des "voir aussi" des différentes fonctions ou commandes.

Du coup, certe cool, ça charge vite, mais à moins de faire du dev en console je vois pas trop l'avantage par rapport à un IDE ou tu n'as même pas besoin de charger la doc.

Pour moi continuer à l'utiliser en ldc pour du dev c'est voué à disparaître à plus ou moins long terme. À part le poids de la tradition et des habitudes, bien entendu.

Tu ne fais que coder en C des programmes en ligne de commande pour t'auto-héberger ?