Olivier a écrit 890 commentaires

Pourquoi utiliser les service de messagerie de son FAI ?
Parce, par exemple, qu'il en propose un...
Personnellement, j'ai 2 adresses email : Une pour les amis et la famille, donc à distribution réduite, et une "publique", lié à mon site web chez free. Cette 2nd adresse me sert pour mes communications à "destination de tout Internet", et c'est moins gênant si elle est spammée, ou qu'elle tombe en rade.

L'adresse changera si tu change de FAI,
Il me semble que ce n'est pas le cas de Free. Tu peux abandonner Free comme FAI, mais tu conserve ton adresse email en réception et en webmail. Par contre, tu ne peux plus utiliser leur serveur SMTP.

Enfin, dans le cas ou HADOPI veuille t'envoyer un petit courier disant que ton adresse IP a été prise en flagrant délit de téléchargement illicite, c'est cette adresse email qui sera par défaut utilisé par le FAI.

La légerté.

GeeXbox permet de visionner un flux de type "DivX" sur une machine à base de PII-450 / 64Mo de mémoire et une carte vidéo de type TNT2 / GeForce 2. Si on l'installe sur un disque dur, il faut environ 20Mo d'espace de stockage. Et sur cette configuration, cela boot en environ 30s.

C'est l'idéal si on veut recycler du vieux materiel (datant d'avant 2000).

A coté de cela, XBMC demande au minimum une carte ayant des fonction 3D (OpenGL), un PIV, et sans doute un paquet de RAM : http://xbmc.org/wiki/?title=Supported_hardware ...

Certes, on trouve actuellement des machines très peu chères qui peuvent supporter XBMC. Mais si on peut recycler du vieux matériel, c'est mieux pour la planète, non ?

Quitte à faire un gros HS, autant le faire tant que l'on est encore en 2009...

A priori, tu est forcé d'avoir un Windows qui tourne sur cette machine si tu veux flasher ton BIOS. Certain constructeurs fournissent encore des programmes sous DOS/FreeDOS pour les flasher, mais cela ne semble pas être le cas du tient.

Si la solution du dual boot Linux+Windows n'est pas possible, tu peux toujours installer temporairement un autre disque dur à la place celui que tu as actuellement, voir de demander à une connaissance de te prêter son disque dur le temps de la manip (bien que je pense que cela doit rompre la licence OEM du disque que l'on te prête).

Sinon, il existe effectivement des solutions pour installer un Windows XP sur une clé USB, mais c'est assez "spécial", car il faut mettre en place un driver USB qui ne fait pas de "reset" du contrôleur USB lors de son démarrage. Tu peux regarder du coté de http://www.pcinpact.com/actu/news/27780-Une-methode-pour-ins(...) ou de "BartPE" http://www.generation-nt.com/creer-son-cd-bart-pe-avec-windo(...)

Il y a un truc que je n'ai jamais compris :
- que ces entreprise utilisent des softs GPL pour faire marcher un busybox ou un kernel Linux simplifié, cela ne pose pas de problème
- qu'elles refusent de diffuser le code source des modifications qu'elles ont pu faire est par contre étonnant : Qu'est-ce qu'elles craignent ? Que l'on voit comment leurs modifications font pour discuter avec leur hardware spécifique ?
- dans ce cas, qu'est-ce qui leur interdit de créer un bon gros module binaire bien obscure, qui lui n'est pas distribué sous GPL, mais intégré dans un kernel Linux standard ? La seule chose à publier serait alors la couche de connexion entre le kernel Linux et le module binaire, mais cela ne contient généralement pas d'informations "secrètes".
- pour faire simple, qu'est-ce qui les empêche de faire la même chose que NVIDIA et ATI, avec leurs drivers vidéo proprio pour Linux ?

