reno a écrit 3886 commentaires

Et as-tu cherché le module sur le disque?

Mais n'est ce pas une fonctionnalité des cgroup plutôt?

Alors on t'écoutes: dans ta liste de "problèmes" qu'est-ce qui dépend de l'implémentation, qu'est-ce qui dépend de l'API?

Je m'en fous royalement.

C'est ton droit, mais dans ce cas là tes critiques n'ont pas grande valeurs..

Mais est-ce que tu vas lui demander si Pulse Audio crashe, d'être capable de dire que ça vient des drivers ou du Kernel ou des drivers de la souris ?

Non, mais s'il me dit, ça vient de toto, il faut remplacer toto quand le problème vient d'ailleurs ou bien que corriger toto suffit, je ne vais pas prendre son commentaire au sérieux..

X est un super machin qui peut tout faire, sauf partager le tampon mémoire et l'adressage mémoire entre plusieurs GPU, ce qui est " un peu " ennuyeux depuis Optimus.

A l'heure actuelle oui, mais s'il y a suffisamment de monde pour changer l'implémentation, ça peut changer: http://www.phoronix.com/scan.php?page=news_item&px=ODA1OQ
Donc ce n'est pas un problème fondamental d'X mais un problème d’implémentation, si tu remplaces X par W et qu'une nouvelle fonctionnalité hardware apparaisse il n'y a pas de raison que cette nouvelle fonctionnalité soit prise en compte moins lentement puisque le problème à la base est le manque de développeurs..

Mais le centième des fonctionnalités de X seulement est utilisé par Gnome ou KDE, laissant l'utilisateur dans la merde quand son unique Xserver crashe

Alors
1) les fonctionnalités non utilisée de X sont là pour la compatibilité, j'ignore si elles réduisent vraiment la vitesse d'évolution de l'implémentation d'X, et toi aussi..
2) une chose que tu oublie (ignore?), c'est que parmi les vrai problèmes d'X il y avait la conception d'Xlib, donc pour palier à ça XCB a été créer sauf que Gnome(GTK) ou KDE(Qt) n'ont pas utiliser XCB..
Mais X est le seul coupable, bien sûr, les boucs émissaires c'est tellement plus facile quand on ne cherche pas vraiment à comprendre..

Quelqu'un peut il m'expliquer comment on meurt de mort naturelle lorsqu'on est dans un coma artificiel, et relié à des machines spéciales ?

AVC, coeur qui lache totalement?

Je ne dis pas que tu as tord mais les "machines spéciales" ne sont pas toutes puissante non plus..

Ça c'est encore un argument mal fichu dont je parlais plus haut.

Pour tout logiciel, il y a les problèmes d'API et les problèmes d'implémentations, X comme tout les logiciels à les deux, et il est important de distinguer les deux:
-les problèmes d'implémentations ne sont pas spécifiques à X, c'est juste qu'il n'y a pas beaucoup de personnes qui travaillent sur les couches basses GUI Linux, changer de couche basse ne résoudra pas ce problème.
-les problèmes d'API, là OK s'il y a un problème fondamental sur l'API d'X, il faudrait remplacer X.

Alors on t'écoutes: dans ta liste de "problèmes" qu'est-ce qui dépend de l'implémentation, qu'est-ce qui dépend de l'API?

Pour une distribution KDE, j'ai entendu du bien de PCLinuxOS.
Je ne l'ai pas essayé mais j'ai remarqué plusieurs choses:
-ils ont pris leur temps pour passer de KDE3 à KDE4
-dans KDE4 ils ont désactiver par défaut les nepomukeries (à un moment, je ne sais pas si c'est toujours le cas)
-j'ai vu un screenshot de KDE4: il était configuré par défaut pour ressembler à du KDE3.
Tout ça me fait dire que c'est une distribution qui préfère vraiment la stabilité ce qui est bien trop rare sur Linux (Ubuntu ne le fait pas bien qu'ils prétendent être une distribution "grand public")..

Pour Kubuntu, j'ai lu qu'ils ont un nouveau mode 'low fat' pour KDE qui a l'air intéressant.

Si tu n'es pas content de GNOME, ben tu es libre de reprendre les sources [coupé] Si ça ne se fait pas, c'est que personne ne considère que ça en vaille la peine.

Bah, non car changer pour un autre desktop a la place de GNOME demande beaucoup moins d'effort que de forker GNOME..

Hum, hum si tu vas par là, alors celui qui fait les meilleurs choix c'est Microsoft car ils ont l'avantage du nombre..

Je ne vois pas le rapport: ils n'ont pas fermer les sources sur KDE4 eux(*), contrairement au développeur d'OSSv4 (au départ).

