totof2000 a écrit 9656 commentaires

D'accord ou pas, c'est ton choix.
Ce n'est pas forcément le mien (enfin le choix du mode de fonctionnement des distibutions). C'est juste pour mettre en évidence que ce qui se fait sous windows n'est pas forcément la meilleure chose à faire, notamment du point de vue de la distribution des logiciels. L'un des gros problèmes de windows est qu'il devient de plus en plus instable au fur et à mesure des installations/désinstallations, et que l'installation d'un soft provenant de on ne sait ou peut amener avec un tas de cochonneries dont on peut ne pas avoir envie. Utiliser un dépot fourni par la distribution permet d'avoir une certaine cohérence et stabilité du système, mais l'inconvénient est que tu ne peux installer de soft non intégrés à la distribution de façon simple. C'est pour ça que pour ma part je préfère l'approche NetBSD avec séparation du systeme et de l'Userland.

Mais alors il ne faut pas demander de drivers ou d'applis portées sous Linux quand on refuse le besoin de 99% des utilisateurs. Si tu veux un minimum d'écoute de la part des autres, il faut avoir un certains poids part de marché, et pour ça il faut faire des concessions.
Il y a déjà des concessions de faites : possibilité de fournir des drivers proprios par exemple. Et il faut aussi réfléchir un peu sur les concessions que l'on fait, sinon elles vont toujours dans le même sens.
Tant que les libristes ne feront pas de concessions, les autres se mettrons ensemble, feront des concessions, et resteront sur le desktop.
Si ce que tu dis était vrai, il y aurait bien plus de BSD que de Linux aujourd'hui. (je t'accorde que MacOSX devient de plus en plus populaire, mais à mon avis c'est pour une autre raison). Linus a fait des concessions pour les pilotes. Certes ça reste plus compliqué pour les développeurs de pilotes proprio d'intégrer leurs pilotes au noyau, mais faut pas non plus exagérer : les concessions elles doivent venir des deux côtés. Et s'il en faisait plus, le noyau se retrouverait complêtement dénaturé de ce qu'il devrait être.
Pourquoi d'après Ubuntu a plus de succès que les autres ditros sur le desktop? J'ai une réponse : parce que ça marche mieux que les autres (grâce entre autre aux drivers proprios --> Concession faite entre le besoin utilisateur et le libre). Mais Ubuntu c'est mal, ils font des concessions.
Je ne dis pas qu'Ubuntu c'est mal, pour moi c'est une bonne distribution (la machine de ma femme est sous ubuntu), justement parce que c'est une distrib qui marche.

Je suis d'accord sur les points suivants :
- Avoir une API de drivers stable et autoriser les drivers non-GPL
d'accord avec la premiere partie, pas la 2eme. D'ailleurs les drivers non GPL sont autorsés, contrairement à ce que tu prétends. Enfin tu raisonnes Linux/X86, moi je raisonne "Libre". Avoir des specifications permettrait de développer des rivers pour d'autres OS (xBSD par exemple).
- Avoir un tronc commun entre toutes les distribs qui permet aux editeurs de developper sans s'arracher les cheveux (LSB c'est sympa, mais c'est un peu pathetique tellement c'est pauvre pour un soft moderne)
Quel est le rapport avec les drivers ? Les drivers accèdent aux couches basses du noyau, qui reste assez standard non ? Sinon effectivement il y aurait probablement intérêt à aller plus loin que LSB, quitte à définir des standards spécifiques pour les serveurs, pour les postes bureautique et pour le matériel embarqué.
- Arreter de remplacer une techno vieille de 6 mois par une nouvelle techno qui elle meme sera remplacee dans 6 mois
Je ne peux qu'adhérer à cette remarque. Il serait temps de stabiliser certaines partie du noyau. Passer son temps
- Avoir une politique de support correcte, et trouver un moyen pour qu'il soit facile pour grand-mere d'installer des softs sans passer par les depots officiels (dependances qui explosent...)
Là je ne suis pas tout à fait d'accord avec toi. Utiliser les dépots garantit une certaine cohérence de ton OS. Ca règle certains problèmes, mais effectivement ça en pose d'autres. Je suis plutot pour ma part, favorable à une solution intermédiaire inspirée de NetBSD : une séparation du système et des couches applicatives. En gros les distributions proposent un socle de base, avec noyau et utilitaires permettant de gérer les couches basses. Les applis userland seraient fournies dans une autre arborescence. C'est ce qui se passe sous NetBSD. Ceci permettrait même d'aller plus loin : les binaires de base dans /usr/bin ou dans usr/sbin, les softs fournis par la distrib dans /usr//bin avec les libs associées dans /usr//bin, et les softs tiers dans /usr//bin, avec libs dans /usr//lib. On peut remplacer /usr//lib par /opt/, comme ça se fait sur certains unix proprios. Je ne sais pas si les gestionnaires de packages actuels permettent ce genre d'installation mais ça pourrait être intéressant et permettre une cohabitation de plusieurs versions de lib différentes.

