Depuis longtemps chez Archlinux et sans doute aussi Debian, le serveur X11 n'a rien de nécessaire pour les sessions graphiques. Pas besoin de serveur X11 pour faire tourner les sessions Gnome standard, juste de XWayland. Ca fait aussi des années que le bureau Enlightenment tourne sans problème en pur Wayland.
C'est le login manager GDM qui a encore le serveur X11 comme dépendance (plus pour longtemps), mais on n'est pas obligé de l'utiliser, celui d'Enlightenment marche très bien par exemple.
Merci pour ton observation. Du coup je m'interroge sur la notion de canal, et notamment de canal de transparence.
Si j'ai bien compris, un canal de transparence dans un format d'image, c'est une valeur de transparence appliquée qui s'applique à l'identique à tous les canaux de couleur.
Est-ce qu'on ne voudrait pas avoir une valeur de transparence par canal de couleur justement ? Comme pour un verre coloré, indiquer que ça ne lasse passer qu'une partie du rouge par exemple.
Je voudrais bien comprendre l'origine du problème.
Le néophyte que je suis et qui pense même avoir un cerveau ne connaît pas les contours politico-juridiques en jeu.
Vous qui avez lu autre chose, pouvez-vous vulgariser en quoi ce qui semble n'être qu'un changement d'adresse pourrait être une cause de soucis ?
Un bon vieux caquelon Le Creusot pourrait gagner un nouveau badge bouilloire, juste en lui mettant de l'eau à bouillir dedans :-)
L'approche a 4 maillons faibles : le prix du nécessaire gaz, la passoire thermique qu'est la cuisine vu les aérations non obturables obligatoires, le faible rendement pour chauffer un mug d'eau, et les émissions de CO2 de la méthode. Tout compris, cette bouilloire certes juste marche super bien mais seulement si on oublie ce qu'elle cause ;-)
Je ne suis pas sûr de comprendre la question.
Les éoliennes pivotent pour s'orienter dans la direction du vent en temps réel, il n'y a donc pas une orientation fixe comme sur certaines installations de panneaux solaires.
Le site éolien en question est un site sur terre (en anglais "onshore"), pas en mer ("offshore"). Les éoliennes elles-mêmes coûtent beaucoup moins cher à construire et surtout à installer et à relier à quelque chose.
L'aspect du coût "à installer et à relier" est assez clair, je ne détaille pas.
Pour le coût de l'éolienne en elle-même, ça mérite en effet une explication.
C'est lié à 2 choses :
1) en mer, il faut poser une technologie qui a besoin du moins d'entretien possible, alors que d'un autre côté
2) sur terre, on peut poser facilement des chose beaucoup plus balèzes.
Pour le 1) Pour les éoliennes en mer, la technologie "puissance++ et sans entretien" disponible est un alternateur à base d'aimants permanents en terres rares et tout, et pas de boîte de vitesse mécanique. Donc en plus des éoliennes, il faut prévoir des trucs de transformation balèzes du type convertisseur AC-DC-AC (certaines parties potentiellement mutualisées entre éoliennes). Là, les électroniciens voient directement qu'une telle bête prévue pour du méga-watt ça se facture en méga-euros (et je ne vous dis pas quand il y a pénurie de fournitures ! …), et en plus il faut le concevoir façon "sans entretien" aussi pour des dizaines d'années… en mer… ou prévoir une installation sur terre supplémentaire du coup parce que c'est plus facile, en tirant beaucoup plus de gros câbles… et ceux-là, moins il y en a, mieux on se porte, s'ils on réduit les coûts là-dessus en mettant un blindage électromagnétiques non adapté.
Alors que sur terre, on pose un gros alternateur sans aimants permanents (pareil que pour les barrages, centrales à gaz etc) dans une nacelle géante avec une boite de vitesses dedans. C'est hyper lourd mais c'est de la techno industrielle standard pas chère, éprouvée, qu'il suffit de venir graisser de temps en temps, dont les équipes qualifiées ne manquent pas. Mais au moins, pour les petits parcs, ça réduit énormément les installations de conversion AC-DC-AC pour au final injecter correctement de l'électricité à la bonne tension et à la bonne fréquence dans le réseau EDF local.
Pour le 2)
L'aspect contraintes d'installation est hyper important. Sur terre on peut installer des trucs beaucoup plus lourds, ou bien en plusieurs pièces qu'on peut prendre le temps d'assembler tranquillou en haut. Sur terre, on mobilise des équipes de grutiers et de monteurs de charpente comment le pays en a par milliers sur le territoire, et on peut décider du jour au lendemain que c'est bon on y va il n'y aura pas trop de vent ce jour-là. Alors qu'en mer, il faut prévoir la disponibilité de la barge-grue modèle top-moumoute dont le planning est prévu des années à l'avance… seules les grosses boîtes peuvent se lancer dans ce genre d'installation en prévoyant tout.
En mer il faut aussi étudier le fond vaseux longtemps pour concevoir l'ancrage du pylône qui conviendra (et qui potentiellement devra être enlevé une fois l'éolienne obsolète). Sur terre, les travaux de BTP impliqués sont assez standards, différentes techniques, des nouvelles arrivent de temps en temps. Exemple de lien pas spécialement récent, ni exhaustif, mais qui vous illustrera certaines installations avec des chiffres, et aussi une ouverture sur les autres défis en jeu pour verdir un poil plus l'éolien (terrestre) :
Côté subventions et tarifs réglementés, les périmètres réglementaires sont différents entre terre et mer pour tenir compte de ces différences de coût, et accompagner le développement des 2 filières sans en tuer une. Jamais tous ses oeufs dans le même panier !
Tout ça pour dire. Ca coûte tellement moins cher à poser sur terre, que la quantité de vent disponible sur site pour être rentable est beaucoup plus faible qu'en mer. L'éolienne est conçue pour le profil de vent disponible sur l'année. C'est pour ça que de nombreuses municipalités veulent et peuvent avoir leur petit parc éolien… surtout depuis que les tarifs de l'énergie en général ont explosé et que des coupures sont possibles. Si c'est installé en ayant prévu le coup (à financer en supplément !), alors un réseau local d'EDF peut continuer à tourner de façon autonome même si c'est tombé au niveau national, s'il y a une production suffisante locale. Là, on a dépassé le cadre de la seule exigence de rentabilité au sens purement pécunier !
Beaucoup de gens mal éclairés pourraient être d'un avis de pur dénigrement au vu d'un chiffre sorti de son contexte facile à affubler d'une interprétation biaisée.
Je vais essayer de donner un éclairage technique pragmatique.
Le fait que 90% du temps, on ne récupère pas la puissance max des éoliennes est parfaitement pris en compte à la conception du site et au dimensionnement des éoliennes qu'il convient d'y placer.
Un site qui produit la puissance nominale des éoliennes 10% du temps, c'est le Graal en termes de récupération d'énergie du vent. Les meilleurs sites permettent de générer dans les 30% de la puissance max des éoliennes, en moyenne sur une année.
Depuis que les "meilleurs" sites ont été équipés (comprenez, le bon rapport entre distance aux civilisations d'intérêt et puissance de vent récupérable), l'industrie et les politiques ciblent maintenant les sites suivants, et obtenir 20% de la puissance max des éoliennes sur l'année c'est pas mal.
N'oubliez pas que le vent est par nature hyper variable, et que les pointes de tempête même les fréquentes sont un danger de destruction autant qu'une opportunité de récupération. Les éoliennes doivent donc être sur-dimensionnées pour y résister, et parfois être arrêtées temporairement pour les protéger.
Il y a toujours des incitations étatiques pour installer des éoliennes, ne serait-ce que que pour réduire le montant des importations de pétrole/gaz (pré-covid et pré-guerre, ça cause un déficit commercial direct de 65 milliards d'euros à la France… par an). Cependant, l'éolien en tous cas en mer est rentable même sans ça - selon le site et selon les tarifs de l'électricité verte qu'on peut en tirer évidemment. Déjà pré-covid, un exploitant britannique se passait des subventions pour un de ses parcs et mer du Nord, parce qu'ainsi il n'était pas asservi à un régulateur étatique qui lui plafonne certains revenus. Je suppose qu'avec les prix de l'électricité actuels et futurs, il sabre le champagne tous les jours.
Sisi, sûrement, excellente suggestion d'ailleurs (je te plussoie).
Mais dans mon cas, une fois embarqué dans une voie, pas moyen de se mettre à réfléchir dans d'autres directions. Ca déconcentrerait. Et ça voudrait dire abandonner.
Et ce n'est que petit à petit qu'on s'enfonce. Ca part d'un rien, puis il suffira certainement juste d'un package de plus… ah merde une étape avant… etc.
Peut-être faut-il être passé par cette case pour que la prochaine fois on reconnaisse le schéma, et alors on saura ce qu'il en coûte, pour passer directement à essayer de recompiler par les sources.
L'auteur semble n'avoir vécu que la confrontation avec un paquet dont il n'avait pas la signature (à obtenir en mettant à jour archlinux-keyring comme mentionné).
Pour que les lecteurs ne se laissent pas endoctriner ovinement par des théologies mal avisées du style suivant
Réinstaller Arch, c'est être faible.
Voilà quelques points croustillants que le lecteur peut tenter de reproduire en devoir à la maison (ou à défaut, en prod) :
- mettre à jour d'abord pacman, parce que le passage récent à la compression zstd nécessite un pacman qui en connaît l'existence, on est sur de l'utilisateur qui essaie d'anticiper, en principe ça part d'une bonne idée
- le "nouveau" pacman installé ne se lance donc pas, parce que pas la bonne version de la lib c++ n'est pas (encore) installée.
- donc on ne peut pas réinstaller l'ancien package avec pacman -U, mais on peut encore contourner en le décompressant manuellement (commande à retrouver sous ce petit coup de stress) puis en l'installant manu militari avec sudo cp ./* /
- pour une solution possible, voir le paragraphe suivant (autres solutions possibles laissées en exercice)
Le top de ma connaissance, c'est quand le pacman de la machine lui-même ne reconnaît pas le format de son propre successeur compressé en zstd.
- donc, avec un autre ordi à côté, farfouiller dans Arch Linux Archive, choper les URL des paquets intermédiaires de pacman, jusqu'à en retrouver une qui n'est pas encore en zstd mais qui connaît ce format. La marge est très faible tant la transition a été rapide.
- et se retaper, pour chaque version de pacman candidate, la manip maintenant éprouvée de wget et sudo cp ./* /
- et pour chaque version de pacman candidate, déterminer et se procurer par les mêmes opérations les bonnes versions de toutes les libs dont il dépend (lib c, libs c++, libarchive, sans doute d'autres oubliées depuis liées au chiffrement)
- opérations qui vont immanquablement aboutir à un wget non fonctionnel parce que ses libs c++ à lui ne sont plus là (et wget n'est évidemment pas le seul outil non fonctionnel dans cette situation, plus rien ne tourne à part le bash du prompt actuel qu'il ne faut surtout pas fermer)
- entre autres solutions qui impliquent de s'être sorti du mauvais pas précédent (créativité laissée en exercice), on peut filouter pour que le noyau garde en RAM plusieurs versions des libc c++ simultanément parce que dépendances d'un outil quelquonque qu'on s'arrange pour qu'il tourne, et ainsi parvenir à ne pas se tuer (wget & Cie) dans le pied pendant qu'on fait les 400 coups
- à la suite de quoi on y arrive non sans avoir perdu la raison au passage (et pas que) et sans même s'être demandé si des fois il n'y aurait pas eu plus simple.
Je pense que, arrivé à ce point ou bien avant, celui qui ne réinstalle pas s'est fait léser à la conception sur l'attribution des rations de bon sens. Notez que réparer son install en rebootant sur clé USB est ici apparenté à une réinstall parce que… ben on a éteint la machine, amour-propre ruiné, comme un funambule tombé de sa corde qui pendouille sur sa ficelle de sécurité.
Ou bien, une fois la persévérance (/acharnement) couronnée de succès après une ou 2 nuits blanche l'écume aux lèvres, il réinstalle quand même parce que apprendre c'est (très) bien, mais à un moment il faut savoir arrêter une guerre limiter les conneries dans lesquelles on vit.
Nom d'un·e petit·e cheval·jument !
C'est un des articles les plus utiles du moment, pour moi. Développeur logiciel, faisant énormément de traitements et de générations de trucs divers par script, mais hélas pas assez de réflexe "ça existe forcément déjà en outil de base dans toutes les distros" pour éviter de se palucher le formatage des sorties.
Et merci pour tous les exemples :-)
Merci pour ces infos sur openFPGALoader.
Je connaissais son existence, mais je me suis toujours demandé quelles sont les différences avec son frère xc3sprog (lien en fin de message). Différences de concept ? d'architecture ? de mainteneur ?
Pour ceux et celles qui se posent la question, on dirait que:
- openFPGALoader supporte bien mieux les différents vendeurs de FPFA
- xc3sprog supporte beaucoup plus de références de FPGA Xilinx, mais le projet ne semble plus actif
Autres différences connues ?
Merci pour la narration sur ce croustillant problème :-)
Je reste un peu perplexifié, parce que si on revient à l'introduction, on nous lance à la criée du problème LLVM, qui aurait été corrigé de surcoît.
Et cependant, le contenu décrit sur une situation courante de déficience cognitive momentanée suite à l'utilisation de GCC, alors même que ce dernier n'y est pour rien !
Est-ce un fourchage de clavier, ou un degré supplémentaire d'exercice de compréhension laissé au lecteur ?
Vu la criticité du sujet, analyser et valider la dizaine de pages du papier devrait être du gâteau pour des mathématiciens standards ou aguerris. Chose qui ne manque pas sur la planète ! (mais je n'en fais pas partie, hein)
Si c'était vrai, qu'on sache factoriser les grands nombres en temps et mémoire raisonnable, alors ça aurait fait (ou dû faire ?) un foin monstre en peu de temps après sa publication.
Ou alors le papier est un sérieux candidat pour remporter un concours d'offuscation de papier, et aucun des lecteurs candidats à en comprendre la teneur n'a osé dire qu'il ne comprenait rien ;-)
Mais admettons que c'est de la bonne théorie et que personne de pertinent n'est tombé dessus.
Même là, c'est quand même difficile à gober que l'auteur n'aurait pas tenté la pratique et implémenté le tout pour confirmer…
Papier compréhensible ou pas, un exemple d'implémentation fonctionnel est encore la meilleure preuve de validité :-)
Je n'ai pas le temps de bricoler des images pour l'instant…
Ce n'est un simple ET analogique avec 2 pass transistors en série, ici on a une porte logique qui réamplifie le signal.
Pour faire plus précis, on peut dire que chaque "fil" rouge est la grille d'un transistor (un même fil peut commander plusieurs grilles, comme c'est le cas sur l'image avec à chaque fois une grille en zone rouge (transistors type P) et en zone verte (transistors type N).
Ici on fonctionne en tout-ou-rien, donc cette grille est en gros la commande d'un interrupteur logique qui autorise ou interdit au courant de passer entre les zones à gauche et à droite de ces grilles.
Source et drain ne sont pas différenciés dans ce circuit simplifié. Par exemple dans le transistor au-dessus de A, le courant passe de gauche à droite, et dans celui au-dessus de B le courant passe de droite à gauche.
Posté par marzoul .
En réponse au journal Le filtrage à la source.
Évalué à 7.
Dernière modification le 24 avril 2018 à 23:01.
Le point de vue optimiste c'est que tout pourrait être mis en place de façon pertinente et juste, oui.
D'un autre côté, quand du code libre se fera jeter parce qu'un système automatisé aura décidé que ça ressemblait trop à du code protégé, on aura quoi comme recours ? Envoyer un mail et se battre des semaines ? Le code d'un logiciel entier ça se fait "protéger" pour 250 euros à l'APP, rien à justifier, on envoie le code et le chèque, point. Le code inclura probablement des portions standard pompées sur internet par un collaborateur négligent. Et des portions qu'on aurait du mal à coder de façon différente de toutes façons, du parcours de liste ou de graphe par exemple.
Quelle est la granularité du système de filtrage ? Comment il va reconnaître une portion "simple" d'une portion "complexe" ? Si on lui apprend à détecter de la similarité incluant un simple renommage de variables on va vite retomber sur les algorithmes qu'on aurait du mal à écrire autrement. Il y aura de l'intelligence artificielle dans le tout, aussi. Massivement automatisé, difficile à contrôler, il y a toujours des faux positifs. Potentiellement beaucoup, vu la quantité de code propriétaire versus la quantité de code libre.
Du coup, avec la dissymétrie des informations (on ne verra jamais le code proprio, mais le système de filtrage le voit), la dissymétrie de qui est scanné pour plagiat et antériorité, l'accès aux specs techniques du système filtrage, le fait que les petites gens capituleront massivement (pas le choix) devant le jugement des missi dominici des ayants droit, et que ni les ayant "droit" ni les plateformes n'auront de sanction alors que se faire refuser la publication de son travail ça peut être démoralisant voir bloquant pour son travail, on a de bonnes raisons de s'inquiéter. Pas d'avoir peur quand même, mais de s'inquiéter. Ce qui n'inquiète pas du tout les lobbys malheureusement.
Où peut-on trouver des cas de repompage de code propriétaire dans du code libre ? En quoi sont-ils suffisamment fréquents pour justifier la mise en place de tout ça ?
Sera-t-il possible de prendre des mesures pour éviter que des "coding trolls" fassent protéger des portions de code simples et/ou génériques ?
Je rêve ou personne ne se pose la question clé : quel est exactement le CPU "Xeon" qui a été utilisé pour la mesure ? Il y en a des pléthores avec des perfs extrêmement variées, alors qu'il n'y a qu'un Qualcomm centriQ, qui est très récent et comme par hasard positionné low-power-toute.
Combien de coeurs, combien inutilisés, quel âge, déclinaison hi-perf ou low-power, quid du reste de la carte mère, etc.
Qu'on prenne le dernier CPU Intel pour laptop par exemple, en série ultra-low power, et ça pourrait surprendre des gens.
Je n'ai de parti pris arbitraire pour aucun fabricant. Mais ces annonces populistes où on joue surtout à ne pas donner les informations importantes me donneront toujours des haut-le-coeur.
Pour compléter, je voudrais dire qu'il faut instaurer pour les parlementaires un devoir d'écoute, et une interdiction de mener des négociations à huis clos avec qui que ce soit.
Tout membre du peuple a le droit de connaître les agissements de ceux pour qui il a voté. Et on devrait beaucoup plus avoir le pouvoir d'exiger la démission et l'inéligibilité de quiconque se démarque par des agissements inacceptables selon ces points. Certaines des nos éminences se seraient fait depuis longtemps vertement limoger en Norvège, Suède ou Finlande.
Merci pour ton journal. Ça rejoint fortement ma propre opinion de choses.
Le fonctionnement par assemblée de représentants est un héritage des temps anciens où les moyens de communication étaient limités. La seule solution pour gouverner était donc d'élire des représentants et de les envoyer siéger physiquement.
De nos jours, oui les minorités sont peu écoutées. Mais on oublie que les majorités aussi : elles sont piétinées par les carriéristes qui mentent sans vergogne afin de se faire élire et dont les actions et les discours sont purement électoralistes.
Il y a 2 causes à cela : les postes politiques sont trop payés, et la sensation de pouvoir trop grande.
Pour une soit-disant démocratie, le simple fait de pouvoir interdire un référendum est une aberration. Or, c'est le procédé de base pour faire remonter au gouvernement les souhaits du peuple. En Suisse, beaucoup plus de choses sont votées qu'en France. J'aimerais bien que le Parti Pirate parvienne, même si c'est lent, à faire rentrer dans les moeurs qu'écouter le peuple point par point est infiniment préférable à élire selon les programmes des partis politiques construits le plus artificiellement du monde. On ne peut pas faire un pays purement de droite, de gauche ou purement vert. Il faut une juste dose de chaque point selon les besoins. Et surtout, il faut des moyens de communication permettant d'éviter aux lobbies de gouverner à notre place…
J'aimerais beaucoup que le Parti Pirate parvienne à faire rentrer cela dans les moeurs. Même si c'est lent.
# D'autres avant...
Posté par marzoul . En réponse au journal Les distributions Linux abandonnent X11 pour Wayland. Évalué à 4.
Depuis longtemps chez Archlinux et sans doute aussi Debian, le serveur X11 n'a rien de nécessaire pour les sessions graphiques. Pas besoin de serveur X11 pour faire tourner les sessions Gnome standard, juste de XWayland. Ca fait aussi des années que le bureau Enlightenment tourne sans problème en pur Wayland.
C'est le login manager GDM qui a encore le serveur X11 comme dépendance (plus pour longtemps), mais on n'est pas obligé de l'utiliser, celui d'Enlightenment marche très bien par exemple.
[^] # Re: WebP sans perte et exact - Et la transparence par couleur ?
Posté par marzoul . En réponse à la dépêche Des formats d'image. Évalué à 4.
Merci pour ton observation. Du coup je m'interroge sur la notion de canal, et notamment de canal de transparence.
Si j'ai bien compris, un canal de transparence dans un format d'image, c'est une valeur de transparence appliquée qui s'applique à l'identique à tous les canaux de couleur.
Est-ce qu'on ne voudrait pas avoir une valeur de transparence par canal de couleur justement ? Comme pour un verre coloré, indiquer que ça ne lasse passer qu'une partie du rouge par exemple.
# Vulgarisation ?
Posté par marzoul . En réponse au journal Le Président de la Cour du Brevet Unitaire décide tout seul de réécrire le traité comme un dictateur. Évalué à 8.
Bonjour,
Je voudrais bien comprendre l'origine du problème.
Le néophyte que je suis et qui pense même avoir un cerveau ne connaît pas les contours politico-juridiques en jeu.
Vous qui avez lu autre chose, pouvez-vous vulgariser en quoi ce qui semble n'être qu'un changement d'adresse pourrait être une cause de soucis ?
Merci
# Brillante dépêche !
Posté par marzoul . En réponse à la dépêche Nouveautés du langage C dans sa prochaine version C23. Évalué à 5.
Des mercis par pelletées !
[^] # Re: à fond la forme / Le Creuset
Posté par marzoul . En réponse au journal NixOS ou comment j'ai rendu mes machines interchangeables et ennuyeuses. Évalué à 3.
Oups, c'est Le CreusEt, pas le CreusOt, pardon.
[^] # Re: à fond la forme / Le Creusot
Posté par marzoul . En réponse au journal NixOS ou comment j'ai rendu mes machines interchangeables et ennuyeuses. Évalué à 2.
Un bon vieux caquelon Le Creusot pourrait gagner un nouveau badge bouilloire, juste en lui mettant de l'eau à bouillir dedans :-)
L'approche a 4 maillons faibles : le prix du nécessaire gaz, la passoire thermique qu'est la cuisine vu les aérations non obturables obligatoires, le faible rendement pour chauffer un mug d'eau, et les émissions de CO2 de la méthode. Tout compris, cette bouilloire certes juste marche super bien mais seulement si on oublie ce qu'elle cause ;-)
[^] # Re: orientation
Posté par marzoul . En réponse au journal Foehn - Exploration des données SCADA du parc éolien de la Haute Borne. Évalué à 2.
Je ne suis pas sûr de comprendre la question.
Les éoliennes pivotent pour s'orienter dans la direction du vent en temps réel, il n'y a donc pas une orientation fixe comme sur certaines installations de panneaux solaires.
[^] # Re: Ce n'est pas sous-exploité, tout va bien
Posté par marzoul . En réponse au journal Foehn - Exploration des données SCADA du parc éolien de la Haute Borne. Évalué à 10.
Le site éolien en question est un site sur terre (en anglais "onshore"), pas en mer ("offshore"). Les éoliennes elles-mêmes coûtent beaucoup moins cher à construire et surtout à installer et à relier à quelque chose.
L'aspect du coût "à installer et à relier" est assez clair, je ne détaille pas.
Pour le coût de l'éolienne en elle-même, ça mérite en effet une explication.
C'est lié à 2 choses :
1) en mer, il faut poser une technologie qui a besoin du moins d'entretien possible, alors que d'un autre côté
2) sur terre, on peut poser facilement des chose beaucoup plus balèzes.
Pour le 1) Pour les éoliennes en mer, la technologie "puissance++ et sans entretien" disponible est un alternateur à base d'aimants permanents en terres rares et tout, et pas de boîte de vitesse mécanique. Donc en plus des éoliennes, il faut prévoir des trucs de transformation balèzes du type convertisseur AC-DC-AC (certaines parties potentiellement mutualisées entre éoliennes). Là, les électroniciens voient directement qu'une telle bête prévue pour du méga-watt ça se facture en méga-euros (et je ne vous dis pas quand il y a pénurie de fournitures ! …), et en plus il faut le concevoir façon "sans entretien" aussi pour des dizaines d'années… en mer… ou prévoir une installation sur terre supplémentaire du coup parce que c'est plus facile, en tirant beaucoup plus de gros câbles… et ceux-là, moins il y en a, mieux on se porte, s'ils on réduit les coûts là-dessus en mettant un blindage électromagnétiques non adapté.
Alors que sur terre, on pose un gros alternateur sans aimants permanents (pareil que pour les barrages, centrales à gaz etc) dans une nacelle géante avec une boite de vitesses dedans. C'est hyper lourd mais c'est de la techno industrielle standard pas chère, éprouvée, qu'il suffit de venir graisser de temps en temps, dont les équipes qualifiées ne manquent pas. Mais au moins, pour les petits parcs, ça réduit énormément les installations de conversion AC-DC-AC pour au final injecter correctement de l'électricité à la bonne tension et à la bonne fréquence dans le réseau EDF local.
Pour le 2)
L'aspect contraintes d'installation est hyper important. Sur terre on peut installer des trucs beaucoup plus lourds, ou bien en plusieurs pièces qu'on peut prendre le temps d'assembler tranquillou en haut. Sur terre, on mobilise des équipes de grutiers et de monteurs de charpente comment le pays en a par milliers sur le territoire, et on peut décider du jour au lendemain que c'est bon on y va il n'y aura pas trop de vent ce jour-là. Alors qu'en mer, il faut prévoir la disponibilité de la barge-grue modèle top-moumoute dont le planning est prévu des années à l'avance… seules les grosses boîtes peuvent se lancer dans ce genre d'installation en prévoyant tout.
En mer il faut aussi étudier le fond vaseux longtemps pour concevoir l'ancrage du pylône qui conviendra (et qui potentiellement devra être enlevé une fois l'éolienne obsolète). Sur terre, les travaux de BTP impliqués sont assez standards, différentes techniques, des nouvelles arrivent de temps en temps. Exemple de lien pas spécialement récent, ni exhaustif, mais qui vous illustrera certaines installations avec des chiffres, et aussi une ouverture sur les autres défis en jeu pour verdir un poil plus l'éolien (terrestre) :
https://decrypterlenergie.org/betonisation-et-artificialisation-des-terres-quelle-contribution-de-leolien
Côté subventions et tarifs réglementés, les périmètres réglementaires sont différents entre terre et mer pour tenir compte de ces différences de coût, et accompagner le développement des 2 filières sans en tuer une. Jamais tous ses oeufs dans le même panier !
https://www.ecologie.gouv.fr/eolien-terrestre
Tout ça pour dire. Ca coûte tellement moins cher à poser sur terre, que la quantité de vent disponible sur site pour être rentable est beaucoup plus faible qu'en mer. L'éolienne est conçue pour le profil de vent disponible sur l'année. C'est pour ça que de nombreuses municipalités veulent et peuvent avoir leur petit parc éolien… surtout depuis que les tarifs de l'énergie en général ont explosé et que des coupures sont possibles. Si c'est installé en ayant prévu le coup (à financer en supplément !), alors un réseau local d'EDF peut continuer à tourner de façon autonome même si c'est tombé au niveau national, s'il y a une production suffisante locale. Là, on a dépassé le cadre de la seule exigence de rentabilité au sens purement pécunier !
# Ce n'est pas sous-exploité, tout va bien
Posté par marzoul . En réponse au journal Foehn - Exploration des données SCADA du parc éolien de la Haute Borne. Évalué à 10. Dernière modification le 19 octobre 2022 à 00:19.
Super ton "truc bricolé" ! :-)
Beaucoup de gens mal éclairés pourraient être d'un avis de pur dénigrement au vu d'un chiffre sorti de son contexte facile à affubler d'une interprétation biaisée.
Je vais essayer de donner un éclairage technique pragmatique.
Le fait que 90% du temps, on ne récupère pas la puissance max des éoliennes est parfaitement pris en compte à la conception du site et au dimensionnement des éoliennes qu'il convient d'y placer.
Un site qui produit la puissance nominale des éoliennes 10% du temps, c'est le Graal en termes de récupération d'énergie du vent. Les meilleurs sites permettent de générer dans les 30% de la puissance max des éoliennes, en moyenne sur une année.
Depuis que les "meilleurs" sites ont été équipés (comprenez, le bon rapport entre distance aux civilisations d'intérêt et puissance de vent récupérable), l'industrie et les politiques ciblent maintenant les sites suivants, et obtenir 20% de la puissance max des éoliennes sur l'année c'est pas mal.
N'oubliez pas que le vent est par nature hyper variable, et que les pointes de tempête même les fréquentes sont un danger de destruction autant qu'une opportunité de récupération. Les éoliennes doivent donc être sur-dimensionnées pour y résister, et parfois être arrêtées temporairement pour les protéger.
Il y a toujours des incitations étatiques pour installer des éoliennes, ne serait-ce que que pour réduire le montant des importations de pétrole/gaz (pré-covid et pré-guerre, ça cause un déficit commercial direct de 65 milliards d'euros à la France… par an). Cependant, l'éolien en tous cas en mer est rentable même sans ça - selon le site et selon les tarifs de l'électricité verte qu'on peut en tirer évidemment. Déjà pré-covid, un exploitant britannique se passait des subventions pour un de ses parcs et mer du Nord, parce qu'ainsi il n'était pas asservi à un régulateur étatique qui lui plafonne certains revenus. Je suppose qu'avec les prix de l'électricité actuels et futurs, il sabre le champagne tous les jours.
[^] # Re: Calimero !
Posté par marzoul . En réponse au journal Comment acquérir un poil de barbe en plus : mettre à jour une vieille Archlinux. Évalué à 1.
Sisi, sûrement, excellente suggestion d'ailleurs (je te plussoie).
Mais dans mon cas, une fois embarqué dans une voie, pas moyen de se mettre à réfléchir dans d'autres directions. Ca déconcentrerait. Et ça voudrait dire abandonner.
Et ce n'est que petit à petit qu'on s'enfonce. Ca part d'un rien, puis il suffira certainement juste d'un package de plus… ah merde une étape avant… etc.
Peut-être faut-il être passé par cette case pour que la prochaine fois on reconnaisse le schéma, et alors on saura ce qu'il en coûte, pour passer directement à essayer de recompiler par les sources.
# Calimero !
Posté par marzoul . En réponse au journal Comment acquérir un poil de barbe en plus : mettre à jour une vieille Archlinux. Évalué à 10. Dernière modification le 06 septembre 2022 à 21:10.
L'auteur semble n'avoir vécu que la confrontation avec un paquet dont il n'avait pas la signature (à obtenir en mettant à jour
archlinux-keyringcomme mentionné).Pour que les lecteurs ne se laissent pas endoctriner ovinement par des théologies mal avisées du style suivant
Voilà quelques points croustillants que le lecteur peut tenter de reproduire en devoir à la maison (ou à défaut, en prod) :
- mettre à jour d'abord pacman, parce que le passage récent à la compression
zstdnécessite un pacman qui en connaît l'existence, on est sur de l'utilisateur qui essaie d'anticiper, en principe ça part d'une bonne idée- le "nouveau" pacman installé ne se lance donc pas, parce que pas la bonne version de la lib c++ n'est pas (encore) installée.
- donc on ne peut pas réinstaller l'ancien package avec
pacman -U, mais on peut encore contourner en le décompressant manuellement (commande à retrouver sous ce petit coup de stress) puis en l'installant manu militari avecsudo cp ./* /- pour une solution possible, voir le paragraphe suivant (autres solutions possibles laissées en exercice)
Le top de ma connaissance, c'est quand le pacman de la machine lui-même ne reconnaît pas le format de son propre successeur compressé en
zstd.- donc, avec un autre ordi à côté, farfouiller dans Arch Linux Archive, choper les URL des paquets intermédiaires de pacman, jusqu'à en retrouver une qui n'est pas encore en
zstdmais qui connaît ce format. La marge est très faible tant la transition a été rapide.- et se retaper, pour chaque version de pacman candidate, la manip maintenant éprouvée de
wgetetsudo cp ./* /- et pour chaque version de pacman candidate, déterminer et se procurer par les mêmes opérations les bonnes versions de toutes les libs dont il dépend (lib c, libs c++, libarchive, sans doute d'autres oubliées depuis liées au chiffrement)
- opérations qui vont immanquablement aboutir à un
wgetnon fonctionnel parce que ses libs c++ à lui ne sont plus là (etwgetn'est évidemment pas le seul outil non fonctionnel dans cette situation, plus rien ne tourne à part lebashdu prompt actuel qu'il ne faut surtout pas fermer)- entre autres solutions qui impliquent de s'être sorti du mauvais pas précédent (créativité laissée en exercice), on peut filouter pour que le noyau garde en RAM plusieurs versions des libc c++ simultanément parce que dépendances d'un outil quelquonque qu'on s'arrange pour qu'il tourne, et ainsi parvenir à ne pas se tuer (
wget& Cie) dans le pied pendant qu'on fait les 400 coups- à la suite de quoi on y arrive non sans avoir perdu la raison au passage (et pas que) et sans même s'être demandé si des fois il n'y aurait pas eu plus simple.
Je pense que, arrivé à ce point ou bien avant, celui qui ne réinstalle pas s'est fait léser à la conception sur l'attribution des rations de bon sens. Notez que réparer son install en rebootant sur clé USB est ici apparenté à une réinstall parce que… ben on a éteint la machine, amour-propre ruiné, comme un funambule tombé de sa corde qui pendouille sur sa ficelle de sécurité.
Ou bien, une fois la persévérance (/acharnement) couronnée de succès après une ou 2 nuits blanche l'écume aux lèvres, il réinstalle quand même parce que apprendre c'est (très) bien, mais à un moment il faut savoir
arrêter une guerrelimiter les conneries dans lesquelles on vit.# La dépêche aussi est super !
Posté par marzoul . En réponse à la dépêche Inkscape 1.2 vient de sortir avec tout plein de bonnes choses dedans. Évalué à 7.
Il y a au moins autant de travail dans cette super dépêche que dans les (super) développements qui ont été faits juste pour qu'elle puisse exister :-D
# Super utile !
Posté par marzoul . En réponse au journal rétrospective sur la mise en page en console. Évalué à 5.
Nom d'un·e petit·e cheval·jument !
C'est un des articles les plus utiles du moment, pour moi. Développeur logiciel, faisant énormément de traitements et de générations de trucs divers par script, mais hélas pas assez de réflexe "ça existe forcément déjà en outil de base dans toutes les distros" pour éviter de se palucher le formatage des sorties.
Et merci pour tous les exemples :-)
# Différences par rapport à xc3sprog
Posté par marzoul . En réponse à la dépêche Sortie de la version 0.6.0 du configurateur de FPGA openFPGALoader. Évalué à 4. Dernière modification le 18 décembre 2021 à 13:15.
Merci pour ces infos sur openFPGALoader.
Je connaissais son existence, mais je me suis toujours demandé quelles sont les différences avec son frère xc3sprog (lien en fin de message). Différences de concept ? d'architecture ? de mainteneur ?
Pour ceux et celles qui se posent la question, on dirait que:
- openFPGALoader supporte bien mieux les différents vendeurs de FPFA
- xc3sprog supporte beaucoup plus de références de FPGA Xilinx, mais le projet ne semble plus actif
Autres différences connues ?
https://github.com/UweBonnes/xc3sprog
[^] # Re: Plutôt construire un paquet
Posté par marzoul . En réponse au journal Compiler ses logiciels, exemple avec Geany 1.37.1. Évalué à 4.
J'ajoute quelques précisions pour Archlinux,
pour ceux qui ne sont pas encore allés regarder comment les choses sont faites ;-)
Le lien du package construit à partir des sources est le suivant :
https://aur.archlinux.org/packages/geany-git/
Le fichier PKGBUILD correspondant est consultable directement depuis la page, ou bien avec le lien suivant :
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=geany-git
Pour le package officiel correspondant à des versions stables, le lien est le suivant :
https://archlinux.org/packages/community/x86_64/geany/
Le fichier PKGBUILD correspondant est consultable directement depuis la page, ou bien avec le lien suivant :
https://github.com/archlinux/svntogit-community/blob/packages/geany/trunk/PKGBUILD
Bonne soirée !
# Et LLVM dans tout ça ?
Posté par marzoul . En réponse au journal Alignement chaotic neutre. Évalué à 10.
Merci pour la narration sur ce croustillant problème :-)
Je reste un peu perplexifié, parce que si on revient à l'introduction, on nous lance à la criée du problème LLVM, qui aurait été corrigé de surcoît.
Et cependant, le contenu décrit sur une situation courante de déficience cognitive momentanée suite à l'utilisation de GCC, alors même que ce dernier n'y est pour rien !
Est-ce un fourchage de clavier, ou un degré supplémentaire d'exercice de compréhension laissé au lecteur ?
# Code ?
Posté par marzoul . En réponse au journal Schnorr aurait-il cassé RSA ?. Évalué à 3. Dernière modification le 04 mars 2021 à 23:31.
Vu la criticité du sujet, analyser et valider la dizaine de pages du papier devrait être du gâteau pour des mathématiciens standards ou aguerris. Chose qui ne manque pas sur la planète ! (mais je n'en fais pas partie, hein)
Si c'était vrai, qu'on sache factoriser les grands nombres en temps et mémoire raisonnable, alors ça aurait fait (ou dû faire ?) un foin monstre en peu de temps après sa publication.
Ou alors le papier est un sérieux candidat pour remporter un concours d'offuscation de papier, et aucun des lecteurs candidats à en comprendre la teneur n'a osé dire qu'il ne comprenait rien ;-)
Mais admettons que c'est de la bonne théorie et que personne de pertinent n'est tombé dessus.
Même là, c'est quand même difficile à gober que l'auteur n'aurait pas tenté la pratique et implémenté le tout pour confirmer…
Papier compréhensible ou pas, un exemple d'implémentation fonctionnel est encore la meilleure preuve de validité :-)
# Excellent !
Posté par marzoul . En réponse à la dépêche Des nombres aléatoires dans le noyau Linux. Évalué à 5.
Un bel article comme celui-là, c'est vraiment la classe. Merci tout plein :-)
[^] # Re: L'image est une porte AND
Posté par marzoul . En réponse au journal Conception d’un circuit intégré avec Qflow. Évalué à 3. Dernière modification le 17 novembre 2019 à 00:12.
Je n'ai pas le temps de bricoler des images pour l'instant…
Ce n'est un simple ET analogique avec 2 pass transistors en série, ici on a une porte logique qui réamplifie le signal.
Pour faire plus précis, on peut dire que chaque "fil" rouge est la grille d'un transistor (un même fil peut commander plusieurs grilles, comme c'est le cas sur l'image avec à chaque fois une grille en zone rouge (transistors type P) et en zone verte (transistors type N).
Ici on fonctionne en tout-ou-rien, donc cette grille est en gros la commande d'un interrupteur logique qui autorise ou interdit au courant de passer entre les zones à gauche et à droite de ces grilles.
Source et drain ne sont pas différenciés dans ce circuit simplifié. Par exemple dans le transistor au-dessus de A, le courant passe de gauche à droite, et dans celui au-dessus de B le courant passe de droite à gauche.
Pour la partie porte NAND, on reconnaît la structure avec le schéma de principe à transistors fourni par Wikipedia :
https://en.wikipedia.org/wiki/NAND_gate#/media/File:CMOS_NAND.svg
Pareil pour l'inverseur constitué des deux transistors de droite :
https://en.wikipedia.org/wiki/Inverter_(logic_gate)#/media/File:CMOS_Inverter.svg
# L'image est une porte AND
Posté par marzoul . En réponse au journal Conception d’un circuit intégré avec Qflow. Évalué à 4.
Et elle a 6 transistors, pas juste 2 :-)
Les deux en haut à gauche sont en parallèle depuis VCC, les deux en bas à gauche sont en série vers GND.
Jusque là, c'est une porte NAND dont les entrées sont les "fils" A et B, et sa sortie est le "fil" bleu qui connecte les deux du haut aux deux du bas.
La sortie de cette NAND commande un inverseur, composé des deux transistors de droite, et la sortie finale Y est l'opération AND.
[^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?
Posté par marzoul . En réponse au journal Le filtrage à la source. Évalué à 7. Dernière modification le 24 avril 2018 à 23:01.
Le point de vue optimiste c'est que tout pourrait être mis en place de façon pertinente et juste, oui.
D'un autre côté, quand du code libre se fera jeter parce qu'un système automatisé aura décidé que ça ressemblait trop à du code protégé, on aura quoi comme recours ? Envoyer un mail et se battre des semaines ? Le code d'un logiciel entier ça se fait "protéger" pour 250 euros à l'APP, rien à justifier, on envoie le code et le chèque, point. Le code inclura probablement des portions standard pompées sur internet par un collaborateur négligent. Et des portions qu'on aurait du mal à coder de façon différente de toutes façons, du parcours de liste ou de graphe par exemple.
Quelle est la granularité du système de filtrage ? Comment il va reconnaître une portion "simple" d'une portion "complexe" ? Si on lui apprend à détecter de la similarité incluant un simple renommage de variables on va vite retomber sur les algorithmes qu'on aurait du mal à écrire autrement. Il y aura de l'intelligence artificielle dans le tout, aussi. Massivement automatisé, difficile à contrôler, il y a toujours des faux positifs. Potentiellement beaucoup, vu la quantité de code propriétaire versus la quantité de code libre.
Du coup, avec la dissymétrie des informations (on ne verra jamais le code proprio, mais le système de filtrage le voit), la dissymétrie de qui est scanné pour plagiat et antériorité, l'accès aux specs techniques du système filtrage, le fait que les petites gens capituleront massivement (pas le choix) devant le jugement des missi dominici des ayants droit, et que ni les ayant "droit" ni les plateformes n'auront de sanction alors que se faire refuser la publication de son travail ça peut être démoralisant voir bloquant pour son travail, on a de bonnes raisons de s'inquiéter. Pas d'avoir peur quand même, mais de s'inquiéter. Ce qui n'inquiète pas du tout les lobbys malheureusement.
Où peut-on trouver des cas de repompage de code propriétaire dans du code libre ? En quoi sont-ils suffisamment fréquents pour justifier la mise en place de tout ça ?
Sera-t-il possible de prendre des mesures pour éviter que des "coding trolls" fassent protéger des portions de code simples et/ou génériques ?
# Xeon vous trouvez ça précis ?
Posté par marzoul . En réponse au journal ARM vs Intel. Évalué à 10.
Je rêve ou personne ne se pose la question clé : quel est exactement le CPU "Xeon" qui a été utilisé pour la mesure ? Il y en a des pléthores avec des perfs extrêmement variées, alors qu'il n'y a qu'un Qualcomm centriQ, qui est très récent et comme par hasard positionné low-power-toute.
Combien de coeurs, combien inutilisés, quel âge, déclinaison hi-perf ou low-power, quid du reste de la carte mère, etc.
Qu'on prenne le dernier CPU Intel pour laptop par exemple, en série ultra-low power, et ça pourrait surprendre des gens.
Je n'ai de parti pris arbitraire pour aucun fabricant. Mais ces annonces populistes où on joue surtout à ne pas donner les informations importantes me donneront toujours des haut-le-coeur.
# Linux ?
Posté par marzoul . En réponse au journal Areva → New Areva → Orano ? Vérifions ça…. Évalué à 5.
On peut aussi souligner que leur truc tourne sous Windows…
[^] # Re: Oui pour l'adaptation au monde actuel
Posté par marzoul . En réponse au journal Pour un renouveau démocratique. Évalué à 1.
Pour compléter, je voudrais dire qu'il faut instaurer pour les parlementaires un devoir d'écoute, et une interdiction de mener des négociations à huis clos avec qui que ce soit.
Tout membre du peuple a le droit de connaître les agissements de ceux pour qui il a voté. Et on devrait beaucoup plus avoir le pouvoir d'exiger la démission et l'inéligibilité de quiconque se démarque par des agissements inacceptables selon ces points. Certaines des nos éminences se seraient fait depuis longtemps vertement limoger en Norvège, Suède ou Finlande.
# Oui pour l'adaptation au monde actuel
Posté par marzoul . En réponse au journal Pour un renouveau démocratique. Évalué à 0.
Merci pour ton journal. Ça rejoint fortement ma propre opinion de choses.
Le fonctionnement par assemblée de représentants est un héritage des temps anciens où les moyens de communication étaient limités. La seule solution pour gouverner était donc d'élire des représentants et de les envoyer siéger physiquement.
De nos jours, oui les minorités sont peu écoutées. Mais on oublie que les majorités aussi : elles sont piétinées par les carriéristes qui mentent sans vergogne afin de se faire élire et dont les actions et les discours sont purement électoralistes.
Il y a 2 causes à cela : les postes politiques sont trop payés, et la sensation de pouvoir trop grande.
Pour une soit-disant démocratie, le simple fait de pouvoir interdire un référendum est une aberration. Or, c'est le procédé de base pour faire remonter au gouvernement les souhaits du peuple. En Suisse, beaucoup plus de choses sont votées qu'en France. J'aimerais bien que le Parti Pirate parvienne, même si c'est lent, à faire rentrer dans les moeurs qu'écouter le peuple point par point est infiniment préférable à élire selon les programmes des partis politiques construits le plus artificiellement du monde. On ne peut pas faire un pays purement de droite, de gauche ou purement vert. Il faut une juste dose de chaque point selon les besoins. Et surtout, il faut des moyens de communication permettant d'éviter aux lobbies de gouverner à notre place…
J'aimerais beaucoup que le Parti Pirate parvienne à faire rentrer cela dans les moeurs. Même si c'est lent.