Olivier a écrit 889 commentaires

Je ne suis pas sûr de comprendre la question.

Si c'est de savoir si j'ai écris un rapport de bug, non je ne m'en suis pas donné la peine. C'était en 2006 cette histoire-là...

Je viens de refaire le test sur ma Debian Squeeze/Testing, avec le fichier host de l'époque, et le problème n'apparaît plus. Je suppose que cela a été réglé à un moment ou un autre.

Bien d'accord avec toi.

Mais comme les softs ne vont généralement pas interroger directement le /etc/hosts, mais passent par des librairies communes pour le faire (libc ?), si crash il y a, c'est la responsabilité de ces librairies-là.

Après, il est possible que Pidgin crashait suite à un code d'erreur que la librairie lui remontait, et qu'il ne comprenait pas (parce que, par exemple, non codé dans le soft).

Un ami a un jour installé un tel fichier /etc/hosts, d'une taille d'environ 70Ko. Quelques moins plus tard, il me contacte pour me dire que son pidgin (client XMPP) ne marche pas, et qu'il crashait à chaque démarrage.

A grand coup de "strace", j'ai analysé ce que faisait son pidgin, en comparant au même soft installé sur ma machine (nos deux machines avaient la même distribution, et le même niveau de mise à jour).

Finalement, il s'est avéré que pidgin plantait à cause de ce fichier /etc/hosts trop gros. En le remplaçant par un fichier plus simple (1 ligne), les crash ont disparus.

Bref, pour moi les conséquences sur les applis de l'utilisation d'une telle méthode de filtrage ne sont pas forcément anodines.

L'utilisateur voulait virtualiser Windows, ce qui implique qu'il y ait en même temps dans la mémoire de la machine :
- Linux
- Apache, outils de dev web, etc...
- VirtualBox
-> Seven
-> IE
-> Photoshop ?

A mon avis, cela commence à faire beaucoup pour 2Go de ram.

Le Windows serait un XP, cela ne poserait pas de problème.

2 Go de mémoire pour faire de la virtualisation, cela me paraît un peu léger. Je ne dis pas que cela ne marchera pas, mais simplement que cela risque de "swaper", surtout si le Windows est plus qu'un Windows XP.

Vu le prix, je te recommande de passer à 4Go

Quand à Lenovo, ils sont généralement solides, mais le prix n'est pas donné.

1ère partie du post:
mais de là à prendre le risque de quitter son boulot pour un système d'exploitation, je trouve cela ahurissant

Dans la précédente boîte internationale dans laquelle je travaillais, une partie grandissante de nos collaborateurs étaient des développeurs indiens. Des discussions que j'avais eu avec leur hiérarchie étaient que les dit développeurs étaient capables de changer de boîte du jour au lendemain, si la boîte en face leur proposait l'équivalent de 10$ de plus par mois (et cela NE représentait pas 10% d'augmentation de salaire). Certes, le marché de l'époque était très actif et concurrentiel, et donc une démission / embauche se faisait facilement.

Tout cela pour dire qu'en Inde, une partie de la population qui a accès à des jobs leur permettant de travailler derrière un ordinateur (donc "des jobs d'assez haut niveau") ne sont probablement pas réfractaire à un changement de poste. J'imagine aussi que la dynamique du marché de l'emploi en Inde doit pas mal aider. Donc de la à change de job parce qu'ils se sentiraient "frustrés" d'être sous Linux, oui, cela ne m'étonnerait pas.

2nd partie du post:
Je ne sais pas comment cela se passe dans les autres sociétés, mais dans la mienne (~14.000 employés dans le monde), bon nombre d'utilisateurs utilisent leur portable de boulot presque comme leur PC perso. Ils installent souvent des "petits" outils non-officiels (exemple : convertisseur d'unités, vlc, firefox, winrar, etc...). Leur connaissance de Windows, pas forcément énorme, leur permette de le faire.
Si nous étions sous Linux, et comme la grande majorité de ces personnes ne saurait pas installer un binaire dans son $HOME, cela créerait une frustration évidente. Après, si on leur montre comment utiliser Wine, je suppose qu'ils seraient plus content.

