Discussion :

[Stéphane le calme]

Microsoft annonce qu'il ne va plus offrir de support à PHP sur Windows dès la version 8.0
dont la sortie est prévue pour novembre

Microsoft a annoncé qu'il n'offrirait pas de support « à quelque titre que ce soit » à PHP pour Windows dès la sortie de la version PHP 8.0.

Microsoft a fourni une assistance pour le développement et la construction du langage de programmation PHP sur Windows. Cette prise en charge comprend le développement de correctifs de sécurité pour PHP et la création de versions natives de Windows. Avec la sortie prévue de PHP 8.0 en novembre 2020, Dale Hirt, responsable de Microsoft PHP Windows, a déclaré sur la liste de diffusion PHP Internals que l’éditeur n’avait pas l’intention de prendre en charge PHP 8.0 pour Windows :

« Nous soutenons actuellement PHP en termes de développement et de build sur les versions PHP 7.3 et PHP 7.4. De plus, nous nous impliquons dans les builds PHP 7.2 sur Windows lorsque des correctifs de sécurité sont requis. Cependant, tandis que PHP 8.0 est en progression, nous voulions faire savoir à la communauté quels sont nos plans actuels.

« Nous savons que la cadence actuelle est de 2 ans à compter de la sortie pour les correctifs de bogues, et d'un an après pour les correctifs de sécurité. Cela signifie que PHP 7.2 sera hors de prise en charge en novembre. PHP 7.3 entrera en mode correctif de sécurité uniquement en novembre. PHP 7.4 continuera d'avoir une autre année de correction de bogues, puis une année de correctifs de sécurité. Nous nous engageons à maintenir le développement et les builds de PHP sur Windows pour les versions 7.2, 7.3 et 7.4 tant qu'elles sont officiellement prises en charge. Nous n’allons cependant pas prendre en charge PHP pour Windows à quelque titre que ce soit à partir de la version 8.0 et au-delà ».

Pour ajouter de la clarté à la publication de Hirt, Sara Release Manager, PHP Release Manager, a publié un billet dans lequel elle a expliqué que cela ne signifie pas que PHP 8.0 ne sera pas pris en charge dans Windows. Cela signifie simplement que Microsoft ne sera plus l’entité qui produit les builds officiels de PHP sur Windows :

« Pour apporter du contexte qui pourrait éventuellement manquer, Microsoft administre https://windows.php.net et produit toutes les versions officielles de PHP pour Windows. Si vous exécutez `php.exe`, ou `mod_php7.dll` ou quel que soit le nom des versions de websapi, vous utilisez soit les propres versions de PHP de Microsoft, soit vous les compilez vous-même.

« Ce message signifie que Microsoft ne produira pas de versions officielles à partir de PHP 8. Ce message ne signifie PAS que personne ne le fera.

« Très probablement, le projet dépoussiérera une machine quelque part dans le cloud exécutant Windows (probablement à l'aide d'une licence gratuite généreusement fournie par MS) et mettra en place des processus de build automatisés pour les faire "en interne".

« Ces machines peuvent même être configurées / entretenues par les mêmes personnes qui effectuaient les versions officielles de Microsoft. Nous sommes encore dans la phase de réaction initiale ici, mais le résultat est qu'il y aura probablement très peu de changements pour les utilisateurs de Windows ».

Microsoft n'a pas expliqué pourquoi il ne prendrait plus en charge PHP 8.0, mais cela pourrait être dû à la prise en charge étendue de PHP déjà existante dans le sous-système Windows pour Linux (WSL). Microsoft a développé activement WSL, qui permet aux utilisateurs d'installer diverses distributions Linux qui s'exécutent directement dans Windows 10.

Étant donné que ces distributions prennent déjà en charge PHP 7.4 et prendront en charge PHP 8.0 lors de leur publication, Microsoft peut juger inutile de continuer à prendre en charge une version PHP native dans Windows.

Source : Microsoft (liste de diffusion PHP)

Et vous ?

Qu'est-ce qui pourrait, selon vous, expliquer cette décision de Microsoft ?

Voir aussi :

Les nouveautés de PHP 8 - Sortie de la version alpha 1 prévue le 25 juin 2020 ! Par Alexandre Tranchant
Une campagne d'attaques massives cible 900 000 sites WordPress en une semaine, la redirection des visiteurs vers des sites malveillants et l'installation de portes dérobées PHP ont été découvertes
PHP 8 : voici un aperçu des nouveautés attendues dans la prochaine version majeure du langage, selon un développeur PHP

