freem a écrit 5059 commentaires

Mais beaucoup de personnes qui aiment leur moto ou automobile vont te dire que c'est insuffisant tout ça. Il faut savoir faire sa vidange comme un grand, changer ses plaquettes, ses pneus, etc.

Pour info, je déteste la mécanique auto, mais je sais changer une route, faire une vidange, changer des plaquettes, des disques, des pneus (oui, garder la roue mais changer un pneu), changer un pot, et j'ai même changé une barre de direction.

La voiture étant un outil de travail indispensable (comme l'ordinateur de nos jours) il est normal de savoir faire un minimum de maintenance, surtout si l'on n'est pas fortuné.

Nous vivons dans une société, l'intérêt de la vie en société c'est justement de pouvoir se spécialiser pour aller plus loin ensemble que d'être juste des groupes de débrouillards qui savent faire des choses plus large mais souvent moins bien (car pas le temps ou les ressources de bien se spécialiser en tout).

Sauf que ce sont les débrouillards, les touche à tout, qui vont être capables de faire la colle entre les spécialistes. Ce sont aussi les débrouillards qui vont être capables de penser différemment et de trouver des solutions originales, simples, et maintenables, parce qu'ils auront connu différents métiers et pratiqué des méthodes radicalement différentes de travail.
Je ne dis pas que les spécialistes ne sont pas nécessaires, mais sans ton médecin généraliste, tu serais bien dans la merde pour savoir quel spécialiste aller voir.

Pour ce qui est des liens, franchement… si le lien n'a aucun commentaire, il est super rare que j'aille faire l'effort d'aller le lire, le risque de perte de temps est trop élevé. Pour les journaux on a au moins quelques lignes, ça indique un peu plus le sujet, c'est utile, ça peut donner envie (ou pas). Et j'inclue les journaux les journaux bookmark: je les trouve mille fois préférables à la tétrachiée de liens surtout politiques et complètement hors sujet (alors que, bon, ils sont censés, je crois, entrer dans la ligne éditoriale: FAIL). Du coup pour moi ça montre plus les tendances politiques et "à la va-vite" du lectorat qu'une réelle pertinence. Et puis de toute façon, on s'en fout un peu du score, non? On sait tous que ça ça ne faut que que très rarement quelque chose.

PS: le délai d'édition est quand quand même un poil court.

Vu que les liens sont censés suivre la ligne éditoriale du site (cf le réglement qui n'est pas suivi du tout et la modération qui ne les modère pas) il me semble évident qu'un lien dont le titre mentionne le mariage pour tous, la montés du faschisme, les âneries de macron sans rapport avec le LL, etc etc… qu'on puisse le moinsser sans lire.
Le plusser, par contre, effectivement c'est douteux.
Il y a aussi, bien entendu, le cas des doublons et des spams évidents.

Je n'ai pas d'avis en ce qui concerne les journaux.

autrement dit, la clé sera soudée à l'ordinateur.

Franchement à l'usage, ce n'est pas ce que je constate. Bon, dans mon cas, c'est une carte à puce, qui sert aussi à ouvrir des portes, mais justement: une carte à puce ça ne dépasse quasiment pas de la machine, et la partie qui dépasse, on s'en fiche un peu.

Et pourtant sur les sites ou j'interviens, la majorité des gens récupèrent la carte quand ils s'absentent. C'est bien plus pratique que de devoir verrouiller sa session à la main, et devoir taper un code à rallonge pour se relog, je pense que ça aide pas mal (la carte nécessite un code pin bien entendu, mais c'est très court et se tape en 2s).

Je ne dis pas que personne ne laisse la carte dans la machine en ma présence, mais en même temps je suis tout le temps amené à manipuler la session des utilisateurs (tech support), donc si biais il y a, il serait plutôt en faveur que les gens vont laisser la carte si je suis dans le bureau que l'inverse.

Après, il ne s'agit que de mon expérience personnelle, bien sûr, et vu que je suis backup, ok je vois plusieurs sites, mais je peux difficilement prétendre avoir une vision précise de chaque site. A prendre avec les pincettes qui vont bien quoi, de la même manière que n'importe quelle supposition ou affirmation dans le vent :)

