reno a écrit 3880 commentaires

Ce n'est pas totalement faux, m'enfin je pense que l'impression que les devs de Canonical ne comprennent rien sont due au wiki, sauf qu'à mon avis le wiki il a été fait par le stagiaire qu'on cherchait a occuper plutôt que par les devs.

La preuve quand un dev de Mir dialogue avec les devs de Wayland sur IRC ( http://pastebin.com/KjRm3be1 ), on peut "résumer" la conversation comme ça:
W-Gérard, tu fais ce que tu veux mais arrête de dire que Wayland a le même problème de sécurité qu'X!
M-Hein? mais non on n'a jamais dit ça..
W-Si, ici!
M-Et m… --> le wiki est modifié

Ceci dit quand on voit que ça ne dérange pas grand monde qu'il y ait 2 systèmes de packaging totalement équivalent (.deb et .rpm, NixOS est différent), je ne vois pas trop pourquoi on tapes sur Canonical pour Mir..

Pour moi, mir c est libwayland et unity weston.
Mais bon j' ai la flemme de lire le code alors je vais attendre qu il y ait de la doc..

A l'utilisation, je trouve G+ beaucoup plus épurée et simple que Facebook, le flux, rien que le flux.

Et personnellement je trouve ça les 2 très chiant à lire, dès qu'il y a un peu de message: pas d'arborescence == le bazar.
Ces 2 "médias" n'ont pas vraiment aucun intérêts pour des discussions sérieuses..

Wayland a une architecture bien plus simple et bien plus propre que Mir.

Ah? Pourtant les deux m'ont l'air assez similaire, c'est quoi les différences selon toi?

Ainsi la plus part de ce que fait wayland sera dans unity et non pas dans mir.
???
Euh la librairie wayland ne fait pas grand chose, c'est weston qui fait plein de chose, non?

Pour le reste, Mir semble en effet immature car il n'a pas encore la gestion des input alors que la partie difficile dans un serveur d'affichage c'est la gestion des inputs, la partie affichage c'est la partie facile..

Ce n'est pas toi..

1) J'ignore pourquoi Wayland et SurfaceFlinger existent tout les deux au lieu d'avoir un seul projet (on pourrait se poser aussi la question avec DirectFB!!) mais un dev Wayland a fait tourné un proto (proof of concept) de Wayland sur Android:
http://ppaalanen.blogspot.fi/2012/07/wayland-on-android-snapshot-release.html?m=1

2) Le truc qui a agacé les dev Wayland, c'est que le wiki de Mir dit que Wayland a le même problème de sécurité qu'X alors que c'est faux (les évènements ne sont envoyés qu'à un seul client et un client Wayland ne peut pas envoyer d’évènements), ça a été corrigé dans le Wiki de Mir: https://wiki.ubuntu.com/MirSpec?action=diff&rev2=4&rev1=3 ce qui devrait apaiser la situation.

Pas sûr que ce soit un problème de math, mais je trouve que ce genre de question montre bien le problème d'Ocaml:
http://linuxfr.org/forums/programmationautre/posts/ocaml-probleme-de-type-avec-les-modules

Euh en fait j'avoue: ce que je l'ai marqué, c'est ce dont je me souviens quand j'avais regardé OCaml mais c'était déjà il y a un certain temps donc je me souviens de me "conclusions" de l'époque mais pas des raisons..

Mes impressions:
1) Peu de librairies, par exemple je ne crois pas qu'il y ait une librairie pour Qt.
2) Les manuels poussent à faire du fonctionnel (alors qu'OCaml peut aussi faire de l'impératif) ce qui rend le code moins lisible quand on n'a pas l'habitude.
3) Une syntaxe qui pourrait être améliorer (celle de F# est mieux qu'OCaml).
4) Pas/peu de marketing comme tu disais.

Ça fait beaucoup..

Merci pour les infos, mais bon passer de ça à ce qu'envisageait symoon, il y a de la marge..

J'ajouterai qu'en cas de vautre à 40km/h, si t'as 20kg de trop, tu vas les sentir pour de bon.

