reno a écrit 3881 commentaires

Et ouais, comme quoi ya pas que les systèmes à licence BSD qui se voient obligés de réimplémenter des choses parce que la licence de la solution proposée ne convient pas.

Tu viens de te réveiller? Parce que c'est pas nouveau: NVidia --> Nouveau, XFree --> X.org, etc.

Non mais ce qu'on dénonce c'est que ce sont des accords non "naturels". B est lié par l'accord alors qu'il aurait aimé ne pas l'être.

Moi aussi je veut le beurre, l'argent du beurre et le sourire de la crémière, mais désolé je dois faire un choix.

Dans la société actuelle malheureusement on n'a pas choisi la forme de l'accord

Pas le choix? N'importe quoi: tout le monde a le choix de créer ou pas, et si tu crée tu as beaucoup de libertés pour définir les termes de l'accord, si tu es un client tu as le choix de consommer ou pas..

si B n'a pas intérêt à ce qu'elle reste secrette, pourquoi ne la diffuserait-il pas ?

Et bien si B a un accord avec A, il violerai cet accord, déjà ça fait un argument (intégrité morale de B a respecter son accord avec A versus son intérêt a diffuser le secret).

Et puis suivant le cas, ça peut avoir des conséquences très diverses: allant de recevoir des récompenses à être mis en prison (secret d'état), alors je ne sais pas si tu peux en déduire quoi que ce soit de ta métaphore..

C'est comme ça que le système actuel veut se justifier : l'auteur a pris 2 ans pour l'écrire, donc c'est un gros investissement, et il faut qu'il puisse en vivre.

Ce n'est pas la seule justification: quand il rend disponible son oeuvre, il le fait avec des conditions, en théorie tu as soit le choix d'accepter, de refuser ou bien de négocier de meilleures conditions dire qu'on peut ignorer ses conditions parce qu'on peut le faire me parait très litigieux.

On ne parle pas de la même chose, ce que j'appelais "shared GPU memory", c'est que dans Wayland ton application fait son rendu directement dans la mémoire du GPU puis passe une référence vers ce buffer (qui reste donc dans la mémoire du GPU) au compositeur, donc le client et le compositeur se partage la mémoire du GPU.

Le support du multi-GPU par Wayland c'est effectivement un effet collatéral, un bénéfice de la jeunesse de Wayland.

C'est une histoire intéressante, mais ça n'a strictement rien a voir avec la propriété intellectuelle, un (gros) constructeur de voiture pourrait faire exactement le même chantage.
La seule chose que ça montre c'est que les entreprises qui sont dans le médicale sont là pour faire de l'argent, bon ça ce n'est pas une surprise..

Le problème c'est que tu ne peux pas avoir une interface a la fois suffisamment simple pour cette personne et suffisamment "puissante" pour un utilisateur normal..

Ceci dit il y a pire que le click-droit, le shift click-droit!
Si, si, ça existe Microsoft l'a inventé, beurk! Je serais curieux de connaître le pourcentage d'utilisateurs qui connaissent ça..

La propriété intellectuelle ne se limite certainement pas au droit d'auteur,

Je ne dis pas le contraire, mais note que le titre est "Droit d’auteur, quel héritage ?".

Et il vaut mieux traiter un seul sujet correctement que d'en traiter plusieurs mal!

Petite question : En tant qu'utilisateur, est-ce qu'il y a une différence majeure entre wayland et Xorg ?

Une différence majeure: X est présent sur tout les Unix, wayland ne sera pour le moment disponible que pour Linux.

Sinon dans certains configuration (rendu de la fenêtre entièrement par l'application) Wayland devrait permettre de redimensionnement une fenêtre sans "tearing", pour certains c'est une différence majeure (ils doivent passer leur temps a redimmensioner leurs fenetres!!), note que cette configuration n'est pas sans inconvénient potentiel: si une application est occupée, elle peut mettre du temps à répondre a une demande d'iconification ou de fermeture..

Note que la configuration rendu client uniquement n'est pas celle choisie par le projet KDE: http://blog.martin-graesslin.com/blog/2011/08/kwin-at-desktop-summit/

Il fait bien plus que ça, ce n'est qu'un effet collatéral.

Hum, pour moi c'est la raison principale pour laquelle Wayland devrait être plus performant qu'X (l'autre raison étant la fusion des serveur, gestionnaire de fenêtre et compositeur dans un même processus), alors appeler ça un effet collatéral me parait "un peu court".

Par exemple, il était prévu que chaque périphérique ait son propre pilote, maintenant tout le monde utilise evdev.

Oui, X (ré)implementait beaucoup de chose pour maximiser la portabilité, à l'inverse Wayland est actuellement Linux-only.
Pas sûr que je considère ça comme un point fort pour Wayland!

On arrive aussi à des situations où les développeurs d'applications doivent utilisé une fenêtre de X pour chacun de leur widget dans la fenêtre (pour éviter que toute la fenêtre soient redessinée à chaque modification du widget).

Il y a une extension XDamage pourtant?

Note bien que personne ne dit qu'X est optimal, par contre passer de X11 à Wayland plutôt que de faire un X12, hum: on n'a pas jeter X quand l'extension "shared memory" a été créer, je ne vois pas en quoi l'ajout de "shared GPU memory" (ce que fait Wayland en fait) serait fondamentalement différent..

Quelqu'un m'explique que viennent faire ici les brevets pour les médicaments(*) dans un article intitulé "Droit d’auteur, quel héritage ?".

*: qui est un problème assez complexe: il y a le coût de la recherche aussi pas seulement les coûts de production..

Ton lien vers SPICE est mauvais: http://en.wikipedia.org/wiki/SPICE_(protocol)

Ensuite je ne vois pas en quoi un protocole lié à la virtualisation est si intéressant que ça.. Est-ce possible d'utiliser SPICE sans virtualisation?

De toute façon le protocole X11 a déjà du mal avec les applications modernes qui utilisent de l'OpenGL et des animations dans tous les sens.

Bah, est-ce un problème d'X11 ou bien est-ce un problème plus générique?
N'importe quel affichage distant aura des problèmes avec de la vidéo ou un jeu à 60 FPS..

As-tu des exemples en LAN ou X11 marche mal mais un autre protocole marches bien?
X11 n'est pas fait pour le WAN, il y a NX/FreeNX qui est prévu pour ça mais j'ignore ses forces/faiblesses par rapport aux autres..

tout le monde y gagnera

Sauf ceux qui utilisent le coté transparence réseau d'X: au mieux ils auront juste une petite perte de performance (serveur X client Wayland), au pire ils beaucoup de problèmes: cas où les toolkits virent le support d'X(*) avant qu'un remplaçant pour la transparence réseau arrive.

*: coté compatibilité les logiciels libres ce n'est pas toujours leur point fort.

Pour moi, ça devrait être exactement la même chose qu'avec X et KMS (d'ailleurs il me semble que si tu n'as pas KMS tu n'as pas Wayland), pour l'input je ne vois pas trop ce que ça va changer au niveau temps de démarrage!

Je ne suis pas sûr de voir la différence au final du point de vue du lancement.

Il n'y en a pas de mon point de vue, mais je pense qu'il y a beaucoup de gens qui en ont tellement marre des problèmes d'IHM actuels qu'ils ont décidé que X c'était mal (même quand les problèmes sont causés par les toolkits ou par les pilotes) et espèrent que Wayland va résoudre tout les problèmes.
Quelque chose me dit qu'ils vont être bien déçus..

Pour répondre à Adrien, si c'est bien fait un utilisateur ne verra pas la différence à part une amélioration de la fluidité en local si tu as un bon pilote de carte graphique. Bon comme toute nouveauté, il y a un risque d'avoir des bugs a cause de l'introduction de nouveau code bien sûr.
J'imagine que dans certains cas (embarqué) une distribution peut choisir de ne pas mettre la compatibilité X et là il y aura un impact oui: plus d'export display qui fonctionne et utilisation possible uniquement des applications utilisant un toolkit porté sur Wayland.

OK pour les meilleurs performances (en local, quand tu as un pilote OpenGL de bonne qualité pour ton matériel et un toolkit qui supporte Wayland), mais un "démarrage plus rapide"??
La je ne vois pas..

Sauf que le monsieur du haut ne dis pas tout: Microsoft va créer une "mini-plateforme" au dessus de ARM pour réduire le coût de test cf http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx

Donc la question n'est pas si on peut "porter Linux sur ARM" mais peut-on porter Linux sur cette mini-plateforme?
Le problème ne sera pas que technique..

Tout Internet passe maintenant les ports 80 et 443

Bientôt que par le port 80: l'Iran a bloqué le HTTPS, je me demande combien de temps il va falloir pour que des gens fassent du HTTPS encapsulé dans l'HTTP?
Le décompte est lancé !

Il y a bloquer les adresses IP aussi, pourquoi c'est pas dans la liste?

Oui et ça montre bien les problèmes de la décentralisation totale beaucoup de forums étant spammé a fond..

Plein de monde parle de cette « intégration de KDE », mais c’est quoi au juste ?

Pour moi c'est plutôt de peaufinage dont on parle en fait:
1) Prendre une "bonne version" (en regardant les retours des utilisateurs) et s'il y a besoin intégrer des corrections.

2) Dans le même esprit: désactiver les machins pas encore stable activé par défaut par le projet KDE (jusqu'à assez récemment Népomuk en était un bon exemple).

3) Remplacer les applis KDE par d'autre par défaut quand celle de KDE sont "moins bonne" (un cas classique étant KMail --> Thunderbird) et si possible s'assurer que ces applis fonctionnent "pas trop mal" avec KDE.

Une "petite" différence: elle a choisi de contribuer volontairement sans gain financier en retour.

Serait-il, par exemple possible d’avoir une VM avec une debian pour la partie travaille, une partie gentoo pour l’accès au web, une BSD pour la partie serveur http de test ?
Le tout s’affichant sur un même serveur X ?

Oui mais note qu'il y a un agent de qube qui doit fonctionner sur chaque VM, cet agent servant de pseudo-gestionnaire de fenêtre et échangeant les données avec le "vrai" serveur X utilisé, je ne sais pas sur quel(s) OS cet agent a été porté/testé..

En tout cas, c'est comme ça que j’interprète le chapitre 5.3 de http://qubes-os.org/files/doc/arch-spec-0.3.pdf

Euh pour le son, le monsieur te dis qu'il a utilisé http://opengameart.org
Les icones des différents desktops ont été souvent créer par des bénévoles..

Créer des graphismes pour un jeux, peut-être que le fait que le jeux peut être monétisé assez simplement (même un jeux libre) rébute les graphistes?