Renault a écrit 7565 commentaires

Par exemple, il y a eu il y a quelques années un conflit en Ethiopie qui aurait fait dans les 800 000 morts, soit plus que la population à Gaza.
J'ai pas le souvenir que grand monde en ait eu grand chose à faire. Pas de manifs, pas de relais dans les médias appelant à prendre telle ou telle position, etc…

Mais peut être parce que l'Occident a une responsabilité particulière dans le conflit israëlo-palestinien en laissant le champs libre à Israël depuis 50 ans et même en soutenant ce régime malgré la violation des résolutions de l'ONU pour laquelle la France en particulier est garante en tant que membre permanent du Conseil de Sécurité ? C'est une lourde responsabilité en théorie d'avoir ce status même si beaucoup semblent l'oublier en particulier les USA et la Russie.

Et cette singularité est probablement plus en rapport avec de la politique intérieure en Occident qu'une quelconque proximité avec la Gazaouis.

Ou d'une responsabilité historique suite à la décision de donner un territoire aux israëliens avec des garanties pour les locaux qu'ils n'ont pas tenu et un soutien armé indirect de notre part ?

Même les Egyptiens (qui leur sont bien plus proche à tout point de vue) pourraient leur venir en aide mais ne le font pas.

Le fait que Israël a l'arme atomique en théorie, et un soutien militaire direct des USA et de l'armement de pointe venant du monde entier explique en partie aussi leur réaction prudente.

Ils ont tenté de lutter contre eux dans le passé et ça s'est mal passé, il n'y a aps de raisons de croire qu'aujourd'hui ils feraient mieux.

Et c'est ça en partie le problème, si Israël n'était pas soutenu comme aujourd'hui, la situation serait sans doute très différente. Du coup malgré les atrocités qu'ils commettent, on les soutient, ce qui les conforte dans leur politique. Super, surtout ne changeons rien.

C'est bien que l'UE constate que la gestion de ce conflit ne peut pas continuer comme ces 30-50 dernières années et qu'il faut changer d'approche si on veut y résolution.

Non, l'inspectrice a dit que le fisc considère systématiquement qu'il y a 30% de fraude et fait ses calculs en conséquence, mais ça ne se voit pas dans les documents. C'est une façon de récupérer des sous sans pressurer les entreprises puisqu'elles fraudent.

Je ne comprends pas ce que tu dis.

Le fisc n'a pas le pouvoir de décider de la fiscalité des entreprises dans son coin, cela se base sur la loi qu'elle applique en veillant à ce que les entreprises et autres entités respectent celle-ci.

Si les 30% ne se voient pas, cela signifie que la loi tient compte de la fraude pour le calcul du budget de l'État. J'ai presque envie de dire, on s'en fout pas mal, l'important c'est que la loi soit claire et que les sous entrent. Et cela me semble normal. Cela ne veut pas dire que si la fraude disparaît la loi changera pour baisser (cela peut être plus ou moins le cas, mais pas certain, surtout dans le contexte budgétaire actuel).

Ou alors cela signifie que le fisc va au delà de la loi et ne tient pas uniquement des documents et déclarations pour calculer l'impôt en ayant sa propre sauce opaque. Je n'y crois pas vraiment, ce serait aberrant dans un État de droit et facile à contester, le fisc ne peut pas imposer plus que ce que la loi permet et elle doit prouver que l'entreprise fraude pour imposer plus.

Ou alors je n'ai vraiment pas compris ou tu voulais en venir avec ton propos.

Tu es en train de dire que le fisc prélève plus de TVA et d'impôts des sociétés en ajoutant 30% de TVA et de CA que ce qui est déclaré ?

Je ne pense pas qu'un comptable laisse le fisc faire une telle chose par défaut, et ça devrait être son rôle de demander au fisc de prouver le manque à gagner pour l'État pour faire un tel "redressement".

C'est environ 27% du budget (ce qui est déjà énorme) : https://www.info.gouv.fr/actualite/comment-fonctionne-le-budget-de-letat

La fraude à la TVA est non seulement une perte de budget pour l'État non négligeable, mais ça cause aussi des injustices concernant l'égalité devant l'impôt.

À part les digital nomads qui travaillent dans des cybercafés et les dayssideurs pressés qui passent leur vie dans des aéroports, ça importe à qui l'autonomie pour un pc de travail?

Les étudiants où il faut se battre pour avoir accès aux rares prises ? :D

Les deux termes sont équivalents du point de vue des libertés pour l'utilisateur.

Cela dépend certainement du sujet tout d'abord.

Ensuite le soucis c'est que si tu es face à une IA unique par rapport à plusieurs humains différents au sein d'une organisation par exemple, les humains peuvent identifier les erreurs des autres et les corriger. Ce n'est pas pour rien que dans certaines situations on ne laisse pas une personne seule à un poste donné.

Ensuite ce que je souhaitais mettre en évidence surtout c'est que certaines personnes prennent tout ce que dit une machine (IA ou pas) comme vrai car c'est "objectif", "neutre", etc. Ce qui est faux. Donc quand la machine se trompe, la personne aura du mal à remettre en question ce que la machine dit. Alors que entre êtres humains ce type de relation peut certainement exister dans des contextes spécifiques d'emprise, mais on a la preuve quasi quotidienne que remettre en cause la parole d'un être humain se fait souvent car on le sait de fait qu'il peut se tromper, être biaisé, etc. Propriétés que les gens prêtent moins souvent aux machines.

parce que je doute qu'elle demande le divorce après être allé voir une voyante…

Ça c'est parce que tu n'as pas fréquenté des gens adeptes de ce genre de pratiques.

Les gens qui croient tout et n'importe quoi qui viennent du gourou ou du charlatant il y en a plein.

C'est un des signes qui montre que mes humains comprennent que l'IA est plus "intelligente" qu'eux.

Ou tout comme les gens qui sont sensibles à l'argument "vu à la TV", "Doctissimo dit que j'ai un cancer", "j'ai trouvé ça sur Google donc c'est vrai" peuvent croire "objective" et "ne peut pas se tromper". C'est d'ailleurs tout le problème de confier certaines décisions à des algorithmes sans possibilité d'intervention humaine en croyant qu'ils ne peuvent faire aucune erreur.

D'ailleurs MrTom nous a fait un petit coucou sur Discord, si jamais tu veux le recroiser.

Pour ma part, je trouve que les conteneurs façon Docker (1 appli dans un conteneur)

Ici dans le contexte des systèmes atomiques ce n'est pas forcément aussi cloisonné que un environnement de productions où chaque application a son conteneur unitaire.

À part l’isolation des processus

Ce n'est pas un détail.

Nix me semble apporter les même avantages : souplesse, robustesse, atomicité des mises à jour…

Concernant les mises à jour, je ne vois pas en quoi l'approche de Nix apporte l'atomicité au même niveau en fait. Mais je ne connais pas parfaitement ce système non plus.

Qu’est-ce qui fait, à votre avis, que Nix reste un produit de niche, alors que les conteneurs gagnent du terrain ?

Le soucis c'est que les conteneurs c'est au delà de la question de Fedora Silverblue ou des systèmes atomiques, leur usage principal n'est pas lié à celui-ci du coup j'ai du mal à comprendre la question.

En tout cas NixOS et Fedora Silverblue ont de nombreuses divergences de conception, chacune avec ses forces et faiblesses. Le fait que les distributions atomiques sont des distributions basées sur des distributions déjà populaires aide certainement à attirer un certain public. NixOS n'a jamais été aussi populaire que Fedora ou OpenSuse à ma connaissance.

Avec les normes WLTP, en thermique pur il ne faut pas dire n'importe quoi car on est vraiment avec des chiffres très fiables.

Pas du tout, et suffit de lire le protocole WLTP pour s'en convaincre que c'est irréaliste.

Et si dans le passé, il fallait rajouter 1 à 1.5l/100km aux chiffres d'homologation pour avoir une idée fiable de la réalité,

Je viens de regarder les résultats WLTP des véhicules que j'ai conduit ces dernières années, alors que je pratique l'écoconduite (jamais à la vitesse max autorisée à partir de 70 km/h, usage intensive du frein moteur), le WLTP sous-estime la consommation d'environ 1 L/100. Ce qui pour des voitures consommant en moyenne 5-5,5L/100 km n'est pas un détail non plus.

Bref, ce cycle est fait pour handicaper le thermique et favoriser l'arnaque, pas nouvelle, de l'hybride passée en surmultipliée avec le PHEV.

Pas vraiment, c'est un effet de bord mais le thermique aussi est vendu comme plus vertueux qu'il ne l'est réellement.