Pour ce qui est de la couche de décodage de DRM/autre, c'est la même chose : Qu'est-ce qui les empêche de développer un plugin/module pour "Mplayer" ou "Xine", qui se charge de cette partie qui "doit rester secrète" ? Et qui bien entendu n'est pas distribué en GPL. Mplayer et Xine par exemple possède déjà des mécanismes gérant en "externe" le CSS ("decss"), qui est semblable à ces DRM. Là encore, il ne serait nécessaire que de publier la "glue" entre le logiciel de visualisation du flux vidéo, et le plugin/module binaire.

Mais on voit bien le soucis. Si un jour, j'ajoute un kernel 2.6.33, mon option GRUB_DEFAULT=2 ne sera probablement plus correcte...

Dans le cas de Debian Squeeze/Testing, le rajout d'un nouveau kernel fera apparaitre ceci :

2.6.33
2.6.33 recovery
2.6.32
2.6.32 recovery
2.6.30-2
2.6.30-2 recovery
Donc par défaut, tu booteras effectivement sur le 2.6.32, et non plus sur le 2.6.30-2.

Mais en fait, sur Debian, ce comportement est exactement le même qu'avec GRUB1 : Debian affiche au démarrage la liste des kernel installés, et ne bouge pas la ligne du curseur à l'affichage du menu. C'est la liste en-dessous qui change.

ajoute une contrainte supplémentaire (pas touche au fichier de conf, ça serait trop facile)

Le /boot/grub/grub.cfg n'est mis à jour que si tu lances la commande "update-grub"/"update-grub2". Entre temps, tu peux très bien modifier ce fichier à la main, histoire de faire des tests, ou des bricolages sur un coin de table.

"update-grub"/"update-grub2" servent entre autre à faire des vérifications sur les UUID des disques durs, et permettent d'écrire un fichier de configuration "grub.cfg" supposé marché correctement, sans intervention de l'utilisateur. Mais rien ne t'empêcher d'écrire ton "grub.cfg" "from scratch", comment auparavant.

Enfin, la seule commande qui ne soit pas remplaçable est le "grub-install /dev/xxxxx", qui modifie le MBR.Mais généralement, tu n'as besoin de lancer cette commande qu'une seule fois.

Personnellement, j'ai eu du mal à swicher de GRUB à GRUB2. Et bien que ce dernier ne soit pas parfais (il manque encore des fonctionnalités), je dois dire que je ne regrette pas plus que cela ce switch, car GRUB2 a un gros potentiel.

Tu es conscient qu'un paquet de gens ont volontairement abandonné leur client mail pour passer sur webmail ?

J'en vois plusieurs raisons :
- internet s'est très démocratisé depuis une quinzaine d'année. Avant, les (rares) personnes qui avaient Internet ne se posaient pas la question d'accéder aux mails depuis ailleurs que chez eux, leur petit modem 33kb/s. A l'époque, un client lourd de mail était la solution la plus classique
Maintenant, Internet est presque partout, les gens veulent pouvoir accéder à leurs mails depuis n'importe où (un cybercafé, le PC du bureau ou d'un ami, le hotspot wifi du coin, ...), donc le webmail est la solution la plus simple, car elle ne nécessite qu'un navigateur

- le webmail, c'est simple. Certains utilisateurs n'ont même pas conscience que les possibilités d''Internet c'est autre chose que l'icone d'un "E" bleu sur leur bureau, voir d'un panda roux. A partir de là, il est logique qu'ils lisent leur mail avec un webmail.

- les FAI font tout pour faciliter cette simplicité. Beaucoup d'internautes néophites ne conçoivent pas (et n'ont même pas l'idée) que leur point de départ de navigation soit autre chose que le moteur de recherche du portail de leur FAI. Et que leur mail soit autre chose qu'un lien "Mon courrier" dans la dite page


- le webmail que j'utilise me permet de sauvegarder mes emails sur un disque local, et je ne m'en prive pas


Personnellement, j'ai 2 webmail et aucun ne me le permettent.

