freem a écrit 5019 commentaires

Je ne peux pas répondre pour d'autres (et manifestement, certains n'ont pas aimé mon post précédent, ça doit déranger d'avoir aimé lire et rêver… mais perso m'en fout).
Je sais que j'ai toujours été plus introverti qu'extraverti, je ne dis pas aisément ce qui me gêne, j'aime bien être dans mon monde.
Ce genre de comportement n'a jamais été, de ma mémoire, bien vu. Mes parents ont été jusqu'à aller me faire voir une pseudo psychologue, pour me faire passer un test QI (j'étais ado, vers 16 ans).
Je vous passe la blague du test, ça vaut pas le coup d'en parler plus que ça, mais par contre ce qui est sûr c'est que ça m'a mis une claque dans la gueule à l'époque: pourquoi me faire passer un test de QI? Je manquais déjà de confiance en moi, voila qu'on me fait passer un test pour débiles? (oups, j'en ai reparlé)

Pour en revenir au sujet, je ne sais toujours pas si mes parents m'ont bien géré, tout ce que je sais, c'est qu'ils l'ont fait pour moi.
Ils l'ont fait sans lire d'études, ce qui se fait depuis la nuit des temps, et il reste a prouver que ces fameuses études ont un effet positif (donc, ni neutre ni négatif) sur l'éducation.
Perso, j'ai un très fort doute sur le sujet.

C'est ce qui m'a été suggéré en 1ère réponse :)

Vu l'argumentation que tu mets en place, c'est clair.

Gamin je m'ennuyais rarement: jamais tant qu'il me restait un bouquin à parser lire. Ça ne m'empêchais pas de fermer le bouquin pour rêvasser et imaginer moi-même une suite, et je ne faisais pas ça par ennui.

Certes, sauf que mon but est de générer un schéma de partitionnement via 1 fichier d'entrée sfdisk et un fstab.
Hors, il s'avère que mkfs ne supporte pas les PARTLABEL. Je doute donc qu'il supporte les UUID, ceux-ci existant aussi sous les partitionnement de type MSDOS, j'imagine qu'ils sont encodés dans le FS lui-même, qui n'est, a mon stade, pas encore créé.

Bah, pourquoi ne pourrait-il pas y avoir de grille pain connectés? Utile pour savoir quand ton pain viens de finir de griller via le cloud :)

les (sous)programmes soient systématiquement assignés à un thread sans pouvoir être baladés

Du coup, une vulnérabilité légèrement moins élevées aux attaques sur les caches peut-être? (vraie question, même si je me doute que c'est loin de protéger)

Ce que tu appelles le "vrai nom"
est le nom du fichier de périphérique qui permettrait d'accéder à la partition.

Désolé, j'ai la tête dans mon script, du coup je suis un peu embrouillé pour expliqué… tu as raison.

en regardant avec la commande readlink

Bien vu, j'avais zappé que ce sont des symlinks. C'est nettement plus simple ainsi en effet.

J'ai une anecdote très amusante sur le sujet aussi, qui date de biieeenn avant LibreOffice: un commercial voulait que je modifie un fichier excel, modifier les formules.
J'ouvre avec excel: impossible d'avoir la formule complète. Ça commence bien. J'ouvre avec OpenOffice, une autre merde, me souviens plus laquelle… zut… j'ouvre avec gnumerics et… 0 problème. J'ai donc pu importer la formule qui dépassait les 1024 caractères de large, la coller dans ce bon vieux notepad++ (j'étais encore windowsien à l'époque, il y a plus de 10 ans), et m'apercevoir que c'était juste une collection de if […] else if […], remplacée par une seule instruction.
Je pense que la formule originale avait été faite avec le clicodrôme, d'où la possibilité d'avoir une formule trop longue pour l'affichage (mais pas pour le fonctionnement).

Donc, ouai, MS supporte pas forcément très bien ses propres formats en effet :)

Il est moins cité que les autres lui, c'est quoi du coup son focus?

Ah non mais attends j'ai rien à faire : c'est installé de base sur ma distrib. Mais bon si t'aimes souffrir années 90-style…

Tu confonds "se faire chier 90-style" et "ne pas avoir a implémenter parce que d'autres ont fait le boulot pour moi". Ce sont deux choses différentes.

Mais bon si t'aimes souffrir années 90-style…

Techniquement, runit est un héritier des daemontools donc c'est "me faire chier 2000-style".
Et techniquement, je pourrais aussi juste utiliser voidlinux, donc je peux aussi parler de 2020-style, et utiliser runit sans m'embêter a faire mes scripts.
Sauf que moi je veux le support de runit dans ma Debian. Et je ne suis pas le seul à le vouloir.

Sinon, au sujet de "se faire souffrir": voici ce que j'ai lu récemment. Vois-tu, il semble que parmi ceux qui ont vraiment besoin de bosser avec le gestionnaire de service, certains trouvent que, oui systemd a de jolies fonctionnalités (One or two features seem to do what we have hacked differently so far.), mais c'est fragile (It looks like several features are incompatible changes and will break things in more or less surprising ways.) et complexe (all development schedules blow up with its complexity).

Malheureusement, cette personne ne parle pas d'autres systèmes qu'elle aurait expérimenté (aurait été intéressant pour comparer).
Pour ma part, j'en ai expérimenté un autre, qui a ses défauts, qui sont différents de ceux de systemd.

Il y en a un 3ème que j'aimerai essayer, qui semble avoir la simplicité que j'apprécie chez runit, sans son inconvénient majeur: l'absence de gestion des dépendances. Un jour je prendrais le temps de tester nosh, s'il tiens ses promesses, alors c'est peut-être bien la meilleure option.
Honnêtement, ça serait pas mal, mais vu que la plupart de ceux qui cherchent une alternative simple et stable à systemd ont tendance a partir vers runit, je préfère suivre ce mouvement dans un 1er temps. Les logiques étant compatible (nosh est aussi un héritier de daemontools) si le jour ou je teste il s'avère que ça marche mieux, migrer sera un jeu d'enfant. Et je pourrais me baser sur un truc qui marche.

Et pour être sûr d'avoir du moinssage cette fois : je suis sérieux en fait :-D

Tu sais que c'est peu probable, tu défends le système le plus utilisé après tout :)

Bah, déjà, je pourrais le rendre moins pire en mettant un simple coup d'astyle. C'est bien pour ça que je dis que c'est fait exprès: un logiciel peut rendre ce code moins illisible.

Et, ça restera toujours du code pré 2011. Après, oui, je pourrais probablement le réécrire. Sauf que bon, je ne suis pas mathématicien. Certes, avec des outils comme valgrind et google-perftools, je pourrais trouver les parties à optimiser… mais, au final, ça avancerais à quoi?
Mes projets perso du moment, c'est:

• patcher coco/R pour qu'il être interactif: pour l'instant c'est juste un générateur de compilateurs… je voudrais m'en servir pour en faire un interpréteur de commandes;
• utiliser ce patch pour écrire un langage (yep) qui remplacera (au moins dans mes usages) la commande dialog, le tout sur une logique client-serveur;
• diverses autres bricoles;

Je peux bien glandouiller un peu ici, et dénoncer grave un pseudo article (et tant pis pour stressand) sans pour autant me détourner de mes objectifs?

Merci, je lirais ça un peu plus tard.

Et, tu as raison, j'aurai du plutôt parler de dépassement de tampon, puisque ce n'est pas un comportement qui serais causé par la RàZ d'un overflow, mais bien par une écriture au-delà de qu'il a le droit d'écrire.

Vu que c'est, dans ce cas, intentionnel, il s'agit d'un hack. Pas malintentionné, certes, mais bon.

NetBSD à la réputation de pouvoir s'installer absolument partout

Vu le code que j'en ai lu, je n'en serais pas surpris, vraiment.

[OpenBSD] font tous dans leur coin

Comme OpenSSH qui n'est pas portable?
Ce n'est pas ce que toutes les rumeurs disent (oui, je parle bien de rumeurs, sinon, je sourcerais).

OpenSSL finalement trop code spaghetti, on refactorise -> LibreSSL.

Non, à l'époque, le bruit c'était plutôt: «OpenSSL est blindé de code mort, qui lui a causé une Nième faille qui est méchamment piquante! Forkons! Virons le superflux, et profitons-en pour exposer une API qui permette aux développeurs d'utiliser TLS sans être des maîtres sur le sujet.»
Et, oui, libressl expose une API compatible "juste refondue" (enfin, plutôt dégraissée hein), mais aussi et surtout une API qui a pour but de mettre le chiffrement à la portée des développeurs normaux.
À noter que cette initiative a fait des petits, chez google par exemple, qui sont je pense aussi assez compétents sur le sujet.

Les jails ? Ca sert à rien c'est bon pour les systèmes avec des failles nous on est tellement sécure qu'on a pas besoin de ça tout est chrooté par défaut.

Tout est chrooté par défaut? Je pensais plutôt que le principe c'était que le code officiel est écrit de façon a être super robuste, ce qui est, il me semble, pas si idiot que ça: tous les systèmes ne peuvent se permettre d'embarquer des jails (en tant que "linuxien", je devrais parler de containers, mais je trouve ça mesquin vu qu'il me semble qu'en effet freebsd fut pionner de l'isolation, et netbsd des rumpkernels).
Parce qu'il me semble bien que ces choses ont un impact sur les ressources, comme toute mesure de mitigation.

Le mutli-coeur ? C'est quoi ça ? Un nid à bug on a pas besoin de ça ou alors dans 10 ans (bon c'est pris en charge maintenant)

