Cher journal,
Je t'écris aujourd'hui pour partager un lien vers un article dont la lecture ouvre une véritable réflexion sur le développement informatique.
Je te donne tout de suite l'url ce qui devrait épargné de lire la suite de ce post:
https://blog.romainfallet.fr/desenchantement-logiciel/
L'article est une traduction par Romain Fallet d'un texte en anglais de Niki Tonsky.
http://tonsky.me/blog/disenchantment/
Sans vouloir résumer un article je pointe quelques éléments: Tout est lent, tout est énorme, tout devient obsolète et personne ne s'en préoccupe.
Cher journal qu'en penses-tu?
# Déjà publié
Posté par goernil . Évalué à -10.
https://linuxfr.org/users/nono/liens/software-disenchantment
[^] # Re: Déjà publié
Posté par cmal (site web personnel) . Évalué à 10.
C'était seulement la version originale, dans le journal bookmark que tu cites. Là c'est la traduction francophone, donc c'est pas bête pour les personnes qui ne sont pas anglophones :)
[^] # Re: Déjà publié
Posté par abriotde . Évalué à -10. Dernière modification le 03 octobre 2018 à 13:51.
J'espère que ça n'existe pas chez les informaticiens
Néanmoins ceux qui ont la flemme de lire la VO, ça ok.
[^] # Re: Déjà publié
Posté par gaaaaaAab . Évalué à 10. Dernière modification le 03 octobre 2018 à 13:56.
il n'y a pas que des informaticiens qui lisent linuxfr. Et les plus jeunes informaticiens ne sont pas forcément encore au point en anglais.
En passant, si on pousse ton commentaire à sa conclusion logique, linuxfr n'a aucune raison d'exister …
[^] # Re: Déjà publié
Posté par abriotde . Évalué à 1.
Si car je parle bien de ceux qui ont la flemme de lire l'anglais, j'ajouterai comme moi parfois.
[^] # Re: Déjà publié
Posté par voxdemonix . Évalué à 2. Dernière modification le 03 octobre 2018 à 14:07.
Je vais ptete t'apprendre un truc, mais aujourd'hui tu trouves :
- des distro traduites en plusieurs langues
- des logiciels traduis dans plusieurs langues
- des documentations/tutos traduites en plusieurs langues (même MAN !)
- des communautés pour chaque langues populaire
- Google translate qui fait des merveilles
:D
(je ne serais même pas étonné que les non anglophones soit plus nombreux, mandarin oblige)
[^] # Re: Déjà publié
Posté par CHP . Évalué à 0.
Tu oublies l'Inde. Ils sont presque aussi nombreux que les chinois, et ils parlent anglais.
[^] # Re: Déjà publié
Posté par 2PetitsVerres . Évalué à 10.
ça se discute.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Déjà publié
Posté par voxdemonix . Évalué à 9.
source : wikipedia
[^] # Re: Déjà publié
Posté par Okki (site web personnel, Mastodon) . Évalué à 5.
J'obtiens généralement de bien meilleurs résultats avec DeepL. Par contre, il ne traduit pas encore autant de langues de Google Translate :-/
[^] # Re: Déjà publié
Posté par abriotde . Évalué à 1.
Je ne vois pas le rapport. Évidemment qu'il y a des traduction car c'est beaucoup plus simple dans la langue maternelle et puis les distributions c'est aussi fait pour les grand-mère ou les enfants de 7 ans.
Mais LinuxFR est tout de même destiné à des français ayant un minimum de compétences en informatique sinon elle ne va pas comprendre grand chose ou même ne pas s'y intéressé du tout. En France l'anglais est obligatoire à partir de 11 ans et même les plus mauvais savent le lire ou demander a "Google Translate" de le traduire.
J'ai jamais dis que la traduction est inutile mais dis que l'argument de "les personnes qui ne sont pas anglophones" ne concerne pas les informaticiens.
[^] # Re: Déjà publié
Posté par Ytterbium . Évalué à 4.
Et puis surtout, tout le monde ne va pas consulter la section lien. Personnellement, je ne l'avais pas vu, donc j'apprécie de pouvoir le trouver dans un journal.
# Ce que j'en pense ....
Posté par totof2000 . Évalué à 10. Dernière modification le 03 octobre 2018 à 11:45.
D'abord sur le fond, je suis assez d'accord avec le texte originel. Dernièrement, je me disais que la batterie de mon ordinateur portable se déchargeait bien vite. En regardant l'applet qui monitore les ressources systèmes, je me suis apperçu que le CPU était pas mal sollicité … et je me suis rendu compte en regardant les process qui tournaient, qu'un ibus prenait plus de 100% de CPU … :(
Je me suis demandé si je rêvais (d'autant plus qu'ibus m'a pris la tête sur mon fixe sous freebsd - il passe son temps
à ignorer le fait que j'utilise un clavier fr, du coup je l'ai désactivé). Sur mon portable, j'ai juste eu à tuer ibus et redémarrer les applications qui semblaient l'utiliser (la saisie clavier ne marchait plus sur l'une d'elles), et l'occupation CPU est redevenue plus raisonnable. Bilan : je me trouve sur ma machine avec un truc qui a priori ** ne sert a rien ** et prend plus de 100% CPU. Ce que je redoute, c'est que ce truc inutile devienne incontournable a l'avenir, et fasse perdre encore de l'autonomie à ma batterie.
Ici je parle d'ibus parce que c'est un truc qui m'est arrivé il y a peu, mais j'ai déjà bien ralé dans le passé parce que des gens ont voulu remplacer un truc qui marchait plutôt bien, qui avait mis du temps à être débuggé, par un truc pas fini qui vient pourrir la vie des utilisateurs (exemple : systemd), ou des trucs pas finis qui viennenet également pourrir la vie des gens (exemple : pulseaudio). J'ai constaté le même phénomène avec hplip: un processus python qui vient à utiliser de grosses quantités de CPU pour rien (au passage, je pense que pour développer ce genre de truc en python, faut être malade, ou avoir envie de décharger les batteries des portables des utilisateurs).
Celà dit, je pense qu'on arrive à la fin d'un cycle et que ces pratiques vont commencer à s'atténuer (si ce n'est disparaître - au moins pour quelques temps). En effet, le coût de la mémoire RAM a pas mal augmenté ces derniers temps, et le cout des processeurs Intel également: j'ai l'impression que l'ère du matériel pas cher est en train de se terminer, et qu'on va voir celui-ci augmenter considérablement dans les années à venir (sans compter le cout de l'énergie qui à mon avis risque d'augmenter fortement). Du coup les développeurs devront réapprendre à optimiser leurs programmes pour qu'ils puissent tourner sur des confs hardware moins gourmandes, et utilisent moins d'énergie pour fonctionner. Alors certes, les restrictions hardwares ne seront probablement pas aussi fortes que dans les débuts de l'informatique, mais je suis d'avis qu'on ne pourra plus faire comme aujourd'hui : considérer qu'optimiser le soft coute plus cher que d'ajouter des capacités hardware.
[^] # Re: Ce que j'en pense ....
Posté par Le Pnume . Évalué à 4.
Sauriez vous me dire pourquoi mon Prumpleffer tout neuf vient d'exploser à la lecture de ce message ?
[^] # Re: Ce que j'en pense ....
Posté par Nodeus . Évalué à 1.
c'est quoi un Prumpleffer?
[^] # Re: Ce que j'en pense ....
Posté par Le Pnume . Évalué à 2.
http://la.buvette.org/tech/reseau/prumpleffer-2.html
[^] # Re: Ce que j'en pense ....
Posté par Nodeus . Évalué à 1.
C'est un vaporware :P
[^] # Re: Ce que j'en pense ....
Posté par modr123 . Évalué à 4.
parce que c'est une contrefaçon
[^] # Re: Ce que j'en pense ....
Posté par MTux . Évalué à 10.
aïe… j'allais plussoyer ton commentaire jusqu'à ce que je lise ça.
Tu as un exemple concret ou c'est juste du FUD ? Pour avoir codé des init et services systemd, le second te fait gagner un temps fou. Je dirais même que Systemd me manque sur FreeBSD.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . Évalué à -1. Dernière modification le 03 octobre 2018 à 16:45.
Bah, voilà le genre de plaisanteries que peut faire systemd. Et j'en ai eu d'autres.
Ben moi il m'en fait perdre bien trop.
Au passage, j'aimerais bien comprendre en quoi systemd te manque sous freebsd.
[^] # Re: Ce que j'en pense ....
Posté par MTux . Évalué à 10.
Le bug que tu cites est lié à Fedora 26, une distribution expérimentale par nature, c'est un peu particulier.
L'exemple que je prends souvent pour défendre Systemd, c'est ça:
Tu as le script init de Nginx, et la version systemd. La seconde est beaucoup plus courte et surtout plus lisible humainement.
On trouve souvent sur FreeBSD des ports qui n'ont pas de script d'init, et quand il faut les écrire c'est vraiment très long alors qu'avec systemd cela aurait été fait en quelques minutes.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . Évalué à 0.
Ben j'ai rencontré le même type de problème sur une redhat qui n'a rien d'expérimental. Je t'accorde que ce genre de bug a tendance à se faire un peu plus rare, mais ça arrive encore que systemd se vautre lamentablement dans certains cas. La ou ça me gène, c'est surtout qu'avant systemd, un bug sur le système d'init pouvait être facilement corrigé sans attendre de mise à jour d'OS (c'est du script), là ou aujourd'hui, il faut attendre le bon vouloir de RedHat pour corriger.
Je viens d'aller voir l'exemple que tu as donné, et je me pose une question : pourquoi le script init de redhat crée-t-il son user à cet endroit précis ? Et pourquoi la création de répertoire doit-elle se faire au démarrage ? côté systemd, ça se fait ou et à quel moment ? (je suis pas un expert nginx donc je ne sais pas trop pourquoi il a besoin de faire ce genre de truc)
Bah, quand il s'agit de faire un bete start/stop, ça prend pas beaucoup plus de temps (je l'ai déjà fait pas mal de fois). Et quand il s'agit de custommiser, systemd est bien chiant :j'ai passé pas mal de temps l'an dernier à faire une pauvre unit pour démarrer un apache compilé maison, auquel je devais faire passer certaines variables d'environnement (j'ai plus les détails en tête, mais si j'avais du faire ça en init classique, ça m'aurait pris bien moins de temps).
[^] # Re: Ce que j'en pense ....
Posté par Psychofox (Mastodon) . Évalué à 6.
À la lecture du fichier init tu comprends aisément que tu peux choisir le nom du user qui fera tourner nginx dans le fichier de conf /etc/sysconfig/nginx. Du coup à chaque changement de config et restart du serveur il n'est pas totalement idiot de s'assurer que l'utilisateur existe. Personnellement je trouve ça un peu redondant puisqu'on peut choisir le user dans nginx.conf et j'estime qu'à partir du moment où on utilise un utilisateur qui n'est pas celui par défaut et créé à l'installation du paquet c'est à l'utilisateur de s'assurer que les prérequis soient là, soit à la main, soit via son gestionnaire de config favori (ansible, puppet, salt, chef,…).
Par contre le service systemd présenté dans la même réponse ne propose ce niveau de configuration donc on n'est pas tout à fait en face de deux trucs qui font exactement la même chose.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . Évalué à 3. Dernière modification le 04 octobre 2018 à 15:15.
Merci, tu confirmes bien ce que j'en avais compris.
[^] # Re: Ce que j'en pense ....
Posté par Alex G. . Évalué à 7.
Pareil. Je trouve que systemd c'est justement une personne qui a voulu ré-écrire une partie du système justement où on accumulait du code dans tous les sens pour un service pas si fiable (les scripts de /etc/init.d était quand même vraiment lourd et lents pour la plupart, sans quasiment aucune unification).
Après je dis pas que c'est parfait ou que ça doit plaire à tout le monde.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . Évalué à 2.
La lourdeur et la lenteur ne sont pas forcément les points les plus importants. Je ne dis pas qu'il fallait garder les scripts d'inits comme ils étaient, par contre la façon de faire de systemd n'est pas non plus la bonne façon de faire.
Les scripts d'init avaient pour gros avantage d'être modifiables et personnalisables à l'envie, de ne pas enfermer les admins dans un moule rigide (ou t'es obligé de te tordre le cerveau dès que tu n'es pas dans un cas prévu), et de pouvoir corriger les bugs du système de démarrage sans avoir à recompiler et attendre une livraison de nouvelle version.
Le fait que les scripts soient des scripts permettait en outre si on le voulait d'étudier facilement ce qu'ils faisaient en les modifiants, sans avoir à passer par des phases de compilation assez lourdes (bien entendu, je parle de faire ça dans un environnement de test, pas sur de la prod …).
A contrario, systemd est un truc plutôt "boite noire" qui peut effectivement permettre de gagner du temps lorsque l'on rentre dans le moule (90% des cas), mais qui fait perdre bien plus de temps pour gérer les 10% de cas non prévus par le bouzin (et manque de bol pour moi, c mon job de gérer ces cas de figure).
Je ne nie pas que systemd apporte un certain nombre d'avantages (par exemple la possibilité de monitorer un process et de le relancer s'il se vautre tout seul), mais il apporte un gros lot d'inconvénients, notamment une perte de souplesse par rapport à init ou upstart.
[^] # Re: Ce que j'en pense ....
Posté par MTux . Évalué à 5.
Avec init t'étais surtout obligé de maintenir des scripts pour chaque distribution.
En tant qu'admin je préfère que les services se plient à ce que systemd permet de faire, je n'aime pas quand chacun veut faire sa sauce et fonctionner comme il lui plait.
Rien qu'avoir tous les logs dans /var/log/messages par défaut c'est une avancée (n'est-ce pas Java…)
[^] # Re: Ce que j'en pense ....
Posté par gaaaaaAab . Évalué à 2.
Ma question va sembler polémique, mais ce n'est pas le but. C'est juste que ce que je comprends m'étonne. Est-ce que permettre à chacun de faire ce qui lui plaît n'est pas l'essence du logiciel libre ?
[^] # Re: Ce que j'en pense ....
Posté par MTux . Évalué à 4.
Ben c'est mon point de vue de sysadmin, je préfère quand le fonctionnement est unifié.
[^] # Re: Ce que j'en pense ....
Posté par gaaaaaAab . Évalué à 5.
ouais, ok, je n'avais pas correctement interprété le périmètre de "En tant que sysadmin" dans ton commentaire.
Je comprends qu'un sysadmin veuille un réseau plutôt homogène. Mais devoir administrer plusieurs distributions va à l'encontre de ce souhait d'homogénéité. La volonté de fonctionnement unifié pousserait plutôt vers l'utilisation d'une seule distrib, et dans ce cas, le système d'init n'a pas vraiment d'importance en terme d'homogénéité.
[^] # Re: Ce que j'en pense ....
Posté par MrBidon . Évalué à 1.
Ajoute netplan a la liste (a moins que ce soit une nouveauté uniquement ubuntuesque).
# bof
Posté par CrEv (site web personnel) . Évalué à 10.
Que si ce n'étais pas totalement exagéré au ridicule ça pourrait être intéressant, mais là…
On parle bien d'un clavier qui gère plusieurs agencements, de la prédiction de mots, le fait de pouvoir écrire des mots en reliant des lettres par un trait continu au doigt (désolé je sais pas si ça a un nom cette fonctionnalité) et probablement pas mal d'autres choses comme l'affichage portrait, paysage, en plusieurs résolution, plusieurs modes d'affichage (je peux l'avoir en pleine largeur ou plus petit à gauche ou à droite pour un usage à une main), etc ?
Bref c'est assez représentatif de tout l'article, un biais et une exagération au ridicule qui dessert le problème et qui ne convaincra que les convaincus.
[^] # Re: bof
Posté par HL . Évalué à 10. Dernière modification le 03 octobre 2018 à 12:26.
Où passent les 150 Mo dans ces fonctionnalités ? (Vraie question)
La seule chose qui pourrait me sembler coûteuse est la prédiction (si elle est contextuelle aux mots déjà tapés, par exemple).
[^] # Re: bof
Posté par nico4nicolas . Évalué à 3.
Sans répondre à la question, je pense qu'une grande partie est du à la multiplicité des environnements. Pour reprendre l'exemple précédent avec Windows 95, combien d'architectures étaient supportés par l'OS ? Quels étaient les drivers inclus ? Combien de langues ? Et d'autres paramètres peut être plus importants que j'oublie.
Pour la question de l'éditeur de texte, il y a une logique à se baser sur ce qui a été fait pour ne pas réinventer la roue. Le "problème" décrié par l'auteur original de l'article est que les briques (ou bibliothèques) utilisées sont très lourdes pour l'application finale. Oui mais, très généralement, on n'utilise qu'une (petite) partie de ces bibliothèques sinon il faudrait avoir des briques très spécifiques et là, ça devient impossible de s'en sortir.
L'exemple de l'application graphique est assez parlant, la librairie graphique pour l'affichage de la fenêtre et des menus a pris beaucoup de poids parce qu'il y a de nombreuses options supplémentaires (qui ne seront peut être pas utilisées). Quelques éléments : les transitions graphiques, les différentes tailles d'écran, les différentes langues.
Je pense que la complexité dont l'auteur se plaint est inhérente à la diversité des environnements et c'est peut être encore plus vrai pour l'univers du web qui est montré du doigt dans cet article. S'il y a une solution pour être compatible avec la diversité tout en gardant un simplicité et une légèreté, je serai le premier à me jeter dessus.
[^] # Re: bof
Posté par barmic . Évalué à 5.
Je ne suis pas sûr que l'on ai un développeur Google dans le coin pour te répondre, mais le clavier de google (on parle de gboard, hein ?) fait :
Je ne sais pas comment son représentés toutes ces données en mémoire, mais il est certains qu'il vaut bien mieux précharger tout ça que de te laisser patienter à chaque fois que tu va utiliser une fonction qui n'était pas encore utilisée.
Au passage c'est calculé comment ces 150Mio ? Il prends de la place quand il en a ou il ne peux pas démarrer sans prendre 150Mio ? Les références faibles en Java sont vraiment simples à utiliser et faites pour ça.
Je pense qu'un réseau de neurones ne doit pas être trop lourd en mémoire éventuellement ça prend de la puissance de calcul, mais là on parle de mémoire.
[^] # Re: bof
Posté par totof2000 . Évalué à 8.
On a compris ou sont passé les 150 Mo … ;)
[^] # Ne prend pas 150 Mo
Posté par millman . Évalué à 2.
Chez moi le clavier de Google n'a jamais consommé plus de 21 Mio de mémoire.
Du coup je ne sais pas trop d'où sort ses 150 Mo.
[^] # Re: Ne prend pas 150 Mo
Posté par Yannick (site web personnel) . Évalué à 2. Dernière modification le 03 octobre 2018 à 18:14.
Je pense qu'il y a confusion entre place sur le disque et empreinte en RAM. Il me semble que l'article parle de l'espace occupé sur le disque.
[^] # Re: Ne prend pas 150 Mo
Posté par littlebreizhman . Évalué à 3. Dernière modification le 03 octobre 2018 à 19:31.
chez moi : op6 android pie
Stockage interne : 431 Mo
Mémoire : 101 Mo au courts des 3 dernières heures
[^] # Re: Ne prend pas 150 Mo
Posté par Julien Humbert . Évalué à 2.
C'est peut-être un peu mieux de donner les détails. On voit clairement que le cache (stickers, gif, etc.) prend la majorité de la place.
Sur mon OnePlus 6, Android Pie, j'ai :
[^] # Re: Ne prend pas 150 Mo
Posté par littlebreizhman . Évalué à 3.
Effectivement, la majorité vient du cache et des données utilisateurs.
Détails en version 7.6.11.2147…
La taille de l'appli étant quand même ~15 Mo (+20%) plus volumineuse pour le même téléphone, même OS
Comme ton screenshot montrait une version (7.6.13.2155…) plus à jour, je viens de la récupérer aussi et après installation :
Y'a donc du progrès (quoiqu'il faudrait faire le calcul à chaque maj pour voir dans quel sens ça évolue, je suppose que parfois la taille augmente).
Mais comme quoi il y a de la place pour de l'optimisation et les développeurs semblent le faire.
[^] # Re: bof
Posté par voxdemonix . Évalué à 9.
Quand tu compares webdav (pourris) et sshfs (just work), ça donne envie de pleurer.
Les nanopc (et smartphone) ont aussi tendance a bien lagger alors qu'ils sont bien plus puissant que les pc d'il y a 20 ans (mais l'archi arm entre en jeu).
Celui de microsoft à l'air de faire pareil (espionnage/keylogger compris) pour seulement 10Mo.
[^] # Re: bof
Posté par Clément David (site web personnel) . Évalué à 3.
Sans doute qu'il ne doit y avoir que l'interface graphique dans ces 10Mo ; le reste est dans un démon au démarrage de la machine voir directement dans l'OS.
[^] # Re: bof
Posté par groumly . Évalué à 10.
Clairement.
Il a l'air de complement ignorer le fait que le software en fait exponentiellement plus a chaque release/amelioration du hard.
Alors, ouais, windows 95 était plus petit qu'une page web, mais il était aussi plutôt basique niveau fonctionalités, crashait a droite a gauche, fallait configurer les irq et dma pour sa carte son a la main (en fait non, mais justement, les mecs qui venaient du dos se plaignaient qu'il fallait un cd-rom entier pour win 95, vous vous rendez compte).
C'est très facile d'oublier a quel point le software d'il ya 10 ans était primitif. Et ya 10 ans, on avait la meme discussion, et on avait oublie a quel point le software d'il ya 20 ans est primitif.
Perso, je bosse dans les applis mobile. En 6 ans, le code de mon appli a grossi grosso modo 5 ou 6x. On a aussi streamline beaucoup de choses (erreurs de jeunesse), ce qui veut dire qu'en pratique, le code est bien 10x plus gros que la version streamlinée d'il ya 6 ans.
On en fait beaucoup plus pour nos utilisateurs. L'appli est vachement plus finie. Des petites touches qui ont l'air de pas grand chose mais simplifient énormément la vie des gens finissent par prendre énormément de code (J'en ai une en tête qui a l'air de rien, se manifeste par juste une petite popup qui prend presque autant de code que la feature qu'elle complemente et nous a prit 1 mois a ecrire).
On en fait beaucoup plus pour nous. On a corrige des bugs. plein. Ca finit par faire plein de cas si ceci ou cela, des refactoring. On se rend compte que le problème est beaucoup plus complexe qu'on le pensait, et forcement, on en fait plus.
On a de l'ab testing de partout. Absolument tout est ab teste. Ca veut dire 2 fois plus de code pour chaque changement (control + variante).
On a de l'analytics de partout (produit, pas marketing). Ca rend notre vie vachement plus simple: on peut decider beaucoup plus vite de si une feature marche, on a un contrôle beaucoup plus find sur le rollout des features, on a plus de visibilité sur ce que les gens font vraiment, ce qui aide énormément a decider la direction a donner au produit.
Tout est plus gros, et consomme plus de resources. Mais tout fait aussi beaucoup plus de choses. c'est aussi con que de dire "ma Clio fait 2 fois le poids de ma deuch, l'industrie auto deconne a plein tubes".
Et ta deuch, pour te rafraichir l'été, fallait ouvrir la fenêtre et accélérer pour faire du vent. Quand t'avais un accident, tu crevais dans un tas de ferraille. Ca a prit 50 ans a l'industrie automobile pour optimizer ces problèmes, sur un produit qui a un scope très précis et limite.
Tu peux pas comparer ca a quelque chose comme du soft pur dont le scope n'est limite que par l'imagination.
Le problème qu'il a est avec la philosophie "un produit évolue constamment et très rapidement sinon il est mort". Je veux pas dire, mais ca fait un bail que ce débat est réglé. Ceux qui pense que les evolutions doivent être lente ne sont plus la pour en parler.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: bof
Posté par beleys (site web personnel) . Évalué à 10.
Oui, mais pas que …
Pour être dans le développement d'application depuis une 10aine d'année, je plussoie ce type de post. La perte de qualité dans le développement est effroyable.
Nous devons sortir de plus en plus vite des nouvelles fonctionnalités et sans jamais prendre le temps d'optimiser nos travaux.
Les ORM sont des révolutions d'un point de vue développement … mais un gouffre s'ils sont mal gérés. Remonter l'ensemble d'une base pour faire un "count" ne choque plus un développeur lambda …
De la même manière, demander le résultat d'une requête avant d'appliquer les filtres sur les données n'est pas problématique.
Les tests de montée en charge ne sont jamais fait (enfin, j'en ai jamais vu) … et on se retrouve avec des applications qui font tomber des VM car elles ont 15 utilisateurs en parallèle.
Avez vous déjà regarder la configuration minimum d'un serveur Sharepoint ? qui servira au final à faire tourner un Intranet plus ou moins statique dans 80 % des cas …
Alors oui, tout n'est pas à jeter, mais, la marge d'optimisation des applications est juste énorme .. simplement en appliquant les règles de base.
Aujourd'hui cela coûte moins cher de faire faire un développement au rabais, dans un temps contraint que de concevoir un produit performant dès le départ … et si le client gueule sur les perfs, on ajoutera un index sur la base ….
[^] # Re: bof
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
Tu as raison de contre-balancer les arguments de l'article, mais comme toujours, je pense que la vérité de se trouve à mi-chemin.
Si on prend les faits et rien que les faits, un utilisateur qui souhaite recevoir et envoyer des mails n'a pas des besoins beaucoup plus raffinés qu'il y a 10 ou 15 ans, et pourtant, même ce genre d'appli (pas toutes bien sûr) prend désormais un temps fou rien qu'à se lancer. Moi je veux juste écrire mon fucking mail, quoi, pas charger des Mo de javascript.
Je pense que l'informatique est un domaine où on tolère beaucoup plus que dans d'autres (aéronautique, mécanique) l'exploitation insensée de ressources, et du coup, tout le monde s'en fout, puisque de toute façon "l'appli tourne" et "n'est pas critique".
De plus, en lisant ton message, j'ai l'impression que tu nous dépeins la situation chez toi au niveau de l'ingénierie logicielle qui semble assez saine, mais je ne sais pas ce qui te conduit à généraliser.
Tout cela n'est pas sain, pas sain du tout, surtout qu'on ne se dirige pas vers un monde où l'énergie sera de plus en plus disponible.
[^] # Re: bof
Posté par BAKfr . Évalué à 6.
Sauf que de nos jours, les mails viennent avec le chiffrement, la mise en forme en fil de discussions, l'autocomplétion des adresses mails, les actions groupées, le drag&drop, un support du HTML beaucoup plus complexe, et des tonnes de détails qu'on remarque très peu, comme la demande de confirmation à la détection des mots "ci-joint" quand tu n'a pas mis de pièce jointe.
C'est vrai que la ratio performance/fonctionnalité a certainement baissé, mais même les clients mails font plus aujourd'hui qu'il y a 15 ans.
[^] # Re: bof
Posté par voxdemonix . Évalué à 2. Dernière modification le 04 octobre 2018 à 12:04.
Si tu sais comment désactiver cette horreur, tu fera un heureux :)
[^] # Re: bof
Posté par lolop (site web personnel) . Évalué à 8.
Sous Thunderbird, Menu Préférences → Section Rédaction → Onglet Général → Option Vérification des pièces jointes manquantes
De rien.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: bof
Posté par voxdemonix . Évalué à 3.
Nice, just work !
Merci ;)
[^] # Re: bof
Posté par harlock974 . Évalué à 1. Dernière modification le 06 octobre 2018 à 06:22.
Merci aussi !
[^] # Re: bof
Posté par gUI (Mastodon) . Évalué à 9.
Pas dans tous les domaines de l'informatique : dans l'embarqué, ça reste encore raisonnable, parce que les coûts sont regardés de très près.
En ce moment par exemple je bosse sur un ADAS (aide à la conduite) pour un constructeur automobile (voiture à sortir en 2019, autant dire qu'on est à la fin du dev).
- Adaptation de la vitesse au véhicule de devant (ça existe déjà chez ce constructeur)
- Suivi des lignes sur autoroute, la voiture est capable de légèrement tourner le volant (ça c'est nouveau).
Attention la bête de course pour gérer ça :
- Dual core 200MHz
- 2.5Mo de flash
- 384ko de RAM
C'est tout simplement codé en C, et peut-être un peu d'ASM pour le bootloader.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: bof
Posté par groumly . Évalué à 4.
Ca se discute. Autocompletion des noms dans l'email (genre de @mention que outlook fait, très pratique), gestion du carnet d'addrese, recherche avancée et instantanée, gestions des tags, gestions des fils, detections des mailings lists (e.g. le bandeau "this mail was sent from a mailing list, click here to unsuscribe" que Mail.app ajoute au dessus de certains mails pour éviter d'avoir a chercher le lien pour se desinscire). Ca c'est juste Mail.app ces 10 dernières annees, qui est franchement super light niveau features. Outlook en fait beaucoup beaucoup plus.
La gestion du spam devient de plus en plus raffinée (meme si elle est effectivement souvent faite cote serveur).
Je retourne la question a l'auteur, qu'est ce qui le conduit a généraliser comme il le fait?
Mon constat se base sur ce qui se fait dans mon industrie (a savoir, les moyens/gros du monde des applis mobile grand public). Je suis au premier rang de ce milieu, et je sais très bien ce que fait la concurrence (grosso modo la meme chose que nous, grosso modo en meme temps).
La performance n'est pas la priorité absolue, c'est sur. Mais on garde un oeil dessus (littéralement, on a des dashboards divers et varies pour le réseau et les perfs clients. On sait quand le business commence a souffrir a cause des perfs, et pour les optimizations, ben c'est un compromis temps passe/argent gagne, tout simplement). C'était pareil ya 10 ans (sauf qu'a l'époque, on mesurait vachement moins, alors on savait pas ou mettre le curseur niveau perf ¯_(ツ)_/¯).
Ya des points noirs, oui, clairement. Le web est probablement vraiment a la traine avec ses montagnes de JS de partout. Mais en fait non. Ces pages qui font dresser les cheveux sur la tete a être plus grosses que win95, quand tu regardes de plus près, la vaste majorité du temps, ca vient de boites dont le coeur de metier n'est pas la technologie.
Typiquement, les sites de news. Leur département technologie est généralement considéré comme un mal nécessaire (a l'inverse d'une boite genre airbnb ou l'ingénierie est au coeur de la boite). Ils ont pas le pouvoir de corriger ce genre de choses (ou n'arrivent pas a attirer les ingénieurs qui pourraient tirer la sonnette d'alarme).
Clairement tout n'est pas parfait, mais prétendre "tout est plus gros et plus lent, sans aucune raison, tout fout l'camp ma bonne dame, c'était mieux a vent", c'est un peu gros quand meme.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: bof
Posté par totof2000 . Évalué à 3.
Pour des applis sur mobiles, je m'attends à ce que l'appli ne fasse pas de trucs inutiles, pour ne pas bouffer ma batterie, donc la perf à mon avis n'est absolument pas à négliger : un CPU qui mouline inutilement à cause d'un algo peu performant bouffe de l'énergie.
[^] # Re: bof
Posté par barmic . Évalué à 2.
Tu entends quoi par performance ? Ne pas trop utilisé de CPU ou ne pas trop utilisé de RAM ? Tu préfère avoir une réactivité instantané ou ne pas faire de pré calcule potentiellement inutiles ? Il vaut mieux favoriser le débit ou la réactivité ? Est-ce que la performance doit se faire au détriment de la résilience (retry etc) ?
[^] # Re: bof
Posté par totof2000 . Évalué à 1. Dernière modification le 05 octobre 2018 à 17:59.
Ben si on veut économiser de l'énergie, on a plutôt intéret à ne pas trop faire mouliner le CPU, donc ça répond à au moins aux 2 premières questions. Perso, je préfère sacrifier un peu de réactivité à une surconsomation d'énergie sur un mobile.
[^] # Re: bof
Posté par barmic . Évalué à 2.
Voilà c'est personnel. Viens que ce n'est pas le besoin de tout le monde. Une grande partie des usages d'un smartphone n'ont tout simplement pas de sens si l'utilisateur attends trop.
Perso je n'ai jamais de problème de batterie (pas rarement, jamais) donc je vous pas pourquoi m'agacer continuellement pour un problème qui n'existe pas (en tout cas de mon point de vue).
[^] # Re: bof
Posté par totof2000 . Évalué à 3. Dernière modification le 06 octobre 2018 à 12:01.
Relis plus haut mon commentaire sur ibus qui prend plus de 100% de CPU et qui fait se décharger la batterie de mon ordinateur portable bien plus vite que la normale.
Alors certes sur un téléphone, c'est plus difficile à détecter, mais si les utilisateurs avaint moyen de voior que leur batterie ne tient pas la charge parce que ya un tas d'applis qui n'optimisent pas leurs algo et bouffent de l'énergie pour rien, je suis certain que le point de vu des développeurs changerait.
Juste pour info, j'ai éjà vu dans les commentaires de certaines applis, des gens qui l'ont désinstallé parce qu'ils ont remarqué que ces fameuses applis avaient tendance à diminuer l'autonomie de leur batterie.
[^] # Re: bof
Posté par barmic . Évalué à 4.
Et on pourra trouver des commentaires expliquant qu'ils ont désinstallé l'application parce qu'elle réagissait trop lentement.
Je n'ai pas dis que le problème n'existe pas, j'ai dis qu'il n'avait pas de sens dans mon utilisation. Ce que je veux dire par là c'est que le discourt simpliste de "il suffit de réfléchir et c'est performant". Il est vraiment simpliste et déconnecté de la réalité :
Tout jeter en bloc sans chercher à comprendre ce qui a mené à la situation, c'est bien pour passer le temps au PMU.
[^] # Re: bof
Posté par CHP . Évalué à 4. Dernière modification le 04 octobre 2018 à 11:24.
Ca dépend dans quel domaine. Si c'est du logiciel destiné au grand public, oui, clairement. Mais si c'est destiné à l'industrie aéronautique (ou pire, aerospatiale), c'est très différent.
[^] # Re: bof
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
Paix à leur âme, ça aurait été intéressant un retour d'expérience.
[^] # Re: bof
Posté par groumly . Évalué à 6. Dernière modification le 04 octobre 2018 à 18:36.
C'est pas ce dont parle l'article, visiblement.
windows 95 et 10, les pages web et leurs pubs, android, gmail. Il parle pas de l'industrie aéronautique, mais du milieu grand public.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: bof
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
Pas sûr de comprendre, tu voulais dire un «control»?
[^] # Re: bof
Posté par groumly . Évalué à -1.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: bof
Posté par BAud (site web personnel) . Évalué à 6. Dernière modification le 05 octobre 2018 à 02:20.
find se traduit en français par « trouver », tu voulais sans doute dire « fin » ou « précis »
rollout c'est « livraison »
feature c'est friture (sur la 3 bune) ou « fonctionnalité » dans le monde normal
pour chelou, je pense que c'est comme caillou, chou, genou et donc prend un x au pluriel (va falloir mettre à jour le BLED /o)
tu peux contribuer à traductions-classiques pour le vocabulaire qui te manque :-)
# À boire et à manger
Posté par arnaudus . Évalué à 10.
Sur le fond, c'est dur de lui donner tort, sur la forme, il y a des trucs douteux. L'exemple des compilateurs, par exemple. Pourquoi compiler du C++ prend des plombes? En grande partie, parce que c'est une tâche hyper complexe, du fait de l'évolution du langage vers de plus en plus de trucs à faire au moment de la compilation (y compris l'optimisation). Pourquoi afficher des trucs prend des plombes? En partie, parce que le nombre de pixels n'a pas augmenté linéairement dans le temps, en partie aussi parce qu'on a amélioré les algorithmes d'affichage (sub-pixellisation, etc), en partie parce qu'on a complexifié les choses à afficher (transparence, coins arrondis…). Nier que les ordinateurs d'aujourd'hui font aussi des tâches beaucoup plus complexes, ça rend quand même l'argument moins pertinent.
Tout grossit aussi parce que les briques de base s'améliorent en terme de fonctionnalités. Ça me semble être une évolution difficile à enrayer pour les bibliothèques de base, par exemple : "et si vous faisiez ci, et si vous faisiez ça", avec l'argument de "mais votre concurrent X le fait!". Un exemple tout con, c'est par exemple d'avoir besoin de fonctions mathématiques pas complètement courantes (je ne sais pas, la fonction probit dans un programme en C, par exemple). Idéalement, il faudrait quoi?
apt install lprobit-devet#include "probit.h", chacun contenant quelques lignes de code? Ça ne marche pas comme ça. Il va falloir installer un gros paquet contenant des centaines ou des milliers de fonctions (boost?), puis appeler un gros .h qui va inclure d'autres .h qui vont inclure d'autres trucs, et voila, ça y est, on a bloaté son système et son logiciel. Honnêtement, j'ai du mal à imaginer de vraies alternatives.[^] # Re: À boire et à manger
Posté par HL . Évalué à 4.
Cet exemple s'applique à un environnement de développeur. Je trouve normal son environnement soit plus "gros". Après tout, c'est un atelier de travail. Et un développeur est un utilisateur "expérimenté", il peut construire son environnement plus facilement à son gré.
Le sujet se joue plutôt à la redistribution de son programme à l'utilisateur final : compilation statique (inclusion de
probitet dépendances dans le programme) ou dynamique (un grosl.soqui contient tout)?[^] # Re: À boire et à manger
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est vrai que les linker devrait faire un plus gros effort pour nettoyer le code inutile.
Mais leur conception date de l'époque, ou les machines étaient tellement faible que la compilation se faisait fichier par fichier, et donc le programme final de link devait faire le minimum de travail. Aujourd'hui ce découpage n'a aucun sens.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par arnaudus . Évalué à 4.
Je ne suis pas sûr qu'il soit aussi simple de détecter les bouts de code qui ne seront jamais appelés (et quand tu compiles statiquement, est-ce que tu veux vraiment que le compilo choisisse ce qui est lié et ce qui ne l'est pas?). Mais de toutes manières, ça pose une énième fois la balance entre la liaison dynamique et la liaison statique, c'est toujours aussi compliqué.
[^] # Re: À boire et à manger
Posté par kantien . Évalué à 7.
À première vue, je dirais que le problème est NP-complet.
Ici, la fonction
fdépend à la fois de la fonctionmapdu moduleListainsi que de la fonction(+), fonctions qui elles-mêmes peuvent avoir d'autres dépendances en amont. Le graphe de dépendances est du même genre que celui d'un gestionnaire de paquets logiciels pour une distribution. Or, il est connu que ce problème se ramène à un problème SAT (voir projet mancoosi) qui est NP-complet.Après, si les compilateurs se mettent tous à embarquer des solveurs SAT (même optimisés pour les graphes de dépendances que l'on trouve dans du code idiomatique), il y en a qui vont se plaindre que la compilation dure trois plombes et que les compilos modernes sont tous bloated. :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: À boire et à manger
Posté par HL . Évalué à 1. Dernière modification le 04 octobre 2018 à 12:10.
Il m'avait semblé que la compilation statique (du moins avec gcc) n'incluait que les objets utilisés. C'est faux ?
[^] # Re: À boire et à manger
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Non, c'est vrai. Dans mon souvenir, le nouveau linker "Gold" de Gcc vire les objets ( au sens binaire) qui ne sont pas utilisés, comme une passe d'élimination de code mort mais au niveau assembleur.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Michaël (site web personnel) . Évalué à 2.
Il y a une différence entre “objets inutilisés” et ”objets qui ne seront jamais appelés” – le premier énoncé porte sur le code et l'autre sur l'éxécution du programme.
[^] # Re: À boire et à manger
Posté par HL . Évalué à 0. Dernière modification le 04 octobre 2018 à 22:38.
Je viens de mettre à jour mon message plusieurs fois, j'avoue que je ne suis plus très sûr : on parle bien d'objets inutilisés ?
[^] # Re: À boire et à manger
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quel différence tu fais ? Le linker de Gcc cherche les objets non appelés pour les éliminer du code;
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Michaël (site web personnel) . Évalué à 3.
Si je suis bien la conversation il y a une confusion entre deux choses:
Les fonctions (pour faire simple) d'une bibliothèque qui ne sont jamais citées par une partie du code. Cela se teste en lisant le code.
Les fonctions d'une bibliothèque qui sont citées mais dont on peut démontrer qu'elles ne seront jamais vraiment appelées pendant l'exécution du programme.
Dans le premier cas c'est un problème relativement facile à résoudre. Dans le second, il y a bien-sûr des heuristiques utiles qui permettent de traiter plein de cas intéressants en pratique, mais c'est impossible à faire “parfaitement” puisque c'est plus difficile que le problème de l'arrêt.
[^] # Re: À boire et à manger
Posté par barmic . Évalué à 1. Dernière modification le 06 octobre 2018 à 08:35.
En fait il suffit de faire ta première étape après l'élimination de code mort pour gagner potentiellement pas mal. À chaque fois que cette première optimisation s'améliorent tu gagne d'autant plus. Et oui on ne peux pas éliminer tout le code mort d'un code c'est indécidable, mais beaucoup d'optimisations fonctionne sur des heuristiques. On fais ce qu'on peut sur cas simples et ça aide déjà pas mal les utilisateurs.
[^] # Re: À boire et à manger
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Dans Lisaac (paix à son ame), le hello world qui ouvrait une fenêtre graphique (genre alerte Javascript) faisait 12 ko. Donc, c'est possible de faire de la découpe. Un programme est un graph acyclique, cela aide à couper les bouts non utilisés.
"La première sécurité est la liberté"
[^] # Re: À boire et à manger
Posté par Thomas Douillard . Évalué à 3.
Le truc qui fait que la gestion des dépendances est NP-complet c’est pas le graphe de dépendance en soi, si je me trompe pas, c’est qu’à chaque dépendance on a le choix entre plusieurs versions de dépendance et les contraintes qui font que certaines de ces versions ne sont pas toutes compatibles entre elles, ce qui nous donne un genre de problème de satisfaction de contraintes.
Ici j’ai l’impression qu’une fois que tu as bien typé ton programme tu t’es débarrassé des différents choix possibles (?) Du coup la complexité est essentiellement celle du typage. Ou alors on parle de la résolution des méthodes virtuelles qui se fait éventuellement à l’exécution, et dans ce cas on est dans le cas indécidable (problème de l’arrêt) :)
Sinon les compilateur font déjà de l’élimination de code : https://en.wikipedia.org/wiki/Dead_code_elimination Ils n’éliminent évidemment pas forcément le code dont ils ne sont pas sur qu’il sert à rien.
[^] # Re: À boire et à manger
Posté par kantien . Évalué à 4.
Effectivement, c'est ce que je me suis dit après avoir écrit le message, la NP-complétude vient peut être de la prise en compte des conflits entre paquets (ce qui revient à gérer la négation logique dans le problème SAT sous-jacent).
Après que les compilateurs effectuent déjà de l'élimination de code mort, je le sais bien. Mon interrogation, dans la lignée de celle d'arnaudus, est plutôt de savoir à quel point il est difficile de ne garder que ce qui est nécessaire et suffisant pour faire tourner le binaire, ni plus ni moins.
Dans l'exemple que j'ai écrit, il me semble bien que le compilateur OCaml va me lier statiquement tout le module
Listbien qu'une grande partie de son code ne soit pas utilisé. Dans le cas d'un langage orienté objet, si mon binaire n'utilise pas toutes les méthodes d'un objet, il n'est pas nécessaire de compiler les méthodes non utilisées. Mais à quel point cela peut-il perturber le schème de compilation pour le code d'un objet ?Quand on fait de la liaison dynamique, on reporte la difficulté sur le gestionnaire de paquet qui doit alors gérer un problème NP-complet (mais c'est sans doute lié au problème de conflits, qui n'existe pas pour la liaison statique). En revanche, pour la liaison statique, ce n'est pas sûr que le problème soit tellement plus simple si on ne veut garder que ce qui est absolument nécessaire, ni plus ni moins, et résoudre la question dans son entière généralité.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: À boire et à manger
Posté par Thomas Douillard . Évalué à 4. Dernière modification le 04 octobre 2018 à 18:59.
Ben c’est indécidable, il me semble, parce qu’il faudrait détecter les points de code inaccessibles. Or ça impliquerait de résoudre le problème de l’arrêt sur un programme tronqué jusqu’à ce point, ce qui est indécidable. https://cs.stackexchange.com/questions/49332/proof-that-dead-code-cannot-be-detected-by-compilers C’est donc bien pire que NP-complet si tu veux ne garder que le strict nécessaire, si on ne peut même pas savoir si un point du code, donc du graphe de dépendance des routines, est accessible, il est impossible de savoir si on doit garder ou pas ces dépendances.
Ça fait partie des nombreuses conséquences fâcheuses du problèmes de l’arrêt, sauf à se « limiter » à un langage comme Coq et les restrictions que ça implique. On est donc condamnés à l’incomplétude dans la détection de code mort, donc de routines mortes, dans tous les cas. Donc pas trop la peine de disserter sur les conséquences du polymorphisme dans ce contexte, on bloque au préalable :)
Et le tout sans même parler des bibliothèques pour lesquelles on a tout simplement pas de point d’entrée :)
[^] # Re: À boire et à manger
Posté par arnaudus . Évalué à 2.
Wikipédia semble lister un grand nombre de langages compilés et reflexifs (Go, objective-C, etc). Je ne les pratique pas, donc je ne sais pas vraiment de quel type de reflexivité on parle, mais j'ai quand même l'intuition que la reflexivité ou la méta-programmation doit empêcher la plupart de l'élimitation de code mort ou de code non-utilisé.
[^] # Re: À boire et à manger
Posté par Thomas Douillard . Évalué à 2.
La méta programmation n’empêche rien je pense, en C++ par exemple tu commences par constuire un équivalent de programme C++ sans template après avoir étendu les modèles (c’est déjà Turing complet par contre), une fois que tu as fais ça tu te retrouves avec un programme C++ exempt de méta programmation donc sur lequel tu peux faire la même chose que sur un langage sans méta programmation.
Pour la réflexivité, ou pour les programmes qui prévoient des plug-ins donc du chargement dynamique de code c’est autre chose effectivement. Imaginons un shell incorporé qui récupère et expose l’API par introspection du modèle du programme, tout ce qui est introspecté ne peut plus être éliminé parce que susceptible d’être appelé par l’utilisateur à l’exécution. Après c’est pareil, si l’introspection se fait sur les classes à l’étape de compilation, il doit être possible de faire l’élimination de code à la compil après cette phase. Si c’est dynamique il me semble effectivement impossible de savoir ce qui ne va pas être introspecté à la phase de compilation.
[^] # Re: À boire et à manger
Posté par kantien . Évalué à 2. Dernière modification le 05 octobre 2018 à 11:38.
Je me rend compte que j'étais resté trop évasif sur ma notion de nécessaire, j'entendais par là la nécessité au sens de l'approximation conservative telle que définie dans ton lien. Est nécessaire tout ce qui est potentiellement appelé, même sous une condition dynamique qui ne peut jamais terminée.
Mais je dois être biaisé dans mon appréhension de la difficulté, d'après Nicolas Boulay le linker de Gcc effectue ces suppressions (quoi que ça ne signifie pas que le problème soit simple à résoudre).
Pour illustrer ce que j'ai en tête, je l'illustre avec un exemple en programmation modulaire. Imaginons qu'on a un module de
Listavec cette signature :Un tel module définit le concept de liste chaînée, ainsi que quelques propositions de base sur lui (une théorie élémentaire sur les listes, en somme). Maintenant, je veux écrire un programme qui utilise ce concept mais le seul théorème qui m'intéresse est que l'on peut mapper une liste. Problème pour le compilateur : faire en sorte que seul le code de
List.mapsoit lié statiquement à mon binaire, mon programme n'ayant rien à faire du fait que l'on puisse aplatir une liste de listes par exemple.On retrouve le même genre de questions dans les langages orientés objets (un objet c'est le module du pauvre) : ne pas lier statiquement le code des méthodes dont on est certain qu'elles ne seront jamais appelées.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: À boire et à manger
Posté par Thomas Douillard . Évalué à 3.
Alors on tourne en rond, j’ai l’impression que c’est l’affaire de juste parcourir un graphe d’appel de fonction dont le point de départ est le « main », le problème que tu définis, et c’est vraiment pas d’une complexité folle. Si aucune fonction appelée depuis le main dans le code, et récursivement, n’appelle LIST.flatten, tu n’as besoin d’inclure aucun code relatif à cette fonction.
Ça ne m’a pas l’air d’être une question de programmation modulaire, posée comme ça, mais d’une question relative à n’importe quel langage dans lequel on peut faire des bibliothèques de fonction.
Après si tu disposes de plusieurs implémentations pour ce modules, je suppose que le compilateur Ocaml sait choisir la bonne de lui même avant de faire l’élimination du code mort ? (je te soupçonne de vouloir m’emmener sur ce terrain si tu insistes sur la notion de module)
[^] # Re: À boire et à manger
Posté par Burps . Évalué à 0.
Pour moi, c'est indécidable car:
Ici,
ma_super_fonctionest du code mort si la machine de Turing décrite parcodesur l'entréeinputtermine. Bonne chance pour décider cela.[^] # Re: À boire et à manger
Posté par barmic . Évalué à 3.
Ce n'est pas du code mort et ce n'est pas la question. L'idée c'est de faire les vérifications statistiques. Bien sûr que si ton programme consiste uniquement à prendre un input A et à exprimer "si A alors B sinon C", tu aura des exécutions qui ne passeront que dans B et d'autres que dans C. Mais ce n'est pas ce dont il est question ici.
[^] # Re: À boire et à manger
Posté par Burps . Évalué à 0.
Si, car le code de la machine de Turing et de son entrée sont connus à la compilation - j'aurais du souligner les
static constpour être plus clair, et aussi que l'évaluateur ne modifie pas l'état global. Je vais la faire en plus simple:Maintenant le code mort est très clair ? Il est tellement clair que n'importe quel compilateur va l'enlever dans ce cas d'ailleurs. J'ai juste remplacer
falsepar une constante plus dure à évaluer (c'est semi-décidable).[^] # Re: À boire et à manger
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est quoi plus dure "à évaluer" ? Soit c'est évaluable, soit cela ne l'est pas.
Tu sépares clairement la phase compilation de la phase exécution, mais dans beaucoup de langage, cela n'a pas trop de sens.
Par exemple, go est un langage compilé. Pourtant, en test, je fais un "go run" qui compile et exécute à la volé. Donc, que l’exécution de ta machine de turin se fasse à la compile ou à l’exécution, cela ne change pas grand chose d'un point de vue pratique (vu de l'extérieur).
"La première sécurité est la liberté"
# c'est sans doute pour ça…
Posté par bobo38 . Évalué à 10. Dernière modification le 03 octobre 2018 à 13:11.
C'est sans doute pour ça que j'utilise dwm, vim et urxvt principalement pour faire tout ce que je veux sur une base archlinux
J'ai arrêté les gestionnaires de fichiers la ligne de commande fait tout plus facilement à part monter les volumes amovibles. Complètement à contre-courant du mainstream qui veut cacher les fichiers, quitte à multiplier les réglages foireux hétérogène, des fonctions d'importation en veux-tu en voilà, ou des bases de données à toute les sauches (pourvu qu'on ne voit plus une arborescence de fichiers qui fait peur – je dois être un homme des cavernes). De même j'ai arrêté les environnements de bureaux lourdingues tout-intégrés, là je ne saurais pas dire pourquoi (mais probablement pour échapper aux choix faits par d'autres, et à la fausse impression de progrès)
En logiciel d'appoint sur cette surcouche minimaliste j'utilise clawsmail (un client mail en 2018 ?!!) pour éviter les webmails moisis, firefox avec ublock origin et privacy badger pour accélérer le web (comme je peux), et mpv pour regarder des vidéos en ligne de commande à l'occasion. Principalement
(je ne suis pas développeur)
# Non mais néanmoins
Posté par abriotde . Évalué à 4. Dernière modification le 03 octobre 2018 à 14:11.
L'article est clairement du niveau de "madame michu", comme dis dans le commentaire précédent il y a a boire et a manger.
Pour reprendre son analogie avec l'automobile ou l'aviation, les compilateurs, les OS, les navigateurs Web et les systèmes de fichiers sont hyper optimisés. Il en est de même pour les grand sites web (Google, Facebook…). Et de manière général les très gros projets sont généralement bien optimisés. Mais plus l'on va dans les plus petits projets (ou dans l'hyper rentable) on trouve souvent moins coûteux de ne pas optimiser et de laisser le système (compilateur, OS) optimiser et pour le reste, la puissance de calcul ne coûte pas cher. Ensuite quand les prix explose, que la charge deviens difficile a tenir on reviens sur le programme et regarde l'optimisation. Le problème viens aussi parfois de la technique qui n'est pas toujours bien maîtriser…
On peux faire l'analogie avec "madame michu" qui reste en 3° à 100 km/h au lieu de passer la 5°, ou l'artisant qui prends un chantier à 100 km et fera l'aller-retour tous les jours de la semaine avec son camion remplis de matériel car au final cela lui coûte moins cher que l'hôtel, que de décharger ou que de prendre une petite voiture en plus pour rentrer…
Peux t'on blâmer quelqu'un? Non, je ne crois pas. c'est juste qu'il faut parfois rappeler qu'il y a moyen de faire plus optimisé, plus écologique.
# CMB !
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Oui tout devient plus gros, mais quelles sont les solutions?
Je fais du Java ou Typescript bloated parce que ça improve ma productivity. Et si je veux plus de performance et d'optimisation sans sacrifier la rapidité de développement?
Go est lent et primitif, Rust produit des exécutables de 4mo pour un Hello World, C++ compile comme un escargot et a un outillage datant de 1742…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: CMB !
Posté par Tit . Évalué à 5.
ça veut dire quoi CMB ?
[^] # Re: CMB !
Posté par dovik (site web personnel) . Évalué à 10.
Comme Mon Bide.
C'est parce que devnewton< approche de la quarantaine.
[^] # Re: CMB !
Posté par eingousef . Évalué à 10.
Il fait des bides depuis bien plus longtemps que ça !
*splash!*
[^] # Re: CMB !
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Le C veut dire « Comme ».
[^] # Re: CMB !
Posté par anaseto (site web personnel) . Évalué à 6.
Hahaha :)
[^] # Re: CMB !
Posté par Boiethios (site web personnel) . Évalué à 2.
https://stackoverflow.com/questions/29008127/why-are-rust-executables-so-huge#29008355
[^] # Re: CMB !
Posté par anaseto (site web personnel) . Évalué à 2.
Après, faut reconnaître que c'est amusant qu'un exécutable « hello world » statique avec rust prenne plus de place qu'avec Go qui lui inclut un GC dans le runtime (enfin, ça a l'air de dépendre de la plateforme aussi). Ceci dit, en dynamique ça donne juste 16K, oui.
[^] # Re: CMB !
Posté par David Marec (site web personnel) . Évalué à 1. Dernière modification le 04 octobre 2018 à 12:46.
C'est pour une commande groupée.
https://www.cafepress.com/mf/1112167/long-sleeve-false-tshirt_long-sleeve-tshirt?shop=false&productId=2551718
Bon, ce n'est pas la bonne convention d'appel pour du Linux, mais il n'y aura pas grand monde pour s'en apercevoir dans la grande famille des développeurs.
# Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par damaki . Évalué à 10.
Nous sommes dans un monde où on sait développer un service accessible depuis l'extérieur, un CRUD qui tape en base en minutes, le tout avec des perfs raisonnables. Alors oui, on peut développer la même chose en C ou C++ en une journée avec le vent dans le dos (et des segfaults) ou en une semaine en assembleur. Donc on développe plus vite des choses plus testables et mieux testées qu'avant.
Là où l'article vire dans la mauvaise foi c'est que nous sommes dans un monde où on veut toujours plus de complexité. Évidemment que Windows 10 est plus lent que Windows 95, il y a beaucoup plus de fonctionnalités dedans qu'on prend désormais comme des acquis. Idem pour un téléphone, on veut une appli de photos, une appli de streaming de musique, gestion de contacts, accès aux mails, services de streaming vidéo et le tout avec de la synchro au cloud parce qu'on a la flemme de faire des copier-coller de fichiers. Combinez la complexité avec les stacks logicielles citées ci-avant qui facilitent le dev et vous avez la réponse à la question "pourquoi cette lourdeur ?". C'est parce que c'est la seule réponse possible à ce que les gens demandent. Une ampoule à LED est largement plus complexe qu'une ampoule à filament ; est-ce que ça les rend mauvaises pour autant ?
Si la réponse ne vous plait pas, changez de question en "pourquoi veut-on autant de fonctionnalités ?".
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 8.
C'est pas ça le problème, le problème, c'est
On veut juste tout de suite un truc qui marchotte plutôt que d'avoir un truc un peu plus léché.
Le problème, c'est que c'est inhérent à l'époque et pas limité à l'informatique.
Alors ça, tu peux oublier. Il y a une quantité de softs où tu te demandes si la procédure d'installation a été testée, si la compilation par un tiers a été testée (le fameux "ça compile chez moi")…
Et heureusement qu'il y a des softs anciens qui ont été testés et qui étaient testables comme les métros, les avions et autres joyeusetés.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par groumly . Évalué à 4. Dernière modification le 04 octobre 2018 à 02:21.
Ben voyaons.
Ya 10 ans, le concept de CI était encore nouveau, les procedures de test/build étaient pour la plupart manuelles. Spring et la dependency injection était un truc révolutionnaire (et comme par hasard, vu d'un mauvais oeil par les cetaimieuavan et les onatoujourfaitcommssa).
Les frameworks de test sont très très loin de ce qu'on avait a l'époque.
Le "spolsky test" était encore de rigueur pour évaluer une boite. J'ai eu un candidat junior qui me l'a pose récemment, ca m'a fait bizarre de me faire demander "est ce que vous utilisez un VCS?".
Yavait autant de code pas testé ya 10 ans que maintenant (si ce n'est plus, comparativement). C'est juste que ce code n'existe plus maintenant (ou a été refactoré depuis).
Donc non, la qualité a pas empiré avec le temps. Elle est passe d'un concept bizarre (tu devrais être content que ca boote, te plains pas!) a une pratique mal comprise et souvent mal voire pas appliquée.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par -mat . Évalué à 2.
Je pense qu'il y a plein de boîtes qui ont voulu faire un produit bien fini, bien testé, pas gourmand, développé à la mimine, bien optimisé… et qui ont au final coulé, car pas rentable, ou arrivé trop tard sur le marché ou n'étant plus compatible avec la nouvelle plateforme matérielle à la mode (bein oui, l'assembleur c'est bien, mais il faut le réécrire)…
Outre l'exagération sans borne des exemples des articles, il y a une réalité du marché. Les applis sont grosses, ok, mais on peut les développer rapidement, et les sortir à temps, et sur plusieurs plateformes, …
Bref il existe des tas d'applications rapides et légères en mémoire. C'est à l'utilisateur de les choisir. Alors effectivement, un clavier léger, ne fait que clavier, et pas la reconnaissance vocale, ni la correction orthographique, ni… Mais il faut savoir ce que l'on veut.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par gaaaaaAab . Évalué à 4.
Ça n'a rien d'une évidence. On n'est pas à matériel constant. La loi de Moore sur 20 ans, c'est quand même une augmentation très significative de la performance brute.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par Renault (site web personnel) . Évalué à 10.
Perso des souvenirs que j'ai de cette époque lointaine, W95 / W98 sur les machines de l'époque ce n'était clairement pas des systèmes hyper réactifs. Je ne crois pas qu'ils soient plus lents en terme absolus pour faire la "même chose". Si on peut considérer qu'on fait réellement la même chose 20 ans après, perso je pense que c'est illusoire de comparer cela.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par gaaaaaAab . Évalué à 2.
Je ne dis pas que les systèmes modernes font "la même chose". Je dis juste que ça ne va pas de soi que le coût de l'augmentation de la complexité consomme une grande partie du gain de réactivité qu'on pourrait attendre de l'augmentation des performances du matériel.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par Astaoth . Évalué à 5.
Toi, t'as pas utilisé Windows 95 sur un ordi de l'époque. Perso, je suis assez content de la réactivité de Windows 10 sur un proc monocore et 1G de ram (jcrois que c'est une config légère ca de nos jours) par rapport à ce bon vieux Windows 95 et ses 5 minutes pour démarrer. Sans parler des problèmes de compatibilités de driver pour le moindre bidule complètement trivial de nos jour (du genre, faire marcher un joystick).
Emacs le fait depuis 30 ans.
[^] # Re: Ça prendrait combien de temps à développer sans cette lourdeur ?
Posté par gaaaaaAab . Évalué à 2.
je ne dis pas le contraire. Je dis juste que c'est difficile de faire la part des choses entre le gain éventuel de réactivité, l'augmentation de la complexité et l'augmentation des performances du matériel. Simplement dire que la réactivité est équivalente ou meilleure aujourd'hui avec l'augmentation de complexité n'est pas incompatible avec la possibilité que nos logiciels actuels soient "bloated".
# C'était mieux avant
Posté par David Demelier (site web personnel) . Évalué à 10.
Je suis globalement d'accord avec ce qui est dit. Et je m'en rends de plus en plus compte. J'ai encore un PC avec un Pentium 4, FreeBSD 8 et seulement 512Mo de RAM et je peux m'en servir correctement.
Dans mon ancien travail, j'avais un Thinkpad X1 carbon 5 avec 8Go de RAM et pourtant combien de fois le kernel m'a tué des processus parce que j'utilisais Atom/Node/Slack/Firefox ? Je ne préfère pas compter (l'entreprise en question développe du nodejs).
Ma haine envers electron est sans fin. Je ne parviens pas à comprendre que des gens se disent et si je codais un terminal en electron ?. C'est à dire charger un environnement web complet pour un shell.
Je pourrais dire de même de la communauté npm qui ne peut s'empêcher de créer des modules pour les gens qui ne savent plus coder résultat : à chaque installation d'un quelconque paquet on télécharge la terre entière.
Pour finir, moi qui ai commencé à utiliser Linux en 2003 (avec Mandrake 9.2 et 10 avec KDE 3) je peux dire que la qualité n'est plus au rendez-vous. Maintenant il y a pas un jour sans qu'evolution se mette en erreur de synchronisation; de bugs en tout genre avec GNOME Calendar; de bugs surprenants dans GNOME Shell.
C'est bien dommage, j'ai l'impression que dorénavant on oublie la qualité. Tout est over-engineered, Red Hat ne fait que rajouter des nouvelles couches au dessus du noyau Linux rendant le système surchargé de services. Avec flatpak, ce sera pire. Et je sens que dans quelques années on finira par lancer toutes nos applications dans des dockers. Parfois j'ai envie de réécrire un OS simple basé sur la vraie philosophie UNIX ou tout serait fichier et non pas un service D-Bus (hostnamed pour exposer un hostname sur D-Bus, tu rigoles ? et non).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'était mieux avant
Posté par gUI (Mastodon) . Évalué à 7.
Oui, c'est aussi mon sentiment général, y compris au boulot, où t'as facilement 10 personnes qui entrent en jeu pendant 6 mois pour designer un truc que finalement deux codeurs font en 2 mois.
Au passage, je fais le parallèle avec ce journal récent : toute notre vie est over-engineered.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C'était mieux avant
Posté par Ontologia (site web personnel) . Évalué à 9.
Plan 9 from Bell Labs ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'était mieux avant
Posté par lolop (site web personnel) . Évalué à 3. Dernière modification le 03 octobre 2018 à 19:48.
Tu nous donneras des nouvelles ?
Dès que ça tourne, tu peux faire l'annonce sur osnews.
Sinon, tu peux aussi jeter un coup d'œuil à Haiku — par contre, c'est pas la philosophie Unix, et c'est du C++.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: C'était mieux avant
Posté par David Demelier (site web personnel) . Évalué à 2.
Oui haiku ça fait un moment que je suis, j'ai hâte de voir ce que ça va donner sur le long terme.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'était mieux avant
Posté par bbo . Évalué à 9.
Haiku a été créé en 2001. Quand tu parles du long terme, ça se positionne comment par rapport à GNU Hurd ?
Note: je suis d'humeur joviale aujourd'hui et plutôt en avance pour demain.
[^] # Re: C'était mieux avant
Posté par David Demelier (site web personnel) . Évalué à 1.
Je pense que Haiku doit commencer à pouvoir s'utiliser en desktop avec du matériel pas trop exotique. Mais comme il n'y a pas de drivers bluetooth je dois dire adieu à mes souris et enceintes pour le moment /o\
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'était mieux avant
Posté par MrBidon . Évalué à 3.
Je suis curieux avec ton pentium 4 tu arrives a surfer ? Si oui quel navigateur ? Est ce que freebsd est plus light qu'une xubuntu par exemple ?
[^] # Re: C'était mieux avant
Posté par David Demelier (site web personnel) . Évalué à 2.
Alors ça fait un moment qu'il est débranché, il tournait sur dwm donc ça utilise très peu de ressources. Mais avant j'étais encore sur GNOME 2 et c'était plutôt fluide. C'est une très vieille version de firefox qui est dessus donc je pense que ça doit tourner pour la plupart des sites peu gourmands (à mon avis tu oublies slack et autres).
FreeBSD est effectivement plus léger en terme de ressources mais c'est assez négligeable.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'était mieux avant
Posté par MrBidon . Évalué à 4.
Dommage, j'ai un latitude E4300 (core 2 duo / 4GB de RAM) je trouve qu'il rame bien sous Firefox. Avec la quantité de framework js qui se propage, il va être nécessaire d'avoir une bête de course pour utiliser la moindre appli web (par exemple, le nouveau Gmail qui me semble plus lourd côté client que l'ancien).
[^] # Re: C'était mieux avant
Posté par Guillaume Denry (site web personnel) . Évalué à 8. Dernière modification le 04 octobre 2018 à 08:56.
Le nouveau gmail est abominablement lent, moi qui était fan de son efficacité à une époque, je commence sérieusement à me demander si je ne vais pas tout migrer ailleurs. Ils sont devenus complètement fous…
[^] # Re: C'était mieux avant
Posté par arnaudus . Évalué à 5. Dernière modification le 04 octobre 2018 à 09:27.
J'imagine que comme toute grande entreprise, les compétences initiales sont noyées dans la lourdeur, la bureaucratie, les décisions de décideurs qui ont une formation top-moumoutte en prise de décisions décisionnelles… Parce que ça ne date pas de Gmail, la "mise à jour" de Google maps d'il y a quelques années ont transformé un site incoutournable en quelque chose de quasi inutilisable. À se demander si Google ne se reconvertit pas dans le minage de bitcoins…
[^] # Re: C'était mieux avant
Posté par Kerro . Évalué à 7.
Au cas où : as-tu essayé avec Chrome ?
Car Maps est bien plus lent avec Firefox qu'avec Chrome. Certains pensent que ce n'est pas tout à fait involontaire.
[^] # Re: C'était mieux avant
Posté par sebas . Évalué à 2. Dernière modification le 04 octobre 2018 à 19:36.
Pareil pour youtube : zdnet.
D'ailleurs, sur qupzilla ancienne mouture (1.8.9, encore en service dans debian stable), le site youtube est devenu soudainement totalement inutilisable (il commence à charger, puis avant d'avoir fini, repart à zéro, ceci en boucle).
[^] # Re: C'était mieux avant
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Il y a encore deux ans, nous faisions tourner une salle de calcul scientifique (18 terminaux en ltsp clients légers) avec une xubuntu de 2014 sur un unique pentium-D avec 4 Go de RAM (depuis on est passé à un core i3). Et oui on pouvait naviguer sur internet sur des sites raisonnables (wikipedia, linuxfr, gmail…). Mais dès qu'un étudiant commençait à chercher à se connecter à des trucs idiots [*], ça ramait.
Le core i3 lui peut faire tourner les xubuntu de 2016 ou 2018 ce que ne savait pas faire son petit camarade.
[*] Je ne donne pas de noms, sinon on va encore me gratifier de qualifications comme anti-mirosoft, ou anti-Albanel primaire.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: C'était mieux avant
Posté par cmal (site web personnel) . Évalué à 2.
Firefox est très performant sur les vieux systèmes si tu désactives Javascript, que tu vires la pub, et que t'essayes pas de décoder de la vidéo MP4 avec.
Perso c'est µblock Origin (bloqueur de pubs) + NoScript (switch par nom de domaine niveau pour activer/désactiver Javascript) côté navigateur, et pi-hole (résolveur DNS) + CAKE (queueing) côté réseau.
Ça fait des merveilles même avec les Pentium 4. Comme quoi le web, ça peut être très bien quand on fait pas n'importe quoi avec. Faut arrêter les simples blogs/vitrines qui ont plus (en poids et en nombre) de Javascript que d'images pour un simple truc qu'on peut faire en CSS3.
Le Javascript ça doit être une surcouche pour augmenter les fonctionnalités, pas un pillier de ta mise en page qui menace de s'effondrer à chaque seconde et fait chauffer ton ordi. Véridique: quand je bloque pas les pubs/JS sur mon ordi, au bout de 30 minutes il surchauffe et il s'éteint parce que y'a toujours au moins une page qui fait prendre 100% d'un CPU à Firefox.
Alors effectivement je comprends qu'il y a plus de fonctionnalités dans vos softs. C'est cool. Et certaines de ces fonctionnalités sont vraiment super (d'autres moins). Mais n'oubliez pas les vraies personnes derrière qui vont utiliser votre système avec du vieux matos de merde et qui ont pas les moyens de faire autrement (on est beaucoup). Pour les anglophones du web : Dear developer, the web isn't about you.
[^] # Re: C'était mieux avant
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Un CPU et son système de refroidissements sont normalement conçus pour fonctionner à fond sur tous les cœurs disponibles. Si une page web (ou n'importe quoi d'autre) fait planter ton PC pour cause de surchauffe, c'est que tu as un problème grave de matériel.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'était mieux avant
Posté par totof2000 . Évalué à 5. Dernière modification le 05 octobre 2018 à 12:53.
tu diras ça aux ordinateurs portables qui plantent sauvagement à cause de la surchauffe lors d'un test mémoire avec memtest.
La plupart des PC portables ne sont pas fait pour tourner à 100% de leur capacité en permanence. Quand tu exécutes un OS comme windows par exemple, celui-ci ralentit la vitesse à laquelle ta machine fonctionne lorsqu'il surchauffe, ce qui fait que tu ne t'en reds même pas compte. Par contre avec un test mémoire, ya pas de régulation de la vitesse en fonction de la température et ça plante.
[^] # Re: C'était mieux avant
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Bizarre, pour moi la régulation thermique était une protection du bios de la machine, pas de l'OS.
"La première sécurité est la liberté"
[^] # Re: C'était mieux avant
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 05 octobre 2018 à 14:39.
Les PC portables de ce type ne devraient même pas être vendus…
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'était mieux avant
Posté par cmal (site web personnel) . Évalué à 0.
J'ai peut-être un ventilo dead mais à part ça rien de grave. C'est un Thinkpad T410 dont on parle donc pas non plus la dernière merde au fin fond du rayon discount ;)
[^] # Re: C'était mieux avant
Posté par dyno partouzeur du centre . Évalué à 6. Dernière modification le 06 octobre 2018 à 10:24.
Sauf qu'aujourd'hui l'Internet qui marche sans JavaScript ça représente quelque chose d'assez infime. J'imagine que des sites comme debian.org ou wikipedia marchent, mais adieu les sites bancaires, l'e-commerce, les réseau sociaux, une grande partie des sites d'informations, etc.
[^] # Re: C'était mieux avant
Posté par cmal (site web personnel) . Évalué à 1.
Ben en fait pas tant que ça. Comme tu l'as dit, certains sites par leurs fonctionnalités comme les webmails et les banques ont besoin de JS (encore qu'on pourrait faire sans), mais 95% du web est read-only et les 5% qui restent fonctionnent très bien avec des formulaires HTTP à l'ancienne sans AJAX.
C'est plutôt rare (mais de plus en plus fréquent) de tomber sur une page qui ne fonctionne pas sans JavaScript. C'est le cas avec certains ****** de frontend designers avec leur framework JS à la con qui génère le DOM et le CSS dynamiquement pour faire un simple blog (ce qui n'est pas recommandé pour plein de raisons).
Donc en fait, j'active Javascript quand j'ai besoin sur un site. Une vidéo Framatube par ci, un webmail par là… Et là j'ai la presque-certitude qu'aucune page web que j'ai whitelistée (pour la session) ne va me bouffer 100% de mon CPU :)
[^] # Re: C'était mieux avant
Posté par MrBidon . Évalué à 3.
Ouais, du coup je commence à penser que les SPA (Single Page Application) en JS vont tuer les vieux PC. Vive les appli PHP à papa avec un menu HTML des familles rafraichi à chaque clic !
[^] # Re: C'était mieux avant
Posté par Stéphane Ascoët (site web personnel) . Évalué à 0.
En effet, il doit être éteint depuis longtemps. Pour utiliser le même genre de configuration quotidiennement, je peux assurer qu'on est hyper bloqué pour un tas de choses, déjà parce qu'en restant sur de vieilles versions, on n'a pas accès aux derniers cyphers TLS qui se généralisent, et ensuite parce que le HTML 5 et ses merdes associées ne sont pas correctement interprétés.
[^] # Re: C'était mieux avant
Posté par Boiethios (site web personnel) . Évalué à 1.
Tu peux jeter un coup d'oeil à redox: https://www.redox-os.org/
[^] # Re: C'était mieux avant
Posté par bbo . Évalué à 2. Dernière modification le 04 octobre 2018 à 12:05.
Vu que tu es utilisateur de FreeBSD (ou, du moins, tu as été), je me demande si le bloat que tu ressens dans l'écosystème Linux se retrouve aussi dans FreeBSD au fil des versions ?
Si je le dis autrement : même la famille des BSD ne t'enlèves pas l'envie de réécrire un OS ?!
(Si ma question est conne, je te précise que je n'ai jamais utilisé de BSD. Donc, il y a peut être D-Bus et les trucs qui te plaisent pas sur FreeBSD, je n'en sais rien)
[^] # Re: C'était mieux avant
Posté par David Demelier (site web personnel) . Évalué à 4. Dernière modification le 04 octobre 2018 à 13:56.
Je n'utilise plus FreeBSD sur mes portables principalement par compatibilité matérielle, je continue sur mes dédiés. J'aime énormément FreeBSD et OpenBSD. les BSD ont effectivement une vision plus simplissime de ce qu'ils écrivent (surtout chez OpenBSD). Exemple simple, j'apprécie pouvoir rajouter des périphériques bluetooth sur FreeBSD sans avoir besoin de D-Bus mais ça ne veut pas dire que tout est parfait, FreeBSD par exemple possède 3 firewalls dans son arborescence, je trouve que c'est un choix particulier. Cela dit grâce au fichier src.conf tu peux recompiler ton kernel+userland pour désactiver tout ce qui ne t'intéresse pas.
C'est assez difficile de comparer, car en tant que tel on peut faire aussi quelque chose de très léger et simple avec Linux. Il y a d'ailleurs la distribution Alpine dont je suis fortement intéressé pour une éventuelle migration. Elle se base sur Linux, musl et busybox ce qui fait quelque chose de très simple.
Non, j'aime beaucoup les BSD. Je n'ai pas grand chose à reprocher d'ailleurs. J'aimerais bien avoir OpenBSD sur mon X1 mais il y a trop de choses qui seraient compliquée pour mon utilisation personnelle (développement Android, pas de bluetooth).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'était mieux avant
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Npm, c'est le système de paquet le plus merdique que j'ai jamais vu. Il permet d'installer la même lib dans N versions. Tu te retrouves alors une appli avec du code quasi-dupliqué N fois, à cause des dépendances qui n'utilisent pas la même version de lib que les autres dépendances.
J'ai installé une appli Web servie par nodejs (Strider-cd), assez conséquente, certes, utilisant beaucoup de paquet différents. Voici quelques statistiques :
Bref, NPM est un système de paquets qui favorisent le bloatware et le gachi de ressources. Faut pas s'étonner après de toutes ces applis Web ou Electron qui réclament des mégas..
# web assembly
Posté par MrBidon . Évalué à 1.
Serait ce une solution pour avoir des applications web moins chargée ?
[^] # Re: web assembly
Posté par guppy . Évalué à 2.
Je ne pense pas. Il y a déjà des tas de possibilités pour améliorer, une de plus ne changera rien. Pour que ça change il faut surtout que l'industrie du développement en ai la volonté / les ressources financières.
# Pour creuser
Posté par _blob_ . Évalué à 0. Dernière modification le 09 octobre 2018 à 19:28.
Bullshit jobs de David Graeber permettra de répondre aux questions que certains se posent ici. L’informatique est particulièrement touchée, mais pas que… Bien que je sois en désaccord avec sa remise en cause du capital ; grosso merdo, le gain de productivité, très certainement sous estimé par ailleurs, est incompatible avec une société “industrielle” qui place le travail rémunéré comme valeur cardinale de l’activité humaine, ce qui dépasse très largement la question du capitalisme.
Pour résumer :
1/ On fait de la merde
2/ C’est voulu parce que ça arrange tout le monde
# Réaction liée
Posté par benoar . Évalué à 2.
Une autre réaction d'un développeur français un peu connu, qui acquiesce :
http://fabiensanglard.net/bloated/index.php
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.