"Il n'y a vraiment aucun intérêt à les maintenir aussi longtemps parce que les gens ne les utilisent pas".
Je suis d'accord. Je suis sûr que quelqu'un utilise encore la version 4.14 dans un système Linux de production, mais il ne doit pas y en avoir beaucoup.
Alors qu'on parle que pour diverses raisons, il faudrait que nos smartphones/matériels soient changés moins souvent et donc supportés plus longtemps…
Je sais pas si il exclu les smartphones de la "production" mais mon Android tourne avec le noyau 4.4… Et on doit bien être des millions dans ce cas là. On aimerait des mises à jours qui durent plus longtemps et c'est pas ce changement qui va aider/encourager les constructeurs.
Mon point de vue est qu'il faudrait quelques rares versions qui soient maintenues très longtemps même si elles seraient moins nombreuses. Et les constructeurs de smartphones et d'embarqués pourraient utiliser ces versions.
Point intéressant, doit-on considérer l'embarqué et le mobile sur des cycles de maintenance à part ? Puisque c'est du matériel "figé" dès sa production.
Je n'ai guère de doutes sur l'utilisation de pile logicielle à jour dans les datacenter et autres entreprises à taille conséquente, pour le reste…
D'ailleurs Torvalds avait évoqué il n'y a pas si longtemps que les mainteneurs vieillissaient et peinent à se renouveler.
Point intéressant, doit-on considérer l'embarqué et le mobile sur des cycles de maintenance à part ? Puisque c'est du matériel "figé" dès sa production.
Techniquement rien n'empêche de changer de version du noyau en cours de route, dans mes projets au boulot on le fait souvent. Mais cela implique évidemment que le constructeur des puces fassent le boulot sinon c'est irréaliste.
Du coup nous on suit les versions LTS de Yocto qui utilisent aussi des versions LTS du noyau, pour cet écosystème un tel changement sera préjudiciable.
Du coup je ne dirais pas que les LTS ne servent pas ou trop peu, déjà il faudrait des métriques pour le vérifier et je ne suis pas sûr que ce soit fondé. Mais il y a un vrai problème de bras et de financement de cette maintenance à long terme. Cette tâche pourrait être mutualisée et je pense que la Linux Fondation sera adaptée à cela, mais faudrait inciter des gens à fournir l'argent nécessaire.
D'ailleurs Torvalds avait évoqué il n'y a pas si longtemps que les mainteneurs vieillissaient et peinent à se renouveler.
C'est aussi un vrai problème. Ce qui est dommage c'est que le workflow du noyau reste très critiqué car assez complexe et provenant d'un héritage lointain où les outils modernes sur le sujet n'existaient pas. Il y a eu 20 000 débats pour passer à une forge ou autres outils plus modernes pour faciliter le travail des mainteneurs et des contributeurs externes pour permettre un tel renouvellement. Mais il y a en tout cas une forte résistance au changement et c'est dommage, cela ne suffirait peut être pas à résoudre ce problème, mais on ne peut pas espérer une amélioration de la situation par la magie, faut impulser des changements pour attirer ce genre de profils.
Il faudrait sans doute inciter les entreprises à valoriser cet aspect du travail, la bonne santé du développement du noyau (et d'autres composants libres par ailleurs) est essentielle à beaucoup d'activités mais peu d'entreprises mettent en valeur un tel job en interne.
Ma compréhension est que les "gros" qui maintiennent un parc (Google, RH, SuSE, Ubuntu, …) n'utilisent pas les noyaux Linux officiellement maintenus mais piochent un peu ce qu'ils ont envie d'un peu partout suivant leurs propres priorités, et que du coup le travail upstream n'est pas utilisé (et donc ne sera pas payé non plus par ceux ayant besoin de long terme).
D'ailleurs, tu noteras que ta version n'est pas dans la liste des versions maintenues, CQFD.
Perso je note que la version sur mon tel est maintenu, mais bientôt plus, c'est une 4.14 qui sera EOL dans 3 mois alors que mon tel est assez jeune et qu'il sera encore maintenu par son constructeur longtemps, donc le LTS upstream sert peut-être mais dans tous les cas mon constructeurs doit garder des ressources en interne donc…
moins souvent et donc supportés plus longtemps…
Mais combien de temps, la est la question… Le soucis est déjà que le temps que ça arrive sur nos smartphones la version date, donc faudrait 10 ans, mais si tu sors 10 ans tous les 5 ans, ça fait que 5 ans en pratique pour le produit.
Moins souvent = problèmes aussi.
Et au final, le problème ne vient pas de la version du noyau, mais du fait que les boites comme qualcom ne sont pas forcés à maintenir leurs drivers et autres bricoles proprios à long terme.
En théorie il n'y a rien qui techniquement empêche les vendeurs de puce de maintenir le support sur des versions changeantes de noyau.
C'est le genre de truc pour lesquels il faudrait que ce soit inscrit dans la loi parce que forcément, aucun constructeur n'y voit un intérêt économique.
Je pense aussi que pour forcer la main, mettre des contraintes légales est nécessaire. Cela peut passer par une durée de garantie plus longue de certains produits. Après il faudrait définir ce que couvre la garantie à ce sujet ce qui n'est pas tout à fait trivial.
Cependant il faut avoir conscience que maintenir proprement de tels projets sur la durée a un coût non négligeable, largement finançable certes, mais les produits avec une très faible marge comme les téléphones bas de gamme pourraient voir leurs prix augmenter voire disparaître faute de rentabilité. C'est une conséquence probable à ne pas sous estimer pour certains produits, après on pourra dire que c'est peut être une bonne nouvelle aussi de les virer du marché étant données leur qualité…
Cependant il faut avoir conscience que maintenir proprement de tels projets sur la durée a un coût non négligeable
ça incitera peut-être les constructeurs à ne pas sortir 36 variantes d'un même composant juste pour de la segmentation marketing, et ça ne serait pas plus mal.
mais les produits avec une très faible marge comme les téléphones bas de gamme pourraient voir leurs prix augmenter voire disparaître faute de rentabilité.
A ne pas sous-estimer en effet (on le voit déjà bien avec la réglementation sur les voitures qui font que les petites voitures ne sont plus trop mises en avant car pas assez rentable), mais perso je doute que ça sera totalement abandonné si c'est fait correctement (bon, ok, la je peux avoir un doute sur la formulation légale… cf réglementation voiture encore où les règles ont avantagé les grosses voitures faute d'avoir bien pensé la réglementation).
après on pourra dire que c'est peut être une bonne nouvelle aussi de les virer du marché étant données leur qualité…
Non, car la qualité n'est pas forcément utile, des gens veulent juste être joignable ou pouvoir joindre.
Et justement, ça va dépendre de la réglementation, il y a de la marge entre corriger les failles de sécu, failles de sécu + MAJ importantes genre le navigateur et TLS, et MAJ de l'OS.
Et justement, ça va dépendre de la réglementation, il y a de la marge entre corriger les failles de sécu, failles de sécu + MAJ importantes genre le navigateur et TLS, et MAJ de l'OS.
Je dirais que le point problématique est là en fait. Car tout est intriqué à partir d'un moment et c'est d'ailleurs le nœud du problème avec le noyau par ailleurs. Backporter un correctif d'une version X à la version X-2 n'est pas toujours possible (ou du moins trivial). Car pour que cela fonctionne il faut adapter le tout à l'ancien code qui peut être radicalement différent.
Les logiciels évoluent vite et sont liés entre eux. Et parfois ton correctif de sécurité c'est devoir changer de version d'une bibliothèque, qui a changé d'API, et pour en tirer bénéfice il faut mettre à jour d'autres bibliothèques, etc. Et ces mises à jour tirent avec eux de nouvelles fonctionnalités et potentiellement plus lourdes. Etc. Cela peut vite être sans fin.
Quiconque a travaillé de près ou de loin sur une distribution type Fedora, Debian ou même un truc plus personnel à base de Yocto ou buildroot peut facilement constater ce que cela représente à l'échelle d'un système complet.
Et par ailleurs il faut codifier proprement ce que l'on veut. Il y a faille de sécurité et faille de sécurité, lesquelles doivent être couvertes légalement et lesquelles peuvent être omises ? Combien de temps pour publier une MaJ ? Quelle responsabilité si l'entreprise n'a pas corrigé une faille parce qu'elle n'en avait pas conscience ? Etc.
Il y a moyen de répondre à ces questions évidemment, je ne dis pas que c'est totalement impossible, mais suivant le but poursuivi les moyens à mettre en place ne sont pas les mêmes. Et il y a probablement des objectifs qui restent irréalistes si on souhaite respecter toutes les contraintes.
Pourquoi ne pas faire payer les mises à jour majeures ?
J'ai dû changer de téléphone à cause de la version Android dessus, mais le fabriquant aurait proposé une MàJ payante je serais probablement resté avec ce téléphone.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Posté par Zenitram (site web personnel) .
Évalué à 3.
Dernière modification le 21 septembre 2023 à 14:51.
Pourquoi ne pas faire payer les mises à jour majeures ?
Parce que tu fais partie des 0.01% prêts à payer, tu n'es pas du tout rentable par rapport au coût.
Sérieux, tu penses vraiment que personne chez les constructeurs y auraient pensé avant toi? Le logiciel seul c'est loin d'être facile à vendre, et même dans les ROM alternatives ça ne fonctionne pas, car déjà le marché est très très petit (ça marche pas mal pendant longtemps, tant pis pour le risque de sécu, et au pire on change quand WhatsApp annonce virer le support d'Android 4.4 et qu'on l'a, c'est bon ça date, et ça fera un gain de perf au passage).
mais le fabriquant aurait proposé une MàJ payante je serais probablement resté avec ce téléphone.
Le ratio entre les gens qui disent qui payeront et les gens qui payent quand c'est dispo est du genre 100 pour 1. Côté développeurs on sait très bien ce que vaut les "si tu fais, je payerai, promis".
# Personne ne les utilisent
Posté par cosmocat . Évalué à 9.
Alors qu'on parle que pour diverses raisons, il faudrait que nos smartphones/matériels soient changés moins souvent et donc supportés plus longtemps…
Je sais pas si il exclu les smartphones de la "production" mais mon Android tourne avec le noyau 4.4… Et on doit bien être des millions dans ce cas là. On aimerait des mises à jours qui durent plus longtemps et c'est pas ce changement qui va aider/encourager les constructeurs.
Mon point de vue est qu'il faudrait quelques rares versions qui soient maintenues très longtemps même si elles seraient moins nombreuses. Et les constructeurs de smartphones et d'embarqués pourraient utiliser ces versions.
[^] # Re: Personne ne les utilisent
Posté par Xanatos . Évalué à 5.
Point intéressant, doit-on considérer l'embarqué et le mobile sur des cycles de maintenance à part ? Puisque c'est du matériel "figé" dès sa production.
Je n'ai guère de doutes sur l'utilisation de pile logicielle à jour dans les datacenter et autres entreprises à taille conséquente, pour le reste…
D'ailleurs Torvalds avait évoqué il n'y a pas si longtemps que les mainteneurs vieillissaient et peinent à se renouveler.
[^] # Re: Personne ne les utilisent
Posté par Renault (site web personnel) . Évalué à 8.
Techniquement rien n'empêche de changer de version du noyau en cours de route, dans mes projets au boulot on le fait souvent. Mais cela implique évidemment que le constructeur des puces fassent le boulot sinon c'est irréaliste.
Du coup nous on suit les versions LTS de Yocto qui utilisent aussi des versions LTS du noyau, pour cet écosystème un tel changement sera préjudiciable.
Du coup je ne dirais pas que les LTS ne servent pas ou trop peu, déjà il faudrait des métriques pour le vérifier et je ne suis pas sûr que ce soit fondé. Mais il y a un vrai problème de bras et de financement de cette maintenance à long terme. Cette tâche pourrait être mutualisée et je pense que la Linux Fondation sera adaptée à cela, mais faudrait inciter des gens à fournir l'argent nécessaire.
C'est aussi un vrai problème. Ce qui est dommage c'est que le workflow du noyau reste très critiqué car assez complexe et provenant d'un héritage lointain où les outils modernes sur le sujet n'existaient pas. Il y a eu 20 000 débats pour passer à une forge ou autres outils plus modernes pour faciliter le travail des mainteneurs et des contributeurs externes pour permettre un tel renouvellement. Mais il y a en tout cas une forte résistance au changement et c'est dommage, cela ne suffirait peut être pas à résoudre ce problème, mais on ne peut pas espérer une amélioration de la situation par la magie, faut impulser des changements pour attirer ce genre de profils.
Il faudrait sans doute inciter les entreprises à valoriser cet aspect du travail, la bonne santé du développement du noyau (et d'autres composants libres par ailleurs) est essentielle à beaucoup d'activités mais peu d'entreprises mettent en valeur un tel job en interne.
[^] # Re: Personne ne les utilisent
Posté par Zenitram (site web personnel) . Évalué à 8.
Ma compréhension est que les "gros" qui maintiennent un parc (Google, RH, SuSE, Ubuntu, …) n'utilisent pas les noyaux Linux officiellement maintenus mais piochent un peu ce qu'ils ont envie d'un peu partout suivant leurs propres priorités, et que du coup le travail upstream n'est pas utilisé (et donc ne sera pas payé non plus par ceux ayant besoin de long terme).
D'ailleurs, tu noteras que ta version n'est pas dans la liste des versions maintenues, CQFD.
Perso je note que la version sur mon tel est maintenu, mais bientôt plus, c'est une 4.14 qui sera EOL dans 3 mois alors que mon tel est assez jeune et qu'il sera encore maintenu par son constructeur longtemps, donc le LTS upstream sert peut-être mais dans tous les cas mon constructeurs doit garder des ressources en interne donc…
Mais combien de temps, la est la question… Le soucis est déjà que le temps que ça arrive sur nos smartphones la version date, donc faudrait 10 ans, mais si tu sors 10 ans tous les 5 ans, ça fait que 5 ans en pratique pour le produit.
Moins souvent = problèmes aussi.
[^] # Re: Personne ne les utilisent
Posté par Psychofox (Mastodon) . Évalué à 10.
Et au final, le problème ne vient pas de la version du noyau, mais du fait que les boites comme qualcom ne sont pas forcés à maintenir leurs drivers et autres bricoles proprios à long terme.
En théorie il n'y a rien qui techniquement empêche les vendeurs de puce de maintenir le support sur des versions changeantes de noyau.
[^] # Re: Personne ne les utilisent
Posté par dj_ (site web personnel) . Évalué à 7.
C'est ce que Qualcomm propose sur le processeur qui est utilisé dans le Fairphone 5 (QCM6490) mais c'est une série spéciale annoncé pour ce but.
Ils ne veulent pas faire ça pour chaque SoC
[^] # Re: Personne ne les utilisent
Posté par Psychofox (Mastodon) . Évalué à 9.
C'est le genre de truc pour lesquels il faudrait que ce soit inscrit dans la loi parce que forcément, aucun constructeur n'y voit un intérêt économique.
[^] # Re: Personne ne les utilisent
Posté par Renault (site web personnel) . Évalué à 4.
Je pense aussi que pour forcer la main, mettre des contraintes légales est nécessaire. Cela peut passer par une durée de garantie plus longue de certains produits. Après il faudrait définir ce que couvre la garantie à ce sujet ce qui n'est pas tout à fait trivial.
Cependant il faut avoir conscience que maintenir proprement de tels projets sur la durée a un coût non négligeable, largement finançable certes, mais les produits avec une très faible marge comme les téléphones bas de gamme pourraient voir leurs prix augmenter voire disparaître faute de rentabilité. C'est une conséquence probable à ne pas sous estimer pour certains produits, après on pourra dire que c'est peut être une bonne nouvelle aussi de les virer du marché étant données leur qualité…
[^] # Re: Personne ne les utilisent
Posté par Zenitram (site web personnel) . Évalué à 4.
ça incitera peut-être les constructeurs à ne pas sortir 36 variantes d'un même composant juste pour de la segmentation marketing, et ça ne serait pas plus mal.
A ne pas sous-estimer en effet (on le voit déjà bien avec la réglementation sur les voitures qui font que les petites voitures ne sont plus trop mises en avant car pas assez rentable), mais perso je doute que ça sera totalement abandonné si c'est fait correctement (bon, ok, la je peux avoir un doute sur la formulation légale… cf réglementation voiture encore où les règles ont avantagé les grosses voitures faute d'avoir bien pensé la réglementation).
Non, car la qualité n'est pas forcément utile, des gens veulent juste être joignable ou pouvoir joindre.
Et justement, ça va dépendre de la réglementation, il y a de la marge entre corriger les failles de sécu, failles de sécu + MAJ importantes genre le navigateur et TLS, et MAJ de l'OS.
[^] # Re: Personne ne les utilisent
Posté par Renault (site web personnel) . Évalué à 4.
Je dirais que le point problématique est là en fait. Car tout est intriqué à partir d'un moment et c'est d'ailleurs le nœud du problème avec le noyau par ailleurs. Backporter un correctif d'une version X à la version X-2 n'est pas toujours possible (ou du moins trivial). Car pour que cela fonctionne il faut adapter le tout à l'ancien code qui peut être radicalement différent.
Les logiciels évoluent vite et sont liés entre eux. Et parfois ton correctif de sécurité c'est devoir changer de version d'une bibliothèque, qui a changé d'API, et pour en tirer bénéfice il faut mettre à jour d'autres bibliothèques, etc. Et ces mises à jour tirent avec eux de nouvelles fonctionnalités et potentiellement plus lourdes. Etc. Cela peut vite être sans fin.
Quiconque a travaillé de près ou de loin sur une distribution type Fedora, Debian ou même un truc plus personnel à base de Yocto ou buildroot peut facilement constater ce que cela représente à l'échelle d'un système complet.
Et par ailleurs il faut codifier proprement ce que l'on veut. Il y a faille de sécurité et faille de sécurité, lesquelles doivent être couvertes légalement et lesquelles peuvent être omises ? Combien de temps pour publier une MaJ ? Quelle responsabilité si l'entreprise n'a pas corrigé une faille parce qu'elle n'en avait pas conscience ? Etc.
Il y a moyen de répondre à ces questions évidemment, je ne dis pas que c'est totalement impossible, mais suivant le but poursuivi les moyens à mettre en place ne sont pas les mêmes. Et il y a probablement des objectifs qui restent irréalistes si on souhaite respecter toutes les contraintes.
[^] # Re: Personne ne les utilisent
Posté par lolop (site web personnel) . Évalué à 3.
Pourquoi ne pas faire payer les mises à jour majeures ?
J'ai dû changer de téléphone à cause de la version Android dessus, mais le fabriquant aurait proposé une MàJ payante je serais probablement resté avec ce téléphone.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Personne ne les utilisent
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 21 septembre 2023 à 14:51.
Parce que tu fais partie des 0.01% prêts à payer, tu n'es pas du tout rentable par rapport au coût.
Sérieux, tu penses vraiment que personne chez les constructeurs y auraient pensé avant toi? Le logiciel seul c'est loin d'être facile à vendre, et même dans les ROM alternatives ça ne fonctionne pas, car déjà le marché est très très petit (ça marche pas mal pendant longtemps, tant pis pour le risque de sécu, et au pire on change quand WhatsApp annonce virer le support d'Android 4.4 et qu'on l'a, c'est bon ça date, et ça fera un gain de perf au passage).
Le ratio entre les gens qui disent qui payeront et les gens qui payent quand c'est dispo est du genre 100 pour 1. Côté développeurs on sait très bien ce que vaut les "si tu fais, je payerai, promis".
# Pendant ce temps, le noyau 3.10
Posté par cg . Évalué à 4.
Dans RHEL 7, le kernel 3.10 (entre autres vieilleries) est maintenu jusqu'en 2026 :).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.