Des smartphones plus durables? - Page 2

Non, je suis pas sur qeu tu te rende compte du boulot que c'est le portage d'une version. C'est pas de l'obsolecence programmé, juste un "manque de moyens"

C'est pas juste un make/make isntall hein.. C'est des mois de boulots, et meme si tu as deja une version anterieur fonctionnelle.

C'est un véritable probleme mais pas de l'obsolescense programée.

Manque de moyens, manque de moyens...

On parle de Apple, Samsung, Microsoft, Lenovo, Sony, là.

Faut pas pousser.

je pense que
soit tu sous estime la charge de boulot (on parle pas de faire clignoter une LED hein)
soit tu surestime la taille des equipes

Bha pour Apple, vu qu'ils font 60% de marge (ils ne savent plus quoi faire de leur centaines de milliards dormants dans des paradis fiscaux) et qu'ils ont un nombre de modèle relativement limité, ça semble très loin d'être impossible par manque de "moyens".

Une mise à jours de sécurité, c'est patcher quelques libs, pas forcément faire un upgrade complet du système.

Après aussi si l'architecture est trop complexe, c'est qu'il y a un problème à la base.

Et si fidéliser leurs clients n'est pas dans leur priorité, qu'ils arrêtent de faire leur ouin-ouin.

L'obsolescence est programmée en BCPL ou en COBOL.

Tron (./5713) :
Une mise à jours de sécurité, c'est patcher quelques libs, pas forcément faire un upgrade complet du système.

Ça dépend du problème. Et quand tu t'engages à faire des mises à jour de sécurité, tu ne choisis pas ceux que tu résous…

Et si fidéliser leurs clients n'est pas dans leur priorité, qu'ils arrêtent de faire leur ouin-ouin.

Je n'ai pas l'impression qu'Apple ait des problèmes de fidélisation de clientèle

zikzak (./5707) :
Je n'ai pas envie de citer à nouveau, mais qu'est-ce que tu ne saisi pas dans l'obsolescence des smartphones qui restent sur une version ancienne de l'OS avec toutes les failles que ça peut comporter ?

Oui, je l'ai déjà lu, mais le répéter ne va pas le rendre plus vrai pour autant. Combien de personnes changent de téléphone parce qu'il n'est plus supporté par leur constructeur ?

Par exemple, l'iPhone 4S vient de cesser de recevoir les mises à jour majeures (de mémoire, il aura encore droit aux màj de sécurité pendant au moins un an). Il ne représente que 1 à 2% des iPhones (selon les sites). Autrement dit, la grande partie des iPhone 4S ont été remplacés bien avant de ne plus avoir les mises à jour… J'imagine que c'est semblable pour les autres constructeurs.

C'est volontaire, c'est une obsolescence programmée.

Non, le but n'est pas de rendre obsolète les machines, mais de se simplifier la vie et celles des développeurs (parce que maintenir un même système avec des machines disparates est pénible, autant pour les développeurs que pour Apple).

Pour les développeurs tiers, le plus simple serait qu'ils mettent à jour toutes les machines (même vieilles) à la version la plus récente de l'OS, comme ça, il y aurait une seule version à gérer.

