Le 03/01/2023 à 15h 01

Je dis juste que j’ai une autre IPv6 dans le meme /64.

Le 03/01/2023 à 11h 10

le NAT64 ne modifie pas le port de destination, comme du NAT ou du cgNAT.
La reservation d’une plage de ports par client pour du cgNAT n’est qu’une option, pas une obligation.
Le cgNAT n’est qu’un ensemble de specs https://www.rfc-editor.org/rfc/rfc6888 , mais ne modifie pas les concepts ou le fonctionnement : le NAT64 peut être du cgNAT64 dans un réseau ; il n’y pas de contre indication.

Vu que c’est un autre /64 (et j’avais plusieurs IPv6), je suppose que c’est carrément en mode pont. Il n’y pas de raisons que ca fonctionne “mieux” avec un iPhone, c’est lié aux réglages opérateurs.

Faudrait faire un tcpdump pour avoir la reponse à ta question.

Le 02/01/2023 à 22h 44

brupala a dit:

Tu ne me feras pas avaler à moi que cgNAT fonctionne avec ipv6. le seul point commun qu’ils ont c’est le manque d’adresses ipv4. Après, qu’il y ait encapsulation des V4 natées dans de l’ipv6, c’est possible, mais pas indispensable.

Je n’avais pas répondu à cette partie de ton commentaire.

Voilà 3 exemples de produits qui permettent l’utilisation du NAT64. Donc si, je vais essayer de te faire avaler que du cgNAT64, c’est possible :-)

Et y’en a d’autres qui sont déployés dans les infras.

https://www.ericsson.com/en/portfolio/cloud-software–services/cloud-infrastructure/nfvi/ericsson-partner-vnf–cnf-certification/nfvi-r6.3-certified-vendors/a10/a10—vthunder-cgn-5.2-

https://doc.6wind.com/turbo-router-³⁄₃.1/turbo-router/user-guide/command-reference/cgnat.html

https://download.riverbed.com/var/imageshare/software-docs/sc_ex_21.1_Whats_New_in_Release_21.1.pdf?did=o1i95tb6muolt101e1qv28i7pu&Expires=1673303887&Signature=HuQ7LFNcuxB4SRyo30EUTyET4Ln5wWqrvIwnmCj7KVibRnIXtbFjd9DO9p5dahUb4SqVFudjITCvZ26Q1X-XrHkUebCvdq77HXMSnhNaexpMvibUcZ4Qx5O0Hf0Q6~JFwzhJZ9PRWoRhMQ5pgf5~k0hut47whfzprCghhjSCg0U_&Key-Pair-Id=APKAIWRBI4NBMRCJQ7RA

Le 02/01/2023 à 22h 24

Oui, partage de connexion à partir d’un iPhone vers un laptop, en USB ou en Wifi, on a bien sûr une IPv6 différente de celle du téléphone (meme préfixe), rien de scabreux au niveau implémentation.

Le 02/01/2023 à 14h 35

Dans un contexte urbain ou c’est super dense, c’est au contraire très utile d’avoir plusieurs micro cellules: chacune servira moins de terminaux, mais pour un niveau de service global supérieur.
Vu la puissance consommée par chaque antenne, pas besoin de travaux spécifiques pour amener des lignes électriques dédiées, si t’en as 1 qui est en panne / crame / est en maintenance, t’as les autres autour pour assurer le service.

Le 02/01/2023 à 14h 27

ben si, t’as une IPv6: fais le test chez Orange: partage de connexion, hop, t’as une IPv6 publique.
2a01:cb1a:4017:7d9f::/64

Le 31/12/2022 à 15h 36

brupala a dit:

Heureusement que le support ipv6 est prévu, ce serait la cata s’il ne l’était pas, irresponsable de développer depuis 2010 un réseau qui ne supporterait pas.

Et pourtant, une raison du déploiement de l’IPv6 dans les coeurs de reseaux “4G” etait la preparation du support des réseaux 5G : c’est bien pour ca que l’IPv6 / CGNAT et 5G sont liés. (pour répondre à ton commentaire precedent).

Tu crois qu’il y a des antennes 26 Ghz installées aujourd’hui ? Sauf les quelques tests, bien sûr, à ma connaissance pas de terminaux qui le font et je pense que ça sera surtout utilisé pour des liaisons fixes point à point, pas pour la communication mobile, le moindre mur et la moindre branche d’arbre détruirait tout, resterait les stations de métro et les stades.

En Europe, aucune (à part pour les experimentations), mais de nombreuses antennes 26 GHz (aux USA) et 28GHz (Japon) sont déployées et en production. (On est au dela de l’antenne de test autour du siege de l’opérateur).
Il suffit de regarder les modèles de smartphones vendus depuis 2 ans: avec (US / Japon) et sans (Europe) antennes millimétriques.

Par exemple, la carte de couverture de Verizon:
https://www.verizon.com/coverage-map/

Ou encore celle d’AT&T: (“5G+”)
https://www.att.com/maps/wireless-coverage.html

Le 31/12/2022 à 15h 08

(quote:2112202:consommateurnumérique)
Le TGV est efficace énergétiquement pour faire des longues distances, pas pour s’arrêter en gare tous les 50Km. La 5G a le même inconvénient : elle permet de rationaliser le spectre de fréquences (qui est limité), mais sans prévoir les usages essentiels à pérenniser au détriment d’autres qui seraient jugés futiles.

