Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.
Et allez on commence par une attaque. Tu es sur de toi là ? Non parce que supposons que j'arrive à démontrer que ce que je dis se tient tu fais quoi ?
Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne.
C'est juste des variables et des interfaces DBus ? Ouf tout va bien alors - ca devrait donc être possible à implémenter sous tous les systèmes qui ont un portage de DBus alors. Ah ben sauf que non, dans la liste que j'ai donné (et que je redonne http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) il n'y a quasiment que des "no" dans systemd Implementation portable to other OSes or non-systemd distributions et le reset c'est partially.
Une variable non portable c'est quoi ? C'est un caractère qui n'existe que sous Linux ? Une interface DBus non portable c'est un acte de divination que fait Linux mais que les autres implémentations n'ont pas ?
Si ces variables et ces interfaces sont non portables c'est qu'elles dépendent à leur tour d'autres éléments du système qui eux n'existent que sous Linux. Ce sont bien des dépendances au sens fort du terme. C'est à dire qu'il faut des éléments système actifs supplémentaires pour que la fonctionnalité soit présente.
Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?
On parle du systemd de maintenant que les distribs sont en train de nous déployer en prod en masse (sauf Red Hat qui se tate encore pour la 7, ce qui en soit devrait mettre la puce à l'oreille), ou du systemd qui existera peut être dans 5 ans ?
Non parce que le systemd d'aujourd'hui il a plein de chose qui sont gênantes pour pas mal de systèmes de chiffrement
a) Déjà le /usr doit être accessible - donc lui si il est chiffré il ne peut l'être que par une des deux méthodes compatibles aujourd'hui
b) Les virtual sockets foutent pas mal la grouille dans tous les chiffrements qui requièrent une synchro précise avec une base de temps extérieure. Ca peut se contourner en rajoutant des dépendances dans tous les sens (ie en ayant tout un pan du processus de boot qui s’exécute de façon séquentielle, donc systemd n'apporte plus rien à ce niveau là) mais systemd va mettre des batons dans les roues pour debugguer (si on oublie une dépendance, l'authentification va foirer, mais on aura aucun message permettant de comprendre pourquoi vu que le socket virtuel aura avalé l'erreur)
c) Je ne vois pas avec l'architecture actuelle comment systemd pourra gérer le chiffrement des partitions liés à un device interactif extérieur (par exemple un lecteur carte à puce dans lequel l'utilisateur doit insérer sa carte puis composer un code au bon moment pour que la partition se débloque). Vu les récentes discussions au sujet de udev et le point de vue du mainteneur actuel ca me semble mal parti pour être corrigé dans un délai court.
d) Dans la même veine, et même sans interaction avec la console je vois mal comment l'automount de systemd va gérer une clef usb (ou équivalent) insérée pendant le boot et qui contient un certificat nécessaire à la poursuite du boot.
Ca c'est pour les exemples qui me viennent en tête là maintenant. Mais honnêtement même un bête déchiffrement via auth kerberos externe pose des problèmes en ce moment.
En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.
Et que donc ça ne marche pas, mais c'est pour autant que l'on ne va pas le mettre en prod au détriment d'un système qui lui fonctionne. Ben voyons.
C'est tellement mieux un script bash avec un case à ralonge…
Pas de case à rallonge, juste un script qui parse un fichier de conf et attribue des variables. C'est assez courant en fait.
Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.
Donc
a) J'ai toujours dix services à maintenir (N.B : sur un système que je maintiens en ce moment les config sont auto-générées et stockées en base, je dois en avoir un peu plus de 3000 là - et non ca n'est pas une mauvaise utilisation du produit)
b) J'ai aussi un script de plus à maintenir pour lancer et enregistrer mes configs (sauf que je ne veux pas toutes les enregistrer, je ne lancerais jamais les 10 VPN en même temps sur ma machine, la plupart n'ouvriront que deux ou trois VPN différents maximum au cours de leur vie, mais je ne peux pas savoir d'avance lesquelles)
c) Au moment de mettre à jour les configs il faut que je me ramasse en plus des tests pour savoir dans quel état est systemd, et si le #@!$ de lien symbolique est en cours d'utilisation ou pas.
d) Il ne faut pas oublier de lancer le script de mise à jour après chaque modif des fichiers de conf, comme au bon vieux temps des premiers lilo. COOL
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte.... Évalué à 10.
Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.
Et allez on commence par une attaque. Tu es sur de toi là ? Non parce que supposons que j'arrive à démontrer que ce que je dis se tient tu fais quoi ?
Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne.
C'est juste des variables et des interfaces DBus ? Ouf tout va bien alors - ca devrait donc être possible à implémenter sous tous les systèmes qui ont un portage de DBus alors. Ah ben sauf que non, dans la liste que j'ai donné (et que je redonne http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) il n'y a quasiment que des "no" dans systemd Implementation portable to other OSes or non-systemd distributions et le reset c'est partially.
Une variable non portable c'est quoi ? C'est un caractère qui n'existe que sous Linux ? Une interface DBus non portable c'est un acte de divination que fait Linux mais que les autres implémentations n'ont pas ?
Si ces variables et ces interfaces sont non portables c'est qu'elles dépendent à leur tour d'autres éléments du système qui eux n'existent que sous Linux. Ce sont bien des dépendances au sens fort du terme. C'est à dire qu'il faut des éléments système actifs supplémentaires pour que la fonctionnalité soit présente.
Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?
On parle du systemd de maintenant que les distribs sont en train de nous déployer en prod en masse (sauf Red Hat qui se tate encore pour la 7, ce qui en soit devrait mettre la puce à l'oreille), ou du systemd qui existera peut être dans 5 ans ?
Non parce que le systemd d'aujourd'hui il a plein de chose qui sont gênantes pour pas mal de systèmes de chiffrement
a) Déjà le /usr doit être accessible - donc lui si il est chiffré il ne peut l'être que par une des deux méthodes compatibles aujourd'hui
b) Les virtual sockets foutent pas mal la grouille dans tous les chiffrements qui requièrent une synchro précise avec une base de temps extérieure. Ca peut se contourner en rajoutant des dépendances dans tous les sens (ie en ayant tout un pan du processus de boot qui s’exécute de façon séquentielle, donc systemd n'apporte plus rien à ce niveau là) mais systemd va mettre des batons dans les roues pour debugguer (si on oublie une dépendance, l'authentification va foirer, mais on aura aucun message permettant de comprendre pourquoi vu que le socket virtuel aura avalé l'erreur)
c) Je ne vois pas avec l'architecture actuelle comment systemd pourra gérer le chiffrement des partitions liés à un device interactif extérieur (par exemple un lecteur carte à puce dans lequel l'utilisateur doit insérer sa carte puis composer un code au bon moment pour que la partition se débloque). Vu les récentes discussions au sujet de udev et le point de vue du mainteneur actuel ca me semble mal parti pour être corrigé dans un délai court.
d) Dans la même veine, et même sans interaction avec la console je vois mal comment l'automount de systemd va gérer une clef usb (ou équivalent) insérée pendant le boot et qui contient un certificat nécessaire à la poursuite du boot.
Ca c'est pour les exemples qui me viennent en tête là maintenant. Mais honnêtement même un bête déchiffrement via auth kerberos externe pose des problèmes en ce moment.
En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.
Et que donc ça ne marche pas, mais c'est pour autant que l'on ne va pas le mettre en prod au détriment d'un système qui lui fonctionne. Ben voyons.
C'est tellement mieux un script bash avec un case à ralonge…
Pas de case à rallonge, juste un script qui parse un fichier de conf et attribue des variables. C'est assez courant en fait.
Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.
Donc
a) J'ai toujours dix services à maintenir (N.B : sur un système que je maintiens en ce moment les config sont auto-générées et stockées en base, je dois en avoir un peu plus de 3000 là - et non ca n'est pas une mauvaise utilisation du produit)
b) J'ai aussi un script de plus à maintenir pour lancer et enregistrer mes configs (sauf que je ne veux pas toutes les enregistrer, je ne lancerais jamais les 10 VPN en même temps sur ma machine, la plupart n'ouvriront que deux ou trois VPN différents maximum au cours de leur vie, mais je ne peux pas savoir d'avance lesquelles)
c) Au moment de mettre à jour les configs il faut que je me ramasse en plus des tests pour savoir dans quel état est systemd, et si le #@!$ de lien symbolique est en cours d'utilisation ou pas.
d) Il ne faut pas oublier de lancer le script de mise à jour après chaque modif des fichiers de conf, comme au bon vieux temps des premiers lilo. COOL