Journal PHP (7) est mort ! Vive PHP (8) !

Posté par  . Licence CC By‑SA.
Étiquettes :
17
28
nov.
2022

Bonjour Nal,
C'est aujourd'hui que le support de sécurité de PHP 7.4 touche à sa fin, mettant ainsi définitivement fin au support de la branche 7 de PHP.
Désormais, ne seront supportées que les versions 8.0 (support de sécurité seulement, et pour encore 1 an : le support actif ayant pris fin avant-hier) et 8.1 (version actuelle).
Vous pouvez retrouver toutes ces informations sur cette page officielle de PHP.

Tout ça en attendant la sortie de la prochaine version 8.2, prévue initialement pour la semaine dernière, mais finalement reportée au 8 décembre [une dépêche est en cours de rédaction, NdA].

  • # Debian (trop) stable

    Posté par  . Évalué à 6. Dernière modification le 28 novembre 2022 à 13:27.

    Merci pour cette info, je ne suis pas d'assez près ce genre d'infos en général.

    Question que nous sommes probablement plusieurs à nous poser:

    Savez-vous ce qu'il va en être de Debian Bullseye qui a choisi PHP 7.4 dans ses dépôts stable; une mise à jour vers PHP8 semble peu probable en cours de route, ce n'est pas leur genre; va-t-il falloir se tourner vers les dépots backports pour les logiciels invitant très fortement à utiliser PHP 8 et supérieur ?

    • [^] # Re: Debian (trop) stable

      Posté par  . Évalué à 7.

      Je ne veux pas me substituer à un expert Debian ou quelqu'un du projet. N'hésitez pas à compléter.

      Normalement Debian Bullseye est parti avec PHP7.4 et ne passera pas à PHP8.

      Si vous avez besoin de PHP8 parce qu'il y a des fonctions qui vous sont nécessaire ou que c'est pour un nouveau développement qui n'est pas pour demain matin, Debian Bookworm est pour l'instant sur la version 8.1. Ce n'est pas la version stable de Debian, mais elle s'installe sans trop de douleur; et pour développer, je n'ai jamais eu de soucis.

      Pour Bullseye, normalement l'équipe en charge de la sécurité assurera dans la mesure du possible, le rétro-portage de tout correctif de sécurité détecté dans la 7.4 jusqu'à un an après la sortir de Bookworm. https://www.debian.org/security/faq#lifespan

      C'est le cas au moins pour les principales distributions Linux qui assurent un suivi de sécurité de leurs paquets au delà du support "à la source".

      • [^] # Re: Debian (trop) stable

        Posté par  . Évalué à 2. Dernière modification le 29 novembre 2022 à 11:17.

        Dans mon cas c'était plus pour héberger des applis, telle Nextcloud, qui arrêtent le support assez rapidement, les nouvelles versions avec les mises à jour de sécurité ne seront pas disponible sur les anciens PHP.

        Mais merci pour les informations complémentaires et aux commentaires en dessous :)

    • [^] # Re: Debian (trop) stable

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

      Tu as aussi la possibilité de passer par https://deb.sury.org/ pour installer les versions les plus à jour de PHP 7.4, 8.1 ou même déjà des versions de 8.2

      Les instructions : https://packages.sury.org/php/README.txt

      Jérôme

      • [^] # Re: Debian (trop) stable

        Posté par  . Évalué à 4.

        C'est d'ailleurs ce qu'utilise Yunohost, car il est nécessaire d'avoir la version 8 de php pour certains paquets.

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: Debian (trop) stable

        Posté par  . Évalué à 2.

        et pour les utilisateurs d'Ubuntu, Ondřej Surý (développeur Debian qui s'occupe de PHP depuis un bon moment) cuisine les divers paquets de PHP et les sert sur ce PPA: https://launchpad.net/~ondrej/+archive/ubuntu/php

  • # PHP 5.x

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

    En attendant y a toujours (beaucoup?) de vieux PHP qui tourne en production et qui ne veux pas mourir. Je serai curieux d'en avoir les statistiques si quelqu'un en a un lien. On est pas loin du zombie, PHP5.x, le mort-vivant.

    • [^] # Re: PHP 5.x

      Posté par  . Évalué à 4.

      Je suis actuellement développeur chez un journal national : on a encore du PHP 5.4 !
      Je ne peux même pas écrire :

      $var = [];
      • [^] # Re: PHP 5.x

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

        GET "/board.php3" car nous n’avons plus de PHP3 depuis un certain temps déjà

        (Analyse des logs Ruby on Rails de LinuxFr.org de début novembre 2022)

      • [^] # Re: PHP 5.x

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

        Pourtant, rendre le code compatible aux versions futures le rend plus maintenant et moins bogué, puis quand on migre on bénéficie de la vélocité des nouvelles versions mais on va préférer investir dans plus de hardware (CPU et RAM sans compter l'archi de l'infra qui devient overkill) pour à peine obtenir les mêmes résultats. Une fois que les managers avisés en auront marre, ils vont juste taper sur le langage (et dire que tel nouveau est mieux sans sourciller de l'énormité de comparer du PHP du siècle dernier avec la version actuelle d'un autre langage qui parfois n'est ps aussi performant que la dernière version de PHP.)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: PHP 5.x

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

          Le problème est qu'une montée de version de langage a un coût non négligeable pour un résultat très peu visible la plupart du temps. Contrairement à un papier peint qui se décolle, un pneu qui crève ou une tâche indélébile sur une chemise, les programmes informatiques n'affichent pas beaucoup leur vieillissement, sauf le jour où ça plante et ça ne repart plus… (ou bien quand le nouveau jeune alternant fait un choc anaphylactique devant les écrans verts sur fond noir gérés avec les touches de fonctions).

          • [^] # Re: PHP 5.x

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

            On est d'accord. Sauf que les DSI ont cru éviter un coût et ont fini par le déplacer ailleurs en plus de l'augmenter. Cerise sur le gâteau, on tourne sur un socle plus mis à jour depuis des lustres (7 ans en informatique ça fait beaucoup) mettant la sécurité en jeu (c'est du même accabit que de faire tourner Win95 ou de rouler avec des pneus usés) …sachant que ce sont des millions de chiffre d'affaire qui vont partir en fumée.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: PHP 5.x

              Posté par  . Évalué à 6.

              Et que le défaut de sécurisation est puni par la loi de manière potentiellement vénère. C'est comme si les conducteurs de bus acceptaient de rouler avec des épaves. Ce n'est pas simplement leur confort qui est en jeu mais leurs utilisateurs et via le RGPD leur entreprise. Cela pourrait être apparenté à de la malfaçon.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: PHP 5.x

            Posté par  . Évalué à 5.

            Le problème est qu'une montée de version de langage a un coût non négligeable[…]

            Non il est surestimé. Plus important encore quelque soit ce coût, il augmente avec le temps. Et non le manager n'a aucune idée de ce que c'est ni de son importance c'est aux gens techniques de le faire avancer tout comme c'est à eux d'expliquer ce que l'on peut ou ne peut pas implémenter.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: PHP 5.x

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

              le manager n'a aucune idée de ce que c'est ni de son importance

              C'est pas Dilbert qui disait que les incompétents on les mettaient à l'encadrement,
              car c'est la qu'ils faisaient le moins de dégâts ?

              • [^] # Re: PHP 5.x

                Posté par  . Évalué à 2.

                C'est pas à un manager d'avoir de la maitrise de ce genre de choses. C'est pas lui qui fait la veille technique pour savoir qu'elle est la santé technique du code.

                C'est pas Dilbert qui disait que les incompétents on les mettaient à l'encadrement,
                car c'est la qu'ils faisaient le moins de dégâts ?

                Je suis pas très à l'aise avec ça. Ça porte des préjugés qui me paraissent dommageables (des préconçus sur le management, sur la manière d'envisager la compétence, sur comment on aime se placer sur du point de vu des développeurs,… et plus j'y réfléchis plus j'en vois).

                Le principe de Peter est bien plus neutre à mon humble avis et s'applique quelque soit le métier. Et oui c'est un problème de considérer que le management est une suite logique d'un métier non-encadrant (sans chercher à cloisonner que quelqu'un se réoriente c'est très bien, mais comme toute réorientation ça se fait avec une formation).

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: PHP 5.x

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

                  C'est pas à un manager d'avoir de la maitrise de ce genre de choses. C'est pas lui qui fait la veille technique pour savoir qu'elle est la santé technique du code.

                  Tout a fait d'accord mais il doit quand même connaître un minimum de choses, ou au moins être capable de comprendre

                  sinon autant confier une bibliothèque à quelqu'un qui ne sait pas lire

                  • [^] # Re: PHP 5.x

                    Posté par  . Évalué à 2.

                    sinon autant confier une bibliothèque à quelqu'un qui ne sait pas lire

                    Ou laisser l'écriture d'une symphonie à un sourd ? ;)

                    Tout a fait d'accord mais il doit quand même connaître un minimum de choses, ou au moins être capable de comprendre

                    C'est un gradient moins il en sait plus il doit pouvoir déléguer/être à l'écoute des autres.

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: PHP 5.x

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

                      Ou laisser l'écriture d'une symphonie à un sourd ? ;)

                      Pas mal comme réponse ;)

                      mais le cas est un peu exceptionnel quand même et AVANT d'être sourd il avait fait un peu de musique aussi :)

                      C'est un gradient moins il en sait plus il doit pouvoir déléguer/être à l'écoute des autres.

                      Avec le risque de déléguer n'importe quoi vers n'importe qui, ce qui devient une patate chaude que plus personne ne veut.
                      Sinon il délègue toujours les mêmes taches vers les mêmes personnes, ce qui cloisonnent complètement les choses, et certaines personnes se retrouvent nommé à vie pour certaines choses pénibles.

                      Ces managers la … tu peux les remplacer par une réunion d'équipe hebdomadaire et un outil style KANBAN

                      • [^] # Re: PHP 5.x

                        Posté par  . Évalué à 2.

                        mais le cas est un peu exceptionnel quand même et AVANT d'être sourd il avait fait un peu de musique aussi :)

                        C'était plus pour la blague qu'autre chose.

                        Avec le risque de déléguer n'importe quoi vers n'importe qui, ce qui devient une patate chaude que plus personne ne veut.
                        Sinon il délègue toujours les mêmes taches vers les mêmes personnes, ce qui cloisonnent complètement les choses, et certaines personnes se retrouvent nommé à vie pour certaines choses pénibles.

                        C'est là exactement le travail du manager. Organiser des gens pour qu'ils se parlent quand il y a besoin ou qu'il fasse la jonction si c'est plus pertinent et savoir quand et quoi déléguer à qui (et savoir que déléguer n'empêche pas d'accompagner).

                        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                        • [^] # Re: PHP 5.x

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

                          Je connais le travail de "manager" ou d'encadrement, pour l'avoir pratiqué de temps en temps
                          sur des projets divers et variés, y compris en dehors de l'informatique.

                          Et cette expérience me permet de repérer "le bon grain de l'ivraie", et il y a du vécu aussi ;)

                    • [^] # Re: PHP 5.x

                      Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 02 décembre 2022 à 13:47.

                      Il y a des sourds qui y entendent des choses à la musique… (par contre faut qu'il y ait de la basse car c'est surtout le ressenti des vibrations… et sinon on peut apprécier aussi une partition à plusieurs niveaux)

                      Tiens, me rappelle un lien qui posait la question de savoir si les managers devaient être très compétents techniquement ou pas.
                      https://linuxfr.org/users/gilcot/liens/our-cto-should-actually-be-technical

                      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: PHP 5.x

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

        Cela ne fait que 7 ans qu'il n'y a plus de mise à jour de sécu (3 Sep 2015 )

        https://www.php.net/eol.php

        Vous êtes large !

Suivre le flux des commentaires

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