Meku a écrit 812 commentaires

Test avec firefox (1 min 30 de démarrage à froid). Les premières minutes étaient assez pénibles (genre 45 secondes pour accéder à LinuxFr), puis après une dizaine de minutes, ça s'est calmé (il n'y avait plus d'activité HDD plein pot) et c'est devenu plus fluide.

LinuxFr s'en sort plutôt bien par rapport à d'autres sites.
Charger une page me prend tout de même une douzaine de secondes. Mais ici c'est le rendu des pages qui paraît le plus lent. Par exemple, si je scroll de plusieurs pages d'un coup, j'aurai des écrans vides pendant 2-3 secondes le temps que firefox redessine la page. Ce ralentissement là, je ne l'avais pas autrefois (y'a 15 ans).

Wikipedia, en consultation, s'en sort pas mal aussi (un peu comme LinuxFr). Par contre, en édition WYSIWYG, c'est 1 min 30 pour charger l'éditeur, puis 1 seconde par caractère modifié.

Le site de nvidia par exemple, c'est 45 secondes pour charger une page, ensuite on peu commencer à scroller mais ça continue de charger des choses. Le formulaire pour choisir son driver, c'est 2-5 secondes de délai pour réagir au choix d'un menu déroulant…

Le site oui-sncf :
- plus de 2 min 30 pour charger la page d'accueil
- plus d'1 min 30 pour obtenir un trajet une fois cliqué sur « rechercher »
- complétion auto des gares dans le formulaire de saisie : 5~10 secondes pour qu'il se déclenche
- affichage détaillé d'un voyage (parmi la liste) : 5~10 secondes (parfois ça affiche le mauvais voyage, comme si le clic avait été capturé pendant que je bougeais la souris, avec un gros lag).
- ça rame même une fois la page chargée (on le sent lors du survol des liens sur une page).
- de nombreux messages firefox « une page web ralenti votre navigateur » …

Je viens de déterrer un vieux AMD K7 (32 bits) de l'an 2000. Je l'ai upgradé en Ubuntu 18.04, sans soucis. C'est un peu lent, mais je pense que c'est pas beaucoup plus lent qu'il y a 15 ans quand je l'utilisais au quotidien.

En sélectionnant une distribution un peu plus adaptée au vieux matériel (là globalement ça fonctionne sous Ubuntu, toutefois, certaines applications, notamment les jeux, ne fonctionnent plus à cause de l'absence du jeu d'instructions sse2…) on pourrait même en faire une machine utilisable comme à l'époque.

Le gros point noir étant effectivement le web. Là, c'est carrément inutilisable sur cette machine (la latence se compte en minutes… la réactivité est à la limite de la mort clinique. J'ai même pas osé tester oui-sncf.com). Je ne sais pas trop comment résoudre ça. Je sais bien qu'il existe des navigateurs légers (dillo, …) mais est-ce réellement utilisable si les sites web sont tout pétés sans leur mégatonne de javascript ? J'ai peur que ce soit un peu perdu tant que le web se complaira dans cette bouillie de javascript largement évitable (au moins, flash, même si c'était de la merde, ça tournait bien sur cette machine).

Un jeu distribué sur Steam ne signifie pas forcément qu'il tourne sous Linux. Il faut toujours aller voir la page magasin du jeu et regarder la configuration requise. Si Linux / SteamOS y est mentionné, alors ça tourne sous Linux en natif.

Exemple pour SpaceChem (un des jeux de Zachtronics, j'ai pris au pif dans la liste de wikipedia) : https://store.steampowered.com/app/92800/SpaceChem/

Celui-ci semble bien compatible Linux.

Maintenant, si un jeu n'est pas prévu pour tourner sur Linux en natif, tout n'est pas perdu. Steam embarque (dans sa version beta ?) Proton, qui est un wine customisé pour Steam, et qui permet de jouer à pas mal de jeux Windows de manière assez user friendly (en gros, tu le lances en un clic depuis ton Steam natif Linux). La compatibilité n'est pas assurée pour tous les jeux, mais protondb recense l'état de pas mal de jeux tournant sous proton, donc tu peux vérifier dessus si le jeux que tu souhaites jouer (mais qui n'existe pas sous Linux en natif) peut tourner via proton ou non.

Je remarque au passage que protondb indique aussi si les jeux sont natifs Linux ou non. Par exemple pour SpaceChem : https://www.protondb.com/search?q=SpaceChem

Il faudrait créer un label pour les sites web bien faits et peu gourmands, ou une échelle de classes énergétiques. Les entreprises étant friandes de green washing, ça pourrait leur plaire d'arborer un logo cool.

Et parallèlement, il faudrait un hall of shame pour montrer du doigt les sites pourris.

T'as qu'à diffuser ton code exclusivement imprimé dans des livres ou sur support audio.

-->[]

Peut-être un pas en avant avec le CERN bientôt :

https://www.phoronix.com/scan.php?page=news_item&px=CERN-Microsoft-Alternatives

Ça ne marche pas, mon buffer reste vide après ces instructions.

Il y a certaines fonctionnalités que je ne trouve pas alors

Tu peux donner des exemples ? car à part l'introspection, j'ai du mal a voir ce qu'il manque par rapport au java (au niveau des capacités du langage)

Moi ce qui me manque quand je change de langage (généralement java), c'est la non maitrise des const, impossibilité de choisir entre valeur/référence/pointeur, impossible de redéfinir les opérateurs (simplification d'interface), les template…

Quand je parlais des fonctionnalités que je ne trouve pas (ou pas facilement), je pensais à la STL, pas au langage même. Je ne cherche pas à faire de comparaison sur les langages, ils sont différents par définition, mais j'attends pour chacun des langages d'avoir une bibliothèque de base suffisamment fournie et pratique à utiliser.

Pour en revenir à un exemple, je cherchais l'autre jour à lire un fichier binaire dans un vector<int>.
Le code suivant fonctionne pour un vector<char>, mais pas pour vector<int> :

std::ifstream file(filename, std::ios::binary);

std::vector<char> buffer(std::istreambuf_iterator<char>(file), {}); // Ok, mais on lit des char...

std::vector<int> bufferInt(std::istreambuf_iterator<int>(file), {}); // Ne compile pas

Ça m'a un peu étonné de ne pas pouvoir faire ça, pour un langage pourtant si puissant en terme de templates.

Je pense qu’il ne parle pas du code en soit, mais du contenu de la popup de doc qui est pas franchement user-friendly en effet.

Tout à fait. Dans cette popup, je m'attendais plus à y voir une description textuelle accompagnant la signature de fonction, d'autant qu'elle existe.

Peut-être est-ce uniquement un problème d'Eclipse (je n'ai pas testé tous les IDE) mais j'espérais qu'une version moderne d'Eclipse soit plus avancée que ça en C++. C'est quand même un gros IDE, et ils ont l'air de mettre le support de C++ pas mal en avant (juste après Java).

On va peut-être encore me dire que je suis trop faible en C++ mais lorsque je vais dans la définition du constructeur en question (le même code qu'on voit dans le popup), puis que je fait un ctrl+clic sur la fonction _M_initialize_dispatch pour continuer de naviguer à l'intérieur de la STL, Eclipse m'ouvre une boite de dialogue me demandant de choisir quelle déclaration je veux visiter parmi 4 signatures possibles. Ça commence à se compliquer pour savoir exactement ce qui se passe, puisque c'est au développeur de déterminer le chemin que va prendre le code… (l'IDE semble avoir déjà perdu le fil)

Une autre question que je me pose : pourquoi tous ces underscores « _ » (voire double « __ ») partout dans la STL, jusque dans les noms des arguments des fonctions qui sont présentés publiquement ? (__first, __last, __a). Ça fait assez ésotérique et brouille un peu la lisibilité.

Sommaire

• • Java
  • Ada
  • C++
  • Conclusion

Étant développeur Ada depuis plus de 10 ans, je ne trouve pas qu'Ada soit si « extrême » que ça, ni difficile, mais c'est peut-être une déformation professionnelle de ma part… Je ne me considère pas guru en Ada.

Il y a le côté fortement typé du langage : au début, quand on vient du C/C++ ou Java, c'est nouveau et ça peut paraître plus difficile, mais rapidement on s'aperçoit que ça fait gagner du temps, car on peut borner beaucoup plus facilement le code à des plages de valeurs restreintes à son besoin, et empêcher de manipuler les variables n'importe comment. En C/C++ ou Java, t'es obligé de tester que ton argument d'entrée "int", "float" ou autre primitive, est correctement borné par rapport à ton attente. Parfois tu ne le fais pas, en te disant que ça a déjà été vérifié plus en amont dans le code, mais parfois tu te loupes (ou parce que soudain ta fonction est appelée d'ailleurs, sans vérification). En Ada, pas de soucis à se faire là-dessus. En fait, le code critique sera celui de la conversion de ta donnée d'entrée en donnée typée (c'est là que tu dois gérer les cas d'erreur possibles), mais il sera alors bien localisé, là où dans d'autres langages ça peut être plus flou (ou plus expéditif… avec son lot de bugs). Aujourd'hui, quand je manipule des variables de type primitives en C/C++/Java, j'ai vraiment l'impression de travailler sans filet de sécurité.

Mon point de vue maintenant sur les temps de développement, à partir de mon expérience perso. Je dirais que chaque langage a ses points forts (où l'on gagne du temps) et ses points faibles (où l'on perd du temps) et j'aurais bien du mal à les classer par ordre d'une manière générale.

Java

• Le côté dynamique de Java permet de démarrer le codage très rapidement. Écrire et exécuter un test unitaire dans Eclipse est extrêmement facile et rapide, et c'est très agréable. Tester la couverture de code sans son IDE également. La compilation est également rapide, les messages d'erreur suffisamment clairs pour comprendre ce qui ne va pas. Les conventions de nommage (voire de codage) fortement imposées permettent d'écarter les questions de base philosophiques qui font perdre du temps pour rien. Bref tu lance ton IDE, Nouveau Projet, et c'est parti !

• Le runtime Java est plutôt bien fourni, ça aide à coder rapidement également.

• Beaucoup de bibliothèques existantes, mais parfois en terme de dépendances, on a l'impression de tirer la mer et les poissons. Quand on travail sur des systèmes critiques où il faut maîtriser toutes les dépendances, il faut parfois apprendre à s'en passer (pareil pour les potentielles galères de licences).

• Là où ça se gâte à mon sens, c'est sur la partie packaging/déploiement, qui quand elle tourne mal, peut faire perdre pas mal de temps qu'on avait gagné en codage (et en général c'est pour des conneries). Certains outils sont censés simplifier ça en imposant une certaine structure (genre maven), mais d'une part je ne trouve pas la syntaxe de ces outils très fluide à manipuler, d'autre part, je suis souvent bloqué par un firewall très filtrant et je dois donc m'organiser comme si j'étais offline 100% du temps. Et là, ça coûte en temps pour la mise en place d'un environnement maven/nexus, l'import des dépendances (qui est devenu galère dans nexus 3), etc. Sur un gros projet, ces coûts pourront s'absorber, mais sur des petits programmes, ça peut parfois coûter plus que le temps de codage.

• Autre point ennuyant, c'est pour faire un simple programme, là où en C, C++ ou Ada tu obtiens un binaire prêt à l'emploi, avec Java t'as un ou plusieurs jar, qu'il faut lier en général avec un script de lancement, tout en s'assurant d'avoir le bon JRE, le bon environnement, etc., bref un peu pénible à gérer.

Ada

• En Ada, le côté verbeux rend forcément l'écriture de code plus lente (c'est tout de même atténué grâce à la complétion auto de l'IDE). Mais en même temps, c'est bien rare que j'arrive, dans n'importe quel langage, à écrire une fonction d'une traite de bout en bout sans me poser et réfléchir entre deux lignes.

• La séparation entre spec (header) et body (source) prends également du temps. Elle permet toutefois de bien séparer le contrat de l'implémentation (pratique pour faire du logiciel propriétaire ;-)). En Java, il n'y a que le code, et le côté dynamique du langage permet d'en extraire les signatures de classes facilement, reste la javadoc, qu'il faut fournir « à côté », là où en Ada on peut se contenter de lire les commentaires présents dans le fichier spec. En C++, c'est la fête du slip.

• La structure d'un programme Ada, en packages, présente les mêmes avantages que Java en terme d'organisation de code, et les packages s'importent simplement comme en Java, dans l'ordre qu'on veut. Le temps de compilation est généralement assez rapide (sauf cas particuliers), un peu comme en C je dirais, mais plus lent que Java.

• Le runtime Ada s'est pas mal étoffé ces dernières années, et propose pas mal de choses.

• Il n'existe pas beaucoup de bibliothèques en Ada, mais on peu faire des bindings avec les bibliothèques C assez efficacement (ça prend un peu de temps de développement).

• Côté outils, Ada étant un langage de niche, il n'y en a pas 36, du coup on perds pas beaucoup de temps à choisir ;), mais on trouve généralement ce qu'il faut.
  L'IDE, GNAT Programming Studio (GPS), commence à être vraiment pas mal.

• Enfin, concernant la fabrication, là c'est c'est vraiment excellent. La description des projets dans des fichiers « .gpr » surpasse de loin tout ce que j'ai vu (Makefile, CMake & co) en terme de clarté, simplicité, rapidité à écrire et maintenir, réutilisation par divers outils (compilateur, IDE, analyseurs, …). En plus, ça marche aussi pour d'autres langages comme C et C++ (ou pour mixer plusieurs langages).

C++

Bon là je vais être méchant, et ça me rend bien triste. J'ai commencé la programmation avec C++, et j'étais fan de ce langage, mais je n'en ai pas fait beaucoup durant cette décennie. De temps en temps, j'essaie d'en refaire un peu histoire de pas trop perdre la main.

Quand aujourd'hui je compare le C++ à Java ou Ada, je trouve que :

• C'est un langage syntaxiquement compliqué. La STL me paraît également compliquée, et limitée. Il y a certaines fonctionnalités que je ne trouve pas alors que je les aurait facilement trouvées en Java ou Ada, ou alors elles existent mais sous une autre forme, propre au C++, mais donc je perds du temps à essayer de les trouver (je suis peut-être trop formaté Ada/Java). Aussi, peut-être je n'utilise pas les bons outils, mais voici un exemple de ce que me propose Eclipse lorsque je place le curseur sur ma variable de style vector:

Ça m'est totalement obscur. Voir ça en 2019 m'a fortement déçu sur l'évolution de C++ et de son écosystème. Et le bout de code en exemple, je l'ai trouvé sur le net. Tout seul je n'aurais pas su l'écrire, et d'ailleurs j'ai encore du mal comprendre comment il fonctionne (!), ce qui m'inquiète beaucoup.

Aussi je perds pas mal de temps à comprendre certains messages d'erreur de gcc (quand c'est pas de la bouillie templatique).

• D'un point de vue organisation du code, à cause du mécanisme archaïque des includes, c'est bordélique. Il faut les mettre dans le bon ordre sinon ça pète. Un truc comme ça en 2019 c'est vraiment difficile à supporter.
  La séparation déclaration/implémentation entre header et source n'est jamais claire, puisqu'on trouve du code dans les headers, partiellement ou complètement. Et honnêtement, je passe (perds) souvent du temps à me demander comment je vais organiser mon code, est-ce que telle fonction je la définis dans le header ou pas, etc.
  D'autre part, je me retrouve à inclure des headers de plusieurs dizaines de milliers de ligne de code (genre vulkan.hpp) dans mes fichiers sources, et je le sens bien en temps de compilation, on se retrouve alors bien plus lent que Ada ou Java.

• Concernant la fabrication, c'est pas encore la panacée à ce que je vois (Make, CMake, etc., communauté encore très fragmentée sur cette question), là où en Ada c'est très clair et simple, pourtant ce sont deux langages proches en terme de fabrication. Donc un peu de perte de temps à ce niveau. Point « positif » : à la fin, on a un binaire comme en Ada, donc de ce point de vue c'est plus simple à lancer hors d'un IDE qu'un programme Java.

Conclusion

Java: Hors écriture de code, Java dans l'IDE, c'est rapide, mais en dehors de l'IDE, c'est plus long.

Ada: Un peu plus long à écrire pour la verbosité, mais temps récupéré sur la qualité du code et des outils de développement. Développer en Ada ne coûte globalement pas plus cher qu'en C, C++ ni même Java à mon sens.

C++: Personnellement je perds du temps en C++ à me demander comment organiser mon code, à comprendre du code obscure, à trouver ce que je veux dans la STL, à trouver qu'est ce qui est censé être la bonne façon de faire telle ou telle chose en C++… mais l'utilisation des bibliothèques en C/C++ est facile (gain de temps ici). Je me pose vraiment des questions sur l'intérêt de C++ quand je vois ce qu'il est devenu (ou ce qu'il est resté).

Je n'ai pas encore testé Rust, mais à première vue, sa syntaxe tendance minimaliste n'est pas trop mon truc (je préfère plus de verbosité).

Sur les modules, pareil, je pense qu'ils ont fait de la merde et qu'au final, tous les bénéfices attendues auront disparu tellement le résultat est complexe parce que tout le monde y a mis son grain de sel.

triste pour les modules ;_;

Pourrais-tu développer un peu sur ce sujet ? qu'ont-ils fait pour saccager le concept ? C'est vraiment le truc que j'attends le plus, j'en ai marre de parser des headers de plusieurs dizaines de milliers de lignes de code pour chaque fichier source du projet…

d'ailleurs c'est toujours pas tranché, même si Vi gagne haut la main …

T'as dû rater un wagon, car tout le monde est maintenant d'accord pour que ce soit Emacs.

/o\ -->[]

Je n'ai désormais plus peur de me manger des rafales de moinssage voir des qualificatifs frolants le point goldwin.

Le point goldwin, c'est en rapport avec les journaux sur les motards ?

tu veux parler des utilisatrices et des utilisateurs, tu l'écris, voila tout

Exactement, ça aussi c’est de l'écriture inclusive. Mais parfois, ça allonge les phrases inutilement ou on est obligé de passer par des répétitions moches donc c’est pratique de passer par des acronymes.

Utiliser la forme longue permet d'insister sur l'inclusion des deux genres, et à mon avis il n'est à utiliser que lorsqu'il peut y avoir ambiguïté (contexte insuffisant). Sinon, la forme neutre suffit (pour justement éviter les lourdeurs).

La forme neutre ici c'est : « des utilisateurs ». Il se trouve que la forme masculine utilise la même forme que le neutre, mais qui va penser en le lisant que ça concerne uniquement des hommes ?

Dans le cadre de ce journal, il n'y a pas besoin d'insister sur l'inclusion : tout le monde comprends que ça concerne tout genre d'utilisateur (sans distinction ni quelconque hiérarchie). Donc utiliser la forme longue comme les formes raccourcies n'apporte rien au fond mais génèrent de la lourdeur dans la forme.

Donc si j'écris en charabia et que tu ne me comprends pas (tout comme les autres lecteurs à qui je m'adresserais), tu considéreras que le problème de communication est côté récepteur ?

c'est un peu dommage de bloquer là dessus

Tout à fait. Mais on ne peut pas mettre la faute sur le dos du lecteur (ou duela lecteurice ?).

Est-ce si difficile à lire ?

Oui, car il n'y a pas de transmission possible à l'orale. Quand je lis, je m'entends lire à haute voix dans ma tête (ou j'entends la voix de la personne qui écrit plutôt). Donc quand je tombe sur « utilisat·eur·rice·s », et bien :

1) Ma lecture est soudainement interrompue par un signe de ponctuation (le point médian ·) qui ressemble fortement à une fin de phrase, donc ça a tendance à me couper dans mon élan de lecture.

