totof2000 a écrit 9656 commentaires

Vous pourriez ammener les commentaires avec, c'est pénible de scinder les discussions comme ça (d'autant plus que les discussions qui en ont suivi ont été très intéressantes).

J'ai entendu dire que le bon langage pour tenir compte de ce genre de contrainte s'appelle Ada.

Oui.

J'ai encore jamais pris le temps ni l'énergie de m'y mettre, mais je suis persuadé que si je dois écrire un programme "sur", c'est vers lui que le me tournerai.

C'est clair. Pour ma part je m'y suis intéressé. C'est un langage assez verbeux et l'appretissage est difficile. Il faut être précis sur tout, et ce langage confirme une généralité : faire les choses très bien et de façon sure, ça coûte. Et je suis certain qu'écrire un programme en ADA, même pour un expert du langage, ça coûte plus cher que d'écrire le même langage en Java (pour le c++ je sais pas : je serais d'avis, mais je peux me tromper, qu'écrire un soft en C++ prend autant de temps et d'énergie que de l'écrire en ADA, avec plus de risque de retrouver des bugs à la fin du développement parce que le langage n'est pas aussi "strict" qu'Ada). Par contre on est sur de ne pas rencontrer tout un tas de bugs qu'on pourrait rencontrer dans d'autres langages, et la maintenance est facilitée.

Pour ce que j'en ai vu, Rust me parait un bon compromis pour écrire des programmes plus sûrs qu'en C ou en C++, sans tomber dans le côté extrême d'Ada. Mais comme je ne suis pas expert dans le domaine, je peux me tromper (et je suis preneur de tout avis qui m'expliquerait en quoi je me trompe).

C'est quand même affolant d'avoir ce genre de comportement dans un langage de programmation. Mais bon, c'est Pytho, langage incohérent comme pas possible.

Pour ma part, quand il faut récupérer un disque défectueux, je préfère passer par dd-rescue.

Au contraire, les langages interprétés décuplent le potentiel de méta-programmation et le modèle sur lequel s'appuie python est super simple et bien fichu.

Non, il est très limité comparé à Ruby. A chaque fois que j'essaie de jouer avec la méta-programmation en Python, je me trouve a devoir essayer de trouver un moyen de contourner les limites stupides et arbitraires du langage.

Personnellement je préfère la philosophie de Ruby "qui consiste à aider
l’utilisateur lorsqu’il a besoin d’assistance et à s’effacer en toute autre circonstance" (Russ Olsen : Les designs patterns en Ruby).

j'ai bien noté qui ici fait du python bashing intensif

Pour ma part je me suis abstenu, j'avais pas envie de rentrer dans ce débat mais cette phrase de ta part m'a incité à intervenir.

Il te semble bien :)

Ben juste parce que le mec qui a fait ça avant il est mauvais. Le nouveau développeur qui a réussi son stage de fn d'année réussira mieux que le dino qui a écrit tout ça avant lui. LEs nouveautés du langage lui permettront de simplifier et de mieux faire marcher le code.

Cette mode de réparer ce qui marche, surtout dans le monde du libre me gave depuis des années. Je me dis parfois que le code payant a du bon : au moins on réinvente pas la roue tous les 6 mois parce qu'un pneu est dégonflé.

Bof faut voir, ça sediscute …
Une application qui ne sert pas a grand chose ne sera pas forcément très sollicitée, donc ne consommera pas tant de cycle CPU que ça. En tout cas, moins qu'une application beaucoup utilisée, qui consomme beaucoup de cycle CPU dans tous les cas, mais qui en consomme encore plus parce que le langage ou le framework sur lequel elle a été développé en a rajouté encore plus.

Pour moi du coup, l'embarqué sera sans doute le dernier domaine avec la conception d'un OS où le C restera pertinent encore longtemps.

Pour ma part je pense que parmi tous les langages que j'ai vu, rust est probablement le seul qui pourrait un jour remplacer le C dans l'embarqué. Le langage est encore jeune, mais si ses concepteurs font les bons choix, on pourrait avoir un langage intéressant. Pour moi, et pour ce que j'en vois, le potentiel est là.

Bof il n'y a pas que les erreurs de typage qui posent problème. Il y en a bien d'autres que Rust permet de compenser. Et ce que je dis pour python/rust est valable aussi pour C/rust par exemple.