Non, bien au contraire : ça signifie avoir beaucoup plus de cas à tester (taille et format d'écran, résolution — retina ou non —, retour haptique sur l'écran, présence du lecteur d'empreinte, sans compter les différences de perfs)

Les résolutions très variées sont pourtant la norme sur PC et on s'en sort très bien. Il faut arrêter de penser en pixels. Faire une interface au pixel près a un sens avec un écran 160×100, mais les smartphones ont bien plus que ça.

pas tous, justement...

tu connais le principe de "responsive design" ? c'est arrivé à cause du coté disparate entre les différents device, c'est très lourd à supporter comme il faut... et puis ensuite les configurations matérielles ne sont pas les même, essayes de faire tourner sur un téléphone milieu de gamme d'il y a 5 ans une appli récente... ou même lire un film en 4K... ça marchera pas... à un moment, ce n'est plus "sage" d'investir pour des mises à jour sur des devices pour lesquels l'appli ne sera pas utilisable...

Godzil (./5709) :
Non, je suis pas sur qeu tu te rende compte du boulot que c'est le portage d'une version. C'est pas de l'obsolecence programmé, juste un "manque de moyens"

Bof... pour le coup, c'est surtout la faute des fabricants de téléphones qui personnalisent Android et ne permettent ainsi pas de pouvoir déployer les mises à jour... C'est aussi la faute de Google qui ne permet pas un mode de distribution d'Android favorable aux mises à jour...
On a quand-même des appareils ultra puissants, avec plusieurs Go de stockage, avec des périphériques internes normalisés ou pour lesquels des drivers existent... il n'y a, aujourd'hui, absolument aucune raison de ne pas être en mesure de pouvoir faire des mises à jour, au moins de sécurité (le nombre d'OpenSSL pourri sur des smartphones encore en fonctionnement est proprement hallucinant). Et qu'on ne vienne pas me dire "oh mais le matériel des smartphones est tellement spécifique pour chaque constructeur" : il y a, en bundle avec Android (et qui n'est même pas nettoyé par les redistributeurs), une térachiée de trucs qui ne sont jamais utilisées (ou utilisables), comme des drivers pour du matériel non présent dans les appareils... ajouter quelques drivers génériques, ou avoir un catalogue en ligne le cas échéant comme ce qui se fait pour les OS de bureau serait une solution...
Microsoft, quant à lui, a peut-être la solution à ce niveau, sauf qu'ils ont changé tellement souvent leur modèle technologique ces dernières années que les ruptures ont cassé les compatibilités matériel/OS.

Apple, si je ne m'abuse, permet à ses téléphones d'avoir les mises à jour d'iOS (mais bien des gens pensent qu'elles ralentissent volontairement les terminaux un peu anciens ; ce qui est certain c'est qu'il arrive un moment où la mise à jour prend trop de mémoire et rend le téléphone inutilisable, vu que les iPhone ne sont pas extensibles).

Nil (./5720) :
Apple, si je ne m'abuse, permet à ses téléphones d'avoir les mises à jour d'iOS (mais bien des gens pensent qu'elles ralentissent volontairement les terminaux un peu anciens ; ce qui est certain c'est qu'il arrive un moment où la mise à jour prend trop de mémoire et rend le téléphone inutilisable, vu que les iPhone ne sont pas extensibles).

Oui et non. Je me souviens justement de ce problème où des utilisateurs d'iPhone 3/3S avaient voulu forcer la MAJ de iOS alors qu'elle n'était pas disponible pour leur appareil, si j'ai bonne mémoire. Le résultat fut que leur appareil était bien plus lent à l'utilisation, car matériellement insuffisant à faire tourner les nouveautés de iOS.

Cyanogen Mod en est un autre exemple sur Android. Cela m'a permis de faire passer mon vieux HTC Desire (premier du nom) vers Android 2.2, une version majeure qui m'a débloqué bien des applications dont c'était la condition minimale, alors qu'il était bloqué en 2.1 depuis longtemps. Mais "pas plus loin", les versions supérieures étant trop gourmandes pour cet appareil.
J'ai ensuite refait pareil avec mon Note 2, qui date quand même de 2012, et me tient toujours autant la route (quelques jeux 3D tirés d'Unity subissent parfois des ralentissements, mais en dehors de cela il pète la forme).

Nil (./5720) :
C'est aussi la faute de Google qui ne permet pas un mode de distribution d'Android favorable aux mises à jour...

Il y a un gros soucis sur Android sur le fait que toute MAJ passe par une MAJ du système lui-même, et non pas la récupération de patchs.

Heu, Nil, je pense que tu ne comprends pas trop comment est fait un OS comem android.