Je vais recadrer le contexte:
- au début de ce troll, un utilisateur a prétendu qu'installer n'importe quel soft sous windows était trivial, et qu'il ne fallait que cliquer
- j'ai répondu, par mon exemple que tout n'était pas aussi simple (problème de dépendances multiples, incompatibilité entre les dll, etc...)
- j'ai indiqué dans un PS que les mises à jours de Windows n'était pas une sinécure, et la discussion est parti en vrille à propos des méthodes "ghost" (utilisons cela en tant que terme générique).

Pour information, je connais parfaitement ce genre de mécanisme, puisqu'en 95 j'avais déjà développé mon propre système de backup/restauration de machine, pour le parc informatique d'une école. A l'époque, le ghost de Symantec n'existait pas (ou du moins je n'en n'avais pas connaissance), et mon mécanisme fonctionnait à partir de disquette NetBIOS (multi-interfaces réseau, à cause de l'hétérogénéité du parc), de "rar", d'un soft pour backuper les "noms longs" (rappel : C'était sous Windows 95, les noms longs venaient d'apparaître...), et de quelques outils développé par moi. Une disquette, un menu pour sélectionner le nom de la machine à restaurer, et le disque était réinitialisé.

Quand à mon niveau de compétence:
- J'ai été 100% sur OS MS pendant 10 ans. Puis, j'en ai eu marre de ne pas pouvoir faire confiance dans un OS qui passait son temps à m'espionner
- d'un point de vue personnel, je suis passé au "tout Linux" par moi-même, à l'époque où je n'avais qu'un modem 33kb, et que les connexions RTC coutaient chères. Et cela fait 10 ans que je n'ai pas de Windows chez moi.
- mais durant ces 10 dernières années, mon boulot est de faire 8 à 10h par jours de l'administration et du support en environnement 100% Microsoft (enfin presque, je m'occupe aussi de trucs sous vxWork, SunOS (Unix) et un tout petit peu de Linux)

Alors, même si je suis un défenseur de Linux, je ne suis pas complètement un novice en terme de connaissance de Windows. Et crois-moi, je suis confronté régulièrement à des comportements complètement bizarres de Windows, qui ne sont pas que le fait des utilisateurs.

Sinon, tu peux utiliser http://www.debian.org/distrib/packages , qui permet de faire une recherche suivant ces critères :

- Noms de paquets seulement
- Descriptions
- Noms de paquets-sources

Mais cela ne prendra en compte que les dépôts de paquets connus par Debian.

Je vois pas d'ailleurs ce qu'aptitude apporte en ligne de commande par rapport aux commandes apt...

On m'a expliqué cela il y a longtemps sur une liste de diffusion, lorsque je me suis mis à Debian : Aptitude a une meilleur gestion des dépendances que apt, notamment pour la désinstallation des paquets. Un même paquet (qui a des dépendances) installé puis désinstallé peut laisser quelques dépendances non désinstallé lorsque qu'apt est utilisé. Ce ne serait pas le cas avec aptitude.

Il semblerait que apt et aptitude n'utilisent pas la même "base de données" pour gérer les dépendances de désinstallation.

En tout cas, une chose est sur qu'il ne fait pas faire : Utiliser alternativement apt et aptitude pour installer des paquets. Dans ce cas là, l'un comme l'autre auront du mal à discerner quels sont les dépendances qui ne sont plus utiles, et te laisserons des paquets des non désinstallés. Donc, pour installer des paquets, soit on utilise "apt", soit "aptitude".

Tu connais pas ghost ?
Tu me donnes une licence ? Nan pas la peine, j'utilise CloneZilla.

