reno a écrit 3881 commentaires

Blague à part, autant pour la déclaration de variable, je suis plus ou moins d'accord, mais ça fait un tas de ligne en trop.

Euh, tu sais on est plus dans les années 80 avec déclaration séparée..
Maintenant dans les langages de bon gout, une déclaration de constante/variable c'est juste un mot clef: "def x = valeur' ou "var x = valeur" le type est inféré..
Et si tu as besoin de spécifier le type "def/var x : type = valeur": pas de ligne supplémentaire dans les 2 cas, ce qui évite que x soit déclaré mais pas initialisé.

Le typage statique n'a aucun intérêt en Python, parce que ce n'est pas dans sa philosophie

Pas d'accord, par exemple ça m'aurait permis de gagner pas mal de temps sur un script ou je passais sans m'en apercevoir un pointeur de fonction et non pas le résultat de la fonction (oubli d'un ())..
Note bien que le langage dont je parlais Groovy n'est pas uniquement statiquement typé: il a les deux!
Typiquement tu commence par faire un script sans préciser les types et si ça ne marche pas comme tu le voudrais ou si tu as besoin de perf, tu rajoute des annotations de type.

Il est excellent pour du scripting rapide et propre (ce que je demande à un langage de script).

Excellent? Bof, pas de possibilité de forcer la déclaration de variable (l'équivalent d'use strict en Perl), pas de typage statique possible (comme Groovy).
Python est un bon langage que j'aime bien mais il est loin d'être "excellent" malheureusement..

Toutes les applications restaient sur X donc pour l'utilisateur mis à part un léger ralentissement, il n'y aurai eu aucun changement.

Non: X11 'utilisé à l'ancienne' te fournit bien plus d'information pour un affichage distant efficace que Wayland!

Justement, il y a quasiment plus de toolkit qui utilise X "à l'ancienne" (à ma connaissance, dans les toolkits actuels (à défaut de modernes) il ne reste que Tk)

Qt4 a un mode XRender, il me semble.

Et puis NX n'utilise pas le proto X11, justement parce que X11 n'est pas adapté.

NX étant une surcouche au dessus de X11, on peut dire qu'il utilise X11, un NWayland serait moins efficace.

Autant faire un proto local et utiliser les autres proto pour le distant.

Certes, mais pour être efficace cela implique que les toolkits doivent parler 2 protocoles..

Il est surement possible de développer un truc équivalent pour Wayland

Oui et non.
Oui: tu peux implémenter un proxy local: Weston le fait déjà avec RDP.

Non: X11 'utilisé à l'ancienne' te fournit bien plus d'information pour un affichage distant efficace que Wayland!
Par exemple dans X11 il y a des API pour le dessin du texte et d'autre pour le fond de ta fenêtre, avec Wayland tu as l'équivalent d'un PNG de ta fenêtre, et c'est tout.
Après X11 a tendance a être utilisé comme Wayland le sera: rendu local dans une image, puis envoi de l'image: efficace en local, beaucoup moins en distant donc en fait c'est une sorte de "nivellement par le bas": avec X11 tu pouvais faire efficace en distant (relativement: X est loin d'être optimal) mais c'était de plus en plus rare, avec Wayland uniquement tu ne pourras pas.

sous-optimal bien sûr, par rapport à une gestion dans le protocole
Pourquoi ?

C'est une vrai question??
Bon aller on va dire que oui: avec Wayland, une application envoi une image de sa fenêtre au serveur (en gros un PNG), donc il y a eu perte d'information et ça deviens beaucoup plus difficile a traiter.
Par exemple pour avoir un affichage distant avec une bonne qualité et une faible bande passante, on peut imaginer d'avoir une compression sans perte pour le texte et une compression avec perte pour le fond, ce qui n'est pas faisable avec du Wayland 'pur': il faut que le tookit/l'appli te donne des informations en plus..

Je ne fais que répeter ce que disent les développeurs de Xorg, et c'est moi le troll ?

1) Les dev de Xorg qui embrassent Wayland ne sont pas neutres, ils défendent leur décision, on n'est pas obligé de répéter bêtement ce qu'ils disent..