Et si tu dis que le webmail permet de sauver tes mails sur ton disque local, c'est que le webmail utilise probablement un ActiveX, une applet Java signé, un plugin, une extension FF, etc... qui le permet. Bref, tu laisses un binaire que tu ne connais pas (et dont tu n'as probablement pas le code source) accéder à ton disque dur. C'est ton choix, mais ce n'est pas le mien que de laisser n'importe quel soft triturer mon disque dur ou mon /home.


- le webmail que j'utilise ne charge pas les images dans les mails en HTML et, au passage, le filtre antispam du webmail que j'utilise fait partie des plus efficace que j'ai rencontré


Bien entendu, tu as contrôlé ceci en utilisant un proxy ou en sniffant les trames IP, afin de bien vérifier que ton navigateur ne faisait pas de connexions en-dehors du webmail ? Pour l'expediteur du mail, Il est enfantin de "piéger" le mail en dissimulant dans le corps du mail:
- soit du javascript qui fait une requête GET/POST vers un site contrôlé par lespammeur
- soit une fausse image invisible de 1x1 pixel, indétectable par l'oeil de l'utilisateur

Si je vais sur le site de MS et que je regarde les "System Requirements" de Windows 7 http://www.microsoft.com/windows/windows-7/get/system-requir(...) , je vois :


If you want to run Windows 7 on your PC, here's what it takes:
* 1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor
* 1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit)


Indique à tes collègues du marketing qu'ils peuvent faire descendre la limite à 512Mo...

Les clients lourds de mail, c'est quand même :
- La fluidité d'utilisation qui n'est pas dépendante de la taille de connexion ADSL, ou de la charge serveur du webmail

- La possibilité d'avoir tout ses mails archivés en local, voir sur plusieurs machines (différents clients IMAP+réplication de mails), archivage de mail sur disques externes, DVD, etc...

- La lecture/écriture de mail en offline (Gmail le fait depuis peu, mais pas les autres webmail)

- La suppression de toutes ces ###### d'images externes au mail, qui servent à envoyer des informations aux spameurs. Par exemple, un mail HTML qui contienne :
<img href=http://vilain.spammeur.com/images/top_modele.png?source=util(...)

