freem a écrit 5059 commentaires

Maintenant, ça peut faire peur aux nouveaux de voir qu'on est des extrémistes ici…

Ou le contraire, des gens pourraient se dire qu'ici, il y a de la suite dans les idées, ce qui peut être perçu comme positif.

De toute façon, proposer des alternatives n'est pas vraiment de l'extrémisme. De l'extrémisme, ça serait de virer automatiquement tout lien vers une solution non libre, et de vérifier le navigateur: si pas libre, rediriger vers un site pour Dl un brouteur libre. Et on en est très, très loin.

Qualifier tout et n'importe quoi d'extrème est juste une manière de disqualifier des options sans avoir a trop réfléchir.

J'y pense, un moyen de réduire le problème serait peut-être d'utiliser des liens vers invidio.us? Sans résoudre le problème (parce que ça reste du proxy, et pas vraiment des solutions alternatives à mon avis), ça réduirait peut-être son impact.

Cool! LDAP fait partie de ces trucs que j'ai envie de me déployer dans un petit labo maison (et a terme pour gérer mon LAN perso), vu que je ne suis pas sysadmin et du coup n'ai pas l'occasion de le manipuler.

Pour info, je trouve le site un peu confusant: la page de téléchargement par exemple donne l'impression que l'on va télécharger openLDAP, et non des outils pour openLDAP.
La présentation de la page d'accueil me donne l'impression que les 4 lignes en dessous de "COMPILATION OF TOOLS FOR LDAP ADMINISTRATORS" sont des liens, mais non.

Enfin, merci en tout cas, je vais creuser ça.

PS: si jamais quelqu'un a des liens pour apprendre LDAP par un débutant (débutant LDAP, hein, pas débutant debian ou en shell) ça m'intéresserait.
J'ai déjà un peu joué avec, je me souviens notamment que l'un des outils pour l'intégrer dans PAM sur debian segfaultait, mais je n'ai pas été très loin.

Lien cassé? [edit] c'est le ":" à la fin, voici le bon lien.

De toute façon je crois me souvenir d'une rétrospective sur le sujet ou il était admis qu'ils n'étaient pas vraiment modérés. C'est dommage du coup de faire "genre on modère" alors qu'en fait que dalle. Après, je comprend que c'est du boulot de modérer, sachant que les liens, ben, ça reste ce qui tombe le plus (après les commentaires, j'espère quand même, mais bon).
Il serait peut-être pertinent de mettre à jour les règles officielles si elles ne sont pas appliquées.

En fait, la personne derrière cet effort de portage vise les 250 maps, aux dernières nouvelles (et est a plus de 200). Bon, à l'origine, elle parlait d'atteindre seulement les 100, donc, à voir la valeur qu'on accorde a cette "limite" :) (mais la valeur de l'effort, elle, est bien réelle, c'est une évidence).

A mon avis, le problème c'est que ni le titre, ni le lien lui-même n'indiquent le sujet. Et comme en plus, c'est youtube, donc privateur et, "pire" google… voila quoi.

Cela dis je suis entièrement d'accord sur le fait que les liens sont plus que régulièrement sans aucun… lien, justement, avec la ligne éditoriale de linuxfr (et il me semble que, contrairement aux journaux, les liens doivent la suivre un minimum. Malheureusement je ne trouve pas les règles de modérations qui s'appliquent aux diverses sections, donc je ne peux pas citer).

Exemple typique au sujet du hors-sujet: https://linuxfr.org/users/gbetous/liens/travailler-avec-les-francais-temoignages-de-17-etrangers-venant-de-12-pays
Il n'y a ni rapport avec linux, ni rapport avec le libre, ni rapport avec même juste le logiciel.

Ça tombe bien, je n'ai jamais parlé de réinventer la roue mais d'avoir des défauts.

C'est difficile, mais tout le monde réinvente la roue sans trop de poser de question, malheureusement.

Pour le fait que le format pourrait être mis à jour, je suis d'accord, sur la théorie du moins (en pratique, forcément, c'est pas la même done).

courant pour certains langages.

D'ailleurs, je me dis, Perl utilise un repo, et je n'ai pas souvenir d'avoir vu ce type de problèmes dans les infos?
Pour ceux qui ont été affectés, je dirait: JS, python, et… c'est tout, non? Rust n'as pas encore été ciblé? Quels autres langages ont été affectés, en fait?

