Pinaraf a écrit 3682 commentaires

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)

Merci pour cette précision. Je pouvais pas deviner les détails, mais j'ai fait une simple extrapolation pour justifier ce phénomène...
La dépêche pourrait passer la modération sans réécriture complète ?

C'est passé en dépêche, et je pense que ça n'aurait jamais du passer la modération vu que cette dépêche était un copier/coller de l'article du journal le point, et donc, je pense, illégale.
Et donc la suppression rapide de la dépêche est tout à fait légitime et normale.

Problème de distrib.
Perso ma debian je l'ai vue changer de version de libc sans soucis.

Ça ne change pas la propagation immédiate du virus, non.
Par contre, si le virus a les droits admin, il peut plus facilement péter l'antivirus et se planquer un peu partout... Ensuite pour le nettoyer, c'est plus tordu vu que l'antivirus ne fonctionne plus. Et donc le virus restera sur la machine plus longtemps, et donc il se propagera plus longtemps.

Caesar 3 marche parfaitement bien dans Wine depuis des années...

Ah? Il mets aussi à jour mes logiciels? non.
Le noyau de Windows est plus gros que celui de Linux, mais ça revien au même : il ne touche pas aux logiciels tiers.
Tu piges rien toi...
Le noyau de windows, c'est trois/quatre fichiers : ntoskrnl.exe, hal.dll et d'autres que j'oublie. C'est tout. La mise à jour du noyau sous windows ne casse pas les pilotes parce qu'il y a une API et une ABI stables pour les pilotes, ce que Linus refuse catégoriquement (avec de très bons arguments)
Un service pack c'est bien plus gros qu'une mise à jour du noyau. C'est comme une mise à jour du noyau, de X, de la libc et d'autres librairies de base du système.
Il est normal que ça casse des choses, mais dans ce cas faut pas affirmer haut et fort que la compatibilité binaire est un point fort de windows.

Oui, les librairies.
Tout comme Qt, la librairie utilisée par KDE, est dispo pour l'embarqué sous le nom Qtopia (y'a des bonus).
Au passage, Gnome c'est GNU Network Object Model Environment, mais ça correspond plus du tout au projet actuel.

Quand tu passes à Linux 2.6.22, si tu le compiles pas toi même comme un glandu en mettant les options au pif, ça pose aucun problème de compatibilité pour les applications...

Donc c'est moins intéressant que ce que je pensais. Je pensais que l'OS pouvait utiliser ça comme un espace de stockage permanent pour certaines données, dont les données de boot. Avec un vrai système de fichiers (adapté à la mémoire flash quand même) et tout... Déçu... Je nie pas les avantages que ça peut avoir, mais j'espérais que ça soit mieux quoi (bon, pour l'instant le seul disque que j'ai vu hybride le prix m'a pas donné envie de l'acheter)

Ha c'est sûr que sur un écran avec une résolution de 800x480, tu vas lancer KDE ou Gnome.
Là dessus je mettrais jamais un KDE, plutôt un système basé sur Qtopia qui, ô surprise, est testé par TrollTech directement. (Tout comme KDE sur Solaris/Sparc et Linux/Sparc qui est testé par l'équipe de KDE par exemple)

Puis c'est sûr, pour une architecture embarquée genre ARM tu vas tester KDE et Gnome...

Oui, c'est très sérieux, ce n'est pas une blague.
E17 c'est pas un gestionnaire de fenêtres. Je te parle des librairies d'E17 et donc des applications écrites avec ces librairies (je me rappelle plus les noms de ces applications par contre)

Pour le boot, à l'avenir on pourra profiter des disques dur avec mémoire Flash intégrée et un système dans le style de fcache, avec tous les fichiers nécessaires au boot sur la carte Flash.
Par contre, une question que je me pose : sur de tels disques, comment se passe le partage avec un autre OS genre Vista ?

Ils ont eu leur heure de """gloire""" sur linuxfr et ailleurs y'a 2 ans environ. À l'époque, X.org venait de faire passer Composite dans sa branche stable, mais le seul composite manager répandu était basé sur XRender, très très mal accéléré par les pilotes. Et donc les ombres et la transparence c'était hyper lent avec X, alors que E17 c'était magique ça faisait de la transparence et des ombres rapides.
Bon avec Compiz/Beryl les gens ont compris que c'était pas X le problème, et que la transparence et les ombres dans E17, c'est du flan (dessiner les ombres sur le fond d'écran, ça ne fait pas un effet d'ombre rendant l'affichage plus agréable vu que des fenêtres se chevauchant n'auront pas des ombres qui se chevauchent)

Sinon, juste comme ça, dans E17 y'a la gestion du copier/coller maintenant ? Je suis sérieux hein, y'a un an, aux RMLL, le mec a découvert lors de la présentation qu'il n'y avait pas de copier/coller, et il a remarqué que c'était pas dans la liste des choses à faire et donc que ça n'allait pas être fait avant la sortie d'une version stable...