Mais si, “prevoir des usages essentiels”: on parle de network slicing, et c’est dans la spec de la 5G, avec une question ouverte sur la neutralité des reseaux (donc probleme politique, et non technique).

Très bien, la 5G est conçue pour répondre à de nombreux usages : déployons la 5G et arrêtons au plus vite 2G et 3G. Ce n’est pas la politique actuelle. Orange annonce l’extinction pour 2030, les discours n’engagent que ceux qui les tiennent. Et 2030 c’est dans plus de 5 ans, c’est le long terme.

Et tu feras partie des gens qui râlent pour obsolescence programmée, parce que des millions de terminaux (je le rappelle, pas seulement des telephones, mais énormément d’objets connectés) seront à changer. N’est-ce pas un désastre écologique de forcer le renouvellement des terminaux ?

Empiler les technologies permet surtout de rentabiliser le marché.

Rentabiliser un marché ou produit, c’est surtout ne pas dépenser et investir pour continuer de vendre une techno deja rentabilisée.. Ca devient une vache à lait vu que tu ne dépenses rien. Ca coute surtout aux opérateurs de la maintenance sur des technos qui ont 20ans ou plus pour certaines.

Si l’objectif était l’efficacité énergétique comme tu disais plus haut, ce n’est pas ce qu’il faudrait faire. On voit bien la priorité donnée. Vendre de la fausse 5G perfusée à la 2G/3G aujourd’hui, pour quel confort demain ? de la 5G avec des délestages ? La société n’est pas prête.

Hein ? J’avoue ne pas suivre ton raisonnement.

Le 31/12/2022 à 14h 59

Le support de l’IPv6 est present dans les standards 3GPP depuis le 1er draft. Donc si, c’est lié :)
Apres se pose la question de mettre en place une dual stack ou pas, c’est pour ca que le CGNAT64 est une reponse technique.

L’exemple du support de l’IPv6 dans le coeur de reseau est un exemple d’evolution en douceur, préalable mais necessaire au deploiement 5G.
Donc au lieu de tout mettre en place en une fois (coeur de reseau IPv6 + coeur de reseau stand alone), il y a un déploiement des technos piece par piece qui permet de réduire les risques et de fournir un service plus rapidement.

Et non, le RAN n’est pas retro compatible: t’as un double équipement pour gerer les différentes generations. Les telephones le sont parce qu’il y avait 2 modems (dont 1 dedié 5G).
Arriveront plus tard les équipements “tout en un”, permettant de gerer les différentes generations, mais ce n’est pas encore le cas aujourd’hui.
Ce n’est pas parce qu’il y a un multiplexage au niveau de l’antenne que le baseband est unique, exactement comme pour les modems des telephones. (Avec en plus des antennes dédiées pour certaines fréquences dédiées a la 5G, pour gerer du 26 et 28GHz).

Le 29/12/2022 à 15h 14

(reply:2112170:consommateurnumérique)
L’efficacité énergétique est corrolaire à l’usage de fréquence. Plus tu peux faire passer de donnees, plus tu peux servir de clients en meme temps sur une antenne unique. Donc, si, l’efficacité énergétique fait partie des specifications de la 5G.

Exemple concret, la 5G Narrow Band, une spec define par le 3GPP, permettant d’adresser le marché des objects connectés, pour concurrencer les reseaux de type SigFox et Lora.

Empiler les technos, ce n’est pas seulement pour répondre aux obligations légales, mais plutot assurer une transition “douce” pour les clients.
Il suffit de voir le tollé qu’il y a eu lors de l’annonce de l’arrêt des reseaux 2G / 3G en Europe et aux US pour voir que c’est nécessaire d’empiler les couches.
Sinon, tout le monde arrête les réseaux 2G et 3G, et on passe en 5G uniquement sur l’ensemble des fréquences. C’est top, on aura de la 5G partout (comme Free…) mais on abandonne énormément de clients, et l’intégralité des clients entreprise / IOT –> et ca va râler pour obsolescence programmée.

Le 29/12/2022 à 15h 07

Non, il y a des vraies differences nécessitant des ruptures technologies, ce qui justifie les generations successives.
Certaines evolutions sont retro-compatibles (VoLTE), et ne nécessitent qu’une nouvelle certification & mise a jour logicielle, mais d’autres changent fondamentalement la modulation (par exemple). Et donc, avoir une nouvelle generation est tout à fait justifiée.
C’est tout a fait comparable aux normes Wifi, en beaucoup plus complexe. Sur du Wifi, on ne se focalise que sur la partie radio (et uniquement en point à point), alors qu’avec les communications cellulaires, l’ensemble est beaucoup beaucoup plus complexe.

Dans le cadre de la 5G, le marketing a voulu afficher le logo “5G” sur les telephones alors que le coeur de reseau ne l’est pas. Donc, effectivement, on est en 5G entre les antennes et le telephone, mais c’est tout.
A cote, des évolutions au niveau du coeur de reseau sont mise en oeuvre depuis longtemps (IPv6 natif par exemple, avec du CGNAT pour les sites accessibles uniquement en IPv4) mais c’est pour preparer le passage aux reseaux 5G SA.

Le 29/12/2022 à 10h 51