Si, ça arrive.

C'est vrai, il peut y avoir des cas d'usages. Désolé d'avoir été aussi péremptoire. Mais je pense que c'est loin d'être la majorité, ou alors tu va me dire que tu utilises du haskell, du java, du C#, du C, du python, du JS, du perl et whatnot dans la même boîte?
Bon, techniquement, perl sous debian t'as pas le choix, python n'est pas le plus simple a esquiver et maintenant ils commencent a mettre JS en dépendance obligatoire des paquets de documentation (ce qui me fait vraiment chier, au passage), mais l'idée est la: je doute sincèrement que l'accès à la totalité de l'archive Debian soit nécessaire dans la plupart des cas.

Par contre oui, ça se fait, et plutôt bien, tant qu'on a l'espace disque. L'avantage est qu'il suffit de pomper la totalité d'un repo http sur un serveur et ça juste roule avec des outils comme reprepro.

mais est très peu utilisé en comparaison

Il fut une époque ou python était très peu utilisé, lui aussi. Troll à part, tu as raison, mais il n'empêche qu'on ne peux pas parler de réinventer la roue quand quelqu'un utilise ar, surtout quand le projet en question est loin d'être jeune.
Je ne connais pas l'historique derrière ce choix, mais il me semble très clair que pour critiquer ce choix, il faut critiquer en fonction de l'existant à l'époque, et des performances des autres solutions à ce moment. De nos jours, changer ça risquerais de casser bien des systèmes pour un gain bien faible (si ça marche, ne répares pas!).
Et de ce point de vue, l'usage de tar pour tout et n'importe quoi est aussi risible: le besoin initial était d'archiver sans perte de place sur des lecteurs de bande!

Je serais curieux de connaître la raison du choix de ar au lieu de tar ou des autres formats de l'époque cela dit (zip?). Si quelqu'un à une info ou une piste, je suis preneur.