Vu qu'il faut pouvoir analyser un dossier et son contenu, il faudra peut-être y ajouter find s'il y a des sous-dossiers dans le dossier.

Et puis, soit disant "techno". Je ne vois pas en quoi le nouveau langage bidule ou la nouvelle API machin révolutionne mon monde. Ah si, ça va ajouter un overhead ici ou là, merci pour les perfs …

Je ne sais pas si tu l'as fait, mais jette un oeil sur Rust. Pour ma part, sans être dev pro, je me suis intéressé à pas mal de langage. Parmi les langages que j'apprécie particulièrement il y a Ruby, Erlang et Rust que j'ai découvert il y a relativement peu de temps.

rust devrait te plaire, car l'objectif du langange n'est pas de tester des concepts nouveaux et 'hype', mais plutôt d'utiliser des concepts ayant fait leurs preuves dans un langage reativement moderne.

L'une des caractéristiques de Rust est de tester plein de choses à la compilation, et de remonter plein de problèmes à ce niveau, un peu comme Ada. Cependant il est beaucoup moins verbeux et prise de tête que ce dernier.

Personnellement, j'ai mis un peu de temps à m'y mettre mais au final c'est un langage que j'apprécie.

Certes il est jeune, et certaines choses ne sont pas complètement matures, mais la version 1 est déjà pleinement utilisable. J'espère que ce langage fera ses preuves et sera adopté rapidement.

Le grand avantage, c'est qu'on n'a pas d'erreur au runtime, donc on gagne du temps là-dessus.

Je pense que tu as mis le doigt sur la grande différence entre les deux méthodes de développement.

En Rust par exemple, tu vois un tas de problème en amont, qui certes te ralentissent un peu pour fournir une fonctionnalité, mais d'un autre côté, quand tu fournis cette fonctionnalité, tu sais que tu t'évites un tas de bugs. D'un autre tu peux fournir un truc rapide mais il va certainement devoir revenir dessus pour fiabiliser le code. Je ne suis pas sur qu'au final, développer en RUST te fgasse perdre tant de temps que ça.