Tu sais, les societes qui ont des contrats globaux avec MS, elles previennent pas non plus IDC quand elles installent un serveur Windows, elles prennent une product key sur le serveur et installent l'OS elles meme.
Tu veux me dire qu'il y a possibilité d'avoir des contrats globaux chez Microsoft qui permettent d'installer autant de machines windows que l'on veut ? Je pensais que les contrats globaux imposaient une limite. Si c'est le cas il y a toujours moyen de savoir combien de licences ont été vendues donc de savoir combien de serveurs seront potentiellement installés.
Unix ou MVS c'est pour du tres gros et c'est tres cher oui.
Oui, et ça tient la route. Cela dit, pour faire des économies, on remplace de plus en plus de serveurs Unix proprio par des trucs fiables qui coutent moins cher. Et tu sais par quoi on les remplace ? Je te laisse deviner.

Quand a Windows etant un jouet, il y a largement assez d'exemples de Windows utilise sur des systemes critiques pour demontrer que c'est loin d'etre un jouet.
La plupart des gros projets que j'ai vu sous windows ont basculé sous Unix (AIX, Solaris et certains sous Linux). Certains n'ont pas basculé parce que l'appli métier en question n'était pas portée sous Windows.
Quand a Linux, quand on voit que Redhat qui est leader loin devant tout le monde dans le monde Linux niveau qualite et professionalisme n'offre que 7 ans de support pour sa distrib, tu m'excuseras de rire un peu, on fait encore des patchs pour NT4 ici hein, qui est sorti en 1996, ca fait 14 ans.
Oui, je n'en doute pas, mais ne faut-il pas un contrat spécial pour prolonger le suppport ? Parce que si tu payes RedHat, ils te fourniront des patch pendant 20 ans si tu veux.

Et les systemes critiques, entre le temps ou l'OS sort, le temps ou ils s'y mettent, testent et deploient, t'as deja bouffe 2-3 ans de la vie de l'OS, ca te laisse 3-4 ans sur un systeme tres lourd et cher a valider avec la solution Redhat qui est a peu pres la seule viable dans le monde Linux, resultat il faut recommencer ta procedure de migration d'OS environ 1-2 ans apres avoir installe le systeme !
C'est d'ailleurs pour ça que les systèmes vraiment critiques sont sous ZOS, VMS ou Unix proprio, avec support étendu. Ca coute cher, mais moins qu'une indisponibilité du système.

Bref, tu n'a absolument aucune garantie, bien au contraire, qu'ils vont s'arranger pour que les softs continuent a fonctionner d'une release majeure a l'autre ce qui va rendre la phase de migration encore plus drole.
Bah, tu sais, ça c'est juste le parapluie, tout comme les contrats de licence pour lesquesl Microsoft se dégage de toute responsabilité vis à vis des problèmes rencontrés suite à l'utilisation de leur OS. Pour RedHat, si t'as du support, ils t'aident, contrairement ce que tu crois. Si tu n'as pas de support tu te débrouilles.

