reno a écrit 3881 commentaires

Tu peux déjà faire une fenêtre transparente qui couvre tout l'écran avec X11

Oui, enfin si tu as un gestionnaire de fenetre qui se préoccupe de la sécurité, il pourrai lui mettre une bordure ce qui ne sera pas très discret, non?

Oui, enfin Microsoft qui de facto forçait les vendeurs de PC à ne pré-installer que du Windows (avant de se prendre le procès anti-trust) et qui à l'heure actuelle utilise ses brevets logiciels pour faire payer les concurrents, je ne vois pas trop la différence avec Apple..
Tout les deux ont choisi d'utiliser à fond leur département juridique pour se faire de l'argent et pour handicaper au maximum les concurrents, ça promet pour le futur..

Dans la première version il n'y avait pas les renvois, résultat c'était lourd à lire.

Alors après j'aurais pu faire plus concis mais si tu ne sais pas ce qu'est "server side décoration", où qui est Kristian Høgsberg, tu perds des infos..
Bref c'est facile de critiquer mais pas si facile de rédiger.

Tu ne peux pas comparer Amiga aux OS modernes: Amiga n'avait pas la protection mémoire, ça change énormément de choses..
BeOS était très réactif et moderne, mais je ne sais pas exactement le découpage qu'il y avait entre les applications et le serveur d'affichage, je sais par contre que chaque application avait une thread séparée pour l'affichage..

Il y a eu plusieurs serveur d'affichage "lourds": NeWS, Berlin/Fresco (n'est pas aller très loin) mais a l'heure actuelle ce n'est pas la tendance effectivement..

Oui, mais si tu veux attendre car tu pense que l'application est juste figée temporairement, tu peux iconifier la fenetre et attendre, avec la décoration coté client, tu as juste une fenêtre figée au milieu de ton écran et puis c'est tout..

Je ne comprends pas bien cette histoire de décorations de fenêtres qui devraient être effectuées par les logiciels eux-mêmes.

La justification semble être que c'est plus simple à faire et plus efficace (cf l'email de Kristian Høgsberg), mais à mon avis, ça ne réduit pas la complexité globale, ça la déplace juste vers le client et puis ça pose des problèmes de fiabilité et de sécurité:
si une application affiche une fenêtre transparente sur tout l'écran, elle peut tout espionner??

est-ce à dire que cela signerait la mort des gestionnaires de fenêtres ?

En tout cas, ça diminuerait de beaucoup leur fonctionnalités mais il resterait des fonctionnalités il me semble: le verrouillage d'écran, le "force quit" a ajouter..

Bah, je suis contre les brevets logiciels, mais évaluer un brevet par son résumé est aussi valable que d'évaluer un livre par son titre, c'est à dire: pas du tout.
Mais comme lire les clauses d'un brevet logiciel c'est pénible, c'est une erreur assez répandu malheureusement.

Vieux pour les gens sous windows c'est 3ans,

Hum, Windows XP est encore très, très utilisé ce qui te contredis..

Merci pour le lien, l'idée d'un "préquel" de la planète des singes me tentait bien, mais après avoir lu ça je crois que je vais passer!

C'est peut-être mieux, mais alors coté doc c'est pas ça, je n'ai même pas compris le comportement avec des processus fils..
Si tu appliques une limites a un processus mais que celui-ci fork un autre processus que se passe t'il?

Oui, bien sûr, sauf qu'il n'y a pas assez de registres de segments pour cela,

