reno a écrit 3881 commentaires

Ce n'est pas parce que c'est pénible que les devs Linux ne le font pas: pour rappel, Linux tourne même sur des processeurs sans MMU!
Et Linus prend la compatibilité ascendante pour Linux très aux sérieux, ce qui est d'ailleurs l'attitude exactement opposé aux desktops basé sur Linux: le contraste est vraiment frappant.
Après on se demande pourquoi le kernel a un succès énorme (serveur, HPC, embarqué) et le desktop Linux pas du tout..

Ayant grandi dans une famille végétarienne, je tiens à faire une remarque: quand on est habitué à manger végétarien et qu'on change ensuite pour un régime "normal", on a toutes les changes d'être en sur-poids!

Une conséquence pas sympa pour les enfants..

Je trouve bizarre, pour le thème de base de Gnome, de ne pas afficher l'ombre des frames.

C'est peut-être pour des raisons de performance?
Je trouverai assez normal que le thème de base désactive tout ce qui puisse poser des problèmes sur des ordinateurs bas de gamme..

J'hésite: c'est un troll ou tu manque vraiment d'imagination??

Si Linux avait beaucoup d'utilisateurs sur le desktop alors les formats ODF et WebM seraient bien plus répandu, les problèmes de vente liés des ordinateurs serait probablement moins nombreux, il y aurait plus de matériel compatible, etc.

Comme dis dans le journal: X.Org n'a pas été retenu non plus.

Si on regarde le nombre d'utilisateur on a X.Org >> CoreBoot >> Plan9

Au dernière nouvelle, ils n'avaient pas été accepté comme organisation mentor ce que je trouve plutôt surprenant quand je vois la liste de ceux qui sont acceptés..

Pour autant que je sache, la seule différence entre une affectation de structure et un memcpy est que memcpy initialise aussi les octets de padding/rembourrage, ce qui a priori n'a pas d'impact.
Donc plusieurs hypothèses:
1) tu t'es trompé et le problème ne vient pas de là
2) la différence sur les octets de bourrage ont un impact sur l'émulateur (??)
3) bug du compilateur: essayer de regarder l'assembleur généré.

En gros, tu veux modifier le fonctionnement d'Ethernet.

Bah non ce que j'ai décris se fait très bien avec des VLAN "normaux", d'ailleurs c'est comme ça qu'on sépare les plans gauches et les plan droits sur les switchs internes aux cartes.

Bon, j'aurais fait un schéma ça aurait été plus compréhensible, ma faute.

Oui, on a une autre configuration qui se monte et effectivement on va aller vers le MC-LAG.

En fait j'ai du mal m'expliquer mais nous sommes dans la configuration que tu décrits dans "autre configuration":
VLAN 10 et 20 natif sur le switch interne de chaque carte, trunkés sur les switchs d'aggregations.

Merci pour le lien sur les bridge inter-VLAN.

Attention par contre si tu veut une configuration résiliente tu va devoir effectuer ce bridging sur les deux switches d'access, et donc … mettre en place une boucle et necessiter … du spanning tree, yala la boucle reboucle !

Pas nécessairement, si je bridge de tel manière que "plan gauche extérieur" et "plan droit extérieur" fonctionne mais pas "plan gauche plan droit".
C'est à dire qu'un broadcast venant de l'extérieur atteindra le plan gauche et le plan droit, mais qu'un broadcast venant du plan gauche ou du plan droit n'atteindra que l'extérieur (et pas le plan opposé).

Certes, mais comme nous avons isolé les "plans droits" et "plan gauche" avec des VLANs, les connecté a un switch, ne fait pas une boucle: il faut 2 switch pour que ça pose un probleme.

Il a dit ça oui, mais il ne faut pas l'interpréter comme tu le fait..
Wayland n'induit pas beaucoup de lag car il est "efficace" en local tout comme DRI2, mais il n'est pas magique si un programme est lent a régénérer l'affichage de sa fenêtre, il va y avoir des effets lors du redimensionnement..

Le test a été fait avec Windows7 ( http://thread.gmane.org/gmane.comp.freedesktop.wayland.devel/786 ), mais ça devrait être pareil avec Wayland: le redimensionnement de la fenêtre peut être saccadé si le programme est lent puisque tu attends que le programme ait fini d'afficher la fenêtre avec de montrer la nouvelle fenêtre..

Si tu fait le redimensionnement coté serveur, il n'y a pas de saccade car c'est le serveur qui va de manière autonome générer une nouvelle fenêtre, mais si le client est lent alors le résultat sera moche car par exemple le serveur générera la nouvelle fenêtre en ajoutant des bords a l'ancienne ou en tronquant l'ancienne image: moche mais fluide.

(Moche et fluide) ou (joli et saccadé): choisi ton camp, il n'y a pas d'alternative..

Enfin si il y en a une: utiliser une thread par fenêtre coté client à la BeOS ce qui devrait éviter qu'un programme soit lent à se ré-afficher.

Pourquoi? Si j'ai bien compris, le client a dessiné sa fenêtre dans le buffer, si on déplace la fenêtre, il n'a rien à faire.

Comment le serveur d'affichage saurait-il qu'il faut déplacer la fenêtre?
Il ne gère pas les décorations..
C'est le client qui le doit le lui dire, il n'y a pas a ré-envoyer le contenu de la fenêtre, mais il y a des IPCs en plus par rapport à une interprétation coté serveur.

Je pense que ça doit donner ça comme séquence avec décoration coté client: action souris --> kernel --> serveur d'affichage qui trouve le client correspondant et lui envoie l'évènement --> client qui interprète l'évènement comme "l'utilisateur veut déplacer ma fenêtre" --> envoit au serveur d'affichage une requête "déplace ma fenêtre".

Comparé à action souris --> kernel --> serveur d'affichage qui interprète l'évènement comme "l'utilisateur veut déplacer une fenêtre", le serveur déplace lui-même la fenêtre.

La nouvelle simplifiée n’amènera pas de baisse de performance en local puisque si tu louches un peu, Wayland c'est DRI2 (ou vice versa).

Bon il y aura quelques changement quand même: gestionnaire de fenêtre (simplifié puisque décoration faite cote client) intégré au serveur d'affichage: moins d'IPC: léger gain en performance, par contre la décoration coté client conduira a plus d'IPC entre le client et le serveur d'affichage quand on déplace une fenêtre, mais en cas de redimensionnement de fenêtre le résultat sera plus joli avec cependant un risque potentiel de saccade..

En réseaux, par contre la situation est beaucoup moins clair: les toolkits garderont-il le support d'X sur le long terme? Si ce n'est pas le cas, ça risque bien d'être le bazar..

Pour ma part c'est pour ça que je ne suis pas chaud lorsque j'entends qu'il existe des initiatives pour virer X11 et développer autre chose à la place

Surtout que comme X11 a l'extension DRI2 (écrite en grande partie par le développeur principal de Wayland d'ailleurs), il n'y aura (à priori) pas vraiment de gain de performance..