2) tu n’arrête pas de répéter la transparence réseau ci, la transparence réseau ça, mais tout le monde le sait que la transparence réseau ça n'existe pas vraiment puisque la bande passante et la latence sont totalement différentes ET CA A TOUJOURS ÉTÉ LE CAS (la latence tu sais ça n'a pas beaucoup changé..).

A partir de là, quelle est la définition raisonnable du terme que tout le monde utilise?
Un protocole d'affichage graphique qui intègre l'affichage distant par défaut, point.
Donc
1) Wayland ne fournit pas ça. On peut ajouter des surcouches à Wayland (dont X), l'implémenter dans le serveur d'affichage (sous-optimal bien sûr, par rapport à une gestion dans le protocole), mais Wayland lui-même est purement local.

2) X11 a l'accès distant en natif lui, même si c'était un accident (quoique vu le nombre d'universités qui se servaient de cette fonctionnalité, c'était un accident très utilisé), même s'il est sous-optimal..
Ceci dit X s'est amélioré avec le temps pour l'accès distant: cache de glyphe XRender qui te permet d'afficher efficacement du texte, XCB asynchrone vs XLib synchrone, là malheureusement les toolkits ont traîné les pieds pour passer à XCB..
De manière amusante c'est Wayland qui a poussé les dev Qt a passé à XCB pour Qt5 (car les deux sont asynchrones), donc l'affichage distant sous X avec Qt devrait s’améliorer grâce à Wayland :-)

Xorg n'a plus de transparence réseau depuis longtemps, faut arrêter avec ce mythe.

Tu as fini de troller??
Tu peux utiliser X en distant de base, oui X a aussi des extensions pour optimiser l'affichage en local et je peux imaginer des toolkits et/ou des applications qui ne fonctionnent qu'en local mais pour l'accès distant ça reste une situation bien meilleure que la situation avec Wayland ou de base tu n'as aucun accès réseau mais si tu as de la chance alors peut-être que ton serveur d'affichage va avoir une extension qui te fournira l'accès réseau en distant.

Modulo que celui dont les propos sont rapportés ne travaille pas directement sur Wayland, par contre effectivement il peut être biaisé: quand on travaille sur le gestionnaire de fenêtre pas sûr que la transparence réseau soit une préoccupation majeure. .

Concrètement, comment tu fais pour avoir une vie sociale sans boire de glucides?

Facepalm, tu as un problème, toi..
L'eau (avec ou sans bulles), les sodas light, le thé, le café ça existe aussi tu sais!

Hum, ce que tu viens de dire est contradictoire: manger moins EST frustrant!

L'alignement n'est pas nécessaire, juste sur le fait que le window manager informe les clients sur le fait qu'il affiche ou pas les barres de titre (et sur la façon de donner les infos pour les barre de titre).

J'espère que ce sera sur le fait que les logiciels ne font pas eux-mêmes leurs décorations, sinon ça va être disparate au possible.

Hum, il n'y a que KDE (de ce que je sais) qui ne va pas fonctionner comme ça, ça ne m'étonnerait pas que ça devienne le nouveau "standard": l'uniformité pour les logiciels libre on ne sait pas trop faire..

Oups, désolé, j'ai sauté ton paragraphe, mais bon étant donné que ton régime me parait fortement contraignant, j'ai comme un doute pour le coté permanence.

Quand on utilise le mot REGIME, ça implique généralement qu'on veuille appliquer le régime pour une période limitée, et qu'est-ce qui se passe à la fin du régime?
On reprends le poids plus un malus!
Ce qui marche c'est changer les habitudes alimentaires(/sportives): tu regardes ce que tu fait mal actuellement et tu change ça, mais de manière totalement indolore, en se faisant plaisir, car le but est de rester ad vitam avec ce nouveau type d'alimentation.
Pour mon cas: augmenter la consommation en crudité, en trouvant des assaisonnements qui me convienne (je n'aime pas l'huile ou la vinaigrette mais la salade avec de la sauce soja ça passe très bien) et ça marche!