Il faudra tout de même comparer des technos qui sont complètes, et pas seulement la partie radio.
Aujourd’hui, le cœur de réseau est encore basé sur les techno 4G, les cœurs de réseaux 5G “stand alone” ne sont pas encore en production.
Avec eux arriveront une optimisation de l’utilisation des antennes, avec une réduction possible des équipements au pied de l’antenne, etc. (C’est justement pour ça qu’Orange parle de réduction d’énergie en 2025)
Donc oui, ça prendra du temps, mais il faudrait pouvoir comparer la consommation par octet de bout en bout entre les réseaux 2G, 3G, 4G.

Aujourd’hui, la conso des antennes n’est qu’un élément (complexe) dans la consommation totale, qui va varier avec l’usage et le nombre de clients connectés à cette antenne : se focaliser uniquement sur cet élément est dommage, d’autant plus qu’en 5G, plusieurs antennes peuvent être actives vers un même terminal.

Le “tacle” du CNRS indiquant qu’il faut améliorer l’existant au lieu de de créer des ruptures montre en tous cas qu’ils ne savent pas de quoi ils parlent. (Ou que trop de vulgarisation fait du mal). Les technos ont évolué en 3G et 4G, par exemple, 3G LTE, vous vous en souvenez ? C’était justement une volition de la norme retro compatible.
Mais comme toute techno, il faut parfois des ruptures pour se débarrasser de pan de technologies obsoletes.

Aussi, le cœur de reseau 4G consomme d’aujourd’hui moins que le cœur de reseau 4G du début à quantité de donnée transférée égale (serveurs plus efficaces avec l’augmentation du nombre de cœurs CPUs, passage d’interfaces de 10Gb à 25Gb, etc. ); les antennes ont aussi évolué (FPGA vers des ASICS), tout comme les puces mobiles.

Bref, entre le discours marketing et l’industrialisation reelle d’un système complet, il se passe toujours beaucoup de temps, avec des gains réels qui ne se perçoivent pas immédiatement.

Le 08/08/2022 à 13h 51

L’alimentation en 5V est toujours présente, mais je ne pense pas que c’était lié à l’alimentation.
Je pencherais beaucoup plus pour la 3e harmonique: 3*340MHz –> 1020MHz.

Le 18/05/2022 à 07h 18

Je pense que c’est surtout lié aux modalités de renouvellement, soit mensuel, soit annuel, non ?

Le 11/05/2022 à 17h 27

Ils vendent l’Apple Watch pour cet usage maintenant ;-)

Le 01/02/2022 à 17h 43

De mémoire, la différence entre le compte payant et le compte gratuit est la durée validité du certificat. (A vérifier !)
Sinon, oui, ça continue de fonctionner après déploiement, comme pour un compte payant.

Le 01/02/2022 à 13h 05

Tu peux deja installer ton appli custom sur ton iPhone/iPad, gratuitement:
https://developer.apple.com/support/compare-memberships/

Il faut bien sur s’enregistrer, et tu as certaines limites par rapport à un compte dev payant, mais pour compiler ton appli et la deployer sur ton device, tu peux le faire gratuitement.

Le 19/10/2021 à 07h 43

Ils ont deja segmenté la gamme avec un nombre de coeurs CPU et GPU differents, je suppose pour avoir un yield correct:
M1

• 8 CPUs / 7 GPUs


• 8 CPUs / 8 GPUs

M1 Pro

• 8 CPUs / 14 GPUs


• 10 CPUs / 14 GPUs


• 10 CPUs / 16 GPUs

M1 Max

• 10 CPUs / 24 GPUs


• 10 CPUs / 32 GPUs

Le 19/09/2021 à 20h 12

Et pourquoi pas moi ?

Le 04/08/2021 à 08h 44

VLB_OB1 a dit:

des communications téléphoniques qui coupent ou avec du son qui ne passe pas, ordi très près du modem. Quand on passe sur du filaire, les problèmes disparaissent. Cela est probablement lié à une connexion internet pas assez performante mais au final, l’important est qu’avec wifi = problème et sans wifi = très bien

intuitivement, j’aurais tendance à accuser en premier la connexion internet mais comme c’est là où on a le moins de prises, on a décidé d’encourager le filaire pour les travailleurs qui font du téléphone

Non: étant donné qu’avec une connexion filaire, il n’y a pas de problème, c’est la connexion Wifi qui est pourrie.

Le 03/08/2021 à 12h 40

“encodage” ? Double chiffrement, peut-etre, mais en effet, il peut y en avoir 3 si on rajoute tu TLS.
Mais le chiffrement n’a pas de lien avec la stabilité du VPN. (Si la connexion Wifi est merdeuse, on ne peut pas accuser le VPN, si ?)

J’avais constaté qu’Orange droppait des packets UDP à un moment (mon boulot utilise OpenVPN) , ce qui conduisait à des perfs merdiques. (on est plusieurs en fibre chez Orange, le probleme nous affectait tous). Passer en TCP nous a permis d’avoir une connexion plus stable en attendant le fix chez Orange.

Le 03/08/2021 à 11h 08

Que veux-tu dire par “double encodage” ?

Le 01/06/2021 à 11h 33

Soraphirot a dit:

Optane… qui bouffe des emplacements DIMMs et ne sont compatibles que sur 1 ou 2 slots, à un tarif dément pour une capacité pas énorme au final…

Le probleme est surtout sur la durée de vie de ces SSDs. Un RAM disk est parfait pour ce type d’utilisation, avant le stockage “froid” sur un HDD.
On n’a pas le tarif de ces SSDs, mais avoir une (ou plusieurs) carte d’extension pour de la RAM fait sens, non ?

