et une petit mention speciale "c'est le roquefort qui dit au camembert: tu pue"
http://apple.slashdot.org/article.pl?sid=09/02/21/1318253

Ballmer trouve qu'ils abusent chez apple pour leur politique ferme sur les iphones.

Mon avis :

1) c'est une connerie de faire yet another linux distribution.
2) vu comment on est dirigé à l'heure actuel, je doute qu'un os national soit vraiment une bonne idée.
3) chaud les exemples Après la Russie et Cuba, la Chine, la Corée du nord et la France !

1/ je prefere yet another distribution et avoir des gens payer pour avoir du support de driver et des corercteurs de bug que la meme somme d'argent partent en license windows.

2/ Tant que tu n'es pas oblige de t'en servir ce n'est pas tres grave. Tu ne veux pas de SarkOS qui redirige tout tes mails a l'elysee ?

3/ En meme temps, ce sont des pays qui luttent contre la dependance commercial. Le logiciel libre a toujours eu un cote un anarko/gaucho. Mais j'espere que l'image va changer. (Il y a meme pas 6 mois on m'a refait le coup: quand j'ai dit a quelqu'un qu'il devrait passer a Linux, il m'a repondu qu'il n'etait pas anarchiste. Comme quoi la desinformation marche bien des fois... (je pense entre autre au documentaire nom de code linux qui a ete pondu par la arte dans lequel le journaliste essaye de faire dire a tous les interviewer que s'ils developpent linux c'est pour abattre le grand capitaliste Microsoft. sisi, je vous jure et payer avec nos impots.) )

Je pense que seul les habitue liront le thread en entier, donc je met ce post ici plutot que dans un topic a part.

Il y a aujourdhui un post 'ask slashdot' a propos des distributions a mettre sur eeepc. La discussion est interessante. On voit que la plupart des distribs principales fonctionnent bien (DebianEEEPC, eeebuntu, ubuntu-eee qui n'est pas la meme). Quelques problemes par ci par la, mais rien de bien grave. On trouve aussi un lien sur l'utilitaire wicd qui sert a gerer les connexions wifi plus simplement que l'horrible network manager.

http://ask.slashdot.org/article.pl?sid=09/02/24/1544229

Sankukai : Inversement, si xorg devait tourner ailleurs qu'en ring 3, il ne serait surement pas le trou de sécurité immonde qu'il est maintenant. De toute façon, tout le monde sait que la solution n'est pas de faire un noyau monolithique. Avec un noyau micro ou hybride, tu peux à la fois avoir la base pour la gui au niveau "système" et en ring 3.

À partir du moment où un programme a une interaction directe avec l'utilisateur, je pense que c'est du suicide de le coller avec les plus hauts privilèges, même s'il est programmé et audité par les paranoïaques de chez OpenBSD. :p
On peut imaginer les dégâts qu'un script « à la » envy malveillant qui irait taper dans les piles de n'importe quel thread entre les mains du joe (geraldo ?) moyen. Ça serait foutrement plus dangereux qu'un bon vieux black screen of death suite à un foirage de la conf. :p

Après oui je suis convaincu qu'un kernel avec un design hybride ou micro est ce qu'il y a de mieux pour la stabilité et la sécurité du système. Après pour les perfs, ça se discute (quoi qu'avec les bécanes actuelles…).

Mais bon sur un Linux ou un BSD, je suis content que la gui n'ait pas intégré le noyau.

Perso, je pense (peut-être complètement à tort) que le gap entre le ring 0 et le ring 3 est sous-exploité. La couche gui est suffisamment riche pour avoir son niveau à elle toute seule d'ailleurs (le ring 2 des x86). Je sais bien que ce n'est pas faisable sur toutes les archis, mais vu que les gens ont du temps à perdre dans la conception de machines virtuelles, pourquoi ne feraient-ils pas plus d' "optimisation" pour xorg sur x86 ?

Moi il y a (à froid) deux trucs qui me dérange dans l'absence de la notion de gui dans le noyau :
1) l'absence totale de cohérence au niveau de l'apparence. Là dans mon bureau de xmonad, j'ai firefox (gtk), xpdf (xlib) et ark (qt). Chacun de ces programmes satisfait (plus ou moins) à mes besoins du moment. Mais bon sang, que de disparité dans l'apparence des fenêtres...
2) le dilème du layout de clavier. Quand tu arrives à avoir un clavier en azerty en mode console, en qwerty au niveau de gdm, et de nouveau en azerty un fois logué, c'est le summon du n'importe quoi. J'ai jamais rien dit d'autre que "azerty" dans ma vie, chose que j'ai dite à l'installation de cette debian... qu'est-ce qu'on vient me faire c***r avec du qwerty...

«Après pour les perfs, ça se discute» c'est tout discuté. Le seul micronoyau qui a des perfs de merde, c'est le noyau de hurd (gnu mach). Des noyaux comme L4 ont des perfs raisonnables. Et puis comme tu dis, avec les machines actuelles...

Effectivement sur les architectures le permettant ça serait une bonne solution de faire tourner le serveur graphique à un niveau de privilège intermédiaire. D'autant que les architectures destinées à faire tourner un serveur graphique ont généralement plus de deux niveaux de privilèges.

En ce qui concerne ton point 1, à moins de verrouiller complètement l'API de programmation de ta gui en ring 2 (par exemple), t'auras toujours des petits malins pour réinventer quatorze fois la roue et te caler une couche en espace utilisateur basée sur ton serveur graphique en ring 2. Y'a qu'à voir le port de KDE sous Windows...
Et du coup t'auras toujours des gens pour programmer des applis d'excellente qualité basée sur des toolkits de merde.

Pour le point 2, moi aussi je trouve ça complètement aberrant ! Même avec un serveur graphique en espace utilisateur ce genre de choses ne devraient pas arriver !
Le clavier est tout bêtement exporté en espace utilisateur via le système de fichier (/dev/kbd par exemple), je ne comprends absolument pas pourquoi il n'y a pas une couche d'interprétation commune à toutes les interfaces pour gérer l'interprétation des keycodes dans /dev/kbd de façon uniforme. Pareil pour la souris ! Pourquoi faut-il un moused/gpm *et* un xf86-input-mouse ?!?
Pour moi c'est une erreur de conception qui va au-delà de l'intégration ou non de la gui dans le noyau.

En ce qui concerne les perfs de L4, c'est vrai... mais il faut voir la non portabilité des hacks qui permettent au système d'être performant :
-- L'usage de la segmentation (présente sur pas grand chose d'autre que l'architecture x86) pour gérer de multiples processus dans un même espace d'adressage et donc économiser sur le flush du TLB et le changement de contexte
-- L'usage des messages de type « rendez-vous » qui passent par les registres permettant à deux processus de communiquer par simple changement de contexte sans passer par de la sauvegarde de registre ou l'usage de la mémoire pour stocker des infos. Ça semble extra mais en contexte multiprocesseur le passage de message n'utilise qu'un seul processeur, l'autre étant idle en attendant...

'fin bon le débat n'est pas là, le design micro induit forcément des contraintes mais il est tellement plus sympathique !

«En ce qui concerne ton point 1...» tu marques 3/4 de point là (et oui, je suis dur en affaire mon bon monsieur ). Ce que tu dis est (malheureusement) vrai. Cela dit, en ajoutant une difficulté supplémentaire, tu peux espérer freiner un peu le malin.

Pour le 2, je suis d'accord. De toute façon, le manque de conception solide se fait sentir un peu partout dans linux. (ce n'est qu'un semi-reproche, l'excès de conception n'aurait pas permis l'expansion qu'a connue linux).

Bref, c'est quand qu'on le fait notre os ?

Je suis un peu a la masse question noyau. Mais je pense que plus on met l'interfacage graphique loin des privileges mieux c'est. Je pense que descendre le serveur graphique dans les couches du noyaux peut permettre d'ameliorer les performances, mais pas la coherence de configuration du systeme.

je plussoie le "le manque de conception solide se fait sentir un peu partout dans linux". Mais en meme temps, c'est pour ca qu'on l'aime

D'autant plus qu'une fois que l'on a poser une interface commune a un meme probleme, on se retrouve confronte a des probleme de compatibilite. On ose plus changer les interfaces de peur de faire une connerie. Alors si tu as besoin d'information en plus, tu va avoir besoin de rajouter une extension "non standar" a l'interface ou de t'interfacer completement differement.
Dans les deux cas, tu vas obtenir a nouveau un comportement non homoegne.

Cela ne voulant pas dire qu'il ne faut pas factoriser les interfaces a posteriori. Mais pour ne pas perdre les autres, en attendant la transition, tu laisses les deux en paralleles et ca fout un bordel monstre. C'est en parti le probleme de pulse audio.

"Mais je pense que plus on met l'interfacage graphique loin des privileges mieux c'est. " ça c'est clair.

"Je pense que descendre le serveur graphique dans les couches du noyaux peut permettre d'ameliorer les performances" ça c'est moins évident. J'ai l'impression que ça permet surtout de se dispenser de hacks de gorets pour avoir ces performances. Le gain reste néanmoins plus qu'intéressant.

"mais pas la coherence de configuration du systeme. " et pourquoi pas ? Avoir une couche de gui fonctionnelle sur laquelle la seule chose possible serait d'appliquer un thème selon le goût de l'utilisateur ne me paraît être ni un luxe, ni surréaliste... (comprenez par là : même sous windows 95, on avait ça )

Sankukai a souligné le problème de doublons dans les drivers pour les périphériques de bases. Moi, j'avais en tête une gestion correcte et *propre* des événements "physiques". Un programme vérolé ne doit pas pouvoir se transformer en remote keylogger. Obtenir une telle garantie ne me semble pas réalisable avec une gui (quasi-)complètement en userland (et même en systemland en ring 3 en fait, j'émets de gros doute).

