Ces messages peuvent être vus comme un progrès pour ceux qui n'utilisent pas un mode de navigation privée, voir avaient depuis la nuit des temps configuré leur navigateur (proposant ces options, tel FF) pour vider la benne à ordure des pubeux de tout ordre à extinction.
On peut aussi vider la benne en cours de session à des moments opportuns, par exemple avant de se connecter à leur banque/site de commerce avec une intention d'achat, d'un Ctrl+Shift+Suppr.
=> Ceux là, soucieux des traces laissées chez eux depuis longtemps, sont au final ceux qui sont emmerdés par ces dispositions législatives très mal pensées car ils vont devoir refaire la manip (en général au plus rapide proposé, accepter tout, sachant que finasser est conçu pour être dissuasif) à chaque re-connexion.
Pour réconcilier tout le monde, ce type de disposition aurait dû être faite sur le mode du "do not track", voir en rendant ce dernier (pré-existant) équivalent à un "ne rien accepter" exclusif de tout questionnement et indépendant du vidage de la benne à cookie et données de sites diverses et avariées.
Comme avec bloctel (il eu mieux valu faire une chose très simple: Redonner un coût obligatoire aux appels vers fixe en faisant un illimité en mode mobile: Peu probable d'y arriver en usage individuel, par contre pas vraiment pour un centre d'appel) qui semble vous ramener plus d'appels qu'en éviter, nous sommes dans un pays qui aime faire des usines à gaz finissant à l'inverse du but visé.
Pour éviter les bidouilles!
On pourrait ajouter les variables static (là aussi, on peut bidouiller), facilitant l'utilisation purement procédurale du langage…
Les outils d'analyse de code C permettent en effet de compenser les avantages de conception de Rust, en évitant en prime de devoir cumuler (au niveau logiciel de base) la complexité de la machine (un processeur/SoC actuel) avec celle du langage (devoir en particulier en permanence s'embêter avec les problèmes d'appartenance).
Je n'ai pas étudié l'affaire de très près, ceci dit, mais vu de haut je vois plus Rust utile côté applicatif que pour coder un système d'exploitation voir ses modules/drivers.
Ce ne serait pas le 1er challenger du C de l'histoire à échouer!
Il y a des tas de choses à bas niveau qui sont propres à chaque architecture et qui n'ont pas leur place dans des langages de haut niveau, même ceux qui permettent déjà beaucoup de choses comme le C.
Sans même parler du strict démarrage (va appeler du C sans avoir initialisé une pile, donc une RAM qui est souvent un bout de mémoire cache plateforme dévoyé le temps de la complexe initialisation DDR!), niveau OS, toutes les primitives bas niveau touchant à la mémoire cache justement, la mémoire virtuelle, préfixes/postfixes d'interruptions, opérations atomiques (test&set)…
Cela ne représente plus grand chose (on n'écrit donc pas vraiment un OS en asm), même s'il y en a quand même de planqué ailleurs (sous forme d'asm inline) que dans des fichiers complets, mais c'est la portion inévitable.
En effet, mes 2 dernières installations:
-Un laptop perso acheté d'occase livré avec un Win10 home refurb sur un BIOS reconfiguré en legacy… mais qui repassé en UEFI, avait encore la clef 10 pro de la version constructeur bien au chaud… avant de lui mettre un double boot Debian.
-Puis une machine labo au taf, avec la clef de licence win7 pro OEM de l'étiquette (bouffée sans pb par l'installeur de 10: Ils ne veulent vraiment plus le vendre!), pour des softs d'analyseur logique, l'horreur Visual eBios d'AMI qui n'avait aucune chance de me réconcilier avec le patchwork Eclipse etc… dont les versions Linux ne sont hélas pas stables (Salae, si tu m'entends…).
Et franchement même réflexion: Zéro problème, fini la litanie d'une demi journée de reboot d'application séquentielle de tous les patchs mensuels depuis la sortie de la dernière ISO. Juste à ruser pour éviter le compte en ligne microsoft et se taper le moins de traceurs (télémétrie en novlangue microsoft) possible.
Au final, on arrive à avoir un système (certes moins complet on n'a pas une suite bureautique etc) qu'un Linux dans un temps à peine 2x supérieur à mon top chrono: La Debian Netinstall, qui charge direct tout un système à jour.
Franchement, cela me semble devenu très correct même si je n'apprécie pas win10 et ne l'utilise que dans des cas contraints (et toujours avec un Cygwin pour le rendre supportable).
Il faut dire qu'utiliser un clone Red-Hat ne se justifie vraiment que pour avoir une version d'OS homogène sur un parc matériel qui va forcément diverger sur les 10 ans de support assuré: Là, avoir Red-Hat qui se tape le boulot de backport du support du nouveau matériel arrivant en flux continu sur un kernel antédiluvien peut avoir une utilité.
Mais la contrepartie, c'est quand même des dépôts qui sont un vide absolu comparé à la richesse côté Debian. Les premiers mois/années, on peut au moins recompiler de manière a peu près fiable ce qui manque soit-même (pour éviter les acrobaties avec les dépôts de la Fée-Dora, sport de masse sous RH) mais cela se gâte très vite.
Pour ma part, entre la gestion de paquets inférieure (en disponibilité et à l'usage) et le cycle AMHA trop long, j'ai toujours trouvé que Debian offrait un meilleur compromis stabilité/nouveauté.
Scientific-Linux devenu un CentOS, après que RH ait déjà savonné la planche aux coucous d'Oracle, les jours de la "RH du pauvre" semblaient comptés. Car le débouché entre Fée-Dora et RH semble pour le moins limité.
Posté par lym .
En réponse à la dépêche Sortie de TIC‑80 version 0.80 .
Évalué à 1.
Dernière modification le 05 novembre 2020 à 16:52.
J'ai toujours mon EeePC901 avec son Atom 1er du nom si "poussif", actuellement avec une Debian 10 et bureau Mate qui n'est pas le plus léger qui soit. Ca reste utilisable. La seule modif avait été de lui payer une barrette de 2GB à la place de celle d'1GB d'origine (+, sans impact ici, carte wifi Ubiquity plus sensible que l'originale et pouvant cracher très au dessus des 100mW autorisés, import US oblige, qui accrochait sans problème des points d'accès à 500m, malgré les antennes internes, en vacances avant la baisse des forfaits data mobiles).
Pour le jeu, pas mal de jeux Linux un peu anciens tournent sans problème… d'encore plus anciens portages, type Doom, également: C'est pas neuf, mais ça reste d'un autre niveau qu'animer des sprites comme sur un Amstrad ou Commodore des années 80 tout de même.
Là si c'est un problème, c'est pas l'Atom qu'il faut blâmer!
Le plus incroyable avec cette petite machine comme on n'en fait hélas plus: Son autonomie, avec une batterie d'origine chargeant encore à 85% de sa capacité théorique. Du Asus de la décennie 2000, en résumé, même pour ce modèle alors low-cost.
Quand on voit qu'un A400M tout frais sorti de l'assemblage a été perdu (tuant l'équipage d'essai) car le FADEC (contrôle moteur), si des calibrations hélice manquaient, était capable d'accepter la puissance maximale au décollage mais qu'ensuite chaque réduction ne permettrait pas de remettre plus de puissance ultérieurement, on ne peut pas trop moquer Boeing hélas.
Et là, on n'a pas l'excuse de pousser à bout un design des années 60 pour économiser sur les requis d'issues de secours actuels, entre autres…
Le pire, c'est que c'était spécifié ainsi! Quel est l'âne qui a pu faire cela? Là ou cela se situe, il doit se faire tout petit outre rhin…
Pour le planeur vs avion de ligne, c'est pas si loin selon le planeur. Si les modèles de compétition sont vers les 60 de finesse, les bois et toile classiques pour l'instruction sont plutôt dans les de 25 à 30. Un avion léger d'aéroclub sera dans les 10/15.
Et puis quand on a un pilote de ligne vélivole à ses heures perdues aux commandes, la finesse d'un avion de ligne (dans les 20) peut vous sauver la vie: https://fr.wikipedia.org/wiki/Planeur_de_Gimli
Pourtant, il y a 25 ans, une personne faisait très bien ce travail seule en plus de pas mal de TP d'enseignement: http://patrick.ducrot.free.fr
Et pour la sécurité, je me souviens encore de ses images "Wanted" balancées régulièrement sur tout le réseau de machines Unix (servant à l'enseignement) visant avec humour le seul élève ayant réussi (pas bien longtemps, juste le temps de repérer un process inconnu rapidement décortiqué) à lui piquer son login. Le petit malin avait exploité (de mémoire) une faille liée au lecteur de disquettes 5"1/4 mis à dispo des élèves pour transférer leurs sources/fichiers de leurs PC perso, pour ceux qui en avaient…
Moi je n'avais pas fait si bonne pêche, avec mon chalut lancé à la même époque côté réseau PC (sous windows 3, de mémoire, à l'époque? Ils servaient alors à la bureautique) qui avait eu a peu près tous les élèves mais pas lui: Trop prudent déjà vis à vis des produits Microsoft, je pense qu'il ne se connectait que de son bureau avec sa machine, ce qui le rendait insensible à mon exploitation de l'ancêtre des services runtime UEFI: Les interruptions BIOS qui permettaient de mettre des hooks (tel un virus de secteur de boot, capacités de réplication en moins) sur les frappes clavier (permettant de récupérer tout ce qui suivait un mot clef type "login", "telnet"…) et accès disque (pour sauver cela, à des fins de glanage ultérieur, sur des zones de HDD inutilisées/cachées à l'OS). Un article cocasse dans le canard de l'école dont je dois toujours avoir copie quelque part avait cloturé ma 3ème année, exposant les mots de passe simplistes ou tout simplement drôles.
C'est triste de voir un Microsoft pourtant en perte de vitesse (hors bureautique et cloud) noyauter ainsi l'enseignement et la recherche. Mais dans le privé c'est pareil, y compris chez LE concurrent de Boeing: S'ils veulent refaire leur retard, au moins, ils n'auront pas à faire comme les Chinois qui avaient acheté un A320 qui ne s'est ensuite jamais montré dans aucun aéroport et n'a pas été revu en vol après sa livraison.
Pourtant, tous les produits et services de Microsoft sont plus que jamais évitables.
Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
Le point qui m’intéressait, c'était que ça tourne sur un PI3, je dois dire.
Ce qui m'embêtait, c'est que c'est le serveur qui centralise, son rôle ne se limitant visiblement pas à la gestion des utilisateurs et leur "mise en relation". Ce qui fait que la visio n'est pas là, elle coincerait de toute façons sur une petite config avec un fonctionnement non pair à pair.
Mais si en prime la config est lourde c'est mort pour sortir famille/amis de zoom et autres machins troués… mais qu'un proche de 80 ans arrive à utiliser avec quelques directives simples.
Ce qui manque en fait toujours, c'est vraiment un Skype libre avec un fonctionnement d'avant son sabordage par Microsoft qui l'a tué, comme à peu près tout ce qu'ils rachètent, en le centralisant…
Pour le -fpatchable-function, on verrait une version plus générique du -finstrument-functions de gcc mais à y réfléchir un peu ça semble difficilement utilisable en comparaison, surtout dans un contexte visant plusieurs architectures avec des tailles d'instruction "nop" potentiellement différentes…
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!
Pour ma part, j'avais regardé la dépêche initiale car je recherche une solution de reco vocale hors cloud et GAFA, mais l'utilité étant sur un système domotique headless sans écran/clavier, ni environnement graphique/bureau installé… Je n'avais pas persévéré.
C'est tellement évident que nos records de température de cet été… les modèles basés sur l'effet CO2 les prévoyaient… dans 30 ans!
Alors soit ils sont archi faux et ceux qui sont payés à les affiner depuis des décennies devraient être invités à changer de métier, soit il y a d'autres facteurs bien plus conséquents à un réchauffement que personne ne conteste.
Pour l'effet sécheresse en Australie, c'est un peu comme la vitesse pour la sécurité routière: Un facteur essentiellement aggravant. De là à en éluder encore une fois ce qui cause au profit de ce qui aggrave…
Pour l'article, le fait qu'on ait laissé le bush à l'abandon et bloqué les voies d'accès c'est du factuel.
Si on fait pareil dans les Landes, le résultat est garanti en peu d'années et blâmer le réchauffement tiendra de la prophétie autoréalisatrice.
Partir sur Greta, je pense que c'était partir clivant pour ne pas dire mal. Il n'y a pas que le grand blanc (pour se la jouer verbiage banlieusard) pour regretter sa notoriété éclair et au fond trop belle pour être honnête: Son téléguidage (pas forcément conscient) par les communicants de la croissance dite verte est largement démontré.
Ces vertueux qui jugent bon de produire de l'électricité avec des éoliennes peinant à produire 20% de la puissance théorique installée, ancrées sur plusieurs milliers de T de béton qui resteront quand on décidera d'arrêter de défigurer le paysage ou que les riverains les dynamiteront lassés des nuisances… ou avec des km2 de produit de fonderie silicium hautement énergivore à la production/recyclage logiquement réservés, avant les aides mal inspirées, a l’électrification des sites isolés. Ou prônant la mobilité électrique incarnée par le succès, lui aussi largement subventionné, de la Zoé. Ou comment faire passer pour vertueuse une citadine de 1.5T, illustration d'un monde qui part vraiment cul par dessus tête!
Niveau émissions, pas mieux: Arriver à faire passer la préoccupation d'un non polluant, le CO2, devant le reste des véritables polluants et monter de toutes pièces une économie de sa taxation… Comment dire? Renvoyer aux propos d'Haroun Tazieff qui dénonçait, depuis son passage au ministère alors en charge des risques naturels (et avoir consulté ses archives), les biais voire mensonges éhontés (distrayant l'opinion des vrais problèmes) de la politique environnementale alors balbutiante?
Deux décennies après sa mort le problème s'est bien aggravé. Il avait démonté d'entrée la thèse du rôle des CFC sur la couche d'ozone, que l'on commence à peine actuellement à remettre en cause. Et pas plus cru à la fable de voir quelques centièmes de pourcent de CO2 dans l'atmosphère responsables de changements climatiques majeurs.
Mais en face, on réfléchit quand même encore. Au point de voir, en Australie puisqu'on en parle aussi, les pompiers faire des doigts d'honneur à leur politiques pour des raisons très claires qui n'ont rien à voir avec le réchauffement et qui étaient déjà exposées ici il y a 2 mois:
En résumé, poussé par les verts le gvt a abandonné et même fait en sorte de bloquer l'entretien du bush afin de le rendre impénétrable aux visiteurs pour le plus grand bonheur des animaux, allant jusqu'à bloquer définitivement les accès pompiers d'enrochements.
Résultat, 1/2 million d'animaux morts à la faveur d'épisodes de forte températures et sécheresse (qui vont souvent de pair, revoir Haroun qui démontrait déjà que le climat était bien plus lié à l'humidité dans l'air qu'a des pouillèmes de CO2) et c'est pas fini.
Mouais… Cela doit dépendre d’où l'on vient car le := me semble pour ma part plus clair.
Visiblement, les discutions ont été agitées au point de tuer le père! En arriver là, vu de dehors, ramène un peu à Sigmund.
Je me rappelle en avoir essayé quelques uns (je parlais d'ailleurs d'outils lint pour le C, désormais tombés en désuétude, j'avais naturellement cherché un équivalent), mais la richesse syntaxique de Python ne me semblait pas être ici un atout: Bien trop de faux positifs à mon goût.
Pourtant, mon usage de Python étant limité, je ne crois pas faire des trucs tordus.. Peut-être pas assez "pythonic" en fait.
En même temps, depuis 2003, les chaînes de compil ont un peu évolué niveau verbosité de warning/erreur et particulièrement pour GCC, intelligibilité.
Le C laisse beaucoup de liberté et c'est très bien ainsi car là ou il est le plus utilisé c'est soit inévitable soit s'en passer a un rapport bénéfice/risque difficilement justifiable.
Alors même si tous les 5 ans on nous annonce son successeur en mieux (dont souvent des langages objet, pourtant au final toujours exclus depuis qu'ils existent car impossible d'y gérer finement l'utilisation mémoire), je pense que c'est bien le seul langage enseigné dont on peut assurer qu'il sera encore là quand ceux qui sortent d'école d'ingé actuellement prendront leur retraite!
En même temps, c'est plus un problème sur un langage interprété.
Ça fait des lustres que les compilateurs lèvent un warning sur ce type d'erreurs sans aller vers la nécessité d'un "décodeur maître Yoda" visuel!
A ce sujet, ayant passé l'essentiel de ma vie à faire du C et ne faisant du python qu'occasionnellement (outils/test au taf ou domotique à la maison), je ne crois pas avoir vu abordé dans les dépêches les outils d'analyse syntaxiques simples et efficaces, s'il y en a, qui permettent d'éviter de ne voir les erreurs à l’exécution (et encore, si on fait en sorte de passer dans la bonne branche de code)?
Bon, ça ramènera 30 ans en arrière quand passer un coup de lint pouvait faire gagner beaucoup de temps vu les temps de compilation de l'époque… Mais si j'en avais testé quelques uns pour Python, adopté aucuns: Trop de faux positifs, configuration pénible (visant de gros projets).
Posté par lym .
En réponse à la dépêche Firefox 69 ☯.
Évalué à 3.
Flash est certes enfin dégagé quasiment à 100% du web, merci html5… Mais reste utilisé par pas mal de sites embarqués pour configurer du matériel réseau, type caméra IP.
Bon, on change pas tous les jours des config l'utilisant (type zones de détection de mouvement) alors l'activer à la demande n'est pas vraiment un problème pour ce type d'usage limité.
Par contre, ce serait bien que cela ne dégage pas totalement tout de même, histoire de ne pas devoir mettre à la poubelle du matériel fonctionnel au moindre besoin de reconfiguration. En tout cas pour ceux qui n'auront pas forcément le réflexe de garder une ancienne version et ses dépendances dans un coin de leur arborescence pour cet usage.
Mais bon, sous Linux ce serait visiblement aussi éviter Wayland ce qui ne fonctionnera qu'un temps même si pour ma part je continuerais à le faire aussi longtemps que possible: Je ne souhaite en effet pas revenir plus de 20 ans en arrière et ne pouvoir tirer une appli graphique à travers le réseau en X11 forwarding (via ssh), se retrouver à tirer un bureau complet (j'ai des machines headless sans environnement de bureau et juste une install X minimale via la version frame-buffer xvfb, ce qui apporte du confort comparé à quelques terminaux en permettant d'utiliser de l'applicatif simple comme rxvt et autres nedit d'une unique connection ssh) via un ersatz de VNC ou RDP, non merci. X a été conçu traversé par la pile réseau et a priori c'était pas trop les plans des développeurs de Wayland, ce qui était pour moi une regression incroyable tant tout le monde utilise ceci. Bon, ca a peut-être changé ceci dit, vu que la réponse il y a qq années m'avait fait en plus du tout regarder ce projet. Attitude pas sans rappeler celle du projet Gnome au passage de 2 à 3, avec les utilisateurs qui hurlaient (Cinnamon, voire Mate sur de petites configs, ont depuis résolu le problème).
Pour en revenir au sujet, côté politique extensions, cela m'a surtout affecté pour Thunderbird: Beaucoup de monde étant passé (par facilité, c'est quand même un pis-aller) au webmail, il a sans doute bcp moins d'utilisateurs que Firefox et aussi de suivi des plugins par leurs auteurs. Là j'ai du bloquer ses MAJ car je me passe assez difficilement de l'extension "attachment extractor" qui n'a pas passé la version 60, je suis donc resté en 52 (Debian = versions ESR).
C'est donc toujours dommage, en effet, de faire de la casse là dessus. Surtout quand leur variété fut un gros point fort.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.
On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.
Rien de plus simple, en fait.
Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.
Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
# Plus un problème qu'une solution...
Posté par lym . En réponse au journal Je viens de déposer plainte à la CNIL : mon retour d'expérience.. Évalué à 1. Dernière modification le 10 décembre 2020 à 13:28.
Ces messages peuvent être vus comme un progrès pour ceux qui n'utilisent pas un mode de navigation privée, voir avaient depuis la nuit des temps configuré leur navigateur (proposant ces options, tel FF) pour vider la benne à ordure des pubeux de tout ordre à extinction.
On peut aussi vider la benne en cours de session à des moments opportuns, par exemple avant de se connecter à leur banque/site de commerce avec une intention d'achat, d'un Ctrl+Shift+Suppr.
=> Ceux là, soucieux des traces laissées chez eux depuis longtemps, sont au final ceux qui sont emmerdés par ces dispositions législatives très mal pensées car ils vont devoir refaire la manip (en général au plus rapide proposé, accepter tout, sachant que finasser est conçu pour être dissuasif) à chaque re-connexion.
Pour réconcilier tout le monde, ce type de disposition aurait dû être faite sur le mode du "do not track", voir en rendant ce dernier (pré-existant) équivalent à un "ne rien accepter" exclusif de tout questionnement et indépendant du vidage de la benne à cookie et données de sites diverses et avariées.
Comme avec bloctel (il eu mieux valu faire une chose très simple: Redonner un coût obligatoire aux appels vers fixe en faisant un illimité en mode mobile: Peu probable d'y arriver en usage individuel, par contre pas vraiment pour un centre d'appel) qui semble vous ramener plus d'appels qu'en éviter, nous sommes dans un pays qui aime faire des usines à gaz finissant à l'inverse du but visé.
# Et enfin un vrai switch/case...
Posté par lym . En réponse à la dépêche Python 3.9 est disponible. Évalué à 0.
Pour éviter les bidouilles!
On pourrait ajouter les variables static (là aussi, on peut bidouiller), facilitant l'utilisation purement procédurale du langage…
Bin non? Pour le 4.0 peut-être?!
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 1.
Les outils d'analyse de code C permettent en effet de compenser les avantages de conception de Rust, en évitant en prime de devoir cumuler (au niveau logiciel de base) la complexité de la machine (un processeur/SoC actuel) avec celle du langage (devoir en particulier en permanence s'embêter avec les problèmes d'appartenance).
Je n'ai pas étudié l'affaire de très près, ceci dit, mais vu de haut je vois plus Rust utile côté applicatif que pour coder un système d'exploitation voir ses modules/drivers.
Ce ne serait pas le 1er challenger du C de l'histoire à échouer!
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 3.
Il y a des tas de choses à bas niveau qui sont propres à chaque architecture et qui n'ont pas leur place dans des langages de haut niveau, même ceux qui permettent déjà beaucoup de choses comme le C.
Sans même parler du strict démarrage (va appeler du C sans avoir initialisé une pile, donc une RAM qui est souvent un bout de mémoire cache plateforme dévoyé le temps de la complexe initialisation DDR!), niveau OS, toutes les primitives bas niveau touchant à la mémoire cache justement, la mémoire virtuelle, préfixes/postfixes d'interruptions, opérations atomiques (test&set)…
Cela ne représente plus grand chose (on n'écrit donc pas vraiment un OS en asm), même s'il y en a quand même de planqué ailleurs (sous forme d'asm inline) que dans des fichiers complets, mais c'est la portion inévitable.
[^] # Re: Tu n'as vraiment pas de chance
Posté par lym . En réponse au journal Ivre, il tente de réinstaller Windows, ça tourne mal. Évalué à 0.
En effet, mes 2 dernières installations:
-Un laptop perso acheté d'occase livré avec un Win10 home refurb sur un BIOS reconfiguré en legacy… mais qui repassé en UEFI, avait encore la clef 10 pro de la version constructeur bien au chaud… avant de lui mettre un double boot Debian.
-Puis une machine labo au taf, avec la clef de licence win7 pro OEM de l'étiquette (bouffée sans pb par l'installeur de 10: Ils ne veulent vraiment plus le vendre!), pour des softs d'analyseur logique, l'horreur Visual eBios d'AMI qui n'avait aucune chance de me réconcilier avec le patchwork Eclipse etc… dont les versions Linux ne sont hélas pas stables (Salae, si tu m'entends…).
Et franchement même réflexion: Zéro problème, fini la litanie d'une demi journée de reboot d'application séquentielle de tous les patchs mensuels depuis la sortie de la dernière ISO. Juste à ruser pour éviter le compte en ligne microsoft et se taper le moins de traceurs (télémétrie en novlangue microsoft) possible.
Au final, on arrive à avoir un système (certes moins complet on n'a pas une suite bureautique etc) qu'un Linux dans un temps à peine 2x supérieur à mon top chrono: La Debian Netinstall, qui charge direct tout un système à jour.
Franchement, cela me semble devenu très correct même si je n'apprécie pas win10 et ne l'utilise que dans des cas contraints (et toujours avec un Cygwin pour le rendre supportable).
[^] # Re: À voir en vrai
Posté par lym . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 5.
Il faut dire qu'utiliser un clone Red-Hat ne se justifie vraiment que pour avoir une version d'OS homogène sur un parc matériel qui va forcément diverger sur les 10 ans de support assuré: Là, avoir Red-Hat qui se tape le boulot de backport du support du nouveau matériel arrivant en flux continu sur un kernel antédiluvien peut avoir une utilité.
Mais la contrepartie, c'est quand même des dépôts qui sont un vide absolu comparé à la richesse côté Debian. Les premiers mois/années, on peut au moins recompiler de manière a peu près fiable ce qui manque soit-même (pour éviter les acrobaties avec les dépôts de la Fée-Dora, sport de masse sous RH) mais cela se gâte très vite.
Pour ma part, entre la gestion de paquets inférieure (en disponibilité et à l'usage) et le cycle AMHA trop long, j'ai toujours trouvé que Debian offrait un meilleur compromis stabilité/nouveauté.
Scientific-Linux devenu un CentOS, après que RH ait déjà savonné la planche aux coucous d'Oracle, les jours de la "RH du pauvre" semblaient comptés. Car le débouché entre Fée-Dora et RH semble pour le moins limité.
[^] # Re: Config
Posté par lym . En réponse à la dépêche Sortie de TIC‑80 version 0.80 . Évalué à 1. Dernière modification le 05 novembre 2020 à 16:52.
J'ai toujours mon EeePC901 avec son Atom 1er du nom si "poussif", actuellement avec une Debian 10 et bureau Mate qui n'est pas le plus léger qui soit. Ca reste utilisable. La seule modif avait été de lui payer une barrette de 2GB à la place de celle d'1GB d'origine (+, sans impact ici, carte wifi Ubiquity plus sensible que l'originale et pouvant cracher très au dessus des 100mW autorisés, import US oblige, qui accrochait sans problème des points d'accès à 500m, malgré les antennes internes, en vacances avant la baisse des forfaits data mobiles).
Pour le jeu, pas mal de jeux Linux un peu anciens tournent sans problème… d'encore plus anciens portages, type Doom, également: C'est pas neuf, mais ça reste d'un autre niveau qu'animer des sprites comme sur un Amstrad ou Commodore des années 80 tout de même.
Là si c'est un problème, c'est pas l'Atom qu'il faut blâmer!
Le plus incroyable avec cette petite machine comme on n'en fait hélas plus: Son autonomie, avec une batterie d'origine chargeant encore à 85% de sa capacité théorique. Du Asus de la décennie 2000, en résumé, même pour ce modèle alors low-cost.
# Autre exemple...
Posté par lym . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 5.
Quand on voit qu'un A400M tout frais sorti de l'assemblage a été perdu (tuant l'équipage d'essai) car le FADEC (contrôle moteur), si des calibrations hélice manquaient, était capable d'accepter la puissance maximale au décollage mais qu'ensuite chaque réduction ne permettrait pas de remettre plus de puissance ultérieurement, on ne peut pas trop moquer Boeing hélas.
Et là, on n'a pas l'excuse de pousser à bout un design des années 60 pour économiser sur les requis d'issues de secours actuels, entre autres…
Le pire, c'est que c'était spécifié ainsi! Quel est l'âne qui a pu faire cela? Là ou cela se situe, il doit se faire tout petit outre rhin…
[^] # Re: A propos du Boeing 737.
Posté par lym . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 6.
Pour le planeur vs avion de ligne, c'est pas si loin selon le planeur. Si les modèles de compétition sont vers les 60 de finesse, les bois et toile classiques pour l'instruction sont plutôt dans les de 25 à 30. Un avion léger d'aéroclub sera dans les 10/15.
Et puis quand on a un pilote de ligne vélivole à ses heures perdues aux commandes, la finesse d'un avion de ligne (dans les 20) peut vous sauver la vie:
https://fr.wikipedia.org/wiki/Planeur_de_Gimli
[^] # Re: Un exemple du quotidien
Posté par lym . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 9.
Pourtant, il y a 25 ans, une personne faisait très bien ce travail seule en plus de pas mal de TP d'enseignement:
http://patrick.ducrot.free.fr
Et pour la sécurité, je me souviens encore de ses images "Wanted" balancées régulièrement sur tout le réseau de machines Unix (servant à l'enseignement) visant avec humour le seul élève ayant réussi (pas bien longtemps, juste le temps de repérer un process inconnu rapidement décortiqué) à lui piquer son login. Le petit malin avait exploité (de mémoire) une faille liée au lecteur de disquettes 5"1/4 mis à dispo des élèves pour transférer leurs sources/fichiers de leurs PC perso, pour ceux qui en avaient…
Moi je n'avais pas fait si bonne pêche, avec mon chalut lancé à la même époque côté réseau PC (sous windows 3, de mémoire, à l'époque? Ils servaient alors à la bureautique) qui avait eu a peu près tous les élèves mais pas lui: Trop prudent déjà vis à vis des produits Microsoft, je pense qu'il ne se connectait que de son bureau avec sa machine, ce qui le rendait insensible à mon exploitation de l'ancêtre des services runtime UEFI: Les interruptions BIOS qui permettaient de mettre des hooks (tel un virus de secteur de boot, capacités de réplication en moins) sur les frappes clavier (permettant de récupérer tout ce qui suivait un mot clef type "login", "telnet"…) et accès disque (pour sauver cela, à des fins de glanage ultérieur, sur des zones de HDD inutilisées/cachées à l'OS). Un article cocasse dans le canard de l'école dont je dois toujours avoir copie quelque part avait cloturé ma 3ème année, exposant les mots de passe simplistes ou tout simplement drôles.
C'est triste de voir un Microsoft pourtant en perte de vitesse (hors bureautique et cloud) noyauter ainsi l'enseignement et la recherche. Mais dans le privé c'est pareil, y compris chez LE concurrent de Boeing: S'ils veulent refaire leur retard, au moins, ils n'auront pas à faire comme les Chinois qui avaient acheté un A320 qui ne s'est ensuite jamais montré dans aucun aéroport et n'a pas été revu en vol après sa livraison.
Pourtant, tous les produits et services de Microsoft sont plus que jamais évitables.
[^] # Re: Congrats
Posté par lym . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 0.
Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
[^] # Re: Accessibilité
Posté par lym . En réponse à la dépêche Audio‑conférences en ligne avec Mumble. Évalué à -1.
Le point qui m’intéressait, c'était que ça tourne sur un PI3, je dois dire.
Ce qui m'embêtait, c'est que c'est le serveur qui centralise, son rôle ne se limitant visiblement pas à la gestion des utilisateurs et leur "mise en relation". Ce qui fait que la visio n'est pas là, elle coincerait de toute façons sur une petite config avec un fonctionnement non pair à pair.
Mais si en prime la config est lourde c'est mort pour sortir famille/amis de zoom et autres machins troués… mais qu'un proche de 80 ans arrive à utiliser avec quelques directives simples.
Ce qui manque en fait toujours, c'est vraiment un Skype libre avec un fonctionnement d'avant son sabordage par Microsoft qui l'a tué, comme à peu près tout ce qu'ils rachètent, en le centralisant…
# Patch
Posté par lym . En réponse au journal Sortie de LLVM 10.0.0. Évalué à 0.
Pour le -fpatchable-function, on verrait une version plus générique du -finstrument-functions de gcc mais à y réfléchir un peu ça semble difficilement utilisable en comparaison, surtout dans un contexte visant plusieurs architectures avec des tailles d'instruction "nop" potentiellement différentes…
[^] # Re: Comble un manque...
Posté par lym . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 0.
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
# Comble un manque...
Posté par lym . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 0.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!
# Env graphique requis
Posté par lym . En réponse à la dépêche NoComprendo, version 1.0. Évalué à 2.
Pour ma part, j'avais regardé la dépêche initiale car je recherche une solution de reco vocale hors cloud et GAFA, mais l'utilité étant sur un système domotique headless sans écran/clavier, ni environnement graphique/bureau installé… Je n'avais pas persévéré.
[^] # Re: Mouais...
Posté par lym . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à -3.
C'est tellement évident que nos records de température de cet été… les modèles basés sur l'effet CO2 les prévoyaient… dans 30 ans!
Alors soit ils sont archi faux et ceux qui sont payés à les affiner depuis des décennies devraient être invités à changer de métier, soit il y a d'autres facteurs bien plus conséquents à un réchauffement que personne ne conteste.
Pour l'effet sécheresse en Australie, c'est un peu comme la vitesse pour la sécurité routière: Un facteur essentiellement aggravant. De là à en éluder encore une fois ce qui cause au profit de ce qui aggrave…
Pour l'article, le fait qu'on ait laissé le bush à l'abandon et bloqué les voies d'accès c'est du factuel.
Si on fait pareil dans les Landes, le résultat est garanti en peu d'années et blâmer le réchauffement tiendra de la prophétie autoréalisatrice.
# Mouais...
Posté par lym . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à -2.
Partir sur Greta, je pense que c'était partir clivant pour ne pas dire mal. Il n'y a pas que le grand blanc (pour se la jouer verbiage banlieusard) pour regretter sa notoriété éclair et au fond trop belle pour être honnête: Son téléguidage (pas forcément conscient) par les communicants de la croissance dite verte est largement démontré.
Ces vertueux qui jugent bon de produire de l'électricité avec des éoliennes peinant à produire 20% de la puissance théorique installée, ancrées sur plusieurs milliers de T de béton qui resteront quand on décidera d'arrêter de défigurer le paysage ou que les riverains les dynamiteront lassés des nuisances… ou avec des km2 de produit de fonderie silicium hautement énergivore à la production/recyclage logiquement réservés, avant les aides mal inspirées, a l’électrification des sites isolés. Ou prônant la mobilité électrique incarnée par le succès, lui aussi largement subventionné, de la Zoé. Ou comment faire passer pour vertueuse une citadine de 1.5T, illustration d'un monde qui part vraiment cul par dessus tête!
Niveau émissions, pas mieux: Arriver à faire passer la préoccupation d'un non polluant, le CO2, devant le reste des véritables polluants et monter de toutes pièces une économie de sa taxation… Comment dire? Renvoyer aux propos d'Haroun Tazieff qui dénonçait, depuis son passage au ministère alors en charge des risques naturels (et avoir consulté ses archives), les biais voire mensonges éhontés (distrayant l'opinion des vrais problèmes) de la politique environnementale alors balbutiante?
Deux décennies après sa mort le problème s'est bien aggravé. Il avait démonté d'entrée la thèse du rôle des CFC sur la couche d'ozone, que l'on commence à peine actuellement à remettre en cause. Et pas plus cru à la fable de voir quelques centièmes de pourcent de CO2 dans l'atmosphère responsables de changements climatiques majeurs.
Mais en face, on réfléchit quand même encore. Au point de voir, en Australie puisqu'on en parle aussi, les pompiers faire des doigts d'honneur à leur politiques pour des raisons très claires qui n'ont rien à voir avec le réchauffement et qui étaient déjà exposées ici il y a 2 mois:
https://volunteerfirefighters.org.au/it-is-high-time-bureaucrats-and-politicians-stopped-blaming-climate-change-for-a-bushfire-crisis-that-is-very-much-of-their-own-making-and-is-putting-lives-at-risk
En résumé, poussé par les verts le gvt a abandonné et même fait en sorte de bloquer l'entretien du bush afin de le rendre impénétrable aux visiteurs pour le plus grand bonheur des animaux, allant jusqu'à bloquer définitivement les accès pompiers d'enrochements.
Résultat, 1/2 million d'animaux morts à la faveur d'épisodes de forte températures et sécheresse (qui vont souvent de pair, revoir Haroun qui démontrait déjà que le climat était bien plus lié à l'humidité dans l'air qu'a des pouillèmes de CO2) et c'est pas fini.
[^] # Re: Python se rapproche du Perl ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 2.
Mouais… Cela doit dépendre d’où l'on vient car le := me semble pour ma part plus clair.
Visiblement, les discutions ont été agitées au point de tuer le père! En arriver là, vu de dehors, ramène un peu à Sigmund.
[^] # Re: Yoda ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 1. Dernière modification le 18 octobre 2019 à 14:12.
Je me rappelle en avoir essayé quelques uns (je parlais d'ailleurs d'outils lint pour le C, désormais tombés en désuétude, j'avais naturellement cherché un équivalent), mais la richesse syntaxique de Python ne me semblait pas être ici un atout: Bien trop de faux positifs à mon goût.
Pourtant, mon usage de Python étant limité, je ne crois pas faire des trucs tordus.. Peut-être pas assez "pythonic" en fait.
[^] # Re: Yoda ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 4. Dernière modification le 18 octobre 2019 à 14:00.
En même temps, depuis 2003, les chaînes de compil ont un peu évolué niveau verbosité de warning/erreur et particulièrement pour GCC, intelligibilité.
Le C laisse beaucoup de liberté et c'est très bien ainsi car là ou il est le plus utilisé c'est soit inévitable soit s'en passer a un rapport bénéfice/risque difficilement justifiable.
Alors même si tous les 5 ans on nous annonce son successeur en mieux (dont souvent des langages objet, pourtant au final toujours exclus depuis qu'ils existent car impossible d'y gérer finement l'utilisation mémoire), je pense que c'est bien le seul langage enseigné dont on peut assurer qu'il sera encore là quand ceux qui sortent d'école d'ingé actuellement prendront leur retraite!
[^] # Re: Yoda ?
Posté par lym . En réponse à la dépêche Python 3.8 : opérateur d’assignation, REPL async, Pickle v5 et plus. Évalué à 2.
En même temps, c'est plus un problème sur un langage interprété.
Ça fait des lustres que les compilateurs lèvent un warning sur ce type d'erreurs sans aller vers la nécessité d'un "décodeur maître Yoda" visuel!
A ce sujet, ayant passé l'essentiel de ma vie à faire du C et ne faisant du python qu'occasionnellement (outils/test au taf ou domotique à la maison), je ne crois pas avoir vu abordé dans les dépêches les outils d'analyse syntaxiques simples et efficaces, s'il y en a, qui permettent d'éviter de ne voir les erreurs à l’exécution (et encore, si on fait en sorte de passer dans la bonne branche de code)?
Bon, ça ramènera 30 ans en arrière quand passer un coup de lint pouvait faire gagner beaucoup de temps vu les temps de compilation de l'époque… Mais si j'en avais testé quelques uns pour Python, adopté aucuns: Trop de faux positifs, configuration pénible (visant de gros projets).
[^] # Re: la version Wayland de Firefox ne prend pas en charge Flash
Posté par lym . En réponse à la dépêche Firefox 69 ☯. Évalué à 3.
Flash est certes enfin dégagé quasiment à 100% du web, merci html5… Mais reste utilisé par pas mal de sites embarqués pour configurer du matériel réseau, type caméra IP.
Bon, on change pas tous les jours des config l'utilisant (type zones de détection de mouvement) alors l'activer à la demande n'est pas vraiment un problème pour ce type d'usage limité.
Par contre, ce serait bien que cela ne dégage pas totalement tout de même, histoire de ne pas devoir mettre à la poubelle du matériel fonctionnel au moindre besoin de reconfiguration. En tout cas pour ceux qui n'auront pas forcément le réflexe de garder une ancienne version et ses dépendances dans un coin de leur arborescence pour cet usage.
Mais bon, sous Linux ce serait visiblement aussi éviter Wayland ce qui ne fonctionnera qu'un temps même si pour ma part je continuerais à le faire aussi longtemps que possible: Je ne souhaite en effet pas revenir plus de 20 ans en arrière et ne pouvoir tirer une appli graphique à travers le réseau en X11 forwarding (via ssh), se retrouver à tirer un bureau complet (j'ai des machines headless sans environnement de bureau et juste une install X minimale via la version frame-buffer xvfb, ce qui apporte du confort comparé à quelques terminaux en permettant d'utiliser de l'applicatif simple comme rxvt et autres nedit d'une unique connection ssh) via un ersatz de VNC ou RDP, non merci. X a été conçu traversé par la pile réseau et a priori c'était pas trop les plans des développeurs de Wayland, ce qui était pour moi une regression incroyable tant tout le monde utilise ceci. Bon, ca a peut-être changé ceci dit, vu que la réponse il y a qq années m'avait fait en plus du tout regarder ce projet. Attitude pas sans rappeler celle du projet Gnome au passage de 2 à 3, avec les utilisateurs qui hurlaient (Cinnamon, voire Mate sur de petites configs, ont depuis résolu le problème).
Pour en revenir au sujet, côté politique extensions, cela m'a surtout affecté pour Thunderbird: Beaucoup de monde étant passé (par facilité, c'est quand même un pis-aller) au webmail, il a sans doute bcp moins d'utilisateurs que Firefox et aussi de suivi des plugins par leurs auteurs. Là j'ai du bloquer ses MAJ car je me passe assez difficilement de l'extension "attachment extractor" qui n'a pas passé la version 60, je suis donc resté en 52 (Debian = versions ESR).
C'est donc toujours dommage, en effet, de faire de la casse là dessus. Surtout quand leur variété fut un gros point fort.
[^] # Re: Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.
[^] # Re: Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.
Rien de plus simple, en fait.
Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.
Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…