Cependant, rien ne me fera investir dans ce type de bouzin si c’est lié à de la crypto monnaie ….

Le 01/06/2021 à 05h 49

Dépasser 2To de RAM est déjà possible sur des serveurs, Intel ou AMD. (Mais ca pique, la segmentation commerciale imposant de prendre les gros CPUs…)

Une solution moins chère serait de créer un RAM disk sur PCIExpress: un FPGA et c’est parti !

A l’image de ce qui se faisait il y a quelques années:
https://www.newegg.com/gigabyte-gc-ramdisk-others/p/N82E16815168001

Le 12/05/2021 à 17h 35

Nordic Semi propose des kits intéressants multiprotocoles, et les kits sont tout à fait accessibles pour un particulier.
Il y a même un exemple à base de rpi pour faire un routeur Thread :-)

Sinon, il reste l’option ESP32 qui fonctionne en Wifi.

https://www.nordicsemi.com/Products/Low-power-short-range-wireless/Thread

Le 01/05/2021 à 11h 28

Ah, autant pour moi, la couleur blanche m’a induit en erreur, et j’ai lu (trop) rapidement le titre :)

Le 01/05/2021 à 08h 32

Faut faire attention avec la gamme FlexMini chez Ubiquiti: elle ne supporte pas toutes les fonctions de la gamme classique, ce qui est compréhensible étant donné le tarif moins élevé.
Exemple tout bête: pas d’acces ssh sur le mini switch 1Gb 5 ports. Pas grave, faut juste être au courant :-)

Le 01/05/2021 à 08h 28

Tout à fait, kvm en HTML 5, fonctionnement nickel, des maj des BMC et BIOS, pas de problème de version de TLS.
Pourtant, le matériel est bien plus ancien que 2016. (J’avais un microserver G8 qui a cramé y’a une semaine, et j’ai 2 DL360 et un DL380, tous G8)

Et on trouve encore très facilement toutes les pièces détachées ! Le seul “problème” étant le bruit, le matériel SuperMicro étant plus silencieux. Mais quand on achète du matos rackable pour un home lab , on est prévenu ;-)

Les problèmes que j’ai eues avec AsRockRack étaient déjà présents en 2018, et le matériel à beau être d’occasion, ça ne justifie aucunement les FRUs moisis.

Le 30/04/2021 à 16h 40

C’est quel modèle par curiosité ? L’AST2400 n’est plus utilisé depuis un moment chez ASR de mémoire (même la X470 qui date de 2019 était en AST2500). J’avais eu un souci similaire Java only avece une vieille carte mère ASUS et l’AST2400.

Par contre pour le suivi BIOS/BMC, pour suivre quelques modèles que j’ai eu en test ou que j’ai à titre perso, il y a régulièrement des mises à jour sur les modèles récents (même si forcément moins que sur un modèle grand public où ça bouge à la moindre modification de l’AGESA côté AMD par exemple).

Une MB a base de Xeon D1541:
https://www.asrockrack.com/general/productdetail.asp?Model=D1541D4U-2T8R
Au dela du support (je comprends que la carte est vieille, mais avec le support de TLS1.0 seulement, oblige de garder un vieux navigateur pour accéder au BMC), c’est toute la partie FRU qui m’avait fait rager:
“Board Product Name”, “Board Serial Number”, “Board Part Number” sont tous vides, et le “Product Serial Number” est défini à “SPMX1541-01”, soit juste un numero générique…
J’en avais acheté 2, et pas possible de faire la difference entre 2 serveurs donc, à part sur les adresses MAC.
Un serveur SuperMicro avec le meme processeur (Xeon D1541) a eu – lui – des maj de BIOS, et de BMC pour une meilleure gestion des certificats.

Alors, peut-etre que je me suis fait avoir (C’était du materiel d’occasion), mais je n’ai jamais eu ce type de probleme avec des serveurs HP ou Dell.
Du HP Gen8, ca marche encore très bien, et pour mon home lab, c’est suffisant.

Le 28/04/2021 à 11h 10

Je me suis fait avoir par du matos asrockrack: plus jamais !
Carte mère avec un xeond, mais les FRUs et le numéro de série étaient identiques “To be Filled by OEM”: le contrôleur AST2400 n’a pas été configuré en usine.
Donc, inutilisable, même pour un home lab.
Et le suivi est une vaste blague: pas de maj bios ou du BMC , on est donc limite à une console Java alors que du matériel Supermicro a eu une maj pour accéder au KVM virtuel en html5.

Le 21/04/2021 à 11h 30

Comparons avec le Mac mini, pas avec un iMac alors. Sinon, faut aussi intégrer le prix de l’écran, (introuvable ailleurs !) et des autres composants (carte wifi 6, clavier/souris, la bonne paire de HP, webcam 1080p, …)
On a ici le nouvel iMac d’entrée de gamme, à comparer avec les anciens iMac 21,5” qui ne disposaient pour certains que du chip graphique intégré.
Patience, le haut de gamme arrivera plus tard.

Le 30/03/2021 à 08h 48

Pour Unifi, l’accès distant est possible, sans configuration particulière, sur https://unifi.ui.com/
De meme, l’application mobile permet de gérer certains réglages.

Le 08/03/2021 à 17h 19

David_L a dit:

Non entre les tête et le module c’est du 868 MHz (qui est techniquement exploitable avec du ZB, mais selon les indications de la fiche technique c’est plutôt du RF).

