Moonz a écrit 3542 commentaires

Ben non, tu ne peux pas transférer de chaleur d’une source froide vers une source chaude sans fournir d’énergie.

je n'arrive pas à imaginer comment il pourrait en être autrement

Le canal de contrôle c’est effectivement un socket Unix (http://wayland.freedesktop.org/docs/html/sect-Protocol-Wire-Format.html), par contre le canal de données c’est de la mémoire partagée (http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_shm.html, http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_buffer.html).

(et peut-être encore autre chose si EGL rentre en jeu, mais j’avoue que j’ai pas regardé plus en détails)

Pourquoi ne pas faire comme gPass/WKR, c’est à dire ne garder que des données chiffrées côté serveur et laisser le navigateur faire le déchiffrage en Javascript ?

Euh non. L'init a besoin que quelque chose découvre le matos avant de booter, et c'est le rôle de udev

Du tout : même si c’était déprecié, tu pouvais utiliser devfs. Voire créer les fichiers à la main (j’ai ouïe dire que ça se faisait dans certains systèmes embarqué, mais j’avoue que c’est pas mon domaine).

Et dans l’autre sens udev ne dépendait pas d’un init particulier, tu pouvais l’utiliser avec initng, sysvinit, mudur, celui de slackware…

Quant à Linux c’est pas vraiment la question, udev était lié à Linux avant, il l’est tout autant avec systemd, pas de changement, je vois même pas ce qu’il y a à discuter là dessus…

Ben bah plus que dans l'ancien modèle, si ce n'est que systemd (le projet) a besoin de linux et pas un autre kernel. Encore une fois, je doute que ça change grand chose par rapport à l'ancien modèle (udev et les scripts SysV Debian tournent-ils sous BSD ? J'ai un gros doute là !)

udev non, les scripts init oui, c’est du bête shell, mais ce n’est pas la question, je ne parle pas du couplage entre l’OS et les différents composants mais des différents composants entre eux.

udev a-t-il besoin de systemd ? Non. C'est juste systemd qui a besoin de udev.

Tu as pas suivi ? udev sans systemd n’est maintenant plus supporté, autrement dit couplage fort entre les deux.

Je peux avoir le système d’init systemd sans le système de gestion de service de systemd ? Et dans l’autre sens ? Il me semble pas.

Et tu vois les choses de manière trop binaire, il y a tout un continuum entre totalement couplé/totalement découplé, et ce que je dis c’est que systemd pousse dans la première direction, ce qu’on peut difficilement nier, puisque c’est après tout un avantage que mettent en avant les défenseurs de systemd (« l’ancien système c’est un patchwork de trucs complètement indépendants qui arrivent tant bien que mal à donner un système fonctionnel, mais fonctionnel n’est ni optimal ni intégré, ce qui ne nous permet pas de lutter face à la concurrence Windows/OSX », pour caricaturer (un peu) le discours) et un objectif affiché du projet (faire un système homogène, unifié et intégré, et ça ça passe par plus de couplage, c’est les deux faces d’une même pièce).

Pourquoi essayer des analogies quand on peut parler de la vraie chose ?

Dans « l’ancien modèle », udev, init, le gestionnaire de service et getty sont totalement découplés.

Dans le nouveau modèle systemd, udev, systemd (init), systemd (gestionnaire de service) et (le successeur de getty dont j’ai oublié le nom) sont fortement couplés (ou plus objectivement, de plus en plus fortement couplés de version en version).

Tout ce que je dis, c’est que cette évolution :

1. existe
2. ne plait pas à certaines personnes
3. cette résistance est distincte de « les méchants réactionnaires qui aiment pas le changement »

Eric R

Hein ? Pourquoi ? Jamais entendu parler d’une sortie à la Linus ou TdR de sa part.