Juste un commentaire quand même, pour préciser que ces logiciels (enfin, au moins claws, mais je doute que sylpheed n'en ait pas) ont un plugin pour faire le rendu HTML directement.
Pour ma part, je ne l'utilise pas, et en effet, quand je peux utiliser claws mail, mes mails sont… juste efficaces.

Oui, c'est du rendu texte, mais personne ne s'en est jamais offusqué, tout comme je ne m'offusque pas qu'ils utilisent du html… pour la simple et bonne raison que je ne m'aperçois pas qu'ils utilisent html, et qu'eux ne s'aperçoivent pas que j'utilise du texte brut avec une fonte mono-space.
La seule chose qu'ils voient, c'est que je ne mets pas de couleur dans mon texte, et qu'au lieu de souligner, mettre en gras, italique, etc, j'utilise en gros du markdown (qui tire ses origines… du mail, justement, me semble?).

Bref, ça juste marche. Le seul moment ou ça ne marche pas, c'est pour les rendez-vous, mais je n'ai pas testé depuis un bail (peut pas utiliser claws a mon poste actuel, malheureusement… je dois me farcir les horribles outlook lourd et web qui sont totalement inutilisable à mes yeux) ça a peut-être changé (extension vcalandar? Je ne sais pas ce qu'elle supporte exactement.)

WireGuard est disponible nativement dans le noyau Linux depuis la version 5.6 et est disponible comme un module externe pour les noyaux 3.10 et ultérieur (en utilisant le support dynamique de chargements de modules DKMS).

Je ne sais pas a quel point le noyau supporte d'avoir 2 implémentations du même module chargés?

À la place du .txt tu peux faire du latex, ça se versionne tout aussi bien.

C'est ce que j'utilisais pour les documentations "read-only" pas techniques. Pour que ça soit plus joli. Au passé, parce que j'ai changé de métier et je n'ai plus ce besoin du coup, sinon LaTeX est effectivement mon outil préféré à l'heure actuelle, même si je m'en sers une fois tous les 36 du mois.

Pour dpkg sans root il y a FakeRoot : https://wiki.debian.org/FakeRoot

C'est un truc qu'il faudrait que j'arrive a me motiver pour utiliser, mais bon, entre fakeroot, fakechroot, fakeroot-ng, et leurs configs, j'avoue avoir la flemme et avoir tendance a juste chroot. Simple, efficace, même si ça requiert un compte root.

Je pense qu'il y a moyen en fait de faire tourner dpkg sans les droits root. D'ailleurs, un essai rapide avec:

mkdir /tmp/foobar
cp /var/cache/apt/archives/busybox-static*.deb /tmp/foobar
cd /tmp/foobar
PATH=/sbin:/usr/sbin:$PATH dpkg --root=./ --force-not-root -i busybox*

Ca semble marcher.
Du coup, lui dire qu'on s'en fiche de pas être root, parce que bon, hein… et spécifier le chemin qu'on veut. Je pensais que ça aurait été plus compliqué en fait. Comme quoi, suffit parfois vraiment de se sortir les doigts.

Bon, j'ai pris busybox-static pour une raison: c'est le moins risqué.
Mais dans l'hypothèse ou l'on a des paquets qui sont conçus pour ne pas nécessiter un accès root à l'installation, ça devrais vraiment pouvoir fonctionner. Typiquement, pour des programmes interprétés, et non compilés (parce que pour les compilés, ldconfig & consorts)…

ceux qui lisent pas la doc, sont aussi ceux qui ne l’écrivent pas ceci dit en passant…

C'est marrant ça. Parce que moi, quand j'écrivait de la doc (tout le temps quand j'était au taf, a divers niveaux de qualité en fonction de l'urgence et de la finition) c'était pour tout le monde, les autres, et moi.
Je préfère avoir une doc qui me permette de revenir 3 mois plus tard a un code que j'ai oublié parce qu'entre temps je suis passé sur 2 ou 3 autres sections du système, et très honnêtement, je sais pertinemment que pour de la doc, mieux vaut ne pas attendre après les autres…

Donc, si tu veux de la doc utile, c'est pas compliqué: tu te sors les doigts quand tu fais ton projet, tu commences par documenter l'archi du proto, puis tu code, puis tu mets à jour la doc. C'est p'tet pas agile, c'est pas non du plus du V, mais ça a très bien marché pour moi. Et quand un collègue venait me sortir qu'il avait trouvé un bug dans mon code, je demandais 2 choses: les logs, et 5 minutes pour qu'il me dise pourquoi il avais mal interprété la doc. Que je la mette à jour.

Alors, quand je parle de doc, hein, je parle pas de ces horreurs de fichiers word. Je parle d'un simple .txt posé dans le repo, et quand ça deviens trop massif, je le divise (typiquement: utilisation, déploiement et maintenance, déjà ça rend les choses plus simples).
Oui c'est moche le .txt, y'a pas de couleurs, pas de gras… mais on peut faire des paragraphes et des retours à la ligne sans se prendre la tête, on peut utiliser son éditeur de code préféré pour maintenir/visualiser, et ça se versionne super bien. Tant qu'on ne s'amuse pas trop a coller des URI à rallonge en brut dans le texte, mais ça de toute façon on peut pas y faire grand chose (enfin si: les mettre dans un index, mais de toute façon c'est rare que je colle des URIs longues dans une doc technique).

Genre #include et démerde-toi pour que ça soit la bonne version dans le path.

Je pense que tu es au courant, mais certaines libs, genre les libs standard de C et de C++, ainsi que leurs variantes des divers compilateurs, définissent des symboles que l'on peut vérifier pour s'assurer d'avoir les fonctionnalités dont on a besoin.
Je ne dis pas que c'est parfait, mais je dirais que ça semble marcher, et peut-être que personne n'a rien trouvé de mieux, parce que le problème n'est pas trivial.

"réinventer la route"

Je voulais bien entendu dire "réinventer la roue", pas la route.

Je ne connais pas la plupart des points soulevés, mais je suis intrigué par certains:

plein de fichiers à télécharger (apt) ce qui rend le mirroring compliqué

Je ne pense pas qu'il soit pertinent de chercher a dupliquer la totalité des paquets de l'archive Debian pour se monter une reprepro local à la boîte, pour le coup. Un système de type serveur sous Debian, avec une install raisonnée, le coeur du système tiens sur environ 300 paquets, chaque nouvel fonctionnalité apportant sont lot de paquets (et ça peut monter très vite selon les technologies, c'est vrai, mais ce n'est pas lié à apt) mais je doute très fortement qu'une boîte ait besoin de tous les DEs et leur tétrachiée de dépendances…

formats d'archives peu classique (.deb qui utilise des ar)

La, vraiment, je ne comprend pas comment on peut sérieusement mettre ça dans un message intitulé "réinventer la route"… Tu parles d'un format d'archive qui existe depuis 1971 selon wikipedia, et qui est actuellement toujours très utilisé pour… la compilation d'outils natifs.

Accessoirement, selon wikipedia dpkg a reçu sa première version en 1994, et est antérieur de 3 ans à rpm (et la, de ce que j'ai lu on est effectivement dans la réinvention de la roue, carrée qui plus est, mais je ne connais pas les raisons historiques).

Je ne défend pas les autres technologies, parce que je ne les connais pas assez, mais de ce que je vois de tes critiques sur .deb et apt, je ne suis pas convaincu que ça soit super fondé.

Les paquets système (RPM, deb) sont stables, testés, et mis à jour de manière intelligente, mais parfois on a besoin d'une version plus récente. Faire ses propres paquets systèmes et les charger dans un Docker ou un Puppet semble bien, mais c'est un investissement en temps

Pour l'avoir fait moi-même dans mon précédent job, faire un script qui génère des paquets binaires (j'insiste, parce que les paquets source c'est plus chiant, faut se taper toute l'usine a gaz pour build) pour les .deb est trivial, tant que tu ne t'embêtes pas a utiliser les scripts pre-rm, post-rm, pre-inst et post-int.

Concrètement, il suffit de faire un dossier DEBIAN, d'y écrire un fichier control, 2-3 autres fichiers qui détaillent les hash et les dépendances, de lancer un dpkg-deb avec l'option kivabien (je me souviens plus de son nom, ça date, mais apt-file show dpkg-dev devrais pouvoir t'aider), d'upload vers un serveur http géré par, il me semble, reprepro.

Tout ça s'automatise super facilement, vraiment. Je me suis débarrassé d'un tas de problèmes grâce à ça, malgré que je n'étais entouré que de "jeunes" développeurs, sortis de l'école (ou qui n'avaient pas touché au code depuis 30 ans littéralement) et 0 compréhension de comment une debian tourne.

Ce qui est magique avec le format .deb, c'est que c'est juste une archive standard (qui contiens un fichier texte qui décrit la version, 1 archive de meta-données, et 1 archive qui contiens la charge utile), donc tu peux simplement mettre en place ce genre de trucs juste en ouvrant les paquets qui marchent, même pas besoin de lire la doc!
Il me semble que pour rpm ce n'est pas la même chanson, mais je n'en ai réellement aucune idée.

Le seul inconvénient de dpkg, c'est qu'il a "besoin" d'être root, mais… en vrai je pense que c'est faux, si on joue un peu avec les paramètres (de mémoire on peut ajuster ce type de paramètres) et qu'on le pointe sur des dossiers accessibles par des UID!=0. Pour dpkg, ça peut marcher, je pense, mais pour apt ou aptitude, c'est moins évident.
Pas sûr non plus que ça soit pertinent, après tout il suffit de coller une MàJ automatique des paquets dans une cron-tab, disons, le midi, et ça juste roule.

Après, la où les larmes risquent effectivement de couler, c'est quand tu vas essayer de convaincre tes collègues, à cause d'une mauvaise réputation (liée au fait que pour contribuer un paquet, il faut que ça soit un paquet source, et suivre les procédures debian, ce qui est normal… mais ici on parle d'un truc en interne, non?), ou si tout le monde ne marche pas sur une Debian-like…

De mon côté, j'avais bricolé un script shell sur quoi? 150 lignes? Il lisait un fichier texte qui décrivait les données a empaqueter et faisait office de "super-control", je gérais 2-3 bricoles automatiquement (l'archi matérielle, c'est trivial, l'auteur idem, et quelques autres bricoles YMMV) et l'outil était utilisé pour empaqueter:

• 4 daemon
• 1 lib commune a tout ce beau monde
• lui-même
• une bonne 20aine de scripts runit et autres qui étaient déployés en prod (chacun dans leur propre paquet)
• quelques autres outils internes

En tout je devais avoir bien une 40aine de paquets… et franchement je n'ai jamais regretté mon choix. Il faut dire que je n'ai eu que moyennement le choix, vu qu'il fallait bien automatiser le déploiement via PXE, et clairement passer sur des .deb était de loin le moins prise de tête.
A l'origine, j'avais déployé le PXE à l'arrache et dans l'urgence, je dézippais littéralement des tarballs dessus après le debootstrap, et ça a été la cause de bien des larmes, justement, jusqu'à ce que je me bloque quelques heures pour faire ce fameux script, et la, magie, une source de galères au déploiement en moins, tout en n'utilisant que des trucs simples (pas de nouvelle dépendance, c'est agréable quand le système de destination est une beaglebone black ou une CM mano842 avec ses 8Gio de stockage… et même sans ça, c'est plus simple de s'assurer que tout marche, quand il y a moins de 400 .deb installés!).
Bon, de temps en temps un collègue ne comprenait pas pourquoi mon script refusais de tourner, dans ces moments je le débloquais, j'améliorais le message d'erreur, et j'améliorais la doc. Au fur et a mesure ces moments étaient de plus en plus rare, et oui, ils utilisaient parce qu'il n'y avait de toute façon aucun autre moyen de déployer :)

D'autres ici avancent que la gestion des cas triviaux ajoute un overhead inadmissible dans du code c++.

Je pense toujours qu'il est dommage de vérifier le fait qu'un conteneur soit vide a chaque interaction. Par contre, je suis d'accord que l'interface n'est pas optimale et pourrais être améliorée.

Si l'optional en question intègre dans son typage la présence ou non d'une valeur … alors ton système de type peux garantir compile time que tu gère les cas d'erreur

Pas vraiment. Il faut déjà que le compilateur soit informé que la non vérification de la valeur de retour d'une fonction est une erreur (ce que C++17 introduit via [[nodiscard]] mais a ma connaissance ce n'est pas encore utilisé dans l'API standard, ce qui est dommage).

Cette fonctionnalité est ce qui permets à mon avis d'avoir un minimum de garanties à la compilation sur ce genre de bugs (bien bêtes, en plus, et pénibles a trouver), l'optional est "juste" un détail d'implémentation qui permets d'avoir une interface cohérente, mais ce n'est pas le seul cas, typiquement, si je fais juste foobar.empty(); ou foobar.size();, il est évident qu'il y a des bugs, et pourtant il n'y a aucune raison de renvoyer un optional.

C'est un peu ce que je fait, en pratique, et c'est vraiment l'intégration avec le C qui est à mon avis sa très grande force.
Et de la même manière, rien ne force à utiliser la SL (et particulièrement la STL, je ne trouve pas que std::string, par exemple, soit une merveille d'ingénierie, je la remplace personnellement par un vector, ça fait le même boulot, en mieux, parce que plus générique, et de toute façon std::string ne comprend rien aux chaînes de caractères), même si je suis assez fan de #include <algorithm>, qui fournit des algo pratiques qui peuvent facilement marcher avec des conteneurs perso voire même de simples pointeurs (par exemple parce qu'on utilise une lib C pour une tâche précise).

Ca fait sens. Il y a fort a parier que la raison que C++ ne fasse pas ça, c'est… tout simplement son âge. Et le refus de casser des APIs importantes (parce que largement utilisé).

Du coup, il faut quand même vérifier que le retour est None, ou un truc de ce type. D'un point de vue "apparence de code", ça doit donc être relativement similaire, du coup.

Ceci dit, je m'aperçois en écrivant ça qu'il y a un problème important avec le retour d'itérateur qui n'a pas été abordé dans la discussion, plus important que l'UB de déréférencer un élément hors-limite: il est possible d'accéder à un élément valide, ce qui génère un bug, si on donne un sous-ensemble à manger à, disons, std::find.
Je trouve que c'est plus gênant que l'UB, parce que l'UB on peut contourner le problème avec des canary ou UBsan, et j'imagine que c'est une des choses que Rust fait par défaut (on ne peux pas tout vérifier à la compilation, après tout).

J'espère que le C++ finira par avoir des versions des algo qui retournent un optional. Je trouve ça bien mieux que les exceptions, de manière générale, plus lisible, et le compilateur peut vérifier que les cas sont traités. Si ils pouvaient en profiter pour faire la même avec les conteneurs, ça serait bien aussi.

Je croyais que c'était orienté linux moi.

Mais surtout, il me semble bien que la ligne éditoriale ne s'applique qu'aux dépêches.
Sinon, je ne saurais expliquer pourquoi il y a eu tant de discussions, liens et journaux (non modérés) sur des trucs totalement hors sujet, qui ne concernent ni la notion de logiciels libre, ni les systèmes basés sur linux. Genre, les trucs liés au covid, les discussions sur le genre, la guerre en ukraine, …

Manque de bol, je n'arrive pas a retrouver la dépêche qui fait un retour sur l'ajout des liens, il me semble que ce type de sujet était abordé.

Mon seul souci avec le Rust, c'est ma propre résistance au changement, j'ai la flemme de l'apprendre.
Bon, il y aurait peut-être aussi le "tout est lié en statique", mais je ne sais pas si cette restriction est réelle ou s'il n'y a pas un moyen de garder des libs dynamiques (de la même manière que j'ose espérer qu'on n'est pas obligé de passer par un repo npm-style, mais ça j'en suis presque sûr que c'est possible), qui n'est pas vraiment lié au langage lui-même si à sa lib de toute façon.

Sur le papier, il a tout pour me plaire, pourtant, sauf peut-être la très très grosse compat avec le C (en C++, il y a juste rien à faire pour utiliser une lib C. J'imagine que ça ne dois pas être le cas de rust, mais en vrai je ne sais pas). Pas sûr que ce point suffirait a m'empêcher d'utiliser rust, par contre.

Ceci dit, question: j'ai cru lire que rust n'utilisais pas d'exceptions, donc, sur la problématique de l'erreur d'un "find max value in range", comment ça marche? Retour d'un équivalent de std::option j'imagine? Parce que bon, utiliser un paramètre de sortie, type error_t find_max_in( start, end, result ) c'est assez moche (force a déclarer les variables avant, impossible de chaîner les appels, etc), donc je ne vois pas vraiment d'autre solution.

Le coup du tableau trop court d'un élément est un classique… et c'est bien pour ça que j'apprécie C++, justement: pas besoin de gérer ses tableaux dynamiques à la main, vector fait ça très bien tout seul (et depuis avant les années 2000). Et si il ne le fait pas assez bien pour une raison X ou Y, alors on implémente son propre conteneur, et on colle des assert un peu partout: ça aide.

Je pense qu'en C aussi il doit y avoir des outils pour aider, mais vu qu'en C rien n'est automatique, l'intérêt est assez faible.

Bref, pour moi un développeur C++ qui fait une allocation dynamique doit avoir une vraie bonne raison, comme par exemple aimer se faire chier avec des bugs inutiles.

Je dirais que pour utiliser C pour un nouveau projet, il faut le même type de vraies bonnes raisons (non, vraiment, je n'en vois pas beaucoup, de raisons d'utiliser le C sur un nouveau code… quitte a ne pas utiliser la RTTI et les exceptions pour des raisons de taille binaire, rien n'empêche d'avoir ses propres conteneurs sans exception, et le résultat sera aussi portable que pour du C. Encore que… j'ai un doute, il me semble qu'il faut un peu plus de code d'initialisation pour C++ que C, de l'ordre de quelques dizaines de lignes en plus? Sur du baremetal je suppose que ça peut être une bonne raison, mais sur un PC? Pas vraiment.)… Qu'il est bon d'être trolldi.

C'est un choix qui est discutable (si tout se passait aussi bien que tu le dis ce ne serait pas un sujet) et pas généralisable.

A un moment, je trouve ça quand même très gênant d'avoir des gens incapables de lire une doc aussi simple que celle de, par exemple, std::find_if…

d'autant que ça peut vite partir en cascade.

Non parce que tu la gère cette erreur. Tu la gère après et pas avant.

Je parlais du fait d'imbriquer des appels qui font faire encore et encore le même contrôle, pour rien, parce qu'il a déjà été fait avant.

Au pire, si tu veux de la sécurité au lieu des perfs, tu peux très bien compiler avec UBsan/ASan, le programme plantera salement, tout comme si une exception avait été lancée sans être attrapée. Et en bonus: tu auras l'information de la ou est le problème, chose que l'on n'a pas avec les implementations d'exceptions en C++ (à ma connaissance).

Donc pour toi tous les pièges qu'on peut trouver dans une bibliothèque standard ou mieux dans le langage lui même ne sont jamais un problème : les utilisateurs doivent à minima avoir une compréhension du langage pour s'en servir.

Je n'ai pas dit ça.
Je trouve juste que le paradigme de renvoyer out-of-bound en cas de non trouvé ou de conteneur vide, c'est pas déconnant du tout. Ca me semble personnellement plus propre que balancer des exceptions pour un oui ou pour un non.