Ok, c’est donc mon erreur, j’avais compris que c’était aussi du Zigbee. Ca fait donc sense que ca nécessite un deuxième pont, meme si je trouve dommage d’avoir choisis un protocole propriétaire…

Le 08/03/2021 à 15h 48

Mon point est que meme pour un meme vendeur, l’interop n’est pas garantie:

• Le thermostat et les vannes connectées Netatmo sont en Zigbee, plus un bridge Wifi (le module connecté à la chaudière)


• les interrupteurs et micro-modules Legrand sont Zigbee aussi

Il y a donc un besoin d’avoir un pont Legrand et un autre Netatmo, les 2 créants leurs réseaux ZB indépendants.

J’espère que Thread/CHIP permettra à minima une unicité du réseau domotique au sein d’un logement, et proposer une solution plus standard pour la mise à jour des différents éléments du réseau (et pourquoi pas au sein de l’application “Home” d’Apple, et l’equivalent côté Android).
Comme tous les routeurs Threads font partie du meme réseau, l’extension de la couverture sera beaucoup plus aisée.
Le fait d’avoir des passerelles Threads non liés à un vendeur particulier me fait espérer, peut-être à tort !

Le 08/03/2021 à 08h 36

Et malheureusement, en Zigbee, ce n’est pas du tout le cas.
Exemple tout bête: la gamme “… with Netatmo” de Legrand ne fonctionne pas avec les produits Netatmo, qui appartient à Legrand !
Donc pour les interrupteurs Legrand, il te faut un pont Legrand :-(
L’application voit bien les 2 ponts, peut controller les 2 Marques, mais c’est tout. Il y a très probablement 2 réseaux (faudrait que je me prenne un dongle Zigbee pour confirmer ca !)

Le vendor lock-in a de beaux jours devant lui, ne serait-ce que pour la mise à jour des éléments: on peut bidouiller et ajouter une ampoule IKEA à un pont Hue, mais on ne peut pas la mettre à jour.

Et ce point limite de fait l’usage avec des passerelles Zigbee et Jeedom (ou autre).

Et c’est l’avantage de CHIP, en théorie.
En théorie seulement, car la couche applicative est aussi à la discrétion de chaque vendeur.
Le protocole Homekjt est maintenant publique, et fait partie de Thread (c’est une option): on peut espérer l’arrivée de la prise en charge d’Homekit dans Android !
Donc, à voir si l’intégration que propose ce Thread/CHIP permet de limiter les applications sur nos téléphones.

Le 24/01/2021 à 12h 42

Je suis étonné que personne ne parle de la presence (ou non) d’une MMU (Memory Management Unit), permettant l’usage de mémoire virtuelle. (Mode “protégé” selon Inte)

Sur les uC, il y a éventuellement une MPU (memory protection unit), mais pas de MMU.

Si on regarde le 8086, il n’y avait pas de MMU (présente sur le 80286), mais déjà le concept était présent avec des segments de 64k (processeur 16bits, bus d’adresse de 20bits, étendu à 24 bits sur le 386).

De manière plus contemporaine, si on regarde les cœurs ARM M vs A (ou plus anciens)

• sur le M7, out of order, mais MPU (trustzone)


• sur les cœurs arm7, arm9 et Cortex A, ils disposent tous d’une MMU.

Les soc permettent surtout de réduire le nombre de composants (réduction d’un coût, PCB moins complexe, etc), mais c’était déjà le cas lors de l’intégration du coprocesseurs flottant ou … des MMU (composant externe pour les 68k par exemple)

Le 19/12/2020 à 08h 14

C’est pour ça que j’ai dit “à ressources constantes, faut prendre des décisions”.

Et donc non, la capitalisation boursière n’a pas d’impact sur les budgets. Le fait d’être racheté par IBM (parce que c’est ça qui semble t’influencer) n’a pas changé ma vie jusqu’à présent.
Je n’en sais rien côté sales, mais côté engineering, CNET’s business as usual.

Haters gonna hate: les gens qui ralent sont forcément plus vocaux. Et bcp ralent simplement parce que ça change.
Leur vie ne change pas, pour certains, Stream pourraient simplifier leur vie, mais je crois que bcp ont râlé à chaud.
Donc bad Buz et PR Hell.

Au lieu d’être en retard, Centos aura un bug fix d’avance. Pour autant, il n’y a pas de raison de casser la compatibilité, ou ça la cassera aussi sur RHEL=> pas de changement à ce niveau.
D’où les 2 versions Stream 8 et Stream 9.

Avec Centos, tu avais aussi un délai entre la sortie mineure de RHEL et celle de Centos.
Donc la compatibilité exacte ne pouvait pas se faire, sauf si tu bloquais la release de RHEL avec Satellite.
Chose que tu peux faire côté Stream, n’est-ce pas ?

Il y a le coût du tooling, mais tu dois déjà avoir déployé un foreman/satellite, c’est donc le coût de la conf initiale à absorber, pour pouvoir fournir la version de Stream correspondant à la version de RHEL. Ce que tu faisais dans l’autre sens pour avoir les mêmes versions releases entre RHEL et Centos.

Ainsi, Stream te fournit le même service (memes versions), avec un délai reduit à zéro, tout en ayant une vision sur les prochains fixes qui arrivent dans RHEL, pour mieux tester/préparer tes applis et des déploiements vers la prod.
Ainsi, Stream est une avancée pour toi, non ?

Le 18/12/2020 à 21h 59

ForceRouge a dit:

“Beaucoup de decisions, bonnes ou mauvaises, sont prises de bonne foi, avec les informations dont on dispose à un moment donné.”

Il n’y a pas de “décisions de bonne foi” dans une boite qui vaut 34 milliards, il n’y a que des dollars sonnant et trébuchants. A part si le big boss est actionnaire majoritaire et est convaincu par la philosophie du libre, les décisions du top management n’iront jamais dans le sens de la beauté de la technique, et encore moins dans le monde “obscur” du libre que les businessmen ne comprennent pas. Autant pour nous, la philosophie derrière un projet à toute son importance, autant pour un décideur qui gère les dollars, un business, c’est de l’argent qui entre, de l’argent qui sort, et comment on maximise le profit tout de suite.

C’est exactement ne pas connaitre Red Hat: le CEO, CTO, et le management de RHEL sont tous convaincus par la philosophie du libre. On peut ne pas être d’accord avec leur decision, mais tu devrais au moins écouter ce qu’ils disent.
Exemple simple: regardes les entreprises rachetées par Red Hat: toutes celles qui avaient du code source fermé sont devenues open source. Ca prend forcement du temps, mais c’est ce qu’il se passe.

Et jusqu’à present, cette amour du libre permet d’avoir des nouveaux clients et de recruter des ingés aussi convaincus qui comptent et contribuent upstream. (beaucoup ne font que ca d’ailleurs !)
Et pourquoi changer quand le CA augmente ?

Et pourtant, parfois, il serait tellement simple de pousser un patch downstream only pour corriger un bug ou ajouter une feature, mais non -> tu expliques au client qu’il va attendre 6 mois le temps que ca soit discuté/revu/re-discuté/accepté upstream puis qu’il devra faire une mise à jour pour être sur la prochaine release.
Parce que Upstream First. C’est contraignant, mais c’est la philosophie de la boite.

IBM, on voit où ils sont aujourd’hui, une société de dinosaure qui essaye de faire du profit sur son trésor de guerre accumulé pendant qu’ils savaient encore faire quelquechose. Ils ont acheter une boite, RedHat, 34Mds, elle doit maintenant rapporter beaucoup, le plus vite possible.

Regarde les chiffres du dernier quarter, on ne peut pas vraiment en demander plus a Red Hat…
Ce qui m’a le plus étonné depuis le rachat par IBM ?
Ben qu’on reste “nous-meme”, c’est a dire qu’IBM n’est pas intervenu dans la façon de travailler, ou placé des gens pour gérer Red Hat, ou faire de l’optimisation.
Rien. Mais vraiment rien n’a changé.
Si -> On a perdu Jim, qui est maintenant le President d’IBM. On a eu des réorganisations, mais pas plus pas moins qu’avant: ca fait partie de la vie d’une organisation.
Et j’insiste, personne d’IBM n’est venu dans l’organigramme.
C’était une promesse faite initialement, et jusqu’à aujourd’hui, cette promesse est tenue. (Et pourtant, on connait tous des histoires de boites rachetées par IBM !)

Croire que l’arrêt de CentOS, c’est pour le bien de la communauté et la promotion de la CI/CD, c’est juste ne pas voir l’éléphant dans le corridor. Tout ce qui se trouve entre la décision initial de tuer CentOS et la finalité qui est que la communauté n’aura plus de système d’exploitation iso-rhel sans support, c’est du détail pour geek en quête de beaux principes.

Quant au board de CentOS, chapeauté par RedHat, lui même chapeauté par IBM… on sait qui décide au final.

Ben… le board de Centos. Tu peux interpeler les membres non-Red Hat leur demander leur opinion là dessus: ca sera le plus simple !.
Je comprends qu’à resources constantes, tu ne peux que faire des choix. Ils essayent de résoudre 1 probleme, c’est devenu un PR Hell; je n’y peux pas grand chose, à part dire qu’il n’y a pas de master evil plan.
Pour preuve ? Regarde Oracle qui appelle du pied les utilisateurs Centos.

A mon avis, un utilisateur Centos ne payera pas pour du RHEL, ou pour du support d’une autre entreprise. Meme ce master plan pour les “forcer” à passer sur du RHEL ne fonctionne pas: ces personnes utilisent Centos 7, qui est encore supporté jusqu’en 2024.
D’ici là, soit Stream aura fait ses preuves, et ils migreront tranquillement en étant rassuré, soit ils seront passés sur autre chose (Scientific Linux / Rocky Linux / autre distrib derivée de RHEL.
Et dans les 2 cas, l’utilisateur ne paiera pas.

Bon, je vais m’arrêter, puisque ni toi, ni moi ne se laissera convaincre.

La culture d’entreprise est juste … différente … d’une autre grosse taule.
Mais je conviens qu’il faut le vivre pour le comprendre.

Le 18/12/2020 à 19h 07

Tu peux bloquer les updates le temps de valider ces updates. Rien de plus.
Concernant le recouvrement Centos Stream ⁸⁄₉… faudra voir quand 9 sortira, je n’ai pas les infos.

Apres, si tu supposes que tout le monde ment en interne, je n’y peux rien…
Je comprends certaines reactions, mais il ne faut pas non plus penser que tout le monde a un master plan pour faire chier le monde.
Beaucoup de decisions, bonnes ou mauvaises, sont prises de bonne foi, avec les informations dont on dispose à un moment donné. (Et encore une fois, la decision est prise par le board de Centos … qui ne contient pas que des employés Red Hat)

En tant que dev upstream, je vois Stream comme une vraie opportunité pour le CI/CD, mais aussi pour la prod (Facebook tourne avec un Centos et leur kernel par exemple, mais ils ont les équipes kernel pour du self-support).

D’un point de vue prod, je vois 2 cas:

• Centos 7: pas de changement


• Centos 8 Stream & suivants: pour ceux qui ne veulent pas suivre la cadence, on a aussi les images UBI7 et UBI8, qui sont gratuites et librement redistribuables, permettant donc une containerisation des applications d’une manière pérenne.

Le 18/12/2020 à 17h 39

Disclaimer: je bosse pour Red Hat, pas dans l’équipe RHEL, ce que j’écris ici n’engage que moi.

Comme a dit un collègue: “C’est à ca qu’on voit qu’on est une boite d’ingés et pas une boite de marketing, on n’a pas su communiquer suffisamment sur Stream”.

Centos Stream != Fedora. Stream n’aura pas de changement radicaux, parce que c’est justement ce que propose RHEL.
J’ai moi-meme été grandement rassuré par ca:
https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/

Le 18/12/2020 à 17h 34

Disclaimer: je bosse pour Red Hat, pas dans l’équipe RHEL, ce que j’écris ici n’engage que moi.
Je souhaitais ne répondre qu’au dernier point, mais je fais une réponse plus complète au final.

ForceRouge a dit:

5 mois de retard sur un support de ⁸⁄₁₀ ans, on s’en sort très bien, je te rassure.

Ben pas forcement.
Quand tu bosses upstream, que tu veux monter un CI/CD, les 6 mois de retard entre Centos et RHEL font très mal, justement:
OpenStack, 1 release tous les 6 mois.
Kubernetes, 1 release tous les 3 mois.

Et comme il n’y avait pas de beta de Centos 8 dispo, ben… c’était une vraie galère à gérer.
En tant que dev upstream, je suis content de ce que Stream peut apporter.
Ca soulève d’autres questions aussi, comme le support des anciennes branches, vu que Stream est en CD.

5 mois de retard, c’est rien. Il faut de toute façon au moins 2 ans pour migrer une plateforme, ensuite 5 ans d’exploitation avant de passer à la release suivante, et encore 3 ans bonus pour encaisser les retards ou laisser mourir les projets qui arrivent à terme. Avec un overlap de deux versions majeures de 4 ans.

Stream c’est 5 ans. Le début de Stream 9 signe la fin de support de Stream 8. Aucune boite ne proposera le support de Stream car ca veut dire qu’elle devra adapter, tester et fournir une version final les quelques jours d’overlap de deux version majeures de Stream. Pareil pour une prod, aucune DSI qui sait ce qu’elle fait n’ira sur Stream.

Je peux aussi dire qu’aucune DSI qui sait ce qu’elle fait n’ira sur un OS sans support, ou sans les personnes qui savent supporter l’OS, mais ca ne fait pas avancer le débat, n’est-ce pas ?

Ah donc tu penses que magiquement toutes les boites du monde vont migrer toutes leurs infra de Centos Stream 8 à Stream 9 en quelques jours? Comme dit plus haut, soit c’est de la propagande, soit tu sais pas de quoi tu parles.

Foreman -> et on peut bloquer les maj jusqu’à validation, faire un rollback si besoin, etc.
Ca ne change pas par rapport à avant: un repo local pour controller les RPMs qui sont deployés.

Ce n’est pas ce que j’ai dit et ca n’a rien à voir. Les bugs identifiés dans RHEL se retrouvent dans CentOS quoi qu’il arrive.

• RHEL n’est donc pas une beta de CentOS.


• Les bug dans Stream ne passeront pas dans RHEL. Stream est donc une beta de RHEL.

Stream n’est pas une beta. Ca sera déjà une selection de patchs, testés upstream, puis downstream, avant d’être intégré dans stream. On est loin d’une version beta.
La, il s’agit d’avoir une meilleure integration, et une meilleure visibilité du boulot effectué en interne.

C’est exactement ce que j’ai dit, RedHat contribue beaucoup au libre et propose une distribution serieuse pour la communauté et donc est apprécié de la communauté. C’est un deal gagnant/gagnant et RedHat gagne déjà beaucoup d’argent avec cet état. IBM veut maintenant gagner plus, au détriment de la communauté.

Dire qu’IBM veut gagner plus d’argent est complètement méconnaître la structure actuelle de Red Hat ET de Centos.
“Au detriment de la communauté” ? Le board Centos a pris cette decision. (Et non, il n’est pas composé uniquement d’employés Red Hat.)
Je suppose qu’avec Stream, Red Hat espère avoir plus de retours, et ainsi avoir plus de feedback sur les features qui sont backportées.

Ce que RedHat fait ici, c’est d’inverser le sens de la contribution. C’est n’est plus RedHat qui contribue au libre, mais la communauté qui contribue à RedHat. Et je pense que ca ne vas pas bien se passer car au final, ce sont les dev du libre qui décident.

Tu y vas très fort je trouve ! (C’est ce qui m’a choqué dans ton post).
Dire que Red Hat ne contribue plus au libre est méconnaître l’engagement de Red Hat. Ce n’est pas simplement “emballer dans du papier cadeau les sources fournies”.
Les dev bossent upstream first. Et ils continueront ; ll continueront de gérer des communautés; ils continueront de gérer des projets; ils continueront d’héberger des confs virtuelles tant que le Covid ne permettra pas des rencontres physiques, etc.
Fedora reste Fedora, rien ne change ici, tout comme la fourniture des SRPMS ; Il n’y a aucune inversion de quoi que ce soit.

L’engagement open source avec les utilisateurs est meme renforcé avec Stream je trouve: (avis perso, encore une fois, je ne travaille pas dans l’équipe RHEL / Centos)

• ensemble de patchs sélectionnés


• Les fixes sont dispos plus rapidement, non seulement pour les bugs mais surtout pour les CVEs


• nightly dispo


• plus grande visibilité des process internes


• tu peux ouvrir un RFE sur Centos Stream, et ca arrivera plus vite que si on devait attendre la prochaine release de RHEL.

Le 18/12/2020 à 13h 16

trexmaster a dit:

Quand au fait de faire tourner tous les workloads dans des conteneurs déjà on en est (très, très) loin, et ensuite je crois pas que Redhat soit le mieux positionné pour ça.

Je suis curieux d’avoir ton avis la dessus :)

Le 18/12/2020 à 13h 11

C’est bien dommage. On ne peut pas fournir un service sans budget (et donc acheter les produits) ni personnel (pour installer et tout maintenir de son côté).
Parce que meme si on est full upstream (Foreman + Centos), ca nécessite du temps pour s’en occuper, du temps pour se former, etc. (Je mets de coté la faible valeur ajoutée perçue)

Si vous avez encore du Centos 6 (EOL le 30 novembre 2020), vous ne devez pas encore etre passé à Centos 8, n’est-ce pas ?
Et le support de Centos 7 est le 30 juin 2024 (Ca n’a pas changé): assez de temps pour passer a Centos Stream donc :)