*: Ça ne veut pas dire que je suis d'accord avec la méthode de développement de KDE, s'ils prétendent vraiment être un desktop stable, ils auraient du porter KDE3.5 sur Qt4 (mis à part Phonon qui était nécéssaire dés le départ car le son fonctionnait mal sur KDE3.5) puis ensuite faire des modifs avec précaution (et pas activer par défaut des outils instables).

Je ne parle pas de OSSv3 l'ancien mais de OSSv4.

Ben voyons, faire confiance à un gars qui a fermé les sources une fois, ça motive tout de suite à utiliser OSSv4.

L'un des objectifs de GNU Linux était de ré-implémenter un système Unix

Sauf que Linux n'est pas seulement GNU, c'est aussi Android, GoboLinux (qui a une hiérarchie de fichier plus claire: /Programs /Users /System /Files /Mount /Depot), NixOS (une distribution avec un gestionnaire de paquet "purement fonctionnel").
Si tu n'aimes pas les innovations apportées par Lennart, c'est simple: utilise une distribution qui ne les utilise pas..

Il y a Wayland dont c'est le but, il me semble.

Pas vraiment: Wayland fournit seulement un système d'affichage local, alors que X a aussi la "transparence réseau" donc Wayland ne fournit qu'un sous-ensemble des fonctionnalités offertes par X.
Pour remplacer X par Wayland, si tu veux vraiment avoir l'équivalent d'X alors tu peux soit:
1- faire tourner X au dessus de Wayland.
2- soit utiliser un autre protocole réseau.
Le problème avec (2) étant bien sûr qu'il y aura probablement des solutions différentes avec chacune son lot de bugs..

Je remplacerais "le remplacement de X" par "l'évolution de X", ceux qui veulent tuer X ont quasi-systématiquement des arguments mal fichu..

Si.. D'ailleurs si tu avais cliqué sur le lien que j'ai fourni tu aurais vu qu'avant ça s'appelait LinuxBIOS.

Il a commencé avec sparse: ajouter des annotations quelque part ça revient à modifier le C..

Les outils Adobe c'est réservé à une élite qui a les moyens, et ils se situent plutôt chez Apple ou Microsoft donc pas étonnant qu'on ne les trouve pas sur Linux.

Tu généralises.. Framemaker ce serait très sympa d'avoir ça sur des stations Linux.

Ça existe déjà un BIOS libre: Coreboot, mais bon je ne connais aucun vendeur de PC qui l'utilise alors..

Intéressant: je ne connaissais pas, curieux qu'il n'y ait pas une extension/un outil de FF qui utilise ces fonctions pour donner le % de CPU utilisé par chaque onglet..

J'ai l'impression que ta réponse n'en est pas une, explique moi comment ce que tu propose fournis a l'utilisateur un moyen simple d'identifier quel onglet utilise le CPU?

L'objectif pour l'utilisateur c'est d'avoir un firefox véloce pas d'avoir des processus en plus.

Autant je suis d'accord pour l'objectif, autant il va falloir que tu m'expliques comment obtenir cet objectif sans les processus.
Partons du cas suivant: un site web codé n'importe comment à du JavaScript qui bouffe une grosse quantité de CPU/RAM, comment faire que FF reste "véloce" (*)?
Note que même Chrome ne résous pas directement le problème, mais il donne un moyen simple de voir quel est le site web qui déconne, ce que FF n'a pas.

*: NoScript n'est pas une réponse acceptable dans le cas présent.

NT

Moui enfin des excuses pour quoi exactement?
Quand Windows a conquis le monde, c'était un système tout pourri par rapport à Unix, donc même si les micro-noyaux ont des avantages techniques réels ce n'est pas évident que ce soit suffisant pour remplacer l'existant..
MINIX ce n'est pas les micro-noyaux, il y a L4, Mach, QNX sont des exemples de micro-noyaux ayant un succès commercial..
seL4 a été "vérifié" ce que ne sera jamais Linux, je ne dis pas que c'est la panacée mais s'il est utilisé ce sera intéressant de voir si cela se traduit par un bénéfice en pratique.

Pas digérer le succès de Linux OK, mais "Il en veux aussi à la GPL" là je trouve que tu l'invente ça: il préfère la licence BSD, c'est différent..

L'informatique est une perpétuelle réinvention: 1978 c'est même plutôt tard pour les machines virtuelles, cf par exemple le P-code vers 1966-1973..

Ses réponses sur les capabilities et seL4 me paraissent assez floues..
Le problème des bugs dans le matériel concernent tout le monde, d'ailleurs il me semble avoir lu que l'IOMMU était désactivé a l'heure actuelle sous Linux car trop buggé: pas facile d'assurer une fiabilité/sécurité quelconque si un pilote de périphérique peut écrire partout dans la RAM..