Journal RPM o RPM !!!

Posté par  (site web personnel) .
Étiquettes : aucune
0
17
mai
2004
Je voudrais savoir si je suis le seul a trouvé énormément de problèmes au système de rpm et qu'il faudrait un peu standardisé tous ca ( Mandrake, Suse, Redhat help me please ? ) ...
Je vais prendre un exemple concret :
J'initie un de mes amis sur Linux avec une distribution genre Mandrake ( simple et conviviale ) et il voudrait installer quelque petits jeux en plus pour ces enfants.

Donc on est chez moi et on va faire un tour sur "www.happypenguin.org" il trouve 3 petits jeux. On va sur les sites des jeux en questions ... youpi un des jeux proposent les packages pour notre version de Mandrake mais ne propose pas en téléchargement ces dépendances alors que tous ces sites proposent des binaires windows qui marchent ( en 3 clics j'exagère à peine ).
La je sors la botte secrète "www.rpmfind.net" on trouve bien les autres jeux et toutes les dépendances ( On s'amuse aux poupées russe ! ). Une remarque certaines distributions célèbres n'ont meme pas de packages pour les jeux en question.
Je met tous sur un CD (en tous 12 rpm) et hop on va chez mon ami. Bon! Heureuse surprise pas mal de RPM sont déjà installés mais pas tous.
Et là c'est le drame un des jeux ne marche pas je bidouille pendant une heure sur la bete mais rien ! Il me dit que c'est pas grave et qu'il s'en passera...

Si moi qui est quand meme quelques notions arrive péniblement a installé 2 jeux sur 3, je me demande comment mon ami aurait fait. Je pense d'ailleurs qu'il n'aurait rien fait qu'il aurait dit que linux s'est de la m... et honnetement aurait il eut tord ?

  • # urpmi

    Posté par  (site web personnel) . Évalué à 2.

    Je te conseil pour les dependances de mettre a jour les listes de mirrors, avec http://www.urpmi.org/easyurpmi/(...) .
    Un très bon site ...

    • [^] # Re: urpmi

      Posté par  (site web personnel) . Évalué à 4.

      mon ami n'a pas internet chez lui .

      • [^] # Re: urpmi

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Les versions des RPM présents sur ses (ou tes) CD d'install de Mandrake ne sont pas assez récents pour ces jeux?

        S'ils le sont, urpmi a toujours la possiblité d'aller chercher les rpms sur ces CD, et un simple "urpmi monjeuenpackagemandrake.rpm" installera tout ce qu'il faut avec dans le pire des cas 1 ou 2 changements de CD.

    • [^] # Re: urpmi

      Posté par  . Évalué à -2.

      Bon rpm rend compte des dépendances mais ne les résoud pas.

      Apt et Yum sont des technologies qui permettent cela.

      En fait la question (trollesque presque) est :

      Is LINUX UserFriendly ?

      • [^] # Re: urpmi

        Posté par  . Évalué à 2.

        Linux est user-friendly... il est juste pointilleux dans le choix de ses amis :-)

        • [^] # Re: urpmi

          Posté par  . Évalué à 2.

          Ca perds beaucoup à la traduction...
          On perds le jeu de mots qui est quand même l'essentiel de la quote.

  • # Envoi un patch.

    Posté par  . Évalué à 3.

    Envoi un patch. C'est la seul façon pour le LL de progresser encore et toujours.

    Faire un .spec, ce n'est pas très compliqué (pour les petits projets).

    Désolé mais les tous petits projets sont un peu comme les sharewares, la qualitai n'est pas toujours au rendez-vous mais contrairement aux sharewares, on peut changer les choses. :-)

  • # C'est bien le probleme

    Posté par  (site web personnel) . Évalué à 2.

    Si moi qui est quand meme quelques notions arrive péniblement a installé 2 jeux sur 3, je me demande comment mon ami aurait fait.
    Il a l'avantage de ne pas connaitre rpmfind...
    C'est quoi tes jeux pour lesquels il n'existe pas de RPM pour Mandrake faits par des packageurs mandrake (en main, contrib ou plf) et donc qui ne sont pas installables par l'outil d'installation de logiciels de mdk ?

    • [^] # Re: C'est bien le probleme

      Posté par  (site web personnel) . Évalué à 2.

      Quand je parlais de Rpm je parlais biensur de fichiers *.mdk qui sont géré par urpmi mais mon problème est que le PC de mon ami ne sois pas relier à Internet sinon tout aurait été plus simple évidemment !

      • [^] # Re: C'est bien le probleme

        Posté par  . Évalué à 1.

        Je vois pas en quoi c'est lié à rpm.
        Puis si rpm te plait pas, utilise des tar.gz ou rpm2cpio.

        Ce n'est pas parce qu'un paquet rpm ne marche pas que c'est de la faute à rpm !
        rpm n'est que le système pour faire les paquets et les installer. Rien de plus.

      • [^] # Re: C'est bien le probleme

        Posté par  (site web personnel) . Évalué à 2.

        Le fait qu'ils s'appellent mdk ne veut rien dire. Viennent t'ils d'un miroir Mandrakelinux correspondant à la version installée ou ont ils été faits par un inconnu ?

        • [^] # Re: C'est bien le probleme

          Posté par  (site web personnel) . Évalué à 1.

          Comme je l'explique plus bas (ou plus haut) mon probleme n'est pas avec mandrake... ou ces rpms. Mon problème est en fait qu'il faudrait simplifier pour certains utilisateurs/ordinateurs (comme ce qui ne sont pas sur internet) les méthodes de gestion des packages. Par exemple créer dans un seul gros fichiers (un Méga rpm) avec l'ensemble des packages (non inclus dans une livraison standard) et le package du logiciel ce qui permettrait de tout installer d'un coup sans jouer aux poupées russes. Et ce qui serait l'idéal c'est que certains rpms ( pour des jeux, des petits utilitaires,... ) soient standard entre les différentes distributions ( mais la je reve ).

          • [^] # Re: C'est bien le probleme

            Posté par  (site web personnel) . Évalué à 1.

            Sésolé mais je préfére que ca me télécharge uniquement l'utile plutot que pour chaque jeu de 100Ko ca te file 100Mo...

          • [^] # Re: C'est bien le probleme

            Posté par  . Évalué à 1.

            Tu veut dire comme sous windows des installer avec windows installer qui contiennent windows installer à l'interieur (Au cas ou tu l'as pas) et qui utilisent la lib c++ de microsoft et qui l'incluent aussi...
            Idem avec les libs VB

            On finnit avec des installeurs qui rament, qui ont des tailles monstrueuses pour de simples logiciels...

            Sans compter les problèmes qu'ammènent ce genre de patch sauvage par un installer tiers (De façon transparente évidement car il faut pas déranger l'utilisateur le consommateur) : Et hop que je te mets la 4.3 là ou tu avait la 4.2 car elle est plus récente, et hop que ça t'explose 5 autres logiciels...
            --> Ce problème étant encore pire sous linux qui n'as pas 2 versions majeures de TOUT (9x et NT) mais une multitude de MAJ/Adaptation et autres.

            Donc je ne pense pas que ce soit une bonne solution même si c'est user-friendly.

            Windows se veut simple pour les non-initiés, pourquoi faire pareil ? Pourquoi ne pas essayer plutôt d'initier les gens.

            Donne du pain à quelqu'un et il mangeras un jour, donne lui du blé et il apprendras peut-être à le cultiver et à manger toute sa vie.
            -> Facilite une installation et seule cette installation seras aisée pour l'utilisateur, apprends lui à le faire et toutes les instalation serons plus simples.

  • # Gros troll ?

    Posté par  (site web personnel) . Évalué à 1.

    C'est juste un gros troll velu ou alors tu n'as pas regardé l'installateur de paquets de Mandrake par exemple, sans parler de urpmi...
    Ce n'est pas le but de RPM de gérer l'installation et la gestion automatique des dépendances, mais celui d'autres outils basés sur RPM, dont certains proposent des interfaces graphiques.

    http://www.mandrakelinux.com/fr/fdoc.php3(...)
    http://lea-linux.org/(...)
    http://www.google.fr/linux(...)

    • [^] # Re: Gros troll ?

      Posté par  . Évalué à 3.

      > Ce n'est pas le but de RPM de gérer l'installation et la gestion automatique des dépendances

      RPM gère les dépendances mais il ne fait pas de récupération automatique des paquets. yum/apt etc utilise la gestion des dépendances de rpm pour récupérer le bon paquets et les installer.
      C'est parce que RPM gère les dépendances que tu ne peux pas désinstaller glibc sans "--nodeps" ou que tu ne peux pas installer gnome sans gtk+.

  • # Ma solution au travail

    Posté par  (site web personnel) . Évalué à 2.

    Je voulais juste montré le travail qu'il y a faire pour démocratiser GNU/Linux à travers un petit exemple concret (difficulté sans internet). Je suis vraiment quelqu'un de pro linux meme defois trop... ca fait plus de 10 ans que je suis tombé dans l'univers du PC et 6 dans celui de GNU/Linux... Comment voulez vous que quelqu'un qui ne sait pas ce qu'est réellement Window ( cad une OS ) et qui a l'habitude d'installer tous en trois clics de souris ne puissent pas dire que "Linux est merdique".

    C'est juste un constat et je défendrait toujours coute que coute la GPL et les "logiciels libres"

    Une solution que j'utilise sur des machines sun(sous RH) au travail:

    - je récupere tout les Packages et les dépendances ( sauf celles installées par défaut sur la machines ) pour un logiciel donné
    - je met tout dans un gros *.tgz
    - j'envois le tout sur les machines concernées
    - j'ai un script qui teste les dépendances et installe les Packages dans l'ordre

    Les avantages de ma méthode: j'ai tout dans un fichier, je sais pourquoi j'ai installé ces packages (sans besoin d'etre sur la machine)et je lance 1 script(=1 commande) pour tout installer.

    Et je suis sur qu'il y a mieux a faire !

    • [^] # Re: Ma solution au travail

      Posté par  . Évalué à 2.

      > Et je suis sur qu'il y a mieux a faire !

      Le problème n'est pas rpm.
      Si j'osais, je dirais que le problème c'est le logiciel libre. Il évolue trop vite.

      Pour éviter ce problème il faut passer par des distribution dont le cycle est lent (type RHEL).
      Exemple :
      http://www.redhat.com/apps/isv_catalog/(...)

      Dans ce cas tu as aucun problème pour installer Sybase ou Oracle.
      Peut-être qu'un jour il y aura une distribution avec un cycle lent "grand public".

      • [^] # Re: Ma solution au travail

        Posté par  . Évalué à 1.

        Peut-être qu'un jour il y aura une distribution avec un cycle lent "grand public".
        Debian ?

        ok........ ->[]

    • [^] # GNU/Linux aime internet !

      Posté par  . Évalué à 1.

      Il est certain que pour utiliser confortablement GNU/Linux (quelle que soit la distrib' ou le système de paquets), il faut avoir internet. Et même illimité (pas forcément haut-débit).
      Car installer les paquets ou faire un upgrade en un coup d'urpmi, d'apt et de yum, c'est super pratique et finalement, c'est tellement pratique que tout a été construit autour de ça depuis quelques temps. Au détriment des anciens modes de distribution des binaires (CD, disquettes).
      Bref, pour GNU/Linux, internet devient plus qu'utile et quasi indispensable.

  • # Est-ce vraiment un mal ?

    Posté par  . Évalué à 4.

    alors que tous ces sites proposent des binaires windows qui marchent ( en 3 clics j'exagère à peine ).

    Oui mais il faut voir a quel prix...
    La gestion de dépendances sous windows est bien pire que totu ce que l'on peut trouver sous linux.
    Il existe surtout 2 sortes de programmes sous windows : les "faites le vous même" et les "pousse toi que je m'y mette".

    Les faites-le vous même sont livrées bruts, pas de dépendances, parfois juste un simple MSI pour limiter la taille au maximum. A vous de comprendre que les erreurs absconces du type : ##@@@&& : procedure entry not found in bidules.dll veut dire qu'il faut que vous installiez au choix : internet explorer 6 ou 5.5, diverses runtime VB ou .Net, windows media player mis a jour, la console de management, un driver ASPI etc. Ce qu'il y a d ebien par rapport a Linux c'est que el droit a l'erreur est tres faible. Vous croyiez que la mise a jour du media player en version 9 resoudrait le problème ? Perdu et en plus maintenant vous etes coincés avec le mastondonte de service. Il y a aussi des pièges droles, comme la MSVCRT buguée qui peut vous planter une install IE 5.5 au beau millieu et vous interdire toute mise a joru par la suite sous pretexte que : "Une installation d'une version précédente internet explorer ne s'est par terminé, veuillez finir cette installation avant de procéder a la mise a jour". Un grand moment de bonheur (car l'install précédente plante bien sur.)

    L'autre type d'install, c'est le pousse toi de la que je m'y mette. La on a un beau executable et on a qu'a cliquer sur suivant, suivant suivant pour installer le logiciel. Sauf que derrière le programme est supposé chercher les DLLs dont il a besoin sur le système, verifier la version, verifier les autres logiciels qui se servent de ces DLLs et suivant les cas metre a jour ou non. dans la pratique le programme arrive souvent avec ses gros sabot et ecrase les DLLs en place par les siennes avant d'avertir l'utilsiateur qu'un redémarrage est necessaire. Et au reboot surprise, la DLL MSCVRT buguée est revenue, un certains nombre de DLLs sont regressées et un eptit message vous annonce calmement que telle ou telle appli ne fonctionne plus. La réponse de MS a ce problème a été de réinventer la bibliotheque statique. Si un programme veut ecraser une DLL système il est immédiatement conatoner dans son repertoire et la DLL système reste en place. La DLL nouvelle se retrouve alors dans le repertoire de cantonnement. Ca permet d'avoir 40 fois la même DLL en copie. Bien sur cette manip fonctionne bien avec l'installeur MSI, beaucoup moins avec les autres. En plus les tests de versions Beta (de DirectX par example) se retrouvent simplifiées. Le nombre de personnes ayant installé la beta de la version 9 qui ont du reprendre leur poste du départ est impressionnant.

    Sincèrement je préfère aller chercher mes dépendances moi même et pouvoir revenir en arrière facilement (même si parfois c'est long et casse pied, GLibC POWA !!) que d'avoir la surprise au reboot.

    Kha

    • [^] # Re: Est-ce vraiment un mal ?

      Posté par  (site web personnel) . Évalué à 4.

      Enfin on a beau dire, le système des rpm c'est théoriquement bien plus avancé que ce qui existe sous Windows, mais moi je constate que sous linux celà pousse à la feignantise : je développe un soft, je te file les sources voir un rpm si j'ai pas trop la flemme et démerde toi avec les dépendances. Bref : end-user c'est à toi de bosser.

      Sous windows, c'est plutôt le boulot du développeur de faire un installeur, et il est obliger de réfléchir à son utilisation par l'utilisateur final (peut être parcque plus généralement ils vendent le produit et qu'ils se doivent de faire un peu attention à ce que le client puisse installer et utiliser le produit...). L'utilisateur final lancera le setup.exe, qui s'installera gentiment, même si parfois la cohabitation avec l'environnement est hasardeuse (problème des dll par exemple)... Mais celà devient de plus en plus rare, et la plupart des applications marchent du premier coup, alors que sous nux je dirais que c'est la proportion inverse pour peux que le soft utilisé ne soit pas estempillé red-hat ou mandrake dans une distri officielle (et encore des fois).

      De toute façon Microsoft a trouvé la solution au problème des installations et des dll-qui-change-de-version : Windows peut conserver plusieurs versions d'une même dll au même endroit (hop plus de conflit de version) et abandon progressif de l'utilisation de la base de registre (l'installation se fait à la bourrine, paèrs vérification des dépendances évidemment : copié-collé).

      • [^] # Re: Est-ce vraiment un mal ?

        Posté par  . Évalué à 3.

        Enfin on a beau dire, le système des rpm c'est théoriquement bien plus avancé que ce qui existe sous Windows, mais moi je constate que sous linux celà pousse à la feignantise : je développe un soft, je te file les sources voir un rpm si j'ai pas trop la flemme et démerde toi avec les dépendances. Bref : end-user c'est à toi de bosser.


        Windows pousse aussi a la féneantise, je me pose pas de question, je créé mon package d'install avec TOUTES les dépendances en mode forcé et j'installe les DLLs a la bourinne.
        Au final j'ai des chances non négligeables de casser le système.
        Personellement je préfère le mode Linux ou au pire des cas ca ne marche pas, mais au moins ca ne casse pas tout mons système.


        Sous windows, c'est plutôt le boulot du développeur de faire un installeur, et il est obliger de réfléchir à son utilisation par l'utilisateur final (peut être parcque plus généralement ils vendent le produit et qu'ils se doivent de faire un peu attention à ce que le client puisse installer et utiliser le produit...).

        C'est toujours au devellopeur de faire l'installeur. En l'occurence sur un système GPL ce sera les fichiers autotools. Le fait que sous windows cela soit payant joue plutot contre les utilisateurs. Tu as déjà vu souvent un message qui te dit "je ne peux pas m'installer, je risque de casser quelque chose" sous Windows ? Ca arrive mais c'est très rare. La plupart des evndeurs préfèrent installer leur logiciel (surout pour les démos/sharewares) et tant pis si ca casse un truc.

        De toute façon Microsoft a trouvé la solution au problème des installations et des dll-qui-change-de-version

        Oui c'est la réinvention des DLLs statisques dont je parlais. Je trouve ca très crade. Mais comem 90% des problèmes de Windows vennaient de la ils ont été obligé de palier.

        abandon progressif de l'utilisation de la base de registre

        Très progressif alors, parceque c'est toujours la fête au village la dedans. le Regmon de sysinternal permet de bien se rendre compte de cela. En plus sous XPs la registry a encore grossi. Et on ne compte pas les interventions direct registry dans les doccuments d'aide de MS.

        Pour finir sous Windows comme sous Linux les devs sont par forcément très propres. Sous Linux c'est casse pied et sous Windows ca peut être dangereux (ou sinon c'est lourd avec la multiplication des DLLs)

        Kha

        • [^] # Re: Est-ce vraiment un mal ?

          Posté par  (site web personnel) . Évalué à 2.

          , je créé mon package d'install avec TOUTES les dépendances en mode forcé et j'installe les DLLs a la bourinne.

          Bah je viens de dire que Windows est capable de garder plusieurs versions d'une même dll... (dans un environnement bien particulier celà dis mais je te laisse deviner lequel ;-) ) Et puis celui qui se fait pas chier et qui fait un truc en mode forcé à la bourrine, il se fait pas chier à essayer de mettre les dll dans un dossier system, il les laisse dans le répertoire de son appli... Et puis faut quand même voir que le développeur feignant il utilise un truc qui fait tout le taf pour lui, genre Visual Studio qui lui fait le setup et gère les dépendances en empaquetant tout ce qu'il faut... du coup il évite des problèmes potentiels... En fait celui qui fait un setup foireux, c'est le non feignant qui veut tout faire à la patte qui fait tout planté... mais là encore c'est de plus en plus rare de trouver ce genre de développeur...

          En fait je me demande si la multiplication des dll c'est pas plus mal : après tout c'est négligeable vu la taille des durs actuels et c'est quand même plus propre à installer/désinstaller quand chacun met ce dont il a besoin dans son dossier...

          dll statiques... y'a pas un problème dans ta phrase ? Y'a un d dans dll ;-)

          • [^] # Re: Est-ce vraiment un mal ?

            Posté par  . Évalué à 1.

            Bah je viens de dire que Windows est capable de garder plusieurs versions d'une même dll...
            dll statiques... y'a pas un problème dans ta phrase ? Y'a un d dans dll ;-)

            C'est quoi l'interet d'une DLL si tu en as une copie par application ? D'ou mon terme de DLL statique, parcequ'elle apporte rien a être dynamique.

            il se fait pas chier à essayer de mettre les dll dans un dossier system, il les laisse dans le répertoire de son appli
            Et puis faut quand même voir que le développeur feignant il utilise un truc qui fait tout le taf pour lui, genre Visual Studio qui lui fait le setup et gère les dépendances en empaquetant tout ce qu'il faut... du coup il évite des problèmes potentiels...

            Ben pas vraiment non, il remet les DLLs la ou il les a trouvés sur son poste parceque c'est ce qui demande le moins d'effort avec les installeurs classiques, lesquels installeurs ne sont pas capables de prendre en compte des versions de DLLs qui n'existent pas, de comprendre qu'il va y avoir un probleme de localisation, demandent de la config pour changer les marqueurs décimaux de , a . etc.

            Le mec il bosse sur son PC avec l'appli qui lui fait tout seul les résolution de dépendance vers des trucs dont il ignore jusqu'a l'existence vers les versions que lui a installé tranquilement.

            En fait je me demande si la multiplication des dll c'est pas plus mal : après tout c'est négligeable vu la taille des durs actuels et c'est quand même plus propre à installer/désinstaller quand chacun met ce dont il a besoin dans son dossier...

            Ah OK, tu fais ca pour le plaisir de troller... Je me suis encore fait avoir moi .... Juste au cas ou : drivers, composants activeX, synchro de données, mutex etc.


            Kha

            • [^] # Re: Est-ce vraiment un mal ?

              Posté par  . Évalué à 2.

              Il faut quand même être honnête. En pratique, il y a plus de problèmes de dépendance sous Linux que sous Windows.

              D'abord parce que Windows est un système "constant", alors que Linux, de part le système des distributions, ne peut pas l'être (ou du moins, c'est pas gagner ...). Il faudrait plutôt comparer une seule distrib à Windows, plutôt que Gnu/Linux en général.
              Et imagine la panique d'un utilisateur banal lorsqu'on lui dit qu'il n'y a pas de rpm/deb pour sa distrib et qu'il a qu'à compiler... C'est dur à faire admettre et comprendre :-(, habitué qu'il est à la politique MS de compatibilité binaire. On a beau dire que sous Linux on a les sources et que la compatibilité binaire nous est inutile (sans blague ? :D), ça passe *très* mal.

              • [^] # Re: Est-ce vraiment un mal ?

                Posté par  . Évalué à 2.

                Je ne nie absolument pas du tout la facilité d'utilisation des installations windows. Mon seul but est de comparer les risques. Il est vrai que la compatibilité binaire est un gros plus, néamoins je maintient que je préfère compiler et résoudre les dépendances a la main comem c'est parfois obligatoire sous Linux, que de voir un installeur automatique me casser mon système sans que je puisse y afire quoi que ce soit, comme c'est parfois le cas sous Windows.

                Comem je l'ai évoqué rapidement dans mon post précédent les installs de drivers, d'objets activeX, ou certains installeurs passent au travers des protections de version DLLs de Windows. Lesquelles protections ne sont a mon sens que des caches misères sur un des problèmes les plus grave de windows.

                Entre les derniers drivers NForce3 et mon script hotplug+mise a jour du kernel je n'hésite pas un instant.
                J'hésite beaucoup moins sous Linux que sous windows deavnt une application un peu exotique, meme si je sais que je risque de galérer a l'installer. Et je ne pense pas être le seul dans ce cas.

                Kha

              • [^] # Re: Est-ce vraiment un mal ?

                Posté par  . Évalué à 1.

                Windows as un grand avantage avec seulement 2 grandes "versions" différentes et ce qui est dit ici est : Les installations sous windows sont un bordel innomable.

                Apprès que ce soit pire sous windows montre une chose :
                - Du point de vue de l'utilisateur il vaut mieux une base stable et un système d'installation chaotique qu'une base mouvante et un système d'installation de qualitée...

                Mais c'est peut-être parceque faire un système d'installation de qualité il est nécessaire de le lier fortement à toute la distrib et que pour ça il faudrait une base stable...

            • [^] # Re: Est-ce vraiment un mal ?

              Posté par  (site web personnel) . Évalué à 1.

              C'est quoi l'interet d'une DLL si tu en as une copie par application ?
              Euh, au pif, la modularité ? C'est quand même plus facile à maintenir... Et le partage peut aussi se faire dans une même solution, enfin moi c'que j'en dis...

              Ben pas vraiment non, il remet les DLLs la ou il les a trouvés sur son poste
              Je sais pas moi sous Visual Studio il me propose une option vachement cool par défaut : "local copy"

              Non je fais pas celà pour troller, je partais juste d'un constat.

              Pour ce qui est des drivers, c'est un cas bien à part... Encore que si les pilotes sont certifiés y'a quand même peu de chance qu'ils foutent la merde... Et puis bon, entre un pilote qui s'installe en 3 clicks sans redémarrer (quand c'est pas Windows qui va les chercher trankillement sur le net) et un pilote qui demande 36 dépendances, + une recompilation du noyau + l'ajout de modules, voilà quoi...

              Les ActiveX c'est du passé. Ils sont encore là à cause de l'existant. (au fait c'est quoi l'équivalent sous linux pour mettre Windows Media Player en un glisser-déplacer dans son application ?)

              • [^] # Re: Est-ce vraiment un mal ?

                Posté par  . Évalué à 1.

                un pilote qui s'installe en 3 clicks sans redémarrer

                Tu parle de ces pilotes graphiques qui te demandent de redémarer l'OS pour s'installer ???
                Car il est vrai que le fonctionnement d'un OS (Services, accès disques) et fortement dépendant du driver graphique :D

                • [^] # Re: Est-ce vraiment un mal ?

                  Posté par  (site web personnel) . Évalué à 1.

                  Bah désolé j'installe tous les pilotes de ma radeon en 3 clicks, il me propose effectivement de redémarrer, mais il suffit de ne pas le faire :)
                  Sinon à part ça la plupart du matos ne demande aucun redémarrage (enfin sous WinXP en tout cas)

              • [^] # Re: Est-ce vraiment un mal ?

                Posté par  . Évalué à 2.

                Les ActiveX c'est du passé. Ils sont encore là à cause de l'existant.

                C'est vrai il ne reste que DirectX, GDI, GDI+, Windows Media, RPC, OLE, 90% des plugins avec support du DRM, ODBC2, les bridge .Net etc. Bref rien de grave. Ceci etant LongHorn a l'air d'en avoir rajoué une petite centaine donc ca m'etonnerais que ca disparraisse demain matin. Je en parle pas bien sur des activeX purs, mais de tous les Objet COM, DCOM et de facon général de tout ce qui a besoin a un moment ou a un autre de faire appel a DLLHOST.EXE.

                Tous ces objets là il ne fait vraiment pas bon les avoirs en double, sinon quand on fait le copier collé d'une appli a l'autre on peut avoir de grosse surprises (crash de l'appli de destination avec une erreur de segment mémoire).

                Kha

                • [^] # Re: Est-ce vraiment un mal ?

                  Posté par  (site web personnel) . Évalué à 1.

                  Jusque là la plupart des API étaient et sont comme tu le décris, avec binding pour .NET. La plupart des nouveaux API de LongHorn sont d'abord conçu pour être utilisé dans le monde .NET, après s'ils proposent des activeX, là encore ce sera pour la compatibilité... Bref, c'est l'inverse qui se passe.

          • [^] # Re: Est-ce vraiment un mal ?

            Posté par  . Évalué à 1.

            En fait je me demande si la multiplication des dll c'est pas plus mal : après tout c'est négligeable vu la taille des durs actuels et c'est quand même plus propre à installer/désinstaller quand chacun met ce dont il a besoin dans son dossier...

            Et le jour ou il y as une faille de sécu pour la corriger tu est bon pour le calvaire, tu est partit pour recensser à la main toutes les versions de la dll incriminée et remplacer par une version patchée compatible (Ce qui selon le nombre de version sur le système deviens infaisable car il faudrait vérifier que la correction ne pose pas d'incompatibilités)

            Adapte ça à un parc de 300 machines et tu te dis que la multiplication des DLL c'est VRAIMENT VRAIMENT plus mal :p

      • [^] # Re: Est-ce vraiment un mal ?

        Posté par  . Évalué à 0.

        Tiens, la base de registre...
        J'ai vu un truc qui m'a fait peur : par défaut sous win2000 le service d'accès au registre à distance est activé !
        Si pBpG ou un autre qui s'y connaisse pouvait m'expliquer le pourquoi du comment...

        • [^] # Re: Est-ce vraiment un mal ?

          Posté par  (site web personnel) . Évalué à 1.

          Je suppose que c'est utile pour un autre service, l'accès au bureau à distance, bien pratique pour le newbie qui a besoin de se faire dépanner par le petit neveu à l'autre bout de la france... Mais je suis pas sûr.

          • [^] # Re: Est-ce vraiment un mal ?

            Posté par  . Évalué à 0.

            Oui mais pour l'accès à distance, y'a VNC ou équivalent, non ?
            Là c'est pas dangereux ? En cas de faille de sécu, comme c'est activé par défaut, vlan accès au registre à distance ! Génial, dans le registre si mes souvenirs sont bons sur un 98 en changeant une clé on peut détruire une résolution d'écran et provoquer un écran bleu à la place (je sais plus comment j'avais fait :)

            • [^] # Re: Est-ce vraiment un mal ?

              Posté par  (site web personnel) . Évalué à 1.

              Oui mais pour l'accès à distance, y'a VNC ou équivalent, non ?
              OUi mais par défaut Microsoft ne fournit pas VNC mais le bureau à distance.
              Tu peux regarder dans l'outils de gestion des services la propriété "dépendances" pour voir tous les services qui dépendent de l'accès au registre à distance.
              Sinon pour savoir si celà peut être un problème de sécurité, si tu pars de ce principe tu supprimes toute notion d'accès à distance... Je te conseille de ne pas brancher ton Windows à l'Internet, bah oué en cas de faille de sécurité ?

              (et puis il suffit d'utiliser les failles de IE si on veut foutre la merde sur un pc, pas besoin de passer par la base de registre à distance une fois que t'as réussi à installer quelque chose sur le pc ;))

              • [^] # Re: Est-ce vraiment un mal ?

                Posté par  . Évalué à 0.

                Tout à fait d'accord
                Mais quand même y'a une limite, non ? Entre avoir 15 possibilités d'applis qui ouvrent une faille et 30, je préfère en avoir que 15 !

                • [^] # Re: Est-ce vraiment un mal ?

                  Posté par  (site web personnel) . Évalué à 1.

                  Oui mais dans ce cas précis Microsoft a préféré choisir la solution de fourni un outil d'aide à distance utilisable par le commun des mortels aisément. C'est toujours le même débat entre accessibilité et sécurité... Reste que Windows c'est pour les newbies donc c'est bien pour eux (pour un Windows Server effectivement ce ne serait peut être pas justifié).

              • [^] # Re: Est-ce vraiment un mal ?

                Posté par  . Évalué à 1.

                et puis il suffit d'utiliser les failles de IE si on veut foutre la merde sur un pc

                Ce que tu dis ne veut rien dire, le problème posé est un problème de sécurité, qui est en fait le risque de laisser ouvert un service à tout vas par défaut, risque qui n'est pas négligeable, les services d'authentification (Sasser) et de DCOM (Le précédent je sais plus le nom) et leurs failles l'ont prouvé.
                C'est un problème car en cas de faille il laisse accès à tout PC ou ce n'est pas désactivé tant qu'il est pour un réseau.
                Je ne vois pas le rapport avec IE qui est un soft pour interpréter les pages HTML, activer une faille dedans nécessite alors du Social engeenering pour ammener la personne sur le site présentant le code malicieux. Là ou à contrario une faille d'un service ouvert en permannence peut permettre à un pirate d'entrer sans faute de l'utilisateur ce qui est un risque beaucoup plus grand.

                Sinon pour savoir si celà peut être un problème de sécurité, si tu pars de ce principe tu supprimes toute notion d'accès à distance

                Il y as une différence comme dit plus haut entre les risques posés par un programme client comme un navigateur web, et ceux posés par un programme qui ouvre un port en écoute et fait donc office de serveur comme ce dont on parle ici.

                Note: Par contre comme dit précédement Windows 2000 n'existe pas en version personelle, c'est donc un OS destiné aux professionnels qui donc prennent leurs responsabilités et son censés savoir le configurer, mais je ne cautionne pas l'activation de service par défaut.

                Note : Au passage microsoft s'amméliore et sur les windows 2003 (Comme le 2000 il n'en existe pas de version personelle) microsoft s'amméliore grandement et n'as laissé que peux de services activés, même DirectX ne peut être installé sans activer des choses. Ils ont fait des erreurs mais semblent quand même s'en rendre compte, après tout pas toutes les distribs linux sont regardantes sur ce qui est lancé par défaut...

        • [^] # Re: Est-ce vraiment un mal ?

          Posté par  . Évalué à 1.

          Peut-être car windows 2000 n'existe pas et que l'OS se nomme windows 2000 Pro ou Serveur et qu'il est fait pour des personnes qui savent ce qu'est un OS, un service, une console d'administration et autres outils de configuration.

      • [^] # Re: Est-ce vraiment un mal ?

        Posté par  . Évalué à 1.

        De toute façon Microsoft a trouvé la solution au problème des installations et des dll-qui-change-de-version : Windows peut conserver plusieurs versions d'une même dll au même endroit (hop plus de conflit de version)

        J'espère juste que tu ne parle pas du GAC pour .Net, même microsoft ils conseille le déploiment en x-copy (Copier coller de toutes les dll dépendantes dans le dossier du programme)

        Et le GAC seulement pour les trucs partagés entre appli/ordinateurs ou les libs de bases.

        Ils se sont rendu compte (Et j'ai beau aimer le projet mono ils sont en train de s'en rendre comtpe aussi sufit de lire les ML) que c'était très loin de résoudre quoi que ce soit et que ça posait même des problèmes suplémentaires : Pour un utilisateur qui sait ce qu'il fait c'est le top, pour un utilisateur lambda ça peut vite tourner au calvaire...

        • [^] # Re: Est-ce vraiment un mal ?

          Posté par  (site web personnel) . Évalué à 1.

          Tout à fait d'accord, le GAC c'est pour les libs de base, sinon x-copy comme je l'ai mentionné. Le premier système de "partage" permet effectivement de foutre la zone, mais il est quand même bien utile pour mettre jour les libs de base (correction de bugs ou failles de sécurité)...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.