Le 18/12/2020 à 11h 00

C’est la ou je rejoins Renault: beaucoup a été dit “A chaud” sans réellement analyser en fait.
Comme le fait que Stream est un CD, pas une rolling release.

Il ne devrait pas y avoir d’incompatibilité de version de lib, parce qu’il y aura 2 streams: Stream 8 et Stream 9.
Et comme on peut ouvrir un BZ sur Stream, et que Stream est la prochaine version de RHEL, ca permet de detecter les problèmes plus tot, et donc de les corriger plus tot aussi.
Je trouve que c’est gagnant/gagnant: les utilisateurs de Stream ont une version à jour rapidement, et leur rapports de bugs permettent d’améliorer le produit plus rapidement qu’avant. (ie: pas besoin de le reproduire sur RHEL pour être pris en compte !)

Apres, une raison aussi de cette migration est la disponibilité de UBI: maintenant que beaucoup d’applications tournent dans des containers, le niveau d’exigence de compatibilité change.
UBI étant redistribuable, vous pourriez avoir le meme container aux US et en Europe :)

Le 18/12/2020 à 10h 34

C’est exactement le contraire en fait.
Centos Stream correspond a la prochaine release mineur de RHEL.
C’est pour ca qu’il y aura un Centos Stream 8 et un Centos Stream 9 [1]

