C’est peut-être une tentative pour que le site reste tout public : si tu n’as compris qu’un seul mot (à ce niveau-là, l’objectif n’est pas atteint), les enfants n’en comprendront peut-être aucun…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J'ai pas eu l'impression que Jancovici soit spécialement pro-nucléaire. C'est surtout qu'il ne vois pas trop comment on va s'en sortir sans, a moyen terme. Sachant qu'en plus, il y a moyen de faire du nucléaire beaucoup plus propre moins sale…
Normalement, le nucléaire pourrait être une solution énergétique sur un terme assez court. Même sans considérer le problème des déchets, qui n’a jamais été résolu, l’uranium n’est pas renouvelable ; et si tous les pays se mettaient à avoir la même proportion de nucléaire que la France, il ne durerait pas longtemps. Concernant le plutonium, on a abandonné, faute de réussir à sécuriser le refroidissement, mais on espère développer la fusion… alors qu’elle dégage encore plus d’énergie que la fission du plutonium.
Mais dans la réalité, le parc de centrales du pays le plus nucléarisé du monde est vétuste et on n’est plus capable que de construire une centrale défectueuse en explosant les délais et les budgets.
Pour que le nucléaire puisse être une solution plutôt que de nous péter à la gueule, il faudrait remplacer tous les jean-foutres qui sont actuellement aux postes de décision de la filière par des gens responsables et capables de la remettre à flot. Pour ça, il faudrait commencer par arrêter de mettre des jean-foutres à la tête de l’État : si nous avions des dirigeants un tant soit peu responsables, ils imposeraient déjà que l’EPR soit conforme à l’état de l’art avant qu’il soit mis en service ; ça donnerait un premier signe fort à la filière qu’il est temps d’arrêter les conneries.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J’attends toujours un exemple d’application réelle utilisant un arbre dont la représentation en JSON ne passe pas avec les analyseurs actuels.
J’aurais pensé que quelqu’un en trouverait peut-être un au moins pour la limite la plus basse par défaut de 100 (un petit effort !), mais j’attends toujours…
Sinon, que les analyseurs JSON ne puissent pas lire un fichier produit dans une démarche malveillante, de test ou artistique, mais sans utilité réelle, ça ne m’empêchera pas de dormir (surtout si ça ne concerne pas ceux de mes langages de prédilection). Il y a des trucs qui m’ennuient plus en informatique (l’abandon du système de fichiers Intermezzo, par exemple, ou Berkeley DB*).
Note : si on a un arbre de plus de 100 niveaux qui tient en mémoire, il est fortement déséquilibré (c’est vrai que j’ai oublié ce cas dans mes commentaires précédents) ou beaucoup de nœuds sont le seul nœud fils de leur nœud parent. Un arbre correspondant au second cas peut être compacté en regroupant ces nœuds avec leur nœud parent.
Un petit schéma (ASCII parce que c’est plus simple — je sais que c’est moche), pour éclairer le principe :
e
/
d e
/ \ /
c f bcd
/ / \
b devient a f
/ \
a g
\
g
Donc, il reste à trouver l’exemple d’une application ayant l’utilité d’un arbre d’une profondeur de plus de 100 (par rapport à la limite par défaut la plus basse) voire 900 (par rapport à la limite de récursion sur Python si elle n’est pas facilement relevable, sinon encore plus) fortement déséquilibré et dont un rééquilibrage fausse le sens.
Cela dit, je n’exclus pas complètement qu’un développeur se retrouve un jour dans ce cas. La page de lovasoa pourrait alors lui être utile… si elle distinguait pour tous les langages ou bibliothèques la limite par défaut et la limite maximale.
* Si je voulais râler contre une brique logicielle, ce serait la base Berkeley DB.
Ton serveur OpenLDAP est arrêté brusquement (coupure électrique…) alors qu’il était bien pépère à ne faire que des opérations de lecture sur son backend bdb et c’est hyper grave, il faut reconstruire la base en suivant une doc imbitable. Merde !
Il y a aussi le cas où un fichier Berkeley DB perdu au fin fond du profil Firefox est corrompu et où Firefox ne démarre plus, sans explication pertinente (heureusement, c’est rare ; Firefox ne doit pas les garder ouverts en lecture…).
Berkeley DB n’est à la fois pas adaptée pour une grosse charge et pénible à gérer pour une faible charge. Malheureusement des logiciels l’utilisent…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.
À mon sens, c’est exactement l’inverse : un format JSON sert à l’encodage d’une structure existante (et qui tient en mémoire) pour pouvoir la recharger lors d’une autre exécution ou la transmettre.
L’utilité du parser est de permettre de restaurer cette structure.
Du coup, à moins que le programmeur (du premier programme si celui qui produit du JSON n’est pas le même que celui qui le lit) soit idiot, il a choisi une structure un minimum exploitable et pas complètement inefficace pour son application. Si on prend l’exemple utilisé pour le test, la seule information encodée par n tableaux imbriqués sans éléments, c’est… n.
J’attends toujours que quelqu’un trouve un exemple d’application ayant l’utilité d’un arbre très profond qui tient en mémoire (c’est une vraie question, je n’affirme pas que ça n’existe pas)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Non, c'est pas du tout ok de s'arrêter pour quelque raison que ce soit.
Nous vivons dans un monde fini (je ne sais pas si les chantres de la croissance infinie s’en apercevront avant d’avoir ravagé la planète au point que ce soit la famine globale, mais c’est une autre histoire), ton ordinateur l’est encore plus. Donc il y a forcément des limites.
Si il y a ce genre de limite, a minima elle doivent être clairement écrite dans la doc.
C’est le cas pour Perl. Si ça ne l’est pas pour ton langage, mauvais langage ⇒ changer de langage.
Ce qui me choquerait c’est que ça segfaulte salement.
Là dessus on est d'accord, c'est encore pire.
C’est pour ça que les auteurs de la plupart des bibliothèques ont fixé des limites.
D’une manière générale, c’est pas une mauvaise pratique de fixer des limites.
Si… Et c'est particulièrement vrai dans le cas d'une bibliothèque où celui qui l'écrit n'a absolument aucune idée de la manière dont elle va être utilisée.
Oui, enfin considérons que tu aies un ordinateur avec pas mal de mémoire, 32 Go. Ça fait 2³⁵.
Considérons un arbre binaire complet de 100 niveaux (la limite la plus basse pour un analyseur JSON selon les test de lovasoa). Il comprend 2¹⁰⁰ - 1 nœuds. Ça n’est pas prêt de rentrer dans ton ordinateur, même si par miracle chaque nœud ne prenait qu’un octet.
Peut-être vas-tu me dire que l’ordinateur de la météo est plus gros. Cela dit, le nombre d’atomes de notre planète est estimé à environ 10⁵⁰, soit environ 2¹⁶⁶. Tu montes un peu la limite par défaut ou tu prends un langage dont l’analyseur JSON a une limite à 512 et ton arbre n’est pas représentable sur Terre, même avec un atome par nœud…
Bon, considérons que l’intérêt est de représenter des arbres incomplets.
On trouve des analyseurs JSON qui tiennent jusqu’à plus de 50 000 niveaux (éventuellement en changeant la limite par défaut). Ça veut dire que pour accéder à une des feuilles les plus profondes, il faut quand même 50 000 itérations. Ça paraît compromettre l’efficacité.
Alors après, on ne peut pas complètement écarter à priori qu’il existe des cas pour lesquels malgré tout une telle représentation serait adaptée. Mais je serais très curieux d’en avoir un exemple. Et là, on pourra dire « quels idiots les programmeurs de telle bibliothèque JSON, elle ne couvre pas tous les usages », mais pas avant.
En attendant, est-ce que le vendeur de ta voiture t’a prévenu que son moteur ne peut pas fonctionner sans oxygène ? C’est quand même une limite très importante !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Oui, en ruby ou en PHP aussi, la limite est fixée dans le code.
Vu les valeurs que tu as trouvées (101 et 512), ça ne m’étonne pas.
Je soupçonnerais la même chose pour Rust (128), C/jansson (2049 — note que ton programme indique la valeur pour laquelle ça ne fonctionne plus, 513 par exemple en Perl en laissant la limite par défaut à 512)…
Cela empêche d'utiliser JSON, pour, par exemple représenter un arbre, alors que sans cette limite fixée par les implémentations, le format s'y prêterait très bien.
La remarque de Thomas ramène à la réflexion : est-ce qu’un arbre très profond a un sens dans une application réelle ?
S’il est très profond, mais pas très large, l’accès aux données ne semble pas optimal ; mieux vaudrait peut-être utiliser une autre structure (table de hachage ?). S’il est très profond et très large, donc très volumineux, est-ce que les capacités mémoires actuelles permettent de l’avoir entièrement en mémoire (la taille augmente exponentiellement avec la profondeur quand même), ou faut-il le manipuler directement sur disque/SSD ? Dans le deuxième cas, la question n’est pas de le sérialiser, mais d’avoir un format permettant un accès efficace sur disque/SSD.
Vois-tu un exemple d’application pour laquelle un arbre très profond (disons avec une profondeur supérieure à 5000) soit une structure adaptée ?
Si oui, la question de pouvoir le représenter pour le stocker, idéalement sous une forme moins sensible à la plateforme qu’une forme binaire, est effectivement intéressante.
Est-ce que les bibliothèques de sérialisation disponibles pour les divers langages gèrent ça mieux que les bibliothèques JSON ? Y a-t-il une représentation (ou à peu près) standard dont les bibliothèques tiennent mieux la route à ce niveau (XML ?) ?
La seule fois où j’ai eu à stocker un arbre (il y a 25 ans ; on trouvait moins de bibliothèques, à l’époque…), j’avais fait un parcours en profondeur et je stockais un nœud par ligne de fichier avec comme indications sa profondeur et sa valeur. Quand on reconstruisait l’arbre, la profondeur indiquait où greffer le nouveau nœud sur la branche courante. D’un point de vue analyse syntaxique, c’est très simple (en tout cas avec les valeurs de mes nœuds, qui l’étaient). Maintenant, cet arbre passerait en JSON, même avec la limite à 100 du parser Ruby…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Et combien de tableaux imbriqués faut-il pour faire planter un parser JSON ?
L’intérêt est-il de pouvoir manipuler des données légitimes qui utiliseraient disons 10000 niveaux (ça existe ?) ou de se protéger contre des fichiers JSON volontairement malformés ?
Le module JSON de Perl fixe la limite arbitrairement à 512. Extrait de son manuel :
Sets the maximum nesting level (default 512) accepted while encoding or decoding. If a higher nesting level is detected in JSON text or a Perl data structure, then the encoder and decoder will stop and croak at that point.
À l’essai, si on remonte la limite beaucoup plus haut, le parser en pur Perl s’arrête à 100000, alors que le parser de JSON::XS (écrit en C pour une plus grande rapidité) plante un peu après 74800 sur mon système (JSON utilise un parser ou l’autre suivant si JSON::XS est installé ou non).
ET bien dans certains langages, très peu.
Peut-être devrais-tu regarder si les limites que tu atteins avec d’autre langages ne sont pas aussi fixées arbitrairement pour éviter des problèmes…
« Brève », je verrais plutôt ça pour les articles (officiels) courts, à la place de « dépêche » (dans le sens où je l’ai utilisé), pour éviter la confusion avec la terminologie actuelle.
C’est vrai que « billet » évoque plutôt une forme courte. Ça laisse donc plusieurs possibilités pour un contenu personnel court : « note » (que j’ai proposé), « billet » ou « brève » (je fais une proposition, je ne prétends pas imposer ma vision des choses ; peut-être la majorité ou les éditeurs du site préféreront-ils un autre choix).
Il reste à trouver un mot pour les contenus personnels longs. Faute de mieux, il m’avait semblé que « billet » faisait moins court que « note » (ou « brève » en l’occurrence), tout en restant relativement adapté à un contenu personnel. Mais si quelqu’un a une meilleure idée…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
je préférerais « bloc-note » (post-it étant une marque déposée iirc) qui fait métonymie avec le support et ce qui est écrit dessus brièvement.
Un bloc-note, c’est un bloc… dans lequel on écrit des notes. Chaque écrit individuel est une note.
Par rapport à tes différences entre bref / long : ce serait une différence d'affichage (soit avec le mot dépêche / article, soit via la css) ? À partir de combien de caractères ? (2000 ou 4000 a priori).
J’aurais tendance à laisser le choix à l’utilisateur de la rubrique dans laquelle il publie, mais en présélectionnant suivant la longueur (quand on clique sur Prévisualiser).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J’en profite pour proposer une terminologie plus proche du français courant, où « journal », c’est un ensemble de feuilles de papier avec des articles dessus.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Cette confusion entre les journaux et les dépêches est favorisée par la terminologie elle-même ! Journaux et dépêches, c'est quand même très similaires. Les habitués s'en sont accomodés, mais les autres ? Il n'est pas évident que « dépêches » ne renvoie pas à « journaux », qui lui renvoie à « journaux personnels ». Pour clarifier, on pense qu'il serait plus évocateur de parler de « blogs », sur lesquels les auteurs peuvent publier des « billets ».
En effet.
Je pense de plus qu’une terminologie différenciée suivant la taille des contenus permettrait de ressusciter les contenus courts (et souvent plus frais que les articles fouillés qui mettent plus de temps à être écrits, les deux ayant leur intérêt), avec une possibilité pour ceux qui ne les apprécient pas de ne pas les afficher plutôt que de râler ou d’inutiler.
Google publie autant qu'ils peuvent les statistiques des rapports à la NSA, par exemple, parce que plus ils donnent la sensation que les données sont en sécurité chez eux et plus les gens seront enclins de le faire. S'il s'avère qu'ils commencent à vendre les données aux assurances ou aux cabinets d'avocat, qui à mon avis seraient (eux) prêts à les payer une fortune, alors les utilisateurs vont fuir, et ça peut aller très très vite.
C’est peut-être un risque qu’ils ne prendront pas maintenant.
Mais le jour où la boîte coulera (OK, ça n’arrivera sûrement pas demain, mais rien n’est éternel), les actionnaires et les dirigeants seront prêts à n’importe quoi pour continuer à toucher encore un peu, il ne faut pas sous-estimer la dangerosité d’un animal blessé (voir SCO). Et là, les données conservées (et certaines boîtes comme Facebook n’effacent pas les données que vous effacez, d’autres ont peut-être plus de données sur vous que vous-mêmes) pourront leur permettre de faire la culbute pour finir en beauté (d’un point de vue financier).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Enfin un clavier où Backspace n'est pas juste à côté de Enter.
Ce n’est pas si rare : des claviers qui satisfont à cette exigence, il doit y en avoir quelques centaines de millions (à la louche) aux États-Unis. Leur touche Enter est deux fois moins haute mais plus large que la touche Entrée des claviers européens, la touche \ (correspondant à la touche * en Azerty) prenant la place du haut de la touche Entrée.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Bizarre Dailymotion : avec l’URL que j’avais dans la zone dédiée du navigateur, on tombe sur une autre vidéo que celle de la page que j’avais (pas forcément moins bien, mais nettement moins à propos)…
Ça ne garantit peut-être pas qu’il n’y ait pas la même architecture avec un processeur maître dont on n’a pas le contrôle, mais s’il ne permet pas la prise de contrôle à distance, c’est déjà nettement moins grave.
Évidemment, l’idéal serait que ceux qui ont analysé l’IME nous disent ce qu’il en est réellement de ces processeurs. En attendant mieux, d’après le mode d’emploi de mon portable, la technologie « Intel AMT » est prise en charge « en fonction du modèle ». Et sur le mien, qui comprend un Core i3, le menu qui permettrait de gérer l’AMT est bien absent du BIOS.
À noter que le manuel indique une procédure pour la désactiver (mais il y en a qui se sont aperçus avec certains PC que l’AMT continuait malgré cela à causer sur le réseau), et avertit que « Si la fonction AMT est ACTIVÉE, elle risque d'être exploitée par des tiers, ce qui risque d'entraîner la fuite d'informations sensibles et/ou propriétaires, la perte de données, l'effacement du disque dur/SSD ou le remplacement de fichiers. »
La moralité selon moi, sachant que certains processeurs semblent quand même moins compromis que d’autres, c’est que si personne n’achetait les plus compromis, les fabricants seraient bien forcés de revoir leur copie.
Comme disait Coluche, « Quand on pense qu’il suffirait que les gens arrêtent de les acheter pour que ça se vende plus ».
Côté AMD, la technologie équivalente se nomme « TrustZone » (sic), et se base sur un processeur ARM. J’avais trouvé une info indiquant que même un AMD E2 (série basse consommation) l’incluait, mais je ne la retrouve plus et je n’ai pas trouvé d’indication générale sur les processeurs qui l’incluent ou pas (mais il aurait peut-être juste fallu chercher plus).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Tous les éléments de la plate‐forme sont en anglais
Pourquoi ?
Cherchez-vous de futurs informaticiens ou des anglicistes ?
Pour le langage informatique, admettions que c’est pour être plus près de la réalité.
Pour le reste (commentaires, tutoriel), je sais qu’un informaticien peut s’attendre à devoir lire des docs en anglais, mais vos candidats qui ne sont pas censés être déjà à l’aise avec un langage informatique, pourquoi le seraient-ils avec l’anglais ?
Pour ma part, lire des docs en anglais, c’est venu avec la pratique (les cours d’anglais de mon cursus scolaire ayant fourni une base, mais sans plus), mais là les candidats ne sont pas censés en avoir.
Pendant ce temps-là, les anglais et les américains ne se mettent pas de barrière de langue…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
xargs peut faire des exécutions multiples si la ligne est trop longue, mais dans find | tar cvf, tu ne l’as pas mis. Je suppose que c’est un oubli (sinon, ça ne va pas faire grand chose…). Cela dit, moi aussi, je l’ai oublié dans mon premier exemple, qui aurait dû être ls *truc | xargs rm -rf (ATTENTION : ne pas faire pareil chez vous, c’est l’exemple erroné qui casse des trucs).
Cela dit, tar a l’option -T qui fait le boulot sans recours à xargs et sans erreur de ligne trop longue au niveau du shell : find -type f | tar cvf fichier.tar -T -
Il y a intérêt à mettre au moins -type f comme argument de find, sinon chaque répertoire va être inclus avec son contenu, puis son contenu va être réinclus. Cela dit, la commande n’a d’intérêt que s’il y a un autre argument à find (sinon, tar cvf fichier.tar . suffit).
Bon, à l’essai, parallel semble fiable par rapport aux problèmes d’espaces : ls | parallel ls depuis un répertoire contenant un fichier avec des espaces s’en sort bien (je n’ai pas dit que cette commande avait un intérêt), alors que ls | xargs ls indique des erreurs sur les morceaux du nom de fichier avec espace (ls | xargs -d "\n" ls permet de ne pas avoir le problème).
Du coup, parallel ça a l’air très sympa comme commande.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ça prête peut-être à confusion.
Je ne parle pas de la commande parallel, je veux dire que je ne ferais pas confiance à une construction du style ls * |, à moins d’avoir une parfaite maîtrise de la commande qui suit le pipe.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Je connais quelqu’un qui a un jour lancé une commande du style ls *truc | rm -rf dans un répertoire dont des fichiers contenaient des espaces dans leurs noms, il a eu des problèmes…
Après, normalement, il n’y a pas d’espace dans les noms des fichiers .c et ça dépend aussi de la façon dont la commande parallel gère ça, mais à défaut de le savoir, je ne ferais pas confiance à une telle commande.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Jouer au démineur en 2157
Posté par Arthur Accroc . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 2.
Ça m’a bien fait rire (euh… c’était bien une blague, hein ?).
Mais il y a intérêt à bien calculer son coup : la terre tourne, si tu rates ton timing, ton morceau d’astéroïde tombera carrément ailleurs !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Le plus malin est en général le premier qui cède
Posté par Arthur Accroc . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 0.
C’est peut-être une tentative pour que le site reste tout public : si tu n’as compris qu’un seul mot (à ce niveau-là, l’objectif n’est pas atteint), les enfants n’en comprendront peut-être aucun…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Le nucléaire est sur le déclin
Posté par Arthur Accroc . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 7.
Normalement, le nucléaire pourrait être une solution énergétique sur un terme assez court. Même sans considérer le problème des déchets, qui n’a jamais été résolu, l’uranium n’est pas renouvelable ; et si tous les pays se mettaient à avoir la même proportion de nucléaire que la France, il ne durerait pas longtemps. Concernant le plutonium, on a abandonné, faute de réussir à sécuriser le refroidissement, mais on espère développer la fusion… alors qu’elle dégage encore plus d’énergie que la fission du plutonium.
Mais dans la réalité, le parc de centrales du pays le plus nucléarisé du monde est vétuste et on n’est plus capable que de construire une centrale défectueuse en explosant les délais et les budgets.
Pour que le nucléaire puisse être une solution plutôt que de nous péter à la gueule, il faudrait remplacer tous les jean-foutres qui sont actuellement aux postes de décision de la filière par des gens responsables et capables de la remettre à flot. Pour ça, il faudrait commencer par arrêter de mettre des jean-foutres à la tête de l’État : si nous avions des dirigeants un tant soit peu responsables, ils imposeraient déjà que l’EPR soit conforme à l’état de l’art avant qu’il soit mis en service ; ça donnerait un premier signe fort à la filière qu’il est temps d’arrêter les conneries.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # J’attends toujours un exemple…
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 2.
Mauvaise foi ? De la part de qui ?
J’attends toujours un exemple d’application réelle utilisant un arbre dont la représentation en JSON ne passe pas avec les analyseurs actuels.
J’aurais pensé que quelqu’un en trouverait peut-être un au moins pour la limite la plus basse par défaut de 100 (un petit effort !), mais j’attends toujours…
Sinon, que les analyseurs JSON ne puissent pas lire un fichier produit dans une démarche malveillante, de test ou artistique, mais sans utilité réelle, ça ne m’empêchera pas de dormir (surtout si ça ne concerne pas ceux de mes langages de prédilection). Il y a des trucs qui m’ennuient plus en informatique (l’abandon du système de fichiers Intermezzo, par exemple, ou Berkeley DB*).
Note : si on a un arbre de plus de 100 niveaux qui tient en mémoire, il est fortement déséquilibré (c’est vrai que j’ai oublié ce cas dans mes commentaires précédents) ou beaucoup de nœuds sont le seul nœud fils de leur nœud parent. Un arbre correspondant au second cas peut être compacté en regroupant ces nœuds avec leur nœud parent.
Un petit schéma (ASCII parce que c’est plus simple — je sais que c’est moche), pour éclairer le principe :
Donc, il reste à trouver l’exemple d’une application ayant l’utilité d’un arbre d’une profondeur de plus de 100 (par rapport à la limite par défaut la plus basse) voire 900 (par rapport à la limite de récursion sur Python si elle n’est pas facilement relevable, sinon encore plus) fortement déséquilibré et dont un rééquilibrage fausse le sens.
Cela dit, je n’exclus pas complètement qu’un développeur se retrouve un jour dans ce cas. La page de lovasoa pourrait alors lui être utile… si elle distinguait pour tous les langages ou bibliothèques la limite par défaut et la limite maximale.
* Si je voulais râler contre une brique logicielle, ce serait la base Berkeley DB.
Ton serveur OpenLDAP est arrêté brusquement (coupure électrique…) alors qu’il était bien pépère à ne faire que des opérations de lecture sur son backend bdb et c’est hyper grave, il faut reconstruire la base en suivant une doc imbitable. Merde !
Il y a aussi le cas où un fichier Berkeley DB perdu au fin fond du profil Firefox est corrompu et où Firefox ne démarre plus, sans explication pertinente (heureusement, c’est rare ; Firefox ne doit pas les garder ouverts en lecture…).
Berkeley DB n’est à la fois pas adaptée pour une grosse charge et pénible à gérer pour une faible charge. Malheureusement des logiciels l’utilisent…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Intérêt ?
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 7.
À mon sens, c’est exactement l’inverse : un format JSON sert à l’encodage d’une structure existante (et qui tient en mémoire) pour pouvoir la recharger lors d’une autre exécution ou la transmettre.
L’utilité du parser est de permettre de restaurer cette structure.
Du coup, à moins que le programmeur (du premier programme si celui qui produit du JSON n’est pas le même que celui qui le lit) soit idiot, il a choisi une structure un minimum exploitable et pas complètement inefficace pour son application. Si on prend l’exemple utilisé pour le test, la seule information encodée par n tableaux imbriqués sans éléments, c’est… n.
J’attends toujours que quelqu’un trouve un exemple d’application ayant l’utilité d’un arbre très profond qui tient en mémoire (c’est une vraie question, je n’affirme pas que ça n’existe pas)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Limites…
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 10.
Nous vivons dans un monde fini (je ne sais pas si les chantres de la croissance infinie s’en apercevront avant d’avoir ravagé la planète au point que ce soit la famine globale, mais c’est une autre histoire), ton ordinateur l’est encore plus. Donc il y a forcément des limites.
C’est le cas pour Perl. Si ça ne l’est pas pour ton langage, mauvais langage ⇒ changer de langage.
C’est pour ça que les auteurs de la plupart des bibliothèques ont fixé des limites.
Oui, enfin considérons que tu aies un ordinateur avec pas mal de mémoire, 32 Go. Ça fait 2³⁵.
Considérons un arbre binaire complet de 100 niveaux (la limite la plus basse pour un analyseur JSON selon les test de lovasoa). Il comprend 2¹⁰⁰ - 1 nœuds. Ça n’est pas prêt de rentrer dans ton ordinateur, même si par miracle chaque nœud ne prenait qu’un octet.
Peut-être vas-tu me dire que l’ordinateur de la météo est plus gros. Cela dit, le nombre d’atomes de notre planète est estimé à environ 10⁵⁰, soit environ 2¹⁶⁶. Tu montes un peu la limite par défaut ou tu prends un langage dont l’analyseur JSON a une limite à 512 et ton arbre n’est pas représentable sur Terre, même avec un atome par nœud…
Bon, considérons que l’intérêt est de représenter des arbres incomplets.
On trouve des analyseurs JSON qui tiennent jusqu’à plus de 50 000 niveaux (éventuellement en changeant la limite par défaut). Ça veut dire que pour accéder à une des feuilles les plus profondes, il faut quand même 50 000 itérations. Ça paraît compromettre l’efficacité.
Alors après, on ne peut pas complètement écarter à priori qu’il existe des cas pour lesquels malgré tout une telle représentation serait adaptée. Mais je serais très curieux d’en avoir un exemple. Et là, on pourra dire « quels idiots les programmeurs de telle bibliothèque JSON, elle ne couvre pas tous les usages », mais pas avant.
En attendant, est-ce que le vendeur de ta voiture t’a prévenu que son moteur ne peut pas fonctionner sans oxygène ? C’est quand même une limite très importante !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Intérêt ?
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 3.
Vu les valeurs que tu as trouvées (101 et 512), ça ne m’étonne pas.
Je soupçonnerais la même chose pour Rust (128), C/jansson (2049 — note que ton programme indique la valeur pour laquelle ça ne fonctionne plus, 513 par exemple en Perl en laissant la limite par défaut à 512)…
La remarque de Thomas ramène à la réflexion : est-ce qu’un arbre très profond a un sens dans une application réelle ?
S’il est très profond, mais pas très large, l’accès aux données ne semble pas optimal ; mieux vaudrait peut-être utiliser une autre structure (table de hachage ?). S’il est très profond et très large, donc très volumineux, est-ce que les capacités mémoires actuelles permettent de l’avoir entièrement en mémoire (la taille augmente exponentiellement avec la profondeur quand même), ou faut-il le manipuler directement sur disque/SSD ? Dans le deuxième cas, la question n’est pas de le sérialiser, mais d’avoir un format permettant un accès efficace sur disque/SSD.
Vois-tu un exemple d’application pour laquelle un arbre très profond (disons avec une profondeur supérieure à 5000) soit une structure adaptée ?
Si oui, la question de pouvoir le représenter pour le stocker, idéalement sous une forme moins sensible à la plateforme qu’une forme binaire, est effectivement intéressante.
Est-ce que les bibliothèques de sérialisation disponibles pour les divers langages gèrent ça mieux que les bibliothèques JSON ? Y a-t-il une représentation (ou à peu près) standard dont les bibliothèques tiennent mieux la route à ce niveau (XML ?) ?
La seule fois où j’ai eu à stocker un arbre (il y a 25 ans ; on trouvait moins de bibliothèques, à l’époque…), j’avais fait un parcours en profondeur et je stockais un nœud par ligne de fichier avec comme indications sa profondeur et sa valeur. Quand on reconstruisait l’arbre, la profondeur indiquait où greffer le nouveau nœud sur la branche courante. D’un point de vue analyse syntaxique, c’est très simple (en tout cas avec les valeurs de mes nœuds, qui l’étaient). Maintenant, cet arbre passerait en JSON, même avec la limite à 100 du parser Ruby…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Intérêt ?
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 6.
L’intérêt est-il de pouvoir manipuler des données légitimes qui utiliseraient disons 10000 niveaux (ça existe ?) ou de se protéger contre des fichiers JSON volontairement malformés ?
Le module JSON de Perl fixe la limite arbitrairement à 512. Extrait de son manuel :
À l’essai, si on remonte la limite beaucoup plus haut, le parser en pur Perl s’arrête à 100000, alors que le parser de JSON::XS (écrit en C pour une plus grande rapidité) plante un peu après 74800 sur mon système (JSON utilise un parser ou l’autre suivant si JSON::XS est installé ou non).
Peut-être devrais-tu regarder si les limites que tu atteins avec d’autre langages ne sont pas aussi fixées arbitrairement pour éviter des problèmes…
Pour référence, le code Perl que j’ai utilisé :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Terminologie
Posté par Arthur Accroc . En réponse à l’entrée du suivi Terminologie et ressuscitation des contenus courts. Évalué à 2 (+0/-0).
« Brève », je verrais plutôt ça pour les articles (officiels) courts, à la place de « dépêche » (dans le sens où je l’ai utilisé), pour éviter la confusion avec la terminologie actuelle.
C’est vrai que « billet » évoque plutôt une forme courte. Ça laisse donc plusieurs possibilités pour un contenu personnel court : « note » (que j’ai proposé), « billet » ou « brève » (je fais une proposition, je ne prétends pas imposer ma vision des choses ; peut-être la majorité ou les éditeurs du site préféreront-ils un autre choix).
Il reste à trouver un mot pour les contenus personnels longs. Faute de mieux, il m’avait semblé que « billet » faisait moins court que « note » (ou « brève » en l’occurrence), tout en restant relativement adapté à un contenu personnel. Mais si quelqu’un a une meilleure idée…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Terminologie
Posté par Arthur Accroc . En réponse à l’entrée du suivi Terminologie et ressuscitation des contenus courts. Évalué à 2 (+0/-0).
Connoté en quoi ?
Un bloc-note, c’est un bloc… dans lequel on écrit des notes. Chaque écrit individuel est une note.
J’aurais tendance à laisser le choix à l’utilisateur de la rubrique dans laquelle il publie, mais en présélectionnant suivant la longueur (quand on clique sur Prévisualiser).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Terminologie
Posté par Arthur Accroc . En réponse à l’entrée du suivi Terminologie et ressuscitation des contenus courts. Évalué à 2 (+0/-0). Dernière modification le 21 octobre 2017 à 14:31.
J’en profite pour proposer une terminologie plus proche du français courant, où « journal », c’est un ensemble de feuilles de papier avec des articles dessus.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Suivi
Posté par Arthur Accroc . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.
C’est fait.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Terminologie et taille des contenus
Posté par Arthur Accroc . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 10.
En effet.
Je pense de plus qu’une terminologie différenciée suivant la taille des contenus permettrait de ressusciter les contenus courts (et souvent plus frais que les articles fouillés qui mettent plus de temps à être écrits, les deux ayant leur intérêt), avec une possibilité pour ceux qui ne les apprécient pas de ne pas les afficher plutôt que de râler ou d’inutiler.
Je reproduis le petit tableau que j’avais déjà proposé :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Deux interprétations
Posté par Arthur Accroc . En réponse au journal [bookmark] Privacy Shield subira-t-il le sort de Safe Harbor ?. Évalué à 4.
C’est peut-être un risque qu’ils ne prendront pas maintenant.
Mais le jour où la boîte coulera (OK, ça n’arrivera sûrement pas demain, mais rien n’est éternel), les actionnaires et les dirigeants seront prêts à n’importe quoi pour continuer à toucher encore un peu, il ne faut pas sous-estimer la dangerosité d’un animal blessé (voir SCO). Et là, les données conservées (et certaines boîtes comme Facebook n’effacent pas les données que vous effacez, d’autres ont peut-être plus de données sur vous que vous-mêmes) pourront leur permettre de faire la culbute pour finir en beauté (d’un point de vue financier).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Entrée séparée de l’effacement arrière
Posté par Arthur Accroc . En réponse au journal Bash et les raccourcis clavier. Évalué à 2.
Ce n’est pas si rare : des claviers qui satisfont à cette exigence, il doit y en avoir quelques centaines de millions (à la louche) aux États-Unis. Leur touche Enter est deux fois moins haute mais plus large que la touche Entrée des claviers européens, la touche \ (correspondant à la touche * en Azerty) prenant la place du haut de la touche Entrée.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: enlarge your kernel
Posté par Arthur Accroc . En réponse au journal Désactiver l'Intel ME: merci la NSA. Évalué à 10.
Du coup, l’OS qui le dispute à Windows comme le plus répandu sur ordinateurs (par opposition aux smartphones, TV connectées…), c’est Minix !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Errata lien Coluche
Posté par Arthur Accroc . En réponse au journal Désactiver l'Intel ME: merci la NSA. Évalué à 2.
Bizarre Dailymotion : avec l’URL que j’avais dans la zone dédiée du navigateur, on tombe sur une autre vidéo que celle de la page que j’avais (pas forcément moins bien, mais nettement moins à propos)…
Bon, la vidéo de Coluche est là.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Choix d’achat
Posté par Arthur Accroc . En réponse au journal Désactiver l'Intel ME: merci la NSA. Évalué à 4. Dernière modification le 02 septembre 2017 à 14:29.
Selon les spécifications Intel, les processeurs jusqu’au Core i3 (en tout cas tous ceux que j’ai regardé) et certains Core i5 n’ont pas la fonctionnalité « vPro », dont fait partie l’« Intel Active Management Technology ».
Ça ne garantit peut-être pas qu’il n’y ait pas la même architecture avec un processeur maître dont on n’a pas le contrôle, mais s’il ne permet pas la prise de contrôle à distance, c’est déjà nettement moins grave.
Évidemment, l’idéal serait que ceux qui ont analysé l’IME nous disent ce qu’il en est réellement de ces processeurs. En attendant mieux, d’après le mode d’emploi de mon portable, la technologie « Intel AMT » est prise en charge « en fonction du modèle ». Et sur le mien, qui comprend un Core i3, le menu qui permettrait de gérer l’AMT est bien absent du BIOS.
À noter que le manuel indique une procédure pour la désactiver (mais il y en a qui se sont aperçus avec certains PC que l’AMT continuait malgré cela à causer sur le réseau), et avertit que « Si la fonction AMT est ACTIVÉE, elle risque d'être exploitée par des tiers, ce qui risque d'entraîner la fuite d'informations sensibles et/ou propriétaires, la perte de données, l'effacement du disque dur/SSD ou le remplacement de fichiers. »
La moralité selon moi, sachant que certains processeurs semblent quand même moins compromis que d’autres, c’est que si personne n’achetait les plus compromis, les fabricants seraient bien forcés de revoir leur copie.
Comme disait Coluche, « Quand on pense qu’il suffirait que les gens arrêtent de les acheter pour que ça se vende plus ».
Côté AMD, la technologie équivalente se nomme « TrustZone » (sic), et se base sur un processeur ARM. J’avais trouvé une info indiquant que même un AMD E2 (série basse consommation) l’incluait, mais je ne la retrouve plus et je n’ai pas trouvé d’indication générale sur les processeurs qui l’incluent ou pas (mais il aurait peut-être juste fallu chercher plus).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Polices
Posté par Arthur Accroc . En réponse au journal Unicode - pédagogique - vue d'ensemble ! ? .. Évalué à 2.
Y a-t-il toutes les polices Noto dans ce paquet ?
Sinon, Symbola et Quivira devraient déjà boucher des trous…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Questionnement
Posté par Arthur Accroc . En réponse au journal OpenStreetMap et carburants. Évalué à 4.
Avec le même genre de justice, l’apartheid existerait peut-être encore en Afrique du Sud…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Vassalisation à l’anglais ?
Posté par Arthur Accroc . En réponse à la dépêche Outil d’évaluation des aptitudes au développement. Évalué à 2.
Pourquoi ?
Cherchez-vous de futurs informaticiens ou des anglicistes ?
Pour le langage informatique, admettions que c’est pour être plus près de la réalité.
Pour le reste (commentaires, tutoriel), je sais qu’un informaticien peut s’attendre à devoir lire des docs en anglais, mais vos candidats qui ne sont pas censés être déjà à l’aise avec un langage informatique, pourquoi le seraient-ils avec l’anglais ?
Pour ma part, lire des docs en anglais, c’est venu avec la pratique (les cours d’anglais de mon cursus scolaire ayant fourni une base, mais sans plus), mais là les candidats ne sont pas censés en avoir.
Pendant ce temps-là, les anglais et les américains ne se mettent pas de barrière de langue…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Conseil de lecture
Posté par Arthur Accroc . En réponse au journal L’État d’urgence permanent. Évalué à 7.
Conseil de lecture : Le Talon de fer, de Jack London, pour sa description du fonctionnement de l’oligarchie du début du 20ᵉ siècle.
Toute ressemblance avec la situation actuelle n’est pas fortuite.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: ls * |
Posté par Arthur Accroc . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 4.
xargspeut faire des exécutions multiples si la ligne est trop longue, mais dansfind | tar cvf, tu ne l’as pas mis. Je suppose que c’est un oubli (sinon, ça ne va pas faire grand chose…). Cela dit, moi aussi, je l’ai oublié dans mon premier exemple, qui aurait dû êtrels *truc | xargs rm -rf(ATTENTION : ne pas faire pareil chez vous, c’est l’exemple erroné qui casse des trucs).Cela dit,
tara l’option-Tqui fait le boulot sans recours àxargset sans erreur de ligne trop longue au niveau du shell :find -type f | tar cvf fichier.tar -T -Il y a intérêt à mettre au moins
-type fcomme argument defind, sinon chaque répertoire va être inclus avec son contenu, puis son contenu va être réinclus. Cela dit, la commande n’a d’intérêt que s’il y a un autre argument àfind(sinon,tar cvf fichier.tar .suffit).Bon, à l’essai,
parallelsemble fiable par rapport aux problèmes d’espaces :ls | parallel lsdepuis un répertoire contenant un fichier avec des espaces s’en sort bien (je n’ai pas dit que cette commande avait un intérêt), alors quels | xargs lsindique des erreurs sur les morceaux du nom de fichier avec espace (ls | xargs -d "\n" lspermet de ne pas avoir le problème).Du coup,
parallelça a l’air très sympa comme commande.« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: ls * |
Posté par Arthur Accroc . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 6.
Ça prête peut-être à confusion.
Je ne parle pas de la commande parallel, je veux dire que je ne ferais pas confiance à une construction du style
ls * |, à moins d’avoir une parfaite maîtrise de la commande qui suit le pipe.« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # ls * |
Posté par Arthur Accroc . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 4.
Je connais quelqu’un qui a un jour lancé une commande du style
ls *truc | rm -rfdans un répertoire dont des fichiers contenaient des espaces dans leurs noms, il a eu des problèmes…Après, normalement, il n’y a pas d’espace dans les noms des fichiers .c et ça dépend aussi de la façon dont la commande parallel gère ça, mais à défaut de le savoir, je ne ferais pas confiance à une telle commande.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone