cg a écrit 1869 commentaires

Je me base sur l'analyse dans l'article de "dark mentor" mentionné par Benoît. Il y est expliqué entre autres que ça affaibli les fonctions comme Secureboot, par exemple.

Attendons quelques semaines pour voir si une attaque sympa voit le jour :).

Déjà c'est super chouette que Espressif fasse une réponse. Cette réponse se veut rassurante, et est l'est partiellement.

Toutefois elle confirme que ces commandes devraient être désactivées au moment du passage en production :

Internal Debug Commands: These commands are meant for use by developers and are not accessible remotely. […] Espressif will still provide a software fix to remove these undocumented commands.

Peut-être que ce sera fait via un fusible matériel dans de futures puces ?

Mais aussi :

Having such private commands is not an uncommon practice.

Et là, ça en dit long sur l'état de l'Internet des objets :-/ … Laisser disponible des commandes permettant de contourner des niveaux de sécurité est donc courant… mais est-ce souhaitable pour autant ?

Petition pour renommer __init__ en __boa__ pour pouvoir les appeler des boas constructeurs (la blague est mieux meilleure en Anglais).

En résumé, l'intention importe peu : si des commandes "cachées" permettent d'abuser des fonctions prévues par le composant, alors elles seront découvertes et seront abusées.

Ce genre de commande pourraient être neutralisées par un fusible interne après les phases de test de qualité du composant.

Pour confirmer ton argument : j'ai vu Python utilisé aussi dans des labos au CEA pour piloter des expériences de recherche en physique quantique. Python n'est pas spécialement temps réel, il s'agit d'un moyen simple pour des chercheuses et des chercheurs qui ne sont pas forcément des brutes en programmation de mettre au point leurs expériences. Derrière, il y a du R, du C, et des matériels très précis.

Il faut garder en tête que Python est un héritage de ABC, un langage simple pour apprendre à programmer. C'est une des raisons de sa popularité.

Si tu parles d'entrées dans le menu UEFI, tu peux aller voir dans /boot/efi/ et supprimer ce qui ne te sers pas. Sur certaines distributions, il faut monter manuellement cette partition (par exemple avec mount -o rw /boot/efi).

Si tu parles d'entrées dans le menu Grub, update-grub devrait suffire.

Python en production, ça peut le faire pour de petites applications. Mais dès que ça monte en charge, ou que l'application devient complexe, Python ne tient plus.

Mais je pense aussi que le problème de python, c'est que la plupart de ceux qui en font ne sont pas formés à ça et se retrouvent à développer du code pourri, qui certes a l'air de fonctionner, mais qui est difficile à maintenir ou se trouve lent à l'exécution parce que les gens qui ont développés ne se sont pas posés de questions.

Tu peux faire la même généralité¹ pour PHP, c'est peut-être vrai mais au final peu important. Pourquoi ? Car la majorité des sites Internet n'ont pas besoin d'être hyper-performants ni de pouvoir monter en charge.

Malgré que ce soit un langage pour crétins décrié par les sachant·es, PHP fait tourner 80% des sites Internet dynamiques (dont une bonne proportion est Wordpress, un CMS à la réputation de bloatware scandaleux).

Les 20% des sites qui doivent être performants concentrent probablement plus de 90% du trafic. Et ces sites à forte charge ou chaque seconde de pages vues vaut des fortunes, ont besoin de code rapide et propre, en Go, Rust, .NET ou que sais-je, avec des CDN et des bases de données rapides. Et pour cette minorité de services, nous sommes d'accord.

J'ai acheté un smartphone d'occasion il y a un an (un iPhone SE première génération à 70€) pour pouvoir m'inscrire à ce service et valider un dossier de formation. J'étais un peu pressé, et cette formation était importante pour moi. Et pour répondre à la question de départ, ça a été assez simple et rapide - probablement le principal avantage d'être sur une plateforme fermée comme iOS.

J'en ai profité pour régler la question du gestionnaire de mots de passe et du TOTP quand je ne suis pas chez moi, avec les applis BitWarden.

Depuis, j'utilise ce téléphone, 10 minutes par jour selon l'appli "temps d'écran". À ma grande surprise, je suis super discipliné et, agrément inattendu, j'ai un plaisir indicible à envoyer balader les personnes qui me demandent d'installer WhatsApp :).

Je ne sais pas si tu connais mais il existe une commande interne, un builtin, nommé help.

Jusqu'à la lecture de ton message, je passais un temps fou à chercher le bon endroit dans la très longue page de man de bash, pour vérifier les options de commandes comme set ou read.

Alors mille mercis !

Super, merci ! Et bien vu, c'est en effet FiraCode dans QTerminal. Certaines ligatures sont très belles.