Quand on compare sur long parcours avec un diesel moderne, pour ma part avec la Série 3 break actuelle (2l diesel bi-turbo avec BVA 8 rapports) je fais de 850 à 1100km selon la lourdeur du pied (57l de réservoir consommés moins la fraction de réserve entre son allumage et la pompe, soit typiquement 52/53l consommés): A voir les tarifs de charge rapide sur autoroute, même économiquement le VE n'a aucun sens.

Normalement tu ne charge pas uniquement sur des bornes à charges rapides qui sont effectivement chères.
Si tu charges ailleurs cela devient plus intéressant.

Après je dirais que l'aspect purement économique d'un choix de motorisation me semble être une mauvaise approche, le coût est un facteur important mais ne doit pas être le seul critère de décision.

C'est pas évident de demander au client si je vais pouvoir recharger la voiture chez lui.

Si c'est juste 100 km, la voiture peut faire l'aller-retour facilement, avec charge potentielle chez le loueur ou éventuellement une charge rapide au retour si jamais le client ne permet pas la recharge par exemple.

Je ne vois pas trop le soucis dans les faits. Oui la charge rapide c'est souvent plus lent qu'un plein d'essence mais on n'est clairement pas dans un problème si bloquant que cela pour la plupart des usages.

Pour la location, le VE n'est clairement pas adapté et cela a coûté son poste (et mis la boite en danger) au PDG de Hertz qui avait trop misé là dessus aux USA il y a environ 1 an.

Après c'était avant et aussi aux USA, les contraintes, besoins et infras ne sont pas forcément les mêmes.

Sans oublier les à priori de nombreux automobilistes.

Je pense en vrai que c'est faisable, y'a bien des taxis ou auto écoles qui tournent avec. Mais la transition prendra du temps.

Pour une fois je n'ai pas répondu, c'était dans ma TODO list mais j'ai oublié car légèrement débordé. Je n'ai d'ailleurs toujours pas lu les derniers livres reçus :)

Merci de m'avoir récompensé encore une fois et désolé de ne pas avoir répondu pour au moins décliner !

Le fait qu'il ne semble même pas y avoir songé me laisse perplexe sur les choix réalisés par la direction de Mozilla…

En quoi le fait qu'il demande une clémence envers Google signifie qu'il n'a pas songé à des alternatives de financement ?

Cela fait des années que Firefox et Mozilla cherchent des alternatives, la réalité c'est qu'un business model sur ce créneau reste compliqué et qu'en dehors des grands acteurs du développement logiciels, les navigateurs indépendants reposent souvent sur des partenariats de ce type.

Cela n'est pas un sujet évident.

Wow tu es toujours dans les parages ? :)

J'espère que tu vas bien depuis le temps. ;)

On voit que dans le cas présent le problème ne se manifeste que si tu manipules des dates anciennes ou très lointaines dans le futur.

Une comptabilité ne va probablement jamais manipuler de telles dates avant des siècles. À l'époque cela devait vraiment être une considération secondaire et même aujourd'hui pour ce cas d'usage l'impact reste marginal.

Après oui les tableurs ont un champ d'utilisation plus large, où l'impact peut être réel cette fois, mais ce n'est probablement pas le cas le plus courant. Et à l'époque cela n'avait pas été conçu ainsi.

Tu oublies les 10 jours à faire sauter, et le fait de repasser en calendrier julien avant 1582. Et certaines opérations sont plus longues, comme calculer le jour de la semaine du 14 février 1435 (pas d'autre choix que de compter le nombre total de jours depuis une date de référence puis calculer le reste de la division euclidienne par 7).

Après Excel comme tout tableur a été conçu avant tout comme un outil pour gérer de la comptabilité.
Gérer des dates aussi loin dans le passé n'était probablement pas dans leurs préoccupations initiales.

En fait les développeurs d'IA dites OpenSource ne publient en général que le résultat : la liste des poids du réseau de neurones.

Ce n'est pas rien, ça permet de tester sur ses propres machines. Par exemple pour ChatGPT c'est impossible car ils ne publient pas ça.

Mais c'est loin d'être équivalent à l'OpenSource ou du Libre au sens des logiciels. Il faudrait les données d'entrainement et le code qui le génère pour que le résultat soit similaire en un sens.

Un abus de langage donc de la part de ces développeurs.

mais d'une façon générale, je suis allergique à ce genre d'argument. On pourrait prendre presque tous les exemples de la vie quotidiennes pour le démonter…

Mais on peut retourner cette logique contre toi dans le sens où sous prétexte d'un changement possible, on ne fait plus rien car on n'a aucune garantie que cela n'ira pas dans un sens qui ne te plaît pas.

Être prudent c'est bien, mais si c'est basé sur rien de bien concret finalement ça n'avance pas à grand chose et n'est pas forcément pertinent.

Je n'ai bien sûr pas d'éléments précis et j'espère bien sûr que la diversité restera (mais comment pourrait-elle l'être au même niveau alors que les forces disponibles sont en quantité limitées?)

