Excellent !
Cela me donne envie de faire cette comparaison :
-
Les entreprises font ce qu'elles veulent, l'emprunte carbone, l'éco-conception, c'est du bullshit face au bénéfice perçu par le sacro-saint actionnariat même pas fiscalisé en France en plus (hein si encore ça finançait nos retraites et nos écoles).
-
Par contre, pour être éco-responsable, les citoyens quant à eux doivent éviter de manger de la viande, préférer les transports en commun ou le vélo, utiliser des pailles en carton recyclé qui s’effritent en 2 min et ne plus pouvoir séparer les bouteilles de leur bouchon... Sans parler des e-mails à effacer et toutes les autres banalités qui vont avec.
Peut-on parler des empruntes carbone et énergétique de ces lave-linges LG ? Peut-on parler d'une loi qui protégerait vraiment les humains de ces réels pollueurs ? Peut-on lancer un mouvement qui boycotterait des marques comme LG qui n'en ont rien à carrer de leur impact environnemental ? Peut-on demander aux députés "verts" ce qu'ils en pensent et ce qu'ils comptent faire pour empêcher cela ? Parce que ça fait 40 ans qu'on les attend...
Les masses prolétaires sont le carbone que l'élite veut réduire. Plus vite l'humanité le comprendra et mieux elle pourra se défendre.
C'est pourquoi je pense à présent qu'il faut polluer individuellement un maximum jusqu'à ce qu'une loi intransigeante soit rédigée. Une loi interdisant aux faibles comme aux puissants le moindre écart.
En attendant, l'éco-responsabilité n'est ni plus ni moins que de la propagande visant à laver les cervelles et éviter de regarder l'incendie au milieu de la forêt, nommons-le : l'hyper-bourgeoisie et les multi-nationales.
Cela peut se faire à partir de 2 ans. Le fait que l'État ne reconnaîtrait pas l'autisme avant les 10 ans du patient est une légende urbaine.
À ce jour, le diagnostic de l’autisme est clinique. Le plus souvent, le diagnostic peut être établi à partir de l’âge de 2 ans. Il repose sur un faisceau d’argument s cliniques recueillis dans des situations variées par différents professionnels. Il est associé à une évaluation des troubles et des capacités ainsi qu’à la recherche de maladies associées. Il se fait en collaboration avec la famille.
Edit comme j'avais des doutes sur le benchmark lancé depuis Intellij, j'ai recodé un comparatif complet qui aura tourné 4 heures sur ma machine
Avec Kotlin, sous Java 21, en utilisant JMH, j'obtiens des résultats en total contradiction avec ceux obtenus via IntelliJ. L'écart passe de 12% à 2,2% dans le pire des cas.
Pour mon benchmark, j'ai calculé la longueur d'une String avec la fonction suivante : 2 * str.length + 1. Le but étant d'illustrer quel type d'appel est le plus rapide pour effectuer ce calcul.
Voici mes tableaux de comparatifs :
| Benchmark (Sorted by Worst) | Score | Error | Worst | Best | Units | Note Relative | Gain |
|---|---|---|---|---|---|---|---|
| ValueClass(str).size() | 2 252 | 34 | 2 218 | 2 287 | ops/us | 1,000 | 0,0 % |
| build_lambda(str)() | 2 269 | 25 | 2 244 | 2 294 | ops/us | 1,012 | 1,2 % |
| Class::size(str) | 2 282 | 37 | 2 245 | 2 320 | ops/us | 1,012 | 1,2 % |
| OpenIntance(str).size() | 2 275 | 27 | 2 249 | 2 302 | ops/us | 1,014 | 1,4 % |
| Instance(str).size() | 2 285 | 37 | 2 249 | 2 322 | ops/us | 1,014 | 1,4 % |
| DataClass(str).size() | 2 273 | 22 | 2 251 | 2 295 | ops/us | 1,015 | 1,5 % |
| object.method(str) | 2 272 | 19 | 2 253 | 2 291 | ops/us | 1,016 | 1,6 % |
| this.size(str) | 2 282 | 28 | 2 254 | 2 310 | ops/us | 1,016 | 1,6 % |
| build_anonymous_function(str)() | 2 266 | 5 | 2 261 | 2 271 | ops/us | 1,019 | 1,9 % |
| Benchmark (Sorted by Best) | Score | Error | Worst | Best | Units | Note Relative | Gain |
|---|---|---|---|---|---|---|---|
| build_anonymous_function(str)() | 2 266 | 5 | 2 261 | 2 271 | ops/us | 1,000 | 0,0 % |
| ValueClass(str).size() | 2 252 | 34 | 2 218 | 2 287 | ops/us | 1,007 | 0,7 % |
| object.method(str) | 2 272 | 19 | 2 253 | 2 291 | ops/us | 1,009 | 0,9 % |
| build_lambda(str)() | 2 269 | 25 | 2 244 | 2 294 | ops/us | 1,010 | 1,0 % |
| DataClass(str).size() | 2 273 | 22 | 2 251 | 2 295 | ops/us | 1,011 | 1,1 % |
| OpenIntance(str).size() | 2 275 | 27 | 2 249 | 2 302 | ops/us | 1,014 | 1,4 % |
| this.size(str) | 2 282 | 28 | 2 254 | 2 310 | ops/us | 1,017 | 1,7 % |
| Class::size(str) | 2 282 | 37 | 2 245 | 2 320 | ops/us | 1,021 | 2,1 % |
| Instance(str).size() | 2 285 | 37 | 2 249 | 2 322 | ops/us | 1,022 | 2,2 % |
| Benchmark (Sorted by Score) | Score | Error | Worst | Best | Units | Note Relative | Gain |
|---|---|---|---|---|---|---|---|
| ValueClass(str).size() | 2 252 | 34 | 2 218 | 2 287 | ops/us | 1,000 | 0,0 % |
| build_anonymous_function(str)() | 2 266 | 5 | 2 261 | 2 271 | ops/us | 1,006 | 0,6 % |
| build_lambda(str)() | 2 269 | 25 | 2 244 | 2 294 | ops/us | 1,007 | 0,7 % |
| object.method(str) | 2 272 | 19 | 2 253 | 2 291 | ops/us | 1,009 | 0,9 % |
| DataClass(str).size() | 2 273 | 22 | 2 251 | 2 295 | ops/us | 1,009 | 0,9 % |
| OpenIntance(str).size() | 2 275 | 27 | 2 249 | 2 302 | ops/us | 1,010 | 1,0 % |
| this.size(str) | 2 282 | 28 | 2 254 | 2 310 | ops/us | 1,013 | 1,3 % |
| Class::size(str) | 2 282 | 37 | 2 245 | 2 320 | ops/us | 1,013 | 1,3 % |
| Instance(str).size() | 2 285 | 37 | 2 249 | 2 322 | ops/us | 1,015 | 1,5 % |
Conclusion après benchmark
Créer des instances à la Yegor Bugayenko semble être globalemment l'une si ce n'est la meilleure des solutions lorsque l'on observe son positionnement qui est au pire moyen sinon deux fois premier.
J'ai passé le nouvel an avec @Kysofer & @Chlouloutte. Quand tous les enfants ont le même âge c'est vraiment sympa ; surtout quand ils se couchent tous en même temps :P
Mais passons, ce matin après ce qui sera déjà l'une des plus courtes nuit de cette nouvelle année, je discute avec @Kysofer de ces projets pour 2024, il me sort un truc improbable :
Je pense que je vais abandonner la programmation orientée objet pour la programmation fonctionnelle...
Là, je le regarde limite choquée... Il faut dire que lui et moi partageons - je devrais dire partagions - le même avis sur la programmation fonctionnelle, notamment depuis nos déboires en OCaml (merci le programme de MPSI).
Donc, avec le plus grand respect je lui réponds :
Nani the fuck !?
À ma décharge je n'ai pas bu un seul verre d'alcool depuis la grossesse de ma petite dernière. Et oui. :P
Là il m'explique tout un tas de trucs et je dois dire que je me sens déstabilisée. Je m'explique, j'ai vécu trop de fois le fait de devoir maintenir du Scala pour savoir à quel point, sur le temps long, la programmation fonctionnelle pure devient encore moins maintenable que du Java + Spring Boot.
D'autant que je m'attendais à ce qu'il m'annonce qu'il allait (enfin) se monter un Shaarli.
Bref son idée est dirigée par les contraintes suivantes :
- Avoir un code dirigé par des contrats (au sens interfaces Java) dont le respect du typage est prouvé lors de la compilation et garanti lors de l'exécution.
- Ne pas avoir besoin de créer des instances techniques qui implémentent ces contrats, afin d'encapsuler des données dedans.
- Parvenir quand même à encapsuler les données pour les protéger mais sans jamais créer de nouvelles instances (cf. le point précédent).
- Avoir les mêmes performance d'exécution que du chaînage d'appels de fonctions
static; et donc l'eldorado du zero GC-time. - Permettre une exécution différée/lazy/paresseuse.
Quand on lit le truc, on se dit que la vie n'est plus à un paradoxe prêt, mais pourtant sa façon de faire fonctionne.
Je vais essayer de vous décrire ce qu'il m'a expliqué afin de mieux l'ingérer moi-même.
Exemple : Déterminer si deux trucs sont égaux
Dans tous les cas de figure, nous allons supposer que les données sont décorées par une implémentation de l'interface suivante qui permet de les représenter sous la forme d'un tableau d'octets.
interface RawData {
fun asBytes():ByteArray
}
Version OOP Pure
1) On exprime le concept de vérification via une interface :
interface Check {
fun status():Boolean
}
Ensuite on fournit une implémentation de l'interface Check qui soit spécialisée dans la comparaison de deux RawData :
class IsEqual(
private val left:RawData,
private val right:RawData
):Check {
override fun status():Boolean {
return this.isSameInstances() || this.haveSameBytes()
}
private fun haveSameBytes():Boolean {
return left.asBytes().contentEquals(right.asBytes())
}
private fun isSameInstances():Boolean {
return left === right
}
}
Et ça s'utilise comme ceci :
val left:RawData = StrAsData("same data")
val right:RawData = StrAsData("same data")
val comparison:Boolean = IsEqual(left, right).status()
Problème
Pour comparer deux objets on doit forcément créer une instance de IsEqual puis invoquer une méthode dessus. Sur JRE, c'est ~12% de temps de calcul supplémentaire par rapport à un simple appel de méthode statiques !
Version PF pure
Avant toute chose, il faut comprendre ce qu'est un contrat pour @Kysofer. C'est un truc qui va prouver à la compilation que les types d'entrée et de sortie soient bien respectés, ce qui fait que l'implémentation A pourra se substituer à l'implémentation B sans problème lors du runtime.
Mais comment peut-on produire l'équivalent d'une interface en PF ?
=> On passe par des fonctions de premier ordre.
En effet, une méthode qui reçoit une fonction de premier ordre ne sait pas ce qu'elle va exécuter. Elle sait juste que la fonction prendra un certain type en entrée et un certain type en retour. Le reste, c'est le compilateur qui agit.
Si l'on reprend l'interface Check cela nous donne le prototype suivant :
val prototype:() -> Boolean
C'est-à-dire un Predicat sans paramètre.
Maintenant passons à l'implémentation naïve, ceci nous donne :
fun isEqual(left:RawData, right:RawData):() -> Boolean {
return {
isSameInstances(left, right) || haveSameBytes(left, right)
}
}
private inline fun haveSameBytes(left:RawData, right:RawData):Boolean {
return left.asBytes().contentEquals(right.asBytes())
}
private inline fun isSameInstances(left:RawData, right:RawData):Boolean {
return left === right
}
On voit bien que la fonction isEqual(..) retourne une fonction de premier ordre qui elle-même retournera un Boolean.
Rappel
En Kotlin, les lambda sont déclarées entre deux accolades { .. }.
Sauf que cet exemple a un problème puisqu'une lambda, sur JRE tout du moins, c'est une instance de l'interface Function ou l'un de ses équivalents. Bref, il n'y a pas de gain en terme de performance par rapport la version OOP.
Pour l'obtenir, il suffit de remplacer la création d'une lambda par un pointeur sur une fonction anonyme, ce qui nous donne :
fun isEqual(left:RawData, right:RawData) = fun():Boolean {
return isSameInstances(left, right) || haveSameBytes(left, right)
}
Et la ça devient magique car la fonction anonyme étant écrite directement dans le byte-code et épinglée une et une seule fois en mémoire, cela revient à avoir un pointeur sur fonction qui exécutera la-dite fonction.
=> Soit un gain de 12% en termes de performance, ce qui fait qu'on rattrape la vitesse d'exécution d'un chaînage de méthodes statiques.
Mieux que cela, @Kysofer s'appuie sur une variante de la Curryfication . En effet, la méthode isEqual(..) sert à encapsuler les données dans la pile d'appel pour les rendre utilisables que par la fonction anonyme. Donc il devient impossible de savoir ce qui sera utilisé par la lambda qui sera retournée.
=> Les paramètres left et right sont bien encapsulés dans la lambda !
Si on résume
- Le fait que la fonction
isEqual(..)retourne une lambda et non un résultat fait que l'on va déclarer un contrat et donc rendre les lambda interchangeables. - Le fait que l'on retourne une fonction et non un résultat permet un calcul différé/paresseux potentiellement dans un autre thread.
- Le fait que l'on passe par une fonction anonyme qui utilisera les paramètres de la fonction déclarée fait qu'on encapsulera bien les données avant d'exécuter quoi que ce soit dessus.
- Le fait que tout soit
fonctiongaranti l'absence de création d'instances techniques.
Nous avons donc bien là une version fonctionnelle de l'encapsulation et des contrats de l'OOP.
Ça aura pris 15 ans mais je pense être réconciliée totalement avec la PF (O_O) ; sauf le récursif, ça jamais ! En tout cas pas avant une démonstration comme celle-ci :P
Arf, je commence l'année en lisant un article pareil...
Comment faire pour sauver Firefox alors qu'il n'est plus la priorité de Mozilla depuis quelques années ? Simple, ne l'installons plus chez personne. Firefox doit mourir au profit de ses petits frères comme Waterfox ou Librefox.
Comment le financer ? En donnant à ces forks et non plus à Mozilla.
Comment leur donner de la visibilité ? En assurant que chacun utilise un user-agent qui n'a plus rien à voir avec celui de Firefox du type "Bye bye Mozilla". Quand Mint avait abandonné le user-agent de Ubuntu, alors le rang de Ubuntu avait dégringolé en quelques mois sur Distrowatch.
Comment renforcer Waterfox et Librefox ? En veillant à ce que les communautés derrière ces deux projets fusionnent ou au moins se soutiennent, car on est plus forts à plusieurs.
Ma résolution de cette année sera de contribuer à la mise à mort définitive de Firefox afin qu'un nouvel élu puisse prendre sa place. Un élu qui ne sera structurellement pas noyautable par les GAFAM... 😌
L'UE qui risque de stopper net le logiciel libre en Europe sous le prétexte de la sécurité. En même temps supporter ces "communistes d'internet" comme dirait Balmer, alors que l'UE veut du business et rien d'autre que du business, quelle idée !
Sortons de ce piège à rats où des diplomates non-élus, votent des lois au profit des lobbyings, qui organiseront la société contre nous.
P.S : d'ailleurs l'UPR se présente aux Européennes, si c'est pas beau ça ! (Ce qu'il ne faut pas faire pour d'obtenir du financement et du temps de parole).
La balise <slot> de HTML5 permet de variabiliser la balise <template> de HTML5, ce qui représente la moitié des besoins d'une SPA.
À cette heure, les <slot> sont pris en charge à 96% selon caniuse.
Merci à Kalvn pour le lien.
Avant ces vacances de Noël, on m'a confié la tâche de déterminer quelle techno utiliser pour coder plusieurs fronts.
J'avais regardé les frameworks SPA via Aurelia et Vue et les pages générées côté serveur via Twig que j'ai toujours adoré 😍.
Ce tuto de Kalvn tombe à point nommé puisqu'il complète très bien l'usage de la balise <template>.
Tout est dans le titre. Comment se prémunir des attaques de type XSS.
Tour à fait d'accord. J'ajouterai à mort les interfaces tactiles pour les micro-ondes et les plaques de cuissons 🤬
Ces deux produits maltraitent de manière ignoble les aveugles !
Dans le cas du micro-ondes, la nuit quand il faut réchauffer un biberon, c'est une misère avec la pénombre ; et c'est tout le temps plein de traces en journée.
Dans le cas des plaques de cuisson, à la moindre goutte d'eau ça change le réglage voire le bloque. Pire, si un liquide bouillant tombe dessus, il faut se brûler pour arrêter la plaque car ça ne marche pas avec des gants... 🤬
J'ajoute à la liste de @Sebsauvage ceux qui mettent du tactile partout et je boycott pour ma part toutes ces marques car payer c'est voter
Je pense qu'il faut faire crever ces imbéciles en faisant d'eux des exemples
(╯° □°) ╯︵ ┻━┻
Dernièrement je regardais les nouveautés en termes de frameworks CSS et globalement il y la liste suivante :
- Bootstrap
- Bulma
- Tailwind
- Foundation
- Skeleton
- Pure
- Tachyons
J'avais beaucoup d'espoir dans Tailwind qui adopte une approche par contraintes, dans le sens où il permet, sur chaque composant, d'appliquer des classes du type "à droite, vertical, graissé, etc" et c'est la combinaison de ces classes qui définira le rendu définitif du composant #SexySur20
A l'opposé, il y a Bulma où des composants déjà prêts existent et où les classes sont du type "burger-menu".
Sauf que je viens de m'apercevoir que Tailwind repose sur la mouvance JS bullshit dont la Comitstrip suivante matérialise parfaitement l'hérésie des fashions victims qui servissent dans l'industrie depuis un moment déjà :