2) Comment convertir ça à l'oral ? je finis par prononcer « utilisateurices », « lecteurices », « programmeurse » mais ces mots là n'existent pas, donc perturbent la fluidité de ma lecture. Et il ne s'agit pas de simple faute d'orthographe ou de faute de frappe, à cause du point médian qui est en plein dans le mot.

3) Ça sert à rien.

4) J'ai l'impression d'avoir à faire à un SJW qui veut m'imposer un mode de pensée auquel je n'adhère pas et ça ça m'énerve (même si l'auteur n'en est pas un). Ça me crée un préjugé personnel mais automatique qui va polluer ma lecture, car je vais devoir faire des efforts pour mettre ces préjugés de côté afin d'avoir une lecture plus impartiale.

Du coup, j'ai lu tout le journal mais je n'ai rien saisi de son sens, je vais devoir le relire encore… (je vais faire cet effort exceptionnellement car le sujet pourrait être intéressant, mais habituellement je passe).

Est-ce que tu as déjà eu a faire à eux, mon cher Nal ? As-tu des retours d'expérience positives ? (ou négatives ?). Les délais de livraison sont-ils raisonnable ? Le SAV à la hauteur (ce point plaiderait plutôt pour le revendeur local) ?

J'ai acheté un portable chez PCW il y a 3 ans. Délais : ~3 semaines. Je ne peux pas me prononcer sur le SAV, ne l'ayant pas contacté.

