Au moins, depuis l'affirmation ci-dessous gratuite et fausse, ton avis a évolué : La version windows est bourrée de plugins multimedias proprios, dont un plugin s'appelant exactement "microsoft DRM".
Quand à ceci : Si tu es d'accord avec ce fait , alors convient que cela est déplorable..
Qu'est-ce qui est déplorable ? Que l'utilisateur lambda accèpte (probablement plus par ignorance qu'autre chose), des DRM et des formats proprios ? Ou qu'un navigateur alternatif (qui cherche à se faire une place là où la concurrence est présent à 90%) s'adapte aux besoins et envies de l'utilisateur ?
Si on suit ton raisonnement jusqu'au bout, il faudrait que FF :
- interdise l'installation de Flash ?
- bloque l'accès aux sites web qui ne sont pas libres (Microsoft par exemple...) ?
- etc...
Dis, cela ne serait'il pas un semblant de comportement de filtrage ?
J'ose espérer que ce commentaire ne m'est pas destiné, et que tu te t'es trompé de personne dans ta réponse.
Mon précédent commentaire était destiné à "free2.org", afin de lui indiquer que le code proprio était propriété de MS, et non comme il le supposait, de Mozilla.
Lorsqu'on lance ce genre d'accusation, le minimum de respect pour le lecteur de LinuxFR serait de se renseigner un minimum.
2 minutes de recherche permettent de trouver que ces 2 dll là se trouvent dans "C:\Program Files\Windows Media Player", et que le propriétaire de ces fichiers est, je cite, "Microsoft Corporation".
Donc ce code, sans doute proprio, ne vient pas de Firefox/Mozilla mais de MS.
Quand au fait que l'on trouve ces fichiers dans le "about:config", j'imagine que FireFox sait lire la base de registre, et il les as trouvé dans celle-ci.
1 minute de recherche dans la base de registre t'aurait permi de trouver des reférences à ces fichiers dans HKEY_CLASSES_ROOT\Software\Microsoft\Multimedia\Components\Informational\DRM_DRM\Files\File0 et HKEY_CLASSES_ROOT\Software\Microsoft\Multimedia\Components\Informational\DRM_DRM\Files\File1
Le chemin indiqué fait clairement référence à un produit MS.
Donc :
- oui, FF sait utiliser des plugins proprio.
- non, ces plugins proprio ne vienent pas de la fondation Mozilla.
Quand à la désactivation de ces plugins, je te laisse chercher (ce n'est pas très compliqué).
qu'est-ce que tu utilises comme client SSH ? Personnellement, j'utilise de temps en temps un client SSH cygwin à travers un tunnel SSH (proxytunnel), et l'option "ProtocolKeepAlives" ne marche pas sous Cygwin.
C'est assez clairement indiqué dans le man de SSH Cygwin. L'option à utiliser est "ServerAliveInterval"
J'ai donc mis dans le ~/.ssh/config" de mon cygwin l'option suivante :
C'est vrai quoi, aller apres des gars qui foutent la merde illegalement sur les machines de 6 millions de clients (et qui donc nuit a leur reputation) c'est condamnable.
D'un autre coté, ces pirates assurent/ons un apport réguilière d'argent à Microsoft et à divers autres sociétés : Symantec, McAfee, etc... (tout les editeurs d'antivirus, firewall, etc...).
De là à dire que MS et consort payent les pirates qui créés des virus, il y a là un pas que je ne franchirais pas. Cependant, force est de constater que les traveaux des créateurs de virus assureront un apport régulier d'argent à MS, entre 2 sorties de leurs produits...
Dans la pratique je tourne en 1.1 Mo/s sur ftp.free.fr (autour de 12Mbps ATM). Depuis le taf, je suis à 3.5 Mo/s.
Pour le FTP, le bridage de Free se fait au niveau 7 du modèle OSI. Pour faire simple, Free regarde quel est nom de l'application FTP que tu utilises pour ta connexion (c'est l'équivalent du "User Agent" en HTTP), et filtre en conséquence.
J'ai pu tester chez moi (free non dégroupé), un download d'ISO de distribution Linux sur un serveur de Free (ftp.free.fr) :
- avec "wget", pas de problème, je téléchargais au max de la ligne (850ko/s)
- avec "kbear", un client FTP graphique sous KDE, le débit était de... 10ko/s ! Le client ayant été testé auparavent en LAN, et fonctionnant normalement.
Le test a été effectué à une minute d'interval, sur le même serveur, et deux fois de suite.
Conclusion : Pour les téléchargements FTP, il faut utiliser des clients "connu". "wget" en fait parti, car il est utilisé par bon nombre de distrib Linux pour les téléchargements de paquets (apt-get, urpmi, etc...)
J'étais persuadé que FF effacait tout les cookies, y compris ceux qui étaient considés comme autorisés. Mais en fait, ceux que l'on a autorisé sont les seuls qui sont gardés.
J'imagine que tu veux parler des boutons "Bloquer" et "Autoriser" dans Edition / Préférences / Vie privée / Cookies / Exception ?
Effectivement, on peut avec ces options avoir le comportement suivant "Tout les cookies sont par défaut interdit, sauf ceux d'une 'liste blanche'".
Cependant, bon nombre de sites ont un comportement "anormal" lorqu'on leur interdit leurs cookies, ou, comme le fait FF, on leur cache le fait que le cookie n'a pas été créé.
C'est pourquoi je préfère laisser les sites poser leurs vilains petits cookies, quitte à ce que le ménage soit fait au prochain démarrage de FF (via mon script). Je ferme suffisament de fois FF par jour (ce n'est pas un problème de stabilité de l'application ou de la machine), ainsi le ménage est souvent fait.
Il n'empèche que j'utilise quand même le bouton "Bloquer" pour interdir les cookies qui reviennent trop souvents (Google, Xiti, akamai.net, etc...)
Il ya quelques différences entre les réacteurs de la centrale de Tchernobyl et les réacteurs ERP que nous avons en France.
Sans rentrer trop dans les détails (notion de "surface efficace" pour les particules en déplacement), les réacteurs à eau pressurisée (les français donc) ont pour effet de s'étouffer lorsqu'ils chauffent trop. Donc la réaction de fusion se ralentie avec la chaleur (*). Contrairement aux réacteurs des Russes, qui eux s'emballent avec la chaleur. Et donc explosent...
(*) Il n'empèche qu'une forte chaleur peut causer des dégats irrémediables sur le coeur du réacteur. Comme cela s'est passé à "Three Miles Island", aux Etats Unis (en 1979)
Hummm, je ne veux pas conparer alltheweb, google, ou qui que ce soit d'autre.
Cependant, il est souvent intéressant de regarder un peu en détail les connexions qui sont faites lorsque l'on utilise un site web.
Dans le cas de "alltheweb.com", toute recherche fait appel à 2 sites web, qui n'ont à priori rien à voir avec alltheweb.com, et encore moins avec la dite recherche :
Exemple chez moi :
bsav.search.yahoo.com/serv?s=xxxxxxx&t=xxxxxxxxx&_ylb=xxxxxxxxxxxxxxxx....
us.bc.yahoo.com/b?P=xxxxxxxxxxx....
Ces données sont extraites des log de Privoxy ( http://www.privoxy.org/ ), un proxy antipub, qui fait un boulot similaire à "AdBlock", mais en plus puissant.
Bien évidement, je n'utilise pas les services de Yahoo, et donc ces connexions n'ont à priori rien à faire ici. Mais en fait, en y regardant d'un peu plus près, on se rend compte que "alltheweb.com" EST yahoo.
Enfin, ce qui m'inquiète un peu plus : Tout clic sur un lien du résultat de la recherche (en vert) passe par Yahoo avant de renvoyer sur le site en question. Donc Yahoo SAIT que vous avez clicé sur ce lien là de la recherche.
Je ne sais pas si cette technique est utilisé afin de juger de la pertience de la réponse affichée. Mais en tout cas, Yahoo identifie mieux le sujet qui vous a intéressé dans la question posée.
A noter qu'en 7 ans d'utilisation de Google, je n'ai vu que 2 fois ce type de comportement (passage par le site de Google avant d'être redirigé sur le resultat de la recherche). Alors que dans le cas de "alltheweb", c'est de toute évidence systématique.
Mais je ne fais pas non plus l'appologie de Google. Le cookie qu'il place systématiquement est un outil, basique certes, permettant d'identifier les besoins de l'Internaute. Et quand aux autres outils de Google (GMail, GTalk), je ne les utilise évidement pas du fait de ce qui est écrit dans le "contrat d'utilisation" (entre autre, l'analyse par des robots des données échangées).
Je n'ai pas de solution miracle à ce problème de confidentialité, ou d'indiscrétion. Si ce n'est quelques outils de base :
- Privoxy ( http://www.privoxy.org/ ) afin de filtrer un maximum de choses. Cela supprime les http-referer, une partie des cookies, les pubs, etc...
- Le mécanisme d'exception de cookies de Firefox (Edition / Préférences / Vie privée / Cookies / Exception)
- Un petit script de ma conception, qui supprime tout les cookies à chaque démarrage de Firefox, exception faite de ceux d'une "white list". Ainsi, je ne concerve que les cookies de 3 sites dont j'ai réellement besoin (et LinuxFR est l'un de ces 3 sites). A ceux que cela intéresse, je peux envoyer le dit script par mail. Me contacter en privé pour cela.
Une machine de production ne devrait jamais être en direct face à internet. Ça permet de réduire pas mal de risques.
Un serveur web, tu es obligé de laisser son port 80 accessible. Mais si le patch de sécurité touche un soft / bibiotheque que peut accéder ce serveur (du PHP, une zlib, du RCP, etc...), un intrus peut accéder à la faille de sécurité. Tout simplement en passant par une requête foireuse (GET ou POST) sur le port 80.
Prend par exemple les problèmes de sécurité sur phpnuke, les blogs, etc... Au final, des serveurs ont été infectés par des escalations de privilège, via des scripts PHP, ASP, CGI-BIN, ou autre qui étaient buggés...
Et une machine pilotant des outils ne devrait même pas être connectée au reste du monde.
Non, mais la machine outil est connectée en réseau à d'autres machines outils, d'un autre fournisseur. Et pour ceux-ci, tu ne peux pas savoir ce qu'en font les gens qui y travaillent dessus. Sans même parler d'espionnage industriel, ou de volontée de nuire...
Enfin, le coup des tests sur des machines importantes, c'est valable pour les patchs sous *nix/bsd aussi...
Tout à fait. D'ailleurs, tu remarqueras que mon commentaire était généaliste (ie: quelque soit l'OS). Je n'ai parlé de Windows que pour cité un exemple concret de mon boulot.
Le système de mise à jour automatique et simplifié de Windows (WindowsUpdate) rempli donc son rôle.
Autant un système de mise à jour automatique peut bien s'utiliser dans un environnement personnel, autant dans le milieu professionel cela pose problème :
- Comment être sûr à 100% que le patch ne va pas planter la machine ? Qui n'a jamais vu un SP de Windows complètement casser l'OS, et devoir tout réinstaller au redémarrage suivant ?
- Quel va être l'impact du patch sur la machine, et sur les autres applications qui y tournent dessus ? Un patch peut produire des incompatibilités avec un code applicatif existant (du PHP, de l'ASP, du SQL, etc...), et peut empêcher l'application "maison" de continuer à fonctionner.
- Après l'installation du patch, il faudra surement arrêter/redémarrer quelques services, voir rebooter la machine. Ce temps d'arrêt va impacter le temps pendant lequel la machine fournit son service. Dans le milieu industriel où je travaille par exemple (machine outil), le reboot d'un PC Windows va créer jusqu'à 4h d'arrêt de l'outil de production (le temps de remettre l'outil de production en température, et de le qualifier). Et bien sûr, chaque minute d'arrêt de production de la machine coûte enormément d'argent...
- Pour bien faire, il faudrait installer le patch sur une machine de test, qui simule l'utilisation du serveur complet. Et évidement, il faut pouvoir tester cette configuration pendant plusieurs jours ou semaines, afin de vérifier qu'il n'y a réellement pas d'impact néfast du patch. Pendant ce temps là, la machine de production est toujours exposé aux vulnérabilités.
Tout ceci explique pourquoi de nombreux ordinateurs ne sont pas patchés dans le milieu professionnel... Les contraintes de productions passe avant celle de sécurité. C'est dommage, mais c'est comme cela.
Bof, si c'est vraiment ça la raison qui retarde le démmarrage pourquoi tester à *chaque* démmarrager??
Tout simplement pour rendre la machine plus flexible, et capable de s'adapter "out of the box" sur une nouvelle machine/configuration.
Imagines :
- Tu installes ta distribution favorite sur une machine "A".
- Tu démontes le disque dur, et tu le mets dans une machine "B", physiquement différente de "A" : Pas les mêmes cartes mêres, réseaux, vidéo, etc...
- Lors du boot de "B", il y a de très fortes chances pour que le Linux se configure tout seul sur ce nouveau hardware, et soit opérationnel tout de suite.
C'est l'usage que l'on fait de l'Informatique au jour d'aujourd'hui (2006) qui veut cela : La configuration d'une machine doit être la plus transparente possible du point de vue de l'ordinateur. Même si cela doit couter une débauche de temps CPU, et de mémoire vive...
On ne change pas de matériel touts le temps et il suffirait d'ajouter un outil pour voir les changements (quitte à rebooter si nécéssaire).
Tu aimes tant que cela les reboots de Windows ? :)
Et je me répète: BeOS faisait 14s *sans optimisation de l'utilisateur* et ce temps inclue le démmarrage du desktop
Et j'imagine que ton BeOS savait gérer :
- L'"export display", qui permet d'envoyer de maniètre transparente l'affichage d'une application sur un écran situé à distance
- Le multi-écrans
- Les effets de transparences, d'ombrages, etc...
- Les périphériques amovibles, genre USB, firewire, etc...
- La 3D (OpenGL)
- Le directrendering (qui permet par exemple d'afficher de la video directement sur le chipset graphique)
- Pouvait utiliser plusieurs toolkits graphiques différents (KDE, Gnome, vxWidget, OpenOffice.org, Mozilla, etc...)
- Etc...
En terme de "look pur", je me souviens de screenshots de BeOS de l'époque. Par rapport aux Windows de l'époque, c'était équivalent. Mais par rapport à ce que l'on peut avoir sur un Linux, il n'y a pas photo. Or, toute cette débauche de couleurs et d'effets graphique des Linux, il faut bien le payer à un moment donné, non ?
Pour ce qui est des serveurs présents par défaut, je pense (et j'espère ne pas me tromper) que ce n'est plus trop le cas sous Linux, d'un point de vue sécurité, c'est une très mauvaise idée!
Lance un "netstat -taupn" sur ta machine, tu auras une bonne vue des serveurs qui y tournent.
BeOS sur une machine bien moins puissante que maintenant démmarait en 14s (du boot loader à l'interface graphique fonctionnelle et sans aucune optimisation de ma part)..
Il faudrait peut-être comparer ce qui est comparable : Ton BeOS n'avait pas à gérer xx interfaces réseaux différentes (et d'ailleurs, combien existait-il de drivers pour les cartes réseaux ?), du Wifi, de l'IPv6, du Bluetouth, et j'en passe et des meilleurs...
Ce que je te faire comprendre c'est qu'avec le temps, Linux s'est diversifié à un point qui n'était pas imaginable à l'époque de ton BeOS, et que dans ce cas, le nombre même de tests à faire pour démarrer le système est nettement plus conséquent.
Prenons un exemple tout simple : Le script de démarrage des couches réseaux d'un Linux. Sur ma MDK, mais c'est sensiblement la même chose pour les autres distributions, le script "/etc/init.d/network" fait 359 lignes. Dedans : du bash qui lance toutes sortes de programmes (awk, ifconfig, etc..), afin de prendre en compte plein de types de configurations de réseaux différentes. Mais si tu veux quelque chose de beaucoup plus rapide pour UNE configuration particulière, cela peut se régler en 3 lignes de bash. Voir à quelques lignes de C, ce qui permettrait en plus d'éviter de lancer l'interpereur bash.
Pourquoi ne pas plus optimiser ainsi tout les scripts alors ? Parce qu'il perdrait pas mal de lisibilité pour les utilisateurs, et qu'ils seraient forcément moins souples.
De plus, il existe tout un tas de programmes qui se chargent automatiquement au démarrage de la machine : serveur de fontes, portmap, serveur SMB, serveur web, firewall, HAL, etc... Tout cela dans le but de rendre la vie de l'utilisateur plus simple, sans qu'il n'ait besoin d'activer manuellement des parties de softs lorsque l'occasion se présente. L'utilisateur veut ne pas avoir à se poser de questions lorsque qu'il est sur sa machine. Cela nécéssite donc de charger dans le système des méchanismes complexes.
Enfin, dans la philosphie de Unix/Linux, il n'est pas habituel de redémarrer son ordinateur : Ce type de machine a été conçu pour être allumé et ne (presque) pas s'arrêter. C'est l'utilisateur actuel qui a sans cesse besoin de l'éteindre et de le rallumer... Ce qui fait au passage des économies d'énergie, ce qui n'est pas forcément plus mal... ;)
Conclusion :
- Linux est long à booter : Oui
- Linux charge plein de trucs inutiles : Oui, afin de faciliter l'utilisation pour l'utilisateur "newbee".
- Le chargement de Linux peut être optimiser : Oui, et très largement :
+ Compilation du kernel pour ne charger que les modules utiles
+Ne pas charger les softs inutiles (par exemple, pour certains un serveur web n'est pas utile)
+ Ré-écriture des méchanismes d'init. Sur une machine définie, un script d'init unique de quelques dizaines de lignes permettrait de tout lancer.
il est plus facile de télécharger une ubuntu qu'une madriva community. car il y a quelques temps j'ai voulu installer une mandriva à un ami, et c'était le parcours du combattant sur leur site pour le télécharger...
C'est un peu de la mauvaise fois quand même...
Il te suffit d'aller sur un des nombreux mirroirs Français qui heberge des distributions Linux, le plus rapide étant ftp.lip6.fr (serveur de l'université de Jussieu, à Paris) : ftp://ftp.lip6.fr
C'est un site d'information pour Mandriva, en fait c'est même carrément la "home page" de http://www.mandriva.com/ , puique www.mandriva.com est redirigé sur wwwnew.mandriva.com :
[olivier@. ~]$ telnet www.mandriva.com 80
Trying 212.85.150.181...
Connected to www.mandriva.com (212.85.150.181).
Escape character is '^]'.
GET http://www.mandriva.com/index.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
Apache-AdvancedExtranetServer/1.3.27 Server at www.mandriva.com Port 80
Connection closed by foreign host.
Par contre, le fait que tu vois des connexions sur "ns2.moondrake.net", vient de la manière dont Mandriva à rempli ses DNS.
Je m'explique :
- "netstat" voit des connexions vers l'adresse IP 212.85.150.181
- Il lance alors une resolution de nom. C'est l'équivalent à la commande "host 212.85.150.181". Cela retourne le "ns2.moondrake.net" que tu reçois. Et ce nom est typiquement celui que l'on donne à un DNS.
- Mais tu y fais dessus des requêtes HTTP. Des requêtes HTTP sur un serveur DNS ? C'est quoi ce bins ? Pas de panique !! Cette adresse IP heberge aussi d'autres serveurs/service :
[olivier@. ~]$ host 212.85.150.181
181.150.85.212.in-addr.arpa is an alias for 181.160/27.150.85.212.in-addr.arpa.
181.160/27.150.85.212.in-addr.arpa domain name pointer ns2.moondrake.net.
[olivier@. ~]$ host www.mandriva.com
www.mandriva.com has address 212.85.150.181
Donc en fait, le problème vient de connexions qui sont faites sur www.mandriva.com . Quel est le programme qui en est la cause, je ne sais pas (encore). Mais cela ne ressemble pas encore trop à un spyware, ou à un truc trop louche.
Bon, le dossier partagé a mis quelque sminutes avant d'être visible sur le réseau
Renseignes-toi un peu sur le protocole SMB (qui à l'origine a été conçu par IBM, et repris par Microsoft). Tout se base sur un mecanisme de boadcasts, envoyés régulièrement sur le réseau. C'est le "envoyés régulièrement" qui fait que ton Windows n'a pas vu tout de suite le partage.
Tips Windows (je sais, c'est hors sujet ici). Sous l'explorateur, tu as un menu pour rechercher un ordinateur sur le réseau. Utilises-le, et tu verras apparaître plus rapidement le partage.
2°) Je peux accéder à ce dossier en lecture depuis un PC sous Mandriva, par contre il m'est impossible d'y accéder depuis un PC sous Windows XP (un login/password m'est réclamé)
Utilise un login/password vide : Si ton samba a été configuré en mode "share", il n'y aura probablement pas de login/password à utilise. Chez moi, même si j'ai configuré mon samba pour qu'il soit accessible sans login/password, Windows en demande quand même un.
J'imagine que quand Microsoft ou autre se sert de ce genre de méthodes, tu es le premier à applaudir...
Microsoft fait déjà quelque chose de similaire. Lorsque tu installes un driver qui n'est pas "certifié Microsoft", tu as une belle boîte de dialogue (avec un icone de "warning" jaune) qui te dit que tu risques des problèmes d'instabilité, du fait que ces drivers n'a pas été testé par les laboratoires MS.
Tu ne sembles pas vraiment savoir ce qui crée de la fragmentation sur un disque dur. Il serait sans doute que tu te renseignes avant d'écrire un journal. A moins que celui-ci ne soit là que pour critiquer (voir, troller)...
La raison pour laquelle les partitions ext2/3 ne fragmentent pas, ou peu, c'est qu'elles gardent en mémoire sur le disque dur, une table indiquant la taille des blocs libres. Ainsi, lorsque l'OS veut écrire un fichier, il choisit le bloc de la plus petite taille possible et qui peut contenir le fichier en un seul morceau. En comparaison, les FAT12/16/32 de Windows n'ont pas ce type de mécanisme (et pour NTFS, je ne sais pas).
Avec un DD presque plein en permanence, surtout contenant des fichiers de grosse taille (j'imagine que ton aMule ne fait que télécharger des images ISO de distributions Linux, au format CD ou DVD...), il ne peut rester comme place sur le disque que des blocs éparses. Donc forcément le FS se fragmente lorsque tu veux rajouter des données, car il ne peut pas trouver un emplacement continue de 700Mo ou 4.7Go.
De plus, aMule (et les autres softs de P2P) amplifie le phénomène de fragmentation, car ils stockent initialement les fichiers téléchargés sous la forme de petits blocs, téléchargés indépendament sur Internet (je suppose par la que tu commences toujours par télécharger des images ISO de distributions Linux, et que tu n'en mets donc pas "spontanement" en partage). Si tu télécharges plusieurs fichiers en parallèle, tu aura donc une partie de ton DD qui sera composé de multiples petits fichiers temporaires
Une fois que qu'une image ISO sera coomplètement téléchargée, *Mule recréera un fichier unique, là où il y a de la place. Et comme ton DD est plein, ce sera à l'emplacement d'anciens petits blocs temporaires
Si tu utilisais un *Mule sous Windows, tu verrais exactement le même phénomène.
Quand à ceci : Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique
Le "pas très logique" confirme bien que tu ne comprends pas le phénomène de fragmentation. C'est pourtant le seul moyen de ne pas fragmenter un DD, lorsque l'on n'utilise pas un soft qui manipule directement le FS au niveau des blocs (donc un soft de defragmentation)
Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)
Au vu de tes journaux, et de ton niveau de connaissances techniques de Linux (je ne parle pas d'experiences, ou d'experimentations), les trollometres vont exploser...
[^] # Re: MS DRM about:plugins
Posté par Olivier (site web personnel) . En réponse au journal Le troll de l'année?. Évalué à 4.
La version windows est bourrée de plugins multimedias proprios, dont un plugin s'appelant exactement "microsoft DRM".
Quand à ceci :
Si tu es d'accord avec ce fait , alors convient que cela est déplorable..
Qu'est-ce qui est déplorable ? Que l'utilisateur lambda accèpte (probablement plus par ignorance qu'autre chose), des DRM et des formats proprios ? Ou qu'un navigateur alternatif (qui cherche à se faire une place là où la concurrence est présent à 90%) s'adapte aux besoins et envies de l'utilisateur ?
Si on suit ton raisonnement jusqu'au bout, il faudrait que FF :
- interdise l'installation de Flash ?
- bloque l'accès aux sites web qui ne sont pas libres (Microsoft par exemple...) ?
- etc...
Dis, cela ne serait'il pas un semblant de comportement de filtrage ?
[^] # Re: MS DRM about:plugins
Posté par Olivier (site web personnel) . En réponse au journal Le troll de l'année?. Évalué à 1.
Mon précédent commentaire était destiné à "free2.org", afin de lui indiquer que le code proprio était propriété de MS, et non comme il le supposait, de Mozilla.
[^] # Re: MS DRM about:plugins
Posté par Olivier (site web personnel) . En réponse au journal Le troll de l'année?. Évalué à 4.
2 minutes de recherche permettent de trouver que ces 2 dll là se trouvent dans "C:\Program Files\Windows Media Player", et que le propriétaire de ces fichiers est, je cite, "Microsoft Corporation".
Donc ce code, sans doute proprio, ne vient pas de Firefox/Mozilla mais de MS.
Quand au fait que l'on trouve ces fichiers dans le "about:config", j'imagine que FireFox sait lire la base de registre, et il les as trouvé dans celle-ci.
1 minute de recherche dans la base de registre t'aurait permi de trouver des reférences à ces fichiers dans HKEY_CLASSES_ROOT\Software\Microsoft\Multimedia\Components\Informational\DRM_DRM\Files\File0 et HKEY_CLASSES_ROOT\Software\Microsoft\Multimedia\Components\Informational\DRM_DRM\Files\File1
Le chemin indiqué fait clairement référence à un produit MS.
Donc :
- oui, FF sait utiliser des plugins proprio.
- non, ces plugins proprio ne vienent pas de la fondation Mozilla.
Quand à la désactivation de ces plugins, je te laisse chercher (ce n'est pas très compliqué).
# Client SSH ?
Posté par Olivier (site web personnel) . En réponse au journal [free non degrp] déco si idle en tcp ?!?. Évalué à 3.
qu'est-ce que tu utilises comme client SSH ? Personnellement, j'utilise de temps en temps un client SSH cygwin à travers un tunnel SSH (proxytunnel), et l'option "ProtocolKeepAlives" ne marche pas sous Cygwin.
C'est assez clairement indiqué dans le man de SSH Cygwin. L'option à utiliser est "ServerAliveInterval"
J'ai donc mis dans le ~/.ssh/config" de mon cygwin l'option suivante :
ServerAliveInterval 90
(90 = 90 secondes)
[^] # Re: Quel dégout ?
Posté par Olivier (site web personnel) . En réponse au journal le FBI décore des salariés de Microsoft pour services rendus. Évalué à 2.
D'un autre coté, ces pirates assurent/ons un apport réguilière d'argent à Microsoft et à divers autres sociétés : Symantec, McAfee, etc... (tout les editeurs d'antivirus, firewall, etc...).
Pour ce qui est de Microsoft, ils préparent un support payant de sécurité : http://rss.zdnet.fr/actualites/informatique/0,39040745,39223(...) , http://rss.zdnet.fr/actualites/informatique/0,39040745,39223(...) . A l'époque où cette news est apparu, on parlait d'un coup mensuel estimé de 5-10 dollars par mois. Avec 6 millions de clients (le chiffre de pBpB), cela ferait un potentiel les 3 milliards par ans.
De là à dire que MS et consort payent les pirates qui créés des virus, il y a là un pas que je ne franchirais pas. Cependant, force est de constater que les traveaux des créateurs de virus assureront un apport régulier d'argent à MS, entre 2 sorties de leurs produits...
[^] # Re: Trop cher
Posté par Olivier (site web personnel) . En réponse au journal FAI filtreurs de P2P?. Évalué à 6.
Pour le FTP, le bridage de Free se fait au niveau 7 du modèle OSI. Pour faire simple, Free regarde quel est nom de l'application FTP que tu utilises pour ta connexion (c'est l'équivalent du "User Agent" en HTTP), et filtre en conséquence.
J'ai pu tester chez moi (free non dégroupé), un download d'ISO de distribution Linux sur un serveur de Free (ftp.free.fr) :
- avec "wget", pas de problème, je téléchargais au max de la ligne (850ko/s)
- avec "kbear", un client FTP graphique sous KDE, le débit était de... 10ko/s ! Le client ayant été testé auparavent en LAN, et fonctionnant normalement.
Le test a été effectué à une minute d'interval, sur le même serveur, et deux fois de suite.
Conclusion : Pour les téléchargements FTP, il faut utiliser des clients "connu". "wget" en fait parti, car il est utilisé par bon nombre de distrib Linux pour les téléchargements de paquets (apt-get, urpmi, etc...)
[^] # Re: Le libre dans tout ça
Posté par Olivier (site web personnel) . En réponse à la dépêche Google, futur grand méchant loup ?. Évalué à 3.
J'étais persuadé que FF effacait tout les cookies, y compris ceux qui étaient considés comme autorisés. Mais en fait, ceux que l'on a autorisé sont les seuls qui sont gardés.
Ca marche nickel ! Merci de l'info !
[^] # Re: Le libre dans tout ça
Posté par Olivier (site web personnel) . En réponse à la dépêche Google, futur grand méchant loup ?. Évalué à 2.
Effectivement, on peut avec ces options avoir le comportement suivant "Tout les cookies sont par défaut interdit, sauf ceux d'une 'liste blanche'".
Cependant, bon nombre de sites ont un comportement "anormal" lorqu'on leur interdit leurs cookies, ou, comme le fait FF, on leur cache le fait que le cookie n'a pas été créé.
C'est pourquoi je préfère laisser les sites poser leurs vilains petits cookies, quitte à ce que le ménage soit fait au prochain démarrage de FF (via mon script). Je ferme suffisament de fois FF par jour (ce n'est pas un problème de stabilité de l'application ou de la machine), ainsi le ménage est souvent fait.
Il n'empèche que j'utilise quand même le bouton "Bloquer" pour interdir les cookies qui reviennent trop souvents (Google, Xiti, akamai.net, etc...)
[^] # Re: Ben si...
Posté par Olivier (site web personnel) . En réponse au journal Nucléaire et journaliste. Évalué à 4.
Sans rentrer trop dans les détails (notion de "surface efficace" pour les particules en déplacement), les réacteurs à eau pressurisée (les français donc) ont pour effet de s'étouffer lorsqu'ils chauffent trop. Donc la réaction de fusion se ralentie avec la chaleur (*). Contrairement aux réacteurs des Russes, qui eux s'emballent avec la chaleur. Et donc explosent...
(*) Il n'empèche qu'une forte chaleur peut causer des dégats irrémediables sur le coeur du réacteur. Comme cela s'est passé à "Three Miles Island", aux Etats Unis (en 1979)
[^] # Re: Le libre dans tout ça
Posté par Olivier (site web personnel) . En réponse à la dépêche Google, futur grand méchant loup ?. Évalué à 8.
Cependant, il est souvent intéressant de regarder un peu en détail les connexions qui sont faites lorsque l'on utilise un site web.
Dans le cas de "alltheweb.com", toute recherche fait appel à 2 sites web, qui n'ont à priori rien à voir avec alltheweb.com, et encore moins avec la dite recherche :
Exemple chez moi :
bsav.search.yahoo.com/serv?s=xxxxxxx&t=xxxxxxxxx&_ylb=xxxxxxxxxxxxxxxx....
us.bc.yahoo.com/b?P=xxxxxxxxxxx....
Ces données sont extraites des log de Privoxy ( http://www.privoxy.org/ ), un proxy antipub, qui fait un boulot similaire à "AdBlock", mais en plus puissant.
Bien évidement, je n'utilise pas les services de Yahoo, et donc ces connexions n'ont à priori rien à faire ici. Mais en fait, en y regardant d'un peu plus près, on se rend compte que "alltheweb.com" EST yahoo.
Enfin, ce qui m'inquiète un peu plus : Tout clic sur un lien du résultat de la recherche (en vert) passe par Yahoo avant de renvoyer sur le site en question. Donc Yahoo SAIT que vous avez clicé sur ce lien là de la recherche.
Je ne sais pas si cette technique est utilisé afin de juger de la pertience de la réponse affichée. Mais en tout cas, Yahoo identifie mieux le sujet qui vous a intéressé dans la question posée.
A noter qu'en 7 ans d'utilisation de Google, je n'ai vu que 2 fois ce type de comportement (passage par le site de Google avant d'être redirigé sur le resultat de la recherche). Alors que dans le cas de "alltheweb", c'est de toute évidence systématique.
Mais je ne fais pas non plus l'appologie de Google. Le cookie qu'il place systématiquement est un outil, basique certes, permettant d'identifier les besoins de l'Internaute. Et quand aux autres outils de Google (GMail, GTalk), je ne les utilise évidement pas du fait de ce qui est écrit dans le "contrat d'utilisation" (entre autre, l'analyse par des robots des données échangées).
Je n'ai pas de solution miracle à ce problème de confidentialité, ou d'indiscrétion. Si ce n'est quelques outils de base :
- Privoxy ( http://www.privoxy.org/ ) afin de filtrer un maximum de choses. Cela supprime les http-referer, une partie des cookies, les pubs, etc...
- Le mécanisme d'exception de cookies de Firefox (Edition / Préférences / Vie privée / Cookies / Exception)
- Un petit script de ma conception, qui supprime tout les cookies à chaque démarrage de Firefox, exception faite de ceux d'une "white list". Ainsi, je ne concerve que les cookies de 3 sites dont j'ai réellement besoin (et LinuxFR est l'un de ces 3 sites). A ceux que cela intéresse, je peux envoyer le dit script par mail. Me contacter en privé pour cela.
[^] # Re: Passage sur les systèmes d'exploitation
Posté par Olivier (site web personnel) . En réponse au journal Comparatif de vulnérabilités IE-Firefox : Symantec change d'avis. Évalué à 1.
Un serveur web, tu es obligé de laisser son port 80 accessible. Mais si le patch de sécurité touche un soft / bibiotheque que peut accéder ce serveur (du PHP, une zlib, du RCP, etc...), un intrus peut accéder à la faille de sécurité. Tout simplement en passant par une requête foireuse (GET ou POST) sur le port 80.
Prend par exemple les problèmes de sécurité sur phpnuke, les blogs, etc... Au final, des serveurs ont été infectés par des escalations de privilège, via des scripts PHP, ASP, CGI-BIN, ou autre qui étaient buggés...
Et une machine pilotant des outils ne devrait même pas être connectée au reste du monde.
Non, mais la machine outil est connectée en réseau à d'autres machines outils, d'un autre fournisseur. Et pour ceux-ci, tu ne peux pas savoir ce qu'en font les gens qui y travaillent dessus. Sans même parler d'espionnage industriel, ou de volontée de nuire...
Enfin, le coup des tests sur des machines importantes, c'est valable pour les patchs sous *nix/bsd aussi...
Tout à fait. D'ailleurs, tu remarqueras que mon commentaire était généaliste (ie: quelque soit l'OS). Je n'ai parlé de Windows que pour cité un exemple concret de mon boulot.
[^] # Re: Passage sur les systèmes d'exploitation
Posté par Olivier (site web personnel) . En réponse au journal Comparatif de vulnérabilités IE-Firefox : Symantec change d'avis. Évalué à 8.
Autant un système de mise à jour automatique peut bien s'utiliser dans un environnement personnel, autant dans le milieu professionel cela pose problème :
- Comment être sûr à 100% que le patch ne va pas planter la machine ? Qui n'a jamais vu un SP de Windows complètement casser l'OS, et devoir tout réinstaller au redémarrage suivant ?
- Quel va être l'impact du patch sur la machine, et sur les autres applications qui y tournent dessus ? Un patch peut produire des incompatibilités avec un code applicatif existant (du PHP, de l'ASP, du SQL, etc...), et peut empêcher l'application "maison" de continuer à fonctionner.
- Après l'installation du patch, il faudra surement arrêter/redémarrer quelques services, voir rebooter la machine. Ce temps d'arrêt va impacter le temps pendant lequel la machine fournit son service. Dans le milieu industriel où je travaille par exemple (machine outil), le reboot d'un PC Windows va créer jusqu'à 4h d'arrêt de l'outil de production (le temps de remettre l'outil de production en température, et de le qualifier). Et bien sûr, chaque minute d'arrêt de production de la machine coûte enormément d'argent...
- Pour bien faire, il faudrait installer le patch sur une machine de test, qui simule l'utilisation du serveur complet. Et évidement, il faut pouvoir tester cette configuration pendant plusieurs jours ou semaines, afin de vérifier qu'il n'y a réellement pas d'impact néfast du patch. Pendant ce temps là, la machine de production est toujours exposé aux vulnérabilités.
Tout ceci explique pourquoi de nombreux ordinateurs ne sont pas patchés dans le milieu professionnel... Les contraintes de productions passe avant celle de sécurité. C'est dommage, mais c'est comme cela.
[^] # Re: Init
Posté par Olivier (site web personnel) . En réponse à la dépêche Accelerated Knoppix : pour des Live-CD plus rapides. Évalué à 0.
Tout simplement pour rendre la machine plus flexible, et capable de s'adapter "out of the box" sur une nouvelle machine/configuration.
Imagines :
- Tu installes ta distribution favorite sur une machine "A".
- Tu démontes le disque dur, et tu le mets dans une machine "B", physiquement différente de "A" : Pas les mêmes cartes mêres, réseaux, vidéo, etc...
- Lors du boot de "B", il y a de très fortes chances pour que le Linux se configure tout seul sur ce nouveau hardware, et soit opérationnel tout de suite.
C'est l'usage que l'on fait de l'Informatique au jour d'aujourd'hui (2006) qui veut cela : La configuration d'une machine doit être la plus transparente possible du point de vue de l'ordinateur. Même si cela doit couter une débauche de temps CPU, et de mémoire vive...
On ne change pas de matériel touts le temps et il suffirait d'ajouter un outil pour voir les changements (quitte à rebooter si nécéssaire).
Tu aimes tant que cela les reboots de Windows ? :)
Et je me répète: BeOS faisait 14s *sans optimisation de l'utilisateur* et ce temps inclue le démmarrage du desktop
Et j'imagine que ton BeOS savait gérer :
- L'"export display", qui permet d'envoyer de maniètre transparente l'affichage d'une application sur un écran situé à distance
- Le multi-écrans
- Les effets de transparences, d'ombrages, etc...
- Les périphériques amovibles, genre USB, firewire, etc...
- La 3D (OpenGL)
- Le directrendering (qui permet par exemple d'afficher de la video directement sur le chipset graphique)
- Pouvait utiliser plusieurs toolkits graphiques différents (KDE, Gnome, vxWidget, OpenOffice.org, Mozilla, etc...)
- Etc...
En terme de "look pur", je me souviens de screenshots de BeOS de l'époque. Par rapport aux Windows de l'époque, c'était équivalent. Mais par rapport à ce que l'on peut avoir sur un Linux, il n'y a pas photo. Or, toute cette débauche de couleurs et d'effets graphique des Linux, il faut bien le payer à un moment donné, non ?
Pour ce qui est des serveurs présents par défaut, je pense (et j'espère ne pas me tromper) que ce n'est plus trop le cas sous Linux, d'un point de vue sécurité, c'est une très mauvaise idée!
Lance un "netstat -taupn" sur ta machine, tu auras une bonne vue des serveurs qui y tournent.
Quand à sécuriser ces serveurs, comme je l'explique ici http://olivieraj.free.fr/fr/linux/information/firewall/fw-02(...) c'est généralement faisable facilement. Sachant qu'en 2nd couche, on peut rajouter Netfilter, le firewall de Linux.
[^] # Re: Init
Posté par Olivier (site web personnel) . En réponse à la dépêche Accelerated Knoppix : pour des Live-CD plus rapides. Évalué à 4.
Il faudrait peut-être comparer ce qui est comparable : Ton BeOS n'avait pas à gérer xx interfaces réseaux différentes (et d'ailleurs, combien existait-il de drivers pour les cartes réseaux ?), du Wifi, de l'IPv6, du Bluetouth, et j'en passe et des meilleurs...
Ce que je te faire comprendre c'est qu'avec le temps, Linux s'est diversifié à un point qui n'était pas imaginable à l'époque de ton BeOS, et que dans ce cas, le nombre même de tests à faire pour démarrer le système est nettement plus conséquent.
Prenons un exemple tout simple : Le script de démarrage des couches réseaux d'un Linux. Sur ma MDK, mais c'est sensiblement la même chose pour les autres distributions, le script "/etc/init.d/network" fait 359 lignes. Dedans : du bash qui lance toutes sortes de programmes (awk, ifconfig, etc..), afin de prendre en compte plein de types de configurations de réseaux différentes. Mais si tu veux quelque chose de beaucoup plus rapide pour UNE configuration particulière, cela peut se régler en 3 lignes de bash. Voir à quelques lignes de C, ce qui permettrait en plus d'éviter de lancer l'interpereur bash.
Pourquoi ne pas plus optimiser ainsi tout les scripts alors ? Parce qu'il perdrait pas mal de lisibilité pour les utilisateurs, et qu'ils seraient forcément moins souples.
De plus, il existe tout un tas de programmes qui se chargent automatiquement au démarrage de la machine : serveur de fontes, portmap, serveur SMB, serveur web, firewall, HAL, etc... Tout cela dans le but de rendre la vie de l'utilisateur plus simple, sans qu'il n'ait besoin d'activer manuellement des parties de softs lorsque l'occasion se présente. L'utilisateur veut ne pas avoir à se poser de questions lorsque qu'il est sur sa machine. Cela nécéssite donc de charger dans le système des méchanismes complexes.
Enfin, dans la philosphie de Unix/Linux, il n'est pas habituel de redémarrer son ordinateur : Ce type de machine a été conçu pour être allumé et ne (presque) pas s'arrêter. C'est l'utilisateur actuel qui a sans cesse besoin de l'éteindre et de le rallumer... Ce qui fait au passage des économies d'énergie, ce qui n'est pas forcément plus mal... ;)
Conclusion :
- Linux est long à booter : Oui
- Linux charge plein de trucs inutiles : Oui, afin de faciliter l'utilisation pour l'utilisateur "newbee".
- Le chargement de Linux peut être optimiser : Oui, et très largement :
+ Compilation du kernel pour ne charger que les modules utiles
+Ne pas charger les softs inutiles (par exemple, pour certains un serveur web n'est pas utile)
+ Ré-écriture des méchanismes d'init. Sur une machine définie, un script d'init unique de quelques dizaines de lignes permettrait de tout lancer.
[^] # Re: Ubuntu
Posté par Olivier (site web personnel) . En réponse à la dépêche Un e-mag pour Mandriva Linux. Évalué à 9.
C'est un peu de la mauvaise fois quand même...
Il te suffit d'aller sur un des nombreux mirroirs Français qui heberge des distributions Linux, le plus rapide étant ftp.lip6.fr (serveur de l'université de Jussieu, à Paris) :
ftp://ftp.lip6.fr
A partir de la racine, tu trouves très facilement ceci (ce n'est pas dur, il suffit de lire le nom des répertoires) :
ftp://ftp.lip6.fr/pub/linux/distributions/mandrake-iso/2006.(...)
He hop, il ne reste plus qu'à télécharger la ou les ISO que tu veux, tout cela parfaitement gratuitement et légalement.
Dans le même esprit, et si tu es un tout petit peu habitué aux CD MDV, tu trouveras facilement
ftp://ftp.lip6.fr/pub/linux/distributions/Mandrivalinux/offi(...)
C'est une image ISO de 13Mo, qui te permet de faire une install de MDV à partir du réseau (il faut pour cela une connexion ADSL)
Quand à la liste des mirroirs de la version Free de MDV, j'ai mis exactement 45s pour la trouver : http://wwwnew.mandriva.com/fr/downloads/mirrors/2006iso (à partir de l'URL http://www.mandriva.fr/ ) . Et encore, le réseau se trainait... ;)
Bref, prétendre qu'une MDV c'est dur à trouver, c'est carrément abuser...
[^] # Re: Oh l'autre ...
Posté par Olivier (site web personnel) . En réponse au journal Novell et les effet graphique. Évalué à 5.
Rien d'illégal, donc...
# Documentation Firewall en Français
Posté par Olivier (site web personnel) . En réponse au message IPTABLES. Évalué à 1.
je suis l'auteur de cette documentation, en Français, sur le firewall et la sécurité informatique sous Linux : http://olivieraj.free.fr/fr/linux/information/firewall/
Tu devrais y trouver des informations intéressantes
# Info
Posté par Olivier (site web personnel) . En réponse au journal Les mandriva serait-elle espionnées par Mandriva ?. Évalué à 1.
http://wwwnew.mandriva.com/
C'est un site d'information pour Mandriva, en fait c'est même carrément la "home page" de http://www.mandriva.com/ , puique www.mandriva.com est redirigé sur wwwnew.mandriva.com :
[olivier@. ~]$ telnet www.mandriva.com 80
Trying 212.85.150.181...
Connected to www.mandriva.com (212.85.150.181).
Escape character is '^]'.
GET http://www.mandriva.com/index.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
301 Moved Permanently
Moved Permanently
The document has moved A HREF="http://wwwnew.mandriva.com/index.html">here /A.
Apache-AdvancedExtranetServer/1.3.27 Server at www.mandriva.com Port 80
Connection closed by foreign host.
Par contre, le fait que tu vois des connexions sur "ns2.moondrake.net", vient de la manière dont Mandriva à rempli ses DNS.
Je m'explique :
- "netstat" voit des connexions vers l'adresse IP 212.85.150.181
- Il lance alors une resolution de nom. C'est l'équivalent à la commande "host 212.85.150.181". Cela retourne le "ns2.moondrake.net" que tu reçois. Et ce nom est typiquement celui que l'on donne à un DNS.
- Mais tu y fais dessus des requêtes HTTP. Des requêtes HTTP sur un serveur DNS ? C'est quoi ce bins ? Pas de panique !! Cette adresse IP heberge aussi d'autres serveurs/service :
[olivier@. ~]$ host 212.85.150.181
181.150.85.212.in-addr.arpa is an alias for 181.160/27.150.85.212.in-addr.arpa.
181.160/27.150.85.212.in-addr.arpa domain name pointer ns2.moondrake.net.
[olivier@. ~]$ host www.mandriva.com
www.mandriva.com has address 212.85.150.181
Donc en fait, le problème vient de connexions qui sont faites sur www.mandriva.com . Quel est le programme qui en est la cause, je ne sais pas (encore). Mais cela ne ressemble pas encore trop à un spyware, ou à un truc trop louche.
[^] # Re: pareil pour gnome
Posté par Olivier (site web personnel) . En réponse au journal Un truc qui manque à Linux. Évalué à 3.
Renseignes-toi un peu sur le protocole SMB (qui à l'origine a été conçu par IBM, et repris par Microsoft). Tout se base sur un mecanisme de boadcasts, envoyés régulièrement sur le réseau. C'est le "envoyés régulièrement" qui fait que ton Windows n'a pas vu tout de suite le partage.
Tips Windows (je sais, c'est hors sujet ici). Sous l'explorateur, tu as un menu pour rechercher un ordinateur sur le réseau. Utilises-le, et tu verras apparaître plus rapidement le partage.
2°) Je peux accéder à ce dossier en lecture depuis un PC sous Mandriva, par contre il m'est impossible d'y accéder depuis un PC sous Windows XP (un login/password m'est réclamé)
Utilise un login/password vide : Si ton samba a été configuré en mode "share", il n'y aura probablement pas de login/password à utilise. Chez moi, même si j'ai configuré mon samba pour qu'il soit accessible sans login/password, Windows en demande quand même un.
[^] # Re: Oui, mais que faire ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 3.
Microsoft fait déjà quelque chose de similaire. Lorsque tu installes un driver qui n'est pas "certifié Microsoft", tu as une belle boîte de dialogue (avec un icone de "warning" jaune) qui te dit que tu risques des problèmes d'instabilité, du fait que ces drivers n'a pas été testé par les laboratoires MS.
[^] # Re: Composite ?
Posté par Olivier (site web personnel) . En réponse au journal Nouveau pilote nvidia sortis. Évalué à 1.
# Avant toute chose, il faut se renseigner...
Posté par Olivier (site web personnel) . En réponse au journal Fait n°1 : Linux n'est pas sujet à la fragmentation.... Évalué à 10.
La raison pour laquelle les partitions ext2/3 ne fragmentent pas, ou peu, c'est qu'elles gardent en mémoire sur le disque dur, une table indiquant la taille des blocs libres. Ainsi, lorsque l'OS veut écrire un fichier, il choisit le bloc de la plus petite taille possible et qui peut contenir le fichier en un seul morceau. En comparaison, les FAT12/16/32 de Windows n'ont pas ce type de mécanisme (et pour NTFS, je ne sais pas).
Avec un DD presque plein en permanence, surtout contenant des fichiers de grosse taille (j'imagine que ton aMule ne fait que télécharger des images ISO de distributions Linux, au format CD ou DVD...), il ne peut rester comme place sur le disque que des blocs éparses. Donc forcément le FS se fragmente lorsque tu veux rajouter des données, car il ne peut pas trouver un emplacement continue de 700Mo ou 4.7Go.
De plus, aMule (et les autres softs de P2P) amplifie le phénomène de fragmentation, car ils stockent initialement les fichiers téléchargés sous la forme de petits blocs, téléchargés indépendament sur Internet (je suppose par la que tu commences toujours par télécharger des images ISO de distributions Linux, et que tu n'en mets donc pas "spontanement" en partage). Si tu télécharges plusieurs fichiers en parallèle, tu aura donc une partie de ton DD qui sera composé de multiples petits fichiers temporaires
Une fois que qu'une image ISO sera coomplètement téléchargée, *Mule recréera un fichier unique, là où il y a de la place. Et comme ton DD est plein, ce sera à l'emplacement d'anciens petits blocs temporaires
Si tu utilisais un *Mule sous Windows, tu verrais exactement le même phénomène.
Quand à ceci :
Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique
Le "pas très logique" confirme bien que tu ne comprends pas le phénomène de fragmentation. C'est pourtant le seul moyen de ne pas fragmenter un DD, lorsque l'on n'utilise pas un soft qui manipule directement le FS au niveau des blocs (donc un soft de defragmentation)
Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)
Au vu de tes journaux, et de ton niveau de connaissances techniques de Linux (je ne parle pas d'experiences, ou d'experimentations), les trollometres vont exploser...
[^] # Re: re
Posté par Olivier (site web personnel) . En réponse au message Boutons de bas de page. Évalué à 1.
Merci !
# Règles précédentes ?
Posté par Olivier (site web personnel) . En réponse au message Logguer les connexions ssh sortantes. Évalué à 1.
iptable -A OUTPUT -j ACCEPT
Sinon, envoie-nous le résultat de :
iptables -L -n -v
[^] # Re: Plus qu'un nouveau Firefox, la réponse face à IE 7...
Posté par Olivier (site web personnel) . En réponse au journal Un nouveau Firefox avant Noël ?. Évalué à 1.
Personnellment, j'utilise Privoxy ( http://privoxy.org/ ), et je n'ai nullement besoin de adblock !!