Les problèmes seront donc plus rapidement corrigés avec Stream qu’avec Centos, qui nécessitait un rebuild à posteriori d’une release de RHEL.

[1] https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/

Le 22/11/2020 à 11h 12

Au niveau connectivité, j’ai vu sur un screen shot que les 2 ports TB sont présentés comme 2 bus séparés.
Sur les Mac Intel, les ports TB sont regroupés par paires, avec donc une bande passante partagée.
Avec les M1, on aurait donc 2x40Gb/s: quelqu’un pour verifier ce point ?

Le 18/10/2020 à 10h 56

La spécification est disponible, avec les exemples.
Donc, si, c’est ouvert.
Et les fabricants voudront plutôt avoir le “logo qui va bien” pour la vente, ce qui nécessite dans tous les cas de passer par la case certification (comme chez les concurrents).
Par contre, ça facilite l’implémentation DIY (home bridge et autres): l’utilisateur n’a qu’un écran supplémentaire indiquant que le produit n’est pas certifié.

Je fais une différence entre ouverture et certification/support. Les distributions Linux payantes sont toutes ouvertes, mais dès que tu intègres un driver de tierce-partie, tu n’es plus supporté.

Le 15/10/2020 à 19h 20

C’est la que l’ouverture de la couche applicative HomeKit devient intéressante, car homekit comble justement ce manque de définition du protocole métier. (Bref, de la couche7)

https://github.com/apple/HomeKitADK

Le 16/10/2020 à 10h 21

+1: quand les fabricants de proc ARM passeront enfin tous à de l’UEFI (EBBR ou SBBR), on gagnera vraiment en confort !
J’ai installé hier une fedora 33-beta ARM sur RPI4 avec de l’UEFI, il n’y a aucune difference avec une installation en x86… (Il manque encore quelques binding pour les drivers Wifi & BT, mais rien qui m’empêche de l’utiliser ; encore que je démarre uniquement avec de l’ACPI, faudrait tester avec ACPI+device tree … )

Le 05/10/2020 à 13h 20

Est-ce que quelqu’un sait si c’est compatible SBSA maintenant ?

La dernière fois (ok, c’était y’a 2 ans :-) ) que j’avais voulu avoir un kernel un peu plus a jour, ca a été une vraie plaie (drivers USB qui n’étaient pas compatibles avec les dernières versions du kernel, plus de support GPU, etc. )