karteum59 a écrit 868 commentaires

Pour le moment ce n'est pas le cas de la parti radio (wifi/bt) comme pour beaucoup de chip (j'ai vraiment jamais compris cette obsession…)

Je vois au moins deux raisons possibles

• il n'est pas rare que la partie radio fasse intervenir des blocs / IPs / softs tierce partie, ce qui complique juridiquement la chose
• la radio, c'est touchy… Les radios aujourd'hui sont souvent des SDR, et si tu ne fais pas extrêmement attention tu as vite fait d'avoir des émissions non réglementaires (au mieux dans ta bande de fréquence e.g. en ne respectant pas le "polite spectrum access", au pire dans d'autres bandes : par exemple si tu fais du clipping n'importe comment sur un signal OFDM tu te retrouves avec un truc qui bave à fond dans les canaux à côté, et faut aussi faire gaffe à l'intermodulation, etc.). L'équipement est certifié conforme (avec son marquage CE) dans un contexte hardware/firmware précis.

Les devs Linux ont à mon avis trouvé un compromis plutôt bon entre quelque chose d'ouvert mais néanmoins de raisonnablement contraint (pour le peu que j'ai regardé, il me semble que le système CRDA/regdb est suffisamment bien fait pour qu'il soit difficile de sortir des clous involontairement). Mais c'est un sujet récurrent chez les régulateurs que d'imposer un hardware/firmware verrouillé pour ne pas laisser l'usager faire n'importe quoi avec la radio.

(pour donner un exemple : les radars météo sont aujourd'hui fréquemment brouillés par des AP wifi 5 GHz, au point que nombre d'entre eux sont désormais contraints de changer de bande - aux frais de Météo France qui ne roule pourtant pas sur l'or - alors que ce sont eux les usagers primaires. Le DFS était sensé les protéger, mais entre les mauvaises implémentations et les usagers qui bidouillent pour le désactiver parce que "ça rend le wifi plus instable" la bande est désormais pourrie pour les radars… Et je rappelle que la météo ce n'est pas juste les 5 minutes à la TV pour te dire s'il fera beau demain, mais c'est aussi la sécurité aéronautique et maritime)

En 2025 les ordinateurs fonctionnent toujours en manipulant des « mots mémoires », des « adresses ». Leurs architectures n’ont fondamentalement pas changé.

Tout le monde n'est pas de cet avis (voir par exemple "C Is Not a Low-level Language - Your computer is not a fast PDP-11")