J'aurai cru qu'il serait possible de demander au TPM d'accéder à la carte à puce, justement? J'ai bien une machine avec un tel système pour le taf, mais bon, c'est pour le taf, j'ai pas le droit de bricoler dessus :)

En fait le cas de la STL est plutôt intéressant je trouve. A l'origine, c'était effectivement "tout dans les méthodes", "parce que les class c'est la classe". Bon, j'exagère peut-être un peu, mais probablement pas tant que ça. Voir par exemple std::string qui est selon moi une très mauvaise interface.

Hors, de nos jours l'idée est plutôt d'utiliser au maximum #include <algorithm> qui par exemple fournit std::back_inserter, et qui devrais être ce que tu veux. Evidemment, ça n'a pas de sense avec un std::set ou std::map, puisque c'est trié… mais bon, ça permets effectivement de pouvoir remplacer aisément un conteneur par un autre, tant que l'opération est légitime pour le nouveau. Cela dis, je trouve la syntaxe "un peu" lourde, c'est surtout utile quand on écrit des template pour moi.

Pas besoin de penser au référencement, c'est juste vachement plus sympa à l'usage que d'avoir des liens dont on ne comprend pas de quoi ça va causer par avance, par exemple sur IRC. Mais dans le cas ou, comme ici, le titre du lien se voit de toute façon réécrit, le "commentaire" n'est que peu utile.

Mais du coup, il y a beaucoup de différence de commandes entre le cas d'une machine avec une "clé physique" et le cas présenté ici?

hows average CPU usage when reloading YouTube six times

J'espère sérieusement qu'il y a une méthodologie plus poussée pour faire des benchmarks du problème.

Je ne sais pas, moi, ce bench bien que trivial me paraît bien plus représentatif d'un usage réel que la plupart des bench plus poussés…

C'est un sujet qui revient épisodiquement avec un ami, qui comme moi, possède un panda juché sur un cimetière d'onglets; ça coinçait, des fois non; Windows vs Debian allez savoir…

Pour le coup, c'est du windows-only, et juste les "windows modernes": win10 et plus récent. A priori, ça devrais concerner tous les logiciels qui utilisent une API de protection de la mémoire virtuelle spécifique à windows, autant dire que ça ne devrais pas toucher la majorité des logiciels libres et portables, puisque ça requiert un développement spécifiques à un seul système.

Ce qui me surprend par contre, c'est que les autres navigateurs, basés sur chromium et notamment edge, ne sont pas affectés, alors que le bug n'est pas lié intrinsèquement à Firefox. Cela semblerait donc indiquer que MS edge n'utiliserai pas les API de sécurité de microsoft, surprenant! Ou peut-être qu'ils utilisent un truc plus performant à la place, parce qu'étant de la même boîte, c'est probablement vachement plus simple pour eux (demander le pointeur vers la bonne doc au collègue lors de la pause café est une facilité, même si je ne suis pas convaincu qu'ils bossent tous dans le même bureau, mais l'idée est la).

pourtant moi j'aime bien le cors, même si j'avoue qu'aller en chercher un ça fait parfois les pieds.

Tu as oublié le xkcd qui va bien!

Mais bon, sinon, ça a aussi le côté fun de bosser avec des trucs tarabiscotés non? Quand il n'y a plus de problèmes a résoudre, s'en créer quelques uns ne fait pas de mal, ça occupe :D

Il y a aussi le fait que, OK, sur un serveur, c'est douteux, mais pour une machine portative, nettement moins, et j'imagine que la même méthode s'applique.

Dont les utilisateurs ne connaissent pas l'utilité ? Quel est le rapport avec des bugs ?

Il me paraît très difficile de déclarer qu'un comportement est un bug (sauf pour les crash, forcément… encore que?) si on ne connaît pas le rôle du programme.

par contre un driver du noyau qui marche pas si bien ça existe.

Bien sûr. Les pilotes graphiques sont par exemple plutôt buggués. Je pense que les pilotes wifi sont aussi assez remarquables de ce point de vue. (être remarquable n'est pas forcément une bonne chose)

Ben du coup, on est d'accord j'ai l'impression?

Bon, pour commencer, je fait partie des gens qui sont passés de windows à linux, donc j'ai eu cette période multi-boot. Je savais coder avant de passer à linux, et je maîtrisais mon windows (non mais vraiment, je m'en sortais pas mal du tout, et aujourd'hui je vois bien que j'ai encore une certaine connaissance de ce système malgré les années sans y toucher et ses évolutions. Je le vois en regardant mes collègues.).
Le truc qui m'a intéressé dans le libre, c'est le fait que la plupart des logiciels sont très configurables, et ça deviens limite un hobby. Quand je suis passé à un système entièrement libre, forcément, je voulais garder cette maîtrise.

Tes ennuis, c'était avec Grub2 ou Grub-legacy ?

Bonne question, ça date. Je pense que c'est grub2… mais impossible d'être certain.

Et est-ce parce-que tu as eu un besoin qui sorte de l'ordinaire ?

Non je ne pense pas que le besoin d'un multi-boot sorte de l'ordinaire (pour ce type de logiciel, du moins). Quoique?

En gros, la gestion automatique des entrées à toujours été une grosse source de galères, avec les systèmes qui se bagarrent entre eux pour savoir qui est responsable du boot loader, et donc quel /etc/ doit être la source.
Et ma réponse à moi, elle est hyper simple: le boot loader, c'est pas le problème des OS.

Ce type d'outil ne devrais pas être contrôlé par un (ou plusieurs) OS installés, et la source de sa config ne devrais pas être dans la partition système d'un de ces OS. Dans le cadre d'un PC avec plusieurs systèmes installés, du moins.

Du coup, j'ai toujours trouvé lilo nettement plus simple et plus fiable. Notamment les fichiers de config, ceux de grub m'ont toujours laissé pantois. Peut-être que je n'avais pas assez lu de doc? Mais justement: avec lilo, je n'ai pas eu besoin de lire la doc. Je m'y suis référé de temps en temps, bien sûr, mais surtout pour régler des doutes ou parce que je ne me souvenais plus d'une option, JAMAIS pour comprendre la syntaxe, l'endroit ou est stockée la config, ou ce genre de trucs de base.

Puis j'ai découvert syslinux, qui supporte plus de situations en étant juste un poil plus complexe, je l'ai donc adopté et je ne me prend plus la tête depuis, sauf quand j'ai une MàJ noyau parce que je dois me souvenir de mettre à jour les fichiers dans la partition dédiée, qui n'est pas montée automatiquement pour des raisons de stabilité (ça évite des bugs de type PEBCAK).

Contrairement à feu lilo ou à grub, syslinux n'est pas intégré dans debian (on peut l'installer, mais ce n'est intégré). Je pense que je pourrais peaufiner ça, mais étant utilisateur de debian, les MàJ kernel sont assez rares pour que ça ne soit pas un problème.

Evidemment, tout ça n'est valable que parce que je suis un utilisateur avancé de mon système, et que j'insiste pour avoir plusieurs OS installés sur un même support de stockage.
Pour un non informaticien ou quelqu'un qui est heureux avec une seule installation d'OS sur la machine, grub est certainement très bien, vu qu'il est notamment bien intégré aux distros, rendant les MàJ noyau automatiques.

Bref, je n'ai pas de bons souvenir de grub de la même manière que je n'ai pas beaucoup de bon souvenir d'outils qui gèrent le système à ma place en me masquant ce qu'ils font.
Dans mes souvenirs, grub est particulièrement hermétique comparé aux autres. C'est à dire, il est plus facile à "utiliser" tant qu'on ne cherche pas à maîtriser son système. Quand on veut maîtriser, alors il est le pire des boot loader que j'ai eu l'occasion d'utiliser.
Liste de ceux dont je me souviens:

• grub
• lilo
• syslinux
• U-boot
• le machin de windows XP, quelque soit son nom (si si, je trouve bien grub pire et plus hermétique, ironique non?)

