Arthur Accroc a écrit 2087 commentaires

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 :

max_depth
$json = $json->max_depth([$maximum_nesting_depth])

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…

Pour référence, le code Perl que j’ai utilisé :

#!/usr/bin/perl -w
use strict;

use JSON;

my $json = JSON->new;
$json->max_depth(5000000);
my $decoded = $json->decode(<STDIN>);

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

« 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

Pour « note », qui est connoté àmha,

Connoté en quoi ?

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

C’est fait.

« 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.

Je reproduis le petit tableau que j’avais déjà proposé :

	publié par la rédaction	personnel
(très) bref	dépêche (actuellement disparu)	note (actuellement inutilé)
(relativement) long	article (actuellement « dépêche »)	billet (actuellement « journal »)

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

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

D'après l'article Intel ME ferait tourner une version modifiée de minix…

Comme quoi le troll n'est pas forcément ce qu'on crois

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

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

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

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

ça parle d'un pays, et c'est d'ailleurs confirmé par la cour de cass 20 octobre 2015, 14-80.021,

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

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

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

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

je ne ferais pas confiance à une telle commande.

Ç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

La rédaction c'est chacun d'entre nous. Ensuite il y a les modérateurs pour le contenu appelé "dépêche".

Ce sont eux qui sont garants de la ligne éditoriale pour la partie « Dépêches ». Ceux qui les écrivent sont plus dans la position de pigistes que de membres de ce qui serait une rédaction. Ce n’est pas une critique, il faut bien une ligne éditoriale sur un site à thème et puis on peut toujours publier en journal les contenus qui en sortent.

Tu es libre de créer une dépêche "Sortie de la semaine"

Entre écrire une brève lorsqu’un projet qu’on suit sort une nouvelle version ou qu’on tombe par hasard sur une nouveauté et scruter toutes les nouveautés, ça ne demande pas du tout le même temps…

ça existait à un moment il me semble.

Je suppose que c’étaient des dépêches collaboratives, ce qui peut demander moins de temps à chacun, mais il faut que beaucoup de monde s’implique pour couvrir tous les projets un peu importants !

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

La version LinuxFr.org actuelle:

Je sais bien à quoi correspond la version LinuxFr.org actuelle.

Mais en vrai, il n’y a plus de « dépêches » brèves et les « journaux bookmarks » se font généralement descendre.
Bon, il y en a quelques uns malgré tout, mais de plus en plus rares. Le dernier, son auteur a créé un multi pour le poster…

Ton tableau sera plus juste en remplaçant « bref ou long » par « long ».

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Je suis nouveau ici alors je n’ai pas connu le temps de DLFP

Je me suis posé la question de la date de la disparition du nom du titre de la page (c’est l’endroit où il est resté le plus longtemps). C’était manifestement entre le 10 février et le 21 février 2011.

D’après la date de création de ton compte, tu as effectivement raté l’époque Da Linux French Page… de quelques mois. Pas assez rapide, petit scarabée !

Quant à sa présence dans le corps de la page, elle semble s’être terminée entre octobre et décembre 2002.

Dans les deux cas, ça correspond peut-être aux moments de changement du moteur du site.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Sept mots en comptant le titre, et un lien, faut pas déconner…

Je te concède que j’aurais préféré qu’au titre soit ajouté « est sortie » (ce qui aurait fait neuf mots).
Ça aurait clarifié l’information et aussi le fait qu’il n’y aurait pas forcément de description de la Devuan Jessie dans le reste du journal.
Mais bon, je ne vais pas lui jeter la pierre pour ça.
Les seuls journaux bookmarks qui m’énervent, c’est ceux qui contiennent juste un lien vers une vidéo avec comme seul texte « regardez la super vidéo ». Le minimum que j’attends, c’est un sujet qui dise de quoi ça parle, afin de passer rapidement si ça n’a aucun intérêt pour moi.

C’est un contenu qui a plus sa place sur la tribune :)

Pour avoir l’information avec la tribune, il faudrait la suivre tout le temps. Ce n’est pas vraiment le média le plus approprié pour diffuser des informations…
J’aimerais bien une page Brèves (avec limitation de taille pour être sûr qu’elles ne gonflent pas au fil du temps — il y a déjà les pages Journaux et Dépêches pour les contenus longs), les râleurs pourraient se passer de la lire, ça leur ferait des vacances et aux autres aussi.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

l'auteur du bookmark n'est peut-être pas impliqué dans le projet.

Si ça avait été le cas, il ne s'appellerait pas "UnGrandJour" avec comme seul message ce journal.

Oui, ça fait très officiel comme communication d’un projet.

Il me semble bien plus probable que ce soit un fan ou un troll, et peut-être même quelqu’un qui a déjà un (autre) compte sur LinuxFr, mais qui n’a pas voulu entamer son karma ou sa réputation, sachant qu’un tel journal se ferait descendre d’une part par les inconditionnels de systemd et d’autre part par tous ceux qui ne tolèrent pas les contenus courts (rappel : au début, Da Linux French Page*, c’était des contenus courts).

Pour ma part, je me demandais si Devuan réussirait à sortir un jour une version stable… mais pas assez pour suivre le projet ou regarder son site régulièrement.
Ce journal a répondu à ma question, merci. C’est exactement ce que j’attends d’une vraie dépêche : avoir une nouvelle fraîche et tant pis pour les détails. Il est toujours temps que quelqu’un fasse éventuellement un article de fond (dit « dépêche » dans la nomenclature LinuxFr) plus tard.
Quant à la forme du journal, man humour, quoi !

* Pour les petits nouveaux, Da Linux French Page, c’est le nom d’origine de LinuxFr.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone