Au dela de la récurence, c'est surtout les imprécisions apparentes qui me frappent, surtout qu'elles se cachent derriére une culture Unix étalé et assumé. Que je sache, la plupart des distros ont d'une part un installeur texte, et aussi une installaton automatisé. Ouais, faut sans doute lire la documentation pour le trouver, c'est scandaleux. Mais on peut pas raler sur "les distros linux deviennent trop pour les neuneus" et en même temps se plaindre qu'il faille avoir des compétences pour faire ce qu'on veut.
Quand au fait que des programmes ne marchent pas sans network-manager, j'en connait pas. Evolution et epiphany marche sans ( mais par défaut l'utilise, vu que c'est logique de se baser sur la configuration par défaut du systéme pour activer les fonctionnalités par défaut des programmes ). Gajim marche sans, Empathy aussi. Packagekit s'en sert pour determiner si la connexion est en 3g ou pas ( ie, est ce qu'il faut faire des mises à jour du cache ou pas ), mais pareil, il marche sans network-manager ( enfin, il part du principe qu'il peut faire la mise à jour ).
Donc si le sujet est "quand on touche à la configuration par défaut, il faut modifier la configuration d'autres outils", c'est juste logique.
J'ai jamais vu le moindre logiciel serveur refusant de tourner sans network-manager, mais je suis sur que l'auteur a des exemples tellement nombreux qu'il a pas cru bon de les donner.
Il connait pas nm-cli, comme dit plus loin ici. 4 ou 5 eme lien d'un moteur de recherche : http://fedoraproject.org/wiki/Features/NetworkManagerCmdline. Mais le premier est sur cnetwork-manager, qui est mort.
Donc ouais, ça bloque sans doute les résultats.
Il parle de vpn over ssh, et trés franchement, c'est une solution des plus baroques. Vu que pour faire ça, il faut d'abord passer root, faire un ssh -w ( depuis le compte root ) aprés avoir fait un tunctl des 2 cotés qui va bien, et mettre des permissions spécifiques pour changer l'ip du tunnel et laisser ssh écrire dans le device. Conceptuellement, c'est pas différent d'openvpn, mais c'est trés manuel. Et faire du vpn par dessus du tcp, c'est pas super. Et bien sur, tu doit te taper 1 interface par utilisateur du coté du vpn, ce qui est pas idéal ( ça monte pas pas trop à l'échelle ). Perso, je m'attendais à mieux de la part d'un security officier de netbsd que de faire faire des ssh en root et en se filant des permissions sur des devices.
Donc oui, faut passer à openvpn ( qui souffre pas des soucis suscités ), ou écrire son propre plugin. Il y a quelqu'un qui a fait un plugin pour iodine, donc c'est surement faisable ( même si c'est .
Et aussi, il a oublié le plugin pptp. Non pas que ça soit recommendé, mais si j'avais voulu troller, j'aurais mentionner ça pour l'exclure d'autant plus et pourrir nm. Et bien sur, il a aussi oublié le plugin pour openswan. Mais pareil, ipsec, c'est trop compliqué parce que c'est pas openssh.
Il parle de debugguer dbus, mais il connait pas les outils ( mdbus, d-feet, bustle ). Soit. En fait, c'est du pur FUD car il part du principe que :
1) dbus loggue dans journal et pas dans syslog
2) dbus loggue exclusivement dans syslog
3) dbus voit un traffic digne de la gare central de Shinjuku
Le 1 n'est pas vrai que je sache, et ne le sera peut être pas. Le 2 dépend de 1, mais que je sache, d'aprés la FAQ :
"You may run rsyslog or syslog-ng side-by-side with journald, and syslog messages will end up in both rsyslog/syslog-ng and the journal".
Quand à 3, si on part du principe que les desktops utilisent à fond dbus, un coup de dbus-monitor va montrer que le traffic est quand même loin de ses peurs et doutes. Et on peut imaginer que si ça devient si problématique, que quelqu'un va finir par écrire un outil capable de gérer ça.
Donc, le jour ou dbus et journal ne marcheront pas ensemble, il va falloir debugguer ça à l'ancienne, avec des -v, des --nofork et de gdb. Alors que si un soft random et syslog ne marche pas, faut débugguer ça à coup de -v, de --nofork, et de gdb. Vraiment, le futur me fait peur.
Donc bon, je lui souhaite bien du courage pour sa conclusion. Je peux comprendre la quête de simplicité, je peux comprendre que tout le monde n'aime pas les choix fait par Fedora, je demande même pas à comprendre pourquoi ou à convaincre. Mais le manque de sérieux d'une part des points soulevés me laisse songeur face à quelqu'un qui commence par aligner des compétences sur l'historique des systémes UNIX. Et même si je laisse le bénéfice du doute, j'en demeure pas moins plus que non convaincu, voir même échaudé par la communauté BSD.
[^] # Re: Ça sent le réchauffé...
Posté par Misc (site web personnel) . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 6.
Au dela de la récurence, c'est surtout les imprécisions apparentes qui me frappent, surtout qu'elles se cachent derriére une culture Unix étalé et assumé. Que je sache, la plupart des distros ont d'une part un installeur texte, et aussi une installaton automatisé. Ouais, faut sans doute lire la documentation pour le trouver, c'est scandaleux. Mais on peut pas raler sur "les distros linux deviennent trop pour les neuneus" et en même temps se plaindre qu'il faille avoir des compétences pour faire ce qu'on veut.
Quand au fait que des programmes ne marchent pas sans network-manager, j'en connait pas. Evolution et epiphany marche sans ( mais par défaut l'utilise, vu que c'est logique de se baser sur la configuration par défaut du systéme pour activer les fonctionnalités par défaut des programmes ). Gajim marche sans, Empathy aussi. Packagekit s'en sert pour determiner si la connexion est en 3g ou pas ( ie, est ce qu'il faut faire des mises à jour du cache ou pas ), mais pareil, il marche sans network-manager ( enfin, il part du principe qu'il peut faire la mise à jour ).
Donc si le sujet est "quand on touche à la configuration par défaut, il faut modifier la configuration d'autres outils", c'est juste logique.
J'ai jamais vu le moindre logiciel serveur refusant de tourner sans network-manager, mais je suis sur que l'auteur a des exemples tellement nombreux qu'il a pas cru bon de les donner.
Il connait pas nm-cli, comme dit plus loin ici. 4 ou 5 eme lien d'un moteur de recherche : http://fedoraproject.org/wiki/Features/NetworkManagerCmdline. Mais le premier est sur cnetwork-manager, qui est mort.
Donc ouais, ça bloque sans doute les résultats.
Il parle de vpn over ssh, et trés franchement, c'est une solution des plus baroques. Vu que pour faire ça, il faut d'abord passer root, faire un ssh -w ( depuis le compte root ) aprés avoir fait un tunctl des 2 cotés qui va bien, et mettre des permissions spécifiques pour changer l'ip du tunnel et laisser ssh écrire dans le device. Conceptuellement, c'est pas différent d'openvpn, mais c'est trés manuel. Et faire du vpn par dessus du tcp, c'est pas super. Et bien sur, tu doit te taper 1 interface par utilisateur du coté du vpn, ce qui est pas idéal ( ça monte pas pas trop à l'échelle ). Perso, je m'attendais à mieux de la part d'un security officier de netbsd que de faire faire des ssh en root et en se filant des permissions sur des devices.
Donc oui, faut passer à openvpn ( qui souffre pas des soucis suscités ), ou écrire son propre plugin. Il y a quelqu'un qui a fait un plugin pour iodine, donc c'est surement faisable ( même si c'est .
Et aussi, il a oublié le plugin pptp. Non pas que ça soit recommendé, mais si j'avais voulu troller, j'aurais mentionner ça pour l'exclure d'autant plus et pourrir nm. Et bien sur, il a aussi oublié le plugin pour openswan. Mais pareil, ipsec, c'est trop compliqué parce que c'est pas openssh.
Il parle de debugguer dbus, mais il connait pas les outils ( mdbus, d-feet, bustle ). Soit. En fait, c'est du pur FUD car il part du principe que :
1) dbus loggue dans journal et pas dans syslog
2) dbus loggue exclusivement dans syslog
3) dbus voit un traffic digne de la gare central de Shinjuku
Le 1 n'est pas vrai que je sache, et ne le sera peut être pas. Le 2 dépend de 1, mais que je sache, d'aprés la FAQ :
"You may run rsyslog or syslog-ng side-by-side with journald, and syslog messages will end up in both rsyslog/syslog-ng and the journal".
Quand à 3, si on part du principe que les desktops utilisent à fond dbus, un coup de dbus-monitor va montrer que le traffic est quand même loin de ses peurs et doutes. Et on peut imaginer que si ça devient si problématique, que quelqu'un va finir par écrire un outil capable de gérer ça.
Donc, le jour ou dbus et journal ne marcheront pas ensemble, il va falloir debugguer ça à l'ancienne, avec des -v, des --nofork et de gdb. Alors que si un soft random et syslog ne marche pas, faut débugguer ça à coup de -v, de --nofork, et de gdb. Vraiment, le futur me fait peur.
Donc bon, je lui souhaite bien du courage pour sa conclusion. Je peux comprendre la quête de simplicité, je peux comprendre que tout le monde n'aime pas les choix fait par Fedora, je demande même pas à comprendre pourquoi ou à convaincre. Mais le manque de sérieux d'une part des points soulevés me laisse songeur face à quelqu'un qui commence par aligner des compétences sur l'historique des systémes UNIX. Et même si je laisse le bénéfice du doute, j'en demeure pas moins plus que non convaincu, voir même échaudé par la communauté BSD.