Raphaël G. a écrit 1927 commentaires

Ben c'est pas les seuls avec des dns pas fiable...

Dans le genre neuf téléphone a deux balle fait pareil...

Je m'en suis rendu compte quand mon /etc/resolv.conf avait été pourrit par l'utilitaire mandriva de config (cooker quand tu nous tiens...)

Résultat 15-20% des requêtes dns tombaient sur la foutu page du routeur a la con...

Solution : urpmi bind bind-utils

Config serveur de cache et on va taper direct dans les top root dns...
(pas propre, mais au moins j'arrive a avoir tout le net)

Mais c'est quand même grave si un FAI se permet d'avoir des dns qui ne renvoient pas 100% des noms de domaines correctement (quid d'un filtrage ?).

Bref neuf téléphone ça pue, ailleur ça pue aussi, mais un peu moins (pas d'interface routeur utilisable uniquement sous IE>=6.0 par exemple)

Ahhhhhhhhhhh, enfin, donc maintenant X (et tout le noyau) va plus planter quand on déplace une fenêtre (genre xawdecode/xdtv) hors de l'écran avec l'option composite activée...

Vivement que la 7.1 arrive en cooker alors ;)

Ça rame surtout a donf si tu n'est pas chez free...

Et ui le direct dl de free c'est limité au abonnés free, chez neuf téléphone on se tape des débits de 5-6ko/s...
(C'est dire j'allais plus vite en tapant dans un proxy chez un copain chez free que en téléchargeant directement)

Le support de gstreamer est incomplet du fait de gstreamer...

En effet depuis le passage de 0.8 à 0.10 un sacré nombre de fonctions ont "sauté" dans gstreamer (comme au hazard le support des flux audio internet, donc au revoir les radiowebs)

Sinon pour ce qui est des moodbars j'ai également un gros plantage a divers endroit du hashage :'(

Par contre si je retire les morceaux amarok cesse tout de suite de me les hasher

J'ai par contre eu une mauvaise surprise avec un fichier mp3 qui me plantait amarok (boucle intempestives dessus, rapport de bug fait, mais j'ai été étonné).

Bref, heureusement que le moteur xine est là pour pouvoir prendre le relais du moteur gstreamer défaillant (sinon je serais réduis a mes 20-30 ogg/mp3 libre qui me sortent par les oreilles ;)

Mplayer a beaucoup de mal avec le rm (jamais marché sur les dernières versions).

Tu peux utiliser helixplayer : hxplay

J'ai juste eu a mettre les paquets : helixplayer-real-codecs helixplayer
(c'est juste encore leur connerie de redistribution pas autorisée qui met ça dans les sources plf).

Sinon ça ferait belle lurette que mplayer supporterait le realplayer correctement.

Enfin les flux proprios c'est MAL(tm).

Autant que je le dise, entre le Ouvrir/enregistrer de gnome/gtk et celui de kde y a UN MONDE...

Celui de gnome est POURRIT (40click pour allez a l'emplacement voulu, déplacement de 3rep).

Celui de KDE est simple, avec un support d'aperçu des fichiers, un ensemble des répertoires courants a gauche (Documents, Images, Téléchargement, Musique, Vidéo).

Bref, gnome, je vois pas ce que vous lui trouvez mais ça ne correspond pas du tout a mes habitudes.

J'en suis même a dégager tous les programmes basés sur gnome/gtk a cause de ces problèmes, c'est dire...

mandriva 2007 ;)

mais ce sera surement sans kde4 :'(

Surement parce que gstreamer 0.10 ne supporte pas les streams audio web...
(et ui ça fait parti des régressions entre la version 0.8 et 0.10...)

Vient sur la cooker, et rejoint la ml, en ce moment ça bouge :
- man page en utf-8 (certains sont pas pour, mais ça passera ptet)
- xorg7 (j'ai fait un mail explicatif sur comment y arriver)
- menu-xdg (merde pas mal)

Écriture de nouveaux outils, etc...

Bref, la 2007 devrais devrait peut-être être un grand crus, y a pas mal de bugs encore ennuyeux, mais je la trouve très bien.

Je tourne en xorg7 (après avoir essuyé pas mal de plâtres) et tout marche, donc pour le pas a jour c'est pas trop trop le cas...

Xgl, je suis pas trop tenté, les drivers NVIDIA a trop de soucis entre la transparence et l'opengl. De plus mandriva est partie sur une solution qui paraissait plus propre et long terme (et ça me convient).
(j'ai pas trop suivit, mais redhat/fedora a choisi encore une autre solution, bref ça bouge et tant mieux...)

J'espère sincèrement que la mandriva 2007 ne refera pas les conneries de la 2006 (avec kat et le driver nv qui marche pas brut de décoffrage) et je veillerais a ce que ça fasse pas un bis répétita sur ce point sur ma machine (au moins).

De toute façon le jour où il voudra savoir comment les choses sont faite il le fera...

Mieux vaut juste l'aiguiller sur les site peux dépravant que sur les horreurs ce jour là.

A tout interdire vous risquez surtout un retour de balancier viollent...

De toute façon c'est un jeu sans fin, il existe des tas de site de ce style :
http://www.hidemyip.eu/
(Je cherchais un autre que j'avais déjà utilisé, mais google m'a mis celui-là en première page).

Bref, le plus efficace est surement de logguer tout est de regarder les top sites consulter et gueuler un coup si des sites peu catholiques monte trop haut dans la liste...

De toute façon, vous vous lancez dans une course a la technologie entre vos enfant et vous, vous n'avez comme avantage que votre (toujours plus qu'on ne le crois courte) avance.
Eux ils ont un cerveau qui fait pour apprendre a très grande vitesse, et vous serez très vite dépassé.

Dans le pire des cas ils vous en voudront plus tard d'avoir mis une chape de plomb qui leur a pourrit la vie et qui ne leur aura pas forcément donné de "bonne manière/conduite".

je parlais d'un module noyau qui autorise les plage de DMA en fonction des cartes et les divers registres nécessaires au cartes en question...

Je pense que les drivers de NVIDIA, ATI et co on juste besoin de pouvoir taper directement dans la RAM embarquée de leur carte et de faire de la magie sur leur registres.

Il n'ont surement pas besoin de quoi que ce soit d'autre.

En fait le problème est que ce serait un module qui ferait une sorte de liste blanche des choses autorisées.
(le dri doit ptet faire pareil).

Après ça empêche pas le driver proprio de faire des conneries avec sa carte graphique, mais au moins dans le pire des cas il ne peux pas compromettre le reste, un gros bac a sable en fait...

Le problème est que ce genre de chose permettrait surement d'intercepter toutes les communications entre le driver et la carte et donc de reverser les drivers.

C'est tout bête, le XFS est conçu pour les perfs, donc il écris là où il y a des block libre, et parfois il écris pas vraiment de manière optimale, quelques blocks avant, d'autre après, etc...
Quand tu supprime un fichier par exemple, il ré-écris les données suivant directement sur l'emplacement de l'inode supprimé (ce qui explique la récupération impossible de fichiers)

De même les inodes sont a taille variable si mes souvenir son bon (128/256bit par défaut), donc tu peux passer d'un inode de quelque octet a un inode dans un block de 4Ko selon la disposition des blocks de ton fichier...
(fait le calcul, en refaisant ça sur tout le dd, ben ça en fait de la place perdue...)

petit détail, si vous voullez utiliser du selinux sur une partition en XFS vous devez créer la partition avec isize=512 (pour avoir la place de mettre les attribut selinux dans l'inode)

A propos d'ipv6 j'ai eu la douloureuse nouvelle en allant sur le site de 6bone d'apprendre qu'il vont rendre les ip a l'iana...

Y a moyen pour un particulier de récup une ipv6 pour faire joujou avec l'ipv6 in ipv4 ? (normalement c'est sensé marcher).

Ui je suis tombé dessus grâce a son pdf et ça marche rudement bien (faut penser a bien garder de la place libre > taille maxi du plus gros fichier).

J'ai même gagné un bon Go sur un dd de 300Go, ça fait très plaisir ;)

pensez a quand même bien faire un sync a la sortie et démonter/remonter la partition pour forcer la remise a zero du journal de "replay".
(ça éviter de faire oups tout est perdu suite a une coupure de courant)

Et des solutions comme kqemu ?
qui exécute du code directement au niveau hard sur les dernières version ?

En fait il y a deux "proof of concept" (exemple d'exploits).

L'un utilise le mode SMM pour viander toutes les protections du noyaux et pouvoir obtenir les droits niveau noyau.

Pour ceci, l'attaquant a besoin d'obtenir les droits de déclancher une intéruptions SMI pour passer en mode SMM et de pouvoir écrire le code qui va bien, là où il faut pour pouvoir exécuter ce code en mode protégé (le noyau n'y voyant rien du tout).

Concrètement, tu diffuse un module X proprio (genre NVIDIA corrompu), ton root l'installe.
Ton code modifié va ouvrir une ouverture d'accès direct a la mémoire vidéo légèrement modifié pour écrire dans la partie de mémoire que le mode SMM peut exécuter.
Après il se débrouille pour lancer une intéruption SMI et paf il charge un module qui lui donne un full accès niveau noyau.

Le cas concret est un de tes utilisateurs XEN se fait trouer et le pirate veux devenir calife a la place du calife...

Pour cette faille il est possible de se protéger en posant certains flags qui vont bien pour interdire le lancement de cette instruction SMI.

Sinon y avais un second hack, mais j'ai déjà oublié...

Enfin la seule solution pour corriger ça serait d'avoir du code "sûr" en mode noyau (avec une whiteliste des fonctions/registres autorisées) et lasser le code useland en ring3 (tournant sous nobody par exemple).

Mais pour ça il faudrait que les fabricants de cartes graphiques qui payent ces même développeurs se décident a libérer les specs de leurs cartes :'(

Il se peux que ton kernel ne boot pas parce que tu as un processeur de la série maudite dont le PAE est non fonctionnel (intel s'est planté dans la conception).

Il te faut alors installer un kernel-i586quelquechose.

Sinon si tu n'a plus d'autre choix de boot dans le menu de lilo, boot sur le cd1, appuye sur F1 pour avoir l'invité de commande, puis rescue.

Choisis de restorer le bootloader linux, avec un peu de chance ça devrais marcher...

Sinon tu peux aussi choisir la méthode ne pas se casser la tête en faisant une installation par dessus (si tu fait bien gaffe a ne pas formater a l'étape de partitionnement), il te fera une mise a jour et une installation du noyau de base qui dois marcher pour ton processeur.

ps : NE VIRE JAMAIS le vieux noyau qui marche !!! (tant que tu n'a pas testé que la version n+1 marche bien), parce que ça sert de backup en cas de pépin...

tu dois être en icewm

pour essayer de te reconnecter en kde, essaye ceci :
au moment du login, choisis kde comme type de session.

Après si ça marche pas, tu a peut-être "cassé" des dépendances a la mise a jour.

Essaye ceci (en root):
rm -f /usr/share/config/kdm/*
rpm -e --nodeps kdebase-kdm kdebase-kdm-config-file kdebase kdebase-common kdebase-servicemenu kdebase-konsole kdebase-progs libkdebase4 libkdebase4-konsole libkdebase4-kate libkdebase4-kmenuedit libkdecore4 libarts1 arts kdebase-progs

urpmi kdebase-kdm kdebase-kdm-config-file kdebase kdebase-common kdebase-servicemenu kdebase-konsole kdebase-progs libkdebase4 libkdebase4-konsole libkdebase4-kate libkdebase4-kmenuedit libkdecore4 libarts1 arts kdebase-progs

On commence par virer la config de kdm qui a peut-être merdé, ensuite on vire les paquets de base (au cas où) sans vérification des dépendances, ensuite on ré-installe la base nécessaire a kde.

Normalement ça devrait être bon ensuite.

Sinon tu peux essayer de vérifier si il n'y a pas de paquets foiré avec cette commande (en root):
rpm -Va

Ça affichera toutes les modifications que tu a pu faire par rapport au paquets de base (donc certains fichiers ont été modifiés et c'est normal).

Si tu vois des dépendances manquantes tente de les installer avec :
urpmi nom_dépendance_manquante

En espérant que ça t'aide...

Soit dis en passant il est "NORMAL" sous linux d'avoir 3-5Mo de ram de libre (surtout si tu utilise un KDE, quelques grosse applis et une lecture de gros ficher mkv/avi).

Ton linux utilise simplement la ram comme espace de cache au lieu d'aller bêtement seeker sur ton disque dur comme le fait un système débile concurent (w*).

Concrètement ta swap ne devrais jamais être utilisée...

Sauf dans le cas précédent de fuite de mémoire.

Sous kde :
kcmshell memory

Si tu a 3-6Mo de swap utilisée(a droite) et toute la mémoire libre restante en cache(au milieu), tu est dans une situation optimale.
(bien sur si ça fait 2h que tu a booté la machine sans rien faire, ça veux rien dire, faut attendre un jour ou deux d'utilisation pour avoir des résultats fiables...)

Si tu tourne sous mandriva et qu'il s'agit d'une carte réseau ethernet (câble et pas wifi), ça dois se faire tout seul.

Si ce n'est pas le cas, installe le paquet lshw

Lance :
lshw -C NETWORK

Examine le résultat, ça devrais te dire quel module noyau tu a besoin.
Normalement ça dois être un de ces modules :
sk98lin (gigabyte nvidia)
3c59x (carte 3com 10/100)

après si tu a un autre type de carte fait ceci :
cd /lib/modules/`uname -r`/kernel/drivers/net
ls

et regarde quel module correspondrait a ta carte en faisant :
modinfo un_nom_de_fichier_sans_le_.ko_de_la_fin

Menu */Exécuter une commande...
menudrake

Ou alt+f2
menudrake

Ou bouton droit sur l'étoile et "Éditeur de menu"

Ensuite choisis :
Toutes les applications

Sauvegarde et ça devrais être bon.

Si tu a pas de résultat de suite tu peux exécuter :
kbuildsycoca
(ça va recharger toute la config de kde a chaud)

Pourquoi créer une couche, des drivers propres en noyau feraient l'affaire...

Pour ça on a besoin que nvidia/ati libère les specs de leur cartes.

Après il y a plus qu'a faire des drivers en modules qui n'autorisent que les fonctions nécessaires au fonctionnement des dits drivers ainsi que les plages d'accès de confiance.

Dans le pdf des chercheurs il le disent bien, on peux donner des accès dma a du code ring3 dans un module/pièce de code ring0.
Mais on ne peux le faire que si dans tous les cas ce que va faire le code ring3 ne peux pas compromettre le code ring0 ou le modèle de sécurité qui le maintient en sûreté (page de mémoire, accès interruptions/PIO/MIMO/etc protégées).

Il y a quelque temps on parlais des modules binaires qui pouvais prendre en otage l'utilisateur entre un système non fonctionnel et un système avec un trou de sécurité.

Malheureusement en voici un exemple concret :'(

Il serait bon que les constructeurs de cartes graphiques se réveillent et lâchent les spécificités techniques de leur cartes afin qu'on puisse avoir un système sur !

Je pense que par exemple les modèles basés sur les drivers DRI ne doivent pas êtres affectés par ce genre de trous de sécurité...

Le risque c'est que dans quelques jours/semaines/mois/années on voie arriver des supères images 3D de la mort qui contiennent du code pour viroler l'os en traversant toutes les couches...

Pour une fois que les services de Villepin font un truc de bien...
(bizarrement je me pose la question de pourquoi ils ont diffusé ce genre d'info au lieu de les garder pour que les services secrets puissent entrer partout...)

arts a été abandonné par son propre concepteur...

Si je me souvient bien c'est parce qu'il était par essence mal conçu.
(je te renvoie a son mail, précédament posté dans une dépèche)

Et puis arts est passablement buggué...
(Pour l'avoir utilisé pas mal de temps, je passait plus de temps a rapporter des bugs qu'a lire mes fichiers audios sous amarok...)

Bon maintenant y a plus le choix, dans la version 1.4, le moteur arts a carrément été droppé...

Ui ça va faire un peu comme arts aujourd'hui de ce côté, mais pour les fonctions de son basiques...
(après il y aura surement un système de branchement backup genre :
gstreamer(mis en défaut)->alsa->xine->etc...)