Je me doute que ça ne va pas plaire à tout le monde, mais bon, on m'a demandé de développer, je m'exécute (sans fork par contre, c'est interdit le clonage humain)

Et pourtant si, c'est un retour d'expérience.

J'ai réellement vu, que tu le veuilles ou non, des machines qui doivent tourner très, très longtemps le temps que tous les logiciels soient finalement utilisables.
Mais je t'en prie, expliques-moi donc que ça n'arrive que dans mes rêves les plus fous.

A un moment il va te falloir admettre que tu parles d'un système auquel tu ne connais visiblement pas grand chose.

de mon peu d'expérience,

Et toi, il va te falloir apprendre à lire avant de répondre.

Pour moi un logiciel qui ne fait pas son travail dans des temps acceptables, c'est effectivement un bug.

Et je suis d'accord que parfois, il faut choisir entre plusieurs problèmes le plus urgent à corriger, et il arrive que le plus urgent soit la rapidité d'exécution plutôt que la précision du travail.

Très bien mais du coup ça veut dire quoi ?

Ca veut dire tendre vers 0. Je ne comprend pas pourquoi je dois expliquer ce que "essayer d'avoir moins de bugs" entends.

La méthode diffère selon la situation, les gens, et leurs compétences.
La preuve de coq est une possibilité (il paraît, je ne jamais vu ça mis en place), mais ce n'est pas la seule. On peut aussi utiliser des outils d'analyse statique, les tests unitaires, la programmation par contrat, … il y a plein de méthodes pour essayer de réduire le nombre de bugs. Aucune à ma connaissance n'est parfaite, mais la méthode joue clairement.
De toute façon, l'absence de bugs est impossible (oui, ça contredit les mathématiciens, qui sont pourtant plus intelligents que moi) avec juste du code: on est toujours exposé aux problèmes "environnementaux": avoir une machine qui plante parce qu'un appareil à proximité émets des ondes magnétiques trop fortes, ça arrive, et tu peux prendre l'algo que tu veux, l'archi que tu veux, la vérification formelle que tu veux, ça ne changera rien.
Bon, évidemment, ce n'est pas le type de bugs le plus fréquent, loin de la et heureusement (parce que c'est la merde a trouver, promis) et ça peut sembler extrême, mais j'ai déjà vu un appel téléphonique faire redémarrer un PC…

Tu as l'impression que c'est ce qu'il se passe ? Que les logiciels utilisés n'ont pas de bugs ?

Toutes les qualités peuvent avoir ce genre de phrases :

Tout à fait, et c'est pour ça que j'ai écrit:

La priorité, c'est que le logiciel fasse sans erreurs ce qu'il a été conçu pour faire, et c'est un équilibre à trouver, toujours.

que j'ai du corriger via un nouveau message en:

La priorité, c'est que le logiciel fasse sans erreurs ce qu'il a été conçu pour faire, et le reste, c'est un équilibre à trouver, toujours.

Mais c'est un avis. Tout a fait discutable.