[Sodium]

Je pense aussi que cela doit être lié à l'intégration WSL. PHP sous Windows ça fonctionne, mais ça n'est jamais sans soucis, ne serais-ce que pour la complexité de l'utilisation de paquets qui vont généralement main dans la main avec ce langage serveur. À moins qu'il y ait eu des évolutions récentes, la librairie Imagick par exemple est impossible à installer sous Windows à part un vendredi 13 de pleine lune après un sacrifice humain à Quetzalcoatl.

WSL permet de mettre en place un serveur LAMP sous Linux en quelques lignes de commande, c'est une bonne manière de se former petit à petit à son utilisation afin d'être prêt lorsqu'il s'agira de travailler avec un vrai serveur de production, et un serveur de production Windows/Apache|Nginx/PHP est rarement une bonne idée. Non pas que ça ne soit pas possible, mais mieux vaut utiliser la technologie la mieux adaptée.

[grunk]

Microsoft a annoncé qu'il n'offrirait pas de support « à quelque titre que ce soit » à PHP pour Windows dès la sortie de la version PHP 8.0.

On sait si il vont continuer le support des drivers sqlserver ? Si c'est pas le cas ca va être problématique.

un serveur de production Windows/Apache|Nginx/PHP est rarement une bonne idée.

Pourquoi ? Je serais curieux d'avoir des explications argumentés la dessus.

[Sodium]

Le premier point c'est que ça veut dire s'encombrer d'une couche OS rajoutant une lourdeur et un prix de licence au serveur pour des technologies qui sont pensées pour être utilisées et configurées en ligne de commande.

Ensuite il s'agit essentiellement d'outils open source, avant tout développés et testés pour de l'open source, avec de la documentation sur l'installation de paquets basée sur de la ligne de commande, une communauté largement développée offrant un support important... toujours sous Unix/Linux. De même, les développeurs et administrateurs serveurs du monde PHP sont rarement bien rodés sur l'administration de serveur Windows.

Bref, un serveur Apache|Nginx/PHP sous Windows ça marche, mais à quel prix et pourquoi faire ?

[valaendra]

Les contributeurs qui prendront la relève feront du bon boulot Ms veut mettre en avant le sous système linux, le reste c'est du blabla.

Le premier point c'est que ça veut dire s'encombrer d'une couche OS rajoutant une lourdeur et un prix de licence au serveur pour des technologies qui sont pensées pour être utilisées et configurées en ligne de commande.

Ensuite il s'agit essentiellement d'outils open source, avant tout développés et testés pour de l'open source, avec de la documentation sur l'installation de paquets basée sur de la ligne de commande, une communauté largement développée offrant un support important... toujours sous Unix/Linux. De même, les développeurs et administrateurs serveurs du monde PHP sont rarement bien rodés sur l'administration de serveur Windows.

Bref, un serveur Apache|Nginx/PHP sous Windows ça marche, mais à quel prix et pourquoi faire ?

PHP ne se limite pas à wordpress... Et Windows ne se limite pas à l'interface graphique (les admins WinServer en ILC, c'est quelque chose à voir^^), ni à Wamp ou consorts...

Le côté open source de PHP a justement permis une version Windows...

De plus, il y a une version PHP Windows officielle, recommandée pour la production. PHP s'intègre très bien aussi dans IIS.

Dans certains S.I full-windows, n'essayez même pas de proposer une VM Linux aux admins au risque de vous prendre un jet de tomates en pleine poire

Je ne suis pas pro Windows, loin de là mais je vous recommande de vous renseigner avant de prendre vos croyances pour la réalité.

[Sodium]

Je te recommande d'arrêter les arguments à base de "oui mais", c'est juste fatiguant. Je ne vois pas non plus ce que ta remarque sur Wordpress vient faire sur le sujet.

Oui on peut. Non ce n'est pas idéal, pour entre autre raisons que j'ai évoquées plus haut.

Bref, un peu bizarre de venir défendre Windows comme plateforme de production PHP sur une news s'intitulant "Microsoft annonce qu'il ne va plus offrir de support à PHP sur Windows dès la version 8.0".

[wilo_ahadi]

Cette décision de Microsoft aura-t-il un impact sur la position de PHP au marché mondial des technologies backend ?

[grunk]

