freem a écrit 5059 commentaires

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.

exercice de sécu «Red Team vs Blue Team»? J'adorerais être pris dans ce genre de trucs un jour, même à mon insu, voire, surtout à mon insu. Lire le résultat doit être super intéressant.

Si je n'arrive pas à reproduire, c'est que j'ai mal écouté le use-case et qu'il me faut revenir vers l'utilisateur.

Toi, tu bosses pas avec du hardware… parce que reproduire un bug causé par des interférences électromagnétiques fortes, causée, par exemple, par un navire qui passe ou par un putain de téléphone qui sonne juste à côté de la carte mère, c'est pas simple.
Le coup du tél on l'a trouvé par hasard (ps: kudos olivier, même si je doute que tu sois dans le coin), mais a permis de mettre en évidence le problème d'origine.
Hé oui, un bug, c'est pas toujours soft ni lié aux use-cases.

Ma foi, nous attendons tes journaux tech avec grande impatience :) Sans blague, c'est sympa de temps en temps ces journaux, j'aimerai qu'ils soient la norme.

Et tant qu'a râler, autant râler sur des sujets un peu liés au thème du coin: linux et logiciels libres. Bon, ajoutons le troll vim vs emacs sur les journaux qui n'ont rien a voir avec les éditeurs de texte, ok (si quelqu'un peut retrouvé la n'image de référénce… j'ai perdu mon bookmark).

C'est d'ailleurs comme cela qu'un lecteur de musique sous Linux réagit aux commandes systèmes type play / pause.

Ben… oui et non.

Oui, parce que je suis sûr qu'il en existe qui utilisent ça.
Non, parce que perso j'utilise mpd, et ce dernier ne réagit pas au clavier :) a la place de ça, il prend ses commandes sur un socket, avec, certes, un protocole spécifique (mais en vrai, même avec dbus, il faut implémenter un protocole, puisque qu'il faut bien définir les messages écoutés et comment y répondre, non?), que causent de nombreux clients.
J'ai nommé mpd et sa clique. Comme il existe un client en ligne de commande, il suffit de bind des raccourcis clavier aux commandes en question et le tour est joué.
LE point négatif, et j'en suis conscient, c'est qu'il faut accepter de faire la config initiale. Dans mon cas, jusqu'ici, je mets les bindings au niveau du gestionnaire de fenêtres, mais je me demande s'il ne me serais pas possible de faire ça directement au niveau d'acpid, ce qui serait plus pertinent (accessible via mes TTYs) et aussi plus portable (non spécifique à un WM, ni même à X11).

D'un autre côté, ce travail a forcément dû être fait pour les gros DEs, donc… faire faire ou faire soi-même, lorsqu'il existe possiblement des solutions déjà existantes qui seraient plus portables, sont-ce les bonnes choses à faire?
Faut que je creuse. Je connais encore trop mal certains sujets comme acpi et udev je le crains.

Bon sujet de dissertation pour un trolldi : Deux distributions Linux différentes sont-elle deux OS différents ?

Le problème est ici la définition de l'OS, de "système d'exploitation". Dans ma définition à moi, la plupart du temps, oui.
Parce que je considère les mécanismes d'installations et les ABI des libs importantes comme étant partie d'un OS et de ses specs.

Une fois que l'on considère deux distributions de Linux comme des OS distincts, c'est logique mais le newB n'a sans doute pas (encore) compris que ce sont des OS distincts.

Bien d'accord avec ce point, mais le problème n'est lié ni au newbie (qui n'étais pas un terme péjoratif dans le milieu ou j'ai appris l'info, y'a 15+ ans, il ne l'est que dans les milieux bourrés de "gamer" et de lamers) ni aux distro linux.
Le problème est lié au fait que les gens qui veulent se rendre intéressants parlent de "linux" sans comprendre ce dont il s'agit. C'est la le grand problème.

D'ailleurs, les gens que je connais ne font pas la "confusion" linux = android, et pourtant…

Euh non, quand je trouvais pas un truc sur Windows, je trouvais cela dommage mais je n'imaginais par faire l'une ou l'autre de ces cabrioles à part la première.

Tu n'as vraiment jamais installé un truc depuis un site tiers? Difficile a croire, désolé. Mais possible, en soit.
Oh, j'oubliais de lister les CDs rom achetés dans le commerce dans ma liste…

Tout à fait. Et je me dis que si un jour, j'installe une version de Linux chez quelqu'un pas très versée en ni intéressée par ce qu'il y a sous le capot; je lui dirai un truc du genre : pour ajouter des programmes tu regardes dans le catalogue (et pas ailleurs). Pas top pour l'émancipation informatique de la personne mais peut-être plus sage au départ.

Ça sera un PC qu'il n'y a pas besoin de déverminer tous les 6 mois. Et avec bien plus de logiciels que sous windows, qui ne sert juste à rien sans logiciels supplémentaires.

Deuxième dissertation pour un trolldi : si une (et une seule) solution type flatpack s'impose globalement pour l'installation des logiciels, que restera-t-il comme différences substantielles entre les différentes distributions ?

Les mêmes qu'aujourd'hui, puisque flatpack, par nature, ne peux pas remplacer le système de paquets natifs, a moins que je ne me trompe complètement.
Son objectif est, d'ailleurs, de le compléter, afin d'avoir un système qui ait la base fiable des distro "traditionnelles" orientées version, tout en ayant la modernité caractéristiques des rolling releases.

Peut-être que je me trompe du tout au tout: il me reste moi aussi une longue route à faire, mais au moins la voie est libre :)

