Embarqué ne signifie pas que tu as une puissance CPU minimale (ou même générale comme une RAM faiblarde). Cela signifie que tu peux rencontrer des contraintes très particuliers :
Interface homme / machine limité voire absente ;
Alimentation électrique ou accès à Internet très intermittent ;
Contraintes temps réelles fortes ;
Grande variétés de capteurs ou d'entrées / sorties ;
Lien logiciel / matériel très poussé pour l'application.
Typiquement il me paraîtrait absurde de considérer que le la machine faisant la conduite autonome d'une voiture ne soit pas considéré comme un système embarqué alors que pourtant le matériel utilisé est plus puissant que bon nombre de PCs en circulation. Mais les contraintes évoquées plus haut rend son développement assez différent que ce qui se fait pour un logiciel traditionnel sur PC.
Bref, les systèmes embarqués avec une faible puissance matérielle ne sont qu'une partie du domaine en question.
C'est pas tellement lié en fait. Le device tree ne liste que les devices qui ne sont pas découvrables, donc sur des bus mémoires, i2c, spi, etc. Pour USB et PCIe, le seul truc qui est listé est le contrôleur. Tout comme ACPI.
Bien sûr, mais les cartes ARM du moins au début recouraient bien moins au PCIe et USB, préférant les bus non découvrables à la place. Alors que la plupart des composants dans le PC finissent par passer par ces bus à un moment ou un autre.
Cela change beaucoup sur la manière de prendre en charge le matériel.
C'est vrai, mais on pourrait utiliser exactement le même argument pour le BIOS / UEFI et les tables ACPI passées au kernel: il faut bien que quelqu'un les écrive pour les parties non-découvrables. Du coup, je vois pas trop où c'est un point fort.
Dans un cas c'est fourni par le constructeur lui même, dans l'autre c'est souvent au développeur de l'ajouter de son côté que ce soit au sein du noyau lui mee ou du chargeur de démarrage.
Si, en fait. Tout ce qui est listé dans le SoC et a un status = "okay" peut être utilisé. Si c'est effectivement le cas reste à charge de l'OS, mais tout est censé être utilisable.
Je sais ce qu'est un device tree, j'en écris régulièrement.
Justement je mentionnais qu'en l'absence de device tree, c'est à dire si tu essayes de démarrer ton noyau avec juste ce qui est fourni de base par le constructeur de la carte, bah tu ne booteras pas ou en mode très dégradé. Car le constructeur ne te fourni pas en dur le device tree qui va bien, tu dois l'ajouter toi même quelque part.
Alors que quand je monte mon PC, je n'ai rien à faire. Je démarre mon noyau sans besoin d'ajouter une description du matériel avec mon système. Car cette découverte est faite et fourni automatiquement à mon système.
La "découverte" du DT en lui même est effectivement le seule avantage du BIOS / UEFI sur le DT.
Cette différence paraît faible mais elle est en fait fondamentale ! C'est cette différence qui est la source de tous les mots et qui rend le device tree obligatoire. Et qui complique la conception d'une image ARM universelle.
J'aurais tendance à dire que non, mais dans ce cas là, le bootloader sur ARM ne fait pas partie de l'OS non plus. Il commence au kernel, qui lui n'a pas à se soucier de la partie decouverte, on lui passe le DT en argument.
L'OS au sens strict du terme se réfère en effet au système noyau + espace utilisateur quelque soit l'architecture. Mais il me semble pertinent de considérer le chargeur de démarrage dedans. Après tout Fedora, Windows ou macOS ont leur propre chargeur de démarrage qui est géré comme n'importe quel logiciel. Et d'autant plus que nous avons dans un cas (pour PC) un chargeur de démarrage universel (il fonctionne pour à peu ès n'importe quel PC sans soucis) et de l'autre nous avons un chargeur de démarrage (que ce soit U-boot ou autre) qui doit être particulier pour l'initialisation de base et sélectionner le bon device tree à envoyer au noyau.
Tu te méprends sur ce qu'est la découverte de périphérique.
Le BIOS / UEFI permet d'initialiser le système sans devoir le décrire, le tout automatiquement. Tout simplement en utilisant des bus matériels permettant la découverte comme l'USB, PCIe, etc. et grâce au fait que certaines choses dans l'architecture PC sont standardisés.
C'est ce qui rend possible le fait d'avoir un OS unique qui peut booter (sur PC) sur à peu près n'importe quelle configuration de carte graphique, RAM, cartes réseaux, etc.
Le device tree est quant à lui statique. C'est un humain qui va décrire dans le noyau les adresses, les bus et les pilotes à employer pour chaque carte ARM. Si tu fais une carte ARM un peu différente, tu devras écrire un nouveau device tree (éventuellement par surcharge) pour exprimer cette différence. Le noyau comme le SoC n'ont aucune idée sinon de ce qui doit être initialisé ou pas.
Le device tree permet une plus grande souplesse :
Grâce à la surcharge, c'est facile de définir un SoC et ensuite les cartes mères qui se basent dessus sans trop se répéter ;
Possibilité de le mettre à jour indépendamment du noyau ;
Possibilité de partager un device tree avec différents OS ou chargeurs de démarrage (cas de U-boot et Linux) ;
Si les cartes mères permettent (via des GPIO par exemple) de dire quelle carte mère tu utilises, tu peux facilement charger le device tree correspondant à la bonne carte. C'est cela qui autorise une image unique pour plusieurs cartes, le chargeur de démarrage peut sélectionner la bonne description du matériel en fonction d'un élément discriminant.
Mais ce dernier point n'a pas la force, robustesse et flexibilité d'un BIOS ou UEFI. Si la carte mère ne fournit rient pour choisir le bon device tree, tu es bien emmerdé.
Tu as une source pour dire ça ? Il me semblait avoir lu des études qui montraient le contraire : la majorité des gens ont installé 0 application sur les 12 derniers mois.
Sur le bureau je veux bien le croire, en général tu en as quelques unes seulement.
Sur mobile j'ai du mal à le croire, tous ceux que je connaissent (qui ne sont pas des technophiles) avec un smartphones installent / désinstallent régulièrement des applications. Dont des jeux.
Ce sont de très mauvais exemples, ces applications sont pré-installées sur les téléphones, il n'y a pas besoin de les installer pour les utiliser.
Peu importe, ils installent des applications pour tout. Wikipédia, Facebook, le magasin préféré (Amazon, Ikea, Auchan, Carrefour, etc.), Netflix, le site d'actu (Le Monde, Le Figaro, 20 minutes, NextINpact, etc.), l'application de la banque, du réseau de transport du coin voire national comme SNCF et j'en passe.
Pourtant ce que je te liste existe en version Web et souvent avec une interface mobile semblable à celle de l'application.
Le navigateur est bien moins utilisé sur mobile que sur les ordinateurs de bureau à cause de cela.
peu de gens se motivent à installer ton application native alors que cliquer sur un lien même madame michu sait faire
Ça va, les gens savent installer une application native quand ils veulent.
Je pourrais même te dire qu'avec les téléphones portables ils préfèrent installer une application native que d'utiliser le site web du service correspondant (tu crois que les gens consultent gmail ou Youtube depuis leur navigateur sur téléphone ?).
ton projet perso, tu le code et le maintiens sur Windows, MacOS, Linux, Android et iOS ou tu fais une version web
Car tu crois qu'un site web universellement compatible cela est aussi facile à faire que de pondre une application multiplateforme ?
Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.
L'API du web (ou l'écosystème de ses frameworks) est aussi très changeant, c'est un monde qui évolue vite contrairement à celui de l'OS. Donc niveau maintenance ce n'est pas une mince affaire que de gérer une application Web.
Ton site, étant donné globalement les infos qu'ils diffusent, je pense que tu peux oublier d'être une source sérieuse. EDF n'a jamais demandé de couper le Linky.
Premièrement ils disent que le Linky est déjà installé presque partout en France ce qui est une vaste blague.
Puis ils disent que le Linky consommerait 100 fois plus que les anciens compteurs (qui consommaient 1W). Cela signifierait que le Linky consommerait 100 W, juste pour calculer une puissance électrique et envoyer des informations ?
Je rappelle qu'un ordinateur portable, écran allumé et logiciels qui tournent, c'est entre 7 et 50 W de consommation. Il est évident que le Linky ne consomme pas 100 W. Cela serait plutôt de l'ordre de 2 W d'après les mesures.
Mais si on revenait en arrière (tout faire sur papier, puis transporter ces papiers par camion), ça serait pas pire ?
Difficile à estimer car simuler une Terre 2 sans Internet est délicat. :)
Techniquement tu as sans doute raison pour un envoi donné mais il ne faut pas oublier l'effet rebond dans l'équation. Comme c'est rapide, simple, non coûteux d'envoyer des documents par courriel, tu en envoies plus qu'avant quand c'était par courrier. Du coup cela compense sans doute voire surpasse la pollution engendrée par le passé avant.
Mais du coup ce n'est pas non plus une comparaison à usage identique, tu pollues plus mais en même temps tu envoies plus d'infos.
L'augmentation perpetuelle des besoins, ce n'est PAS de l'obsolescence programmée. L'obsolescence programmée ca serait par exemple une imprimante qui refuse d'imprimer après 10 000 pages (cas tout à fait fictif bien sur ). Ton ordinateur d'il y a 10 ans, si tu lui demandes de faire la meme chose qu'il y a 10 ans, il sait toujours faire, au pire au prix d'un petit nettoyage. Lui demander de répondre aux usages d'aujourd'hui et se plaindre d'obsolescence programmée, c'est du foutage de gueule.
Je ne peux qu'approuver, l'usage du terme obsolescence programmée est à 99% du temps très mal employé et c'est vraiment dommage car du coup on passe à côté de ce qui est problématique.
Une question qui me taraude : pourquoi les développeurs de GTK+ ont-ils créé gObject (en C, donc) plutôt qu'utilisé directement le C++ ?
Ne pas oublier que le C++ à l'époque n'était pas aussi populaire qu'aujourd'hui, d'ailleurs la première norme du C++ date de 1998 soit l'année de la sortie de GTK+ / GLib (mais le tout reposait sur des travaux sur GIMP qui existait depuis 1995).
Le C était aussi à l'époque le langage de référence de la programmation système dont ces couches font partie.
Et l'un des avantages de GTK+ / GLib je crois c'est qu'il supporte plus de ports vers d'autres langages (enfin, de bindings) que Qt. En particulier le C évidemment.
Et du coup, est-il plus facile de programmer en gObject (GTK+) qu'en C++ (Qt) ?
Qt est bien plus vaste que GTK+, il faudrait comparer à minima le couple GLib / GTK+ avec Qt et encore je crois que même là Qt reste plus complet.
À titre personnel je n'ai pas vraiment de préférence ayant fait les deux. Peut être que c'est plus naturel pour un développeur C++ de faire du Qt que pour un développeur C de faire du GTK+. Mais si tu as un développeur Python qui utilise les ports de chacun d'eux j'ignore s'il trouvera l'un plus agréable que l'autre.
Je pense que ce qui intéresse le plus les gens est plutôt la direction des projets. GTK+ reste piloté par GNOME et Linux en tête quand Qt est plus générique dans son orientation.
J'avais du mal à terminer le TP seul surtout le dernier jour, surcharge, dérivation, polymorphisme de classe qu'est ce que tu me racontes là … bon ok ça a l'air super puissant, mais qu'est ce que ça a l'air complexe … tout ça pour faire une calculatrice ça fait grosse artillerie tout de même … ça a l'air plus simple en Pascal tout de même …
Tu pointes je pense des difficultés de concept plus que des difficultés liées au C++ lui même. Après tous ces notions existent dans beaucoup de langages orientés objets. Si tu les as découvert avec le C++, c'est normal que la combinaison d'apprentissage OO + C++ t'aies paru lourd.
La difficulté du C++ ne réside pas dans les concepts que tu as pointé, mais plutôt :
Bibliothèque standard assez pauvre (du moins avant C++11) ce qui obligeait à réinventer la roue ou à utiliser les bibliothèques externes pour tout ;
Beaucoup trop de paradigmes dans un seul langage : impératif, objet, fonctionnel, méta-programmation avec les templates, etc. Du coup tu as une syntaxe très lourde et riche ce qui rend difficile sa maitrise ;
Compatible avec C (ou presque) ce qui pose un soucis d'héritage historique qui alourdit la sémantique et autorise un curieux mélange des genres qui est délicat pour le débutant ;
Souffre malheureusement d'un enseignement souvent porté sur C puis vers C++ en considérant les deux comme liés ce qui maintient les mauvaises habitudes. Il vaut mieux considérer le C++ comme différent du C et ne pas parler de la compatibilité syntaxique au début.
Cet ensemble de choses font du C++ comme difficile à maitriser. En général tu te spécialises dans un sous ensemble du C++.
Oui, pour moi le comptage de références (reference counting) est une forme de GC, mais une différence importante entre C++ et les langages managés est que, en C++, les constructions du langage ne t'imposent pas l'usage de shared_ptr ou d'un autre schéma automatique pour tracer les allocations mémoires, donc c'est facile de s'en passer et il y a des pratiques reconnues pour écrire du code où tout est géré manuellement. On peut aussi écrire du code qui n'utilise pas le GC dans un langage managé, mais c'est souvent beaucoup moins bien compris et donc plus délicat, et ça peut mal interagir avec le reste de l'écosystème logiciel.
Dans l'ensemble tu as raison, mais après ne pas oublier que ces pointeurs intelligents s'imposent de plus en plus car c'est considéré comme une bonne pratique.
C'est de mon point de vue de plus en plus rare de trouver des codes C++ avec une gestion complètement manuelle de la mémoire.
C++11 et C++14 sont disponibles maintenant presque partout, les compilateurs concernés sont suffisamment à jour. Car sinon on peut aussi parler de la vitesse d'évolution de Rust que tout le monde ne parvient pas à suivre.
Tant qu'à faire, autant utiliser le Rust, surtout que son côté fonctionnel (entre autres) rend les choses encore plus agréables (sum types, orienté expression, etc.).
On peut construire un type SUM en C++ assez facilement, ce n'est absolument pas un soucis, les "Variant" existent un peu partout.
Mais outre cela, il faut je pense arrêter de considérer le choix d'un langage uniquement sur ses qualités techniques. Car bon le C++ c'est aussi :
Une base de code existante énorme, qu'il faut maintenir et faire évoluer (la réécriture ça demande du temps) ;
C++ a beaucoup d'ingénieurs formés pour en écrire et en lire, Rust beaucoup moins (je ne me vois pas imposer en entreprise un langage qui n'est connu que de moi) ;
C++ a beaucoup de bibliothèques, que ce soit des trucs maisons ou de l'extérieur comme Qt ou Boost ;
C++ de par son âge a un écosystème d'outils pour le manipuler qui est assez large et ancien. Coder en C++ depuis CentOS 6 ne devrait pas être simple…
Le C++ est de mémoire disponible sur plus d'architectures matérielles (pour l'embarqué donc).
C'est ainsi pour tout langage, même le C a aussi son intérêt. Tout comme Python ou Ocaml. Aucun langage n'est parfait, même si certains sont d'un point de vue strictement technique meilleur, le reste compte aussi pour faire un choix.
C'est quoi un «criminel» ? Les armes de chasse sont responsables d'un nombre non-négligeable d’homicides , et dans la majorité des cas, un meurtrier est quelqu'un qui n'a aucun antécédent criminel avant de commettre son meurtre.
Je parle de ceux qui vont se procurer une arme dans le but de commettre un crime (ou d'être menaçant à l'égard d'autrui). Cela ne concerne pas ceux qui font de la chasse, ni ceux qui ont une arme pour s'entraîner au tir sportif.
Car à priori, ces armes là ce destinent à ce genre de public.
Certaines armes à feu (les plus faciles à se procurer en France, notamment : les armes de chasse) ne peuvent tirer qu'un ou deux coups max avant de devoir être rechargées.
Malgré la simplicité d'en avoir, c'est rarement utilisé par les criminels mais plutôt par des… chasseurs.
Pour moi, le principal danger de l'arme à feu est sa capacité à tuer efficacement à distance (c'est possible à l'arc ou à l'arbalète, mais c'est nettement plus aléatoire)
Les armes en plastiques sont globalement bien moins précis que leur équivalent en métal. Et comme ce sont des armes jetables, qui en plus d'une réalisation à l'autre change (une imprimante 3D n'a pas une précision infinie), pour s'entraîner ce n'est pas facile.
Suffit de voir dans les fusillades, même avec des armes traditionnelles, tuer n'est pas si évident. Cela demande un sacré entraînement pour viser juste. Alors qu'ils ont des armes automatiques et plus précis.
Je ne dis pas que ces armes ne sont pas dangereuses, mais il faut savoir analyser leur capacité opérationnelle aussi qui n'est pas si terrible que présenté en général.
Le principal danger d'une arme à feu est sa capacité à faire beaucoup de victimes (ou de tentatives du moins) en peu de temps. Si quelqu'un veut tuer une personne ou deux, il a pas mal de choix pour faire sans (couteau, objet contondant, etc.) ce qui le rend beaucoup moins pertinent.
Je suis contre les armes à feu hein et cela ne me plaît pas qu'on puisse faire ça. Mais ce n'est pas non plus l'apocalypse car cela reste vachement limité.
Les gouvernements vont enfin pouvoir arrêter de perdre de l'argent dans le contrôle des armes, tant au niveau de la production, que au niveau de la possession vu que ce sont des armes en polymère, non détectables par les détecteurs de métaux.
J'ai des souvenirs vagues de ces histoires d'armes en 3D. Si ce n'est pas terrible comme dispositif, ce n'est pas non plus équivalent à une arme à feu classique et sans contre mesure.
Déjà si l'arme n'est pas en métal (enfin le détonateur sera toujours en métal), les munitions le sont. C'est plus discret mais ça se détecte. De plus le fait que ce soit en plastique le rend peu résistant à la chaleur dégagée par la détonation. L'arme pourra tirer au maximum une poignée de coups de feu avant d'être inopérant. Bref, ça peut tuer, mais n'espère pas faire un massacre de masse en douce avec. Et pas de système automatique, faut tirer balle par balle en chargeant manuellement.
Et de souvenir, c'est aussi vachement moins précis. Bref, ce n'est pas si redoutable que cela.
Honnêtement, j'ai plus tendance à taper sur le C++ qui est devenu une énorme usine à gaz sans cohérence ; mais je respecte tout à fait le D et l'Ada.
Je ne suis pas un amoureux du C++, je suis plutôt un puriste du C. Mais je pense que le C++ va malgré tout dans la bonne voie, C++11 et C++14 ont apporté pas mal de choses pour corriger les erreurs de jeunesses.
Le C++ est en effet un langage très gros et incohérent avec le temps, tu as pas mal de paradigmes qui se baladent, des héritages parfois malvenus du C et de son histoire, etc.
Mais je pense qu'en fait il ne faudrait plus jamais évaluer le C++ dans son ensemble qui pour des raisons de compatibilités est en vrai une chose infâme. Si tu utilises le C++11 / C++14 en évitant les vieilleries (ce qui est largement possible, si tu n'utilises pas Qt du moins) tu gagnes largement en cohérence et en puissance. Si un projet mélange les vieilles structures avec les nouvelles, c'est en effet hideux, mais c'est à éviter en réalité.
Mais t'inquiète pas que la balance économique import/export est en notre faveur ;)
Cela ne signifie pas que la balance ne pourrait pas être encore plus avantageuse.
Cela pourrait aussi diminuer le besoin de centrales à énergie fossile, source de pollution et de coûts. Cela peut aussi simplifier le maintient du réseau (PACA et la Bretagne sont particulièrement vulnérables en cas de gros pics de consommation). Etc.
Bref, la situation peut être améliorée. Pourquoi s'en priver ?
La consommation totale = la production totale à tout instant (c'est en fait, un peu plus compliqué car il y a l'interconnexion des réseaux en Europe donc des entrées/sorties du réseau français à prendre en compte). Et on la connaît en temps réel. On la connaît aussi à des mailles plus fines comme les entrées/sorties du réseau de transport.
Pour apporter plus de précisions, une partie du contrôle se fait via la fréquence électrique du réseau (qui est aux alentours de 50 Hz en Europe). Si la fréquence monte, c'est que la production est trop élevée par rapport à la consommation. Et inversement par ailleurs. Grâce à un système asservi les turbines hydrauliques des centrales électriques ajustent donc l'apport en eau pour que la turbine tourne 50 fois par secondes idéalement. Mais en cas d'écart trop important, il faut en effet couper ou lancer des centrales (hydrauliques et gaz / pétrole / charbon pour les changements brusques).
Si vous avez suivi l'histoire de la fréquence bizarre du réseau électrique européen du au Kosovo en début d'année, on comprend mieux ainsi pourquoi ce n'est pas qu'un problème pour afficher l'heure sur nos microondes.
Avec la dérégulation du marché, il y a de nouveaux producteurs, commercialisateurs et de toutes façons ce n'est plus son job (en réalité, la transition ne s'est évidemment pas faite du jour au lendemain de l'ouverture du marché et a duré - dure encore ? - de longues années).
Tu oublies d'autres soucis.
Avec l’essor des énergies renouvelables, éolien et solaire, qui ne sont pas pilotables (Enedis ne peut pas contrôler ce qui est injecté dans le réseau) ils manquent des données pour correctement gérer le réseau très finement. Et avec le temps cela ne s'améliore pas. Puis Enedis aura des informations plus précises de la consommation localement ce qui améliorera les besoins réels de production et d'entretien.
D'ailleurs en Belgique le Linky sera imposé d'abord aux gros consommateurs (plus de 6000 Wh/an) et aux détenteurs de panneaux photovoltaïques pour cette raison.
ou d'achat de capacité d'effacement (usine qui diminue sa consommation, voire même des particuliers - je ne sais pas si ce genre de contrat existe encore)
J'ai connu le système EJP d'EDF qui en échange d'un tarif électrique intéressant le reste de l'année pouvait décider 20 jours par an entre novembre et avril des jours où le tarif serait prohibitif. Ces jour-là étaient annoncées de la veille au lendemain (site web ou téléphone) et dépendaient pour l'essentiel de la météo.
Du coup ces abonnés étaient incités à baisser drastiquement leur consommation ces jours là,jours à priori où le reste de la France en avait le plus besoin. Mais les nouveaux abonnements ne le proposent plus.
Puis en plus les appareils de froid modernes peuvent tenir plusieurs heures (si fermées) sans crainte pour le contenu. Même si cela entraîne une surconsommation globale, cela reste largement possible s'il le souhaite.
C'est accessoire par rapport à la discussion en cours, mais non, Enedis ne vend pas d'électricité.
Non, mais il fait payer l'usage de l'infrastructure à ceux qui en vendent. Si les frais d'Enedis montent, la facture sera répercutée aux producteurs comme EDF. Qui répercuteront cela sur les consommateurs.
À moins que Enedis ait une source cachée de financement, si ses frais montent, l'électricité sera plus chère.
Par ailleurs il n'y a pas de raison logique pour que le régulateur autorise un coût d'acheminement dépendant du coût de l'énergie transportée (ceci dit, c'est quand même peut-être le cas, à vérifier).
Non, mais les producteurs d'électricité eux le peuvent.
Pour info à l'époque où Linky était juste un projet des chercheur avait montrés qu'il était possible avec une bonne sensibilité d'acquisition de savoir quel film DVD une personne était en train de regarder chez elle (avec les variations de courant de la lentille laser), et cela malgré le frigo, le lave linge, les lampes …
En général ces études là se font dans un environnement ultra connu. Genre il a déjà échantillonné la consommation du lecteur DVD pour tous les films présents, il a les mesures exact du cycle du frigo, de l'ordinateur, etc. dans les conditions du logement (car un frigo consomme plus selon la température environnante).
C'est très semblables aux études qui permettent de récupérer pour un CPU et un ordinateur donné précis la clé de chiffrement via la mesure de la température.
En gros oui c'est possible mais si tu as déjà beaucoup d'infos sur les conditions du logement lui même. S'ils doivent effectuer ces tests dans un logement totalement inconnu (ce qui est à priori le cas quand on souhaite utiliser Linky comme vecteur d'espionnage) ils ne peuvent rien en retirer du tout car trop de choses leur sont inconnus pour extraire le signal utile.
À ce qu'il me semble, on voit clairement que c'est bien Enedis qui cherche à déployer cela partout, donc cela devrait être à eux de payer.
Mais tout se paye. Enedis ayant des ressources financières via la vente d'électricité. Si le coût monte, les abonnements électriques aussi.
Sauf certains cas bien identifiés, relevant de la solidarité (infrastructures publiques, assurances chômage et maladie par exemple), il est intolérable de faire payer autrui pour ce que l'on demande.
Et le réseau électrique détenu par l'État à 85% ce n'est pas une infrastructure publique par hasard ? Et les compteurs électriques intelligents font l'objet d'un vaste plan européen en la matière, on est clairement dans une démarche étatique en fait.
[^] # Re: embarqué ++
Posté par Renault (site web personnel) . En réponse à la dépêche Embedded Recipes 2018 : bientôt les inscriptions. Évalué à 10.
Embarqué ne signifie pas que tu as une puissance CPU minimale (ou même générale comme une RAM faiblarde). Cela signifie que tu peux rencontrer des contraintes très particuliers :
Typiquement il me paraîtrait absurde de considérer que le la machine faisant la conduite autonome d'une voiture ne soit pas considéré comme un système embarqué alors que pourtant le matériel utilisé est plus puissant que bon nombre de PCs en circulation. Mais les contraintes évoquées plus haut rend son développement assez différent que ce qui se fait pour un logiciel traditionnel sur PC.
Bref, les systèmes embarqués avec une faible puissance matérielle ne sont qu'une partie du domaine en question.
[^] # Re: Fragmentation risk
Posté par Renault (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 5.
Bien sûr, mais les cartes ARM du moins au début recouraient bien moins au PCIe et USB, préférant les bus non découvrables à la place. Alors que la plupart des composants dans le PC finissent par passer par ces bus à un moment ou un autre.
Cela change beaucoup sur la manière de prendre en charge le matériel.
Dans un cas c'est fourni par le constructeur lui même, dans l'autre c'est souvent au développeur de l'ajouter de son côté que ce soit au sein du noyau lui mee ou du chargeur de démarrage.
Je sais ce qu'est un device tree, j'en écris régulièrement.
Justement je mentionnais qu'en l'absence de device tree, c'est à dire si tu essayes de démarrer ton noyau avec juste ce qui est fourni de base par le constructeur de la carte, bah tu ne booteras pas ou en mode très dégradé. Car le constructeur ne te fourni pas en dur le device tree qui va bien, tu dois l'ajouter toi même quelque part.
Alors que quand je monte mon PC, je n'ai rien à faire. Je démarre mon noyau sans besoin d'ajouter une description du matériel avec mon système. Car cette découverte est faite et fourni automatiquement à mon système.
Cette différence paraît faible mais elle est en fait fondamentale ! C'est cette différence qui est la source de tous les mots et qui rend le device tree obligatoire. Et qui complique la conception d'une image ARM universelle.
L'OS au sens strict du terme se réfère en effet au système noyau + espace utilisateur quelque soit l'architecture. Mais il me semble pertinent de considérer le chargeur de démarrage dedans. Après tout Fedora, Windows ou macOS ont leur propre chargeur de démarrage qui est géré comme n'importe quel logiciel. Et d'autant plus que nous avons dans un cas (pour PC) un chargeur de démarrage universel (il fonctionne pour à peu ès n'importe quel PC sans soucis) et de l'autre nous avons un chargeur de démarrage (que ce soit U-boot ou autre) qui doit être particulier pour l'initialisation de base et sélectionner le bon device tree à envoyer au noyau.
[^] # Re: Fragmentation risk
Posté par Renault (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 3. Dernière modification le 27 août 2018 à 14:34.
Tu te méprends sur ce qu'est la découverte de périphérique.
Le BIOS / UEFI permet d'initialiser le système sans devoir le décrire, le tout automatiquement. Tout simplement en utilisant des bus matériels permettant la découverte comme l'USB, PCIe, etc. et grâce au fait que certaines choses dans l'architecture PC sont standardisés.
C'est ce qui rend possible le fait d'avoir un OS unique qui peut booter (sur PC) sur à peu près n'importe quelle configuration de carte graphique, RAM, cartes réseaux, etc.
Le device tree est quant à lui statique. C'est un humain qui va décrire dans le noyau les adresses, les bus et les pilotes à employer pour chaque carte ARM. Si tu fais une carte ARM un peu différente, tu devras écrire un nouveau device tree (éventuellement par surcharge) pour exprimer cette différence. Le noyau comme le SoC n'ont aucune idée sinon de ce qui doit être initialisé ou pas.
Le device tree permet une plus grande souplesse :
Mais ce dernier point n'a pas la force, robustesse et flexibilité d'un BIOS ou UEFI. Si la carte mère ne fournit rient pour choisir le bon device tree, tu es bien emmerdé.
[^] # Re: Puis une bascule chez SFR pour un vrai forfait internet illimité à 55€
Posté par Renault (site web personnel) . En réponse au journal LineageOS. Évalué à 5.
La fin de cette itinérance est déjà en cours, et va durer par phases jusqu'en 2020.
[^] # Re: Kotlin
Posté par Renault (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 6. Dernière modification le 02 août 2018 à 12:08.
Sur le bureau je veux bien le croire, en général tu en as quelques unes seulement.
Sur mobile j'ai du mal à le croire, tous ceux que je connaissent (qui ne sont pas des technophiles) avec un smartphones installent / désinstallent régulièrement des applications. Dont des jeux.
Peu importe, ils installent des applications pour tout. Wikipédia, Facebook, le magasin préféré (Amazon, Ikea, Auchan, Carrefour, etc.), Netflix, le site d'actu (Le Monde, Le Figaro, 20 minutes, NextINpact, etc.), l'application de la banque, du réseau de transport du coin voire national comme SNCF et j'en passe.
Pourtant ce que je te liste existe en version Web et souvent avec une interface mobile semblable à celle de l'application.
Le navigateur est bien moins utilisé sur mobile que sur les ordinateurs de bureau à cause de cela.
[^] # Re: Kotlin
Posté par Renault (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 6.
Ça va, les gens savent installer une application native quand ils veulent.
Je pourrais même te dire qu'avec les téléphones portables ils préfèrent installer une application native que d'utiliser le site web du service correspondant (tu crois que les gens consultent gmail ou Youtube depuis leur navigateur sur téléphone ?).
Car tu crois qu'un site web universellement compatible cela est aussi facile à faire que de pondre une application multiplateforme ?
Avec Qt tu peux faire une application sur les plateformes que tu cites. Pas sûr que cela demande plus de travail qu'une version full web.
L'API du web (ou l'écosystème de ses frameworks) est aussi très changeant, c'est un monde qui évolue vite contrairement à celui de l'OS. Donc niveau maintenance ce n'est pas une mince affaire que de gérer une application Web.
[^] # Re: Éteindre le compteur linky
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 4.
Ton site, étant donné globalement les infos qu'ils diffusent, je pense que tu peux oublier d'être une source sérieuse. EDF n'a jamais demandé de couper le Linky.
Premièrement ils disent que le Linky est déjà installé presque partout en France ce qui est une vaste blague.
Puis ils disent que le Linky consommerait 100 fois plus que les anciens compteurs (qui consommaient 1W). Cela signifierait que le Linky consommerait 100 W, juste pour calculer une puissance électrique et envoyer des informations ?
Je rappelle qu'un ordinateur portable, écran allumé et logiciels qui tournent, c'est entre 7 et 50 W de consommation. Il est évident que le Linky ne consomme pas 100 W. Cela serait plutôt de l'ordre de 2 W d'après les mesures.
Bref, commentaire poubelle.
[^] # Re: digital, vraiment ?
Posté par Renault (site web personnel) . En réponse au journal Pollution numérique. Évalué à 10.
Difficile à estimer car simuler une Terre 2 sans Internet est délicat. :)
Techniquement tu as sans doute raison pour un envoi donné mais il ne faut pas oublier l'effet rebond dans l'équation. Comme c'est rapide, simple, non coûteux d'envoyer des documents par courriel, tu en envoies plus qu'avant quand c'était par courrier. Du coup cela compense sans doute voire surpasse la pollution engendrée par le passé avant.
Mais du coup ce n'est pas non plus une comparaison à usage identique, tu pollues plus mais en même temps tu envoies plus d'infos.
Je ne peux qu'approuver, l'usage du terme obsolescence programmée est à 99% du temps très mal employé et c'est vraiment dommage car du coup on passe à côté de ce qui est problématique.
[^] # Re: GTK+ / gObject ?
Posté par Renault (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
Ne pas oublier que le C++ à l'époque n'était pas aussi populaire qu'aujourd'hui, d'ailleurs la première norme du C++ date de 1998 soit l'année de la sortie de GTK+ / GLib (mais le tout reposait sur des travaux sur GIMP qui existait depuis 1995).
Le C était aussi à l'époque le langage de référence de la programmation système dont ces couches font partie.
Et l'un des avantages de GTK+ / GLib je crois c'est qu'il supporte plus de ports vers d'autres langages (enfin, de bindings) que Qt. En particulier le C évidemment.
Qt est bien plus vaste que GTK+, il faudrait comparer à minima le couple GLib / GTK+ avec Qt et encore je crois que même là Qt reste plus complet.
À titre personnel je n'ai pas vraiment de préférence ayant fait les deux. Peut être que c'est plus naturel pour un développeur C++ de faire du Qt que pour un développeur C de faire du GTK+. Mais si tu as un développeur Python qui utilise les ports de chacun d'eux j'ignore s'il trouvera l'un plus agréable que l'autre.
Je pense que ce qui intéresse le plus les gens est plutôt la direction des projets. GTK+ reste piloté par GNOME et Linux en tête quand Qt est plus générique dans son orientation.
[^] # Re: Super facile !
Posté par Renault (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 8.
Tu pointes je pense des difficultés de concept plus que des difficultés liées au C++ lui même. Après tous ces notions existent dans beaucoup de langages orientés objets. Si tu les as découvert avec le C++, c'est normal que la combinaison d'apprentissage OO + C++ t'aies paru lourd.
La difficulté du C++ ne réside pas dans les concepts que tu as pointé, mais plutôt :
Cet ensemble de choses font du C++ comme difficile à maitriser. En général tu te spécialises dans un sous ensemble du C++.
[^] # Re: Phobie du GC
Posté par Renault (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 5.
Dans l'ensemble tu as raison, mais après ne pas oublier que ces pointeurs intelligents s'imposent de plus en plus car c'est considéré comme une bonne pratique.
C'est de mon point de vue de plus en plus rare de trouver des codes C++ avec une gestion complètement manuelle de la mémoire.
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 5.
C++17 n'est pas très répandu encore, et alors ?
C++11 et C++14 sont disponibles maintenant presque partout, les compilateurs concernés sont suffisamment à jour. Car sinon on peut aussi parler de la vitesse d'évolution de Rust que tout le monde ne parvient pas à suivre.
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 3.
Je voulais dire coder en Rust depuis CentOS 6.
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 7. Dernière modification le 27 juillet 2018 à 14:23.
On peut construire un type SUM en C++ assez facilement, ce n'est absolument pas un soucis, les "Variant" existent un peu partout.
Mais outre cela, il faut je pense arrêter de considérer le choix d'un langage uniquement sur ses qualités techniques. Car bon le C++ c'est aussi :
C'est ainsi pour tout langage, même le C a aussi son intérêt. Tout comme Python ou Ocaml. Aucun langage n'est parfait, même si certains sont d'un point de vue strictement technique meilleur, le reste compte aussi pour faire un choix.
Le culte du compromis en somme.
[^] # Re: Mouais
Posté par Renault (site web personnel) . En réponse au journal Des armes en Open-Source. Évalué à 3. Dernière modification le 27 juillet 2018 à 12:30.
Je parle de ceux qui vont se procurer une arme dans le but de commettre un crime (ou d'être menaçant à l'égard d'autrui). Cela ne concerne pas ceux qui font de la chasse, ni ceux qui ont une arme pour s'entraîner au tir sportif.
Car à priori, ces armes là ce destinent à ce genre de public.
[^] # Re: Mouais
Posté par Renault (site web personnel) . En réponse au journal Des armes en Open-Source. Évalué à 3.
Malgré la simplicité d'en avoir, c'est rarement utilisé par les criminels mais plutôt par des… chasseurs.
Les armes en plastiques sont globalement bien moins précis que leur équivalent en métal. Et comme ce sont des armes jetables, qui en plus d'une réalisation à l'autre change (une imprimante 3D n'a pas une précision infinie), pour s'entraîner ce n'est pas facile.
Suffit de voir dans les fusillades, même avec des armes traditionnelles, tuer n'est pas si évident. Cela demande un sacré entraînement pour viser juste. Alors qu'ils ont des armes automatiques et plus précis.
Je ne dis pas que ces armes ne sont pas dangereuses, mais il faut savoir analyser leur capacité opérationnelle aussi qui n'est pas si terrible que présenté en général.
[^] # Re: Mouais
Posté par Renault (site web personnel) . En réponse au journal Des armes en Open-Source. Évalué à 7.
Le principal danger d'une arme à feu est sa capacité à faire beaucoup de victimes (ou de tentatives du moins) en peu de temps. Si quelqu'un veut tuer une personne ou deux, il a pas mal de choix pour faire sans (couteau, objet contondant, etc.) ce qui le rend beaucoup moins pertinent.
Je suis contre les armes à feu hein et cela ne me plaît pas qu'on puisse faire ça. Mais ce n'est pas non plus l'apocalypse car cela reste vachement limité.
# Mouais
Posté par Renault (site web personnel) . En réponse au journal Des armes en Open-Source. Évalué à 7.
J'ai des souvenirs vagues de ces histoires d'armes en 3D. Si ce n'est pas terrible comme dispositif, ce n'est pas non plus équivalent à une arme à feu classique et sans contre mesure.
Déjà si l'arme n'est pas en métal (enfin le détonateur sera toujours en métal), les munitions le sont. C'est plus discret mais ça se détecte. De plus le fait que ce soit en plastique le rend peu résistant à la chaleur dégagée par la détonation. L'arme pourra tirer au maximum une poignée de coups de feu avant d'être inopérant. Bref, ça peut tuer, mais n'espère pas faire un massacre de masse en douce avec. Et pas de système automatique, faut tirer balle par balle en chargeant manuellement.
Et de souvenir, c'est aussi vachement moins précis. Bref, ce n'est pas si redoutable que cela.
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 7.
Je ne suis pas un amoureux du C++, je suis plutôt un puriste du C. Mais je pense que le C++ va malgré tout dans la bonne voie, C++11 et C++14 ont apporté pas mal de choses pour corriger les erreurs de jeunesses.
Le C++ est en effet un langage très gros et incohérent avec le temps, tu as pas mal de paradigmes qui se baladent, des héritages parfois malvenus du C et de son histoire, etc.
Mais je pense qu'en fait il ne faudrait plus jamais évaluer le C++ dans son ensemble qui pour des raisons de compatibilités est en vrai une chose infâme. Si tu utilises le C++11 / C++14 en évitant les vieilleries (ce qui est largement possible, si tu n'utilises pas Qt du moins) tu gagnes largement en cohérence et en puissance. Si un projet mélange les vieilles structures avec les nouvelles, c'est en effet hideux, mais c'est à éviter en réalité.
[^] # Re: Mouai...
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
Cela ne signifie pas que la balance ne pourrait pas être encore plus avantageuse.
Cela pourrait aussi diminuer le besoin de centrales à énergie fossile, source de pollution et de coûts. Cela peut aussi simplifier le maintient du réseau (PACA et la Bretagne sont particulièrement vulnérables en cas de gros pics de consommation). Etc.
Bref, la situation peut être améliorée. Pourquoi s'en priver ?
[^] # Re: Pourquoi doit-on payer ?
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 4.
Pour apporter plus de précisions, une partie du contrôle se fait via la fréquence électrique du réseau (qui est aux alentours de 50 Hz en Europe). Si la fréquence monte, c'est que la production est trop élevée par rapport à la consommation. Et inversement par ailleurs. Grâce à un système asservi les turbines hydrauliques des centrales électriques ajustent donc l'apport en eau pour que la turbine tourne 50 fois par secondes idéalement. Mais en cas d'écart trop important, il faut en effet couper ou lancer des centrales (hydrauliques et gaz / pétrole / charbon pour les changements brusques).
Si vous avez suivi l'histoire de la fréquence bizarre du réseau électrique européen du au Kosovo en début d'année, on comprend mieux ainsi pourquoi ce n'est pas qu'un problème pour afficher l'heure sur nos microondes.
Tu oublies d'autres soucis.
Avec l’essor des énergies renouvelables, éolien et solaire, qui ne sont pas pilotables (Enedis ne peut pas contrôler ce qui est injecté dans le réseau) ils manquent des données pour correctement gérer le réseau très finement. Et avec le temps cela ne s'améliore pas. Puis Enedis aura des informations plus précises de la consommation localement ce qui améliorera les besoins réels de production et d'entretien.
D'ailleurs en Belgique le Linky sera imposé d'abord aux gros consommateurs (plus de 6000 Wh/an) et aux détenteurs de panneaux photovoltaïques pour cette raison.
J'ai connu le système EJP d'EDF qui en échange d'un tarif électrique intéressant le reste de l'année pouvait décider 20 jours par an entre novembre et avril des jours où le tarif serait prohibitif. Ces jour-là étaient annoncées de la veille au lendemain (site web ou téléphone) et dépendaient pour l'essentiel de la météo.
Du coup ces abonnés étaient incités à baisser drastiquement leur consommation ces jours là,jours à priori où le reste de la France en avait le plus besoin. Mais les nouveaux abonnements ne le proposent plus.
[^] # Re: Tu extrapoles un peu vite
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 4.
Puis en plus les appareils de froid modernes peuvent tenir plusieurs heures (si fermées) sans crainte pour le contenu. Même si cela entraîne une surconsommation globale, cela reste largement possible s'il le souhaite.
[^] # Re: Pourquoi doit-on payer ?
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
Non, mais il fait payer l'usage de l'infrastructure à ceux qui en vendent. Si les frais d'Enedis montent, la facture sera répercutée aux producteurs comme EDF. Qui répercuteront cela sur les consommateurs.
À moins que Enedis ait une source cachée de financement, si ses frais montent, l'électricité sera plus chère.
Non, mais les producteurs d'électricité eux le peuvent.
[^] # Re: Tu extrapoles un peu vite
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 8.
En général ces études là se font dans un environnement ultra connu. Genre il a déjà échantillonné la consommation du lecteur DVD pour tous les films présents, il a les mesures exact du cycle du frigo, de l'ordinateur, etc. dans les conditions du logement (car un frigo consomme plus selon la température environnante).
C'est très semblables aux études qui permettent de récupérer pour un CPU et un ordinateur donné précis la clé de chiffrement via la mesure de la température.
En gros oui c'est possible mais si tu as déjà beaucoup d'infos sur les conditions du logement lui même. S'ils doivent effectuer ces tests dans un logement totalement inconnu (ce qui est à priori le cas quand on souhaite utiliser Linky comme vecteur d'espionnage) ils ne peuvent rien en retirer du tout car trop de choses leur sont inconnus pour extraire le signal utile.
[^] # Re: Pourquoi doit-on payer ?
Posté par Renault (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
Mais tout se paye. Enedis ayant des ressources financières via la vente d'électricité. Si le coût monte, les abonnements électriques aussi.
Et le réseau électrique détenu par l'État à 85% ce n'est pas une infrastructure publique par hasard ? Et les compteurs électriques intelligents font l'objet d'un vaste plan européen en la matière, on est clairement dans une démarche étatique en fait.