Moonz a écrit 3657 commentaires

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…

et qui reprend un laconique « vous verray ! » d'un populiste formé à l'école d'une bureaucratie mythomane qui a affamé son peuple pendant des décennies pour entretenir l'illusion de pouvoir faire la course à la puissance ?

Huh ?

Il n'y a pas d'outil équivalent sous Linux?

btrfs send pour btrfs. À ma (maigre) connaissance il n’y a pas d’équivalent pour ext*.

Les journaux sont supposés être une "création" personnelle, d'où le nom journal. Ils sont moins nombreux mais ils sont uniques.

{{référence nécessaire}}

et ils se font pas chier avec des packagings aussi complique

D’un autre côté quand on a pas de système de package avec gestion des dépendances c’est plus facile de gérer les mises à jour de l’arbre complet, effectivement.

Je savais pas que c’était possible de se suicider à l’hélium…

Pas besoin de télécharger le tarball des sources, ni de le dépaqueter avec arch?

Non, ça fait partie du PKGBUILD (l’équivalent du debian/rules), les sources sont listées dans une variable source, téléchargées et décompressées automatiquement lors de la création du paquet (avec vérification des checksums, support de sources git/svn/mercurial…)

Sans compter l’Afrique.

Tu n’as de toute façon pas une seule config pour toutes les versions de la distro vu que chez debian chaque version de la distro a une version upstream différente…

le principe de rétro-compatibilité, sont vraiment très importants.

Pourquoi ? C’est quoi l’intérêt de pouvoir construire un package d’il y a 10 ans sur une distrib d’aujourd’hui ? En quoi est-ce tellement plus important que d’avoir un système propre et clair aujourd’hui ?

Donc rien, c'est une fonctionnalité présente dans RPM, très bien. C'est le genre de truc que je m'attends à voir dans les outils d'empaquetage bien fournis, mais pas dans des trucs volontairement très simples, c'est tout.

Je connais pas les ports mais c’est possible avec les PKGBUILD, qu’on aura pourtant du mal à ne pas classer dans la catégorie « volontairement très simple »