- La suppression de la pub ! (tout le monde n'a pas un bon filtrage de configuré)

- La possibilité de ne pas avoir d'adresse email associé aux recherches internet : Avec les cookies, l'ami Google/MS/Yahoo, etc... associe les mots-clés de recherche à des adresses email

- etc...

Bref, le webmail c'est pratique lorsque l'on n'a pas le choix. Mais pour un vrai confort, rien ne vaut le client lourd.

Hormis le bête coup de "pas de chance" / "loi des séries", le problème peut aussi venir d'un courant électrique 220v qui ne soit pas stable en tension ou en fréquence.

As-tu un filtre / onduleur sur la prise électrique de l'écran ?

Depuis la Ubuntu 9.10, beaucoup de site parlent de désactiver IPv6 en utilisant grub :

http://linux.leunen.com/?p=719

Il existe d'autres techniques pour d'autres distribs http://www.dsfc.net/logiciel-libre/linux/desactiver-ipv6-a-p(...)

Après le reboot, tu ne devrais plus d'avoir ipv6 : le "ifconfig ne devrait plus que te montrer une adresse IP par interface réseau, en x.x.x.x. Et cela devrait être moins lent pour toutes les applis.

Franchement, je n'y ai jamais trouvé des informations intéressantes, ou du moins, utiles pour résoudre mes problèmes.

J'y jette toujours un coup d'oeil, pour le cas cas où, mais je sais que cela se terminera invariablement par une recherche sur Internet, ou au pire, à une analyse des différents scripts que constituent les programmes.

J'ai lu les premiers épisodes avec intérêt, mais je n'ai pas eu l'occasion de retourner sur ton site pour lire la suite.
Je viens de m'abonner au RSS, comme cela je ne raterai pas les prochains.
Merci pour ton travail, c'est très réussi !

Dans le cas de Debian Squeeze/Testing, le paquet de GRUB2 a modifié tout seul le /boot/grub/menu.lst, afin de rajouter une entrée supplémentaire. Celle-ci permet de "chainer" GRUB2 à GRUB1 lors du boot, afin de tester sans risque GRUB2.

Le truc, c'est que l'installation du paquet demande à l'utilisateur si il veut ou non "chainer" GRUB2. Si tu réponds "non", GRUB2 est installé directement dans le MBR.

Certes, le paquet GRUB1 est toujours présent, et tu peux toujours réinstaller à coup du "/usr/sbin/grub / root (hdx,x) / setup (hdx) / exit". Mais le MBR a été modifié.

Debian fait des choses simples, mais compliquées pour l'utilisateur.

Je dirais plutôt qu'il y a une "philosophie Debian" : Certains choix techniques sont des vrais transgressions de ce qu'à conçu le développeur (je pense par exemple au /boot/grub/menu.lst de GRUB1), mais d'autres idées sont plutôt bonnes. Par exemple, la gestions des modules avec un /etc/modprobe.d/ au lieux d'un /etc/modprobe.conf, qui permet à chaque paquet de rajouter son propre fichier de configuration des modules.

La manière dont les paquets kernel sont gérés est aussi assez "space", et la première fois que j'y ai touché, je me suis demandé si il était vraiment sérieux de laisser la gestion de leur kernel aux Debianistes... Mais après avoir compris comment eux ils avaient conçu la chose, on se dit "Mais oui en fait, c'est logique".

Le gros problème que j'ai eu avec Debian au début, c'est que les modifications qu'ils apportent ne se retrouvent pas forcément dans les "man". Il faut alors chercher sur le net les informations sur "Debianneries", ce qui n'est pas forcément facile.

Au final, j'ai migré sur Debian Squeeze/Testing toutes mes machines, ainsi que celles de la famille. Et j'installe des Ubuntu sur les machines de collègues qui veulent s'essayer à Linux parce que :
1) ils peuvent trouver de la doc sur http://doc.ubuntu-fr.org/
2) une Ubuntu et une Debian s'administre de manière assez similaire, c'est donc plus facile pour moi
3) je trouve que Debian Squeeze/Testing n'est pas administrable pour un néophyte qui veut/peut vouloir découvrir comment Linux marche. Par contre ,c'est utilisable par n'importe quel néophyte