Soupir, là tu parles d'une implémentation spécifique, je ne vois pas de raison particulière pour laquelle les segments ne seraient pas efficace dans l'absolu
(mais il y a un coût: stocker/relire le numéro de segment en mémoire n'est pas gratuit, mais vérifier le non-débordement des accès a un tableau est encore plus coûteux).

Enfin bon, si on veut absolument éviter les débordements de tableaux, on peut utiliser des structures de données adaptées au lieu d'imaginer des bidouilles architecturales.

Je ne vois pas de quoi tu parles, c'est quoi une structure de donnée adaptée qui remplace un tableau?
Et puis qualifier un concept de bidouille parce que tu ne le connais pas, ça ne montre pas une grande ouverture d'esprit..

Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles.

Directement non, mais c'est comme l'histoire, il faut connaître le passé pour pouvoir mettre en perspective les choix du présent: le x86 (beurk) n'est pas tout dans la vie..

J'ai du mal à voir comment KDE pourrait avoir une chance sur le mobile.

Pareil, mais tu comprends le mobile, c'est nouveau donc c'est bien!

Wayland, ça n'apporte pas grand chose par rapport à une évolution de X (qui supprimerait les parties inutilisée pour simplifier la maintenance, ajouterait une option de partage de la RAM du GPU (*) ce qui préserverait le support de la transparence réseau par défaut)?
Non, mais c'est nouveau donc c'est bien!

Bref, si tu comprends que "si c'est nouveau, c'est bien", tu as tout compris de la philosophie de pas mal de projets, bon après curieusement quand j'entends "on va faire du nouveau pour du nouveau", et mais on va se focaliser sur "l'augmentation de la qualité", quelque part je suis un peu sceptique..

*:comme il est déjà possible d'utiliser la shared memory (pas la même) a l'heure actuelle.

Je suis peut-être rabat-joie mais je ne comprends pas trop qu'on s'extasie devant la réplication des partie plastique d'une imprimante,
d'un point de vue complexité je dirais que 99% de la complexité d'une imprimante est dans: la tête de buse, les moteurs, l'électronique
et tout ces partie là ne peuvent pas être répliquée a l'heure actuelle..

C'est un peu comme s'extasier devant des feux d'artifices quand on rêve d'aller sur la lune, ok c'est le même principe, mais bon..

Avec des types entiers, pas de problème, mais avec des types flottants ?

Note que tu peux caster ton flottant en entier (tout flottant a une représentation entière correspondante) puis faire l'échange avec la représentation entière.

Bon, tout ça me parait totalement dépourvu d'intérêt en pratique car "la réduction de l'utilisation mémoire": c'est du pipeau, pas besoin de stocker la variable temporaire en mémoire, un registre suffit..

Il y a un monde entre la version 4.2 et la 4.6…

Oui, euh les améliorations des compilateurs, on les remarque surtout sur des tests artificiels, tu as un benchmark d'une application réelle qui montrerait une grosse différence entre gcc 4.2 et 4.8?

J'espère que ça va aller mieux avec clang-llvm.

D'après les benchmark (tests artificiels) que j'ai vu llvm génère du code un peu moins performant que gcc, mais bon en pratique je ne suis pas sûr que ça compte beaucoup, les messages d'erreurs plus explicite de llvm me semblent un atout non négligeable..

J'avais fais des quelques très modestes tests entre fedora 15 et freebsd 8.2… c'était pas brillant pour freebsd.

Quel tests?

Certe question gestion de projet, les deux n'ont rien à voir, mais comme le dit maclag au dessus le projet KDE a laissé tomber la stabilité et laisse aux distributions le soin de baser un tout stable au dessus (ou pas stable, selon le choix de la distrib) .
Mon reproche principal est qu'ils devraient avoir l’honnêteté de le reconnaître, par exemple en arrêtant de nommer "Release Candidate" des bétas versions et en communiquant mieux avec les utilisateurs, par exemple en disant: "pour avoir des bureaux KDE stables passer par les distributions X, Y, Z, si vous voulez contribuer à KDE n'hésiter pas à télécharger vous-même KDE etc"

En théorie oui, en pratique pas toujours: je suis quasiment sûr que Kubuntu a utilisé KDE4.0, ce que j'avais vraiment trouvé choquant a l'époque, tout comme le fait qu'Ubuntu ait utilisé PulseAudio alors qu'il venait juste de sortir:
ça fait vraiment du tord aux utilisateurs quand une distribution pour le "grand public" décide d'utiliser des logiciels pas encore prêts..

Ceci dit, je suis d'accord: je trouvais curieux que Linus se plaigne d'avoir un KDE instable alors qu'il utilisait Fedora, il utiliserait PCLinuxOS, il n'aurait pas eu ce problème..

Tu l'as déjà marqué mais ce n'est pas parce que tu ne comprends pas que c'est vrai..
Les protections ne sont pas les mêmes: les segments fournissent une protection à l'intérieur même d'un processus, c'est un peu comme si chaque tableau était dans son propre espace virtuel.
Lis le lien de dominique dechamps sur multics, ça peut peut-être t'aider.

Il semble que les X86 aient une instruction INTO qui permet de lever des exceptions sur bit d'overflow

Lever une exception de dépassement entier en une seule instruction c'est bien, mais ça fait quand un surcoût à l'exécution: les MIPS ont 2 variantes des instructions entières, une avec trap sur dépassement l'autre pas, donc il n'y a besoin d'ajouter aucune instruction supplémentaire..

tout est là pour "faire de la sécurité"

Tout était là pour faire de la sécurité: il n'y a plus de segments en mode 64bit sur les x86, comme les logiciels n'utilisaient pas la segmentation, AMD l'a retirer du jeux d'instruction pour le mode 64 bit :-(

ils parlent de fournir une expérience utilisateur sympa.

Déjà de quels utilisateurs parles-t'on?
Pour Gnome3, la cible n'est probablement pas les développeurs, donc ils s'en vont ce qui est assez logique.

y'a donc un décalage entre les discours de chaque projet et ce que leurs développeurs veulent faire, on dirait.

Peut-être et il y a aussi la façon de le faire: regarde KDE4.x, il y a une partie de nettoyage qui était nécessaire (Phonon pour régler le problème du son), mais il y a eu aussi plein de nouveauté qui ont été là clairement pour faire plaisir aux développeurs (les activités, Nepomuk) et introduit de manière perturbatrice pour les utilisateur (les questions 'comment désactive-t'on Nepomuk?' et assimilée sont nombreuses; ils ont introduit une réécriture des indexeurs Strigi/Nepomuk entre la dernière RC de KDE 4.7 et la version finale).

C'est ce manque de stabilité de KDE4 qui avait fait partir Linus: les dev de KDE préfère "tout casser" pour aller plus vite dans l'introduction des nouvelles fonctionnalités, c'est leur choix, mais bon personnellement je trouve que cela montre un manque de maturité du "bureau KDE" et je trouve ça dommage car au niveau fonctionnalité, on ne peut pourtant pas dire que KDE en manque!

Comme d'habitude LWN fournit un résumé de grand qualité: http://lwn.net/Articles/452865

Cependant, le point qui m'a le plus intéressé (plutôt que le débat classique portable vs non-portabilité) est l'avis d'Al Viro: http://lwn.net/Articles/453529/
Il déteste systemd car il dépend de partie du kernel qu'il n'aime pas comme les cgroup et fanotify, intéressant car j'ignorais que ces parties du kernel était si mal vue..

Il n'aime pas D-Bus, il préfère plumber(*) , ce n'est pas la première critique que je vois de D-Bus, intéressant aussi: quelqu'un connait-il les deux pour donner son avis?

*un protocole dévoloppé pour Plan9: http://en.wikipedia.org/wiki/Plumber_(program)

Bah, tu peux dire tout ce que tu veux, quand les objectifs ne sont pas les même cela ne va pas changer grand chose:
1-les utilisateurs comme Linus (et plein d'autre) veulent un bureau "quasi-stable" i.e les nouvelles fonctionnalité c'est sympa mais uniquement si ça ne change pas trop la façon de faire, si ça n'occupe pas trop de ressource et si ça ne rend pas le bureau plus fragile.
2-ce qu'on voit avec KDE et Gnome, c'est que leurs développeurs (*) veulent faire des nouvelles choses avec des technos intéressantes.

Comme les objectifs des utilisateurs et des développeurs KDE&Gnome sont différents et que les utilisateurs ne payent pas ces développeurs, ce n'est pas surprenant que les utilisateurs 'à la Linus' ne soient pas satisfaits de ce que font les développeurs KDE&Gnome et qu'ils aillent voir ailleurs, heureusement qu'il n'y a pas que KDE et Gnome..

*: pas forcément tous, mais c'est le résultat vu de l'extérieur.

OK, rien j'y suis allé trop fort: SMEP est une avancée intéressante.

Quant aux débordements d'entiers tout bon processeur se doit d'avoir un bit d'overflow sur les opérations entiéres, c'est le cas des X86.

Sauf qu'avec les MIPS, tu peux avoir des trap en cas de débordement sur les opérations entières et si tu as le bon gout de programmer en Ada, ça correspond à une exception, tout ça quasiment gratuitement au niveau performance, contrairement au test des bits d'overflow..

sauf à créer des tampons pur-silicium autogérés ... encore une décennie ou deux soit patient ;-) !

C'est à ça que je fais allusion avec les segments, mais vu la difficulté de faire évoluer les jeux d'instructions des CPUs, une ou deux décennies ne suffiront probablement pas..

ils reviendront quant ça sera stable (kde4 à l'époque)

Je ne sais pas si on peut vraiment juger car peut-on vraiment dire que kde4 soit stable?

Un exemple: apparemment il y a eu intégration d'une réécrite de code pour Strigi/Népomuk entre la dernière "RC" et la livraison finale de KDE4.7,
ce qui veut dire 2 choses: les RC ne sont pas vraiment des RC et il y a du code peu testé dans une version dite stable;
alors je ne suis pas sûr qu'on puisse dire que kde4 soit vraiment stable..

Donc à mon avis, c'est trop tôt pour voir si les utilisateurs qui veulent du stable vont revenir..

Bin non justement dans ce cas présent, il est peu probable que la roue soit réinventée ce qui est dommage car les fabriquants de CPU ajoutent des millions de transistors pour gagner 0.0001% en performance, mais rien pour:
-détecter les débordements d'entier sauf si on a la chance d'avoir un MIPS.
-empêcher les écrasements de buffer..