freem a écrit 5059 commentaires

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…

Comme quoi, nos vieux clients IRCs qui mettent en highlight uniquement le salon ou l'on est cité, et ce une seule fois (tant qu'on ne va pas dessus forcément), ne sont pas si en retard que ça :D

Parce que c'est plus facile de choper le messager, tout simplement. Remonter les chaînes de fournisseurs est plus complexe, et ça n'est souvent pas faisable en se contentant d'introduire de backdoors dans les algo de chiffrements et en mettant la population entière sous écoute.
Ca nécessite un vrai travail d'enquête, d'infiltration, etc (et ça peut déboucher sur des résultats comme choper plusieurs tonnes de drogues, d'ailleurs, il faut bien les alimenter les gens qui imaginent ces fausses informations! ;))

D'un côté le lien était la en 1er, mais d'un autre côté le journal ajoute une information réelle, lui (déjà testé, et retour d'expérience certes bref mais existant).
Du coup compliqué de justifier la fermeture d'un des deux j'imagine.

Il y a peu, on m'a forcé mis un smartphone dans les mains,

Pareil. Sauf que l'appareil qu'on ma fourni n'est pas verrouillé, et que teams lui-même refuse de marcher avec le réseau de la boîte, à mon plus grand bonheur dam.

Ceci dit, il est assez simple de désactiver les notifications.
A noter pour teams que j'avais le même problème, mais sur le PC. Et c'est aussi assez simple de configurer teams pour couper ces merdes.

Ce que je voulais dire, c'est que couper une source d'informations (peu importe le type d'informations) hertzienne me semble en fait loin d'être trivial.
C'est vrai que le nombre de récepteurs diminue, et je ne sais pas a quel point il est faisable d'émettre sur un réseau hertzien numérique, mais ces technologies sont plus simples a mettre en place par une partie que déployer ou pirater un satellite, et de loin.

Quant aux récepteurs… ma foi, on en trouve malgré tout encore en grand nombre, à commencer par les téléphones et les voitures.

Alors oui, on peut envoyer une force armée (une police ou une milice, l'armée ou la gendarmerie, peu importe) pour occuper un local émetteur, mais encore faut-il savoir ou il est. Dans le cas de Cnews, c'est facile, certes, mais par le passé il me semble que les radios pirates n'étaient pas simples a contrer.

Que certains résultats de physique soient hermétiques au commun des mortels est bien dommage et pose plus la question du niveau d'éducation de la plèbe que du média (ou de la confidentialité qui ne devrait pas être de mise àmha.)

Il suffit de remplacer les pubs pénibles par le streaming de france culture ou des podcast de la méthode scientifique (de cette même radio), non? /me->[]

Pas vraiment.
L'expérience récente montre en Ukraine qu'il est possible de couper ou contrôler le Grand Ternet pour un agresseur (et donc à fortiori pour un gouvernement en place), alors que les ondes, non.
Du coup, la télé ou la radio hertziennes ne sont pas simples à couper, contrairement au réseau internet dans son état actuel.
Aussi étrange que soit cette pensée.

Dans la théorie, on peut bâtir un mesh WiFi qui transcenderais les frontières, et aurait une belle portée, oui, mais techniquement je doute que ça soit réellement tenable, compte tenu du débit qui serait nécessaire.

Cela semble impossible, mais on a bien réussi à se débarrasser des greffons pénibles (flash, realplayer…).

Justement, ils n'ont pas été supprimés, ils ont été fusionnés dans le web. C'est probablement une cause majeure de problèmes pour avoir des nouvelles implémentations, du coup.

Si la France en retard s'amuse pour compenser son retard à sur-utiliser, ce sera le max des bêtises sur le sujet

On parle des politiciens français ici hein… ça me surprendrais vraiment pas, et d'ailleurs écrit dans le lien, tu peux vérifier je n'ai pas inventé la citation :D

Je me souviens aussi avoir récemment lu quelqu'un sur linuxfr (un truc au sujet des code Amber & co aux USA) qui justement disait ignorer les alertes d'enlèvement d'enfants, ou un truc du genre?
Un peu la flemme de chercher sur le site, c'est trop pénible de chercher un commentaire spécifique quand on ne se souviens pas du sujet d'ouverture… du coup, oui, j'ai peur de la sur-utilisation.