lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
Et vous allez me faire croire qu'un admin ne sait pas gérer çà simplement ?
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
En gros, pour vous les Gentooistes sont incapables d'avoir une bonne méthode pour connaître les problèmes de sécurité
d'un soft sans la MAJ. Par exemple, si le OpenSSL nouveau débarque, ils ne sauraient pas ? Vous plaisantez là ?
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
Dans un monde de bisounours ton environnement est clean
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Dites vous croyez qu'ils sont stupides chez Nginx, ou dans le kernel.org pour préferer un JSON like ?
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Ca prouve qu'il ne sait pas de quoi il parle. J'arrive à faire chauffer mon processeur, donc il doit bien être capable de faire fonctionner ras la gueule un serveur.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
J'ai bien ri: on vous dira sûrement: il suffit d'écrire un script pour régler vos problèmes.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
2/ Si le gars a trop peur pour son système, il pourra toujours faire du git et/ou du svn avec son répertoire /var/* et/ou /etc/*
Avec un peu d'entraînement il va y arriver. Lorsqu'il maîtrise le processus, il automatisera la tâche…
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Systemd est refusé par deux distributions majeures et à peine acceptée par d'autres.
En effet, ils savent très bien que linux est tiré par RedHat, parce que RedHat a des sous, les autres moins.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Pourquoi ne pas l'avoir contruit avec un JSON like bon sang de bonsoir ?
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Où il m'a mis la patée ?
Un peu dans tout les commentaires. Dans celui la aussi.
Je dirais pour terminer que je souhaiterais que linux ne dépende pas trop de RedHat [freedesktop, xorg, pusleaudio, nouvel init (systemd), etc.].
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Un peu dans tout les commentaires. Dans celui la aussi.
ça va être dur :
http://community.redhat.com/contributions/
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.