Euh, à moins de se prendre un arbre, la vitesse horizontale ne compte pas vraiment il me semble..

Le lien a tout hasard:
http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341359084

Après le problème de tout ces cartes, c'est qu'il faut faire très attention au GPU, si je ne me trompe pas le Mali est celui pour lequel les efforts d'ingénierie inverse sont les plus prometteurs:
http://www.cnx-software.com/tag/fosdem-2013/

Euh je ne suis pas sûr qu'avoir un entrainement physique ça aide à prévenir les fractures.
Où alors l'entrainement physique ça rend les os plus solides?

Quand tu passes à 32 bits, tu augmentes encore la complexité.

Euh quelle complexité? Le nombre de transistors utilisés,OK mais la complexité d'utilisation c'est plutôt l'inverse: c'est plus simple de servir d'un CPU 32 bits que d'un 8/16 bits.

Ici, on parle d'élément minuscule qui ne consomme rien, et on remplacer les µp 8 bits.

La d'accord.

J'ai un peu l'impression que le web est divisé entre une partie "civilisée" (par exemple, Wikipédia ou Linuxfr), où, mine de rien, il y a une ligne éditoriale (et un certain suivi, on "rencontre" virtuellement plusieurs fois les mêmes personnes), et une partie "far west", où des handicapés sociaux viennent déverser des torrents de bile haineux.

Pas si sûr qu'il y ai une vrai division: les trolleurs sont quasiment partout, après quand tu as l'auteur de site qui trolle lui-même(phoronix) forcément ça appelle au troll quoiqu'il y ait parfois les auteurs des logiciels qui interviennent sur le forum!

Le msp 430 est super clean.

Pour un micro-contrôleur 16 bit, tu aurais pu préciser ça m'aurait éviter de chercher et d'avoir les pointeurs NEAR/FAR qui me reviennent à l'esprit (argh!).

Sur le principe ok, mais bon les coopérations inter-distributions j'y croierai quand je le verrai: même pas fichu de se mettre d'accord sur un format de package alors cooperer sur un DE..

Ouaip, tant que ça boote Debian: http://lwn.net/Articles/540244/

Bon blage à part, les changements de l'ARMv8 sont plutôt bien expliqués ici: http://www.realworldtech.com/arm64/

Dans les instructions de load: le prefetching.

ARM dispose maintenant d'un grand nombre de mode d'adressage qui l'éloigne du concept RISC.

Bof, pas tant que ça dans le RISC l'essentiel au point de vue adressage c'est d'avoir des instructions LOAD/STORE séparée des instructions arithmétiques qui ne touchent que les registres.

Ses derniers évolutions utilisent un jeu d'instruction avec 2 tailles d'instruction : 16 et 32 bits. Cela commence à se complexifier.

1) le MIPS a aussi une variante avec jeu d'instructions sur 16/32 bit
2) tu retarde un peu: l'ARMv8 (64bit enfin) vient justement de laisser tomber les instructions 16bits.

Tu oublie que le projet KDE ne cherche pas vraiment à livrer des versions stables: ils ont tendance à activer par défaut des nouvelles fonctionnalité pas vraiment finie, donc pour les utilisateurs qui veulent juste utiliser KDE et pas faire les béta-testeur, utiliser une distribution qui fait l'effort de stabiliser KDE au lieu de prendre juste la dernière version de KDE, ça a un grand intérêt.

C'est gentil de lui faire ses devoirs.

Entre autres, ça leur ait arrivé de désactivé par défaut des nouveautés du projet KDE car elles n'étaient pas fiables,
dommage que pas mal de distribution (ou le projet KDE lui-même) ne font pas ce travail..

Après un de ses développeur principal TexStar semble s'être arrêté pour raison de santé..

Pfff, complètement faux: tu confonds le débit et la latence.
D'ailleurs l'augmentation du débit de la mémoire se paye souvent par une augmentation de la latence..

C'est une bizarrerie de NX ou de LibreOffice?
Je veux dire: est-ce que ça se passe aussi comme ça avec un 'export DISPLAY' de base (non NX)?