Le premier point c'est que ça veut dire s'encombrer d'une couche OS rajoutant une lourdeur et un prix de licence au serveur pour des technologies qui sont pensées pour être utilisées et configurées en ligne de commande.

La license c'est hors de propos , c'est le problème de l'entreprise. Si effectivement la stratégie vise à ne payer de licence , évidemment le bon choix est linux.
En quoi l'UI ajoute une lourdeur ? Il faudra probablement dimensionner la machine en conséquence , on aura une utilisation de ram supérieur à un linux minimal mais à part ca je vois pas bien
Pour la ligne de commande , qu'est ce qui empêche de l'utiliser et de le configurer comme ca sous Windows ?

Ensuite il s'agit essentiellement d'outils open source, avant tout développés et testés pour de l'open source, avec de la documentation sur l'installation de paquets basée sur de la ligne de commande, une communauté largement développée offrant un support important... toujours sous Unix/Linux.

Ha donc les logiciels open sources marche mieux sur des système opensource. C'est intéressant.
Quant à la documentation , les logiciels étant multiplateforme les docs le sont également. Celle de PHP étant d'ailleurs particulièrement bien fait quand il y'a des petites différences entre Windows/linux

Bref, un serveur Apache|Nginx/PHP sous Windows ça marche, mais à quel prix et pourquoi faire ?

Au prix de la licence effectivement.
Pourquoi faire ? Je te donne mon exemple , quand tu as un ERP qui marche sous sql server et qui t'impose un serveur windows, que l'ensemble de l’écosystème de l'entreprise est windows ... bah t'as des serveur web sous windows. Qui au passage pourraient avoir des uptime de plusieurs année si il n'étais pas coupé une fois detemps en temps pour mettre à jour la stack.
Et pour le coup le prix de la licence est négligeable par rapport au temps de formation nécessaire si il fallait former les sysadmin pur windows à du linux.

C'est sans doute pas la meilleure solution dans tous les cas , mais de là à dire que ce n'est pas une bonne idée ...

[Sodium]

Le prix de la licence et le fait qu'il faille revoir légèrement à la hausse les ressources du serveur c'est en effet négligeable dans les grosses boîtes, mais ce n'est pas toujours le cas dans les agences où quelques centaines d'euros de licence peuvent faire une différence en fin de mois.

Pour la ligne de commande, je voulais surtout dire que pour une majorité de problèmes, tu vas trouver dans les communauté les commandes Linux pour le régler, il suffit donc d'un copier-coller en ayant évidemment la présence d'esprit de vérifier que ça ne fait pas n'importe quoi. Pareillement pour l'ensemble des paquets, modules qui vont main dans la main avec PHP et dont l'installation + activation se fait souvent avec un simple apt-get. Mais il est certain que je ne connais pas le gestionnaire de paquets de Microsoft pour comparer.

Je veux bien te croire que la doc Windows de PHP est bien faite, mais qu'en est-il de l'ensemble de l'écosystème courrament utilisé ? Une large proportion des mainteneurs de projet open-source sont sous Linux, certains font certainement un très bon travail de documentation multi-support, d'autres non.

Quand les impératifs de l'entreprise exigent des serveurs Windows, bien entendu qu'il s'agit du choix logique. Quand on est un débutant souhaitant se former à PHP par contre, ça serait une erreur de ne pas acquérir quelques bases en administration Linux, surtout depuis que WSL a transformé ça en jeu d'enfant.

[chrtophe]

Pareillement pour l'ensemble des paquets, modules qui vont main dans la main avec PHP et dont l'installation + activation se fait souvent avec un simple apt-get

Tu peux utiliser php pear

Bref, un serveur Apache|Nginx/PHP sous Windows ça marche, mais à quel prix et pourquoi faire ?

Pourquoi faire ? Pour s'intégrer avec des produits métiers sous Windows, qui utilisent notamment SQL Server par exemple (bien que ça soit aussi possible depuis Linux).

PHP/apache utilisés sous Windows n'ont pas plus d'avantage ni d'inconvénient en soi que l'équivalent Linux, mais quand on est dans un environnement complètement Windows, ça reste plus pertinent que de monter un serveur Linux. Et un sysadmin Windows qui ne maitrise souvent pas Linux aura tout intérêt à rester sur la plateforme qu'il maitrise.

[air-dex]

La première chose à laquelle j'ai pensé en lisant cela a été d'aller taper "Linux ASP" sur Google. Les deux premiers résultats sont des pages officielles de Microsoft Docs indiquant comment installer ASP.NET Core sur des serveurs Apache et Nginx sous Linux :