Bah, c'est la même chose avec X, il y a beaucoup de conventions, qui ne fonctionnent "bien" que parce que les devs les ont implémentés: j'ai déjà eu des problèmes de copier/coller avec des toolkit différents.
Avec Wayland, c'est juste plus visible parce que c'est tout neuf..

Bin en même temps avec Wayland c'est le toolkit qui s'occupera d'afficher la barre de titre

Non, c'est une possibilité mais par exemple le dev de KDE qui maintient KWin n'aime pas ça et veut garder ça comme serveur avec KDE, donc c'est juste une possibilité, pas une nécessité.

Et surtout, le produit le plus mortel contenu dans le Coca-Cola est de loin le sucre.

Pas pour tout les cocas.. Etant un gros consommateur de Coca light/zero j'en ai rien a faire du sucre, mais ce fameux colorant m’embête un peu..
Bon le site Open Food Facts est inutile sur le sujet: il dit qu'il y a un colorant dans le coca qui est un problème, mais il ne marque pas combien il y en a!!

N’y a-t-il moi que ça frappe que pour pousser ses jeux sur Linux un éditeur décide de sortir sa propre distribution ? Toujours ce morcellement sans fin.

Ce n'est pas vraiment surprenant vu la façon dont les distributions Linux fonctionnent actuellement: pas de standardisation sur le packaging, ABI pas vraiment stable..

Mais bon, ce qui était voulu a pu être fait seulement grâce au délire de la GPL à faire des différences entre les types de link

Tu veux parler de la LGPL pas de la GPL, je pense.
Et oui je suis d'acord avec ton point de vue sur la LGPL.

Le pire c'est qu'il y a réellement des avocats de la CDDL (des gens de Sun/Oracle principalement) qui te disent sérieusement que c'est la faute de la GPL..
C'est vrai que la GPLv2 était une licence mineure totalement inconnue et inutilisée quand ils ont écrits la CDDL!

Etant donnée que la licence ne change pas, je ne vois pas ce que ça apporte pour Linux, pour les BSD effectivement c'est sympa pour eux.

Les deux grands ont laissé tombé et ne se servent de l'ordi que comme simple outil, sans jamais avoir essayé de contourner (ou même de comprendre) les dispositifs de contrôle. Je trouve cela dommage.

C'est ça: s'ils ont mis la main sur une 'live key' qui leur permet de contourner les sécurités de ton ordi sans laisser de traces, ils vont te le dire..

Bah, ça dépend du but: éviter que des jeunes enfants voient des images sexuelles avec une liste blanche, ça doit marcher.
Après on peut débattre de l’intérêt de la chose, bien sûr..

Pour éviter que des ados aillent surfer sur des sites de cul quand on n'est pas là, effectivement là c'est perdu d'avance.

oui mais supposons que cet iPhone rame aussi par moment et que c'est au delà de ces 5 minutes d'essai…

Bin oui, mais j'avais essayé de switcher rapidement d'une tache a l'autre et je n'ai pas remarqué de ralentissement alors que mon GS3 :-(

j'ai un nexus 4, et ça rame vraiment pas souvent, sauf quand il y a trop de programmes de lancés en même temps, en ce cas il suffit de tuer des tâches (souvent des gros jeux bien lourds et bien graphiques)

Nexus étant un Android "pur jus", tu réponds à mes interrogations Android/Touchwiz: c'est le système de gestion des processus d'Android qui est mal fichu: c'est à lui de tuer des process, pas à l'utilisateur..

Ben t'enlèves tous les widgets que t'as mis sur ta 'home'

1) Ça me parait un peu extrême, à mon avis il y a des widgets bien programmés et d'autre pas, mais savoir quel widget ralenti le téléphone est un problème..

2) d'ailleurs le problème n'est pas limité aux widgets, j'ai eu une application de gestion de tâche(memoriser les RDV, etc) (Astrid) qui faisait aussi ramer le téléphone.