Bref, il ne reste plus que Pure et Bulma comme frameworks CSS qui soient de vrais frameworks CSS paramétrables et simples. Certains me demanderont pourquoi j'insiste le fait d'avoir des CSS purs et durs et l'argument est simple : les SPA/PWA, j'en suis revenue !
Argumentons quand même. Selon moi, à moins que votre site implique au moins deux critères parmi les suivants (si ce n'est pas trois) :
- Du streaming de TRÈS gros fichiers (genre youtube)
- Des temps de surf qui se comptent en heureS (m'voyez le 'S') voire en jours
- Des actions ultra complexes (genre éditeur de photo en ligne)
- Le besoin de déporter des calculs côté clients si lourds qu'aucune infra sur terre ne tiendrait la charge si tout était centralisé côté serveur (ou alors à un coût équivalent à celui de ChatGPT)
- Le besoin de travailler en mode hors connexion
=> alors les SPA/PWA sont une mauvaise idée.
Du coup, la seule manière de pouvoir coder un design system qui fonctionne à la fois dans des MPA (ie. terme à la mode pour dire "pages générées côté serveur" comme Papy faisait avant en PHP) mais aussi dans des SPA/PWA, c'est d'avoir un framework CSS indépendant de tout JS et qui soit téléchargé en tant que fichier CSS et non JS.
Bref, je vais zoomer sur Pure histoire de voir ce qu'il est devenu - et peut-être Cardinal aussi - mais dans le fond, je pense garder Bulma d'autant que son développement aurait récemment repris :P
@Sebsauvage ces derniers temps je suis souvent en désaccord avec toi, mais ça n'empêche pas que quand je partage ton avis, je le fais à 100000% (oui rien que ça) et là, je partage vraiment ton avis !!
Permets-moi d'ajouter à ta liste, les développeurs qui empêchent le zoom sur les sites mobiles quand c'est écrit trop petit
ヽ(`⌒´メ)ノ
Totalement d'accord avec toi. J'ajouterai que le principe de taxe sur la consommation n'a de sens que pour des gouvernements sans projet.
Je me raccroche à l'idée de Houellebecq qui a presque 20 ans à présent.
1. L'état récupère le droit (exclusif) de créer ET de détruire la monnaie.
L'état aura bien l'exclusivité de ce droit. Donc ça va fâcher les banques. Actuellement elles fabriquent de la monnaie lorsqu'elles octroient un crédit plutôt que de prêter l'argent déposé par les épargnants. Puis elles détruisent l'argent qu'elles ont créé à chaque mensualité. Les intérêts qu'elles prélèvent proviennent de la création monétaire des crédits futurs (merci à nos enfants de se sacrifier pour nous)... Quant à l'argent des épargnants, elles le spéculent en bourse ou s'en servent comme collatéral.
Avec ce retour à la normale, elles pourront spéculer en bourse mais uniquement sur leurs recettes et sur leurs fonds propres, et devront prêter l'argent de leurs épargnants si elles souhaitent faire crédit. Par contre, impossible pour les épargnant d'utiliser leur argent si ce dernier a été prêté... Mais celui-ci étant mobilisé, il sera rapporteur d'intérêts !
Les banques devront donc proposer deux types de comptes : les comptes rémunérés puisque l'argent sera loué à quelqu'un, et les comptes non-rémunérés pour une réserve d'argent toujours disponible. La possibilité de faire crédit n'est plus donné aux banques mais confiée au marché via les épargnants, c'est nettement plus démocratique et horizontal comme mécanique de décision des taux puisque ça repose sur une offre et une demande.
Mais quel bourgeois voudrait ça ?
2. L'état fabrique de la monnaie pour financer ses services publics et ses grands-travaux.
Plus besoin de quémander une pièce sur les marchés financiers. Le rapport de force s'inverse, l'état redevient souverain. Par contre, il faut qu'il organise des projets de société à mener chaque année. Nous passerions d'un gouvernement qui administre à un gouvernement qui entreprend, et c'est un tout autre paradigme.
Évidement c'est impossible tant que la mafia parlementaire à régime électif propagandiste nous gouverne (coucou l'UE/BCE). Il faut que nous votions les lois nous-mêmes pour que ça marche.
L'avantage, c'est que les problèmes de financement des services publics et de la retraite disparaissent immédiatement ! Et les privatisations des services publics aussi...
3. L'état détruit les excédents monétaires périodiquement (tous les mois, trimestres, semestres, années).
L'argent produit par création monétaire ex-nihilo va accentuer le risque d'inflation, pour contrôler l'inflation et non la subir, l'état agira sur la quantité de monnaie qui circule à chaque instant.
Techniquement, si trop de monnaie a été fabriqué pendant une période, alors l'état lève de l'impôt en fonction de cet excédent, ce qui lui permet de faire revenir la quantité excédentaire d'argent pour la détruire.
Si pas assez d'argent a été créé, alors l'état fabrique de nouveau de la monnaie et durant cette période, il n'y a pas d'impôt. C'est sûrement cet aspect qui j'apprécie le plus dans ce système.
Mais bon, Houellebecq a été taxé d'extrême-droite quelque fois par certains radicaux de la gauche progrès/woke, donc même si certaines de ces idées sont bonnes, puisqu'il n'est pas fréquentable, ses idées sont mauvaises c'est évident :'(
Il y a une idée qui me travaille depuis quelques temps et il faut que je l'écrive pour m'en débarrasser.
Les médias nous disent qu'il ne faut pas aider les plus pauvres car cela encourage l'assistanat. Nous pouvons même lire et entendre dans le monde occidental des milliardaires ou des journalistes nous expliquer que rien n'est gratuit, car au bout de course, il y a toujours quelqu'un qui a travaillé ; et c'est vrai.
J'écoutais dernièrement Warren Buffet parler de l'idée d'une sécurité sociale aux USA et le milliardaire s'appuyait sur cet argument pour expliquer que cela ferait du prolétariat des assistés voire des vampires qui suceraient la richesse produite par les travailleurs.
Et c'est ici que mon esprit s'est emballé...
Taxer la richesse produite par les travailleurs pour son bénéfice personnel, c'est la définition même d'un actionnaire. Fondamentalement, si on veut être en accord avec l'idée qu'il ne faut pas taxer la richesse des travailleurs pour une sécurité sociale car on est de droite néo-libérale, alors il faut être en accord avec l'idée qu'il faut interdire l’actionnariat qui fait la même chose.
Mais l'inverse est vrai aussi, si on accepte de taxer la richesse pour une sécurité sociale, alors on accepte l'idée même de taxer la richesse et donc l'actionnariat ne devrait pas être un problème pour la gauche socialo-communiste.
En fait, les deux camps s'accordent pour taxer la richesse produite par les travailleurs, mais chaque camp ne veut l'attribuer qu'à ce qui l'intéresse. Je trouve que c'est quand même moralement supérieur de vouloir taxer les travailleurs pour leur fournir une sécurité sociale complète et efficace car ils récupèrent ainsi le fruit de leur travail, ou éventuellement voient leurs semblables en profiter lorsqu'ils ne sont pas malades.
Après je ne suis plus contre les dividendes tant qu'ils sont majorés en valeur et en temps ; mais je suis pour qu'on interdise les plus-values sur le marché secondaire. Le marché primaire reste utile à l'économie, le secondaire et les produits-dérivés ne sont qu'un casino qui assassine les populations à petit-feu.
Ma compréhension de l'argument sous-entendu dans cette BD est ceci (mais je peux me tromper bien sûr) :
Parce que les inégalités existent ailleurs dans la société, alors autant ne pas essayer de réduire leur impact, en commençant dès l'enfance, en imposant l'uniforme à l'école.
Je pense que l'avis derrière cette BD est proche du stupide et s'articule autour du navrant. Dans la vraie vie, tenter l'uniforme à l'école, ça s'appelle essayer quelque chose en commençant quelque part. Ensuite on observe, on mesure et enfin on conclut sur l'intérêt de poursuivre ou non l'initiative.
A ma connaissance, l'uniforme total - c'est-à-dire celui qui inclus sacs et chaussures - n'a jamais été testé à grande échelle dans les écoles de notre république. Tentons le coup quelques années et récoltons les retours d'expérience des enfants, des profs et des familles avant de jeter le bébé avec l'eau du bain.
Pour avoir travaillé une fois dans la fonction publique, cette mentalité (de merde) est ce qui grève tout capacité d'entreprendre et d'avancer dans ces milieux où l'immobilisme structurel est le maître absolu. Pire que cela, permettre à certains de vivre mieux attiserait les jalousies, alors mieux vaut ne rien faire quitte à tirer tout le monde vers le bas... Une démarche Franco-Française en somme, donc tout va bien.
Je viens de tester sur Firefox 119 et Chromium 109.
Résultat : Firefox est un peu plus de 20% plus rapide que Chromium !
- Chrome 106 runs / minutes avec 1,9 d'écart type.
- Firefox 129 runs / minutes avec 3,3 d'écart type.
@Mozilla ajoutez les features qu'on vous demande, la mécanique est bonne. Les Pocket et consorts on s'en fiche !
Incroyable ! #ConsanguinitéSur20
@Strak ce n'est pas parce que Firefox est moins utilisé qu'il faut l'abandonner. Sommes-nous à ce point des moutons de Panurge ? Je ne pense pas qu'utiliser Firefox quand les autres sont sur autre chose soit une honte, c'est juste un choix.
Je reste sur un Firefox like, c'est-à-dire Waterfox. Le problème vient bien des dirigeants de Mozilla qui ne parviennent pas à étendre Firefox avec 500 M$ de budget annuel.
Ils préfèrent dépenser cet argent sur des projets marginaux, ne font plus la promotion de Firefox et ne cessent de s'augmenter aussi... Depuis combien de temps n'avons-nous plus vu la dernière publicité pour Firefox ou assisté au dernier événement autour du navigateur ? Je dirais 10 ans si ce n'est pas 15.
Redresser la pente pourrait-être simple mais long :
- Refaire de la publicité. La sortie d'une nouvelle version doit être un événement majeur et qui se fête. Avoir un modèle "fluide" qui consiste à dire qu'une mise à jour est tellement stable qu'elle en devient un non-événement c'est super quand on est en situation de monopole. Autrement c'est contre-productif.
- Cibler les 12/16 car ceux sont eux qui installeront Firefox chez les autres.
- Ajouter des affiches dans les grandes villes et dans les lieux ou les décideurs sont susceptibles de passer (métro, gares, la Défense).
- Tisser des partenariats avec des écoles.
- Tisser des partenariats avec des fabricants de PC/Mobile (Xaomi, Huawei, etc) afin de diversifier les sources de revenus, ce qui séparerait Firefox de Google et lui permettrait de protéger la vie privée sans contre-partie.
- Tisser des partenariats avec des entreprises ciblant la vie privée (e.g. ProtonMail).
- Tisser des partenariats avec des projets communautaires (e.g. Mastodonte, Gnome).
- Faire des appels aux dons.
- Arrêter d'ajouter des features (connectées) que la communauté ne demande pas.
- Remettre du lien entre Firefox et sa communauté au travers d'événements et des modalités de dialogue différentes.
- Cibler les pays émergeant, tisser des partenariats avec leurs gouvernements.
- Arrêter de s'imaginer que la solution viendra des geeks alors que le problème vient de la direction de Mozilla qui vit dans une bulle-cognitive.
- De notre côté, organiser des choses autour de Firefox, de ses fonctionnalités, des ses performances.
- Profiter du fait que Google va tout bloquer sur Youtube et Chrome dans pas longtemps et que la seule alternative viable soit Firefox.
Nous allons t'aider Firefox, et de bon cœur, peu importe que Mozilla te maltraite, il faut juste que tu tiennes le temps que nous nous mobilisions pour toi.
Je finirai pas un point Godwin. Entre 1943 et 1945, quand tout était perdu, la résistance française représentait environ 1% des français seulement... Alors à 3,2% de parts de marché tout est encore faisable. Mais espérer ne sert à rien, il faut que nous agissions si ce projet nous tient à cœur. Ce ne sont pas nos shaarlis, nos tweets ou nos pouets qui vont changer la donne, ce sont nos actions concrètes.
@Animal pour toi qui aimes lire les RFC...
En quatre étapes :
1) Récupérer le certificat au format TXT
openssl s_client -connect mon-domaine:443 > mon-certif.pem
2) Nettoyer le fichier TXT pour ne garder que ce qu'il y a entre les sections BEGIN CERTIFICATE et END CERTIFICATE inclus, par exemple :
-----BEGIN CERTIFICATE-----
MIIDnzCCAocCBE/xnXAwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkRFMRUw
EwYDVQQIEwxMb3dlciBTYXhvbnkxEjAQBgNVBAcTCVdvbGZzYnVyZzEYMBYGA1UE
ChMPU2FhUy1TZWN1cmUuY29tMRowGAYDVQQDFBEqLnNhYXMtc2VjdXJlLmNvbTEj
MCEGCSqGSIb3DQEJARYUaW5mb0BzYWFzLXNlY3VyZS5jb20wHhcNMTIwNzAyMTMw
OTA0WhcNMTMwNzAyMTMwOTA0WjCBkzELMAkGA1UEBhMCREUxFTATBgNVBAgTDExv
d2VyIFNheG9ueTESMBAGA1UEBxMJV29sZnNidXJnMRgwFgYDVQQKEw9TYWFTLVNl
Y3VyZS5jb20xGjAYBgNVBAMUESouc2Fhcy1zZWN1cmUuY29tMSMwIQYJKoZIhvcN
AQkBFhRpbmZvQHNhYXMtc2VjdXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMUZ472W3EVFYGSHTgFV0LR2YVE1U//sZimhCKGFBhH3ZfGwqtu7
mzOhlCQef9nqGxgH+U5DG43B6MxDzhoP7R8e1GLbNH3xVqMHqEdcek8jtiJvfj2a
pRSkFTCVJ9i0GYFOQfQYV6RJ4vAunQioiw07OmsxL6C5l3K/r+qJTlStpPK5dv4z
Sy+jmAcQMaIcWv8wgBAxdzo8UVwIL63gLlBz7WfSB2Ti5XBbse/83wyNa5bPJPf1
U+7uLSofz+dehHtgtKfHD8XpPoQBt0Y9ExbLN1ysdR9XfsNfBI5K6Uokq/tVDxNi
SHM4/7uKNo/4b7OP24hvCeXW8oRyRzpyDxMCAwEAATANBgkqhkiG9w0BAQUFAAOC
AQEAp7S/E1ZGCey5Oyn3qwP4q+geQqOhRtaPqdH6ABnqUYHcGYB77GcStQxnqnOZ
MJwIaIZqlz+59taB6U2lG30u3cZ1FITuz+fWXdfELKPWPjDoHkwumkz3zcCVrrtI
ktRzk7AeazHcLEwkUjB5Rm75N9+dOo6Ay89JCcPKb+tNqOszY10y6U3kX3uiSzrJ
ejSq/tRyvMFT1FlJ8tKoZBWbkThevMhx7jk5qsoCpLPmPoYCEoLEtpMYiQnDZgUc
TNoL1GjoDrjgmSen4QN5QZEGTOe/dsv1sGxWC+Tv/VwUl2GqVtKPZdKtGFqI8TLn
/27/jIdVQIKvHok2P/u9tvTUQA==
-----END CERTIFICATE-----
3) Dire à git d'aller chercher ce certificat
git config --global http.sslCAInfo /mon/chemin/vers/mon/certif.pem
4) S'assurer que la vérification SSL/TLS n'est pas désactivée dans Git
git config --global http.sslVerify true@Animal La réponse est dans cette phrase
Les taux d'intérêts actuels sont trop bas par rapport à l'inflation actuelle.
Tant que les taux n'ont pas rattrapé l'inflation, c'est jouable. Même une baisse de 30% dans 5 ans ne compensera pas une inflation de 5% par an ; et nous sommes à plus que ça.
Alors si quelqu'un parvient à obtenir un taux entre 4% et 4,5% et un TAEG inférieur à 5%, c'est bien pour lui, une situation correcte pour acheter.
Sur le temps long, l'immobilier rattrapera toujours l'inflation, puisqu'il y a augmentation perpétuelle de la masse monétaire et que la monnaie se diffusera toujours, même si c'est lent, dans la population.
La baisse de valeur des biens s'étendra sur une décennie tout au plus comme nous avons pu le constater lors du siècle passé.
Donc acheter pour revendre avant 10 ans n'est pas un choix judicieux du tout ! Par contre il faut acheter pour constituer un patrimoine à léguer ou une rentee à construire pour les plus chanceux.