Ce n'est pas Google qui compile le tout et les fabricant qui copient juste des binaires..
Ca peux marcher pour des app, pas pour l'OS.

L'OS est compile par le fabricant, patche aussi par le fabricant, les drivers sont fait/mis a jour pour chaque version d'android, le kernel ausis set mis a jour, le tout a la base pour supporter le materiel avant les "surcouche" fabricant & co

Ce n'est pas trivial du tout.

La magie des OS monolithiques. Un petit micro-kernel et hop, tu ne mets à jours que la partie concernée

Bah oui, (micro)kernel vs (no)stub

Godzil (./5722) :
Heu, Nil, je pense que tu ne comprends pas trop comment est fait un OS comem android.

Ce n'est pas Google qui compile le tout et les fabricant qui copient juste des binaires..
Ca peux marcher pour des app, pas pour l'OS.

L'OS est compile par le fabricant, patche aussi par le fabricant, les drivers sont fait/mis a jour pour chaque version d'android, le kernel ausis set mis a jour, le tout a la base pour supporter le materiel avant les "surcouche" fabricant & co
Ce n'est pas trivial du tout.

Je sais bien que ce n'est pas comme ça (et, d'ailleurs, ce n'est pas vraiment ce que j'ai dit). Ce que je regrette, c'est
- Que Google ne propose pas une base d'OS avec des modalités de mises à jour de sécurité
- Que Google propose tout de même des mises à jour (mais "en bloc") et que les modifications réalisées par les fabricants de téléphones ne permettent pas une réinjection simple des modifications, parce qu'il n'y a absolument aucune raison (mais vraiment aucune) de ne pas avoir les modifications réalisées par les fabricants sous formes de drivers+applis (donc avec rien ou quasi rien à changer au niveau de l'OS).
- Que ce qui est possible pour d'autres OS (et sur du matériel de même type, avec une variété incroyable de périphériques supportés) ne le soit pas pour les smartphones. Autant je le comprends il y a 10 ans, où on était vraiment dans de l'embarqué pur, autant vu les couches d'abstraction et la base de l'OS derrière Android, on reste dans un fonctionnement aussi handicapant.

Meowcate (./5721) :

Nil (./5720) :
C'est aussi la faute de Google qui ne permet pas un mode de distribution d'Android favorable aux mises à jour...

Il y a un gros soucis sur Android sur le fait que toute MAJ passe par une MAJ du système lui-même, et non pas la récupération de patchs.

Oui. S'ils faisaient des paquetages comme les distributions GNU/Linux, les mises à jour seraient beaucoup plus faciles. Voire des paquetages en rolling release (style Arch Linux), où tout le monde qui met à jour se retrouve automatiquement avec la version la plus récente (mais ça a d'autres inconvénients, ça rend notamment quasiment impossible d'opter contre des mises à jour "cassantes"). Mais même si on garde les releases, les paquetages rendraient les mises à jour plus simples et plus efficaces (autant à l'intérieur d'une release que d'une release à la prochaine).

Godzil (./5722) :
L'OS est compile par le fabricant, patche aussi par le fabricant, les drivers sont fait/mis a jour pour chaque version d'android, le kernel ausis set mis a jour, le tout a la base pour supporter le materiel avant les "surcouche" fabricant & co

C'est bien ça qu'on critique! Le fabricant devrait rajouter au maximum les pilotes (idéalement, ils seraient aussi disponibles sous forme de paquetages (cf. le paragraphe précédent) officiels), la distribution des mises à jour devrait être centralisée. C'est le système d'image monolithique qui casse tout, il oblige chaque fabricant à recompiler toute l'image à chaque fois.

Le noyau à recompiler (voire souvent patcher) pour chaque modèle d'appareil, c'est aussi une absurdité qui complique la vie à tout le monde pour rien. Il existe maintenant (enfin!) une solution (device tree), il est temps qu'elle soit enfin adoptée par Android!