Merci ! Et donc la doc de [ se trouve dans la page de manuel de test.

Truc marrant d'ailleurs, sur un terminal dans une VM Kali Linux, je regarde la page de man de test, et je vois des opérateurs comme ≠, ≥ et ≤. Je me dis tiens c'est moderne dis-donc, tiens (dis-donc).

Et en passant le curseur dessus, et bien le ≠ se change en !=, et le ≥ en >=. Je n'avais jamais vu ça avant, c'est le terminal qui interprète les séquences. Je ne sais pas trop si j'aime ça dans le cadre de lecture de doc sur la syntaxe d'un commande, mais ça m'a intrigué :p.

Au Royaume-Uni c'est en cours.

pourquoi le code suivant, dont les seules différences sont les espaces dans les accolades, produit-il une erreur ?

Parce que le mot-clé { n’est pas reconnu comme tel sans cet espace ?

Oui, certainement, la question est pourquoi ce n'est pas reconnu. Sans doute un truc historique défini au néolithique et qu'on se traîne encore :).

C'est amusant que bash ne sache pas s'en sortir sans les espaces. C'est un comportement plutôt rare dans les langages de programmation. Il y a la même chose avec l'opérateur [[ ]] :

[[ $a -lt 10 ]] -> ok
[[$a -lt 10]] -> erreur de syntaxe

D'ailleurs, depuis quelques versions de GNU tar (un peu moins de vingt ans?), on peut lui donner l'option a pour auto-compress:

tar caf toto.tar.xz
tar caf toto.tar.lzma
tar caf toto.tgz
tar caf toto.tbz

$ file toto*
toto.tar.lzma: LZMA compressed data, streamed
toto.tar.xz:   XZ compressed data, checksum CRC64
toto.tbz:      bzip2 compressed data, block size = 900k
toto.tgz:      gzip compressed data, from Unix, original size modulo 2^32 66549760

tar détecte tout seul l'extension. Pareil pour décompresser, plus besoin de préciser le type de compression utilisé, tar xf suffit.

Et comme il se disait à la rédaction de Charlie Hebdo : Cabu boira.

ici: https://participer.passageenseine.fr/ :)

… je vous propose une variante, en shell bash¹.

Pour quelle valeur de a le code suivant se comporte-t-il correctement ?

~$ a=16
~$ a(){ a|a& };a

Question subsidiaire, mais je trouve bien plus intéressante et moins potache : pourquoi le code suivant, dont les seules différences sont les espaces dans les accolades, produit-il une erreur ?

~$ a=16
~$ a(){a|a&};a
bash: syntax error near unexpected token '{a'

Qu'on m'explique : par défaut, systemd et sa config sont bien supposés attendre que le réseau soit UP pour tenter des montages ? (J'attends plus que "ça dépend", merci)

Alors pourquoi ne le fait-il pas avec cette carte ? Ma supposition : le driver. La conséquence : un client DHCP plus lent ? Et alors ? Pourquoi "ça" n'attend pas que le réseau soit UP ?

Sur Debian et ses dérivés, quand une interface réseau est déclarée avec allow-hotplug dans /etc/network/interfaces, cette interface n'est pas prise en compte par la chaîne de dépendances genre "wait-network-online", car l'interface peut apparaître bien plus tard, ou jamais (c'est le sens de "hotplug" dans ce contexte, une interface USB ou que sais-je), et ce serait absurde de l'attendre.

C'est peut-être (désolé) ce qu'il se passe dans ton cas ?

Il y a aussi le docu Travail à la demande qu'on peut regarder sur arte.tv moyennant quelques euros. Il a été partagé en lien.

Le thème autour de Mechanical Turk est pertinent concernant ces "centaines de milliers d'emplois".

L'IA c'est comme la machine à vapeur en son temps, cela détruit des emplois de force et en créé d'autres un peu moins pénible… et comme l'humain en demande toujours plus il y aura toujours du travail pour tous…

Non, non, il faut surtout passer d'une société dans laquelle le revenu est fondé sur le travail à autre chose. C'est très ancré culturellement, mais c'est ridicule de rester sur le système « qui ne travaille pas ne doit pas manger ».

De la même manière qu'un morceau est rarement potable et encore moins un tube dès le départ, entre ce qui arrive dans un studio et ce qui en sort, il y a parfois un monde.

Pour que la trame de ce que peut pondre un·e humain·e ou une machine (que ce soit via algo classique comme on sait le faire depuis 30 ans au moins, ou par un truc genre machine learning, peu importe), la production va faire des retours, les compos vont être retouchées… S'il y a du potentiel, il faut en faire quelque chose, et c'est rarement le cas dès les premières étapes, sauf exceptions.

Si je fais un parallèle, une de mes filles est pas mal influencée par les musiques de film, et elle se trouve géniale d'arriver à composer des trucs qui sonnent bien avec une formation musicale très basique, mais finalement elle restitue essentiellement les éternels arpèges¹ de piano.

Pour résumer, les LLMs actuels souffrent de l'effet Dunning-Kruger à un niveau stratosphérique, ça passera peut-être…

Si tu introduis le doute ou l'ignorance dans ces machines, les seules réponses possibles deviennent "il y a plus d'une manière de le faire" et "ça dépend", et ça, tu peux le faire en quelques lignes de Perl :).

Merci pour ta réponse, je comprend mieux à quel type de doc se destinent les résultat des tests !

Les autres clavier ortholinéaires sont intéressants, ils sont simplement beaucoup plus chers que les TypeMatrix. Quand j'ai voulu tester ce genre de clavier, ça a pesé dans mon choix.

Salut,

j'ai bien compris l'objectif d'unifier la doc et les tests, et je trouve le parti de bbt d'être facile d'accès super intéressant ! J'ai justement un outil à tester, je vais voir si ça colle.

Par contre je n'ai pas compris l'intérêt d'avoir les cas de tests et les résultats attendus dans la doc. Je regarde les exemples, ça passe car c'est assez court (par exemple le run_error_msg.md). Mais j'imagine l'équivalent d'une page de manuel comme celle de ls, ce serait un peu indigeste , non ?

C'est tout à fait possible que je sois à côté de la plaque quand à l'usage dans un certain type de doc, je suis preneur de plus de détails :).