J'en suis plutôt satisfait, puisque j'ai pu me faire monter un portable sur mesure (ou presque - j'ai même eu le choix de la pâte thermique) à base de Clevo (P750DM-G), sans OS, assemblé en France, et avec des composants compatibles Linux (il n'y a que le Thunderbolt 3/USB type C que je n'ai pas pu expérimenter, faute de périphérique pour tester. Je ne sais même pas s'il est bien reconnu actuellement).

Ils proposent des scripts de post installation Linux, mais je n'ai jamais essayé. J'avais jeté un coup d’œil, et ça me semblait pas être nécessaire pour un non novice.

Pour les quelques fonctionnalités spécifiques Clevo (contrôle du rétro-éclairage du clavier, bouton RF-kill, et peut-être quelques autres trucs) j'ai utilisé le driver : https://bitbucket.org/tuxedocomputers/clevo-xsm-wmi/src/master/

Sur le web, j'ai pu trouver la doc de maintenance (http://www.e-weekly.co.uk/download/RnD/DRIVERS/CLEVO/P7x0DM/P75DM_ESM.pdf). Y'a carrément des schéma électroniques, ça m'a étonné, je pensais que ça se trouvait plus depuis les années 90 ce genre d'info.

Sur cette machine, j'ai 2 ports SATA et 2 ports M.2 (SATA ou PCIe) pour le stockage, mais c'est un 15". J'ai acheté la machine sans aucun disque, et j'ai mis mon propre SSD SATA. Le démontage est super simple, les choses facilement accessibles. J'ai 4 emplacement SO-DIMM et le CPU est un… core i7 6700K (c'est pas vraiment un processeur de portable :p), donc aucun soucis pour la virtualisation. Mais avec tout ça, il est lourd, un peu épais et la batterie c'est juste pour le temps de le déplacer d'une table à une autre, hein.

