briaeros007 a écrit 9441 commentaires

ahahaha

on explique ce qui pourrait être un problème potentiel à notre avis.
Au début on se fait insulter
ensuite on nous explique qu'on est trop con et qu'on comprend à rien.

Et maintenant c'est à nous d'expliquer par A+B pourquoi l'ancien système, qui n'avait pas cette contrainte, … ben n'a pas cette contrainte.

(ah en fait, sauf erreur de ma part, tu n'es pas limité à du bash, et de base on est même plutôt en sh, mais tu peux même faire un binaire statique).

et le type qui plutot que de répondre sur tes arguments (entre autre augmentation de la surface d'attaque, etc…) ou de t'opposer un quelconque raisonnement cohérent t'explique que tes arguments sont "complètements stupides"
tu le classe où dans l'instance de divorce ?

ca fait toujours plaisir de parler avec toi.
Au moins j'aurais essayé, de mon coté, de ne pas être insultant.

Ce n'est pas le cas de tout le monde dans cette discussion.

je parlais dans les commentaires ici.

La mauvaise foi c'est aussi déformé les propos pour ne pas reconnaitre que, si, depuis le début des commentaires, il est quand même dur d'avoir des choses objectifs dans les commentaires.

si openssh se plante tout seul, toute mes condoléances.
Ca t'es arrivé souvent ?

Non, pas vraiment. Prends un script d'init bsd et mets le sur un linux, qu'on regarde comment ça marche bien. C'est pas parce que tu peux faire un script qui va marcher partout que tout les scripts marchent partout, ni même que l'intégration soit correct. Si tu veux suivre les coutumes locales, la config du script va aller dans /etc/default pour debian et consorts, et /etc/sysconfig pour RH et dérivé, et ailleurs pour suse, sauf erreur de ma part. Ou les BSD et arch.

Ce n'était pas le but de mon propos.

init V et systemd n'ont jamais eu pour but de remplacer LSB ou l'intégration des mainteneurs.

Suivants les distribs/… certains soft sont packagé dans /usr/share, ou dans /opt/ ou dans …

tu vas me dire que systemd va deviner tout seul quand le service à gérer est dans /opt plutot que le /usr/ classique ?
J'ai comme du mal à le croire, je ne sais pas pourquoi.

Donc permet moi de dire que tu surestimes la portabilité, et que tu sous estimes le travail des packageurs à ce niveau. ( et l'imagination dont font preuves certains upstreams pour faire des trucs chiants à lancer correctement )

Ou alors je ne confond pas le rôle du système de démarrage avec le role du mainteneur et de la distrib.
Si la distrib ont décidé de changer les répertoires utilisés, systemd ne vas pas les deviner tout seul. Il faudra dans ce cas packager correctement et tu auras du taff à faire, systemd ou init V

/sbin/init fait plus que ça. Il se charge aussi de tuer les process zombies qui se rattache à lui, de relancer si tu demandes ( respawn ), il gère les touches ctrl alt del, il gère le fait d'avoir courant coupé (via l'action powerwait, powerfail et consort ).

Pour les process zombie ok, mais d'un point de vue hierarchique c'est le seul qui peut le faire aussi.
sur ctrl+alt+del, et les powerwait/… tu ne peux pas me dire que ça n'a pas de lien avec l'arrêt/démarrage des services, même si je suis d'accord que d'un point de vue modulaire, ça devrait faire l'objet de services à part.

Et pourquoi tu penses que tout un tas de distributions l'adoptent si c'est si mauvais et que tout le monde soit disant n'en veut pas ?

Où j'ai dis "tout le monde" ?

Pour ta question, un peu comme PA, non ?
Sauf qu'il ne suffit pas de faire un remove de PA dans ce cas /o\

Le lien que tu as fournis est très intéressant.
Entre autre lorsqu'il dit "non mais les dépendances c'est pas grave il n'y en a que 10, et puis c'est bon (mangez en) les dépendances).

Il oublie juste un ou deux trucs dans le problèmes des dépendances :
- plus tu as de dépendances , plus tu as des risques qu'une merde à un moment ou à un autre.
- plus tu as de dépendances, plus tu as un risque dans la fiabilité du code.
(Tu as plus de chance de trouver au moins un bug dans 15 librairies, que dans une seule. Le dernier MISC avait un article très interessant sur du fuzzing sur adobe reader à partie d'une librairie qu'il utilisait).

Une des principales critiques que j'avais était le fait justement du bloatware.
Je n'avais pas vu qu'il y a bien de multiples binaires.
(fait une recherche systemd multiple binaries tu verras que l'information ne semble pas si répandu).
Maintenant est ce qu'il y a une véritable séparation ou est ce que les autres binaires peuvent faire ce qu'ils veulent avec PID 1 ?

Ah ça me manquait tes ad hominem etc…

Ne pas t'écouter != ne pas écouter tout ceux qui font de la prod

Je n'ai jamais écrit à lennart ni rien donc il risque pas de m'écouter :P
Mais je constate que nombre de voix se sont élévés contre systemd auparavant, par des gens bien plus "en vue" que moi (c'est pas très dur tu me diras).
Et que sur certaines critiques avec lesquelles j'étais d'accord (sur cette partie "prod") , aucune réponse satisfaisante n'a été apporté.

Et pour ton info, je travaille avec des pros-redhat et il y a de super produits sous redhat (spacewalk par ex).

Systemd a des intérêts. Mais si il y a des points criticables, pourquoi n'auront pas le droit de les critiquer ?

T'es pas content? Fork et montre qu'il y a du monde qui veut autre chose

Il y a déjà un truc qui marche très bien. Pourquoi forker un truc qui existe déjà et fonctionne très bien?

Oups, raté, personne ne s'y colle… (quelques projets par ci par la qui lâcheront bien vite, on le voit déjà maintenant qu'il n'y a pas foule qui adhère)

AHAHAHA.
"Il n'y a personne qui s'y colle" .. "ah mais en fait si, mais c'est qu'ils sont trop nul c'est tout".

Comment dire tout et son contraire, ça me manquait ta prose

Init est tellement cool que nombre de choses sont impossibles voire difficiles à réaliser sur nos machines modernes ce qui bloque nombres de personnes. C'est sûr qu'un truc qui fait rien ne risque pas de péter.

J'aimerais bien savoir quoi (et ca bloque combien de personnes vu que tu as l'air de savoir plein de chose, y compris "nombres de personnes")

Parce que à part dire "systemd ca simplifie tout" "init c'est de la daube", j'ai pas vu grand chose de plus précis.

Je peux faire la même chose en inversant les noms…

• tu peux définir un nombre de relance en cas de crash (essayes de faire ça avec init.d)

\o/
On va gérer les services à la windows. "y'a qu'a relancer, pas besoin de savoir pourquoi ca crash et essayer de gérer ce problème avant".
(et sinon il y a des watchdog ou des solutions de HA quand tu as besoin de HA).

• les démons type httpd n'ont plus besoin de démarrer root, car c'est systemd qui ouvre les ports.

capabilities, ou authbind, ca dit quelquechose à quelqu'un ?

• interaction avec dbus et du coup, possibilité d'interfaçage avec des clients desktop

Il n'y a que moi que ça gêne de rajouter des couches à l'intérieur d'un système critique, et non pas rajouter un service qui fait la "traduction" entre le desktop et ledit systeme critique ?

Si t'as envie de rester à l'age de pierre,

C'est clair qu'on a toujours envie de discuter avec des gens qui croient tout savoir et sont pédants.

bizarre qu'il soit à -10, parce que son propos est pertinent (cohérent, logique, et possible) même si il ne convient pas à la vision de tous.

Aucun problème si c'est toi qui gère toute cette merde. Tu ne te proposes pas? Pourquoi les autres se feraient chier pour toi?

Et pourquoi on devrait se faire chier parce qu'un dev (lennart) est persuadé d'avoir la réponse à tout mais refuse d'écouter tout ceux qui font de la prod ?

Ouais mais bon si tu adores faire des scripts illisibles et difficiles à maintenir pour avoir ton init chéri qui a du mal à gérer nombre de situations, c'est ton choix mais pas tout le monde n'a envie d'avoir ça.

C'est sur, tu ne feras plus de scripts de démarrage.
Mais bon ça sera toujours pas plus lisible, et en plus moins modulaire (ie tu auras des scripts de démarrage quand systemd ne sait pas faire un truc, et un démarrage à la systemd quand il sait gérer).

Systemd permet d'avoir pour toutes les distributions le même mécanisme de démarrage sans refaire els mêmes bidouilles mais différemment. La main d’œuvre manque cruellement pour qu'on puisse éviter ce surplus de travail.

Tout comme system V ou l'init BSD.

https://xkcd.com/927/

Peut être aussi que simplement démarrer ou arrêter des services ne répond plus au besoin d'aujourd'hui ?

Euhhh on parle de quel besoin là ? On parle toujours de l'init où on parle d'autre chose?
Si c'est l'init, on lui demande juste de démarrer ce qu'il faut, et d'arrêter ce qu'il faut.
Si j'ai besoin d'un watchdog parce que mon service se casse la geule "mais que je sais pourquoi" ce n'est pas censé être le problème de l'init (ton service est pas fiable, il est pas fiable : dans ce cas tu corrige ton service, ou tu établis un watchdog qui va vérifer des conditions qui font planter ton service (log par exemple)).
Si c'est du réseau … ben c'est le role du réseau, et d'un point de vue cybersécurité c'est une hérésie de mettre en place le système central de l'ordi (qui a donc TOUTE autorisation pour lancer des process sous n'importe quel utilisateur et avoir tout accès au matériel etc… (héritage des droits et transitions des rôles) une ouverture sur le réseau!

Ca me fait penser aux automates SCADA que l'on peut trouver ouvert sur le net.
Et les gens qui font ces systèmes ont exactement les mêmes propos que toi "on demande maintenant bien plus à un automate que juste faire un automate"

Conclusion, on sait griller des sous stations électriques par internet maintenant \o/
(test fait par la DHS de tête).

le calculateur d'injection c'est de l'embarqué (donc déjà pas comme un pc et un os).
Ensuite il y a un lien très fort entre le code et le matériel.

Un windows, il n'a (presque) aucun lien avec le pc (je peux mettre un même windows sur une autre machine, et je peux faire tourner la même machine avec plusieurs versions d'OS (windows 7, XP, GNU/Linux,…) )

Bref, encore une fois tu troll et fait des correspondances qu'on a déjà répondu un bon millier de fois.

Depuis 2008 tu devrais avoir eu ta réponse quand même.

(ah j'oubliais, un pc n'a pas besoin d'un OS poru fonctionner.
La preuve, le bootloader il fonctionne bien sur ton pc… et il n'utilise pas d'OS)

carte graphique <-> matériel <-> même type de produit (de contrat) que le reste du pc

OS/logiciel <-> logiciel <-> type de produit différent (de contrat)

Donc fournir des configuration matérielle assemblée , lorsque tu les achète, tu as le même contrat

Quand tu fournis un pc avec un os, tu as un (ou des ) contrats subsidiaires … que tu n'a PAS accepté au moment de la vente (au moment où le vendeur, et donc ses fournisseurs, recoit ses sous).

Si tu veux une correspondance, c'est comme si, lorsque tu acheteait une voiture, tu es obligé de prendre l'assurance du copain (et de la conserver pour bénéficier de la garantie), et qu'on incorpore le prix de l'assurance dans le prix de la voiture, sans que tu n'ai jamais vu, nulle part, ce que tu paie pour la voiture, et ce que tu paie pour l'assurance…

il t'a pas donné la date de l'anecdote, si ?

Et en même temps, si ms avait pas foiré vista c'eut été recevable. Mais comme ce n'est pas le cas, et que l'upgrade est payante…

sous ubuntu je ne sais pas, mais je me souviens qu'une fedora avec kde, il y a déjà quelques années, il détectait tout seul que tu avais pluggé un nouvel écran et te proposait ce que tu voulais en faire (clone,étendu, quelle résolution), avec les options par défaut tout à fait utiles (bonne résolution et étendu de tête).

Par contre je ne me souviens plus si c'était arandr ou un autre frontend

okular marche souvent très bien avec leur pdf.

Tu n'es pas naïf au point de croire que parce qu'il y a des I/O standards pour les dialogues entre certains composants du système qu'aucun effet de bords est possible ?

Le respect des standard et des protocoles sert à ça.

Je suis "naif" car quand un soft est bien codé, il n'y a presque pas d'effet de bord.

Je n'ai encore jamais eu à "intégrer" un apache avec un firefox.
Et si j'ai un quelconque problème, je regarde qui ne respecte pas le standard ietf.

C'est quand même marrant où 99% des softs "daemon" fonctionnent sans avoir besoin d'intégration poussé (le chemin des fichiers de conf, et les scripts d'init et c'est à peu près tout), mais que pour 1%, sans raison, l'intégration ressemble à du voudou (le soft fonctionne mais prend bizarrement 15% du cpu sans raison à un moment X, …)

Pour prendre une comparaison automobile : quand je met un sac dans mon coffre, je ne m'attend pas à devoir changer de bouchon de radiateur.

Un logiciel tel que PA demande beaucoup d'effort d'intégration car de nombreuses applications y sont touchées (celles susceptibles de fournir du son

euh faut pas déconner, elles communiquent avec PA avec le "langage" propre à PA (ie son api)
Si il n'est pas capable de comprendre son propre "langage" sans avoir besoin qu'on le bichonne, c'est qu'elle est mal codé, point.

oui et non, cela reviendrais à accepter le principe de "délit continu" et je ne pense pas que beaucoup de juge accepterais.

Ensuite si on te redemande dans des affaires différentes, là oui tu auras une condamnation supplémentaire

Je ne dis pas que Debian fait de la merde, amis elle peut sur un logiciel rater l'intégration, ce n'est pas exclu.

Je n'ai jamais compris cette aspect "d'intégration" d'un serveur.

L'intégration d'une gui pour qu'elle offre un look& feel et une ergonomie identique au reste du système je comprend.

L'intégration d'un soft dans une infrastrucure (réseau, autres logiciels, …) aussi je comprends

Mais là on parle d'un soft qui
-> en entrée a son propre connecteur et protocoel
-> en sortie utilise le noyau linux et plus précisément la couche alsa, qui est standard

Il peut y avoir quelle intégration avec ça ?

charge machine faible ?
On a pas dut avoir le même PA (en tout cas au début de sa vie)

d'un autre coté, compiler en O2 ne rend pas les symboles de debug inutiles.
Juste que tu auras quelques problèmes sur quelques tests (comme indiqué, valeur optimisé etc…)

Donc, vu qu'on parle d'une compil à la main (donc possiblement un testeur), laisser les options de debug permet d'attaquer le debug quand on rencontre un problème, et le reste du temps d'utiliser le soft normalement

Si tu regarde les sources de openssh tu vois qu'il lui faut la clé publique dans le authorized_keys mais aussi
-> que le répertoire .ssh et le fichier authorized_keys appartiennent à l'utilisateur, soit ils appartiennent à root (et si c'est quelqu'un d'autre, il te demandera ton mdp)
-> groupe et other n'ont PAS le droit d'écriture.

Tu peux activer le debug dans sshd pour voir ce qu'il n'aime pas dans ton authent.

je sais pas si c'est un anarchiste, mais quand je vois l'armada de flics pour les 3000 morts sur la route, et quand je vois qu'a coté on laisse en libre service plus de 60 000 morts par an pour le tabac et plus de 40 000 morts par an pour l'alcool (et je ne parles pas de l'ensemble des malades et des contraintes sur les autres (violences, empoisonnement, …))

Ben désolé je reste dubitatif sur le fait que ce ne soit pas plus contrôlé.