Merci, crcr.
Ca ressemble quand même beaucoup à de l'obsolescence programmée voulue.

Leon.

comme la transition de x86 à x86_64, avec dès 2015 des gros logiciels (suite adobe par ex), qui ne prennent plus qu'en charge le 64, regardant de haut ceux restés sur le bas coté de la route en 32.
le noyau linux ne prends plus en charge les premiers cpu intel :
https://arstechnica.com/gadgets/2025/05/linux-to-end-support-for-1989s-hottest-chip-the-486-with-next-release/

mais oui ca donne clairement ce résultat là. On l'avait déjà vu avec les applis :
https://www.rtl.be/actu/belgique/lapplication-bancaire-de-michel-ne-fonctionne-plus-sur-son-telephone-de-2018-je/2023-04-24/article/533828
https://www.frandroid.com/marques/apple/904391_peut-on-garde-un-iphone-4s-pendant-10-ans%E2%80%89-le-materiel-fonctionne-mais-cest-complique

l'autre notion à bien cerner :
en informatique, les ordinateurs, à l'exception de marques particulières anciennes (amiga, atari, mac-ppc), se sont tous unifiées, par IBM, sur un standard : l'ibm pc. C'est ce standard qui s'est imposé sur les pc, et qui "commande" au bios (ou à l'efi), de gérer par ce biais, les différents composants matériels. En clair, n'importe quel os "compatible pc", compatible avec la génération de processeur (32, 64..), pourra fonctionner sur l'appareil. D'où la cohorte d'OS tiers, l'armée de linux, les mac "compatibles pc" (mac intel), les windows, les unix tiers (haiku, redox, et plein d'autres petits systèmes à la kolibri), pour utiliser un logiciel différent en partant d'une même base unifiée : le standard ibm/pc.

Le gros avantage : tout le monde par d'une base commune. Elle évolue (le CPU) avec le temps, les logiciels s'adaptent. Et la plupart des matériels sont compatibles, par génération, à part p-e le CPU, parfois "bloqué" sur intel ou amd..
Le gros inconvénient : ça consomme.

Maintenant, regardons de plus près le principe du mobile : il fonctionne sur de l'arm. L'ARM? des schémas de composants, d'organisation électroniques, qui sont loin d'être simples à comprendre.
Deux éléments fondamentaux :
-l'arm est un miroir inversé du monde PC. En ARM, un circuit/CM électronique est "unique", et le logiciel **DOIT** savoir à quel endroit, se trouve quel type de composant. Sinon, ça ne fonctionnera pas. C'est pour ça qu'il est très compliqué de proposer des ROM sur smartphone (ou autres appareils), parce que cela demande un lourd trvaail d'adaptation du logiciel, linux ou pas linux. Pareil dans la crèmerie d'en face chez apple : adapter Darwin/xnu/macos, à un tout petit appareil, pour donner l'iphone : des heures de R/D pour adapter le logiciel, à cet appareil là exclusivement.
-la société ARM ne fabrique rien : elle imagine, concoit, des schémas, qui devront ensuite être fabriqués sous licence par des "fondeurs", qui fabriquent des composants à destination des fabriquants de téléphone.

le plus gros incovénient de l'arm : c'est du sur mesure à tous les étages, point. Pas d'équipe pour adapter le logiciel "bas niveau" (=OS, pilotes..), pas de système.
le plus gros avantage de l'arm : ça consomme très très peu. grosses avancées en miniaturisation. Parfait pour la mobilité.

En gros, comme dans le monde PC, il peut y avoir des dizaines d'interfvenants pour fabriquer le matériel, **mais** il n'y a pas la base logicielle commune. Celle ci est à définir par les protagonistes, de manière à savoir "quel logiciel va devoir tourner dessus". Souvent, le fabricant d'un capteur optique proposera un pilote logiciel pour telle version d'android, et débrouille toi avec. Une version plus récente? Faudra passer à la caisse, on bosse pas gratos. Et comme le pilote est dédié à une version du noyau spécifiquement (c'est ultra complexe). Donc chaque maillon doit faire avec ce qu'il a a dispo, sinon négocier pour espérer un changement.

Le monde ARM, c'est un peu comme des mafieux qui essaient de se mettre d'accord sur les points de revente : y'en aura pas pour tout le monde, y'aura un peu de violence, et les acteurs d'aujourd'hui ne pourront pas être ceux de demain.

Suffit de voir le simple cas de qcomm, apple est parti en procès contre (ça a fini à l'amiable), pour le plus grand plaisir des concurrents. Et y'a énormément de verrouillage concurrentiel à tous les étages. À ça, rajouté le problématiques techniques des pilotes, des fabricants qui appliquent mille patchs en croisant les doigts...

le monde android est un enfer, apple l'a bien compris : la recette? controler de bout en bout, le plus possible, l'ensemble de la chaine.

Les fabricants android secondaires, qui pèsent peu, iront forcément dans le mur (htc a rendu l'ame, LG on en parle plus, etc..)

Autre hypothèse : en attendant de pouvoir bien séparer les deux types d'itinérance, les opérateurs ont complétement désactivé la présentation du numéro, le temps de développer les fonctions SI qui vont bien.

Salut

Vous avez quelle Signal optique sur votre box ?


Je comprend pas j'ai pas du tous le meme signal ici au Photometre

L'IA indique que meta priority modifie la priorité du connecteur réseau (socket) (SO_PRIORITY) :

meta priority → skb->priority
                     → egress-qos-map
                     → PCP dans vlan_tci
                     → insertion 802.1Q

et que egress-qos-map fait correspondre cette priorité interne à la valeur du champ PCP.

Pour une interface VLAN logicielle (pas DSA), sans accélération matérielle (hardware offload) ou déchargement de flux (flow offloading) :

uci -q batch <<-EOF
add firewall include
set firewall.@include[-1].enabled='1'
set firewall.@include[-1].type='nftables'
set firewall.@include[-1].path='/etc/custom-netdev-table.nft'
set firewall.@include[-1].position='ruleset-post'
EOF

wan_iface=$(jsonfilter -i /etc/board.json -e '$.network.wan.ports[0]')

cat >/etc/custom-netdev-table.nft <<EOF
table netdev filter
flush table netdev filter

table netdev filter {
        chain set_isp_vlan_832 {
                udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for DHCPv6 packets"
                udp dport 67 vlan pcp set 6 ip dscp set cs6 counter comment "Set QoS for DHCPv4 packets"
                icmpv6 type { 133, 135, 136 } vlan pcp set 6 ip6 dscp set cs6 counter comment "Set QoS for ICMPv6 packets"
        }
        chain set_isp_vlan_840 {
                ip protocol igmp vlan pcp set 5 ip dscp set cs4 counter comment "Set QoS for IGMP packets"
        }
        chain lan_iptv {
                ip protocol igmp ip dscp set cs4 counter comment "Set DSCP for IGMP packets"
        }
        chain egress {
                type filter hook egress device $wan_iface priority filter; policy accept;
                vlan type arp vlan pcp set 6 counter comment "Set QoS for ARP packets"
                vlan id 832 jump set_isp_vlan_832
                vlan id 840 jump set_isp_vlan_840
                jump lan_iptv
        }
}
EOF

J'ai écrit cette configuration il y a plusieurs mois (cela commence à dater).

Les compteurs ne semblent pas fonctionner mais c'est une autre histoire.

Je n'ai pas testé sur la version 25.12. J'utilisais la version nocturne. Il faut au minimum la version 25.12 (nftables >= v1.1.3).

Bonjour,

Depuis hier soir, j'ai un souci avec ma connexion B&You Pure Fibre 8Gbps.

Phénomène hier soir, entre 20h et 1h : le ping vers les dns google, vers bouygues, et autres est supérieur à 30ms (alors qu'il est de 2-3ms en temps normal). Depuis mon PC en 10Gbps, j'avais un débit exécrable (moins de 100Mbps en dl).
Le test de débit depuis la box donnait le message suivant : votre débit descendant semble temporairement limité.
Beaucoup de pertes de paquets à signaler aussi.

A 6h du matin aujourd'hui, la connexion était redevenue normale : ping de 2-3ms, débit descendant entre 6 et 7 Gbps selon la destination.

Sauf que j'ai vu le phénomène se reproduire à 17h30 aujourd'hui : j'avais un ping en boucle vers les dns google, et il est passé de 3ms à 30ms. Le débit est passé à moins de 500Mbps en dl.
Pour le moment pas de perte de paquets significative, mais la soirée ne fait que commencer

Est-ce qu'il y a un incident ou des travaux dans le secteur Suresnes / Puteaux ?