Pinaraf a écrit 3671 commentaires

Solid, plasma, kross, le développement des widgets oxygen, phonon, strigi et tout un tas d'autres trucs, ils n'étaient pas obligés de le faire tout en même temps.
Ils auraient pu commencer par ne faire que porter les API de KDE à QT4. Puis implémenter plasma et toute la clique de façon incrémentale.
Non. Parce que en portant l'API uniquement, ils auraient gardé des choses inutiles genre arts, et lors de l'introduction de phonon par exemple ils se seraient retrouvés avec un "conflit" entre phonon et arts.
Pour oxygen, ça a été fait principalement par des artistes, et le thème ne commence à être développé que maintenant en fait.
Pour solid par contre, c'était pas indispensable certes, mais autant en profiter vu que ça va aider des applications diverses et réduire l'effort de portage pour les applis (certaines disparaissant purement d'ailleurs).
Pour strigi, c'est pas une nouveauté de KDE4, c'est plutôt nepomuk la nouveauté. Bon, là par contre je suis d'accord, lui il irait bien dans KDE 4.1 de mon point de vue, mais c'est trop tard.
Pour kross, même problème : laisser les gens utiliser directement KJS dans KDE4.0 puis les faire passer à Kross après au petit bonheur la chance ?

On parle plus de fonctionnalités là, on parle d'API. Ça n'a rien à voir au niveau des contraintes.

C'est ta machine, sur mon konqueror je vois très bien les captures d'écran.

Sauf qu'un grand changement peut être inévitable.
Pour KDE 4 il l'est : améliorations importantes de l'API, suppression de tout ce qui était devenu inutile au fil du temps (arts par exemple)... Alors certes, c'est un grand changement d'un coup, certes ça prend du temps, mais des changements incrémentaux ne peuvent pas marcher tout le temps si tu as dans tes objectifs la compatibilité d'API et d'ABI.

Et tous les geeks de KDE sont occupés à bosser, alors que les geeks de Gnome ça fait une paire d'année qu'on attend qu'ils bossent plus que 2 heures par version de Gnome...

Houlala tu te fatigues beaucoup toi...
Tu supprimes tes cookies et ça suffit pour revoter.

Citons OSNews (ainsi que de nombreux experts) :
Hence, these reports are not proper measurements of security - they are just that, a tally of fixed vulnerabilities. Any conclusions like "x is more secure than y" cannot be drawn from this data set.
Traduction (à peu près) :
Ainsi, ces rapports ne sont pas des mesures valables de la sécurité - ils comptent simplement les vulnérabilités corrigées. On ne peut pas tirer de ces données une conclusion comme "X est plus sécurisé que Y".


Alors bravo pour le lancer de trolls, mais sache que pour un bon lancer de troll, il ne faut pas mettre de sources (même sans liens).

La gestion de certains trucs graphiques dans le noyau ça peut déjà aider à retourner dans un état potable sans X, puis relancer X derrière sans soucis.
Sinon, pour GLX et XVideo, ça m'étonnerait que ça soit faisable. Il faudrait au minimum faire une sauvegarde de la mémoire vidéo utilisée par un programme, la restaurer de la bonne façon, s'occuper des shaders et de toutes les joyeusetés disponibles... Bref, truc bien lourd.

Ce qui c'est passé avec Novell et Xgl/Compiz, c'est que Novell a décidé d'embaucher le développeur de Xgl et de faire bosser sur un dépôt interne jusqu'à ce que le produit soit présentable, et le présenter avec autant de force marketing que possible.
Novell n'est pas à l'origine de Xgl et Compiz.
Sinon, pour les plantages, y'a des trucs qui rendent ça impossible ou presque :
1- les applis utilisant GLX ou XVideo (ou tout ce qui fait du rendu direct) : à mon avis Xmove marche pas pour ça et marcherait pas pour ça avant un bout de temps...
2- l'absence de gestion des modes de l'écran dans le noyau pour lui permettre de remettre la carte graphique dans un état potable avant de relancer X.

(Le deuxième problème est en cours de résolution, mais ça va prendre un certain temps...)

Les tests de Konqueror et Safari sont incomplets pour l'instant :/

* Upstart (gros morceau ça)
Mouais, il serait temps qu'ils tiennent leurs promesses à ce sujet. Ils avaient promis de réécrire tous les scripts d'init pour profiter pleinement d'upstart, c'est loin d'être le cas.

* Implémentation du sudo par defaut
Est-ce une bonne innovation ? J'en doute fortement. Personnellement ça m'emmerde plus qu'autre chose quand j'administre la kUbuntu "familiale" : je suis obligé de me logger sur mon compte utilisateur puis de faire sudo pour administrer (donc 2 commandes : su + sudo, alors qu'une suffit sur toutes les autres distribs).

Non, je n'ai pas dit qu'il ne me plaisait pas.
J'ai dit :
Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...

On le refait en version bien diluée pour aider à la compréhension :
Et pour quelles raisons une personne pourrait décider de ne pas contribuer à Qemu ? Parce que le code de Qemu peut ne pas plaire à cette personne, parce que la structure de Qemu peut ne pas plaire à cette personne, parce que certains choix techniques effectués dans Qemu peuvent être à l'origine de désaccords avec d'éventuels contributeurs...

Peut être que sur notre vieux continent on n'a pas l'esprit "Microsoft c'est une entreprise américaine, faut la défendre", on a pas une allergie au communisme (les préjugés Linux = communisme ont la vie dure, je crains que ce ne soit facile de trouver des gens qui y croient et continueront à y croire pendant encore longtemps), on n'a pas eu dans la gueule des belles campagnes Get the facts (je l'ai vue que sur des sites US, pas sur des sites français par exemple)...

C'est pas parce que ton site est compatible Firefox qu'il respecte les standards.
Firefox a, comme tous les navigateurs, un "quirk mode" pour interpréter du code pourri.
De plus, si tu fais un site avec une identification du navigateur pour balancer du code HTML ignoble pour IE ou du XUL pour Firefox, ton site sera pas plus respectueux des standards.

Enfin, un autre "détail" : ce qui compte de plus en plus, c'est le Javascript, et là c'est bien pire que le HTML...

Hum, pas si sûr que ça.
De plus tu sépares comment la fonction test du reste de l'outil ?
Sans oublier que Sax et drakxtools ont déjà la fonction test depuis longtemps.

Et SaX2, l'outil de Suse, qui est loin devant drakx11 ?
Il permet de configurer des systèmes avec plusieurs écrans, des tablettes graphiques, des écrans tactiles, il gère à peu près toutes les options des pilotes...

L'ai-je jugé ? Non.
J'ai simplement donné des raisons pour lesquelles de nombreux projets pourraient être créés (et même sont créés) plutôt que de contribuer à qemu.

Ils vont même encore plus loin que ce que tu dis.
Je cite :
This feature is actually Ubuntu-specific at the moment, though other distributions are sure to adopt it soon.
Traduction : "Cette fonctionnalité est actuellement propre à Ubuntu, mais les autres distributions vont surement l'adopter rapidement."

Même kUbuntu a certaines (pas toutes, certes) des fonctionnalités qu'ils ont mis dans leur truc.

Finalement, à quoi sert le test Acid2 ? Il ne teste que quelques points spécifiques de différentes normes, rien de plus.
Ce n'est pas un test exhaustif de CSS, HTML ou Javascript.
Il n'existe pas, il me semble, d'outil permettant de tester de manière précise et exhaustive le niveau du support Javascript dans un navigateur. On peut certes trouver des benchmarks, mais rien de plus :/
Connaissez vous de tels tests, qui pourraient aider à justifier le non support de tel ou tel navigateur (généralement, c'est juste la flemme) ?

Sinon j'ai suppose que tu n'aimes pas trop QEMU a cause de cette phrase : "Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords..."
Attention, je crois, vu la note de mon commentaire, que cette phrase a porté à confusion : je voulais dire par là que la contribution à un projet libre est conditionnée à un point de vue personnel, et qu'on peut souvent réinventer la roue juste par désaccord avec le projet originel.
J'ai pas assez regardé le code de Qemu pour porter un jugement à ce sujet.

Sinon, pour le BIOS, il me semble que le BIOS utilisé par Qemu et Bochs est un BIOS libre, codé spécifiquement pour les émulateurs. Pareil pour le BIOS VGA... Par contre, comme ces BIOS sont liés à une certaine organisation derrière, de nombreuses similitudes seront obligatoires entre les projets les utilisant pour la carte graphique par exemple.

C'est surtout que dans la série des KDE 3.5, y'a eu beaucoup de "corrections de bugs" sur Konqueror (émuler tel comportement de Gecko, contourner tel problème vu sur gmail...) uniquement pour faire marcher des bousins comme gmail.

Désolé, j'avais pas fait gaffe aux noms. C'est surtout après l'auteur de ce commentaire que j'en avais : http://linuxfr.org/comments/859230.html#859230
(La précision concernait cette phrase : Il n'empeche que le code de QEMU/Bosh est reutilise dans la majorite des solutions de virtualization open source actuelles)
Dire que le code de VirtualBox pour les pilotes est profondément fondé sur le code de Qemu me semble exagéré, VirtualBox a ajouté des fonctionnalités (dans le cas du pilote graphique, y'a la possibilité de configurer la VRAM disponible, et j'ai vu dans leur bugtracker un travail effectué sur le support de la 3D, dispo uniquement avec un patch un peu "bâtard" pour Qemu (patch non intégrable dans Qemu donc))

Au passage, où as-tu vu que je n'aime pas Qemu ? Je l'utilise régulièrement, probablement plus que VirtualBox (qui refusait de marcher jusqu'à peu sur mon ordinateur portable, comme VMWare ou Xen. Qemu était le seul à marcher)

Pourquoi devrais-je avoir des exemples ?
Je n'ai pas regardé le code de Qemu, mais personnellement je ne contribue pas à un projet dont le code ne me plaît pas. Et un code me plaît ou non selon des critères qui me sont propres, chacun voit le code à sa façon.

Correction importante : du code de Qemu et/ou bochs est réutilisé.
Ça veut pas du tout dire la même chose.
Virtualbox n'a pas grand chose à voir avec Qemu.
Au passage, si tu fais un grep sur le code source de VirtualBox, c'est du copyright 2003 ou 2004. J'ai vu un fichier avec un copyright 2005. C'est du code de Qemu qui marche et qui n'a simplement pas besoin d'être modifié. Pourquoi réécrire le code qui marche quand il existe ?
Et pourquoi ne pas contribuer à qemu ? Parce que son code ne plaît pas, parce que sa structure ne plaît pas, parce que certains choix techniques peuvent être à l'origine de désaccords...

Virtualbox issu de qemu... Un "peaufinage" ?? Woaw, ça c'est de l'information.
Sources ?
Si tu regardes les informations sur l'organisation du code source de Virtualbox ( http://virtualbox.org/wiki/Source_code_organization ), tu découvres que du code de Qemu est utilisé certes, mais à un seul endroit :
src/recompiler/ contains a recompiler (emulator based on QEMU) for a few situations within VirtualBox. Essentially, all guest code runs natively on the hardware. The recompiler, however, steps in as a fallback when guest code disables interrupts and VirtualBox cannot determine when they will be switched back on; for single instruction execution on faults; for real-mode code (e.g. BIOS, DOS, operating system startup).

En clair, qemu n'est pas du tout à la base de Virtualbox, c'est utilisé uniquement à un endroit bien précis. Tout le reste c'est fait par Virtualbox et ça n'a rien à voir avec Qemu.

Les librairies Gnome, c'est une sous partie de Gnome.
Tout comme les librairies KDE sont une sous partie de KDE. Et il me semble que les librairies de KDE4 marcheront avec QTopia... (enfin un truc bien avec Qt c'est que à lui tout seul il est déjà extrêmement complet)