Quelqu'un avait pertinenté jusqu'à 43. J'ai du rectifier en inutilant ton journal, désolé.

Moi je discute avec mon boss sur IRC. Du coup, quand il passe en mode /away, je sais qu'il risque d'arriver sous peu à mon bureau, ce qui me laisse le temps de masquer les fenêtres IRC à la souris. Donc leur fork privateur de mes fesses, ils peuvent se le garder, j'en ai pas besoin !

J'avais bien vu ce nouveau journal DLFP dans mon agrégateur de flux RSS, mais je m'étais dit que je le lirai plus tard (véridique).

Qu'en est-il de la consommation électrique de cette cryptomonnaie ?
Et où se situe-t-elle vis à vis des autres cryptomonnaies sur ce plan ?

Flash ? Ça existe encore ce truc ?

Et pendant ce temps, chez Microsoft, on suggère à Mozilla d'abandonner le développement de son moteur de rendu pour Chromium :

Thought: It's time for @mozilla to get down from their philosophical ivory tower. The web is dominated by Chromium, if they really cared about the web they would be contributing instead of building a parallel universe that's used by less than 5%?

https://www.zdnet.com/article/microsoft-guy-mozilla-should-give-up-on-firefox-and-go-with-chromium-too/

À propos de oui.sncf, j'ai une anecdote à partager.

L'an dernier lorsque j'ai contacté le support, je suis passé par le formulaire en ligne. Formulaire super bien gaulé : dès que vous cliquer sur la toucher « Entrer » pour aller à la ligne, ça valide le formulaire ┗(ᐖ )┓

C'est ainsi que j'ai envoyé mon premier message :

Bonjour,

La réponse du support :

Bonjour Monsieur XXX,

Besoin d'informations ? Votre mail est vide.

Vous aviez une questions ? Besoin de conseils ? Dites-moi tout et je vous aiderai !

En attente de votre retour, je vous souhaite une bonne journée.

:-)

Je me demande s'ils ont corrigé leur site depuis…