Il y a pas a dire, gerer des systemes critiques avec Linux, c'est le paradis !
Pas pire que sous Windows. Pas forcément mieux dans tous les cas, mais c'est loin d'être pire.

Alors la permet moi de douter de ces chifres qui pour moi n'ont pas vraiment de sens : Ils parlent en terme de ventes, mais pas en terme de machine installées. Parce que tu sais, lorsque j'istalle une Debian ou CentOS au taf, je préviens pas IDC pour qu'ils incrémentent leurs compteurs. De plus ces chiffres confirment bien ce que je pensais : windows c'est plein de petits serveurs style serveurs bureautique pas sensible: c'est pour ça qu'il y en a plus. Les grosses conf, c'est de l'UNIX ou MVS (ou VMS). Windows ce n'est qu'un jouet, dès qu'on a besoin de sérieux, il faut l'oublier.

Le vent tourne sur les serveurs (remplacement d'AIX/HP-UX/Solaris par Linux).
Remplacement également des serveurs Windows par des serveurs Linux.

Dure réalité que de constater que Linux a du chemin à faire avant de répondre au besoin (déjà, si Linux avait un concurrent correct face à Exchange/Outlook pour l'entreprise... Bon, OBM commence à taquiner, mais c'est encore petit)
Je suis d'accord avec toi sur le fait qu'il reste du chemin à parcourir, mais comparé à ce qui existait il y a 10 ans, je trouve qu'on a pas mal avancé. Celà dit, certaines administrations se sont mises à Linux sur le poste de travail sans problème . Même s'il y a du chemin à faire, il y a pas mal de cas ou Linux peut remplacer Windows.

Bref, si tu veux rejoindre l'equipe de test ici, t'es sense comprendre comment un OS fonctionne de l'interieur, savoir debugger des problemes compliques et etre capable d'ecrire du code C/C++ solide.

Ca me parait bizarre cette contrainte. Ne serait-ce pas plus productif d'avoir une équipe de test qui justement ne voit pas ce qui se passe à l'intéieur ? Est-ce que les connaissances de l'intérieur ne risquerait-elle pas d'influer sur leur manière d'écrire les tests ?

Ah tu me feras toujours bien rire.

Il n'y a que très peu d'appli sérieuses qui tournent sous Windows. Windows, c'est majoritairement de la bureautique ou des petits serveurs pas cher. Pour le reste, dès qu'on a besoin de performances ou de haute dispo, on trouve en général (en France) :
- Manframes IBM/ZOS
- AIX sur matos Bull ou IBM
- Solaris/HP-UX
- de plus en plus de Linux.

Ben oui allons, mettons les tous dans le meme paquet, et surtout, surtout, ne nous demandons pas pourquoi toutes ces boites restent sur du MS plutot que virer leurs admins incompetents pour mettre du Linux super pas-cher avec des admins competents hein !
Le vent tourne ... Le vent tourne !!!

Que ce soit sous XP ou sous Linux, il faut au minimum 1 Go de RAM pour faire tourner les applis courantes sur ce genre de bécane.

J'ai vu pas mal de bécanes de ce genre me passer entre les mains il y a environs 2 ans; Ces machines tournaient toutes sous Windows XP SP1 sans trop de ralentissement, (j'enai même vu une tourner avec 256 Mo de RAM). Par contre dès qu'elles ont été connectées sur Internet, ila fallu faire les mises à jour, coller antivirus/antispyware/firewall/anti tout ce que vous voiulez, et à partir de làn, même avec 512 Mo de RAM, ces bécanes étaient inutilisables. Même Linux avait du mal avec une telle config (enfin ..; Linux tournait bien mais dès qu'on lançait un firefox, un OpenOffice ou un autre truc un peu gourmand, ça swappait à donf). En leur collan 1 Go, que ce soit sous Xp ou Windows, ça tournait beaucoup mieux.

assez surprenant, les Dell ne sont pas forcément réputés pour être des machines de qualité.

La gestion de l'ACPI pourrait être en cause : si les CPU tournent toujours à pleine puissance, ou si le refroidissement n'est pas optimum, je suis sur que la durée de vie du matos peut se réduire.