Que je rejoins globalement, mais je suis quand même intrigué: tu as déjà vu des logiciels dont les utilisateurs ne connaissent pas l'utilité? Après, il est aussi vrai que parfois certains bugs sont mués en fonctionnalités, et vice versa.
En tant qu'utilisateur, je me contrefout que le code de linux soit écrit en C, en Rust ou en brainfuck. Ce que je vois (ou pas), c'est quand ça bug. En tant qu'utilisateur, c'est bien la seule chose que je remarque la plupart du temps :D (et en tant que codeur, je sais que c'est difficile a digérer)

Euh… si tu le dis. Je t'avoue que tu m'a largué dès que tu as dégainé OCaml, ce qui est assez habituel me concernant (être largué quand je vois du code de language fonctionnel).

A priori, sur le principe, je suis d'accord avec toi, mais… bon: je ne vois pas le rapport avec la performance, qui est l'un des point principaux de l'article que l'on commente.

Bon, j'ai quand même vaguement compris que tu défends l'idée que les interfaces c'est bien pour la compréhension. Je suis d'accord avec ça.

Par contre, ton commentaire ne parle en rien de performance, je vais donc me permettre de compléter avec mon opinion:

Moi, ça me paraît évident, en fait, et je pense même qu'avec des interfaces suffisamment claires, on récupère de la performance tout simplement parce qu'on va éviter de faire plusieurs fois la même opération pour rien, naturellement.

Autrement dit, je pense que d'avoir des algo super performants dans chaque fonction, ben, je m'en fout. De toute façon moi, je suis nul en algo.
Je préfère de loin me concentrer sur l'architecture: ça permets de faire la maintenance plus facilement, et si besoin est, de remplacer, justement, les algo par d'autres mieux adaptés en fonction du contexte.

Dans son exemple, si on a besoin plusieurs fois de la surface d'un carré, on va la calculer a chaque fois. Bonjour la performance… alors qu'avec des classes, aussi pourries soient-elles dans l'exemple qu'il a effectivement piqué à un «défenseur de la POO» (la POO a des soucis a se faire avec ce type de défenseurs…) il serait possible à posteriori de modifier les classes pour ne faire le calcul que lors des modifications des côtés du carrés, rectangle, … et ce, sans devoir passer au peigne fin quelques dizaines de milliers de lignes de code. Pour les petits projets. On parle bien vite de centaines de milliers, après tout…

Pour info, https://intelligence-artificielle.developpez.com/actu/342714 passe. En fait, vu l'URI, j'ai supposé que leur BDD n'utilise pas le texte comme indice, mais le numéro juste avant. J'ai probablement deviné juste. Ou pas, je ne peux pas vérifier. Mais bon: ça marche :)

En même temps avec un OS digne de ce nom, il suffit de mettre caps lock, ce n'est pas si difficile :)

Le coeur du système sous Debian n'utilise pas bash, mais dash. Il est très probable que ça s'applique aussi à ses dérivées.
Je sais que bash est toujours un paquet essentiel, et je n'ai pas encore fait l'effort de forcer debian à le virer pour le fun, mais j'ai le sentiment que c'est surtout historique.

Quant à Grub, ma foi, pour moi il ne fait pas partie de l'OS. D'ailleurs je nai jamais supporté grub2, heureusement qu'il y a toujours eu le choix de ne pas l'utiliser, moi ça ne m'a apporté que des emmerdes grub.

Vu comment ça marche super bien le déploiement des logiciels en milieu pro sous windows… de mon peu d'expérience, y'a environ 15% des installs qui foirent, les install ne sont pas en parallèle (sous debian non plus cela dit) et le tout est d'une lenteur telle que pour avoir un système fonctionnel après un "PC refresh" il vaut mieux tabler sur une journée, une demi si on a de la chance!

Alors que je me souviens avoir pondu une config pxe qui faisait une install (de debian) automatisée en moins de 30 minutes, avec tout configuré une et une seule fois, et tous les paquets à jour…

Non, vraiment, du point de vue du déploiement, jusqu'à présent je n'ai jamais vu de windows s'installer facilement ou même juste rapidement.

La sortie de ls ne va pas changer de si tôt, ça casserait énormément de scripts

Il me semble que ça s'est produit il y a peu, chez GNU.

J'ai toujours comparé PowerShell à un langage comme Python plutôt qu'a un shell comme Bash. Je n'ai pas l'impression que les utilisateurs de PowerShell tape de la ligne de commande a longueur de journée, et me semble plus adapté à l'écriture de scripts.

+1. PowerShell n'est pas franchement adapté à utilisation interactive, je suis bien d'accord. Mais il peut être utilisé ainsi.

L'approche des shells "classiques" me parait plus flexible et plus facilement extensible que PowerShell, avec une approche "gestion de flux".

Justement, le powershell en faisant passer des objets développe la gestion de flux pour moi. Tout fonctionne toujours via du pipe en série après tout.
Mon avis sur PS est compliqué, parfois je l'aime parfois je le hais, mais bon, je n'ai pas assez l'occasion de le pratiquer. Je pense quand même dans l'ensemble qu'il est plutôt bien foutu. Si seulement windows avait un éditeur de texte et un émulateur de terminal potables, ça serait p'tet plus intéressant…

Parce que c'est un exemple de nom comme un autre, mais tu as raison de rappeller qu'il ne fait pas utiliser ls dans un script, notamment parce que son interface n'est pas standard, ni celle d'entrée, ni celle de sortie, donc au moindre changement d'upstream ça peut péter le script.
Avec ls, il faut parser la sortie, et parser du texte c'est très difficile (sisi, c'est très difficile, il suffit de penser a tout ce qu'il faut gérer, unicode arrivant en 1er). Surtout que cette commande n'a pas été faite pour être parsée, malheureusement.