"des probleme de compatibilite" parce que le passage de KDE 3 à KDE 4 n'engendre aucun problème peut-être... Moi, je suis d'avis que lorsque les choses marchent bien (c'était le cas pour à peu près tout dans la sarge sauf le wifi), on doit commencer à essayer de figer ces choses, tout en continuant des développements alternatifs en parallèle (dans des distributions pour barbus comme gentoo). La xlib, c'est bien naze, alors on a fait gtk et qt... très bien. Quelqu'un ici peut-il me donner une différence significative entre gtk et qt ? Pour moi, c'est juste deux trucs qui font la même chose, et presque de la même manière en plus... Pourquoi on ne flanquerait pas l'intersection des gtk et qt dans une couche plus bas ? Pour moi, on arriverait justement à «Avoir une couche de gui fonctionnelle sur laquelle la seule chose possible serait d'appliquer un thème selon le goût de l'utilisateur»
Bien sûr, c'est facile de dire tout ça, et beaucoup moins facile à faire.

Pour finir, je ne peux pas m'en empêcher ( ) :
"C'est en parti le probleme de pulse audio." quel problème avec pulseaudio ? C'est ubuntu le problème, pas pulseaudio...

"mais pas la coherence de configuration du systeme. " et pourquoi pas ? Avoir une couche de gui fonctionnelle sur laquelle la seule chose possible serait d'appliquer un thème selon le goût de l'utilisateur ne me paraît être ni un luxe, ni surréaliste... (comprenez par là : même sous windows 95, on avait ça )

En fait on le l'avait pas vraiment. Toutes les applications ecrites dans un style 3.1 restaient dans un style 3.1 peint windows 95.
La meme chose pour les applicatifs 95 qui tournent dans XP. Il y a des incoherences graphiques. (Souvent la fenetre ouvrir un fichier, ou les barres de defilement) Je ne dis pas que c'est incoherence sont lie au model.

"Un programme vérolé ne doit pas pouvoir se transformer en remote keylogger. Obtenir une telle garantie ne me semble pas réalisable avec une gui (quasi-)complètement en userland (et même en systemland en ring 3 en fait, j'émets de gros doute)."
Non, ca ne reglera pas vraiment le probleme. Potentiellement, si une appli verole tourne, tous les processus de cet utilisateur doivent etre considere comme verole. Donc implicitement, il faudrait que les frappes de touches n'atteignent jamais le processus. Le modele de programmation actuel n'est donc pas adapte et je n'arrive pas a concevoir un model de programmation qui le soit.

"Moi, je suis d'avis que lorsque les choses marchent bien (c'était le cas pour à peu près tout dans la sarge sauf le wifi), on doit commencer à essayer de figer ces choses, tout en continuant des développements alternatifs en parallèle (dans des distributions pour barbus comme gentoo)"
+1

"La xlib, c'est bien naze, alors on a fait gtk et qt... très bien. Quelqu'un ici peut-il me donner une différence significative entre gtk et qt ?"
ils n'ont pas la meme grand mere ? nan, je ne vois pas non plus...

"Pourquoi on ne flanquerait pas l'intersection des gtk et qt dans une couche plus bas ? Pour moi, on arriverait justement à «Avoir une couche de gui fonctionnelle sur laquelle la seule chose possible serait d'appliquer un thème selon le goût de l'utilisateur»
Bien sûr, c'est facile de dire tout ça, et beaucoup moins facile à faire."
Je suis bien d'accord avec la factorisation d'interface. Le probleme avec les gui est que les gens les factorisent par au dessus au lieu de les factoriser par en dessous.
Ce que je veux dire c'est qu'ils vont faire une lib d'intersection qui utilise soit gtk soit qt.
Au lieu de faire une lib du dessous et de reimplementer gtk et qt par dessus. Naturellement, c'est bien plus difficile a faire.

Moins point a la base est que tu veux avoir une interface commune et efficace mais tu ne veux pas non plus pieger le developpeur. C'est pour ca qu'il faut continuer a supporter des interface de tres bas niveau de type X.

"quel problème avec pulseaudio ? C'est ubuntu le problème, pas pulseaudio... "
C'est aussi qu'il y a plein d'appli qui ne supportent pas pulse audio. En tout cas, il y a un an c'etait le bordel, je n'ai pas regarde recement.

Bah, windows 98 (j'ai pratiquement jamais vu de windows 95) me pique moins les yeux que firefox, ark et xpdf sur le même écran. Globalement, c'était quand même assez cohérent. Et sous XP, j'avoue avoir longtemps utilisé le thème "classic" vu que le thème par défaut est trop "playschool" à mon goût.

«Donc implicitement, il faudrait que les frappes de touches n'atteignent jamais le processus.» Moi, j'imagine bien un gestionnaire d'événements qui tourne en tant qu'utilisateur système xorg (privilégié pour certains points, bridé sur d'autres), dont le rôle serait d'envoyer chaque événement *uniquement* à l'application concernée. Ça pose néanmoins un problème pour les raccourcis claviers au niveau du windows manager. Cela dit, on peut aussi imaginer un système de filtre intelligent : le wm dit à son lancement au gestionnaire d'événements tout ce qu'il gère et tout ce qui va vers l'application qui a le focus. Bien sûr, gare au wm vérolé dans ce cas là. (mais bon, on ne peut pas corriger toute la merde du monde non plus...)

«Je suis bien d'accord avec la factorisation d'interface. Le probleme avec les gui est que les gens les factorisent par au dessus au lieu de les factoriser par en dessous. » je sais bien... si j'étais 1 million, les choses seraient autrement.

«mais tu ne veux pas non plus pieger le developpeur» je ne suis pas bien sûr d'avoir compris. Le développeur qui fait ça petite interface graphique pour son jeu de poker en ligne, il s'en fiche un peu du code de la gui, tout ce qu'il veut, c'est un menu, de boutons et que ça soit joli. J'ai déjà vu plusieurs gens se demander s'il valait mieux utiliser gtk ou qt pour faire une interface graphique... c'est triste. Ces gens là préféreraient ne pas se poser une question aussi stupide et utiliser une lib unique bien éprouvée, qui marche bien sur toutes les machines.

«En tout cas, il y a un an c'etait le bordel, » mais c'est pas pulseaudio qui a fait le bordel. C'est ubuntu qui a imposé pulseaudio à ces utilisateurs... Ce choix était pour moi une erreur. C'était bien trop tôt pour faire passer pulseaudio du monde du barbu au monde du novice/utilisateur lambda.

PS : damned, sans le vouloir, voilà encore un pavé.

'«Donc implicitement, il faudrait que les frappes de touches n'atteignent jamais le processus.» Moi, j'imagine bien un gestionnaire d'événements qui tourne en tant qu'utilisateur système xorg [...] gare au wm vérolé dans ce cas là. (mais bon, on ne peut pas corriger toute la merde du monde non plus...)'
Je ne suis pas sur que ca soit suffisant, des qu'un processus est verole, c'est le bordel, tu peux commencer a substituer des libs, a changer les plug ins. A te substituer au wm...
Mais certainement ca serait mieux.

"«mais tu ne veux pas non plus pieger le developpeur» je ne suis pas bien sûr d'avoir compris. Le développeur qui fait ça petite interface graphique pour son jeu de poker en ligne"
Je ne parlais pas de ce developpeur la, mais de celui qui ecrit la lib graphique. J'ai par exemple un ami qui a ecrit un patch pour enlightenment (enfin, la lib graphique qui est dessous, je ne sais pas ce que c'est) afin d'ajouter le support des langues complexes. Je pense qu'il etait bien content de le faire dans un endroit bien isole, en user space sans rien risquer de casse a l'autre bout du monde linux.
Cependant, si le monde etait bien fait, il n'aurait jamais eu besoin d'ecrire ce support parce qu'il existait deja ailleurs.

PS: il manque un vrai systeme de quote sur ce forum

« il manque un vrai systeme de quote sur ce forum » +1, ce truc pourrait faire l'objet d'une suggestion.

«Je ne suis pas sur que ca soit suffisant, des qu'un processus est verole, c'est le bordel, tu peux commencer a substituer des libs, a changer les plug ins. A te substituer au wm...» c'est pas si simple. Tu es effectivement maître de tous les procéssus dont tu es le père... tu peux essayer de pourir ton frère... mais c'est pas pour autant que tu peux tout faire car ton père te contrôle, et il ne te laissera pas modifier l'environnement de ton frère par exemple. Avec un système très stratifié avec des droits stricts, tu peux arriver à quelque chose d'assez robuste. Après, comme tout système multi-couche,
tu le paies en efficacité.

«Je ne parlais pas de ce developpeur la, mais de celui qui ecrit la lib graphique» ok, le terme "barbu" était plus adapté alors.

tu peux changer les fichiers de confs pour prendre la main au prochain run (tu peux toujours les signer). Il y a des failles de securite dans certain logiciel en envoyant des fichiers mal formatter et les logiciels comme open office qui ne se charge qu'une fois vont etre impacte. Changer les plugins de ton navigateur web.
Une fois que tu es infecte, c'est vraiment difficile de contenir le probleme je pense.

Justement, je me demande si on ne pourrait pas pousser une des hints de lfs plus loin pour protéger les fichiers de confs (et autre) :
http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt

J'avais déjà un peu réfléchi sur le sujet en fait. Mais n'ayant pas (encore ) trouver de solution à la fois satisfaisante en matière de sécurité et facile/rapide à mettre en place/maintenir, je n'ai jamais mis en pratique plus que ce qui est dit dans l'hint. D'ailleurs, j'avais fini par capituler et lancer xorg en root à l'époque maintenant que j'y repense.

Ouhla ça discute vraiment technique ici

C'est pour te fournir le meilleur des OS mon enfant.

Ah d'accord
Bon ben vous vous dépéchez de me créer l'OS parfais svp.