Mais la ce n'est pas Linux qui est directement en cause mais les constructeurs.

A mon avis ce genre de clause ne tiendrait pas devant un tribunal.
C'est un peu comme si on te faisait sauter la garantie de ton appareil photo parce que tu as changé toi même la pile/batterie.

les gens ont autre chose à faire que de regarder comment on branche. On a dit simple! Ta définition de simple n'est pas celle des acheteurs.

Avec l'arrivée de l'USB, c'est pas plus compliqué que de brancher un lecteur DVD sur sa télévision :
- 1 prise d'alim pour la tour
- 1 prise écran
- 1 fiche audio (pour installation simple, pas pour du 42.1)
- 1 prise USB pour le clavier
- 1 prise USB pour la souris.

Toutes les prises sont colorées, tu ne peux pas te tromper.

J'ai vu bien pire . A moins d'être très limité, cet argument tient plus de la flemme (ou de la peur irrationnelle qu'ont certains avec l'informatique).

Pour le reste je suis d'accord : avoir une machine qui se range facilement, ou que l'on peut utiliser n'importe ou à la maison ou ailleurs a un grand intéret. Puis des fils qui trainent partout, c'est affreux.

Euh ... faut voir aussi comment tu le traites ton matos ... :) Cela dit le matériel récent est peut-être un peu moins fiable ( gravage de plus en plus fin + vitesse de plus en plus rapide) . Mais il n'est pas rarte de rencontrer des gens ayant du matos Apple qui dure depuis plus de 5 ans sans problème.

Euh .. sans être un fanboy d'apple, on peut au moins leur accorder le fait que le matériel est fiable. Un peu plus cher que le matos entrée de gamme que t'achètes à la grande surface du coin, mais au moins ça tiens la route (je n'ai pas de matos apple, mais tous ceux que je connais qui en ont n'ont pas à se plaindre de ce côté).

XEN = Gros problème de performance (accès disque et débit monstrueusement faible), peux-être que les problèmes ont été résolu car nous avions tester cette solution il y a 2ans environ... Ou peux-être que nous n'avions pas bien cherché, bref c'était compliquée pour pas grand chose, recompilation de noyau etc... pas fait pour les débutants

Installation en mode paravirtualisé ou en mode natif ? La gestion de la virtualisation (Intel-VT ou AMD-V ) activée ?

Sinon, tu as mal choisi ton hote, avec un NetBSD c'est trop facile à faire. L'inconvénient : un peu de retard dansd la version de Xen supportée sur la version stable.

VMWARE = C'est tout cuit, ça fonctionne directe (à condition de ne pas avoir de problème lors de la compilation des modules pour le noyau, dans ce cas on cherche des patchs... Défois on recompile un nouveau noyau...), quelques problèmes de performance (128Mo de RAM dédiée à une machine virtuelle = un fichier d'échange sur le disque, donc problème de lenteur et freeze, contournement en utilisant /dev/shm, performance pas mal après l'avoir bien configuré.)
Je ne sis pas spécialiste de VMWare, mais la ou je l'ai vu tourner en général ça marche pas trop mal. Mais kj'avais vu il y a quelques temps (3 ou 4 ans) que Xen était meilleur en mode paravirtualisé. Mais je n'ai malhereusement pas d'infos précises.

Pour KVM je ne le connais pas du tout. Faudrait que je le teeste un peu.

Merci pour ce retour.

Moi j'utilise Xen et ça me suffit également : c'est juste pour faire des install/configuration de distribs, etc ... et j'ai ue ou 2 VM qui tournent en permanence pour faire du dev Ruby/Rails + ma doc perso. PAs besoin non lus de bascule (de toute façon je n'ai pas les liens réseau qui vont bien), mais sur le matéériel que j'aurai à dispo, je devrais pouvoir jouer avec ça.

Je connais un peu VMWare, je connais assez bien Xen, mais pas du tout KVM.