Personnellement, je suis en Testing depuis un bout de temps (déjà, à l'époque de Lenny).

En terme fiabilité, je dois dire que je n'ai pas de gros soucis. Mais indubitablement, c'est une version un peu "vivace" (un peu comme un cheval que l'on pensait avoir dressé, mais qui fait une ruades de temps en temps), dans le sens où les mises à jours nécessitent de faire un minimum attention. Et il y a de temps en temps des surprises. Les derniers en date était GRUB2 et aussi Xorg + kernel 2.6.30 (qui ont tout cassé avec les drivers nvidia-legacy-7xxx, et ATI fglrx)

C'est ce qui m'intéresse avec Testing : Des versions de softs récentes, suffisamment testés pour ne pas tout planter tout le temps. Mais qui réserve des surprises, qui forcent l'utilisateur à ne pas s'endormir sur sa machine. Recherche d'info dans les man, les doc, sur le net, analyse des scripts, etc...

En fait, cela permet d'apprendre plein de choses, au fur et à mesure que les changements arrivent.

Sur mon portable de boulot, je fais des actions similaires aux tiennes :
- hibernation du Windows
- reboot du Linux (Debian Squeeze/Testing) pour travailler sur des applis réseaux

Afin d'éviter les ennuis que tu indiques, j'ai forcé dans mon /etc/fstab 2 choses:
- la partition windows n'est monté QUE manuellement
- par défaut, elle est montée en Read-Only :

cat /etc:fstab :
/dev/hda1 /mnt/windows_c ntfs-3g noauto,ro,user,uid=1000,gid=1000 0 0

L'inconvénient, c'est qu'il faut être root pour monter la partition :

sudo mount /mnt/windows_c

Si, je dis bien SI, j'ai précédemment arrête le Windows par un "shutdown", alors je peux alors monter le Windows en lecture/écriture :

sudo mount -o rw /mnt/windows_c

A noter que j'ai déjà utilisé un LiveCD "PuppyLinux" : Lorsque celui-ci détecte que la partition Windows est en hibernation, alors il ne permet de la monter qu'en lecture seul.

Pour en revenir à Ubuntu, oui je pense que c'est un bug, ou à une mauvaise configuration de udev, qui force le montage en lecture/écriture de ntfs-3g.

Et oui, c'est complètement aberrant de modifier un système de fichier lorsque celui-ci est en hibernation. Aucun OS ne peut supporter cela, et cela casse tout.

Je suis d'accord avec toi, un utilisateur non-root n'a pas à installer un soft dans le "/".

Le root peut connaitre des informations sur le système que l'utilisateur lambda ne connait pas, et l'installation de paquet supplémentaires peut mettre le système à mal.

Récemment, sur Debian Squeeze/Testing j'ai eu des mises à jour qui m'ont causé quelques soucis (GRUB2, Compiz, xorg-server, ...), du fait de spécificités des machines, ou de vieux problèmes bien vicieux enfouis dans le système de fichiers. J'ai mis plusieurs jours à m'en sortir, et heureusement que les machines en question étaient en local, et non pas à distance, sinon cela n'aurait pas été corrigeable facilement.

Un peu plus bas, il est écrit que rien n'empêche un utilisateur de compiler un soft dans son $HOME, voir de s'y installer toute une chaine de compilation dedans. Certes, mais cela demande des connaissances informatiques assez poussées quand même, et en tout cas largement plus que de double-cliquer sur un package.

Le jour où "mes utilisateurs" (famille, amis, collègues de boulot auquel j'installe des Linux perso) aurons atteint un tel niveau de compétence de compilation, alors je les laisserai administrer par eux-même leur machine (de toute façon, ils connaissent déjà leur mot de passe root).

Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global.

C'est faux, les Windows 1.x -> 3.x, 95, 98, Me ont toujours autorisés les utilisateurs à installer n'importe quoi sur tout le système. Du moins, dans leur configuration par défaut (sans usage du "policykit").

En même temps, une entreprise qui laisse un partage CIFS (ex SMB) accessible de l'extérieur... L'attaquant doit donc être déjà dans le réseau local de l'entreprise.

Parmi les cas très classiques d'infection, il y a le portable pro de l'employé utilisé pour terminer un rapport pendant le WE, et utilisé pour surfer sur le web (éventuellement à titre professionnel, par exemple pour faire des recherche). Le portable se prend un virus à ce moment-là, et le ramène tranquillement dans le réseau de l'entreprise, le lundi matin...

Le routeur/firewall/proxy de la boîte est ainsi complètement contourné, et le virus peut ainsi se farcir tout le joli réseau interne en 192.168.x.y/10.x.y.y, avant éventuellement de se lancer à des connexions externes.

La version finale, sans doute pas. Les dev de GRUB* doivent avoir encore des choses à intégrer avant de passer à la version 2.0.

Mais comme souvent dans le LL, des versions inférieurs à du X.0 (X étant supérieur à 1) ne sont pas synonyme de code de mauvaise qualité et inutilisable.

Entre un pilote de chasse qui doit continuer à manipuler ses systèmes de surveillances, d'armes, de brouillage, de propulsion, de communication, etc..., le tout sous +6G, et un utilisateur d'informatique, tranquillement assis devant sa machine, il y a une petite différence quand même ! ;)

Comme dit plus bas, le /etc/grub.d/40_custom est présent afin de rajouter ses propres "commandes GRUB2", ce qui est suffisant pour rajouter au "/boot/grub/grub.cfg" une entrée écrite à la main par l'utilisateur.

De plus, le /etc/default/grub permet de customiser, avec quelques moyen simples, son GRUB2. Personnellement, j'ai rajouté un "ipv6.disable=1" au "GRUB_CMDLINE_LINUX=", afin de désactiver complètement ipv6 (merci au passage aux forums Ubuntu qui en parlent).

Pour avoir récemment installé ou mis à jour un paquets de machines Debian Squeeze/Testing et Ubuntu 9.10, je dois dire que la méthode "Unbutu" pour démarrer un Windows via GRUB2 est mieux conçu que celle de Debian :


### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Microsoft Windows XP Professionnel (on /dev/sda1)" {
insmod ntfs
set root=(hd0,1)
search --no-floppy --fs-uuid --set xxxxxxxxxxxxxxxxxxx
drivemap -s (hd0) ${root}
chainloader +1
}


En effet, le "drivemap -s (hd0) ${root}" permet proprement de démarrer un Windows installé sur un disque non-bootable, via une inversion, au niveau du BIOS, des 2 disques. Auparavant, cela était fait dans GRUB 1 par la commande "map". Mais là, telle que c'est écrit, cette instruction est "générique", et fonctionne quelque soit le disque sur lequel est installé Windows.

J'ai beaucoup utilisé GRUB 1 "à la mano", afin de résoudre des problèmes de muti-boot un peu vicieux, et le passage à GRUB2 m'inquiétait, du fait que je n'avais pas les bons outils pour répondre aux même besoins qu'avec GRUB 1. Typiquement : "Comment restaurer le MBR de GRUB2, une fois que Windows à ré-écrit le sien, et empêche de booter Linux ?."

La lecture de http://grub.enbug.org/GRUB2LiveCDInstallGuide-FR m'a beaucoup aidé.

On peut résumé par ceci :

+ Boot sur un live-CD

+ Recherche de toutes les partitions de tous les disques :
fdisk -l

+ Montage du / :
mkdir /mnt/restore
mount /dev/sda2 /mnt/restore

+ Montage du /boot, si il est à part :
mount /dev/sda1 /mnt/restore/boot

+ Montage du /dev, en utilisant celui du live-CD :
mount --bind /dev /mnt/restore/dev

+ Chroot dans le linux monté :
chroot /mnt/restore
OU
chroot /mnt/restore /bin/xxxx
ou "xxxx" est le nom de votre shell préféré

+ Si nécessaire, re-installation du paquet GRUB2 :
aptitude install grub-pc

+ Vérifier la cohérance du /boot/grub/devicemap

+ Création d'un nouveau /boot/grub/grub.cfg :
update-grub

+ Installation de GRUB2 dans le MBR du /dev/sda :
grub-install /dev/sda
OU essayer "grub-install --recheck /dev/sda" si cela rate

+ Sortie du chroot :
exit

+ Demontage du /dev :
umount /mnt/restore/dev

+ Demontage du /boot :
umount /mnt/restore/boot

+ Demontage du / :
umount /mnt/restore

+ Redémarrer la machine sur le disque dur...

Je ne dis pas que le stockage en "non-clair" (comme cela, je n'utilise pas le mot "chiffrage" ou "obfuscation") est quelque chose de 100% sécurisé.

Mais tu admettras qu'il y a une différence entre :
- un virus qui tape directement en UPnP sur un routeur/box sans mot de passe, afin de s'ouvrir un port
- et un autre qui :
&bnsp;&bnsp;+ soit sniff les trames IP
&bnsp;&bnsp;+ soit possède une connaissance de divers logiciels qui seraient susceptibles de posséder le mot de passe UPnP

Le 1er me semble plus facile à coder, et plus "discret" en terme de taille de binaire
Mais je ne nie pas que le 2nd est techniquement faisable.

Quoi qu'il en soit, la meilleur pratique est, comme je le disais au début de cette discussion, de désactiver purement et simplement le UPnP, et de tout configurer une bonne fois pour toute le routeur/box via son interface.

PS: Je n'avais pas lu ta signature jusqu'à présent... ;)

Je donne des exemples simples, pour que tout le monde comprenne...