Bonjour, tu as raison, je vais faire corriger pour que ça soit plus clair (Marc Rees, tu nous manques !). Toutefois l'exemple n'est pas tout à fait adapté : le code source de RHEL est bien "ouvert", et il est gratuit. Donc libre à toi de l'utiliser. Sauf qu'en pratique, on n'utilise pas le code source mais les objets compilés par Red Hat, qui eux sont soumis à modèle commercial payant, non ouvert. D'ailleurs, il existe des distributions dérivées de RHEL, utilisant son code source, comme CentOS Stream, AlmaLinux, ou Rocky Linux. Fedora, elle, est une version "en amont" de RHEL.
CentOS Stream est en amont de RHEL, et non un derivé. C'était Centos (tout court) qui était un rebuild.
ce que je lis ici ne correspond pas à ce que je constate (réseau Bouygues).
ton partage de connexion mobile sur iphone, tu dis que c’est le même préfixe puis que c’est un autre /64, soit c’est le même soit c’est un autre. si c’est le même /64 alors il y a des chances que ce soit en pont. l’opérateur peut définir la taille du préfixe alloué et le nombre de /64 délégués, mais je pense qu’ils se limitent à un seul, quand ça n’est pas un /128.
Je dis juste que j’ai une autre IPv6 dans le meme /64.
Le
03/01/2023 à
11h
10
Non, rien de concret là dedans, nat64, c’est pas le cgNAT, c’est encore autre chose. le cgNAT partage les ports udp/tcp entre plusieurs utilisateurs sur la même adresse V4. nat64 ajoute le préfixe ipv6 64:ff9b::/96 à une adresse ipv4 pour traverser le réseau ipv6, principalement mais ne tripatouille pas les ports, il me semble, car l’adresse ipv4 destination est vue avec tous ses ports. Dans l’autre sens, le port est sans doute changé, mais de façon transparente.
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.
je ne suis pas abonné chez Orange, mais tu parles du partage de connexion vers une autre machine ? cette adresse IPV6 c’est sur un PC ou sur le téléphone ?
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
D’ailleurs l’intérêt par rapport à l’effort de couverture semble très limité… Déployer des antennes massivement sur des lampadaires ou mobilier urbain pour couvrir 100 mètres autour…
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
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. D’ailleurs, toujours pas d’ipV6 sur un partage de connexion mobile, pourtant le mobile reçoit un /64 si j’ai bien compris, pas un /128, il faut dire que la version actuelle de SLAAC n’aide pas, une petite évolution du système pourrait donner une adresse interface en /48 (comme les adresses mac) et 16 bits pour des SR dans un /64, on serait encore large (256 mille milliards d’interfaces par SR et 65 000 SR par /64) , ce serait vraiment souhaitable ce genre de mécanisme.
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.
(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
Je ne vois pas bien où tu vas chercher un rapport entre ipv6 cgnat et 5G aucun des trois n’est lié. Les réseaux à antennes 5G acceptent les modulations des réseaux précédents, et surtout les terminaux aussi, heureusement.
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
Justement, il faudrait arrêter avec ces histoires de G qui n’ont qu’une existence marketing, pas du tout technique, car la technologie évolue en permanence sans barrières réelles entre les “G” qui de toute façon restent rétro compatibles avec l’existant. Même les nouvelles bandes de fréquence de la 5G pourraient être utilisées en LTE. D’ailleurs, il faudrait généraliser ce terme LTE où le L et le E tombent pile poil pour contredire les “G” bidon. Un bon réseau est capable d’évoluer sans se remettre en cause tous les 10 ans, c’est ce qui se passe d’ailleurs, le réseau radio ne nécessite jamais de tout renouveler, comme ça c’est passé pour aller du cuivre à la fibre, et encore, les fourreaux et poteaux ont été conservés en distribution partout où c’était possible. Ce sont plutôt les terminaux qui ont du mal à suivre le réseau plutôt que l’inverse, passer de la télé analogique à la TNT HD a été quasi transparent dans le réseau d’émetteurs, mais plus complexe pour ce qui est des téléviseurs et du codage à la source des flux, sans parler des problèmes administratifs de partage des multiplex.
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.
D’après la page wiki sur le HDMI, la tension est de 5V pour un ampérage pouvant atteindre 50mA, soit 0.25 W.
Par contre pour le GHz, je ne sais pas l’expliquer. Visiblement les fréquences du signal d’horloge sont dans la centaine de MHz (~300 MHz). A moins que le problème venait d’un mauvais blindage couplé à une mauvaise mise à la terre. Mais ça me parait pas suffisant.
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.
L’application continue de fonctionner quand on arrête le test ?
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: Apple
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.
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
je pense qu’il veut dire un fois par le vpn et une fois par le protocole wifi
“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.
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 !
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.
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 :-)
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.
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.
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.
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.
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)
Ca c’est sure, très peu payerons du RHEL là où CentOS était utilisé, et le peu qui payeront sera compensé par le nombre qui migrerons vers une autre distro.
“The CentOS Project Community-driven free software effort focused on delivering a robust open source ecosystem around a Linux platform. “
Je n’ai pas l’impression que CentOS soit très “community-driven”, comme ils disent, mais bel est bien business driven.
Il y avait une autre solution simple si l’objectif n’était pas le benef a court terme: Faire une RHEL Stream + RHEL et CentOS Stream + CentOS…
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
C’est bien de bloquer les updates dans TheForeman, mais c’est encore pire, tu n’es simplement plus à jour… justement le fond du problème.
Avec une release majeur RHEL tous les 4,5-5 ans et un support de Stream de 5 ans. Pendant combien de temps sera l’overlap de maintenance Stream 8 et Stream 9? Aucun? 1 mois? 6 mois comme Fedora?
Parce que même 6 mois pour que:
Tous les softs d’éditeurs externes déployés se rendent compatible (s’ils le sont un jour), quand je dis compatible, je veux dire que la société éditrice supporte la nouvelle version de Stream pour ne pas se faire raccrocher au nez
Que l’infrastructure intègre la nouvelle release de Stream avec tous les sytèmes de déploiements, d’audit, de log, de sécurité, d’authentification, etc…
Que les dev internes soit repackagés, testés et validés avec la nouvelle release de Stream
Que toute la plateforme soit migrée
,c’est évidement fait pour que plus aucune prod de tourne sur CentOS et donc forcer la migration vers RHEL. Je ne doute pas de ta bonne foi, mais dire le contraire, c’est ne pas voir l’évidence et propager un mensonge qu’on vous balance en interne.
La vrai vie de la prod, c’est de gérer plusieurs projets en parallèle et se mettre des contraintes d’update d’une prod complète en 6 mois, ca veut dire “n’utilisez surtout pas Stream en prod”.
En tuant CentOS, un autre projet va venir le remplacer, mais ca va prendre une bonne paire d’année et pendant ce temps la, beaucoup auront migré sur RHEL8. C’est de la pure décision business de gens qui n’ont jamais tapé une ligne de commande de leur vie.
Ok alors si Stream est si bien, que les patchs sont testé et validé, que tous vas plus vite pour le mieux sans rien casser, pourquoi RHEL n’est pas Stream aussi? A t’entendre, RHEL c’est obsolète… non ?
Tu peux bloquer les updates le temps de valider ces updates. Rien de plus. Concernant le recouvrement Centos Stream 8⁄9… 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
Stream n’est pas l’équivalent d’une distribution linux “stable”, c’est à dire qui ne propose pas de changements radicaux subitement.
si il vous faut maintenir des serveurs à jour, avec des correctifs de sécurité par exemple, vous ne pouvez pas vous permettre de passer à Stream: trop risqué.
Il vous faudra à une autre distribution maintenue à moindre coût que RHEL.
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”.
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 8⁄10 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
Je veux bien le croire, sauf que la réalité de la majorité des services IT c’est : pas de temps, pas de budget, pas de personnel, pas une priorité. Donc le mal est fait parce que les gens vont retenir que CentOS n’est plus une copie sans support de RHEL (ce qui allait très bien à tout le monde) et vont chercher une alternative (comme le font mes collègues) avant même de se poser la question de savoir ce qu’est CentOS Stream.
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.
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.
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 ?
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)
+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 … )
191 commentaires
L’open source est partout, donc…
07/10/2024
Le 10/10/2024 à 14h 50
C'était Centos (tout court) qui était un rebuild.
Le CNRS se demande pourquoi l’exploitation des réseaux 5G « s’avère finalement aussi coûteuse en énergie »
28/12/2022
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
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-3⁄3.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
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).
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
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).
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 ?
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.
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
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.
Quand une box, un casque sans fil ou un câble HDMI brouille les fréquences
08/08/2022
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.
Apple autorise la tacite reconduction des abonnements en cas de hausse de prix, sous certaines conditions
17/05/2022
Le 18/05/2022 à 07h 18
Je pense que c’est surtout lié aux modalités de renouvellement, soit mensuel, soit annuel, non ?
L’aventure iPod s’arrête : Apple met fin à la commercialisation du Touch
11/05/2022
Le 11/05/2022 à 17h 27
Ils vendent l’Apple Watch pour cet usage maintenant ;-)
Epic vs Apple : Microsoft, l’EFF et 35 États soutiennent l’éditeur de Fortnite
01/02/2022
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:
Apple
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.
Apple M1 Pro et M1 Max : qu’est-ce que ces SoC ont dans le ventre ?
19/10/2021
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
M1 Pro
M1 Max
Concours GeForce RTX 3060 Ti : et le gagnant est…
27/09/2021
Le 19/09/2021 à 20h 12
Et pourquoi pas moi ?
WireguardNT : le protocole VPN adapté au noyau Windows
03/08/2021
Le 04/08/2021 à 08h 44
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” ?
PlotRipper : Sabrent dévoile ses SSD pour Chia Network, jusqu’à 54 000 To d’endurance
31/05/2021
Le 01/06/2021 à 11h 33
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
Domotique : CHIP devient Matter, la Zigbee Alliance renommée Connectivity Standards Alliance
12/05/2021
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
UniFi Switch Flex XG d’Ubiquiti : 4x 10 Gb/s dans un format compact
29/04/2021
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 :-)
ASRock Rack TRX40D8-2N2T : 2x 10 Gb/s + 2,5 Gb/s et Ryzen Threadripper dans un serveur
28/04/2021
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
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.
AirTag, TV 4K avec Thread, Nouvel iMac, iPad Pro M1, 5G et Mini LED : Apple fait le plein
21/04/2021
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.
Netgear met fin à l’offre Basic d’Insight
29/03/2021
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.
Domotique : Orange rejoint la Zigbee Alliance, le Thread Group et mise sur CHIP
05/03/2021
Le 08/03/2021 à 17h 19
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:
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.
Processeur, SoC, micro-contrôleur : quelles différences ?
22/01/2021
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)
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)
Red Hat met fin à CentOS et pousse Stream, colère au sein de la communauté
18/12/2020
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
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.
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.
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 8⁄9… 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:
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.
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.
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 ?
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.
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)
Le 18/12/2020 à 13h 16
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/
Mac mini avec Apple M1 : nos premiers résultats (natifs)
20/11/2020
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 ?
Domotique : HomePod mini est le premier appareil HomeKit Thread d’Apple
14/10/2020
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)
Raspberry Pi 4 et Ubuntu 20.10 : une image Desktop ARM64 sera disponible
14/10/2020
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 … )