Et bien je pense que si tu mets un gros verrous ou si tu utilise des transactions plus fines pour le STM alors il est possible que l'implémentation avec STM soit plus performante.
Certes la réponse est alors: tu ne compares pas des choses comparables, mais ce n'est pas tout à fait vrai si la référence est la simplicité d'utilisation pour le programmeur.

Si je comprends bien, tu tagues tes deux sortis sur ta « carte » pour ne pas qu'elles se trouvent sur le même LAN mais après tu veux… bridger ces deux VLAN ?

Oui.

Tu sais que tu viens de faire exactement ce que tu t'empêchais de faire en mettant les sorties sur deux VLAN différents ?…

J'ai plusieurs carte avec un switch interne connecté aux deux switch d'accès (et ne peut pas utiliser RSTP): si je ne met pas de VLAN différent, j'ai une belle boucle Ethernet!

Bah, l'école c'est pour apprendre la vraie vie: donc les élèves apprennent qu'il faut être "lèche botte" avec son patron pour être bien noter.

Quand sur LinuxFR on dit « Linux n'est pas prêt pour la tablette », évidemment qu'on parle de GNU.

D'accord pour cette partie, ceux qui font semblant de ne pas comprendre sur LinuxFR sont des enc.. de mouches: le contexte est clair dans 99% des cas.

On s'en fou du noyau, le noyau il est prêt pour tout.

Pas d'accord: pour ce que veut faire Ingo, il veut une sandbox pour les applications "tierces" et là potentiellement ça a des impacts sur le noyal pour avoir ça: à l'heure actuelle le noyau Linux n'a pas de sandbox en standard..

Parce que bon quand on parle de GNU, on va pas se restreindre à du dalvik..

Après avoir une vrai API pour faire un système desktop qui soit utilisé par plusieurs distrib, j'y croirais quand je verrai une application packagée en RPM acceptée dans Debian: après tout c'est le format défini par la Linux Standard Base, non?

Je suis une bille pour faire des diagrammes, mais je peux expliquer:
1-il y a plusieurs cartes qui ont un switch interne avec 2 sorties, ces cartes sont connectées a 2 switches pour la redondance d'accès.
Pour éviter qu'il y ait des boucles L2, on doit utiliser des VLANs différents pour chacun des switchs d'accès (autrement les switch internes aux cartes nous feraient des belles boucles et le RSTP c'est trop lent).
2-l'idée est de connecter ces 2 switches d'accès à un troisième switch pour accèder avec 2 liens possible à un équipement.

J'avais fait l'explication avec juste 2 VLANs car c'est plus simple à comprendre, mais ce qu'il faut retenir c'est que je ne peux pas mettre le même VLAN de chaque coté.

Le but? Faire communiquer 2 LAN dont je ne peux pas changer les VLAN ID sans devoir utiliser un routeur..
Mais j'ai l'impression qu'avec 802.1Q on ne peut qu'ajouter ou retirer des tags de VLANs pas passer d'un tag à un autre, je me demande bien pourquoi ils ont choisi ceux qui ont fait cette norme ont fait ce choix étrange.

Non plus: Weston n'est pas une API, donc remplacer Wayland par Weston dans son post ne le rend pas beaucoup plus correct.

Je me demande si ça serait possible d'ajouter un mode combat?
Dans un premier temps, ce serait juste des "lasers" qui tirent tout droit et un système de score.
Après ça pourrait être améliorer progressivement: des balles qui ont une vitesse finie, puis qui subissent la gravité, et ensuite qui ont un effet de "recul" et enfin un modèle de dommage sur les avions(!)..

Je n'ai jamais trouvé que voler seulement dans la campagne était intéressant, avoir un mode de combat avec des avions réalistes c'est plus amusant (enfin surtout les vieux coucous, les avions récents c'est trop compliqué).

Ils donnent un exemple pour appeler des librairies C ou Fortran: http://julialang.org/manual/calling-c-and-fortran-code/

Oui, enfin on pourrait dire de la même chose pour d'autres divisions des logiciels libres: deb/rpm je n'ai jamais compris l'intérêt,
par contre Julia a une syntaxe proche de Matlab ce qui peut être un plus pour les utilisateurs,
pareil pour KDE/Gnome avoir plusieurs options cotés interfaces graphique ça apporte un bénéfice aux utilisateurs..