Vivaldi le gère déjà sous Windows et Linux, par exemple avec Subsonic/Airsonic ou Youtube

Vraiment? Avec quel DE? Je suis curieux de connaître comment ça marche sous le capot (chez moi, ça marche pas, mais je pense que c'est normal, quand on choisit d'avoir un système hors normes, faut pas s'étonner que les softs soient pas très bien intégrés).

Ah, ben j'ai trouvé… diantre…

Tu fais vraiment ça? :

#!/bin/sh
#
# PROVIDE: goprogram
# REQUIRE: networking
# KEYWORD:

. /etc/rc.subr

name="goprogram"
rcvar="goprogram_enable"
goprogram_user="goprogram"
goprogram_command="/usr/local/goprogram/goprogram"
pidfile="/var/run/goprogram/${name}.pid"
command="/usr/sbin/daemon"
command_args="-P ${pidfile} -r -f ${goprogram_command}"

load_rc_config $name
: ${goprogram_enable:=no}

run_rc_command "$1"

Niveau complexité, c'est digne de systemd pour le coup, avec pleins d'artefacts qui sentent bon les race conditions en plus :)

Je préfère ne pas aller voir le contenu de . /etc/rc.subr hein…

Aie machine à Troll lancée …

On a le droit, c'est trolldi :)

je me félicite car j'ai évité systemd & co […] j'aime grave rc.d

Déjà, c'est quoi, "& co"?

Et sinon, pourquoi, du coup?
Je veux dire, systemd à de très certains défauts, mais aussi des avantages. Je n'ai aucune honte a dire que, quand je ne connaissais que les implémentations de inittab et rc.d dans debian, j'ai été SOULAGÉ d'apprendre qu'il existerais une alternative.
Dans les flamewars qui ont suivi, j'ai appris que c'était déjà le cas, et j'ai trouvé mon bonheur dans le passé plutôt que dans le futur, quand les 2 m'imposaient d'apprendre.

Ironiquement, je crois que, sans systemd, jamais runit n'aurait été considéré comme alternative à sysvinit dans Debian, et je pense sincèrement que c'est le boucan autour de systemd qui a fait qu'aujourd'hui, il y a cette alternative dans Debian.
Même si je n'aimerai probablement jamais systemd, je dois lui reconnaître ça: il a fait bouger les choses dans le bon sens.
Le bon sens, parce que j'ai vu des systèmes embarqués nécessiter une intervention de spécialiste (donc, 2 déplacement + intervention au bureau) parce qu'il y avais un système d'init tout foireux qui se contentais de lancer les trucs et baste, tant pis si ça se ferme. Des milliers d'euros de perdus, des litres de pétrole cramés pour rien.

Quels sont, en pratique, les points forts de rc.d? De ce que j'ai lu, ça semble être une sorte de /etc/inittab. Un truc certes très simple, mais qui nécessite une grosse attention quand on développe un logiciel de type daemon, sans quoi ce dernier ne sera pas relancé, ce qui est pourtant très important, surtout dans le cas d'une machine à laquelle l'on n'a pas d'accès physique (j'en ai eu pas loins de 250)…

De ce que lis… enfin, non, greppe ici, les termes "moni[toring]", "sup[ervision]", "wat[chdog]" ne sont jamais mentionnés.

Systemd n'est, bien évidemment, pas le seul a en être capable, et je n'ai aucun doute que des init et autres capables de remplir ces tâches existent sous FreeBSD (ne serait-ce que mon préféré, qui ne l'est que parce que je n'ai pas pris le temps d'en creuser 150- est portable).

Ma question ici, c'est: quel est l'intérêt de rc.d par rapport aux inits qui sont conçus avec cette problématique à l'esprit?

Tout ça pour dire, tu pourrais nourrir un peu plus les trolls quand même.

Tu sais, a ce stade, tu aurais pu linker vers lycos(d'ailleurs, je savais pas que ça existait encore), ceux qui se rappellent des pubs t'auraient probablement pertinenté :) (d'ailleurs, je vais me garder l'idée, c'est plus fun que rtfm ou
lgmtfy pour ceux qui ont le contexte)