Le but devrait être qu'on puisse récupérer une image directement chez Google ou Cyanogen et l'installer sur n'importe quel matériel (la même image), et ensuite la mettre à jour comme une distribution GNU/Linux.

Tron (./5723) :
La magie des OS monolithiques. Un petit micro-kernel et hop, tu ne mets à jours que la partie concernée

On n'a pas besoin d'un vrai microkernel pour ça, un noyau monolithique modulaire comme Linux fait ça très bien. (Il est possible de mettre à jour le noyau sans casser les modules, RHEL le fait par exemple.) De plus, le noyau peut de toute façon généralement être traîté comme un seul morceau, c'est au niveau userspace que les paquetages sont le plus utiles.

DeviceTree..

Une feature faite par des gens qui n'ont aucune idee de ce que informatique embarque veux dire.

(Oh et les devicetree ne marche que pour les drivers, pas le support CPU.. et ce meme dans la meme famille, un kernel pour un S3C2440 ne peux pas etre utilise pour un OMAP3621 ou un BCM2709 ou un iMX31 ou un A13, ...)

Une feature faite par des gens qui en ont marre des limitations stupides de la plateforme ARM sous prétexte que c'est "embarqué" et qui ne voient pas pourquoi on ne peut pas faire ce qui se fait sur PC depuis très longtemps (depuis une époque où les PCs étaient moins puissants que les smartphones actuels!). On a exactement le même problème (matériel très varié, un bordel de noyaux différents par matériel), la solution est la même (on distribue les pilotes sous forme de modules et on fait en sorte que le noyau charge les bons modules automatiquement).

Godzil (./5729) :
(Oh et les devicetree ne marche que pour les drivers, pas le support CPU.. et ce meme dans la meme famille, un kernel pour un S3C2440 ne peux pas etre utilise pour un OMAP3621 ou un BCM2709 ou un iMX31 ou un A13, ...)

Le noyau peut être compilé pour ARMv7 générique. Fedora ARM ne propose que 2 noyaux AArch32, un pour ARMv7 sans LPAE et un pour ARMv7 avec LPAE. Et même le noyau LPAE ne serait pas strictement nécessaire, et n'est de toute façon pas utile pour les smartphones, ça ne sert que si on veut faire tourner du 32-bits sur un processeur AArch64.

et avec des libs dynamiques?

Le matériel PC est une plateforme ouverte, standardisée, et faite pour que le matériel soit détecté au run-time. Sur les smartphones, les fabricants sont beaucoup plus libres de faire ce qu'ils veulent avec le matériel, et ils ne fournissent bien entendu pas de docs.

Android pourrait certainement faire mieux pour ce qui est des mises à jour, mais il faudrait :