Ma question est effectivement plutôt mal formulée : je ne cherche pas une étude de spécialiste gratuite, j'ai déjà une idée des tests que je veux lui faire faire (en gros je voudrais savoir comment se comportent ces 3 solutions en terme de perfs vu du réseau, des accès disques, et niveau charge CPU. J'aimerais aussi voir comment se comporte l'ensemble lorsqu'on charge le système hote avec plein de VMs. Maintenant, je t'avoue que c'est peu de temps avant avoir posté que j'ai appris que j'aurai des machines à dispo, par contre je n'en disposerai pas très longtemps. Et lorsque j'ai posté je n'ai pas eu trop le temps de réfléchir à la question.

En fait ce qui m'intéresse le plus c'est le retour d'expérience que pourraient avoir certains, comme indiqué ci-dessous par d'autres intervenants (même s'ils n'ont pas moyen de prouver, je suis preneur de toute info sur le "ressenti" en terme de perf, je pourrai orienter mes tests en ce sens).

Pour les tests pertinents, c'est vrai que ma question est un peu stupide. Mais il me semblait avoir supprimé cette phrase de mon post. Je fatigue ...

C'est un peu succint comme infos.
Quel type de VPN utilisez-vous ?

Euh remplacer implicite par explicite dans mon avant dernière phrase.

Moins intuitif pour toi et pour moi, parce que l'on connais déjà os.popen.
Enfin, quand tu compares les deux approches il n'y a pas photo. Dans le cas ou l'on veut récupérer le flux retourné par une commande la premiere solution reste la plus simple. Les histoires de pipe peuvent être intéressantes, mais pour le cas du popen simple, je trouve que ça embrouille plus qu'autre chose.

(AMA plus intéressant pour les nouveaux venus) les utilisations en Pipe shell.
C'est quand même sortir la grosse artillerie pour pas grand chose je trouve.

Et c'est plus sécure: là, tu indiques explicitement que tu vas aller utiliser le shell pour lancer la commande, donc qu'il peut y avoir une tromperie à ce niveau - tu dois en être conscient.
Mouais, ça reste dans l'état d'esprit Python, et c'est ce genre de truc que je n'aime pas. A force de devoir tout spécifier de façon implicite, on en arrive à l'incantation. Si j'ai besoin de programmer une appli nécessitant une fiabilité telle qu'il soit nécessaire de tout spécifier, je code en ADA, c'est fait pour.

... tu risques de te prendre un procès de la part des édition Albert René.

Et comment reconnaitre un mauvais commentaire d'un bon commentaire ?

Etant un utilisateur occasionnel de Python, je ne pense pas que je gagnerai du temps à coder ça.

C'est une seule fonctionnalité: lancer un process séparé.
Après, la façon dont tu identifies le binaire, comment tu communiques avec ce process, comment tu fournis les paramètres, etc... ce ne sont que des options.

Mouais, réunir plusieurs fonctions (popen popen2, etc ..) en une seule (même fonctionnalité), pourquoi pas. Par contre je trouve que la façon de faire de Python n'est pas ddes plus intuitives. J'ai repris le code d'exemple que j'ai trouvé dans la doc tel quel, sans trop comprendre ce qu'il fait. Et pour un langage ou tout est explicite, je pense qu'il vaut mieux avoir 5 fonctions différentes pour 5 variantes d'une action plutot que d'avoir une seule fonction ou il faut spécifier explicitement des paramètres inutiles dans la plupart des cas. Je trouvais que l'ancienne version popen popen2, etc .. était plus claire dans son fonctionnement.

Après, tu as le communicate() pour les besoins simples (mais les plus courants), et tu peux utiliser des pipes vers stdin/stdout/stderr pour les choses plus compliquées.

Ce qui me gave c'est qu'un truc simple comme
pipe = os.popen("cmd", 'r', bufsize)
qui est très clair à comprendre devient
pipe = Popen("cmd", shell=True, bufsize=bufsize,stdout=PIPE).stdout
qui est quand même moins intuitif.

Qu'il évolue, pourquoi pas. Mais tant qu'à faire, il faudrait qu'il évolue en mieux.