Et dans le cas de systemd, systemd (l'init) est indépendant de systemctl (le gestionnaire de services) : l'init n'a pas besoin de faire appel à systemctl pour booter.

Heu… source ? Parce que ce que tu es en train de dire, c’est que je peux par exemple prendre systemd en tant que /bin/init puis lancer initng (qui a besoin d’être PID 1) pour gérer mes services ?

Je peux me tromper, mais j’en doute énormément.

Et si je fais ça, les autres composants de systemd (journald, udev…) marchent toujours ? (sachant que le PID 1 n’est plus celui de systemd)

Dans le cas de SysV/Upstart/Pardus ça m'étonnerait que ce soit différent.

Ça l’est : leur gestionnaire de service était utilisable sur des systèmes sans leur init (j’ai essayé mais abandonné rapidement, préférant initng à l’époque). Tout ce dont il a besoin, c’est d’être PID 1 (c’est à dire que la seule chose nécessaire c’est que l’init puisse passer la main au gestionnaire de service une fois le système initialisé, c’était assez facile à faire sous Arch)

Mais elles ne sont pas fortes dans le cas de systemd : les outils qui le compose peuvent être remplacés.

Tu veux dire, un peu comme udev ?

Un système / programme sans dépendances : c'est un système / programme qui ne fait RIEN DU TOUT.

Ben non, si je reprend mon exemple de Pardus plus bas, leur système d’init (mudur) et leur gestionnaire de service (dont j’ai oublié le nom) étaient totalement indépendants (puisque j’ai pu utiliser l’un sans l’autre), et ils sont loin d’être inutiles.

Et pour reprendre l’exemple de sinma (projet GNU), emacs est indépendant de hurd.

De même, getty est indépendant de init, ça rend pas getty et init inutiles.

Gros paquet de nouilles interdépendant ≠ Monolithique

MacOS X n’est pas monolithique, bonne chance pour faire fonctionner son serveur graphique sans avoir tout ce qu’il y a autour. Postfix c’est plein de binaires différents et donc n’est pas « monolithique », ça n’empêche qu’ils fonctionnent de manière interdépendante.

Ben les fichiers de config aussi, et ça correspond aux scripts.

Non, du tout, si je compare à l’ancien init de Arch (connais bien moi le sysvinit classique), les scripts c’est pas seulement le démarrage des services, c’est aussi toute l’initialisation du système (/etc/rc.sysinit de mémoire), c’est à dire le montage des partitions, l’hostname, luks, lvm… et c’était typiquement pratique quand tu voulais jouer avec des trucs un peu bleeding-edge qui doivent se faire à l’initialisation du système : c’était juste un coup de vim /etc/rc.sysinit (à tes risques et périls bien sûr).

Pardus avait un système encore plus sympa avec l’équivalent de /etc/rc.sysinit écrit en Python (mudur je crois) qui passait ensuite la main à un gestionnaire de service à la systemd/initng. Je me souviens à l’époque de m’être fait un mélange des deux sous Gentoo, où l’init se faisait avec mudur et passait la main à initng — et ça marchait vraiment pas trop mal (et pour revenir dans le troll systemd, c’est justement ce genre d’expérimentations que le projet systemd va rendre de plus en plus difficile voire impossible).

Pas plus que le projet GNU qui comporte un interpréteur de commande, un noyau de système d’exploitation, une boite à outils graphique, un logiciel de dessin matriciel, un navigateur web, un système d’exploitation éditeur de texte, un langage de programmation, un compilateur, etc.

Je peux utiliser n’importe lequel de ces composants sans les autres, ils sont tous (ou presque) indépendants.

Moi j’aime bien systemd le système d’init, mais les trucs à la consolekit/policykit je les ai toujours fuis comme la peste. Lennart ne veut pas seulement faire plein de briques (j’ai rien contre ça, au contraire), mais il veut les « unifier », c’est à dire de faire de tout ça un gros paquet de nouilles interdépendant.

Tu ne peux pas comprendre l’opposition à systemd si tu persistes à dire « systemd c’est un projet, un peu comme GNU », c’est plus un projet comme Windows ou MacOS X, et c’est pour ça que ceux qui aiment le modèle Linux s’y opposent.

systemd divise suffisamment pour que Gentoo se fasse chier à continuer de maintenir des solutions alternatives (alors qu’à priori maintenir l’upstream c’est pas leur boulot à la base).

C’est pas une question d’historique (à priori on a toujours voulu de cette précision, c’est pas un changement), c’est une manière simple, concise et rapide d’expliquer une partie de l’algorithme, une manière élégante de dire « y * ( threehalfs - ( x2 * y * y ) ) c’est juste une manière de s’approcher du résultat, on peut le faire autant de fois qu’on veut pour avoir la précision souhaitée, mais pour ce qui nous intéresse, une seule itération suffit », moi qui ait jamais entendu « Newton-Raphson » avant aujourd’hui (et qui n’a rien compris du reste de l’algorithme), j’ai compris ça du premier coup. C’est donc un commentaire efficace :)

Pour le coup ça me choque pas, ça permet à quelqu’un qui reprend le code dans 10 ans et qui se dit « j’ai besoin d’un peu plus de précision » de voir du premier coup d’œil comment faire sans avoir à comprendre le reste du code.

C’est une mode apparue lors de la médiatisation de l’État Islamique dans les cercles conservateurs, pour montrer leur solidarité envers les chrétiens irakiens dans les villes occupées (leurs maisons étaient marquées de ce symbole de par la raison indiquée sur wikipedia)