Tu fais une image a jour, tu ne repartira que de ce point.
il existe des equivalents libre aussi.
Il ne te vient pas à l'esprit que la précédente sauvegarde ne convenait plus, car les besoins de l'utilisateur avaient changés ? Passage de MSOffice à OpenOffice notamment. Plus tout un tas d'applis "métier" qui étaient sur le dernier backup, et qui n'avaient plus de raison d'être.
Plutôt que de trainer toutes sortes de vieux débits de softs incomplètement désinstallés (si le "uninstall" de MS marchait réellement, il ne resterait pas tant de m... dans la base registre), il vaut mieux dans ce cas tout réinstaller from scratch.

Pas mal, tu parles des .msi qui est le seul système de paquets de Windows et qui est essentiellement utilisé par les softs M$ et autres compères à leur solde.

Ah bon ? La dernière fois que j'ai discuté avec un dev qui bossait sous environnement Windows (mais il ne bossait pas pour MS), il me vantait les avantage du ".msi", et me disait que c'était très facile à créer pour faire un package d'installation.

Ca existe sous Linux de manière portable ca ?
Il suffit que le dev veuille bien se donner la peine de faire un soft "portable", en mettant toutes les librairies nécessaire dans le .tgz. J'en connais au moins un : http://filezilla-project.org/

Tu décompresses cela dans le ~/, ou le /usr/local/, ou le /opt/ et cela marche tout seul.

Non, tu mets une version pas à jour de Windows XP, oui, mais pareil pour un Linux pas à jour.
[...]
Arrêtez de sortir des trucs sur Windows qui ont le même problème avec Linux (ne jamais mettre une vielle distro sur le net non plus)
Au jour d'aujourd'hui (2010/08/26), tu mets des versions de 2001 et non mises à jour de Windows XP et Linux, et tu comptes le nombre d'infections :
- pour le Windows, ce sera effarant
- pour le Linux, vu le nombre ridicules de virus qui circulent sur le net, et le peu de ports ouverts par défaut, tu ne verras aucune infection.

débranche ton Linux du net aussi, le problème étant surtout l'interface chaise-clavier au niveau virus. Les virus sous Linux existent aussi.

Soyons sérieux : Compare la bibliothèque de virus qui fonctionne sous Windows à celle qui existe sous Linux, et tu verras que le risque se trouve très largement en faveur de Windows.

Vis à vis des vers (virus qui attaquent de manière autonome la machine, en profitant d'un trou de sécurité dans un démon qui écoute sur le réseau), tu peux configurer un Linux pour avoir ZERO port en écoute ("netstat -taupn" vide). Ce n'est pas possible de faire la même chose sous Windows ("netstat -an" non vide). Les ports non fermés étant la cible des vers.

Tu as déjà essayé de mettre à jour un Linux de 2001 vers sa version de 2010?
Et quel serait l'intérêt ?
Linux, que ce soit une version de 2001 ou de 2010, je peux l'avoir gratuitement et de façon parfaitement légale. Donc, si la machine le permet, autant prendre la dernière version.
Windows, je l'ai acheté ~100€ en 2001. Si je veux passer à la dernière version (Seven), il faut que je repaye. Et, personnellement, je ne vois pas l'intérêt de Seven par rapport à XP.

La consommation mémoire d'un Linux de 2010 est nettement supérieure à celle d'un Linux de 2001. Et?

Tu as mal lu ma phrase :
- Je ne comparais pas un Windows XP de 2001 et un Windows Seven de 2010
- je comparais un Windows XP de 2001 non mis à jour et le même Windows XP mis à jour. Et après cette "simple" mise à jour, les performances de la machine chutent.

En 2001, j'avais une "Mandrake xx". Avec ses dernières mises à jours (grosso-modo 2 ans plus tard), l'OS n'était pas spécialement plus lent.
Quand à un changement Mandrake xx à Mandriva 10.10, ce n'est plus une mise à jour, mais... un changement de version (ce qui n'était pas mon propos).

C'est un peu dingue de partir d'une version toute nue d'il y a 9 ans et penser qu'on peu rattraper toutes les mises a jour en un claquement de doigts hein...

