freem a écrit 5019 commentaires

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.

Lenteur excessive

Même que c'est pour ça que ça n'a jamais été utilisé pour faire des jeux vidéo sur les vieux téléphones… laissez-moi réfléchir… j'ai comme l'impression d'oublier un détail important, la?

Plus sérieusement, je ne pense pas que Java soit la raison derrière le gouffre en RAM et la faible lenteur.
J'accuserai plus volontiers des développeurs qui ne se sont pas cassés la tête, parce que "le client rachètera de la RAM au pire" (entendre ça de la part d'un prof, ça fait rêver… et c'était pas sur du java!), parce qu'il faut release rapidement ou autre.
Ainsi, pour les serveurs, que les admins qui n'ont pas paramétré la JVM selon les besoins de l'application.

Le java dont je me souviens (je n'ai jamais aimé ce langage) a effectivement des "problèmes" hein:

• définir la fonction main() comme étant une fonction statique d'une classe qui sera instanciée qu'une seule fois, parce que seule la POO devrais exister (oupa)
• des namespace avec une profondeur telle qu'on se demande si a force de creuser on va pas finir en enfer

Mais globalement, les exceptions bien spécifiées je trouve ça au contraire génial: si C++ avait ça, ben les exceptions je m'en servirais!
Les getter/setter, j'ai toujours eu ça en horreur, mais c'est pas lié à java, juste a du cargo cult.
Overengineering? Idem.

Tous les trucs que je reprochais à Java, je les ai vus dans des codes dans d'autres langages. Tous.
D'autres langages? Lesquels? C. Et C++.

Oui, j'inclue le C, parce que j'ai vu des gens réimplémenter l'héritage (c'est pratique faut dire, quand c'est bien utilisé) en C, et en abuser. Les namespaces n'existent pas en C? Pas grave, le workaround c'est des "conventions de nommage" du style un_truc_comme_ca_et_ajoutons_encore_un_peu_de_texte_pour_la_route(). Le truc, c'est que tant C++ que Java permettent de faire du using pour réduire ça. Avec le C, on ne peut pas, on est obligé de recourir à des #define…

Ah. Le Go et le Rust, c'est mieux. C'est probablement vrai, mais… l'astuce, c'est l'âge.
Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.
En face, C, C++, Java, Pascal… ces langages ont de l'historique. Et, non, faire comme python2 vers python3 n'est pas acceptable pour des langages de leur importance. A titre d'exemple, le programme ppp que l'on utilise pour les liaisons point à point (modems, entres autres, et sisi c'est toujours utilisé) utilise a certains la endroits des résidus de K&R.
Il arrive que quelques points soient interdits dans des versions plus à jour (auto_ptr pour C++, pour le C les trigrammes sont retirés dans C11 il me semble) mais c'est rare et ne casse pas 90% des bases de code.

comment une bibliothèque fait pour dire à son utilisateur "là il y a un cas que je ne sais pas traiter".

Avec de la doc.

Je préfère une lib qui est documentée correctement et qui ne vérifie (explicitement) pas des pré-conditions, ça me permets d'avoir un code comme ceci:

void foo( std::vector<int> const& bar )
{

  if( bar.empty() ) { return; }
  std::vector<int>::iterator it1 = std::find_if( std::begin( bar ), std::end( bar ), []( int v ){ return v > 10; } )
  if( std::end( bar ) == it1 ){ return; }
  std::vector<int>::iterator it2 = std::find_if( std::begin( bar ), std::end( bar ), []( int v ){ return v < 10; } )
  if( std::end( bar ) == it2 ){ return; }
}

Sans que std::find_if n'ait besoin de vérifier a chaque fois que le vector est bien peuplé.

Le fait que le vector ne soit pas peuplé ne relève clairement pas de la responsabilité de std::find_if, ni de bien d'autres fonctions, et souvent on fait plusieurs opérations sur les collections, et il est plus pertinent en terme de perfs de ne faire le boulot qu'une seule fois plutôt qu'a chaque appel, d'autant que ça peut vite partir en cascade.

Alors, oui, ça implique que le dev sache lire une doc… mais savoir lire une doc, ça me paraît la base du métier: on lit de la doc en permanence, a commencer par les documents (plus ou moins bien faits) qui décrivent le besoin auquel on doit répondre.
Et le C++ n'a jamais fait de mystère qu'un de ses objectifs principaux, c'est la performance. Faire un truc rapide sans avoir de compréhension de la lib standard, peut importe le langage, ça me semble très… disons difficile.

Ca existait: std::auto_ptr. Il avait plusieurs problèmes, notamment, je cite:

Because of these unusual copy semantics, auto_ptr may not be placed in standard containers

Dans mon cas, je n'ai appris pour auto_ptr qu'en apprenant que C++0x (à l'époque) allait introduire un pointeur automatique (std::unique_ptr) qui résoudrait les problèmes d'auto_ptr. Les types qui se prétendaient profs que j'ai eu en BTS n'ont jamais parlé de cette fonctionnalité pourtant très importante.

Je ne sais pas si mon cas peut être généralisé, mais au moins dans mon cas, la seule raison de non-utilisation d'auto_ptr dans mes codes ça a été: je savais pas que ça existait.

C'est une sorte de récap des "pratiques" qu'epson et autres constructeurs d'imprimantes utilisent pour forcer le rafraîchissement du parc, empêchant les consommateurs de changer des cartouches d'encre, les vidant avec des tests de calibration inutiles, en collant des DRM dans le papier, en briquant l'imprimante quand elle a fait un certain nombre de pages, etc, etc, etc.

Avec la gestion des exceptions, c'est plutôt:

try
{
  faire_un_truc();
}
catch( auto& e )
{
  throw;
}

Sans les exceptions:

if( faire_un_truc() == ERROR )
{
  return;
}

Ca, c'est pour le squelette individuel.
Les exceptions sont extrêmement verbeuses dans des fonctions courtes (4 lignes effectives ici) quand on veut traiter une ou plusieurs erreurs, ce qui me semble être le but originel (si c'est juste pour logguer, franchement, on a vu mieux que les exceptions de C++, à commencer par celles de java qui affichent toute la stack automatiquement, et qui accessoirement a un compilateur qui râle, de mémoire, quand les exceptions ne sont pas toute gérées… c'est à dire une véritable intégration dans le langage).

En théorie, sur une fonction longue, avec juste une partie des erreurs traitées (ou avec aucune traitées), ce qui serait l'intérêt, alors oui, le code est plus clean et plus court, mais bon perso j'évite au maximum les erreurs longues…
Il y a aussi le problème que, dans un catch(), tu catches l'erreur de quelle ligne, au fait? En C++, l'info est perdue.

Dans une gestion des erreurs traditionnelle avec RAII, je fait juste:

#define xstr(s) str(s)
#define str(s) #s
#define HEADER_LOG __FILE__ " [" str( __LINE__ ) "]: " 
...

class bla
{
public:
  bla( void ) = default;
  bla( bla const& ) = default;
  bla( bla&& ) = default;
  bla& operator=( bla const& ) = default;
  bla& operator=( bla&& ) = default;
  ~bla( void ) = default;
  //oupa, selon qu'on doit gérer des trucs nus...

  static bla create_bla_from_network( foobar )
  {
    bla ret;
    if ( do_something( foobar ) ) { return bla(); }
    return ret;
  }
  bool operator==( bla const& o ){...; return result; }
};

bool hello()
{
  auto world = bla::create_bla_from_network( foobar );
  if( wold == bla() )
  {
    fputs( HEADER_LOG "bla bla\n", stderr );
    return true;
  }
}

Et je garde l'info de l'endroit ou le problème s'est produit, contrairement a ce que font les exceptions en C++.

Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.

Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.

Chacun ses contraintes, mais eux ont le financement :p

Et au pire quand ça pète ils sont plus dans la même boîte :D
Blague a part, je ne voulais pas dire que perl est mieux que les autres. Ce que je voulais dire, c'est que ton point n'était pas autant en défaveur de perl qu'il n'en donne l'impression, parce que justement il y a une grosse de base de code qui existe, et que ce n'est pas parce que les utilisateurs de perl sont discrets qu'ils n'existent pas.

Pour prendre un cas bien, bien extrême (on est vendredi après tout): "cobol is still relevant in 2022". Ca recrute encore sur cette tech, et il faut bien maintenir, le temps de finir les migrations, si elles ont été commencées, ce qui est loin d'être garantit partout.
Qu'un langage devienne un langage de niche n'est pas choquant, surtout que bon, perl, ça a toujours été un langage de niche pour moi: conçu pour remplacer /bin/sh, awk, grep, sed… mais les gens utiliserons toujours ces outils la en premier, par simple flemme et puis c'est ce qui est utilisé dans le terminal. Puis c'est simple. Chiant a maintenir quand ça se développe, un peu comme un fichier excel, et perl serait un peu le ms access du coup. Possiblement moins chiant, mais pas le truc qu'on fait naturellement.

Et je n'utiliserais pas perl sur de l'embarqué ou la contrainte de stockage est hyper forte. J'ai souri quand j'ai vu l'article considérer qu'une raspberry pi c'est serré… Je veux dire, il y a combien de stockage sur un rPI? Sur les BBB, de mémoire il y a un lecteur de carte + 8 gig de stockage. Tellement de place que c'est dur à remplir, si on fait juste un peu attention.

Sur le site de busybox on peut lire:

microperl A small standalone perl interpreter that can be built from the perl sources via "make -f Makefile.micro". If you really feel the need for perl on an embedded system, this is where to start.

Suivi juste après d'une phrase qui semble plutôt encourager à utiliser lua pour du code neuf. Et en terme d'embarqué ultra contraint, j'aurai tendance a me fier aux auteurs de busybox.

D'ailleurs, vu qu'il existe des compilateurs python, je dirais même que ça serait la solution la plus simple: une fois compilé, j'ose espérer que les programmes sont plus compacts que tout l'environnement (et plus rapide, mais ça, tant qu'on n'a pas mesuré, on peut pas savoir si c'est pertinent, et impossible d'avoir une estimation simple et générique, contrairement au stockage).

Ma question est plutôt sur le nombre de paquets a installer, et maintenir. Le contexte de cyber sécurité est loin d'être détendu, il me semble, donc même si je sais que la sécurité on s'en fout un peu, il me semble que faciliter la maintenance et réduire la surface d'attaque, c'est pas une mauvaise chose.
Si un jour ruby ou python remplacement complètement perl dans le coeur de mon système, j'aurai le même type de critique contre l'usage de perl. Et le point ici, ce n'set pas vraiment l'espace disque, même s'il peut parfois être pertinent. C'est plutôt le problème de maintenance, de surveiller les failles de sécurité (qui existent dans tout éco-système, je ne crois pas que perl soit tellement mieux de ce point de vue) et de pouvoir boucher les trous. C'est plus facile de limiter le nombre de trous, quand il y a moins de trucs installés, c'est tout.

Un saignement par mois désormais. .

A ne pas sortir du contexte, j'imagine?

En même temps je répondais a ça:

Ce journal est un peu surprenant, Firefox est justement super dans le fait que si le comportement par défaut ne te plait pas, il y a tout un tas de choses qui sont paramétrables, je crois que c'est une de ses caractéristiques qui le distingue des autres navigateurs justement - il est excellent pour ça :-)

Ici, le seul argument, c'est que c'est vachement configurable. Ca ne dis pas en quoi, par contre, mais marrant, personne n'a demandé de développer ça. Parce que ça défend Firefox?

Hum… voyons voir, je n'ai ni otter ni firefox ni vivaldi sous le coude, la, donc je vais répondre de tête:

• les mouse gestures.
• avoir la barre des onglets en vertical, c'est très pratique vu nos écrans moderne.
• désactivation de JS, au site par site.
• l'apparence, le thème graphique quoi.

J'en oublie certainement, mais bon…

Pour ce qui est de la quantité de trucs configurables, le about:config de firefox, il existe aussi chez les autres hein (sauf que ça a un nom plus adapté: about:flags). Par contre ça ne compte pas vraiment, je trouve, parce que bon, sinon windows est ultra paramétrable, tu as vu la tonne de trucs qu'on peut config via regedit?
A ce stade, on pourrais presque dire que puisqu'on a accès au source et qu'il y a même une API de plugin on peut tout faire… (pour rappel, c'est vrai aussi de plusieurs autres, chromium et otter, par exemple)

Est-ce que ça contre-balance la quantité de chose qu'on peut configurer sur Firefox et pas ailleurs ?

Tu me demandes de développer, mais toi tu ne le fais pas?

Justement.
Il y a une plus grosse base de code perl dans le coeur de mon système (debian) que, par exemple, python. Quelqu'un a mentionné ruby, plus haut: idem.
A tel point que l'interpréteur perl est required (sur debian) mais j'ai eu de nombreux systèmes parfaitement fonctionnels sans python ni ruby ou autres.

Du coup, ça ne serait pas, justement, les gens qui utilisent ces langages qui n'en font qu'à leur tête?

Ton argument est, justement, en faveur des langages qui sont arrivés les premiers…

Ah oui. Et aussi…

• [perl-base(https://packages.debian.org/bullseye/perl-base): 3 dépendances, ~7.5megs une fois installé;
• python3-minimal: 5 dépendances (je "déplie" libpython hein), ~10megs installé, à noter que je n'ai pas encore vu de paquet python utiliser le minimal, hein, a chaque fois en pratique il y a une chiée de trucs qui arrivent avec…
• ruby2.7: la flemme, trop de trucs a compter.

Ce que je veux dire, c'est que rien qu'en théorie, perl gagne sur le nombre de paquets et l'espace disque occupés. En théorie, python est comparable, mais en pratique je n'ai pas souvenir d'avoir vu une seule application python ne pas dépendre des paquets plus complets. Je sais que de nos jours, quelques megs de stockage ne font pas une grande différence dans l'immense majorité des cas, mais le fait d'avoir moins de paquets installés, ça permets de pouvoir plus facilement lire les changelogs de tous les paquets lors des mises à jour. Et ça, je pense que c'est important, d'un point de vue sécurité.

Toujours sur une Debian, ou perl est requis, se concentrer sur perl ou dash pour automatiser ça implique qu'il n'y a pas besoin d'installer d'autres interpréteurs, ce qui réduit la surface d'attaque.
Et vu que tu parles d'automatisation, avant qu'on ne me demande "comment on gère le parc", je dirais que pour éviter un nouvel interpréteur, toujours sur une debian, je vois:

• drist, en shell posix
• rexify, en perl
• cfengine3, en C

Seul cfengine3 dispose d'un système d'agents, par contre (pour un outil codé dans l'un de ces langages. Je peux me tromper) ce qui implique que les systèmes peuvent se mettre au propre d'eux mêmes, quand ils ont le temps et l'accès au réseau (l'air de rien, l'accès constant au réseau etre loin d'être aussi garanti qu'on ne le pense, il suffit de voir les équipements de rue qui peuvent être placés dans des endroits ou ça ne capte pas, par exemple. Je ne parle pas juste de mémé dans son coin perdu ou c'est a peine si le téléphone cuivre passe).
A ma connaissance, il existe de nombreux autres outils de gestion de conf, qui eux, sont en ruby ou python principalement, donc c'est vrai qu'il y a de très, très grandes chances que de toute façon python ou ruby soient installés.
Mon propos n'est pas de nier une réalité (dans la plupart des cas, il y aura un truc plus connu de nos jours que perl d'installé) mais bien de rappeler qu'il est très possible que perl5 soit justement la façon de faire au sein d'une industrie, puisqu'il est la depuis très longtemps (je n'ai pas souvenir d'avoir utilisé debian basée sur perl4, ni même embarquer les deux… pour python, no comment) et a une belle assise dans nos systèmes actuels. A moins de considérer debian comme négligeable :) (plutôt utilisé par des petites boîtes il paraît).

A noter que je ne code ni en python, ni en ruby, ni en perl, donc je ne sais pas ce que ces langages valent en terme de perf.

Ce journal est un peu surprenant, Firefox est justement super dans le fait que si le comportement par défaut ne te plait pas, il y a tout un tas de choses qui sont paramétrables, je crois que c'est une de ses caractéristiques qui le distingue des autres navigateurs justement - il est excellent pour ça :-)

Pas vraiment non.
C'est l'un des pires navigateurs en terme de facilité de configuration, selon moi. Même le pire, depuis que IE est mort, je dirais.
Faudrait que je fasse un bug report, mais au final, c'est plus simple de juste utiliser un navigateur moins difficile a paramétrer, même si non libre. Mais bon, pas terrible de dire ça sur un site dédié au libre.
Reste qu'a mon avis, le navigateur libre le plus intéressant en terme de config, et je parle bien d'un libre, c'est Otter browser. C'est très loin de firefox, sur ce point. Loin devant.

il n'y a que ceux à base de firefox ou de webkit

Yep. Et pour webkit, il n'y en a pas tant que ça qui soient encore maintenus. Typiquement, il me semble que midori ne l'est plus, depuis longtemps. A ma connaissance, otter-browser est encore activement maintenu, et dispose même à la compilation d'un choix entre plusieurs moteurs de rendu, webkit et je-sais-pu.
C'est à mes yeux le seul espoir qu'il reste pour avoir un navigateur libre avec une UI potable et un support du web moderne acceptable.
Par contre, y'a pas grand monde derrière, ça n'avance pas aussi vite qu'on le voudrait (ça n'avance jamais aussi vite qu'on veut de toute façon) et ça ne coche pas un certain nombre de cases dans la demande.

D'un autre côté, une demande qui veut un navigateur alternatif qui soit mieux que les navigateurs upstreams, c'est un peu comme les recruteurs qui cherchent un mec sorti de l'école avec 20 ans d'expérience sur une techno qui n'existe que depuis 5 ans, payé au smic…

throw nan? J ai toujours entendu dire que c'etait un barbare exceptionnel.

Ou est la porte, deja…

Ma foi, ça arrive. Ca vaut aussi pour plus bas:
«Non le "ben tiens" faisait référence au fait que tu aies arbitré en ta faveur : c'était bien un sous-entendu d'ailleurs, mais à vocation humoristique (réussi ou loupé)»

Impossible de lancer la pierre, il m'arrive souvent aussi de mal interpréter. Ou de mal m'exprimer. Parfois c'est pire, je fais les deux à la fois!
D'ailleurs, la preuve, j'ai mal interprété le «ben tiens» :) CQFD

Sauf que je n'ai pas remis en cause ton éthique? (plutôt le contraire en fait, vu comment j'avais interprété le "ben tiens")

Blague à part, c'est surtout une limite des liens pour moi.
Un lien ne demande aucun travail pour être partagé, alors qu'un journal nécessite à minima un petit texte.
Quand les textes sont très petits, certains utilisateurs vont poster un lien avec un commentaire en dessous.
Accessoirement, les journaux sont, il me semble, mieux mis en avant, les liens étant juste absents de la page d'accueil par défaut (celle que je ne peux plus aller voir dès lors que je me connecte, et du coup j'ai un doute mais je ne peux pas vérifier :/).

Il ne me paraît du coup pas forcément déconnant d'avoir des "doublons" à ~60min d'intervalle (c'est court, 60 minutes, même si on pourrait dire que pour le texte dans ce journal, ça ne l'est pas). Et bien difficile en effet de dire lequel devrais être modéré.

Je soupçonne que le "ben tiens" fait référence au fait que la modératrice qui interviens pour dire que le doublon sera gardé soit également celle qui a partagé le lien, et je le trouve quelques peu déplacé (tout en n'ayant pas pris la peine de pertinenter ou l'inverse).

[edit]

Après vérification non, les journaux ne sont pas mis en avant. Mais d'où pouvais bien me venir cette idée…