• Apache : https://docs.microsoft.com/fr-fr/asp...aspnetcore-3.1
• Nginx : https://docs.microsoft.com/fr-fr/asp...aspnetcore-3.1

Les deux articles datent d'il y a 3 mois seulement (10 Avril 2020).

Du coup je me pose la question suivante : et si c'était une manœuvre pour saquer PHP au profit d'ASP, qui rappelons-le est un concurrent de PHP développé par Microsoft ? On se retrouverait ainsi avec ASP.NET disponible sur tous les OS et tous les serveurs, contrairement à PHP pour qui il faudrait Linux (ou macOS ?). Cela deviendrait plus simple de faire du développement Web avec des serveurs LASSA (pour "Linux Apache SQL Server ASP") et leurs variantes WASSA et MASSA, plutôt qu'avec les traditionnels serveurs LAMP (ainsi que WAMP et MAMP).

Embrace (Linux), extend (ASP.NET Core to Apache/Nginx) and extinguish (PHP) ?

[grunk]

Mouais j'y crois pas un seul instant.
Déjà parce que l'utilisation d'ASP est annecdotique comparé à celle de PHP et que PHP sous windows ne va pas disparaitre, il ne sera juste plus maintenu par Microsoft.
Soit c'est PHP qui reprend les reines de windows.php.net soit ca va être confié à une entité tiers de confiance comme c'est le cas avec Apache et apache lounge.

[redcurve]

Le premier point c'est que ça veut dire s'encombrer d'une couche OS rajoutant une lourdeur et un prix de licence au serveur pour des technologies qui sont pensées pour être utilisées et configurées en ligne de commande.

Ensuite il s'agit essentiellement d'outils open source, avant tout développés et testés pour de l'open source, avec de la documentation sur l'installation de paquets basée sur de la ligne de commande, une communauté largement développée offrant un support important... toujours sous Unix/Linux. De même, les développeurs et administrateurs serveurs du monde PHP sont rarement bien rodés sur l'administration de serveur Windows.

Bref, un serveur Apache|Nginx/PHP sous Windows ça marche, mais à quel prix et pourquoi faire ?

Depuis quand Windows a besoin d'une interface graphique ? En prod on utilise du nano server, et tout est géré à coup de powershell pareil pour les machines linux tout avec powershell. Si vous voulez installer l'interface graphique c'est votre choix et elle consomme quedal en terme de resource de toute façon et Windows ne passe pas son temps à redessiner toute l'interface mais uniquement les pixels modifiés.

[RedGuff]

On va donc passer à GNU/Linux, pour ceux qui ne l'avaient pas encore fait !

[grunk]

Pour info les release windows de php 8 sont toujours disponible sans problème

[Fleur en plastique]

PHP sous Windows ça fonctionne, mais ça n'est jamais sans soucis

Je ne te le fais pas dire.

Je fais faire part d'une anecdote, qui est très ancienne (2003) donc certainement pas un reflet de ce qu'est Windows aujourd'hui, mais intéressante.

L'entreprise pour laquelle je travaillais avait des sites en PHP, hébergés sur un Windows Server 2003. Ils voulaient tout passer en ASP.NET. Bon déjà parce qu'un commercial leur avait vendu le fait qu'avec ASP.NET on avait exactement le même confort utilisateur dans un navigateur qu'une application de bureau (c'était un énorme mensonge, sachant qu'à l'époque ASP.NET était limité en JavaScript et les navigateurs n'avaient pas du tout la même puissance en JavaScript qu'aujourd'hui), mais aussi, et c'est là que c'est drôle, parce que leurs sites en PHP avaient tendance à planter. En fait, le serveur cessait de répondre, jusqu'à ce qu'un gars de la firme aillent se connecter physiquement sur la machine Windows... pour fermer une boîte de dialogue d'erreur, qui suspendait totalement IIS tant qu'elle était ouverte. Et ça c'était plusieurs fois par semaine.

J'ai trouvé ça honteux de la part de Microsoft de prétendre offrir un OS serveur et des logiciels pour OS serveur (IIS) et pourtant bloquer tout espèce de fonctionnement du logiciel serveur à cause d'une fenêtre modale affichée sur le serveur à refermer comme si on était sur un vulgaire PC de bureau. N'importe quel Linuxien aurait ricané devant une situation aussi grotesque.