Le SP3 est supposé rattraper d'un coup toutes les mises à jour jusqu'au 2008/06/05 ( http://www.microsoft.com/downloads/details.aspx?displaylang=(...) ). Toutes les mises à jours (et les reboot !) successives qui ont suivit n'ont été nécessaire que pour grosso-modo la dernière année.

Lorsque j'upgrade une Debian de Stable à Testing, soit un "saut" de "seulement" 4 ans :
- j'ai doit à un seul reboot
- la machine est installé avec les tout derniers patchs
- et en plus, ce n'est pas que l'OS "nu" qui est mis à jour, mais aussi toutes les applications tierces (openoffice, firefox, etc...).

La maniere dont tu le relate ferait presque penser qu'a chaque fois que t'a passél a mise à jour ca dure 3 heure.. non en fait le PC il n'avais jamais vu une mise à jour...

C'est exact : Je réinstallais le PC "from scratch", à partir du CD de XP originel (XP ayant été acheté, je ne vois pas pourquoi j'aurai dûs installé un CD plus à jour, trouvé je ne sais où). Une fois l'OS installé, "Windows update" m'a demandé si je voulais le mettre à jour, et je l'ai laissé faire. Et c'est à partir de ce moment là que cela a duré 3h.

En fait, ce n'est pas tellement la durée qui me pose problème, c'est le fait que à chaque mise à jour, tu relances Windows Update", et celui-ci te dit "il y a une mise à jour". Alors que pour la mise à jour terminée 2 minutes avant, j'avais demander de TOUT mettre à jours.

Bref, je me serais attendu à ce qu'une seule mise à jour fasse tout le boulot d'un coup.

Merci, j'ai beaucoup rit !

Personnellement je suis sous Debian Squeeze/Testing:
- des mises à jours régulières, qui font évoluer la distribution par petites touches, et non pas pas à-coup (sauf lors du passage de KD3 à KDE4, là cela a été assez radical)
- cela permet de n'avoir qu'une surprise à la fois, et donc de se donner le temps de corriger les éventuels problèmes aux fur et à mesure. Et donc de découvrir de nouvelles astuces au fur et à mesure: Ahh, le passage de grub1 à grub2, c'est clair qu'il faut s'être donné le temps de l'anticiper, et ne pas à avoir à le subir...
- assez peu de gros soucis, mais jusque ce qu'il faut pour ne pas s'endormir sur ses lauriers. Les moteurs de recherche permettent de dénouer 95% des problèmes
- régulièrement je fais du ménage, en purgeant les paquets orphelin, et les paquets "rc" (j'ai écris un script pour cela)
- par contre, il faut avoir une connexion réseau qui fonctionne. En faisant une mise à jour de la machine tout les jours, j'ai souvent 800-900Mo de paquets téléchargés tout les mois rien que pour cela

Bref, une Debian Testing, c'est un peu de faire un safari dans une savane de bugs à bord d'un car climatisé : C'est tranquille et confortable, mais de temps en temps il faut être capable de sortir du cocon, pour affronter les bugs.

Tu vois, à la méthode Windows:
1) Télécharger le logiciel en version bêta,
2) L'installer,
3) ????
4) PROFIT !


Hummm, la dernière fois que j'ai dus installer un soft sur le Windows d'un collègue :
- j'écume le web à la recherche du site officiel du soft XXXX (un soft gratuit dont il m'avait parlé) : plein de sites proposent de le télécharger, mais comme ce ne sont pas le site officiel, il y a un risque fort que le paquet ait été bidouillé d'une manière quelconque. Donc, perte de temps pour rechercher la source.
- je télécharge le soft XXXX
- installation de XXXX : Marche pas, il faut une mise à jour du msi (Microsoft Installer)
- recherche du "msi" qui va bien sur le site de MS
- installation de XXXX : Marche pas, il faut ".NET"
- recherche du ".NET" qui va bien sur le site de MS
- installation de XXXX : Marche pas, il faut le dernier SP en date du ".NET"
- recherche du dernier SP de ".NET" qui va bien sur le site de MS
- installation de XXXX : Ca marche
- démarrage de l'appli, qui crash comme une grosse bouse
- recherche d'infos sur le message d'erreur, utilisation de "filemon" et "regmon" (outils de type "strace", mais en plus simple) pour analyser ce que fait la machine avant de planter
- plein de temps perdu...
- finalement, le problème venait d'un obscure conflit de dll, qui faisait que la dll utilisée n'était pas celle fournit avec le soft (les"règles" de chargement de dll chez MS sont assez obscures).