Un rapide EHLO avec socat sur le serveur de mail de la boîte m’indique que oui.

Il n’y a rien à valider dans une variable d’environnement : du point de vue du shell le contenu d’une variable d’environnement n’est pas censé avoir la moindre sémantique.

Question bête, tu proposes de l’échapper comment, le () { ? Le shell ne défini aucune séquence d’échappement pour le contenu d’une variable d’environnement (et pour cause, une variable d’environnement n’a pas de sémantique)

Précisément, la frontière artisan/artiste est assez floue.

On peut dire la meme chose de gzip, xz, postgresql, ext4, et tout un tas d'autres trucs.

Déjà si ton système de fichier est inutilisable à cause d’un bloc corrompu tu devrais en changer très vite.

Pour gzip, postgres, xz, etc c’est pour ça qu’on fait des sauvegardes. Ça marche beaucoup moins bien pour les logs, parce que si problème il y a, il est certainement dans les logs… dans la partie corrompue non encore sauvegardée.

Scénario d’exemple : je sauvegarde tout à 5h du matin.

À 6h du matin il se passe je ne sais pas quoi qui corrompt à peu près tout.

Mes informations importantes, du point de vue base de données, sont dans les sauvegardes, donc pas de problème, j’ai eu une alerte SMS/mail, je bascule sur le système secondaire à 7h du matin et je restaure la base, tout le monde pourra bosser normalement en arrivant à 8h sans même savoir qu’il y a eu un problème.

Mes informations importantes, du point de vue du log, c’est ce qu’il s’est passé aux alentours de 6h. Ça a vachement intérêt à être lisible même avec un bon paquet de pertes, parce que ce qui est intéressant n’est par définition pas dans le backup (vu que tout tournait bien au moment du backup).

Bref c’est pas une question de systemd/reste du monde, c’est une question de log/reste du monde, le reste du monde peut se permettre de se reposer sur les sauvegardes en guise d’intégrité des données, les logs ne le peuvent pas, ils doivent se reposer sur eux-mêmes.

Parce que dhclient permet l’exécution de hooks (bien pratiques) et que pour transmettre un paquet d’informations (genre les routes, dns, etc…) à un hook les variables d’environnement sont un bon moyen.

Et en dehors de DHCP tu as dans la norme CGI le fait que toutes les entêtes HTTP sont exportées en variables d’environnement.

La dernière fois que j’ai testé, ça foirait lamentablement s’il y avait un sleep dans le rc.local (ou autre blocage type montage d’un FS réseau).

J’aime comment tu balaies d’un revers de main la difficulté de faire correctement de la distribution de clé. Si le canal avec le dev est pas sécurisé, comment peut-il te communiquer de manière sécurisée :
- l’identité de ce tiers ?
- sa propre identité ? (non parce que si en tant qu’attaquant j’ai juste à dire « je m’appelle moonz et je suis l’auteur de git-webui » pour te convaincre de télécharger ma version vérolée de git-webui…)

Il te faut un tiers connu avant l’échange. Tu peux m’en donner un là maintenant qui soit :
- suffisamment connu pour avoir confiance dans son intégrité (pas dguihal.ru ou moonz.ro quoi…)
- ait des procédures suffisamment sûres pour que je ne puisse pas m’inscrire avant alberthier et me prétendre comme étant lui
?

(on pourrait appeler ça « PKI », l’utiliser pour sécuriser des transactions HTTP qu’on renommerait pour le coup « HTTPs »… mais je m’égare)

Et de fait on s’éloigne du sujet, qui est: en quoi un "curl … | bash" est significativement pire que le cas médian/moyen (qui ne choque personne) qui n’est pas un machin signé avec une clé publique communiquée off-channel mais un simple tar.gz avec au mieux une somme de contrôle (sur le même canal de distribution) ? Et de toute façon, pourquoi diable aurais-tu plus confiance en un git-webui correctement signé d’un git-webui non signé vu qu’à priori tu ne connais de toute façon son auteur ni d’eve ni d’adam ?

Si le développeur n’est pas dans ton WoT (comme c’est généralement le cas) c’est comme md5.

Et tu peux faire confiance que le md5 publié correspond bien au code de l’auteur parce que ? …

c'est aussi avoir une confiance complètement aveugle non seulement en toi, mais aussi en toute la chaine des fournisseurs entre ton PC et mon PC

À partir du moment où tu comptes télécharger et exécuter son programme tu es de facto dans cette situation, indépendamment que l’installation se fasse avec un script bash, un paquet deb préparé avec amour, une suite d’instructions dans un README ou un installeur en .msi à utiliser avec wine…