Journal Novell sort un Service Pack 1

Posté par  (site web personnel) .
Étiquettes :
0
20
juin
2007
Alors ça, c'est un coup de génie !
Novell vient d'annoncer la sortie d'un SP1 pour sa Suse Linux Enterprise 10.
Magnifique, rien à dire, c'est parfait. En fait, j'hésite entre la démagogie et le génial coup de marketing.
Des mises à jour automatiques ? Des programmes dispo sur les serveurs, à installer un par un si on veut ? C'est d'un ringuard !!! Nan, pour impressionner les DSI, il faut des Service Pack. Le vendeur en cravate, il dit que Novell assure des SP régulièrement, et hop c'est signé, emballé, c'est pesé.
C'est une suite des accords avec Microsoft, qui leur a donné cette idée géniale ?

Mandriva, ou toutes les autres, devraient faire pareil ! Pour la 2007.1, ou Spring, ils auraient dû retoucher un peu l'installeur, et appeler ça un Service Pack, et voilà.

  • # Ca peut aider parfois !

    Posté par  . Évalué à 10.

    Dans certains domaines hautement critique, tu as besoin de savoir quel système d'exploitation tu utilises. Le problème avec Linux et les mises à jour, c'est que pour connaître la version exacte de ton système, tu es obligé de sortir la liste des programmes installés. Sous windows par exemple, tu peux connaître la version de ton système en ne sortant que la liste des mises à jour : Windows XP SP2 + kb4444 + kb55555. Le terme SP2 te permet de ne pas sortir la liste de 150 mises à jour.

    Donc pour Suse Linux, tu pourras dire que tu es sous Suse SP1 + telles mises à jour. Ca va te simplifier la tâche un peu.

    Après, si tu profites de cela pour taper sur les autres, c'est ton problème.

    • [^] # Re: Ca peut aider parfois !

      Posté par  . Évalué à 4.

      Tout a fait d'accord. Il arrive d'ailleurs que l'on ait besoin d'un système avec X patches mais qui pour des raisons obscures (les sysadmins sont des fois prano!) ce meme système ne peut être connecté à internet. La solution du Service Pack est dans ce cas idéal.

      PS: Ce nèst pas parce que M$ use et abuse des SPs que cela est forcément mauvais.....

    • [^] # Re: Ca peut aider parfois !

      Posté par  . Évalué à 6.

      Au contraire, moi je trouve que le terme service pack ne donne aucune information. Si y a un problème avec une application, on se moque pas mal des correctifs des 150 autres dont ton application ne dépend pas!

      Ce qui est bien avec linux c'est que si t'a un problème avec un logiciel, tu n'a qu'à regarder la version du logiciel dans ton gestionnaire de paquets, la version de ses dependances et la version du kernel.
      Avec ça t'as une information précise, tu contrôle le problème, tu peux savoir s'il y a déjà eu des retours de bug et des patch proposés...
      Alors qu'avec le service pack... tu sait rien! Et pour contribuer sur le bugzilla officiel de l'application, ça va pas les aider si tu leur dit : mon machin bidule plante quand je fait ça sous Suse Linux SP2 ... Ils ont besoin d'informations précises, ils connaissent pas par coeur les versions des logiciels de Suse Linux SP2.

      • [^] # Re: Ca peut aider parfois !

        Posté par  . Évalué à 3.

        Ils ont besoin d'informations précises, ils connaissent pas par coeur les versions des logiciels de Suse Linux SP2.


        Au contraire, c'est la moindre des choses pour un service de support chez Novell. Évidemment pas forcément par c½ur, mais facilement accessible l'info.

      • [^] # Re: Ca peut aider parfois !

        Posté par  . Évalué à 3.

        Dans une démarche contractuelle, il est important de tracer les différentes versions d'un produit déployées afin de mieux identifier chacune de ses composantes. On appelle ca la gestion de configuration.
        Le fait d'identifier une configuration permet d'identifier chacune de ces composante précisément.
        A partir du moment où on connait la version, on est capable de lui associer les changements qui lui on été apportés par la fourniture d'un document associé qui est alimenté également par une autre discipline de gestion de projet , le suivi des demandes de changement.

        Or il se trouve qu'une distribution commerciale linux est un produit comme un autre. Ces versions de référence permettent un suivi précis pour les demandes commerciales et sont plus productives si le client procède à des mises à jour identifiées. Dans ton cas ca veut dire qu'au moindre problème Novell va passer tout son temps à reproduire un environnement identique au tien, devra retrouver les sources et dependances associés une par une puis en déduire les changements qu'il englobait et le faire pour chaque client.
        Une structure commerciale n'est pas en mesure de fournir un tel investissement ou elle va droit à la faillite.
        Le client utilise dionc des versions identifiées supportées et surtout testées. S'il décide de faire ces mises à jour dans son coin il est normal que l'editeur nassume pas le support puisqu'il n'a pas pu tester cette configuration. La combinatoire rend matériellement impossible les tests exhaustifs.

      • [^] # Re: Ca peut aider parfois !

        Posté par  . Évalué à 7.

        Ce qui est bien avec linux c'est que si t'a un problème avec un logiciel, tu n'a qu'à regarder la version du logiciel dans ton gestionnaire de paquets, la version de ses dependances et la version du kernel.

        Et chez Windows tous les binaires ont un numero de version, bref meme topo. T'as simplement un nom (Service Pack) qui n'est vraiment rien d'autre que :
        "On a un ensemble de tous ces patchs qu'on a teste serieusement, et l'ensemble fonctionne bien"

        Ca permet d'avoir une ligne de depart tous les ans a peu pres, plutot que donner la liste des 423 patchs installes sur ton systeme. Mais t'es toujours libre de donner des numeros de version si tu y tiens vraiment, ca ne change rien.

        Alors qu'avec le service pack... tu sait rien! Et pour contribuer sur le bugzilla officiel de l'application, ça va pas les aider si tu leur dit : mon machin bidule plante quand je fait ça sous Suse Linux SP2 ... Ils ont besoin d'informations précises, ils connaissent pas par coeur les versions des logiciels de Suse Linux SP2.

        Le truc c'est que les entreprises elles vont pas a travers le bugzilla, mais a travers l'entreprise qui fait le support (Redhat, Novell, ...)

  • # Hu ?

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

    C'est quoi le soucis ? Qu'il le nomme "SP1" ?

    Parce que des révisions de distribution stable ca existe dans d'autre distribution.

    Debian sort de R... (genre la derniere sarge est un R6 -> http://www.us.debian.org/News/2007/20070407 ).

  • # C'est pas nouveau !

    Posté par  . Évalué à 10.

    euh, sur sles9 ils ont déjà sorti 3 SP !

    et puis RedHat le fait également et ils appellent ça des Updates
    ça leur permet juste d'éditer de nouveaux média pour les installations, d'intégrer les mises à jour pilotes pour le support de nouveaux matériels, etc.

    • [^] # Re: C'est pas nouveau !

      Posté par  . Évalué à 4.

      > et puis RedHat le fait également et ils appellent ça des Updates

      Oui.

      > ça leur permet juste d'éditer de nouveaux média pour les installations, d'intégrer les mises à jour pilotes pour le support de nouveaux matériels, etc.

      Pas seulement. Un update chez RHEL, reste 100 % compatible source et binaire avec la version précédente. Mais un update peut aussi ajouter des fonctionnalité.

      Exemple :
      RHEL 4 :
      RHEL 5 : nouvelles fonctionnalités et compatibilité avec RHEL 4 non garantie.

      RHEL 4 update 2 :
      RHEL 4 update 3 : nouvelles fonctionnalités et compatibilité avec RHEL 4 update 2 garantie.

      Dans "nouvelles fonctionnalités", il n'y a pas que des nouveaux drivers.
      Des errata ne justifient pas la sortie d'un update.

      Lorsqu'on a une souscription, on passe automatiquement d'update en update (puisque la compatibilité est garantie).

      Les Service Pack de MS n'offre pas toujours une compatibilité ascendante. Mais en général ça le fait.

  • # Vive les trolls

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

    Non sérieux, tu ne t'es pas dit que peut être certaines entités n'ont pas les mêmes besoins que toi ?

    On ne passe pas comme ça à l'aveugle des mises à jour sur certains serveurs de production. Ca se prévoit, ça se teste longuement, on fait des études d'impact ... et même avec tout ça on prend un risque.

    Tout ça prend du temps et comme on ne peut pas faire travailler 5 équipes de migration/test/qualification en permanence, on regroupe les mises à jour en étapes importantes. Ca évite de lancer la grosse machinerie toutes les demi journées à chaque mise à jour.

    Du coup on sépare les tous petits updates urgents (résolution de bug bloquant et mises à jour de sécu critiques) qu'on fait passer très régulièrement, et de temps en temps, plus rarement, on tente une mise à jour plus grosse avec des mises à jour qui sont nécessaires mais moins urgentes/critiques.

    Les faire par gros palier permet de tout qualifier en même temps et aussi de pouvoir parler un langage commun avec les éditeurs et ceux qui assurent le support. On sait qu'on est en version 12.3 et pas en 12-qui-date-de-jeudi-18-juste-avant-la-mise-a-jour-de-18h03. Tout le monde a un environnement cohérent et c'est d'autant plus simple/efficace pour assurer la stabilité de l'ensemble et l'organisation des équipes de production.

    Alors oui, pour plein de gens les service pack c'est super important, peu importe comment tu les appelles. RedHat en fait d'ailleurs depuis longtemps mais il les appelle des "update" (RHEL 3r3, le r3 étant plus ou moins un service pack).


    Maintenant on peut aussi jouer le troll et tout dénigrer dès que ça ressemble de près ou de loin à quelque chose qui se fait du coté de chez Redmond. Mais je ne suis pas sûr que cette dernière option soit la meilleure

    • [^] # Re: Vive les trolls

      Posté par  . Évalué à 0.

      Je pense que le monsieur, il fesait allusion au termes "service pack" qui est très microsoftien....

Suivre le flux des commentaires

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