Bref, ce n'est pas toujours très simple chez MS

PS: Et à la question : "Pourquoi la machine n'était pas à jour", je dirais :
- machine non connectée à Internet, à cause des risques de virus
- la dernière fois que j'ai mis à jour un Windows XP ("SP0"), il m'a fallu environ 3h, en comptant tous les reboots (une douzaine ?) et toutes les mises à jours successives (une douzaine aussi: genus advantage, SP3, tout les hot fix, .NET, etc...). Et bien sûr, je ne parle pas des drivers constructeurs
- vrai-fausse raison, mais à noter quand même : entre un Windows "SP0" et un Windows XP3 + patchs à jour, la consommation mémoire est nettement supérieur, et le temps de boot nettement allongé. Sans compter les centaines de Mo perdu dans les C:\windows\$xxxx\ de fichiers de désinstallation des patchs...

c'est fluide et utilisable c'est même beaucoup plus fluide que vnc sur la même connexion (j'ai fait le test).

VNC, par défaut, n'utilise pas de mécanisme de compression d'image avec perte, d'où une bande passante assez "énorme" pour afficher un écran.

Si sur le serveur tu désactives les effets "kikoo", et que tu passes par "xtightvnc", ou le mode "-encoding tight" de VNC, la bande passante utilisée sera très très réduite.

Je l'utilise pour la maintenance de machines de proches, et je n'ai besoin que de 50-100Kbit/s pour une connexion (j'ai bien écrit "kbit", et non pas "ko")

En jouant un peu avec les taux de compression jpeg, et en acceptant un rendu plus moche, on peut même tomber à moins de bande passante.

Avec les explications que tu donnes en-dessous, c'est un peu plus clair :

Cas 1:
- Le serveur Linux a un serveur X, et un mécanisme de auto-login pour un utilisateur physique (local)
- Si cet utilisateur lance "x11vnc", alors il peut partager son écran complet avec un tier. A noter que "x11vnc" peut-être lancer automatiquement, au démarrage de la session
- Le tier n'a accès qu'à cet écran
- Lorsque le tier se déconnecte, le serveur X reste dans l'état actuel, et les applications (lancées par l'utilisateur local ou à distance), restent lancées

Cas 2:
- Pas de serveur X
- Un serveur VNC (et non pas x11vnc)
- Un utilisateur se connecte à distance pour ouvrir sa propre session, via la fenêtre de login (kdm, gdm, xdm, autre)
- il est seul à pouvoir voir son écran
- lorsqu'il se déconnecte, toutes les applications lancées par lui sont tuées
- A noter que plusieurs utilisateurs peuvent se connecter en parallèle, chacun ayant sa propre session

Cas 3:
- Pas de serveur X (à vérifier)
- Un serveur NX ou FreeNX
- Un utilisateur se connecte à distance pour ouvrir sa propre session, via la fenêtre de login (kdm, gdm, xdm, autre)
- il est seul à pouvoir voir son écran
- lorsqu'il se déconnecte, il existe un mode qui permet de "sauvegarder" sa session. Les applications graphiques restent donc lancées dans la mémoire du serveur.
- L'utilisateur peut alors se reconnecter au serveur quand il le désire, et ouvrir soit une nouvelle session, soit poursuivre la session en cours
- A noter que plusieurs utilisateurs peuvent se connecter en parallèle, chacun ayant sa propre session

J'ai expliqué ces différentes subtilités dans cette conférence que j'ai donné :
http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...) (et pages suivantes)

