Pur procès d'intention. Pourquoi est-ce que tu doutes ? Tu as des raisons objectives ou bien est-ce juste du FUD ? En quoi est-ce différent de la situation de Debian Wheezy ? C'est bien Ben Hutchings qui maintient le noyau 3.2 dans ce cas, alors pourquoi reprocher par avance à Ubuntu de maintenir le 3.13 ?
Parce que la décision n'as pas été prise arbitrairement sans concertation avec les autres projets. Le noyau 3.2 est supporté à la fois par Debian et Ubuntu ce qui réduit certainement la charge de travail. Si Debian base la version 8 sur le noyau 3.13, alors mon argument n'aura plus de poids. Ce n'est pas encore le cas.
Là encore il n'y a aucun argument factuel qui expliquerait que ce choix est mauvais.
Voici une liste de bugs qui pointe vers des problèmes techniques dans Upstart (https://lwn.net/Articles/582585/). Ces bugs ont été acceptés par le mainteneur d'Upstart (à l'époque) comme valides. Cela aurait peut-être dû les pousser à envisager une alternative plus tôt.
Il est évident qu'Ubuntu ne pouvait pas faire la transition vers systemd en quelques semaines, après la décision Mark Shuttleworth de suivre Debian et de basculer vers systemd.
Plusieurs choix s'offraient à eux, et ce n'est pas comme si cette décision n'était pas pressentie depuis un moment au vu du mouvement général des distributions vers systemd. Ils auraient pu aussi prévoir le coup et avoir gardé un paquet systemd à peu près fonctionnel sans le mettre par défaut (une grosse partie du boulot a été déjà fait par les autres distributions).
La seule critique que tu exprimes c'est que ce "sera donc supporté uniquement par les développeurs d'Ubuntu". Encore une fois ou est le problème ?
Les projets annoncés comme « morts » n'ont jamais attirés une foule de contributeurs volontaires. Les bugs mentionnés ci dessus datent pour certains de plusieurs années. Permets moi de douter fortement qu'ils soient corrigés dans Ubuntu 14.04.
Et puis de toute façon MariaDB est dans Universe.
Je n'avais pas connaissance de ce fait. Merci pour la précision, cette réserve n'a donc plus lieu d'être.
C'est faux puisque (..) on peut parfaitement changer la liste des serveurs. Cela se paramètre dans /etc/default/pollinate donc il n'est nullement nécessaire de faire confiance aux serveurs de Canonical.
C'est un argument auquel je réponds dans la suite : les options de configurations par défaut ne sont pas souvent changées et il est très peu probable qu'elles ne le soient jamais sur les clouds qui ne changent déjà pas les seeds des machines virtuelles.
Là encore il faut lire ce qu'écris Dustin Kirkland dans sa présentation : We are mitigating that (risk) by bundling the public certificates in the client. The pollinate package ships the public certificate of entropy.ubuntu.com.
Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Pourquoi pas un serveur local qui distribuerait la graine aux machines virtuelles ?
Si il est possible de mettre un serveur local pour le faire alors les autres solutions bien moins intrusives et tout aussi efficaces sont aussi réalisables.
Cela ne peux pas faire de mal (c'est comme RDRAND, on ne l'utilise pas exclusivement, on l'ajoute à tout le reste).
Le problème ici est qu'un attaquant aura connaissance d'une partie importante des données qui seront ajoutée dans la « pool » d'entropie, et peut potentiellement bruteforcer le reste des données dont il n'as pas connaissance.
Contacter inconditionnellement un serveur au démarrage d'une machine n'est pas non plus une action neutre en terme de sécurité. Que se passe-t-il si ce certificat est volé ou si une faille de sécurité est trouvée dans curl ?
Mais en quoi est-ce un problème ?
La quasi totalité des développeurs de la pile graphique sous Linux ne travaillent pas sous Ubuntu. Les projets annoncés comme morts n'attirent pas les contributeurs. De plus il leur faudra supporter à la fois Compiz et Mir pour les années à venir. Comme tous les projets, les ressources ne sont pas illimités et ils vont devoir faire de plus en plus de travail sans aide extérieure, ce qui impactera nécessairement le nombre de bugs qui seront corrigés.
Les autres distros aussi utilisent des trucs spécifiques quils sont les seuls à supporter.
Je veux bien des exemples. GNOME 3 n'en est pas un.
Sur LWN cette semaine on parlait de firewalld pour Fedora. Est-ce que tu vas beugler en disant que firewalld n'est supporté que par les devs de Fedora et qu'en conséquence on ne peut pas utiliser cette distribution ?
Non, parce qu'il est tout à fait possible de se passer de firewalld qui est chargé de la gestion des règles iptables. Trois commandes simples suffisent pour s'en débarrasser et rester dans une configuration complètement supportée :
systemctl stop frewalld
systemctl disable firewalld
systemctl mask firewalld
Il n'est pas du tout aussi facile de se débarrasser des modifications faites dans la pile graphique sous Ubuntu (il faut au minimum changer le noyau et mesa). Je veux bien un lien vers cette discussion sur firewalld.
Donc cela ne peut pas servir d'argument pour ne pas utiliser Ubuntu. Donc le citer est du pur FUD.
Je mentionne juste après la raison pour laquelle cet ajout affecte aussi ceux qui n'utilisent pas Mir sur Ubuntu.
Et puis conseiller Fedora 20 comme serveur...heu comment te dire...
Si mon texte est du FUD, où sont les arguments contre Fedora 20 sur un serveur ?
[^] # Re: Fallait attendre vendredi
Posté par Siosm . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à -5.
Parce que la décision n'as pas été prise arbitrairement sans concertation avec les autres projets. Le noyau 3.2 est supporté à la fois par Debian et Ubuntu ce qui réduit certainement la charge de travail. Si Debian base la version 8 sur le noyau 3.13, alors mon argument n'aura plus de poids. Ce n'est pas encore le cas.
Voici une liste de bugs qui pointe vers des problèmes techniques dans Upstart (https://lwn.net/Articles/582585/). Ces bugs ont été acceptés par le mainteneur d'Upstart (à l'époque) comme valides. Cela aurait peut-être dû les pousser à envisager une alternative plus tôt.
Plusieurs choix s'offraient à eux, et ce n'est pas comme si cette décision n'était pas pressentie depuis un moment au vu du mouvement général des distributions vers systemd. Ils auraient pu aussi prévoir le coup et avoir gardé un paquet systemd à peu près fonctionnel sans le mettre par défaut (une grosse partie du boulot a été déjà fait par les autres distributions).
Les projets annoncés comme « morts » n'ont jamais attirés une foule de contributeurs volontaires. Les bugs mentionnés ci dessus datent pour certains de plusieurs années. Permets moi de douter fortement qu'ils soient corrigés dans Ubuntu 14.04.
Je n'avais pas connaissance de ce fait. Merci pour la précision, cette réserve n'a donc plus lieu d'être.
C'est un argument auquel je réponds dans la suite : les options de configurations par défaut ne sont pas souvent changées et il est très peu probable qu'elles ne le soient jamais sur les clouds qui ne changent déjà pas les seeds des machines virtuelles.
Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Si il est possible de mettre un serveur local pour le faire alors les autres solutions bien moins intrusives et tout aussi efficaces sont aussi réalisables.
Le problème ici est qu'un attaquant aura connaissance d'une partie importante des données qui seront ajoutée dans la « pool » d'entropie, et peut potentiellement bruteforcer le reste des données dont il n'as pas connaissance.
Contacter inconditionnellement un serveur au démarrage d'une machine n'est pas non plus une action neutre en terme de sécurité. Que se passe-t-il si ce certificat est volé ou si une faille de sécurité est trouvée dans curl ?
La quasi totalité des développeurs de la pile graphique sous Linux ne travaillent pas sous Ubuntu. Les projets annoncés comme morts n'attirent pas les contributeurs. De plus il leur faudra supporter à la fois Compiz et Mir pour les années à venir. Comme tous les projets, les ressources ne sont pas illimités et ils vont devoir faire de plus en plus de travail sans aide extérieure, ce qui impactera nécessairement le nombre de bugs qui seront corrigés.
Je veux bien des exemples. GNOME 3 n'en est pas un.
Non, parce qu'il est tout à fait possible de se passer de firewalld qui est chargé de la gestion des règles iptables. Trois commandes simples suffisent pour s'en débarrasser et rester dans une configuration complètement supportée :
systemctl stop frewalld
systemctl disable firewalld
systemctl mask firewalld
Il n'est pas du tout aussi facile de se débarrasser des modifications faites dans la pile graphique sous Ubuntu (il faut au minimum changer le noyau et mesa). Je veux bien un lien vers cette discussion sur firewalld.
Je mentionne juste après la raison pour laquelle cet ajout affecte aussi ceux qui n'utilisent pas Mir sur Ubuntu.
Si mon texte est du FUD, où sont les arguments contre Fedora 20 sur un serveur ?