- que Linux ait une ABI noyau stable (non, les fabricants ne vont pas mettre leurs drivers en open-source - ce serait un trop beau cadeau pour leur concurrent - et ils ont autre chose à faire que de patcher les drivers tous les 4 matins parce que l'ABI noyau a encore changé)

- que les opérateurs arrêtent de faire pression pour rajouter leurs surcouches pourries et virer des features pour les vendre en options payantes : ils sont aussi responsables de l'absence de mises à jour sur certains modèles.

Zerosquare (./56) :
non, les fabricants ne vont pas mettre leurs drivers en open-source - ce serait un trop beau cadeau pour leur concurrent

Les pilotes libres marchent très bien sur PC, je ne vois pas pourquoi ce modèle ne devrait pas marcher pour les smartphones. Parfois, ce sont les constructeurs du matériel qui fournissent les pilotes libres, parfois, c'est la communauté, on s'en fout au final, tant qu'il y a un pilote libre en sortie. La situation actuelle des pilotes est le principal problème des plateformes mobiles. C'est aussi un bâton dans les roues de projets comme Ubuntu Phone ou Plasma Phone, qui se voient obligés à rajouter des couches de compatibilite pour utiliser les blobs pour Android (qui sont compilés avec la libc d'Android (Bionic), ne gèrent que les APIs graphiques Android, etc.).

Je ne vois pas de solution à base de pilotes propriétaires.

et ils ont autre chose à faire que de patcher les drivers tous les 4 matins parce que l'ABI noyau a encore changé

Ça cesse d'être leur problème le moment où leur pilote est intégré au pilote officiel, c'est bien ça le principal avantage compétitif de mettre leur pilote sous une licence GPLv2 ou compatible (et aussi de suivre les conventions de développement du noyau, sans couches d'abstraction ou réimplémentations de fonctionnalités du noyau qui ne seront jamais acceptés upstream).

que les opérateurs arrêtent de faire pression pour rajouter leurs surcouches pourries et virer des features pour les vendre en options payantes : ils sont aussi responsables de l'absence de mises à jour sur certains modèles.

S'il y a enfin une image standard directement de Google ou Cyanogen qui marche partout, ni les fabricants, ni les opérateurs ne pourront rajouter leur sauce.

Kevin tu ne connais rien au hardware c'est virtuellemetn impossible de faire un truc universel sans avoir des normes restrictive comme le son le PCI/PCIe/USB & co.

Tu n'a aucun moyen d'enumerer les peripheriques sur un bus SPI, ou I2C dans une parties des cas, ou de savoir ce qui est branche sur tel et tel GPIO.

Et puis c'est sur que la "communaute" connais bien mieux le hardware que ceux qui l'on concus (bon ok ca peux arriver, mais ce cas est extreme)

Et comme dit plus haut de toute maniere, un kernel configure pour un chip AllWinner A13 et ce meme avec les DT ne pourra pas fonctionner sur une carte avec un iMX51, ou un s3c2440

Et tout compiler en ARM7 n'aurais aucun sens (pour supporter le maximum de CPU ARM), c'est comme ne compiler qu'en mode 8086 sur un Core i7.

Godzil (./58) :
Tu n'a aucun moyen d'enumerer les peripheriques sur un bus SPI, ou I2C dans une parties des cas, ou de savoir ce qui est branche sur tel et tel GPIO.

C'est ça le but du device tree. Il suffit de stocker un bootloader et le device tree dans une ROM, le bootloader lance le noyau (de l'image OS universelle), le noyau lit le device tree, et tout se lance.

Et comme dit plus haut de toute maniere, un kernel configure pour un chip AllWinner A13 et ce meme avec les DT ne pourra pas fonctionner sur une carte avec un iMX51, ou un s3c2440

Le noyau doit être configuré pour ARMv7 générique.

Et tout compiler en ARM7 n'aurais aucun sens (pour supporter le maximum de CPU ARM), c'est comme ne compiler qu'en mode 8086 sur un Core i7.

Tu ne peux pas comparer ARMv7 au 8086, c'est plus comme i686, pour lesquels les distributions x86 actuelles sont compilées. (L'équivalent de i586 serait ARMv5 (ARMv5TE), l'équivalent de i386 serait ARMv1. L'équivalent du 8086 n'existe même pas en ARM, ce serait du 16 bits.)

ARMv7 minimum doit exclure en gros 50% des produits utilisant un composant ARM. (si ce n'est plus)

Et si tu ne comprends pas l'analogie ARM7/8086 (et pas ARMv7) desole je ne peux rien pour toi.

Parler des coeur ARM par l'architecture de base n'a aucun interet. Un ARM7RDMI et un ARM9TDMI qui pourtant on le meme "coeur" ARMv4T ne sont pas vraiment identique.

En fait ce qui est appele "architecture" par Wikipedia (ARMvX) est grosso modo le jeu d'instruction de base. Si tu veux parler d'un chip ARM il faut parler des "core designeds by ARM Holdings" (enfin Softbank maintenant ) parce que ca change BEAUCOUP de choses. Mais comme tu semble confondre ARMv7 avec ARM7 c'est que tu n'es a priori pas trop au courant de ce qui se passe dans ce monde la.