Oui, x11vnc pour le serveur, et xtightvnc pour le client : J'utilise cette configuration chez moi, et cela marche très bien.

Si des besoins de chiffrage sont nécessaire, tunnel SSH ou l'option "-s" (je ne l'ai pas testé avec x11vnc)

Ou alors, il y a le mécanisme utilisé par Ubuntu : Vino , qui se base en fait sur VNC

Pareil, j'ai aussi lu ceci dans le passé.

Il est probable que cela ait été posé sur LinuxFR.

Essaye de faire une recherche en limitant le site à celui-ci, en rajoutant "site:linuxfr.org" à la requête Google.

De ce que j'ai lu à ce sujet, télécharger un fake est aussi pénalement coupable que de télécharger la version "originale".

Car c'est l'intention de téléchargement illégal qui compte.

C'est pareil, j'imagine, pour le vol d'un mobylette dont le voleur se rendrait après coup que le moteur est cassé : Il a volé l'objet, que celui-ci était ou non en état de fonctionner avant son intervention.

De façon l'OS virtualisé est confiné dans la machine virtuelle.

Une petite remarque à ce sujet : Si la VM a été configurée pour que l'OS invité accède au réseau, les virus qui tournent dessus peuvent attaquer le réseau local (gare alors aux partages SMB), ou accéder à Internet (attention alors aux risque de prise en main à distance).

La solution est toute bête:
- ne pas activer la couche réseau de la virtualisation
- ou, si on a à tout pris besoin de partager des données réseaux entre le host et le guest, on configure le Windows virtualisé avec une adresse IP fixe, sans passerelle, et on désactive les services DNS et DHCP. Le virus alors ne pourra que attaquer le host, dont on aura au préalable verrouiller tout ce qu'il faut (exemple : l'éventuel serveur SMB).

La police n'a en effet pas le droit de "tendre un piège" à des délinquants, comme, par exemple, en vendant de la drogue afin d'arrêter des revendeurs.

Dans le cas de cette HADOPI, mais surtout des sociétés chargées de faire la collecte des adresses IP, je me demande qui est-ce qui irait, voir même pourrait le vérifier.

Il suffit que la dite société loue une "seedbox" à l'étranger, par exemple en Espagne où les loies sur le P2P sont moins strictes, et ils pourraient relever des adresses IP Françaises de téléchargeurs .

Certes, ce serait probablement très "limite" en terme de loi, mais la HADOPI nous a habitué à cela.

Enfin, en parallèle de cela, j'indiquerai que les majors se sont déjà amusés (et le font toujours) à injecté des "fakes" dans les réseau P2P. J'ai notamment souvenir de la première fois que cela a été médiatisé, avec un morceau du film "Blueberry", qui tournait en boucle, avec 15 minutes de films, et un message "télécharger, c'est mal". Et évidement, ils n'ont eu aucun problème à collecter les adresses IP des personnes qui cherchaient et téléchargeaient ce fake/hash-là.

Humm, il faut avoir sacrément confiance dans ces instructions pour faire ce genre de choses...

De plus, si le BIOS est un peu "exotique", BIOS de constructeur par exemple, je me demande si les mécanismes de reset sont placés aux mêmes endroits.

Enfin, il faut booter la machine sous DOS pour le faire (donc changer la séquence de boot), ou au minimum avoir des droits admin/root pour pouvoir taper dans le BIOS. Donc sur une machine ultra-verrouillée (mot de passe de BIOS + boot seul sur le DD + pas de droits admin), cela ne va pas être très utile.

Imaginez-vous que vous soyez connecté à ce réseau, votre bande passante aura vite fait d'exploser sans que vous ne téléchargiez encore rien pour vous,

C'est déjà ce qui se passe avec TOR...