Rien de très nouveau pour ceux qui connaissent bien le sujet, mais j'ai appris énormément de choses avec ce post (le même en VO) sur la complexité d'Unicode, la nuance entre caractère, point code et graphème ("un point-code n'est pas toujours un caractère unique" alors que naïvement je pensais au départ qu'un bloc de 32 bits en UTF-32 représenterait toujours un caractère…).

Tu peux opter pour un smartphone qui soit conçu de série sans port USB tel que le Meizu Zero (mais faut accepter le spyware chinois qui vient avec :)

Bon après, Roland Jacquard ("considéré par CNN en 20028 et par Newsweek, en 2005, comme un expert français de référence en matière de terrorisme") nous disait il y a pas si longtemps dans C dans l'Air que le C++ était une arme de terroriste :)

l'un mérite le rebut pour recyclage (…) le choix me semble vite fait => rebut (…) un facteur 10 de consommation à l'utilisation me semble pour toi — comme pour moi — à sélectionner celui qui apporte le plus de fonctions et le moins de fuite en avant sur la consommation

Tu n'as pas répondu sur le point principal de mon post : ce qui est énergivore est avant tout la fabrication des machines : il est évident que si on regarde la facture d'électricité au niveau individuel, on préfèrera une machine moins énergivore. Il n'empêche que sur un plan global (CO2/ressources), mettre au rebut des machines parfaitement fonctionnelles est extrêmement dommageable sur le long terme. Il faut avant tout prolonger la durée de vie des machines existantes (donc moins en mettre au rebut) pour moins en fabriquer de neuves !

Tout ce qui est Pentium 4 (trop energivore) et en dessous, au revoir _o/

On rappelle quand même que ce qui est énergivore est avant tout la fabrication des machines (+ l'extraction minière derrière) et non leur utilisation (même avec un P4). Bref sur le plan global/environnemental prolonger la durée de vie d'un P4 vaut toujours la peine (surtout en France où l'électricité est décarbonée !)

"Depuis 2000, toutes les unités centrales sont de couleur noire donc ce matériel a été fabriqué avant et donc trop vieux": Archi-faux!

Pareil, j'ai sauté au plafond en lisant ça !
N.B. J'ai reconditionné nombre de machines plus anciennes que du Core i3 (on peut souvent faire un petit effort en montant la RAM au max, etc). Au nom de quoi n'aurait-il "plus trop d'espérance de vie" ? Et sans rentrer dans les détails je trouve que tout le tableau de "critères de non prise en charge / explications" est plus que douteux… à moins que Emmaüs croule sous les machines modernes lui permettant de faire la fine bouche ?

"Le top du top étant un portable 🙂"

Bof, un portable signifie souvent justement une machine moins réparable et moins robuste…

N.B. je suis en revanche d'accord sur une chose même si je ne place pas le curseur au même endroit que l'auteur : en dessous du Athlon/Duron 1000 / 1 Go de RAM, on entre dans un territoire où malheureusement même avec les distros les plus légères (LXQT/Falkon/Abiword…) la machine va ramer avec un usage "moderne" (i.e. avec du web, avec l'absence de support de ssse3, etc.). ça n'empêche pas pour autant de réutiliser ces machines, qui sont toujours capables de faire ce qu'elles faisaient il y a 25 ans (e.g. traitement de texte + impression avec Word97, etc)

Mais j’avais déjà noté la levée de boucliers quand son langage favori n’est pas en tête,

Le problème n'est pas que notre langage "favori" soit en tête ou non (d'ailleurs en ce qui me concerne je n'ai pas de langage vraiment favori) mais que les résultats soient douteux et la méthodologie derrière aussi. Les bonnes pratiques de conception ou d'éco-conception ne peuvent pas se réduire à "tel langage est plus performant / plus économe" (je ne sais pas si les gens se rappellent d'une ancienne version de Gnome où Nautilus mettait je crois environ 70 secondes pour afficher /usr/bin, bien qu'étant codé en C…).

Dans mon cas, il est possible que mon code Python/numpy/Geopandas soit plus performant que la même chose écrite en C (car en l'absence de "pénalité" sur les boucles je n'aurais peut-être pas naturellement vectorisé mon code de la même manière, or le fait de vectoriser permet de mieux utiliser le SIMD et le cache du CPU).

Mouais bof, je ne suis pas spécialement convaincu par ce tableau ni par la méthodologie (et apparemment je ne suis pas le seul quand on regarde les commentaires). Pour les cas que je connais, je suis en particulier sceptique sur

• n'avoir qu'une seule case "Python" car ça ne permet pas de distinguer le cas où on fait du "pur" python (assez rare) et le cas où en réalité la majorité du temps se passe dans une lib écrite en C/C++ (e.g. numpy). Idem pour Perl d'ailleurs
• Fortran 4.2x plus lent que le C ?? (alors qu'il est au contraire plus efficace car le compilo est davantage en mesure de faire des optimisations poussées)
• Lua dernier ? (il est souvent plus rapide que Python, sans même parler de LuaJIT)
• Java plus efficace que Go et OCaml ? …

De plus, tout dépend de la manière dont on code. Le C avec GObject est-il un modèle de légèreté/concision/sobriété ? (je ne devrais pas trop juger car je ne connais pas bien, mais à l'époque où j'ai regardé je n'ai pas du tout aimé…)

mais qui sont de plus en plus écrits en Python, et qui bouffent je ne sais combien de ressources CPU lorsqu'ils se réveillent

Je ne pense pas que mes softs en Python/numpy/geopandas soient tellement plus consommateurs de ressources que la même chose écrite en C (le Python est essentiellement un wrapper autour de libs elles-mêmes écrites en C/C++…)

Tu aurais pris un meilleur exemple en parlant du web ou d'Electron ou de ces articles…

Sur Wikipedia on trouve: https://en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM

Et sinon quelques liens en vrac (même si certains datent pas mal et sont peut-être obsolètes): 1, 2, 3

On sait trés bien qu'il ne faut pas croire tout ce qu'on lit sur internet (c'est Victor Hugo qui l'a dit, je l'ai lu quelque part…).

Ouais, Lincoln aussi… :)

La manipulation d'image et de photos existe depuis que la photographie existe, bien sûr pas à une telle échelle et avec une telle facilité, mais maintenant qu'on est au courant, il faudra juste adapter nos curseurs de croyance, et ne plus prendre une photo comme une preuve de quoque ce soit.

Je ne suis pas sûr que la prise de conscience du grand public (et encore moins des décideurs politiques) aille aussi vite que le développement fulgurant de l'IA dans nombre de domaines (ce qui inclue la désinformation, mais aussi plein d'autres choses. Une des choses qui m'inquiète est la capacité d'automatiser le hacking de systèmes (aujourd'hui pénétrer un système, scanner un environnement, s'y adapter et utiliser metasploit en fonction de cela requiert des compétences pointues, là où demain on pourra voir des armées de bots faire ce taff).

N.B. Microsoft (mais aussi plusieurs autres startups) a récemment annoncé être capable de faire dire n'importe quoi à n'importe qui sur la base de 3 secondes d'enregistrement d'une personne cible. Les tribunaux vont s'amuser… (et à l'inverse s'ils n'en prennent pas conscience à temps, des innocents seront un jour envoyés en prison sur la base de preuves forgées de toute pièce…)

Il y a longtemps j'étais tombé sur ce programme (Ant is Not TeX :). J'ai l'impression que c'est abandonné mais ça m'avait semblé assez complet.

(et il y a encore plus longtemps, j'étais tombé sur Lout qui semble être tombé dans l'oubli donc ce post est l'occasion d'en reparler :)

Un jour surtout, on taxera l'énergie (qui fait fonctionner les machines-outils qui fabriquent en série nos iBidules neufs à un coût défiant toute concurrence, rendant de fait toute réparation impliquant une activité humaine non "rentable" sur le plan pécuniaire).

D'ici là, et comme on n'a toujours qu'une planète (mais plus pour longtemps à ce rythme), c'est toujours mieux que rien qu'un tel indice (fut-il imparfait) existe, et que "quelques activistes" (qu'on espère chaque jour plus nombreux) aient des solutions pour réparer leurs devices (avec un moyen d'évaluer les produits les moins mauvais, avec des boîtes comme Fairphone qui se positionnent sur ce créneau, etc)

=> Je pense désormais passer sur Alma Linux (au moins c'est du "vrai" support à long terme sur les MAJ de sécurité. OK les softs sont anciens mais dans ce cas d'usage "if it aint't broken, don't fix it")

Bon, rectification: Alma Linux marchait très bien en test dans ma VM chez moi, mais au moment de l'installer sur un (vieil) ordinateur familial je me suis payé un magnifique kernel panic au boot (idem avec Rocky Linux), expliqué par le fait que le jeu d'instruction x86_64-v2 est désormais requis (plus d'infos sur ce que ça implique ici. Autant j'étais au courant de la fragmentation (et des exigences différentes entre distros) sur x86, autant je ne m'attendais pas à voir de la fragmentation sur x86_64…).

=> Bref Red Hat n'est pas copain avec le vieux matos, et du coup ça sera Debian (que je connais mieux de toute façon mais qui a un support à long terme moindre que RHEL… :-/ )

Je pensais que c'était le cas d'ubuntu, mais apparemment cette distribution est également décriée pour sa gestion des mises à jour, à moins de ne prendre que la version LTS

J'ai mis des xubuntu LTS pendant des années chez mes proches dans ma famille. Après l'arrêt du support de 18.04 je me suis décidé à faire la MAJ 18.04->20.04->22.04, et ça a cassé plein de choses (aussi bien au niveau de l'impression "driverless" que du boot 2x plus long, une impression générale de lenteur, thunderbird qui a apparemment changé de format de profil, des interfaces qui changent et qui déroutent l'utilisateur par rapport à ses habitudes…). OK c'est du vieux matos, mais rien qui justifie de telles régressions. J'ai essayé de réinstaller 22.04 from scratch, sans vrai résultat convaincant.

=> Je pense désormais passer sur Alma Linux (au moins c'est du "vrai" support à long terme sur les MAJ de sécurité. OK les softs sont anciens mais dans ce cas d'usage "if it aint't broken, don't fix it")

C'est peut-être un chouia hors-sujet, mais dans la même veine : j'ai un téléphone fonctionnant sous LineageOS/MicroG (donc sans le Google Play officiel ni le spyware Google Service Framework). SNCF Connect s'installe via Aurora et me permet d'acheter les billets grandes lignes, mais en revanche impossible de lui faire acheter des billets transilien (qui nécessitent le NFC) : l'appli refuse de fonctionner et me renvoie "vous n'êtes pas éligible à ce service : votre téléphone est actuellement rooté ce qui vous empêche d'accéder au service proposé" (je n'ai pourtant pas rooté mon téléphone après l'install LineageOS, mais évidemment mon bootloader est déverrouillé…). Evidemment, les bornes transilien ne proposent pas de billets hors IDF (les lignes vont parfois plus loin que le bout de l'IDF, et dans l'autre sens certaines gares n'ont ni personnel ni automate !)… Bref c'est une plaie !
Doctolib refuse aussi de fonctionner sur mon smartphone (mais au moins l'appli web fonctionne, contrairement à transilien qui n'offre aucune alternative au NFC).

Pas encore essayé avec Magisk. Mais je suis extrêmement agacé par ces comportements alors que le recours à un firmware open-source est un moyen de prolonger la durée de vie de son ordiphone.

lignes != caractères

Oups j'ai lu trop vite… Bon, cela dit dans l'exemple pris plus haut, copilot renvoyait plus que 150 caractères ! Et en fait je pourrais aussi dire qu'il peut y avoir des petites révolutions en 150 caractères (l'exemple ci-dessous avec fast inverse square root qui a eu à l'époque un impact majeur dans Quake :)

float Q_rsqrt( float n ) {
long i;
float x2, y;
const float th = 1.5F;
x2 = n*0.5F;
y  = n;
i  = * (long *) &y;
i  = 0x5f3759df - (i>>1);
y  = *(float *) &i;
y  = y*(th-(x2*y*y));
return y;
}

(bon OK, 191 caractères ici. Mais tu vois l'idée… :)

rappelons que le libre n'est pas synonyme de copyleft (…)

Je ne dis pas le contraire. Je dis juste que le sujet des AI comme copilot qui renvoient du code copyrighté pose un problème qui ne peut être éludé (que ce soit dans le cas où qqun réutilise du code non-libre et non supposé être utilisé, ou dans le cas inverse ou du code GPL sera intégré à l'insu de l'utilisateur dans une appli non-GPL).

C'est quoi qui est nouveau? L'automatisation. Et ça change un truc légalement? Tu ne l'as pas démontré

Cette automatisation fait que le "programmeur" qui utilisé du code généré par copilot peut se retrouver à utiliser du code copyrighté à son insu. Et oui: ça pose problème !

Si lors d'un exam tu ressors l'algo quicksort vu en cours, personne ne te dira rien (c'est au contraire ce qu'on te demande). Par contre si tu te fais choper à copier sur le voisin (aux noms de variables et aux fautes près), tu te feras sanctionner ! Bref il y a une limite et une nuance…

la majorité des gens faisant du code libre se fout complet qu'on leur "pique" 150 caractères de code…

N.B. on peut faire une foule de choses en 150 lignes ! :). 150 lignes c'est nettement plus que "quelques lignes depuis stackoverflow".

La communauté "libre" attache précisément de l'importance au respect des licences (et en particulier à ce qu'il ne soit pas illégalement volé/redistribué sous une autre licence notamment non-libre). De plus tout le code sur Github n'est pas nécessairement du code libre et personne n'a envie de se voir attaqué par le propriétaire légitime d'un morceau code qui aurait été généré via Copilot.

D'autant qu'en fait ladite "intelligence" a été entrainée sur des données réelles. L'exemple des bouts de code générés par Github Copilot quasi-équivalents à du code copyrighté utilisé pour son entrainement est édifiant et pose réellement question…

Oui, des solutions existent mais est-ce que des instances sont disponibles ?

https://cryptpad.fr/ par exemple pour accéder à des instances OnlyOffice ?
(bon par contre si toute l'EN se mettait à l'utiliser je suppose que leurs serveurs exploseraient… :)

Au risque de passer pour un noob : quelqu'un peut-il m'expliquer ce qu'est GraalVM ? (oui je sais, Google est mon ami (même si pas tant que ça :) et en fait j'ai entendu parler de graalVM depuis longtemps. Mais comme Java me donne des boutons je n'ai jamais regardé de près…). Ce qui pique un peu ma curiosité est notamment qu'ils parlent de Python/Ruby/WASM/… et pas seulement de Java.

=> est-ce que c'est une réimplémentation alternative de la JVM (indépendante de celle d'Oracle et de OpenJDK) ? Et un peu comme la CLR de Microsoft (que je ne connais pas bien non plus) ils se sont mis en tête de supporter d'autres langages, c'est ça ?

Il faudrait voir ce que donne un sqlite compressé read-only

ça existe !

Mais en général, les performances d'accès à un fichier sont bien plus rapide que les performances d'accès à un élement d'une base de donnée

ça se discute…