J'avais cru comprendre que le problème venait du mulithreading, en soit, qui me semble être un coeur partagé? (et en effet, les failles d'intels étaient plus sensibles à cause de ça)

Vrai aussi. Mais je préférais aller vérifier avant de moinsser :)

Là il ne s'agit que de faire un peu de pub à Nim.

Désolé, j'aime pas quand on tape injustement sur un langage en faisant exprès de coder avec les pieds pour faire passer un autre langage comme "plus rapide".

Au moins avoir un code lisible dans les 2 comparaisons et utiliser des technologies de même génération, ça me semble un minimum requis de bonne fois.

Tu veux dire que ça, c'est pas du use-case ?

En vrai, j'ai dis le problème d'origine, mais c'est p'tet juste un d'eux. Pas comme si on avait des gens dont c’eut été le métier, en fait, alors on s'est démerdé à l'empirique.

Bon, et sinon, le "use case a écouter", c'était "Bonjour, je suis arrivé, la borne est freeze". Démerdes toi. Faut faire un poff/pon déjà pour remettre en service, parce que le client en a besoin pour alimenter son bateau, et donc ouai, t'as aucune info, sauf, ça freeze. Est-le soft? Est-le hard? Tu sais pas.
Et tu peux pas forcément aller voir sur place, non.

je crois que ça reste pareil : si y'a une sorte de grain de sable, il faut le trouver avant de s'attaquer au reste.

Dans ce cas on n'aurait jamais rien livré, parce qu'on ne peux pas reproduire aisément dans un petit atelier le passage a proximité d'une péniche mal blindée, l'usage d'un groupe électrogène foireux dans un système qui est connecté d'une manière ou d'une autre au système électrique, les problèmes de radio, etc.

C'est une des différences entre les problèmes liés au hard et ceux qui sont 100% logiciels.
Dans une solution purement logicielle, tu peux tout simuler a moindre frais, tu peux même fuzzer pour 3 fois rien, sans même instrumenter!
Quand c'est lié au hard (ou a des bugs de firmware qui seraient utilisés dans des composants hein)… pas vraiment. C'est pire que d'avoir un code proprio à intégrer.

Après, je manque clairement d'expérience sur le sujet, mais le peu que j'en ai me fait penser que c'est bien plus difficile a jauger quand il faut composer avec le matériel, ses défauts, les conditions météorologiques, les systèmes pourris qui passent à côté et t'envoient un max de parasites de partout (oui, le blindage aide, les mises à la masse aussi, mais difficile de toute tester amha), …

Pas grand chose de plus a dire pour le coup, désolé.
C'est vraiment juste: une carte mère à la masse, reliée à un module usb qui lui ne l'étais pas.
Parfois le matos freezais, on ne savais pas du tout dans quelles circonstances, vu que c'était déployé en bord de cours d'eau pour être branché sur des péniches.
Le mettre à la masse "semble" avoir résolu le problème, que l'on n'était pas sûr d'avoir vraiment identifié, personne d'entre nous n'ayant de réelles compétences en radio/électronique et autres joyeusetés.
Il y a eu d'autres problèmes de hard/soft, si ça se trouve c'était juste une seule des causes. Je n'en saurais jamais plus :)

Je sais que c'est fait exprès, mais tu as quand même enlevé un morceau important: je ne parlais pas de l'heure actuelle, sinon "date" m'aurai suffit :)

il ne charge que les 512 octets d'un secteur

Si je me trompe pas:

Dans le cas d'un partitionnement type MS-DOS, le 1er secteur (donc 512 octets) du disque ne contiens pas à proprement parler le boot loader, mais un code qui permets de trouver la partition à booter, qui elle contiendra un chargeur de démarrage, la ou LILO, Syslinux vont aller se coller. Grub2, en effet, va modifier ce 1er secteur, ce qui m'a suffisamment cassé les pieds par le passé.

C'est pour ça que grub est en deux partie (stage 1 et stage 2). La première est minimaliste et permet juste de charger la deuxième qui est plus complète et va elle-même avoir les instructions pour charger un kernel et l'initrd.

Mais la 1ère partie de grub ne tiens pas sur 512 octets, ce qui semble être la raison qui fait qu'utiliser grub sur un système GPT en legacy boot implique l'usage d'une partition dédiée, parce que Grub2 se base sur un overflow.
Les autres que j'ai pu utiliser (LILO, syslinux, et probablement le démarrage sous dos, w9x, wXP) ne faisaient pas ça.