Il y a de toute façon plein de distros différentes dont plein qui finalement réinventent la roue. Ces ressources pourraient être utilisées pour maintenir des modèles de distributions différentes justement. Si du moins assez de personnes sont convaincues que cela en vaut la peine évidemment.

Pour l'instant il y a bien plus de gens qui ne croient pas au système atomique comme système universel que l'inverse. Aucune distribution majeure n'a encore un plan pour en faire des systèmes principaux et n'a annoncé l'abandon de l'ancien modèle. La plus avancée sur ce terrain là, à savoir Fedora, en est encore loin de ce stade en fait.

Et si tout le monde bascule un jour aux versions atomiques, c'est que les contributeurs auront tous été convaincus de l'intérêt de la chose. Dans ce cas, où est le problème ? Tu veux faire quoi pour les en empêcher ? Les punir, les attacher ? On ne peut pas, et ces contributeurs ne nous doivent en fait rien.

Le code est libre, cela ne signifie pas que quelqu'un doit nécessairement faire le sale boulot pour nous faire plaisir. Si personne ne veut maintenir une distro à l'ancienne (ce qui est à ce jour très hypothétique, perso je n'y crois pas vraiment), ainsi soit-il. S'il y a assez de gens convaincus par l'intérêt de la chose, cela continuera quitte à devoir financer des gens pour cela.

Je ne vois pas pourquoi on devrait râler car des gens tentent des choses en fait. C'est l'essence même du libre de pondre du code pour ses propres besoin, et si les développeurs veulent faire ça, qui est-on pour les en empêcher ? Avec quel prétexte ? Même si le résultat ne te plaît pas, c'est leur doit aussi.

Tout à fait, globalement pour atteindre la température idéale du moteur (autours de 90°C), il faut rouler, préchauffer sans rouler n'apporte pas de vrais gains.

Il est recommandé de rouler tranquillement jusqu'à cette température de toute façon, je dirais que même après ce n'est pas une mauvaise chose pour la consommation de carburant et le bon fonctionnement des instruments.

Quand il fait froid, prendre son mal en patience le temps que le moteur chauffe, quand il fait chaud, quand c'est possible laisser les fenêtre légèrement ouvertes (moins de la taille d'un doigt) pour limiter l'effet serre fonctionne bien, et évidemment ouvrir les fenêtres et portes quand on s'installe pour évacuer le gros de la chaleur avant de partir fonctionne mieux et limite la consommation liée à la clim qui prendra le relais une fois que l'excès de chaleur a été enlevée de l'habitacle.

J'utilise beaucoup docker et docker-compose pour mes applications Web. Du coup, ce n'est pas du tout pareil avec Toolbox alors…

Ce sont les mêmes technos mais pas le même usage.

Les container ont l'air de se persister même au redémarrage et du coup, on peut tout installer dessus à la main si je comprends bien. Mais il n'y a pas un conteneur pour l'appli, un autre pour la base, etc.

L'objectif n'est pas d'avoir une application par conteneur, il faut plus le voir comme une machine virtuelle légère. Le but est de pouvoir facilement travailler sans pour autant toucher au système principal ni avoir des conflits avec d'autres projets par exemple.

Donc oui tu mets plus d'éléments dedans contrairement à un usage applicatif des conteneurs où tu vas chercher à avoir le plus petit conteneur possible et en isolant au maximum les composants entre eux.

Google depuis longtemps migre des éléments de la couche Android de base vers ses services Google Play.

C'était pour eux le meilleur moyen de permettre de mettre à jour les composants du téléphone pendant longtemps sans que les constructeurs aient la main mise dessus. Car ils étaient très réticents à maintenir longtemps le système de leur appareil. Et cette fragmentation est un problème de Google tant pour la sécurité du système mais aussi pour la possibilité de distribuer des applications compatibles.