Il faut quand même se préparer à un changement sur ce point avec l'arrivée de green IT. Parce qu'utiliser un langage peu performant qui consomme des cycles CPU (donc de l'energie) pour rien, c'est pas très écolo.

Alors je ne sais pas si green IT c'est juste un truc a la mode ou si ça va réellement prendre un jour, mais si ça prend, il va falloir penser à revoir certaines archis, et à revoir les habitudes de développement du style "si ça rame, on change de matos".

Après je suis peut-être pessimiste, mais j'ai l'impression que l'ère du hardware pas cher va bientôt cesser. Exemple: le prix de la RAM qui a flambé depuis quelques années suite à la pénurie liée aux besoins de RAM pour les smartphones. Le fait que ce atériel est conçu avec des matériaux rares, n'arrange pas les choses (combien de temps pourrons-nous tenir le rythme actuel). Ces matériaux sont semble-t-il détenus en grande partie par la Chine (je crois avoir lu qu'elle en possédait environs la moitié), et la guerre commerciale US-Chine risque de ne pas arranger les choses.

Donc je pense que dans peu de temps, les devs capable d'écrire des programmes consommant peu de ressources (hardware et énergie) seront de plus en plus recherchés.

Un dinosaure de l'informatique (ta boîte pas toi) voit la mode de l'Agile et se dit "tout le monde fait ça, il faut faire pareil". Alors ils collent le mot Agile sur tout et n'importe quoi.

A mon avis c'est comme ça pour plus de la moitié des boites qui disent être agiles : pour elles lorsqu'elles ontpassé le délai de mise à disposition d'une nouvelle appli de 6 mois à 4 mis, elles peuvent se prétendre agile.

il faudrait lancer un terminal, brancher le disque et exécuter la commande dmesg.

Si tu peux fais un copier/coller ici des 10 dernières lignes.

Normalement si le disque est physiquement détecté par le noyau tu devria svoir des logs contenant un truc avec sd dedans.

La réassignation de blocs est e semble-t-il automatique quand tu écris un bloc défectueux. Si ça ne fonctionne pas, c'est peut-être parce que ton disque ne dispose plus de blocs libres pour le faire. La comande smartctl devrait te fournir plus d'infos (fais une recherche sur le net, je n'ai plus les infos en tête, ça fait longtemps que je ne l'ai plus fait). Sinon essaie d'utiliser l'utilitaire fourni par le constructeur de disque. J'ai déjà réussi à réassigner des blocs de cette façon par le passé, là ou d'autres façons de faire ont échoué. Celà dit, même si tu arrives à réallouer des blocs, , je te déconseille d'utiliser ce disque pour stocker des données sensibles.

Ben oui, Git ne gère que le code source. Il simplifie les choses, mais ne résout pas tout les problèmes. Tant que les structures impactées par les modifications restent les mêmes d'unebranche à l'autre ça pose pas problème, mais quand les projets commencent à diverger, ça devient plus compliqué.

https://lecrabeinfo.net/verifier-etat-de-sante-tester-secteurs-defectueux-disque-dur-ssd-sur-linux.html

Avec ça tu devrais voir si des blocs défectueux sont détetés.

Je sais que tu as lancé la commande badblock, mais uniquement sur /dev/sda1. Tu devrais la retenter sur tout le disque. Je soupçonne que les blocs défectueux ne soient pas sur la partition, mais sur une zone au début du disque, là ou est écrit la table de partitions par exemple (et l'erreur n'est peut-être pas à l'écriture mais à la lecture de cette zone).

Sinon tente une analyse avec l'utiitaire de maintenance fourni par le constructeur. Par le passé il m'est arrivé de détecter des problèmes qui ne l'étaient pas autrement.

Si tu as des données à récupérer, tu pourras le tenter via ddrescue. Pour ma part, j'ai réussi à récupérer mes données dans plus de 95% des cas en utilisant cet utilitaire (mais il faut un peu de patience).

Sinon jette un oeil sur ce billet que je trouve intéressant.

L'intéret du noyau LTS n'est pas pour les distributions "grand public" mais plutôt pour les entreprises qui développent des produits basés sur ledit noyau. Ca leur permet par exemple, de ne pas sortir un produit obsolète avant même qu'il ne soit sur le marché.

Maintenant, l'idée de faire évoluer/maintenir un noyau LTS en partenariat avec les distribs est en théorie intéressante. En pratique, ça pourrait être complioqué : c'est toujours difficile de maintenir plusieurs branches parallèles d'un même produit. Sans ajouter de nouvelles fonctionnalités à un ancien noyau, backporter ne serait-ce que les bugs ou un pilote de périphérique (parce que comme dit plus haut, pour une distribution, avoirt un noyau qui ne supporte pas les nouveaux périphériques grand public ça sert pas à grand chose), c'est très difficile (j'ai bossé les deux dernières années dans le développement de trucs bien moins complexes qu'un noyau, mais gérer ne serait-ce que les deux dertnières versions majeures d'un produit pour assurer une certaine stabilité à la prod est une grosse galère).

Bah, tout le monde sait que ce n'est pas une vraie moto.

Bah, poour ma party je pense que la section lien est en train de tuer linuxfr.

Et toi, lecteur, lectrice, comment gères-tu les relations avec les commerciaux sur les aspects techniques ?

Ben je ne gère pas avec les commerciaux, je demande à parler avec un techos. Après je n'ai jamais eu affaire à un FAI, mais à des fournisseurs de matériel informatique.

Ca me semble contre productif d'aborder les modeles de données par les files, les listes chainées et les structures alors qu'on a la possibilité d'attaquer avec des trucs (genre les tableaux PHP) qui sont générique et qui permettent d'assimiler le concept d'un array_map, d'un foreach etc.

Ben non, moi ça me parait tout sauf contre-productif. quand une personne n'y connait rien, la noyer avec un objet qui fait tout en même temps, ça n'aide pas. Et a mon avis, le but n'est pas de voire les files pour les files (ou les piles pour les piles), mais plus un moyen d'impleémenter des patterns assez simple pour apprendre.

Globalement, cela manque de juridique : pb des brevet, copyright, droit des base de données, RGPD.

Bof c'est pas forcément le but de la formation, cependant, une sensibilisation à la protection des données et à la vie privée serait intéressante.

Cela manque aussi d'un point de vue de plus haut niveau économique pour expliquer le concept de plateforme (amazon, apple store), l'uberisation, et la publicité ciblée.

C'est clairement pas le but de la formation.