Je n'arrive pas a retrouver les documents que j'avais sur le sujet, tant pis (j'aurai bien aimé revérifier mes propos et avoir des références plus précises, mais ça fait plus de 15 ans que je les ai pas vus).

J'ai voulu lire le code C++… Ça pique. C'est illisible, et pas a cause d'optimisations.
Ce qui, en revanche, n'est pas le cas du code nim, étrangement…

Pour info, le fichier .cpp à 103 lignes, le fichier .nim 335, alors que C++ est réputé verbeux.

Là ou le code Nim est bien lisible: une instruction par ligne, des lignes vides pour aider l'oeil a distinguer les blocs, des commentaires qui sont sur leur propre ligne, du code aligné… le C++ à l'air obfusqué et codé dans du pré-C++11.
D'ailleurs, aucune bibliothèque de C++ n'est utilisée ici. Pourquoi? Ça aurait réduit considérablement la quantité de code à écrire… et aurait pu inclure du code optimisé, justement.
Perso, quand je dois faire de la 3D, je n'implémente pas mes algo de détection, j'utilise ce qui existe. Que l'on compare son implémentation de nim avec du code C++ qui utilise ça, et on en reparle.

Le code me semble clairement écrit en faveur de nim, et le C++ semble malgré tout proche de nim question performances. Ma conclusion c'est que Nim est plus lent que C++, et le code est fait salement en C++ pour empêcher de facilement voir pourquoi c'est lent.
Non, ce n'est pas du C++ naïf, sinon l'auteur n'utiliserais inline, qui n'est pas ce que l'on trouve en 1er dans les tutoriels et docs.

Extraits choisis de code C++:

     if (det<0) return 0; else det=sqrt(det);
    return (t=b-det)>eps ? t : ((t=b+det)>eps ? t : 0);

Pourquoi laisser le else? Si tu retournes dans le if, le else sert évidemment à rien.
2 branchements avec l'opérateur ternaire sur un return? J'appelle ça du code de merde, sans parler des affectations au milieu: l'auteur ne veut pas que l'on puisse comprendre ce qui se fait.

  inline bool intersect(const Ray &r, double &t, int &id){
  double n=sizeof(spheres)/sizeof(Sphere), d, inf=t=1e20;
  for(int i=int(n);i--;) if((d=spheres[i].intersect(r))&&d<t){t=d;id=i;}
  return t<inf;
}

Errrr…. spheres était un table de taille de fixe, on peut constater ici plusieurs erreurs, possiblement optimisée par le compilo, mais peut-être pas:

• a chaque appel de la fonction intersect, on refait une division inutile: n devrais être une constante, calculé une seule fois. Et pas un double.
• cast double vers int inutile pour n.
• for(int…) vraiment? Même en C ou C++03 on faisait mieux, avec les pointeurs. Du C++11 moderne, donc de moins de 10 ans, utiliserais juste un range for. Bon, ici, il semble réutiliser l'entier pour le retourner dans le cas ou il trouve une intersection, mais vu que le code est imbuvable, difficile de dire si on ne peut pas s'en passer.

Aussi:

Nim 1.2.0 (GCC 10.1), flag -d:danger

Donc, version récente: "1.2.0 2020-04-03".

Pourtant, il n'utilise pas C++20, pourquoi? Ça aurait permis d'éviter certaines implémentations, genre clamp vs std::clamp.

Tu peux te passer de grub avec un UEFI.

Exact. Tout comme on peut le faire avec un BIOS en vrai.

Zut on est plus trolldi, je dois donc préciser, le BIOS boote un secteur précis, etne savais pas gérer un format de fichier.
UEFI lui semble savoir gérer un format de ficher (FAT?) et booteras une partitions avec un UUID spécifique. Ou partiras sur un interpréteur de commandes.
Ça reste flou… mais bon, dans l'état, grub n'a toujours été qu'in intermédiaire, il n'a jamais été techiquement nécessaire, je me trompe?

Bonne question. Je n'ai jamais eu le besoin encore.

Les *BSD sont des descendants direct d'UNIX. Mais je suis pas sûr d'avoir compris la question.

de tout monitorer,

Ça serait possible de nous expliquer ce que tu monitores et comment, sur un système linux ou bsd?
J'ai passé ma journée a explorer le sujet, pour linux, j'ai lu pas mal de choses intéressantes, mais tout semble très… disons, expérimental, fragile. Mais sujet passionnant!

En plus, ça tombe bien, tu sembles t'ennuyer, et apprécier les discussions ici: je peux t'assurer que, quand on écrit un journal, on a des retours pas forcément positifs, mais très souvent instructifs et/ou divertissants.