Quand une version avec ostree est "pinned", ça veut dire qu'elle ne sera jamais effacée ?

Tant que tu la gardes dans cet état, en effet. C'est justement tout l'intérêt du concept.
L'idée est que normalement tu as deux versions du système A / B. Quand tu utilises A, tu mets à jour le système, tu bascules sur B. En cas de pépin tu peux revenir sur A. Mais si une nouvelle mise à jour intervient alors que tu utilises B, A devient alors C et ton prochain boot l'utilisera. A disparaît du système.

Si tu avais pinné A avant, A serait conservé.

Quand on fait un rpm-ostree install, c'est pareil que quand on fait un dnf install ? C'est les mêmes dépôts ?

Les mêmes dépôts oui, l'impact sur le système est un peu différent cependant.

On peut installer un grand nombre de logiciels avec rpm-ostree ?

Techniquement tu peux installer ce que tu veux avec.

Ca ne dénature pas la distribution ? Par exemple, si j'ai besoin d'inkscape, pourquoi est-ce recommandé d'utiliser Flatpak ?

Tout le concept du système atomique est d'avoir cette base atomique la plus petite possible. Si tu commences à ajouter de grosses applications dessus, tu perds un peu l'intérêt du concept. Cela ne doit être réservé qu'à des cas spécifiques, normalement des outils pour lesquels tu n'as pas trop le choix et qui sont souvent petits comme des utilitaires en ligne de commande ou des pilotes par exemple.

L'objectif d'avoir cette base petite et légère est multiple :

• Plus tu es proche de l'image d'origine de Silverblue (par exemple), comme la base est la même chez tout le monde, la fiabilité et l'intégration sera mieux testée et plus fiable. Si tu ajoutes des composants en plus, des problèmes pourraient survenir plus facilement ;
• L'objectif est notamment que l'image de base serve à démarrer ton système dans un état correct pour éventuellement revenir à la version précédente automatiquement en cas de problèmes. Plus tu ajoutes des composants dans l'image de base, plus le risque d'un blocage apparaît. Pas forcément avec inskscape mais avec d'autres cela peut arriver plus facilement ;
• Ajouter des couches dans rpm-ostree rend les opérations d'ostree plus lentes ;
• Les Flatpak proposent de l'isolation des processus ce que ne font pas les applications RPM standards. Tu perds cette capacité. De même, le Flatpak te permet plus facilement d'avoir une version à jour ou commune à d'autres distros si tu en as besoin.

C'est optimisé du coup sur les versions atomiques ?

La techno Flatpak est la même que tu sois sur Fedora Linux classique ou Fedora Silverblue par exemple. Les inconvénients que tu observes seront les mêmes.

Autre petite question sur Flatpak, pourquoi n'y a t-il pas plus de webapp empaquetées ? (genre nextcloud, nodered, n8n, appsmith, …) C'est une limitation technique ?

J'en sais rien du tout.

J'ai pas encore bien compris l'intérêt de toolbox (ou toolbx), c'est bien pour faire des container facilement ??

Flatpak est conçu pour les applications graphiques mais pas pour le reste.
Toolbox permet de facilement créer des conteneurs exploitables. Par défaut tes conteneurs ont accès à ton répertoire utilisateur, peuvent dialoguer avec Wayland ou DBus pour interagir avec le reste du système, etc. L'intégration est plus simple et bien meilleure.

Tu as du coup les avantages et inconvénients des conteneurs comme d'habitude. Pour les développeurs c'est le meilleur moyen de travailler sur des systèmes atomiques, tu fais le conteneur lié à ton projet ou ta techno et tu as les outils qu'il te faut sans polluer le système et quand tu as fini tu peux facilement le virer aussi.

Mais ça ajoute une couche en plus.

j'ai prouvé que c'etait viable, aurait tu un quelconque lien vers lkml ou un code source sur kernel.org qui PROUVE ce que tu dis ici ?

Tu n'as rien prouvé du tout.

Le simple fait que ce ne soit pas dispo même quand l'option est active montre le contraire.

La meilleure solution semble de récupérer un framebuffer virtuel via le sous-système DRM comme effectué ici : https://github.com/embear-engineering/drm-framebuffer
Pas testé mais ça peut fonctionner, ça rempli le job voulu mais ne passe pas par l'ancienne interface et ajoute un peu de complexité pour obtenir le framebuffer.

Évidemment cela ne peut pas fonctionner si un environnement graphique est lancé.