Journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir

Posté par  (site Web personnel) . Licence CC By‑SA.
-14
29
avr.
2014

Sommaire

Ceci est une traduction de l'article publié sur mon blog personnel : Ubuntu 14.04 LTS: Why you should not use it, at all. La version anglaise est probablement plus fluide et mieux rédigée car elle a été la cible de la plus grosse partie du travail de rédaction.

Ubuntu 14.04 LTS (Trusty Tahr) vient juste de sortir (le 17 avril 2014). Cette version au support étendu (LTS) est donc toute fraîche. Pourquoi est-ce que je vous suggère alors de ne pas l'utiliser ? Ce journal détaille mes arguments.

Trop long, je ne veux pas tout lire: Quelle distribution(s) devriez-vous plutôt utiliser ?

Pour les serveurs ou les machines dans le "cloud":

  • Si vous pouvez vous permettre d'attendre un peu, choisissez Red Hat Enterprise Linux (RHEL) 7 (ou CentOS 7) ;
  • Si vous avez besoin de quelque chose tout de suite, utilisez soit :
    • RHEL 6 (ou CentOS 6) si l'age du noyau ne vous pose pas de soucis (vous pouvez utilisez les Software Collections pour obtenir des logiciels en espace utilisateur plus récents) ;
    • Fedora 20 si vous avez besoin de logiciels plus à jour (prévoyez de passer à RHEL 7 une fois disponible) ;
    • Debian 7 si vous êtes OK avec le système de gestion de paquets (passer à systemd et prévoyez la mise à jour vers Debian 8 qui utilisera systemd par défaut).

Pour les machines dites de bureau (ce qui inclut les ordinateurs portables) : Fedora 20 ou Arch Linux.

Votre distribution favorite n'est pas dans la liste ? Dommage, lâchez vous dans les commentaires.

L'avantage principal des versions LTS d'Ubuntu est que les logiciels sont mis à jour pendant cinq ans. Ces versions sont aussi supposées proposer des logiciels stables et matures qui s'insèrent bien dans l'écosystème logiciel actuel. Voici les raisons qui font que cela n'est pas du tout le cas et ne le sera probablement jamais avec cette version d'Ubuntu 14.04 LTS.

Raison 1 : Noyau Linux non supporté

Cette version inclut le noyau Linux 3.13. Cette version a apparemment été choisie pour assurer une plus grande compatibilité matérielle à la sortie d'Ubuntu. Ce critère est en effet important lors du choix de la version du noyau à proposer pour les machines de bureau (rappel, cela inclut les ordinateurs portables). Mais il l'est beaucoup moins lorsque l'on se penche sur le cas des serveurs où le matériel peut demander l'utilisation d'un noyau compilé particulièrement pour celui-ci ou encore dans le cas des machines virtuelles pour lesquelles le matériel n'est plus du tout un critère important.

Donc, pour assurer une bonne expérience utilisateur sur les machines de bureau, ils ont choisi une version qui n'est pas supportée sur le long terme par les développeurs du noyau. Cela signifie que les mainteneurs du noyau Ubuntu seront les seuls à rétro-porter les patchs de sécurité et les correctifs sans aucune aide de la communauté, pendant cinq ans. Je ne connais pas les personnes responsables du maintien des patchs noyau pour Ubuntu, mais je doute de leur capacité à réaliser ce fastidieux travail alors qu'aucune autre distribution ne le fera pour ce noyau. À terme de comparaison, Red Hat a choisi d'utiliser le noyau 3.10 (qui est supporté sur le long terme officiellement) pour RHEL 7, qui n'est pas encore sorti.

À mon avis, un choix judicieux aurait été de proposer deux noyaux :

  • le premier basé sur une version supportée pour les serveurs et les machines virtuelles (3.10 ou 3.12 par exemple);
  • le deuxième basé sur une version à jour du noyau pour les machines de bureau.

Cela aurait aussi éviter beaucoup de travail à l'équipe de mainteneurs du noyau car :

  • pour la version pour les serveurs, le travail aurait été en partie fait par la communauté ;
  • pour la version pour les machines de bureau, les paquets du noyau auraient pu être partagés avec les versions futures d'Ubuntu.

Vous pourriez être tenté de me rétorquer que cela risquerait de rendre le travail des administrateurs plus complexes. J'en doute fortement puisque la distinction entre la version serveur et la version bureau d'Ubuntu est clairement présentée sur la page de téléchargement et cela n'impacterait que le noyau utilisé par défaut lors de l'installation. Les deux versions du noyau seraient disponibles dans les dépôts et les utilisateurs/administrateurs pourraient changer de version si des soucis venaient à se produire.

Raison 2 : Upstart

Cette version d'Ubuntu inclut Upstart comme processus d'init et comme processus chargé de la gestion des services. Le choix a été fait de rester sur Upstart alors que la plupart des distributions avaient déjà fait le choix de migrer sur systemd et que Debian était en train de discuter la possibilité d'une telle migration.

Support

Le premier problème ici est lié au support d'Upstart qui est maintenant considéré comme étant un projet sans avenir, mais qui va devoir nécessiter du support pendant encore cinq ans. Certaines personnes (incluant Mark Shuttleworth) clament qu'Upstart est mature et bien supporté car il a été inclus dans une grande partie des distributions (avant que systemd ne vienne le remplacer) : par exemple RHEL 6, qui sera même encore supportée après les cinq de support de la version Ubuntu 14.04 LTS.

Je suis en désaccord total avec cette position. La plupart des fonctionnalités d'Upstart ne sont pas utilisées dans RHEL 6 par exemple. Upstart est uniquement utilisé comme intermédiaire pour lancer un imposant script « à la sauce SysVinit » qui fait tout le boulot : /etc/rc.d/rc.sysinit. Il n'y presque aucun « job Upstart » natif dans RHEL 6 (tty, gestionnaire de connexion à l'environnement graphique, support de control-alt-suppr et c'est à peu près tout). Ainsi, tout le reste n'est constitué que de scripts d'init. Donc les fonctionnalités de gestion des dépendances entre les services, de gestion des événements, de gestion du cycle de vie des services ne sont pas utilisées. Les seuls vrais utilisateurs d'Upstart sont les utilisateurs d'Ubuntu et le support vient uniquement des développeurs Ubuntu (et les services proposés dans les dépôts d'Ubuntu n'utilisent pas non plus tous Upstart).

logind

Avec cette erreur de jugement mise de côté, nous pouvons nous attaquer au démon logind, ou pour faire simple, une partie du projet systemd utilisée sans systemd.

La gestion des sessions été auparavant le travail de ConsoleKit, mais le développement de ce logiciel a été stoppé il y a quelques années. L'alternative moderne est le démon systemd qui fait partie du projet systemd. Mais systemd n'est pas utilisé dans Ubuntu. Ils ont donc dû inclure une version modifiée du démon logind pour le faire fonctionner sans systemd. Ceci n'est bien entendu pas du tout supporté par le projet « upstream » et donc uniquement testé par les développeurs d'Ubuntu.

Ainsi, il n'est pas possible de s'appuyer de façon sûre sur les fonctionnalités d'Upstart, les nombreuses fonctionnalités de systemd ne sont pas disponibles et le gestionnaire de session comporte des modifications sans support du projet officiel et sera donc supporté uniquement par les développeurs d'Ubuntu.

Raison 3 : Les services sont démarrés et ajoutés au démarrage par défaut lors de leur l'installation

Cette « fonctionnalité » est héritée de Debian : les services sont démarrés et ajoutés au démarrage par défaut lors de leur l'installation, avant même que l'administrateur ait eu l'occasion de les configurer. C'est un problème de sécurité parce que n'importe quelle erreur dans la configuration d'un service peut mettre en danger le système.

Les administrateurs consciencieux doivent d'abord arrêter les services démarrés le plus rapidement possible après l'installation pour pouvoir les configurer (et éventuellement les retirer du processus de démarrage). Cela réduit à néant le supposé avantage consistant à les démarrer par défaut.

Les réponses sur Serverfaults, AskUbuntu et AskDebian ne sont pas satisfaisantes et ne sont que des « hacks » non permanents. Pour les utiliser, il faut faire attention à bien les mettre en place avant chaque appel à apt-get et ensuite faire attention à bien les retirer. Rien de tout ceci n'est bien entendu supporté et il n'est plus possible d'utiliser juste apt-get install car il faudrait alors s'assurer qu'aucune des dépendances installées ne démarre automatiquement un service.

Démarrer les services par défaut introduit une nouvelle contrainte : il faut demander à l'utilisateur certaines informations lors de l'installation lorsque les valeurs de configuration par défaut d'un service qui ne peuvent pas être devinées automatiquement.

Enfin, les services sont aussi automatiquement redémarrés lors de leur mise à jour et il n'existe pas de moyen propre de bloquer ce comportement. Il est bien entendu important de redémarrer un service aussitôt que possible après une mise à jour pour qu'il en bénéficie, mais c'est une décision qui devrait être laissée à la charge de l'administrateur.

Toutes ces « fonctionnalités » font qu'un administrateur doit être particulièrement attentif lors de l'installation de paquets sur un système ou lors des mises à jour. C'est une conséquence malheureuse pour des fonctionnalités sensées rendre la mise à jour et l'installation des paquets plus simple.

Raison 4 : MySQL

La version de MySQL disponible dans les dépôts d'Ubuntu 14.04 vient directement d'Oracle. Mark Shuttleworth a justifié ce choix avec les arguments suivants :

It's very potent when we are able to give an upstream the ability to deliver their best bits directly to Ubuntu users using the awesome immediacy of the packaging system - we can only do that when we have established a shared set of values, and this is a great example.

As for phobias, the real pitchforks have been those agitating against Oracle. I think Oracle have been an excellent steward of MySQL, with real investment and great quality.

Ce qui peut se traduire par :

C'est un avantage notable de pouvoir donner à un développeur upstream la capacité de livrer directement la dernière version de leur logiciel aux utilisateurs d'Ubuntu, à l'aide du gestionnaire de paquets. Nous ne pouvons faire cela que lorsque nous avons établi qu'un ensemble de valeurs était partagé [entre les deux projets] et ceci en est un bon exemple.

En ce qui concerne les peurs (?), les enquiquineurs sont plutôt ceux qui ont prôné l'agitation contre Oracle. Je pense qu'Oracle est un excellent mainteneur de MySQL, avec un réel investissement et une grande attention portée sur la qualité.

Bien entendu, les développeurs de MariaDB, les créateurs originel de MySQL ont un point de vue différent sur la question, comme l'ensemble des distributions qui ont choisi MariaDB comme remplacement à MySQL. Ils ont aussi fait une comparaison au niveau des fonctionnalités et ont récemment annoncé la sortie de la dernière version de leur fork de MySQL.

Raison 5 : Choix de sécurité discutables

Pollinate

Pollinate est une nouvelle « fonctionnalité de sécurité » introduite dans les images cloud d'Ubuntu 14.04 LTS. C'est un script qui va récupérer des graines aléatoires à partir d'un ensemble de « serveurs fournisseurs d'entropie » pour « amorcer » (seed) le générateur de nombre pseudo aléatoire de Linux (PRNG). Il y a plusieurs inconvénients liés à cette approche (pensez à lire les commentaires aussi). Je vais essayer de les résumer ici.

Tout d'abord, le but principal de ce script est d'améliorer la qualité des « amorces » (seed) pour les instance d'Ubuntu déployées dans le cloud, lorsque qu'aucune source d'aléatoire n'est disponible (pas de pilote virtuel virtio-rng, pas d'entrée/sortie non prévisible, pas d'amorce générée avant le lancement individuellement pour chaque instance). Pour cela, il récupère des données aléatoires à partir d'un ensemble de serveurs et par défaut, ces serveurs sont ceux hébergés par Canonical, faisant fonctionner le service Pollinate qui retourne des données aléatoires à tous ses clients.

  • Premier problème évident : il faut faire confiance à cet ensemble de serveurs (bon, vous êtes déjà en train d'utiliser des logiciels fournis par la même entité qui héberge les serveurs, donc vous devriez déjà leur faire confiance de toute façon) ;
  • La première session TLS sera créée avec très peu d'entropie disponible, ce qui laisse à un attaquant la possibilité de soit complètement prendre le contrôle des échanges entre le serveur et le client (MITM ou attaque de l'homme du milieu) ou de déchiffrer le contenu de la communication lui donnant ainsi une quantité d'information non négligeable sur l'état d'amorçage du générateur de nombre pseudo aléatoire de l'instance dans le cloud.

Un effet de bord très « sympathique » de cette « fonctionnalité de sécurité » pour Canonical est qu'ils vont recevoir une demande d'entropie pour chaque nouvelle instance d'Ubuntu lancée dans un cloud qui n'aura pas changé la liste de serveurs d'entropie par défaut pour le script pollen. Comme pour la plupart des options de configuration par défaut, il est peu probable que les gens prennent le temps de la changer. Ainsi Canonical aura un nombre qu'il pourra utiliser pour se gargariser de l'importance du déploiement d'Ubuntu dans les clouds, même si ce nombre ne représentera pas grand chose puisqu'il pourrait y avoir bien plus d'instance déployées (dans les clouds privés) ou beaucoup moins (que se passe-t-il si j'effectue chaque construction et test de mon projet dans une nouvelle instance "propre" d'Ubuntu ?).

Comme expliqué dans les commentaires de ce post mentionné au dessus, la bonne façon d'amorcer le PRNG d'une machine virtuelle est de soit :

  • utiliser l'hôte pour générer un fichier avec du contenu aléatoire et l'insérer dans le disque de la machine virtuelle avant de la démarrer (virt-builder est capable de réaliser cette opération for example). Cette opération est indépendante de l'hyperviseur utilisé ;
  • activer le pilote virtuel VirtIO RNG dans le noyau de la machine virtuelle et d'utiliser l'option de configuration correspondante pour Qemu pour l'activer pour la machine virtuelle (documentation). Cela dépends bien évidement de Qemu et de KVM.

Note: Pollinate/Pollen est peut-être bien une façon efficace d'amorcer le PRNG d'une instance d'Ubuntu dans un « mauvais cloud », mais la question est : Est-ce que les bénéfices valent les risques encourus ? Je n'en suis pas sûr.

AppArmor

Note: Je suis biaisé sur ce sujet parce que j'ai principalement étudié le fonctionnement de SELinux.

J'ai récemment jeté un coup d'oeil au support d'AppArmor dans libvirt (implémenté comme driver/plugin sVirt).

Lorsqu'une machine virtuelle est lancée en utilisant libvirtd, un processus annexe (/usr/lib/libvirt/virt-aa-helper) génère un profil AppArmor à partir de la configuration XML de la machine virtuelle dans libvirt. Ce profil autorise les accès (au niveau de AppArmor) du processus Qemu à tous les éléments définis dans la configuration de la machine virtuelle. Parmi les éléments de configuration disponible, il y a le partage de dossiers depuis la machine hôte vers la machine virtuelle en utilisant la technique de « file system passthrough » avec le pilote virtuel VirtFS (Plan 9 folder sharing over VirtIO).

Le programme annexe virt-aa-helper traduira sans se plaindre n'importe quel chemin choisi comme partage (dans la configuration XML d'une machine virtuelle) en règles AppArmor accordant l'accès en lecture et écriture à ce chemin et à ses sous dossiers. Ceci désactive une bonne partie de la protection normalement offerte par AppArmor. Cette "fonctionnalité" seule ne permet pas de passer root sur une machine parce que le contrôle d'accès classique RWX UNIX (Discretionary Access Control ou DAC) est toujours appliqué (et les processus Qemu tournent sous un utilisateur restreint : libvirt-qemu). Mais cela supprime la partie « Obligatoire » dans le Contrôle d'Accès Obligatoire (Mandatory Access Control ou MAC) car un simple utilisateur autorisé à configurer des machines virtuelles pourra désactiver une partie des protections d'AppArmor pour des machines virtuelles.

Un exploit complet nécessitera d'abord un exploit pour s'échapper de la machine virtuelle pour pouvoir accéder à l'hôte, et ensuite un exploit local root classique qui ne sera pas gêné par AppArmor autant qu'il aurait dû l'être.

Le problème majeur ici est que ce modèle autorise des utilisateurs qui ne sont pas de confiance à influencer de façon significative le profil AppArmor utilisé pour une machine virtuelle.

Note 1: J'ai utilisé ici le pilote VirtFS parce qu'il n'empêche pas le processus Qemu de démarrer si l'accès un fichier ou un dossier particulier est refusé dû aux contrôles DAC, mais n'importe quelle entrée de configuration de type « device » dans la configuration XML pourrait être utilisée pour obtenir les mêmes résultats.

Note 2: Ce cas est un exemple où le « Contrôle d'Accès Obligatoire » (MAC) devrait empêcher les utilisateurs (et même les administrateurs) de faire une action stupide (partager le dossier /etc de l'hôte avec une machine virtuelle par exemple). Un des éléments important dans le modèle de « Contrôle d'Accès Obligatoire » est que la seule entité prenant des décisions lors de l'exécution doit être le noyau (le moniteur de référence), et que ces décisions doivent être basées sur une politique ayant été écrite dans un environnement de confiance et ayant été vérifiée avec soin. La génération même partielle de politiques lors de l'exécution et sous contrôle d'un utilisateur est une violation de ce principe.

Rien de plus que les autres

Dustin Kirkland a partagé le support d'une présentation qu'il a réalisé récemment. Ce qu'il faut noter ici : 99% de ce qui est mentionné dans cette présentation n'est pas spécifique à Ubuntu et est disponible dans toutes les autres distributions. Les 1% restant incluent la « fonctionnalité » présentée au dessus : pollen.

Raison 6 : Compiz & Mir

« OK, j'ai compris, il n'est pas raisonnable d'utiliser Ubuntu sur un serveur. Mais je l'aime beaucoup sur mon ordinateur de bureau / ordinateur portable. Je dois bien pouvoir le garder ? »

Malheureusement non, je vous le déconseille. La différence principale entre une serveur et une machine de bureau est l'interface graphique, ou plus globalement la « pile graphique » : cela inclut les pilotes de carte graphique dans le noyau, le serveur d'affichage, le compositeur, les bibliothèques OpenGL… Ubuntu se reposera ici aussi sur des logiciels qui ne sont plus supportés car elle utilise toujours Compiz comme compositeur, alors que le développement a été arrêté il a plus de deux ans. Unity est le seul environnement de bureau qui utilise encore Compiz et les développeurs d'Ubuntu sont les seuls à le maintenir.

Ils ont aussi choisi de travailler sur leur propre serveur d'affichage et compositeur : Mir. Cette décision a déjà été vivement critiquée :

Bien que Mir ne soit pas le serveur d'affichage par défaut dans Ubuntu 14.04, le code pour lui permettre de fonctionner a été ajouté dans mesa notamment et dans d'autres logiciels de la pile graphique. Cela signifie que ces logiciels sont compilés avec des patchs spécifiques à Ubuntu et supportés uniquement par les développeurs de Mir.

Autres supposées raisons devant vous pousser à choisir Ubuntu

Distribution Nombre de voix Pourcentage
Ubuntu 111 53,1%
CentOS + RHEL + Scientific Linux 49 + 21 + 2 = 72 34,4%
Debian 6 2,8%
Fedora 3 1,4%
OpenSUSE + SUSE Linux 3 + 3 = 6 2,8%
Non Linux + Autres 9 + 1 + 1 = 11 5,2%
------------- ---------------- ------------
Total 111 + 49 + 49 = 209 100% (99,7% avec les arrondis)

Rien d'impressionnant. Je suis presque inquiet pour Debian :).

Conclusion

Ubuntu 14.04 est une version au support étendu. Une partie des paquets installés par défauts (pour la version serveur et pour la version bureau) sont non supportés, ne sont plus développés, sont obsolètes et certains le sont depuis plus d'un an.

Je ne comprends pas comment il est possible d'accepter cet oxymore.

  • # OSEF

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 29/04/14 à 03:02.

    Qui utilise encore Ubuntu alors que Debian est prêt pour le desktop? Le seul problème c'est de trouver la netiso de l'installeur de testing sur le site web officiel de Debian. On pourrait lancer un concours dans les linux parties pour rigoler.

    • [^] # Re: OSEF

      Posté par  . Évalué à 7.

      Tu es mauvaise langue, le site de Debian s'est beaucoup amélioré par contre, il y a 4/5 ans…

      • [^] # Re: OSEF

        Posté par  . Évalué à 10. Dernière modification le 29/04/14 à 10:52.

        bah, compte le nombre de clics pour arriver jusqu'à ca : http://cdimage.debian.org/debian-cd/7.5.0/ia64/iso-cd/

        • on rentre dans des détails technique dont tout le monde se moque, sauf les informaticiens
        • je suis parti du site principal : https://www.debian.org/ (qui détecte mon désire de communiquer en Français ; un bon point)
        • je fais "obtenir debian" (1 clic)
        • je vois télécharger une image d'installation ??? (gniii) ; c'est quoi une image d'installation ?
        • zut, c'est pas le bon lien
        • je clic sur "une image d'installation complète" (2 clics) … ha bon … comment peut-on deviner qu'il faut cliquer sur ce lien, si on n'est pas au fait de la technique ?
        • je sais qu'il faudra cliquer sur "Télécharger les images des CD ou DVD par HTTP" ; mais c'est bien parce que je sais ce qu'est FTP et HTTP (3 clics). Au passage, on aura pu cliquer sur "… gidgo, bittorent. N'ayant pas de bitcoins, j'ai pas envie de cliquer sur ce lien. Et puis pourquoi ce n'est pas une image "live" par défaut qui est proposée a cette page : https://www.debian.org/CD/
        • on continue (https://www.debian.org/CD/http-ftp/) : encore plein de questions techniques dont tout le monde se moque éperdument. Je veux juste un CD ou DVD d'installation Debian que je puisse graver sur DVD. Stable et testing … c'est bien encore une question technique non ?
        • je clic sur "stable", parce que je sais que c'est ce qu'il me faut : args, je vois amd64, ia64, …
        • encore un clic et je me retrouve devant un beau listing issu du Web 0.9-beta.

        salutations.

        • [^] # Re: OSEF

          Posté par  (site Web personnel) . Évalué à 8.

          Attend, il faut cliquer ?

          Je veux installer Deubianne moi, pas faire de l'Internet.

          • [^] # Re: OSEF

            Posté par  . Évalué à 1.

            cliquer, tout le monde sait cliquer. Interpréter ce qui se cache sous le jargon informatique, c'est bien autre chose. Pour ma part, je n'éprouve aucun soucis avec la Debian, bien au contraire. Mais elle n'est pas tout a fait prete pour la mère de famille moyenne et en particulier pour ce qui concerne le site, mais aussi l'installateur.

            Coté ubuntu, ca va bien plus vite. Mais le site est en Anglais il me semble.

            • [^] # Re: OSEF

              Posté par  . Évalué à -10.

              En fait, en dehors de la France, les gens sont capables de parler anglais.

              • [^] # Re: OSEF

                Posté par  (site Web personnel) . Évalué à 6.

                Un petit coup de bashing anti-Français pas cher . As tu des faits quelconques montrant que nos concitoyens européens ou nos amis chinois ou japonais parlent mieux l'anglais que nous autres, pauvres français ? En tout cas, ça ne correspond pas à mon expérience personnelle (uniquement dans le cadre du boulot, donc des ingénieurs et/ou docteurs). Pour moi, c'est un peu pareil partout, y'en a des parfaitement bilingues, et beaucoup qui baraguinent un sabir anglais.

                • [^] # Re: OSEF

                  Posté par  . Évalué à 6.

                  As tu des faits quelconques montrant que nos concitoyens européens

                  Soyons honnete les allemands et Neerlandais parlent souvent bien mieux l'anglais que la majorite des francais mais bon apres tu as les italiens, les espagnols, les portigais et la c'est bien pire. En gros, au Nord de l'Europe ca parle pas mal anglais globalement et plus tu vas vers le sud plus c'est pourrit, la France etant au milieu le niveau est moyen.
                  Quoiqu'il en soit tous ces pays parlent bien mieux une autre langue que n'importe quel pays anglophone ou ils sont en enorme majorite des monolingues (pourquoi se fatiguer quand les autres font l'effort?).

                  • [^] # Re: OSEF

                    Posté par  (site Web personnel) . Évalué à 10.

                    En gros, au Nord de l'Europe ca parle pas mal anglais globalement et plus tu vas vers le sud plus c'est pourrit, la France etant au milieu le niveau est moyen.

                    En gros, les zones d'Europe où la langue maternelle est germanique parle bien l'anglais, qui est une langue germanique aussi. Alors que là où la langue maternelle est une langue slave ou latine, l'anglais est beaucoup moins bien parlé.
                    Quelque chose me dit qu'il n'y a pas que les méthodes d'apprentissage de la langue qui entrent en jeu.

                    Concernant l'Asie, de ce que j'en connais, hors des zones touristiques et des universités, ça parle anglais au moins aussi mal qu'en France.
                    Idem pour la partie non-anglophone de l'Afrique.

                    La connaissance libre : https://zestedesavoir.com

                    • [^] # Re: OSEF

                      Posté par  . Évalué à 1.

                      Si l'on regarde un peu ce que l'on pourrait appeler "l'utilite" des langues les neerlandais sont un peu mal barre avec tres tres peu de monde le parlant, les allemands c'est pas beaucoup mieux. Par contre, le francais c'est nettement plus developpe et ne parlons pas de l'espagnol.

                      En resume il y a plein d'explication pour expliquer la chose et la facon d'enseigner ne fait pas tout ca c'est clair mais bon en France les methodes utilises sont particulierement pourri. Combien d'entre nous on parle anglais plus de 1h en 7 ans d'enseignement d'anglais a l'ecole? Je dirais 5% a tout casser et je suis peut etre genereux.

                    • [^] # Re: OSEF

                      Posté par  . Évalué à 7.

                      les zones d'Europe où la langue maternelle est germanique parle bien l'anglais, qui est une langue germanique aussi.

                      Je vois au moins deux autres explications:

                      • Dans les "petits" pays (au sens de la taille de la population parlant cette langue dans le monde), ils sont quasi-obligés d'apprendre une langue étrangère (et notamment l'anglais) s'ils veulent s'en sortir
                      • Dans ces mêmes "petits" pays, les films passent souvent en VO à la télé. Du coup les gamins baignent dans l'anglais dès leur plus jeune âge…
                      • [^] # Re: OSEF

                        Posté par  . Évalué à 2.

                        Clairement, ce qui explique notamment pourquoi les slavophones (contrairement à ce qui est dit plus haut) sont assez généralement bons en langues, y compris en anglais.

                        • [^] # Re: OSEF

                          Posté par  . Évalué à 4.

                          ce n'est pas l'unique raison. J'avais assiste a une conf un jour ou un graph montrait les frequences utilise par les differentes langues et c'etait assez imteressant. En gros l'anglais se parle majoritairement sur une game de frequence, le francais sur deux gammes (quasi en opposition de l'anglais :) ) et le russe sur une gamme tres large qui utilise quasiment tout le spectre que la voix humaine peut atteindre.

                          • [^] # Re: OSEF

                            Posté par  (site Web personnel) . Évalué à 5.

                            Ouep, dans un de ces bouquins, Jean-Pierre Changeux explique qu'on n'utilise pas notre cerveau de la même manière pour la langue maternelle que pour les autres langues. Il dit que les sonorités d'une langue qui n'ont pas été entendues dans l'enfance sont perdues, que les français ne captent pas toutes les sonorités de l'anglais, tandis que le suédois les capte toutes.

                            • [^] # Re: OSEF

                              Posté par  . Évalué à 1.

                              Du coup, ça impliquerait que les russes soient meilleurs que la moyenne pour les langues, puisqu'ils exploitent dès l'enfance toute la gamme de la voix humaine?

                              • [^] # Re: OSEF

                                Posté par  (site Web personnel) . Évalué à 2.

                                Ça n'est pas suffisant pour être bon en langue, et il y a d'autre paramètres plus importants. C'est principalement fait que d'avoir les films en V.O. qui donne un avantage aux scandinaves.

                                • [^] # Re: OSEF

                                  Posté par  (site Web personnel) . Évalué à 2.

                                  En VO sous-titrée dans la langue d'origine alors.
                                  Parce que la VO sous-titrée dans ta langue maternelle ne t'apprends pas grand-chose de la langue d'origine, tant que tu n'a pas déjà une solide connaissance de cette langue - une connaissance suffisante pour cesser de lire les sous-titres. À la limite ça t'apprends des expressions et la sonorité de la langue. Ce qui est intéressant mais n'explique absolument pas facilité d'apprentissage de tout un pays.

                                  Si cette logique était vraie, je parlerais un japonais courant…

                                  La connaissance libre : https://zestedesavoir.com

                                  • [^] # Re: OSEF

                                    Posté par  . Évalué à 4.

                                    Ecouter en VO forme ton oreille et cerveau a pouvoir travailler avec des sonorites differentes et je ne sais pas pourquoi j'ai comme un doute sur le fait que tu regardais enfant en VO japonaise tes anims…

                                    • [^] # Re: OSEF

                                      Posté par  (site Web personnel) . Évalué à 3.

                                      Malgré tout, si tu n'as pas entendu durant ton enfance une sonorité cela ne nuit pas à devenir multi-lingues après même si cela demande des efforts supplémentaires. À force d'écouter tu devrais réussir à progresser même si l'apprentissage est tardif.

                                      • [^] # Re: OSEF

                                        Posté par  . Évalué à 3. Dernière modification le 30/04/14 à 14:50.

                                        Tout a fait d'accord avec toi. C'est comme cela que j'ai appris l'anglais et surement pas a l'ecole.

                                    • [^] # Re: OSEF

                                      Posté par  (site Web personnel) . Évalué à 4.

                                      Je n'ai jamais prétendu que j'avais regardé mes animes en étant enfant…
                                      D'autre part, le japonais est un mauvais exemple pour les sonorités, puisque les sonorités de cette langue se retrouvent pratiquement toutes en français (mais pas dans l'autre sens).

                                      Non, je me contentais de répondre à cet argument fallacieux qui dit que si tu regardes des séries ou des films en VO ça t'aide à apprendre une langue.

                                      C'est vrai, mais c'est ultra marginal tant que tu n'as pas les bases suffisantes pour te passer des sous-titres ou au moins les lires dans la langue d'origine.
                                      Tant que tu n'en es pas à ce niveau, le seul apport, c'est une meilleure compréhension des sonorité et quelques expressions. Autant dire, presque rien face à la grammaire et au vocabulaire.

                                      Il y a sans doute beaucoup d'explications qui font que les pays scandinaves ont de meilleurs niveaux en langue que la France. Entre autres :

                                      • Le fait que leur langue ne sert pratiquement que dans leur pays, donc toute communication internationale passe par une autre langue. Ce qui motive le gouvernement à promouvoir des méthodes d'enseignement efficaces, d'autant plus que ce sont des pays sensiblement plus petits (en terme de nombre d'habitants) que la France.
                                      • Les méthodes de langues utilisées dans le milieu scolaire sont bien meilleures que celles utilisées en France (pour diverses raisons, dont celle ci-dessus).
                                      • Le fait que l'on parlait ici de l'anglais. L'anglais est une langue germanique, comme les langues scandinaves (sauf le finnois), ce qui aide beaucoup à l'apprentissage.
                                      • La France a pendant longtemps eu une politique d'éradication des langues locales et des patois. Résultat : le français ne parle qu'une langue et jamais appris, jeune, à apprendre une autre langue.
                                      • Le français est une langue internationale importante (la 2ème langue de travail dans les organisations internationales juste après l'anglais), qui a pendant longtemps été la langue de travail à l'international, comme l'est l'anglais aujourd'hui. C'est fini, mais ça a quand même laissé une trace dans notre culture (couplés à d'autres facteurs) : pour un français, apprendre une autre langue apparaît moins comme une nécessité que pour d'autres personnes.

                                      La connaissance libre : https://zestedesavoir.com

                                      • [^] # Re: OSEF

                                        Posté par  (site Web personnel) . Évalué à 7.

                                        Puis cela implique également autre chose : tu as une quantité de ressources en français incroyable.
                                        Il est possible dans la plupart des domaines scientifiques (et culturels aussi) de se procurer des ouvrages de références en français (oui même en informatique) ce qui est plus délicat dans une langue qui concerne une dizaine de millions de personnes. Puis les communautés francophones étant plus grandes, tu as plus de ressources crées par elles…

                                        Du coup l'importance d'une langue étrangère peut être repoussée très loin dans le cursus scolaire ou professionnel d'où le retard.

                                      • [^] # Re: OSEF

                                        Posté par  . Évalué à 0.

                                        Non, je me contentais de répondre à cet argument fallacieux qui dit que si tu regardes des séries ou des films en VO ça t'aide à apprendre une langue.

                                        Ce n'est pas falalcieux, en gros pour apprendre a parler et a comprendre a l'orale une langue etrangere, quand tu n'as pas le don des langues, tu n'as pas beaucoup de solution:

                                        • tu vas vivre dans le pays et tu ne cotoies QUE des natifs et tu restes pas chez toi a regarder des anims dans une autre langue. En gros tu pratiques la langue avec les natifs.

                                        • Tu regardes/ecoutes des emissions tele/radio ce que tu veux dans la langue que tu souhaites apprendre mais ensuite il faut aussi pratiquer mais deja tu auras former l'oreille au sonorite de la langue en question ce qui est deja un grand pas.

                                        Quand aux methodes utilises dans les pays scandinaves elle est super secrete mais comme je suis gentil je vais te la donner. Elle consiste a …. ecouter et parler dans la langue. Pas a faire un quasi-uniquement un enseignement theorique.

                                        • [^] # Re: OSEF

                                          Posté par  (site Web personnel) . Évalué à 3.

                                          Tu regardes/ecoutes des emissions tele/radio ce que tu veux dans la langue que tu souhaites apprendre mais ensuite il faut aussi pratiquer mais deja tu auras former l'oreille au sonorite de la langue en question ce qui est deja un grand pas.

                                          Ce qu'il dit c'est que les sous-titres dans ta langue natale tue l'intérêt de la VO pour apprendre la langue car tu seras tenté de lire le sous-titre qui n'est pas celle de la langue écoutée.
                                          La VO c'est bien pour apprendre uniquement si les sous-titres sont dans la même langue, et pour suivre ça il faut un minimum de bagage quand même (regarder un film où pendant 1h30 tu ne piges rien aux dialogues, c'est long…).

                                          • [^] # Re: OSEF

                                            Posté par  (site Web personnel) . Évalué à -1.

                                            Rien d'autre à dire : écouter beaucoup une langue étrangère c'est bien pour l'apprendre, à condition de ne pas avoir de sous-titres dans ta langue maternelle. Sinon, tu lis les sous-titres et tu n'avances pas.

                                            C'est en ça que l'argument "les TV étrangères passent de la VO c'est pour ça qu'ils sont bons en langues à l'étranger" est invalide. Parce qu'ils passent de la VO sous-titrée.

                                            La connaissance libre : https://zestedesavoir.com

                                            • [^] # Re: OSEF

                                              Posté par  . Évalué à 9.

                                              Personnellement, j'ai beaucoup progressé quand je débutais en anglais en regardant en VO avec les sous-titres français. Ça permet de comprendre des bouts mais de quand même garder le contexte quand tu n'as pas compris quelque chose.

                                              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                              • [^] # Re: OSEF

                                                Posté par  . Évalué à 2.

                                                D'ailleurs, si je me souviens bien, d'avoir une traduction d'un document d'une langue inconnue vers une langue connue est ce qui à permis de comprendre la langue inconnue.

                                                Bon, je ne suis pas capable de me rappeler le nom des 2 langues en question ni celui qui à été donné à la tablette ( ou était-ce une pierre? ), désolé pour ça, je ne me suis jamais réellement penché sur l'archéologie.

                                                Toujours est-il que pour moi, oui, les sous-titre, ou plutôt, les documents traduits, permettent d'apprendre une langue. A condition de faire l'effort.

                                                • [^] # Re: OSEF

                                                  Posté par  (site Web personnel) . Évalué à 3.

                                                  Ce que tu cherches : la pierre de Rosette.

                                                  • [^] # Re: OSEF

                                                    Posté par  . Évalué à 1.

                                                    C'est ça, merci!

                                                    C'est tellement désagréable de pas se rappeller le nom exact des choses :/

                                                    • [^] # Re: OSEF

                                                      Posté par  . Évalué à 1.

                                                      C'est tellement désagréable de pas se rappeller le nom exact des choses :/

                                                      certes. Mais c'est bien mieux de se rappeler des concepts ou des idées que de leur nom, qu'ils fussent jolis ou non.

                                  • [^] # Re: OSEF

                                    Posté par  (site Web personnel) . Évalué à 7.

                                    tant que tu n'a pas déjà une solide connaissance de cette langue

                                    Eh bien maintenant, une grande majorité de français apprend l'anglais à l'école et à donc les bases. Un des problèmes des français est leur accent pourri, et à cause de ça ils ont la trouille de s'exprimer en anglais et ne progressent donc pas. Un autre problème est le vocabulaire plus littéraire que l'on apprend à l'école qui n'aide pas toujours à se débrouiller dans la vrai vie. Mais le plus gros problème est selon moi que l'oreille n'est pas assez habituée et qu'ils ne comprennent rien à l'oral et qu'il y a un gros décalage avec l'écrit, ce qui empêche de mener une conversation (c'est plus facile avec d'autre français, voire d'autre anglophones non natifs car l'accent est moins marqué).

                                  • [^] # Re: OSEF

                                    Posté par  (site Web personnel) . Évalué à 1.

                                    En VO sous-titrée dans la langue d'origine alors.

                                    Les scandinaves ont de nombreux films en V.O. sans sous-titrage.

                        • [^] # Re: OSEF

                          Posté par  (site Web personnel) . Évalué à 3.

                          Clairement, ce qui explique notamment pourquoi les slavophones (contrairement à ce qui est dit plus haut) sont assez généralement bons en langues, y compris en anglais.

                          Bémol : les Russes qui sont nombreux et dont la langue est comprises à l'étranger (en ex-URSS et en Europe de l'Est) sont largement plus mauvais que nous en langue étrangère. La majorité des gens ne parlent véritablement que leur langue maternelle.

                          • [^] # Re: OSEF

                            Posté par  (site Web personnel) . Évalué à 1.

                            les Russes qui sont nombreux et dont la langue est comprises à l'étranger (en ex-URSS et en Europe de l'Est) sont largement plus mauvais que nous en langue étrangère. La majorité des gens ne parlent véritablement que leur langue maternelle.

                            Alors là va falloir m'expliquer, même si ça devient de plus en plus vrais.
                            Mais même encore maintenant une grande quantité de Russes parlent le Français et le parle bien. Avant la création de l'URSS c'était encore plus courant.

                            kentoc'h mervel eget bezan saotred

                    • [^] # Re: OSEF

                      Posté par  (site Web personnel) . Évalué à 3.

                      En gros, les zones d'Europe où la langue maternelle est germanique parle bien l'anglais, qui est une langue germanique aussi.

                      C'est la première réaction que j'ai eu aussi quand j'ai lu le commentaire précédent.
                      Mais ma mère (prof d'Allemand) a fait durant toute sa carrière des échanges entres des lycéens et quand je me souvient de leur niveau il était clairement excellent (pourtant le Français est majoritairement Latine).
                      Mais il faut savoir aussi que leur programme de langue débute plus tôt et est aussi bien plus intensif que le notre (de mémoire 12H par semaines dés le primaire) donc quand on met les moyens quelque part les résultats sont là.

                      kentoc'h mervel eget bezan saotred

                      • [^] # Re: OSEF

                        Posté par  . Évalué à 4.

                        donc quand on met les moyens quelque part les résultats sont là.

                        Ça n'est pas qu'une question de moyens.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: OSEF

                      Posté par  (site Web personnel) . Évalué à -9. Dernière modification le 29/04/14 à 23:55.

                      Alors que là où la langue maternelle est une langue slave ou latine, l'anglais est beaucoup moins bien parlé.

                      Toujours à trouver le maximum d'excuses externes à soit, "pas ma/notre faute".
                      Maintenant, avec ta superbe théorie, explique-moi pourquoi les allemands parlent aussi super bien le français (quand ils disent "je parle que un petit peu français", ça veut dire que leur niveau est meilleur que le français qui dit "je parle très bien anglais").

                      Bref : foutaises, excuse pour éviter de voir que le problème n'est pas que les autres ont "plus de chance", juste qu'on est mauvais. Au mieux tu peux dire que les slaves et latins sont tous des feignasses en langue, mais pas que c'est plus difficile.

                      PS : ça ne veut pas dire que les autres sont tous meilleurs, le hasard fait que je suis actuellement à Tokyo et force est de constater que d'une même dans la capitale peu de monde sait parler anglais, et que de deux notre prononciation et compréhension des sons anglais sont… différents. La langue des signes est actuellement mon meilleur ami. Mais le faits qu'ils sont mauvais n'enlèvent rien au fait que les français soient mauvais aussi pour des raisons aussi interne que les japonais, pas pour des raisons externes.

                      • [^] # Re: OSEF

                        Posté par  . Évalué à 2.

                        Et on s'arrête au constat ? Si on s'arrête là on a aucune solution.

                        • [^] # Re: OSEF

                          Posté par  (site Web personnel) . Évalué à -6.

                          Personne qui reconnait qu'elle est malade à moitié guérie.
                          Force est de constater que la première moitié de la solution est déjà refusée.
                          Je ne m'arrête pas au constat, je propose qu'elle reconnaisse déjà qu'il y a un problème, en démontrant que les allemands savent bien parler français ce qui casse le pseudo argument des sons bla bla bla, mais ne peut pas non plus forcer une personne à accepter qu'elle est malade, c'est à cette personne de commencer à faire le travail sur elle-même. J'ai une belle démonstration qu'on en est encore au refus de reconnaitre qu'on est malade (les commentaires ici ne sont qu'une partie de ce que je vois).

                          • [^] # Re: OSEF

                            Posté par  . Évalué à 4.

                            Euh, moi je vois surtout des gens qui s'estiment super mauvais en anglais, je vois pas en quoi le constat est nié.

                      • [^] # Re: OSEF

                        Posté par  . Évalué à 3.

                        Maintenant, avec ta superbe théorie, explique-moi pourquoi les allemands parlent aussi super bien le français (quand ils disent "je parle que un petit peu français", ça veut dire que leur niveau est meilleur que le français qui dit "je parle très bien anglais").

                        Ah bon ? C'est nouveau ça ? Je suis allé plusieurs fois en Allemagne (et pas à la frontière, bien évidemment), et je ne me rappelle pas avoir rencontré un allemand qui parle super bien le français.
                        Je viens d'une commune jumelée avec une commune allemande, et les seuls qui parlaient correctement le français étaient ceux qui participaient activement à ce jumelage. Dans le cadre de ce jumelage, tous les élèves de ma classe qui apprenaient l'allemand ont eu un correspond allemand. Parmi ces correspondants, très peu parlaient bien le français (de même que peu de français parlaient bien l'allemand), le mien avait même abandonné l'idée de me parler en français. Par contre, pour la plupart, ils parlaient très bien anglais. Mieux que nous, et mieux que nous ne parlions allemand.

                      • [^] # Re: OSEF

                        Posté par  (site Web personnel) . Évalué à 4.

                        Maintenant, avec ta superbe théorie, explique-moi pourquoi les allemands parlent aussi super bien le français

                        Les Allemands qui parlent bien français sont peu nombreux. Il y en a probablement proportionnellement autant que de Français qui parle bien allemand (je précise car ton post peut laisser supposer que les Allemands parleraient en grande majorité bien le français).

                • [^] # Re: OSEF

                  Posté par  (site Web personnel) . Évalué à 4.

                  Un rapport de 2012 de l'Union Européenne montre que pour les langues étrangères, les Français sont dans la moyenne (ni les meilleurs, ni les moins bons) parmi les citoyens de l'UE : http://ec.europa.eu/public_opinion/archives/ebs/ebs_386_fr.pdf

                  • [^] # Re: OSEF

                    Posté par  . Évalué à 1.

                    Hum…
                    Quelle page? Parce que moi, sur la page 16, je vois un graphique qui indique que la France est à 19% de la population capable de tenir une discussion dans au moins 2 langues, alors que la moyenne de l'UE serait de 25%.

                    Nous sommes donc clairement en dessous de la moyenne, bien que pas les pires, en effet.

        • [^] # Re: OSEF

          Posté par  . Évalué à 6.

          Le truc, c'est que c'était pire avant.

        • [^] # Re: OSEF

          Posté par  . Évalué à 10.

          bah, compte le nombre de clics pour arriver jusqu'à ca : http://cdimage.debian.org/debian-cd/7.5.0/ia64/iso-cd/
          Et encore, tu es tombé sur les images iso d'installation pour Itanium. Peu de chance que tu réussisses à en tirer quoi que ce soit pour ton desktop.

        • [^] # Re: OSEF

          Posté par  . Évalué à 9.

          Sur la page principale de https://www.debian.org, il y a un bouton Télécharger Debian 7.5 en haut à droite. Ça mène vers une ISO qui permet d'installer en 32 ou 64 bits.

          Ce n'est pas ce que tu cherchais ?

          • [^] # Re: OSEF

            Posté par  . Évalué à 4.

            oui, mais visiblement, j'ai pas trouvé du premier coup. Comme quoi l'ergonomie d'un site, c'est un travail de fond. Sur ce coup, je plaide coupable, mais à 50%.

            • [^] # Re: OSEF

              Posté par  . Évalué à 4. Dernière modification le 29/04/14 à 19:24.

              Tu cherchais surtout la Netiso, ne soyez pas malhonnête très cher. :)

              EDIT: il ne m'a falu que 3 clicks… non là je ne pige pas, d'autant que la NetISO c'est pas pour Tata Monique, la même qui installe des OSX et Windows si facilement.

              • [^] # Re: OSEF

                Posté par  . Évalué à 8.

                Tata Monique, la même qui installe des OSX et Windows si facilement.

                Euh… non. OSX j'avoue que je ne sais pas, mais Tata Monique n'installera jamais Windows elle-même. Elle demandera à son neveu éventuellement.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: OSEF

                  Posté par  . Évalué à 2.

                  ah non, ce n'est pas prêt pour le desktop alors.

                  Si Monique et Michu ne savent pas installer Windows ou OSX seules, ça n'est pas prêt!

                • [^] # Re: OSEF

                  Posté par  . Évalué à 0.

                  '…) Tata Monique n'installera jamais Windows elle-même. Elle demandera à son neveu éventuellement.

                  Parce qu'elle n'ose pas essayer.

                  Mais le jour où le neveu ne peux pas (genre il est à des milliers de kilomètres), qu'il la rassure un peu et lui explique comment booter depuis un CD par téléphone, elle y arrive, sans plus d'explication. Exemple vécu.

                  • [^] # Re: OSEF

                    Posté par  . Évalué à 5. Dernière modification le 30/04/14 à 13:59.

                    Mais le jour où le neveu ne peux pas (genre il est à des milliers de kilomètres), qu'il la rassure un peu et lui explique comment booter depuis un CD par téléphone, elle y arrive, sans plus d'explication. Exemple vécu.

                    1) Elle continue à se reposer sur le neuveu

                    2) Cette situation serait tout autant possible avec Ubuntu.

                    Mais c'est même mieux avec Ubuntu, et si quand bien même elle n'arriverait pas à l'installer, en démarrant sur le CD ou clé USB, elle arrive sur un environnement live prêt à l'emploi, avec Internet et pourra utiliser sa machine en attendant la venue ou l'aide du neveu. Voire mieux, on peut lui prêter une certaine intelligence*, celle de poser la question à google. :)

                  • [^] # Re: OSEF

                    Posté par  . Évalué à 2.

                    Rate car il manque tout un tas de drivers et la va lui expliquer d'aller sur le site de Dell pour recuperer le driver de la carte reseau qui est manquant…

                    • [^] # Re: OSEF

                      Posté par  . Évalué à 2.

                      Rate car il manque tout un tas de drivers et la va lui expliquer d'aller sur le site de Dell pour recuperer le driver de la carte reseau qui est manquant…

                      Je saute dedans ou pas? Mmm… non. :)

                      • [^] # Re: OSEF

                        Posté par  . Évalué à 2.

                        Si tu prend la version fournit par dell c'est:

                        1 - triche :)
                        2 - pas forcement la version que tu veux. Actuellement chez Dell tu commandes un pc avec windows 7 et c'est l'OS qui est sur le PC. Par contre le CD fournit (quand il y a) c'est … windows 8. Ca va faire des surprises a tata si elle se retrouve avec ce truc.

        • [^] # Re: OSEF

          Posté par  . Évalué à 8.

          compte le nombre de clics pour arriver jusqu'à ça : http://cdimage.debian.org/debian-cd/7.5.0/multi-arch/iso-cd/debian-7.5.0-amd64-i386-netinst.iso

          je suis parti du site principal : https://www.debian.org/ (qui détecte mon désire de communiquer en Français ; un bon point)

          Je clique sur le gros bouton vert "Télécharger Debian 7.5"

          Voilà.

          salutations.

          • [^] # Re: OSEF

            Posté par  (site Web personnel) . Évalué à 8. Dernière modification le 29/04/14 à 16:41.

            Franchement, ce bouton, je ne l'avais pas vu non plus. Il n'est pas si gros que ça (ni même vert tant qu'on ne passe pas la souris dessus : juste du texte vert sur fond blanc… pas franchement voyant) et l'œil est plus facilement attiré par la masse le liens en bleu éparpillés dans toute la page dont l'énorme menu horizontal.

        • [^] # Re: OSEF

          Posté par  . Évalué à 10.

          compte le nombre de clics pour arriver jusqu'à ca : http://cdimage.debian.org/debian-cd/7.5.0/ia64/iso-cd/

          bin, j'ai cliqué une seule fois sur ton lien et j'y suis arrivé.

    • [^] # Re: OSEF

      Posté par  . Évalué à 7.

      Bof, suffit d'installer une stable et de l'upgrader.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: OSEF

        Posté par  . Évalué à 1.

        • [^] # Re: OSEF

          Posté par  . Évalué à 10.

          Hem, ceux qui croient qu'une Debian n'est pas facile à upgrader n'ont jamais essayé de le faire avec une Red Hat…

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: OSEF

            Posté par  . Évalué à 5.

            Depuis une installation fraîche c'est d'autant plus simple et rapide, il y a aussi la possibilité de faire une installation en mode expert.

            Après personnellement, j'ai prix l'habitude de télécharger mes images sur http://live.debian.net/.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: OSEF

            Posté par  (site Web personnel) . Évalué à 3.

            Mais RH dit que c'est pas supporté pour RHEL. Et pour Fedora, la communauté se bat depuis des années pour savoir si ça marche ou pas, et comment ( ie, preupgrade/fedup vs yum ). Y a pas moyen de tester de façon exhaustive, mais les gens le font et corrige à la main et disent de le faire. Et parfois, garder une vielle configuration montre des comportements inattendus dans les softs.

            Ça marche avec Debian, mais c'est pas non plus "j'ai rien à faire" comme on m'a vendu ça y a plusieurs années ( et dieu merci, sinon j'aurais pas eu de boulot à corriger ça ).

            • [^] # Re: OSEF

              Posté par  . Évalué à 3.

              Note que même si c'est pas supporté pour RHEL, c'est parfaitement possible mais y'a des manip particulières plus contraignantes que Debian (installer un initrd particulier puis booter dessus en appelant un kickstart spécifique, et terminer par un ménage dans les RPM installés).

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: OSEF

          Posté par  . Évalué à 7.

          Je trouve que c'est plutôt simple à upgrader.
          Il juste faire un changement de distribution dans le source.lst, puis faire un update, un dist-upgrade et un upgrade, non ? En tout cas chezmoicamarche™.

          Opera le fait depuis 10 ans.

          • [^] # Re: OSEF

            Posté par  (site Web personnel) . Évalué à 2.

            • Changement de distribution dans les sources ;
            • apt-get update ;
            • apt-get install screen ;
            • dans screen :
              • apt-get dist-upgrade ;
              • apt-get --purge autoremove $(deborphan) (relancer autant de fois que nécessaire) ;
            • reboot.
            • [^] # Re: OSEF

              Posté par  . Évalué à 1.

              Changement de distribution dans les sources ;
              apt-get update ;
              apt-get install screen ;
              dans screen :
              apt-get dist-upgrade ;
              apt-get --purge autoremove $(deborphan) (relancer autant de fois que nécessaire) ;
              reboot.

              Quel est l'intérêt de screen? je veux dire, à part avoir un tiling window manager pour gérer le contenu d'un terminal…
              Au passage, je me suis toujours demandé à quoi exactement sert deborphan. J'ai dû l'installer une fois ou deux, mais il n'a jamais été capable de virer le moindre paquet automatiquement. D'ailleurs, je n'ai toujours eu besoin au maximum que de 2 passes dans aptitude pour virer complètement un logiciel. ( ça m'arrive moins maintenant, mais à l'époque ou je cherchais encore mes marques j'ai pu aller jusqu'a installer/supprimer une 30aines de logiciels divers par semaine… histoire de tester. )

              En tout cas chezmoicamarche™.

              C'est sûr, après, tout dépend des logiciels que tu utilises. Certains sont plus ou moins bien maintenus, et si on tombe plus dans le moins que dans le plus, un ou deux peuvent péter.

              • [^] # Re: OSEF

                Posté par  (site Web personnel) . Évalué à 9.

                Quel est l'intérêt de screen?

                À éviter de te retrouver comme un con parce que ta connexion avec le serveur à été coupé en plein milieu du dist-upgrade.

              • [^] # Re: OSEF

                Posté par  . Évalué à 5.

                Quel est l'intérêt de screen? je veux dire, à part avoir un tiling window manager pour gérer le contenu d'un terminal…

                Reprise/Partage de la session screen. Ce qui peut être pratique en cas de problème ( réseau qui tombe, problème d'upgrade, reprise sur la console physique ou ssh , clavier qui se blo

                • [^] # Re: OSEF

                  Posté par  . Évalué à 0.

                  Ah, donc dans le cas d'une MaJ d'une machine distante alors?

                  Il me semble qu'apt fait les mises à jour de façon séquentielle ( d'abord le dl, puis la décompression et ensuite la configuration, par défaut et sans apt-utils si je ne m'abuse ), cependant, donc même si on perd la connexion ssh, je n'arrive pas à voir quelles pourraient être les conséquences?
                  Je veux dire, le système de paquet me semble assez robuste pour encaisser ce genre de situation? Enfin, je suppose qu'il faudrait que je me penche plus sur l'intérêt de cet outil, je pensais qu'il ne s'agit que d'un outil pour "fenêtrer" un terminal… mais il semble pouvoir faire plus?

                  • [^] # Re: OSEF

                    Posté par  . Évalué à 5.

                    Pas du tout, tu mets à jour un serveur à distance via SSH. L'installation des paquets est en cours (donc après téléchargement qui lui, peut être repris effectivement), ta connexion se coupe et pouf, état système incohérent et pas forcément facilement reprenable suivant quels paquets sont mis à jours. Alors qu'avec screen, ta connexion se coupe mais l'installation des paquets suit son cours dans un screen.

                    • [^] # Re: OSEF

                      Posté par  . Évalué à 1.

                      Ok, ça fait un peu comme nohup mais en mode interactif, si je comprend bien: détachement du processus de son lanceur?

                      • [^] # Re: OSEF

                        Posté par  (site Web personnel) . Évalué à 3.

                        En fait, screen gère des sessions que tu peux détacher du shell courant et rattacher à un ou plusieurs autres shells.

                        • [^] # Re: OSEF

                          Posté par  . Évalué à 1.

                          Ok, merci beaucoup pour toutes ces explications, je pense que je vais consacrer un peu de mon temps à lire la doc de ce truc, c'est bien plus utile que je ne le supposais.

  • # 3 jours de plus

    Posté par  (site Web personnel) . Évalué à 6.

    La version anglaise est probablement plus fluide et mieux rédigée

    n'aurait pas été plus mal pour améliorer le poil de la bête ;-) Là en début de semaine, c'est guère passionnant…

  • # Upstart, Debian

    Posté par  (site Web personnel) . Évalué à 10.

    Le choix a été fait de rester sur Upstart alors que la plupart des distributions avaient déjà fait le choix de migrer sur systemd et que Debian était en train de discuter la possibilité d'une telle migration.

    Donc si j'ai bien compris, le statu quo chez Debian est plus acceptable que chez Ubuntu. Ça me semble raisonnable d'attendre la décision du projet upstream avant de changer.

    • [^] # Re: Upstart, Debian

      Posté par  (site Web personnel) . Évalué à -5.

      Donc si j'ai bien compris, le statu quo chez Debian est plus acceptable que chez Ubuntu.

      Les situations ne sont pas du tout comparables. systemd est disponible dans Debian depuis un certain temps et fonctionne. Ce n'est pas le cas dans la version 14.04 d'Ubuntu (ils viennent juste de rendre systemd fonctionnel en prévision de la 14.10). Debian s'est donné les moyens de prendre une décision en mettant à disposition toute les alternatives.

      Ça me semble raisonnable d'attendre la décision du projet upstream avant de changer.

      Ont-il attendu que Debian passe sur Upstart pour passer sur Upstart ?

      • [^] # Re: Upstart, Debian

        Posté par  (site Web personnel) . Évalué à 10.

        N'importe quoi tes arguments (comme l'ensemble de ton journal), genre ils vont intégré systemd à l'arrache dans une LTS alors que ça fait des années qu'upstart est correctement intégré.

        • [^] # Re: Upstart, Debian

          Posté par  (site Web personnel) . Évalué à -5. Dernière modification le 30/04/14 à 02:55.

          genre ils vont intégré systemd à l'arrache dans une LTS alors que ça fait des années qu'upstart est correctement intégré.

          Je n'ai jamais dit cela. Comme Ubuntu n'a pas attendu Debian pour choisir d'utiliser et de développer Upstart, Ubuntu n'avait pas plus de raison d'attendre le choix de Debian pour se positionner sur le futur d'Upstart. Le travail d'intégration aurait pu démarrer bien avant.

          Ce travail d'intégration de systemd dans les distributions a déjà été en grande partie fait par toutes les autres distributions et par Debian. Il aurait peut-être été judicieux d'envisager de reporter la date de sortie de cette version comme cela avait été fait pour la version 6.06.

          • [^] # Re: Upstart, Debian

            Posté par  . Évalué à 10.

            Tu sembles grandement sous estimer la charge de travail nécessaire pour passer d'un système d'init à l'autre.
            D'autant plus qu'Ubuntu utilise toutes les features d'Upstart, particulièrement sur le téléphone où il fait partie intégrante du système de gestion du cycle de vie des applications ainsi que du système de sandboxing.

            Déjà qu'on est même pas sûr que systemd sera prêt sur Ubuntu 14.10 (dans le sens pas de régression par rapport à la version actuelle), il était clairement inenvisageable d'utiliser autre chose qu'Upstart dans la 14.04. Upstart est stable et éprouvé, sa maintenance pour 5 années supplémentaire ne devrait pas poser le moindre problème.

            Sur un autre point, je te ferais remarquer que l'intégration de systemd dans Debian est faite en collaboration avec Ubuntu. Ce n'est pas « Ubuntu contre le reste du monde » ici, comme j'ai l'impression que tu le laisse entendre.

            • [^] # Re: Upstart, Debian

              Posté par  (site Web personnel) . Évalué à -2.

              D'autant plus qu'Ubuntu utilise toutes les features d'Upstart, particulièrement sur le téléphone où il fait partie intégrante du système de gestion du cycle de vie des applications ainsi que du système de sandboxing.

              Si tu as un lien avec des informations à ce sujet je suis intéressé.

              Upstart est stable et éprouvé, sa maintenance pour 5 années supplémentaire ne devrait pas poser le moindre problème.

              Cette collection de bugs encore ouverts et acceptés laisse penser qu'Upstart n'est pas aussi stable qu'annoncé : https://lwn.net/Articles/582585/.

              Sur un autre point, je te ferais remarquer que l'intégration de systemd dans Debian est faite en collaboration avec Ubuntu. Ce n'est pas « Ubuntu contre le reste du monde » ici, comme j'ai l'impression que tu le laisse entendre.

              Je pointe les cas où Ubuntu est effectivement la seule distributions à supporter certains logiciels. Ce n'est en effet pas le cas pour systemd.

              • [^] # Re: Upstart, Debian

                Posté par  . Évalué à 3.

                Cette collection de bugs encore ouverts et acceptés laisse penser qu'Upstart n'est pas aussi stable qu'annoncé

                Ouhais enfin upstart est utilise depuis des annees et je n'ai jamais vu un plantage de sa part. Certes je ne suis qu'un exemple mais j'ai un enorme doute sur le non stabilite de upstart pour 99,99% des personnes mais peut etre as tu ete toi meme victime de sa non stabilite si oui donne nous un exemple.

                • [^] # Re: Upstart, Debian

                  Posté par  (site Web personnel) . Évalué à 0.

                  Ouhais enfin upstart est utilise depuis des annees et je n'ai jamais vu un plantage de sa part.

                  En informatique particulièrement, le fait que « cela marche » n'est pas significatif de la validité de l'approche employée, et ne signifie pas que l'on ne vas pas rencontrer de soucis lorsque que l'on va s'en servir de façon un peu plus intensive par exemple. Sinon on pourrait chmod 777 tous les fichiers et cela marcherait pour tous les utilisateurs lambda (Windows avec le compte administrateur par défaut ?) mais cela ne rendrait pas l'approche plus valide.

              • [^] # Re: Upstart, Debian

                Posté par  (site Web personnel) . Évalué à 7.

                • [^] # Re: Upstart, Debian

                  Posté par  (site Web personnel) . Évalué à 0.

                  Tiens, cadeau: https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd

                  Je l'attendais celle là. Je ne me suis pas contenté de prendre tous les bugs ouverts dans Upstart pour les balancer comme argument. Ici, les bugs (qui ont été regroupés par une autre personne que moi) concernent tous des fonctionnalités d'Upstart plus ou moins utilisées dans Ubuntu (pour le démon CUPS par exemple) mais qui sont acceptées comme étant cassées. Tous les fixs relatifs à ces bugs ont été sous forme de contournement dans les programmes impactés et rien n'as été fixé à la source dans Upstart. Je trouve cette situation plutôt étrange.

                  Si demain je veux écrire un job Upstart pour un démon sous Ubuntu, il va falloir que je prenne la doc, et que je retire toutes les fonctionnalités considérés comme cassées dans les bugs reports. Si ces bugs n'ont pas été fixés pour la LTS, il ne le seront pas plus tard.

              • [^] # Re: Upstart, Debian

                Posté par  . Évalué à 3.

                Si tu as un lien avec des informations à ce sujet je suis intéressé.

                Il y a cette page, mais je ne sais pas si elle est vraiment à jour par rapport à ce qui a été implémenté en pratique. Les grandes lignes sont là en tout cas.

                Cette collection de bugs encore ouverts et acceptés laisse penser qu'Upstart n'est pas aussi stable qu'annoncé : https://lwn.net/Articles/582585/.

                « Stable » ne veut pas dire sans bug (comme on te l'a fait remarquer, même systemd a des bugs !).
                Upstart est utilisé depuis des années dans Ubuntu sans que ça ne pose de vrai problème a ses utilisateurs. C'est un fait, ou une constatation si tu préfères. Si Upstart était vraiment non-maintenable et broken by design, il n'aurait pas été adopté par RedHat avant l'arrivé de systemd.

                Je pointe les cas où Ubuntu est effectivement la seule distributions à supporter certains logiciels. Ce n'est en effet pas le cas pour systemd.

                En fait je répondais à cette partie de ton commentaire précédent :

                Ce travail d'intégration de systemd dans les distributions a déjà été en grande partie fait par toutes les autres distributions et par Debian.

                Le travail d'intégration dans Debian (qui est loin d'être fini) étant fait avec les devs Ubuntu, je ne comprends pas le sens de ton "c'est des feignasses les gens d'Ubuntu, ils n'avaient qu'à faire un copier-coller depuis ailleurs et ça aurait juste marché pour la 14.04" (je schématise, mais c'est ce que j'ai compris de ton commentaire en tout cas).

                • [^] # Re: Upstart, Debian

                  Posté par  (site Web personnel) . Évalué à -4.

                  Il y a cette page, mais je ne sais pas si elle est vraiment à jour par rapport à ce qui a été implémenté en pratique. Les grandes lignes sont là en tout cas.

                  A en croire cette partie, l'intégration (pour la partie mobile si j'ai bien compris) consiste à effectuer les actions suivantes avant de lancer une application :

                  • Définir des variables d'environnement ;
                  • Définir quel profil AppArmor va être utilisé.

                  On a vu plus poussé (et plus difficile à reproduire avec systemd) comme intégration.

                  Rien ne pointe vers une difficulté particulière pour le passage à systemd et oui, je pense qu'il n'y a presque rien de plus à faire qu'un copier / coller des units systemd depuis une autre distribution et de tester cela. En plus, c'est typiquement dans ce genre de cas que le système de gestion de paquet de Debian est sensé être le plus efficace : changements massifs impactant un grand nombre de paquets de la même façon (ici le remplacement des jobs upstart par les units system).

                  « Stable » ne veut pas dire sans bug (comme on te l'a fait remarquer, même systemd a des bugs !).

                  Merci d'énoncer l'évident, tout logiciel a des bugs. Cf commentaire au dessus qui explique le problème avec ces bugs.

                  Si Upstart était vraiment non-maintenable et broken by design, il n'aurait pas été adopté par RedHat avant l'arrivé de systemd.

                  Encore une fois, Upstart a bien été utilisé dans RHEL / Fedora mais les services n'ont presque pas été migrés pour utiliser les fonctionnalités d'Upstart. Tout est resté sous forme de script SysVinit.

                  Je n'ai pas non plus dit que Upstart était broken by design et non maintenable, j'ai dit que le design de systemd était considéré comme meilleur et que plus personne ne serait intéressé par la maintenance d'Upstart.

                  Le travail d'intégration dans Debian (qui est loin d'être fini) étant fait avec les devs Ubuntu, je ne comprends pas le sens de ton "c'est des feignasses les gens d'Ubuntu, ils n'avaient qu'à faire un copier-coller depuis ailleurs et ça aurait juste marché pour la 14.04" (je schématise, mais c'est ce que j'ai compris de ton commentaire en tout cas).

                  Si le travail d'intégration est fait avec les développeurs d'Ubuntu pourquoi est-ce que systemd n'est pas disponible dans les dépôts de cette LTS ? La remarque "Il n'est pas supporté" n'est pas valide, il y a plein de logiciels non supportés dans les dépôts d'Ubuntu et même Red Hat propose parfois des "Technical Preview" qui ne sont pas supportés mais qui mettent à disposition des logiciels récents ou des fonctionnalités particulières.

                  • [^] # Re: Upstart, Debian

                    Posté par  . Évalué à 6. Dernière modification le 06/05/14 à 11:55.

                    Rien ne pointe vers une difficulté particulière pour le passage à systemd et oui, je pense qu'il n'y a presque rien de plus à faire qu'un copier / coller des units systemd depuis une autre distribution et de tester cela.

                    Ce n'est parce que tu pense qu'il n'y a rien à faire que ça se fait facilement, quand Ubuntu a fait le choix d'Upstart pour la 14.04, c'était encore sysv chez Debian et plusieurs prédisaient à un passage à Upstart plutôt à systemd. Et ce n'est vraiment pas un choix qui se fait rapidement en copier deux-trois unit chez les autres. Il y a la migration à tenir, la définition du réseau… Par exemple, pour l'instant le script d'init du réseau chez Debian est buggé, ça ne posait pas de problème avec sysv mais avec systemd, ça l'empêche de démarrer si une ligne du fstab contient un partage nfs. Ce n'est pas vraiment le genre de bug que tu as envie de trainer dans une version stable.

                    NdM: lien retiré car non pertinent

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Upstart, Debian

                      Posté par  (site Web personnel) . Évalué à 1.

                      Je pense qu'il y a une erreur dans le lien présent dans le commentaire parent. Il faudrait demander à un modérateur de le retirer.

                      • [^] # Re: Upstart, Debian

                        Posté par  . Évalué à 3.

                        Corrigé. Merci.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Upstart, Debian

                    Posté par  . Évalué à 6.

                    Rien ne pointe vers une difficulté particulière pour le passage à systemd et oui, je pense qu'il n'y a presque rien de plus à faire qu'un copier / coller des units systemd depuis une autre distribution et de tester cela.

                    Ouhais c'est ce que l'on disait pour Pulse audio…

  • # é è ai

    Posté par  (site Web personnel) . Évalué à 6.

    La gestion des sessions été => La gestion des sessions était

    Faute courante des gens qui ne font pas la différence entre les é è ai et :D

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

  • # Plus supporté

    Posté par  (site Web personnel) . Évalué à 10.

    Donc "supporté/développé par Ubuntu" équivaut chez toi à "pas supporté du tout"

    J'imagine que ça fera plaisir à tous ceux qui bossent chez eux.

    C'est pas comme si côté Desktop Ubuntu et ses dérivés étaient très répandus hein.

    • [^] # Re: Plus supporté

      Posté par  . Évalué à 4.

      et puis qui va utiliser une LTS pendant 5 longues années. J'en connais bien peu. Mais passer de LTS en LTS, c'est sans doute bien plus courant. Mais dans le fond, Siosm a tout de même raison. Mais je dirais que la cible des 5 ans, c'est plutot du coté du serveur.

    • [^] # Re: Plus supporté

      Posté par  (site Web personnel) . Évalué à -5.

      Donc "supporté/développé par Ubuntu" équivaut chez toi à "pas supporté du tout". J'imagine que ça fera plaisir à tous ceux qui bossent chez eux.

      La tournure fâcheuse de ma phrase de conclusion peut laisser sous entendre que c'est ce que je pense. Ce n'est pas du tout le cas. J'ai pris grand soin de préciser à chaque fois que les logiciels n'était plus supportés que par les développeurs Ubuntu. Il n'y a aucun jugement de valeur. C'est une constatation de la charge de travail grandissante qui ne sera supportée que par Ubuntu, pendant cinq ans, et ceci alors que les prochaines versions n'utiliserons pas les mêmes logiciels (Upstart/systemd, Compiz/Mir).

      C'est pas comme si côté Desktop Ubuntu et ses dérivés étaient très répandus hein.

      Le fait qu'une distribution soit populaire auprès des utilisateurs ne va pas réduire la charge de travail des mainteneurs.

      • [^] # Re: Plus supporté

        Posté par  (site Web personnel) . Évalué à 3.

        Donc Ubuntu se donne du boulot et tu as la profonde conviction qu'ils ne se donneront pas les moyens de le réaliser.

        Pur procès d'intention donc.

        Pour ma part j'ai la profonde conviction que s'ils se permettent de supporter autant de projets "morts" (faudra d'ailleurs que tu m'expliques comment tu peux qualifier de "mort" un projet alors que les devs Ubuntu s'en occupent. "repris" ou "forké", mais pas "mort"), c'est qu'ils ont prévu les équipes en face.

      • [^] # Re: Plus supporté

        Posté par  . Évalué à 6.

        J'ai pris grand soin de préciser à chaque fois que les logiciels n'était plus supportés que par les développeurs Ubuntu. Il n'y a aucun jugement de valeur.

        Bien sur que si : tu te sers de ca comme argument pour ta thèse "il vaut mieux ne pas utiliser ubuntu". Si c'est un argument pour dire qu'il ne faut pas utiliser ubuntu, tu y poses forcément une valeur négative.

  • # Fallait attendre vendredi

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 29/04/14 à 10:33.

    Je ne connais pas les personnes responsables du maintient des patchs noyau pour Ubuntu, mais je doute de leur capacité à réaliser ce fastidieux travail alors qu'aucune autre distribution ne le fera pour ce noyau.

    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 ?

    Le premier problème ici est lié au support d'Upstart

    Là encore il n'y a aucun argument factuel qui expliquerait que ce choix est mauvais. 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.
    Donc il n'y avait pas d'alternative à Upstart. Et cela ne pose pas de problèmes ! 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 ?

    MySQL

    Ce choix résulte sans doute d'un partenariat avec Oracle, tant mieux si ça fait rentrer de l'argent dans les caisses de Canonical. Et puis de toute façon MariaDB est dans Universe.

    Pollinate : Premier problème évident : il faut faire confiance à cet ensemble de serveurs

    C'est faux puisque, comme l'explique Dustin Kirkland dans sa présentation, 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.

    Pollinate : La première session TLS sera créée avec très peu d'entropie disponible

    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.
    Et là encore il est toujours possible d'ajouter des serveurs dans /etc/default/pollinate. Pourquoi pas un serveur local qui distribuerait la graine aux machines virtuelles ?
    Et ne pas oublier que tout ça va s'ajouter dans l'entropy pool du noyau. Cela ne peux pas faire de mal (c'est comme RDRAND, on ne l'utilise pas exclusivement, on l'ajoute à tout le reste).

    Compiz & Mir : Unity est le seul environnement de bureau qui utilise encore Compiz et les développeurs d'Ubuntu sont les seuls à le maintenir.

    Toujours le même argument ! Mais en quoi est-ce un problème ? Les autres distros aussi utilisent des trucs spécifiques qu'ils sont les seuls à supporter. 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 ?

    Bien que Mir ne soit pas le serveur d'affichage par défaut dans Ubuntu 14.04

    Donc cela ne peut pas servir d'argument pour ne pas utiliser Ubuntu. Donc le citer est du pur FUD.
    Je suis le premier à regretter la création de Mir. J'ai même écris un journal à ce sujet. Mais citer ce point alors que la 14.04 n'utilise pas Mir c'est un peu fort de café.

    En résumé ton texte me semble être en grande partie du FUD non supporté par les faits.
    Et puis conseiller Fedora 20 comme serveur…heu comment te dire…

    • [^] # Re: Fallait attendre vendredi

      Posté par  . Évalué à 10.

      On est d'accord que c'est du bon gros troll fudesque.

      Le plus risible étant de reprocher de fournir MySQL quand l'utilisateur demande MySQL. Si je veux mariaDB, je suis capable de faire un apt-get install mariaDB.

    • [^] # Re: Fallait attendre vendredi

      Posté par  . Évalué à 10. Dernière modification le 29/04/14 à 10:21.

      Et puis conseiller Fedora 20 comme serveur…heu comment te dire…

      Puisque tu ne le dis pas je vais le faire a ta place cela serait une enorme connerie. Fedora c'est une version de test et ne doit jamais etre utilise en prod surtout pas sur un serveur. Si tu veux du stable tu prend RedHat ou un des clones.

      • [^] # Re: Fallait attendre vendredi

        Posté par  . Évalué à 2.

        Et puis surtout la "durée de vie" d'une Fedora c'est très court. 13 mois il me semble.

        • [^] # Re: Fallait attendre vendredi

          Posté par  (site Web personnel) . Évalué à 3.

          Non, 2n + 1 mois pour n le nombre de versions de Fedora sorties depuis. En général comme il y a une version tous les 6 mois en effet ça dure 13 mois mais comme la version 21 va sortir en octobre/novembre (soit près de 6 mois en retards), il y aura la Fedora 20 et 19 qui auront un cycle de vie de 19-20 mois.

          • [^] # Re: Fallait attendre vendredi

            Posté par  . Évalué à 4.

            Ce n'est donc pas prédictible, ce qui peut être un problème pour l'admin sys qui veut prévoir ses déploiements à l'avance.

      • [^] # Re: Fallait attendre vendredi

        Posté par  (site Web personnel) . Évalué à -5.

        Fedora c'est une version de test et ne doit jamais etre utilise en prod surtout pas sur un serveur.

        Je ne conseille pas d'utiliser n'importe quelle version de Fedora, je conseille la version 20, qui est peut être la version de Fedora la plus testée à ce jour et dont le cycle de vie sera le plus long vu les retards de la version 21.

        Ce n'est donc pas prédictible, ce qui peut être un problème pour l'admin sys qui veut prévoir ses déploiements à l'avance.

        Encore une fois, je ne conseille pas d'utiliser Fedora sur un serveur sur la durée, je conseille de l'utiliser en attendant de pouvoir migrer sur CentOS 7 qui ne devrait pas tarder à sortir.

    • [^] # Re: Fallait attendre vendredi

      Posté par  . Évalué à 4.

      Je ne connais pas les personnes responsables du maintient des patchs noyau pour Ubuntu, mais je doute de leur capacité à réaliser ce fastidieux travail alors qu'aucune autre distribution ne le fera pour ce noyau.

      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 ?

      Je pense que cette partie fait référence au fait que le kernel 3.2 a été choisi pour faire de la maintenance sur le long terme, on voit sur https://www.kernel.org/ qu'elle est taggée longterm et que la dernière version est sortie le 9 avril. En plus du mainteneur chargée de produire la version, beaucoup de monde envoi des correctifs.

      Le kernel 3.13 n'est plus maintenu depuis le 22 avril par l'équipe kernel. Cela veut dire qu'en plus de tout le travail propre a la distribution, le mainteneur doit aller à la pêche pour récupérer tous les patchs correctifs qui passent pour les intégrer. En prime ces patchs ne seront pas prévus pour le kernel 3.13 et ne lui seront pas spécialement adressés.

      J'imagine qu'il va tenter d'intégrer tous les patchs de la 3.12 et probablement de toutes les autres longterm qui sortiront ensuite. Ça représente quand même un gros boulot, les patchs ayant tendance à toucher le code qui vient d'être modifié.

      • [^] # Re: Fallait attendre vendredi

        Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 29/04/14 à 11:35.

        Je pense que cette partie fait référence au fait que le kernel 3.2 a été choisi pour faire de la maintenance sur le long terme

        C'est Greg KH qui choisit les noyaux qu'il va maintenir en mode LTS. Actuellement seuls les noyaux 3.4.x et 3.10.x font l'objet de ce maintien LTS officiel.
        Après il y a d'autres développeurs qui décident de maintenir des noyaux en fonction de leurs besoins propres. On a par exemple Jiri Slaby qui maintient le 3.12.x et Ben Hutchings qui maintient le 3.2.x. Ils font ce travail dans git.kernel.org et c'est pour ça que ces noyaux sont listés sur la page de kernel.org mais ça ne signifie rien de plus.
        Ubuntu a annoncé qu'ils prenaient en charge la maintenance à long terme du noyau 3.13.x mais ils font ce maintien sur git://kernel.ubuntu.com/ubuntu/linux.git au lieu de le faire sur kernel.org.
        C'est la seule différence et le mainteneur ne doit pas plus "aller à la pêche" des patchs que Jiry ou Ben. Il leur suffit d'être abonné à la liste de diffusion stable pour voir passer les patchs et décider si ça s'applique au noyau qu'ils maintiennent.

    • [^] # Re: Fallait attendre vendredi

      Posté par  (site Web personnel) . Évalué à -5.

      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  . Évalué à 4.

        Si mon texte est du FUD, où sont les arguments contre Fedora 20 sur un serveur ?

        http://linuxfr.org/users/siosm/journaux/ubuntu-14-04-lts-pourquoi-il-vaudrait-mieux-ne-pas-du-tout-s-en-servir#comment-1535447

      • [^] # Re: Fallait attendre vendredi

        Posté par  . Évalué à 2.

        Il y en a ici.

        Pour être plus précis ( attention, je parle bien d'argument contre l'install sur un serveur de production, nous sommes d'accord! ):

        Fedora has a reputation for focusing on innovation, integrating new technologies early

        Intègre vite. Donc, peu de test, donc de bugfixes.

        Fedora has a relatively short life cycle: version X is supported only until 1 month after version X+2 and with approximately 6 months between versions this means that a version of Fedora is supported for approximately 13 months.[7] This promotes leading-edge software because it frees developers from some backward compatibility restraints, but it also makes Fedora a poor choice for product development, which usually requires long-term vendor-support.

        Ici, c'est expliqué pourquoi en prod c'est moyen… je vais pas paraphraser.

        The default desktop in Fedora is the GNOME desktop environment and the default interface is the GNOME Shell.

        Donc, par défaut, une interface graphique est installée? Pour un serveur? ( je sais, la plupart des distros aussi l'installent par défaut, et j'imagine que ça se désactive lors de l'install, mais je me mets au niveau de ton journal en restant sur le par défaut. )
        Vu que tu sembles ne pas aimer l'automatisme sur les serveurs ( après tout, un service installé ne devrait pas être automatiquement démarré, pas vrai? Après ton install de fedora, le serveur graphique fraîchement installé est bien démarré, pas vrai? ) tu ne dois pas trop aimer ça.

        Fedora uses the RPM package management system.

        Ah… moi, je préfère celui de Debian, donc celui Debian est mieux et celui de fedora/RHL mauvais. Je suis encore une fois à ton niveau quand tu dis "Debian, si on aime bien sa gestion de paquets".

        Basiquement, on m'a toujours parlé de Fedora comme d'une excellente distribution, à destination des dev et des early adopters.
        Donc, je ne pense pas qu'elle soit mauvaise, et avec une boîte comme RHL derrière, j'aurai tendance à avoir confiance dans la bête.
        Mais pas pour un serveur, sur lequel il est plus pertinent d'utiliser RHL elle-même ou Debian. En mode minimaliste. ( D'ailleurs, je n'ai pas apprécié quand Debian ont activé l'installation par défaut des paquets recommandés… par chance, ça se désactive, mais obligé de tout décocher à l'install de base, c'est dommage. )

        • [^] # Re: Fallait attendre vendredi

          Posté par  (site Web personnel) . Évalué à -3.

          Fedora has a reputation for focusing on innovation, integrating new technologies early

          Intègre vite. Donc, peu de test, donc de bugfixes.

          Les versions de Fedora intègrent quasiment les mêmes versions de logiciels que ce qu'il y a dans Ubuntu (Ils sont généralement un poil plus à jour). Par contre, quand il y a des bugs, il ne font pas semblant de ne pas les voir pour ne pas retarder la sortie d'une version (http://www.h-online.com/open/news/item/Ubuntu-10-04-LTS-delayed-by-last-minute-GRUB-bug-990277.html) et ils prennent le temps de les fixer et de tester les changements. C'est notamment pour cette raison que Fedora 20 est sortie si tard. Alors l'argument Fedora intègre plein de trucs donc il y a des bugs est complètement à côté de la plaque vu qu'ils prennent justement le temps de fixer les bugs quand c'est nécessaire. Bonus, ils essaient de fixer les bugs upstream en premier pour que tout le monde en bénéficie.

          Ici, c'est expliqué pourquoi en prod c'est moyen… je vais pas paraphraser.

          Fedora 20 (la version que je recommande) est encore un cas particulier, et son support est particulièrement long vu les retards de la version 21. De plus, je ne recommande Fedora 20 que comme palliatif en attendant RHEL/CentOS 7 qui sera de configuration très similaire, et de support bien plus long.

          Donc, par défaut, une interface graphique est installée? Pour un serveur? ( je sais, la plupart des distros aussi l'installent par défaut, et j'imagine que ça se désactive lors de l'install, mais je me mets au niveau de ton journal en restant sur le par défaut. )

          Par défaut avec Ubuntu tu installes la version desktop sur un serveur ? Non, tu prends la version serveur pour les serveurs. Fedora c'est pareil, il y a une version serveur qui n'installe pas d'interface graphique par défaut.

          Ah… moi, je préfère celui de Debian, donc celui Debian est mieux et celui de fedora/RHL mauvais. Je suis encore une fois à ton niveau quand tu dis "Debian, si on aime bien sa gestion de paquets".

          Je n'ai jamais dit que le gestionnaire de paquet sous Debian/Ubuntu était mauvais. Je ne l'aime pas personnellement ; j'ai donc ajouté la remarque "si vous êtes OK avec le système de gestion de paquets" parce que c'est un facteur à considérer. Je ne rentrerai pas dans le débat RPM/Deb et je n'aurais peut-être pas dû mettre cette mince remarque en premier lieu.

          • [^] # Re: Fallait attendre vendredi

            Posté par  . Évalué à 1.

            De plus, je ne recommande Fedora 20 que comme palliatif en attendant RHEL/CentOS 7

            Autrement dit, tu conseilles d'utiliser ce qui est, j'en ai bien l'impression, une version de test. Un peu comme si je conseillais aux gens d'installer Debian testing sur des serveurs de prod en somme.
            Chose amusante, j'ai vu passer des thread sur la ml ou la plupart des interlocuteurs considéraient qu'il valait mieux utiliser unstable ou stable que testing sur un serveur de production. Avec un certain nombre d'arguments pertinents pour ceux qui préféraient stable et/ou unstable.

            Par défaut avec Ubuntu tu installes la version desktop sur un serveur ? Non, tu prends la version serveur pour les serveurs.

            Je ne sais pas, je n'ai pas installé de Ubuntu depuis… 6-7 ans, peut-être?
            En tout cas, avec Debian, je ne crois pas qu'il existe une version serveur/desktop ( si c'est le cas, je ne suis pas au courant ).
            Il ne s'agit que d'une option lors de l'installation ( on sélectionne les tâches que la machine sera amenée à exécuter ). Je t'avoue, je ne suis pas un grand fan de cette approche ( pour être plus précis, je trouve qu'ils n'ont pas poussé assez loin, mais bon, facile à dire sans contribuer… ), mais au moins, il suffit d'une iso pour les installer toutes.

            et je n'aurais peut-être pas dû mettre cette mince remarque en premier lieu.

            Sur un journal déjà très trollifère, si ce n'était pas le but de troller, c'est clair. Sinon ça à sa place :D

      • [^] # Re: Fallait attendre vendredi

        Posté par  . Évalué à 2.

        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.

        Ca s'appelle du SSL Pinning. Le client refuse de continuer si le certificat présenté par le serveur n'est pas le meme que celui present cote client.
        En clair: a moins d'avoir la cle privee du certificat, ton homme de le milieu il va être dur.

        Tu l'as super mal prepare ton troll quand meme, tes arguments sont tous bateaux et tu passes surtout pour un clown quand tu réponds.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Fallait attendre vendredi

          Posté par  (site Web personnel) . Évalué à -4. Dernière modification le 03/05/14 à 21:43.

          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.

          Ca s'appelle du SSL Pinning. Le client refuse de continuer si le certificat présenté par le serveur n'est pas le meme que celui present cote client. En clair: a moins d'avoir la cle privee du certificat, ton homme de le milieu il va être dur.

          Encore une fois, ce n'est pas du tout de cela dont je parle.

          Rappels sur l'établissement d'une session TLS :

          • ClientHello: Le client envoie la liste des algo supportés ;
          • ServerHello: Le serveur choisit une version du protocole TLS et quelle "CipherSuite" sera utilisée. Ceci indique entre autre la méthode utilisée pour échanger la clé qui sera utilisée par la suite ;
          • Certificate: Le serveur envoie son certificat ;
          • ServerKeyExchange (optionnel suivant les méthodes) et ClientKeyExchange : Échange de clés pour établir le secret utilisé pour chiffrer le contenu de la session ;
          • ServerHelloDone: Fin du handshake.

          L'élément qui pose problème ici est que l'échange d'information (Key Exchange) pour établir la clé de chiffrement se fait avec très peu d'entropie du côté client vu que le client pollen est exécuté très tôt au démarrage du système, avant que les autres services ne se lancent.

          Si l'on prend l'exemple de l'algorithme d'échange de clé Diffie-Hellman, et en considérant que le secret généré aléatoirement par le client n'est pas si aléatoire que cela, alors il est très facile pour un attaquant de déterminer le secret partagé obtenu à la fin de l'échange à partir des informations envoyées par le serveur. Il n'a qu'à essayer tous les nombres aléatoires potentiellement générés par le client qui ne dispose pas d'une bonne entropie.

          Cela s'applique aussi aux autres algorithmes d'échange de clé parce qu'ils reposent tous sur le principe que le client (au minimum) a généré un nombre aléatoire que lui seul connaît. Ce n'est pas une faiblesse du protocole, seulement un prérequis.

          Donc la clé de chiffrement de la connexion TLS peut être obtenu par une personne positionnée en man in the middle entre le client et le serveur, ce qui lui permet ensuite de déchiffrer le contenu de la connexion et donc d'obtenir les données aléatoires renvoyées par le serveur, et donc d'obtenir une très grande partie des informations qui seront par la suite utilisées pour amorcer le PRNG.

          Tout ceci n'est même pas de moi. C'est ce qui est expliqué dans ce post et les commentaires qui suivent, que j'ai déjà mentionné dans l'article.

          Tu l'as super mal prepare ton troll quand meme, tes arguments sont tous bateaux et tu passes surtout pour un clown quand tu réponds.

          Je suis presque déçu que cela ai été perçu comme un troll. Je ne me permets pas non plus de traiter les autres de clown. Par contre beaucoup de gens se sont permis de se débarrasser de mes arguments (qu'ils soient bons ou mauvais) en les traitant de FUD, ou en me traitant d'incompétent, ce qui simplifie bien les choses.

  • # Mr Pernickety

    Posté par  . Évalué à 2. Dernière modification le 29/04/14 à 09:01.

    Bon article,

    Juste un petit correctif, sur la version anglaise. Ça me fait mal aux yeux:

    Dans le paragraphe sur AppArmor:
    an helper process => a helper process

    Voilà, mes deux cents…

  • # Mouarf

    Posté par  . Évalué à 10.

    Debian 7 si vous êtes OK avec le système de gestion de paquets (passer à systemd et prévoyez la mise à jour vers Debian 8 qui utilisera systemd par défaut).

    Donc, Red Hat, on peut la prendre même si on n'est pas OK avec le système de gestion de paquet ?

    Sinon, pourquoi justifier de passer à systemd 44 sous Debian 7 alors qu'il est pris en charge que par Debian alors que c'est un problème pour Ubuntu et le noyau ?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Mouarf

      Posté par  . Évalué à 3.

      Sinon il y a la version 204 en backports, mais je ne suis pas sûr que la sécurité soit aussi suivie.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Mouarf

      Posté par  (site Web personnel) . Évalué à -3.

      Donc, Red Hat, on peut la prendre même si on n'est pas OK avec le système de gestion de paquet ?

      J'attends les arguments contre le format de paquet RPM :).

      Sinon, pourquoi justifier de passer à systemd 44 sous Debian 7 alors qu'il est pris en charge que par Debian alors que c'est un problème pour Ubuntu et le noyau ?

      C'est pour cela que je suggère de prévoir tout de suite la migration vers Debian 8 qui supportera une version plus à jour de systemd. La taille et la complexité du projet systemd n'est pas non plus comparable à celle du noyau ou encore à celle des éléments de la pile graphique.

      • [^] # Re: Mouarf

        Posté par  . Évalué à 3.

        J'attends les arguments contre le format de paquet RPM :).

        Et moi ceux contre les deb? Pour le moment, dans ce journal et ses commentaires, il n'y en a eu aucun.

        • [^] # Re: Mouarf

          Posté par  . Évalué à 4.

          Perso j'en vois un c'est le support des delta par les rpm et pas par les deb.

          • [^] # Re: Mouarf

            Posté par  . Évalué à 1.

            C'est à dire?

            Les rpm intègrent un mécanisme de versioning, et donc ne font que patcher l'install existante?

            Je n'ai jamais utilisé de système basé sur rpm, et je me suis toujours demandé quel était la différence entre deb et rpm, en fait.
            Donc je chope la balle au vol :) ( et sur google, a part des troll, impossible de trouver un truc correct à ce sujet. Ça vaudrait le coup d'en faire une page wiki sur linuxfr, peut-être ? )

            • [^] # Re: Mouarf

              Posté par  . Évalué à 2.

              les delta rpm fait que tu ne download que la difference entre deux versions de paquet.

              • [^] # Re: Mouarf

                Posté par  . Évalué à 1.

                Ok, utile en effet.

                Cependant, est-ce vraiment lié au format, ou aux outils? En gros, j'imagine que le système de paquet envoie la version courante au serveur, qui fait un diff binaire à renvoyer au client, qui génère un paquet tout frais a partir de l'ancien et du nouveau.
                Je n'ai jamais réfléchi à ce point, mais est-ce que ça ne serait pas faisable avec deb?

                Je veux dire, est-ce l'outil, ou le format, qui permet cette fonctionnalité?

                • [^] # Re: Mouarf

                  Posté par  . Évalué à 1.

                  Je sais et je trouve que la discussion ne sert a rien car quand tu dis que l'upgrade avec des distribs a base de rpm on te dis que c'est la faute des logiciels autour et quand tu donnes un avantage sur le rpm on te dis aussi que ce sont les logiciels autour.

                  Perso j'en ai rien a foutre, le format rpm il vient avec ses outils donc si ca merde que ce soit la faute du format, du logiciel rpm, de yum, urpmi ou tartampion j'en ai rien a taper ca ne marche juste pas.
                  Et inversement quand il y a un truc dedabs qui est bien, je remarque que l'environnement rpm a la possibiltie des delta que l'environnement deb n'a pas.

                  Qui va installer a la main un paquet deb en decompressant avec ar, qui va installer un paquet rpm a la mano (je me souviens plus du format utilise). Le truc c'est rpm+son environnement et deb+apt-get.

                  autrement pour le format delta rpm j'ai fait la recherche pour toi sur google:

                  http://www.mpipks-dresden.mpg.de/~mueller/docs/suse10.2/html/opensuse-manual_en/manual/sec.rpm.delta.html

                  • [^] # Re: Mouarf

                    Posté par  (site Web personnel) . Évalué à 2.

                    Le truc c'est rpm+son environnement et deb+apt-get

                    Le truc c'est que si en gros deb veut dire utiliser apt-get (ou aptitude) rpm ne veut pas dire utiliser redhat et yum… c'est plus fragmenté. Donc oui il y a quand même une différence

                    Perso j'en ai rien a foutre, le format rpm il vient avec ses outils donc si ca merde que ce soit la faute du format, du logiciel rpm, de yum, urpmi ou tartampion j'en ai rien a taper ca ne marche juste pas.

                    Ben non, le format rpm il vient pas avec ces outils par magie.
                    Et le ça marche juste pas, c'est juste risible.

                    • [^] # Re: Mouarf

                      Posté par  . Évalué à 2.

                      Ben non, le format rpm il vient pas avec ces outils par magie.
                      Et le ça marche juste pas, c'est juste risible.

                      idem pour deb donc quand tu parles de rpm tu fais comme pour deb tu parles d'un environnement.

                    • [^] # Re: Mouarf

                      Posté par  . Évalué à 1. Dernière modification le 02/05/14 à 16:25.

                      Pour le fait que certains aillent critiquer un format ou l'autre, perso je m'en moque, je ne me permettrait pas de critiquer les deb alors que je ne connais que ça ( et les .exe, .msi, .run, mais bon, ça compte pas comme de vrais formats… quoique msi… mouai. ).
                      Ma question était relative au format, pas aux outils. On peut ne pas aimer les outils qui vont autour. Genre, on pourrait dire que j'aime bien HTML et HTTP, qui sont un format et un protocole, mais ce qui est clair, c'est que je n'aime à l'heure actuelle aucun navigateur qui les exploite de ceux que j'ai testés ( IE, FF, opera, midori, uzbl, et divers autres dont j'ai oublié le nom ).

                      En tout cas, le delta rpm à effectivement l'air très puissant, merci.

                      Le truc c'est que si en gros deb veut dire utiliser apt-get (ou aptitude)

                      Ou dselect, ou dpkg, ou synaptic, et j'en oublie sûrement.

                      Je ne sais pas si l'environnement autour de rpm est fragmenté ou pas, mais celui autour de deb n'est pas uniforme.

                      • [^] # Re: Mouarf

                        Posté par  . Évalué à 1.

                        Je ne sais pas si l'environnement autour de rpm est fragmenté ou pas, mais celui autour de deb n'est pas uniforme.

                        rpm c'est pire, chaque distrib fait a sa sauce voir plusieurs sauve a la fois:

                        RH/Fedora: rpm+yum
                        Mandriva: rpm+urpmi
                        Suse : rpm+zypper

                        • [^] # Re: Mouarf

                          Posté par  (site Web personnel) . Évalué à 3.

                          rpm c'est comme dpkg, après la surcouche à tout ça peut être en effet yum (et bientôt dnf pour Fedora), urpmi, zypper voire encore PackageKit.
                          dpkg a aussi apt-get, aptitude, PackageKit…

                          • [^] # Re: Mouarf

                            Posté par  . Évalué à 3.

                            Packagekit, c'est une surcouche à apt, yum, zypper, pas à rpm ou dpkg il me semble. Sinon, aptitude et apt-get sont des surcouches à libapt lui-même une surcouche à dpkg.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: Mouarf

                              Posté par  (site Web personnel) . Évalué à 2.

                              Oui mais finalement tu retombes sur du rpm ou dpkg.

                              • [^] # Re: Mouarf

                                Posté par  . Évalué à 3.

                                Ça dépend des fonctionnalités, il n'y a aucun résolution des dépendances dans rpm ou dpkg, c'est fait dans les couches au dessus par exemple. Même chose pour la gestion des paquets installés automatiquement sous apt-get/aptitude.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Mouarf

        Posté par  . Évalué à 2.

        J'attends les arguments contre le format de paquet RPM :).

        C'est a peu pres impossible d'updater un systeme a base de RPM et il est fortrement conseille de faire une re-installation.
        Et mon experience m'a montre que cela etait vrai alors que ca fait plus de 15 ans que pour passer d'une version de debina ou ubuntu a la superieur je ne fais que un upgrade pas une reinstallation.

        • [^] # Re: Mouarf

          Posté par  (site Web personnel) . Évalué à 2.

          Et quel serait le problème de RPM qui en serait la cause ?

          • [^] # Re: Mouarf

            Posté par  . Évalué à 3.

            systeme base RPM : upgrade tres complique voir impossible
            systeme base Deb : upgrade tres facile

            alors apres ca peut venir de apt qui est vachement mieux que yum et toute la clique de logiciel equivalent sur ces systemes mais j'ai comme un doute vu que apt avait aussi ete porte dessus donc apres il reste le format ou l'interface chaise-clavier mais tu peux pointer une autre solution.

            • [^] # Re: Mouarf

              Posté par  (site Web personnel) . Évalué à 5.

              alors apres ca peut venir de apt qui est vachement mieux que yum et toute la clique de logiciel

              Tu serais pas en train de mélanger RPM et Yum ?
              Parce que bon y'a pas de Yum pour faire du rpm, et les urpm* en général s'en sortent plutôt pas mal.

              systeme base RPM : upgrade tres complique voir impossible
              systeme base Deb : upgrade tres facile

              Heu, ça c'est des arguments ??

              • [^] # Re: Mouarf

                Posté par  . Évalué à 4. Dernière modification le 30/04/14 à 14:47.

                Pas des arguments, juste des constatations mais je m'en moque tu sais. J'utilise differents linux avec differents systemes de paquet. Je prefere* les debian-like et j'ai toujours une apprhension avec les rpm-like c'est historique et je ne pretend pas qu'il y ait de logique a cela :)

                Par contre je vois que meme red-hat deconseille tres fortement un upgrade…

                Et enfin non je ne melange pas yum et rpm.

            • [^] # Re: Mouarf

              Posté par  (site Web personnel) . Évalué à 4.

              Un .deb, c'est une archive .ar qui contient un .tar.gz pour les métadonnées (infos sur le paquet à installer sous forme texte, plus les scripts d'installation et suppression) et un .tar.gz qui contient l'arborescence complète des fichiers à écrire.

              Un .rpm, c'est une archive .cpio qui contient (de mémoire) une archive pour les métadonnées (infos sur le paquet à installer sous forme XML, plus les scripts d'installation et de suppression), et un .tar.gz qui contient l'arborescence complète des fichiers à écrire.

              Qu'est-ce qui fait la différence pour la difficulté à mettre à jour avec du .rpm ?

              • [^] # Re: Mouarf

                Posté par  . Évalué à 1.

                Le facon de gerer les dependances peut etre?

                • [^] # Re: Mouarf

                  Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 30/04/14 à 22:04.

                  Ça ne concerne pas rpm ou deb, ça.
                  La façon de noter les dépendances est identique dans les deux types de paquet (paquet, et critères sur la version).

                  C'est lié à yum, aptitude, apt, … D'ailleurs, apt et aptitude n'ont pas exactement la même méthode de gestion des dépendances, ce qui fait que certaines opérations sont faisables avec l'un mais pas avec l'autre quand il y a des soucis de dépendance.

                  • [^] # Re: Mouarf

                    Posté par  . Évalué à 2.

                    C'est lié à yum, aptitude, apt, …

                    Non, plutot au fait que les packagers testent l'upgrade et corrigent les problemes sur l'une des distributions, et sur l'autre ne le supportent pas donc ne font peu etre pas particulierements d'efforts la dessus.

                    Je pense que yum a autant que aptitude / apt les fonctionnalités qu'il faut pour permettre un upgrade.

          • [^] # Re: Mouarf

            Posté par  . Évalué à 4.

            Simple : entre RHEL5 et 6 le format a changé, c'est la raison pour laquelle cette MAJ n'est pas supportée.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Mouarf

          Posté par  (site Web personnel) . Évalué à 2.

          C'est a peu pres impossible d'updater un systeme a base de RPM et il est fortrement conseille de faire une re-installation.

          T'as des liens, des infos, quelque chose de précis ?
          Nan c'est juste pour que je sache comment je fais depuis plus de 10 ans…

          • [^] # Re: Mouarf

            Posté par  . Évalué à 3.

            http://tvtropes.org/pmwiki/pmwiki.php/Main/AllJustADream

            Depending on the time of day, the French go either way.

          • [^] # Re: Mouarf

            Posté par  . Évalué à 2.

            Il y a deja eu plusieurs personnes dans ce journal ayant mentionne cela, je te laisse chercher tout seul.

            • [^] # Re: Mouarf

              Posté par  (site Web personnel) . Évalué à 2.

              mouarf
              Ben essaie de pointer les arguments parce que dans ce journal y'en a pas vraiment hein…

              • [^] # Re: Mouarf

                Posté par  . Évalué à 1.

                https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-upgrade-x86.html

                Lis donc le gros truc en jaune au debut de page. Maintenant chez RedHat ils sont peut etre nul, ne connaissent pas le system qu'ils developpent ou sont incompetents? Perso je pense plutot qu'ils ne veulent pas s'emmerder a etre sur qu'un upgrade fonctionnera et c'est tout. Donc ca peut fonctionner mais si ca fonctionne pas ils s'en lavent les mains et c'est pas fait expres.

                • [^] # Re: Mouarf

                  Posté par  (site Web personnel) . Évalué à 5.

                  C'est un avertissement qui tombe sous le sens et qui est valide pour toute distribution, même Debian.
                  Quand tu changes de version majeur du système par une mise à jour en place, tout peut arriver : fichiers de configurations incompatibles entre les versions des applications par exemple. Red-Hat ne peut rien garantir de ce point de vue et Debian non plus. Car si l'application décide de casser ça, le système ne peut pas le rattraper.

                  Debian et d'autres distributions peuvent tester minutieusement pour corriger les éventuels soucis mais la garantie absolue n'existe pas selon moi. Et quand Red-Hat fait payer ses clients pour le support il est bon qu'ils sachent dire "ici aucune garantie" quand c'est vrai plutôt que de mentir et de faire courir de gros risques à ses clients…

                  Toute mise à jour présente des risques, le contraire n'est que mensonge. Au moins Red-Hat le précise et c'est un comportement responsable. Après tout quand on est passé à KDE4 et qu'il fallait repartir à 0 niveau configuration de KDE tellement c'était cassé, tu crois que le fait d'utiliser les paquets DEB y changent quelque chose par rapport à RPM ?

                • [^] # Re: Mouarf

                  Posté par  (site Web personnel) . Évalué à 3.

                  hein ? quoi ? tu peux perdre de la conf en upgradant ?
                  Et d'ailleurs tu sais quoi, beaucoup de logiciels que tu utilises ont une belle clause qui dit qu'ils ne sont garanti en aucun cas, que ça peut ne pas fonctionner bla bla. Ça veut dire que les développeurs ne connaissent pas ce qu'ils développent ou sont incompétents ?

                  Et sinon, reste que j'ai quand même bien l'impression que tu confond RPM et yum/redhat.
                  A moins que, encore une fois, tu montres que RPM a un problème sur l'upgrade (et non yum, et non redhat en particulier).

                  Parce que bon des maj qui foirent à base de deb ça marche aussi hein.

                  • [^] # Re: Mouarf

                    Posté par  . Évalué à 2.

                    Parce que bon des maj qui foirent à base de deb ça marche aussi hein.

                    Bien sur mais mon experience m'en a donne moins que de mise a jour foiree avec des distribs a base de rpm. Apres encore une fois chacun a ses preferences (et ses automatismes).

                    • [^] # Re: Mouarf

                      Posté par  (site Web personnel) . Évalué à 2.

                      Ouais enfin choisir une distribution pour son format de paquet c'est un peu comme choisir une voiture pour la couleur de la jante… C'est vraiment un détail mineur par rapport au reste : communauté (ambiance, langue et taille), philosophie, paquets disponibles, fonctionnalités uniques, intégration de tes logiciels favoris, cycle de vie, support, licences, obsolescence des logiciels, architectures supportées, etc.

                      Franchement que ce soit DEB ou RPM, c'est rien du tout, en général tu exploites tout via les dépôts et le reste est transparent.

                      • [^] # Re: Mouarf

                        Posté par  . Évalué à 2. Dernière modification le 30/04/14 à 17:40.

                        communauté (ambiance, langue et taille), philosophie, paquets disponibles, fonctionnalités uniques, intégration de tes logiciels favoris, cycle de vie, support, licences, obsolescence des logiciels, architectures supportées, etc.

                        Parceque tu crois vraiment qu'il y a une enorme difference entre debian-like et rpm-like pour ces points?

                        De tout de facon je choisis mes distributions suivant le but d'utilisation, suivant les utilisateurs ou autre criteres mais pas sur le format de package.

                        • [^] # Re: Mouarf

                          Posté par  (site Web personnel) . Évalué à 2.

                          Justement, je pense que le fait d'utiliser DEB ou RPM est une différence plus historique que réelle aujourd'hui.
                          En gros il y a potentiellement plus de différences entre Debian et Ubuntu qu'entre Debian et Red-Hat…

                          • [^] # Re: Mouarf

                            Posté par  . Évalué à 1.

                            Euh pas vraiment enfin avec le fait que debian passe a systemd (mais ubuntu aussi) cela va en effet se rapprocher mais bon cela n'a rien avoir avec le format de package.

                            • [^] # Re: Mouarf

                              Posté par  (site Web personnel) . Évalué à 3.

                              Mais justement !
                              Tu as dis que tu avais des soucis d'upgrade dans les distributions RPM et je tente de t'expliquer que c'est indépendant du gestionnaire de paquet et qu'en soit le format de paquets est un détail dans une distribution…

                              • [^] # Re: Mouarf

                                Posté par  . Évalué à 1. Dernière modification le 30/04/14 à 18:13.

                                Ce que je dis c'est que en plus de 15 ans d'utilisation de linux j'ai toujours eu des problemes lors d'upgrade avec des rpm-like alors que cela a ete rarement le cas avec des debian-like. Maintenant je ne me fatigue meme plus a faire un upgrade avec une rpm-like, je re-installe et comme ca je sais que ca va fonctionner avec une debian-like je vais d'abord faire un upgrade.

                                Desole si je me sert de mon experience mais bon c'est un peu ce que tout le monde fais non?

                                Et aussi pour en revenir au journal, mon experience m'a montre que utilise Fedora sur Desktop c'est deja tendu alors sur un serveur en production je n'ose meme pas imaginer.

                                • [^] # Re: Mouarf

                                  Posté par  . Évalué à 3.

                                  C'est à peu près aussi intelligent que de dire "en plus de 15 ans d'utilisation de linux j'ai toujours eu des problemes lors d'upgrade avec des distributions dont le nom commence par R, alors que cela a ete rarement le cas avec celles dont le nom commence par D. Maintenant je ne me fatigue meme plus a faire un upgrade avec une distribution dont le nom commence par R, etc …". Ou alors en remplacant "rpm-like" et "deb-like" par la license utilisée, la version de bash, l'age moyen des developeurs ou le modulo de la taille de l'ISO.

                                  Avant de conclure que le fait d'etre basé sur rpm implique que l'upgrade va poser problème il faudrait voir exactement d'ou vient le problème.

                                  A mon avis le format rpm supporte aussi bien les upgrades que le format deb, et les problèmes ne viennent pas du format du package. Les developeurs de certaines distributions décident de passer du temps à résoudre le plus de problèmes liés à l'upgrade, tandis que d'autres estiment que ca n'est pas leur priorité et donc ne le supportent pas. Mais ca n'a rien à voir avec le format de package.

                                  • [^] # Re: Mouarf

                                    Posté par  . Évalué à -1.

                                    C'est à peu près aussi intelligent

                                    ca tombe bien tout le monde sait que je suis idiot et dit que des conneries.

                                    Avant de conclure que le fait d'etre basé sur rpm implique que l'upgrade va poser problème il faudrait voir exactement d'ou vient le problème.

                                    Desole de me servir de mon experience qui m'a fait avoir pas mal de probleme avec des upgrades de rpm (redhat en premier) alors que avec les debian-like (debian ou ubuntu) cela a ete plus que limite. Je dis bien que c'est mon experience, que quelqu'un d'autre ait une experience oppose et il dira l'inverse et fera comme moi mais du cote oppose et il aura raison car c'est ce que son experience lui auras appris.

                                    Il n'existe, que je sache, aucune metric absolue sur le sujet donc c'est l'experience (par definition) subjective qui fera la difference.

                                    Pour dire exactement ce que je n'aime(ais) pas dans le format rpm. Tu installes un rpm a la main qui foire et il va te dire: il te manque la libXX et c'est tout. Un paquet debian te dira exactement quel est le nom du paqet manquant. Pour moi c'est une petite difference appreciable.

                                    • [^] # Re: Mouarf

                                      Posté par  . Évalué à 4.

                                      Ton experience te permet peu etre de conclure que l'upgrade d'une version à l'autre se passe mieux sur une Debian que sur une Red Hat, mais rien n'indique que ca soit lié au format de package.

                                      • [^] # Re: Mouarf

                                        Posté par  . Évalué à 0.

                                        apt-get a existe pour rpm mais vu le nombre de solution qui existe pour ce format de package et le nombre de solution essaye par red-hat je me dis qu'il y a comme un probleme quelque part.

                                        Mais je m'em moque chacun fait ce qu'il veut avec ses connaissances et son vecu.

                                        • [^] # Re: Mouarf

                                          Posté par  . Évalué à 2.

                                          Comme deja dit je sais pas combien de fois ca n'a rien à voir avec apt-get ou le gestionnaire de packages. Utiliser apt-rpm (version d'apt-get pour rpm) va pas magiquement rendre la procedure d'upgrade testée, debugguée et supportée. Et yum/rpm ont deja toutes les fonctionnalités qu'il faut pour permettre de gerer une upgrade. Utiliser apt-get va pas corriger automatiquement les bugs de packaging ou autre qui peuvent faire qu'une upgrade peut mal se passer.

                                          Ton raisonnement de "j'ai eu des pb d'upgrade sur des distro à base de rpm et ca fonctionnait bien sur une Debian donc rpm ne permet pas les upgrades de distro contrairement à deb" est juste completement cretin.

                                          Le package X dont j'ai besoin est disponible dans les depots de Debian mais pas ceux de RHEL => mon experience montre qu'il est impossible de packager X en rpm alors que c'est possible en deb (en remplacant X par le nom d'un logiciel quelconque). Voila, c'est le meme genre de raisonnement.

                                        • [^] # Re: Mouarf

                                          Posté par  . Évalué à 1.

                                          En fait, je pense que ce qu'il essaie de te dire, c'est que ce n'est pas un problème de format ( deb/rpm ) mais de soin apporté au paquet par le distributeur de la distro.

                                          Debian étant, à priori et selon tes commentaires, plus soigneux que Red Hat, tu as vécu moins de problèmes, mais ceux-ci ne seraient liés qu'a la distro, et non pas au format des archives.

                                          J'ai bon?

                                          • [^] # Re: Mouarf

                                            Posté par  . Évalué à 2.

                                            J'ai bon?

                                            Oui, c'est ce que je voulais dire. Merci.

  • # systemd-login

    Posté par  (site Web personnel) . Évalué à 7. Dernière modification le 29/04/14 à 21:59.

    Il n'y a pas qu'Ubuntu qui fournis systemd-logind avec un init classique:

        $ lsb_release -r -d -c
        Description:    Debian GNU/Linux unstable (sid)
        Release:    unstable
        Codename:   sid
        $ dpkg -S /sbin/init
        sysvinit-core: /sbin/init
        $ dpkg -S /lib/systemd/systemd-logind
        systemd: /lib/systemd/systemd-logind
        $ sudo ls -l /proc/1/exe
        lrwxrwxrwx 1 root root 0 avril 28 09:15 /proc/1/exe -> /sbin/init
        $ pidof systemd-logind
        2723
        $ dmesg |grep systemd-logind |tail
        [67305.464386] systemd-logind[2723]: Removed session c49.
        [67305.591322] systemd-logind[2723]: New session c50 of user nico.
        [67310.444139] systemd-logind[2723]: Removed session c50.
        [67318.269359] systemd-logind[2723]: New session c51 of user nico.
        [67318.269871] systemd-logind[2723]: Lid opened.
        [67318.269919] systemd-logind[2723]: Operation finished.
    • [^] # Re: systemd-login

      Posté par  (site Web personnel) . Évalué à 0.

      Il n'y a pas qu'Ubuntu qui fournis systemd-logind avec un init classique

      Tout à fait, si l'on n'utilise pas systemd. Ce que je ne recommande pas dans l'article.

  • # Raison 3

    Posté par  . Évalué à 10.

    Les administrateurs consciencieux doivent d'abord arrêter les services démarrés le plus rapidement possible après l'installation pour pouvoir les configurer (et éventuellement les retirer du processus de démarrage). Cela réduit à néant le supposé avantage consistant à les démarrer par défaut.

    Non les administrateurs consciencieux n'auront pas laissé des ports ouverts non utilisés donc ils prendront leur temps de savourer leur café ou leur thé avant de se précipiter pour faire une chose ou une autre.

    Les réponses sur Serverfaults, AskUbuntu et AskDebian ne sont pas satisfaisantes et ne sont que des « hacks » non permanents. Pour les utiliser, il faut faire attention à bien les mettre en place avant chaque appel à apt-get et ensuite faire attention à bien les retirer. Rien de tout ceci n'est bien entendu supporté et il n'est plus possible d'utiliser juste apt-get install car il faudrait alors s'assurer qu'aucune des dépendances installées ne démarre automatiquement un service.

    Ce n'est pas permanent parce qu'ils n'ont pas décris qu'il est tout à fait possible d'utiliser DPkg::Pre-Invoke et DPkg::Post-Invoke dans /etc/apt/apt.conf.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Raison 3

      Posté par  . Évalué à 10.

      D'autant plus que les administrateurs consciencieux auront déjà configuré l'application dans un lab ou environnement de test et passeront par des outils de déploiement de configuration (cfengine/puppet/whatever) pour passer le tout en prod avec installation du package. C'est un travail de goret d'aller installer et configurer à la mano sur un serveur de prod.

    • [^] # Re: Raison 3

      Posté par  (site Web personnel) . Évalué à 1.

      Non les administrateurs consciencieux n'auront pas laissé des ports ouverts non utilisés donc ils prendront leur temps de savourer leur café ou leur thé avant de se précipiter pour faire une chose ou une autre.

      Utiliser un firewall pour contourner le fait qu'un service démarre dans ton dos, ça ne rentre pas dans la catégorie des "hack"?

      • [^] # Re: Raison 3

        Posté par  . Évalué à 4.

        Je n'ai pas argumenté sur le fait que ce soit bien ou pas de lancer automatiquement les services, j'ai dis que dire que « administrateur consciencieux » fait un infarctus si le service est lancé automatiquement c'est ridicule. Il n'y a aucune raison de ne pas configurer son firewall et si ça peut lui éviter d'aller aux urgences pourquoi ne pas le faire ?

        Personnellement c'est ce qui fait que je me balance royalement du fait que ce soit lancé automatiquement ou pas.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Raison 3

      Posté par  . Évalué à 1.

      Dans la même "raison", est-ce que quelqu'un pourrais me dire en quoi le fait de mettre à jour un service sans le redémarrer aussitôt est gênant?

      Déjà, pour un poste de bureau, ça ne pose aucun souci, c'est rapide et n'interrompt potentiellement l'utilisateur qu'a peine une dizaine de secondes ( je suis large, très large, parce que mon expérience sur une machine desktop mise à jour régulièrement montre plutôt des "interruptions" d'a peine 2s. C'est surtout "gênant" pour mpd… le reste… bof. ).

      Et pour un serveur, rien, strictement rien, n'empêche de faire la mise à jour du service uniquement au moment ou l'on veut le redémarrer. Avec un cron job, par exemple.
      Et accessoirement, ça me semble éviter les situations ou un daemon est à jour sur le disque dur, mais l'admin ayant oublié de le redémarrer, il a conservé les failles dans la RAM…

      Me trompe-je?

    • [^] # Re: Raison 3

      Posté par  (site Web personnel) . Évalué à 0.

      Non les administrateurs consciencieux n'auront pas laissé des ports ouverts non utilisés donc ils prendront leur temps de savourer leur café ou leur thé avant de se précipiter pour faire une chose ou une autre.

      Cela résout en effet une partie du problème. Je vais mettre à jour avec cette remarque.

      Ce n'est pas permanent parce qu'ils n'ont pas décris qu'il est tout à fait possible d'utiliser DPkg::Pre-Invoke et DPkg::Post-Invoke dans /etc/apt/apt.conf.

      Je ne connaissais pas. Merci pour cette précision.

  • # Pitoyable

    Posté par  . Évalué à 10.

    Désolé mais lire cela c'est affligeant, on dirait la communication de Microsoft quand ils sortent une nouvelle version de IE. Du FUD, du FUD et encore du FUD, basé sur des affirmations subjectives et non fondées. As-tu déjà installé un serveur ubuntu ? As-tu déjà installé et maintenu un serveur tout court ? Non parce que citer Fedora et Archlinux pour des serveurs, bravo. Allons-y en vrac :

    Raison 1 : Noyau Linux non supporté

    RedHat, que tu sembles tant aimer, supporte encore un kernel 2.6.18 en 2014. Je ne crois pas que ce soit encore upstream. Donc cela ne semble pas infaisable.

    Raison 2 : Upstart

    Comme 95% des sysadmin, je m'en fiche un peu, du moment qu'on peut faire service mescouilles start. Comme tu aimes RedHat, tu dois aimer systemd, et ça tombe bien, ubuntu va y passer.

    Raison 3 : Les services sont démarrés et ajoutés au démarrage par défaut lors de leur l'installation

    J'ai toujours eu l'impression qu'à l'inverse c'est RedHat qui ne les ajoute pas automatiquement. Les autres le font. Souvent ces services sont inoffensifs tant qu'ils ne sont pas configurés (par exemple Postfix ne relaie pas le courrier). Donc faux problème.

    Raison 4 : MySQL

    Tout le monde demande du MySQL, de plus :
    - Tu peux installer MariaDB à partir des repo
    - Très peu de distributions utilisent MariaDB par défaut, donc il ne faut pas pointer du doigt Ubuntu comme si c'était une exception.

    Raison 6 : Compiz & Mir

    Rien à battre sur un serveur, pas d'interface graphique…

    • [^] # Re: Pitoyable

      Posté par  (site Web personnel) . Évalué à 4.

      RedHat, que tu sembles tant aimer, supporte encore un kernel
      2.6.18 en 2014. Je ne crois pas que ce soit encore upstream.
      Donc cela ne semble pas infaisable.

      Je pense aussi que c'est faisable, mais je pense aussi que Canonical n'a pas les moyens qu'a Red Hat en terme de dev à temps plein, donc je peux dans une certaine mesure comprendre les doutes des gens.

      Tout le monde demande du MySQL, de plus :
      - Tu peux installer MariaDB à partir des repo
      - Très peu de distributions utilisent MariaDB par défaut, donc
      il ne faut pas pointer du doigt Ubuntu comme si c'était une
      exception.

      Je pense que la raison, c'est plus le coté totalement faux jeton de Mark Shuttleworth vis à vis d'Oracle. Tout comme Mark a fait un volte face sur le bug #1, il fait de la com pour faire plaisir à Oracle, car les devs Oracles sont venus tout d'un coup faire du taf avec les distros le jour ou les gens ont dit "tiens, et si on prenait Mariadb à la place, car Oracle ferme trop Mysql". Et pour moi, c'est clairement parce que RHEL part sur du Mariadb par défaut dans la 7 que Canonical tente de se distinguer car sinon, ça part pour être libreoffice vs openoffice à nouveau.

    • [^] # Re: Pitoyable

      Posté par  (site Web personnel) . Évalué à 2.

      Non parce que citer Fedora et Archlinux pour des serveurs, bravo.

      Heu, ou conseille il Archlinux sur un serveur ?
      Il dit que la solution est Fedora ou Arch pour la machine de travail, sur la TV opposée a la chaise par rapport a l’utilisateur.

      Il cite effectivement Fedora 20 pour un serveur, en précisant de passer a RHEL 7 quand sorti.

      Comme 95% des sysadmin, je m'en fiche un peu, du moment qu'on peut faire service mescouilles start. Comme tu aimes RedHat, tu dois aimer systemd, et ça tombe bien, ubuntu va y passer.

      Je suis trés loin d'être un spécialiste, mais systemd change quand même un certain nombre de chose dans la gestion du démarrage des services.

      Très peu de distributions utilisent MariaDB par défaut

      RedHat l'annonce par défaut sur RHEL 7.
      Ensuite Fedora (biensur), Mageia et OpenSuse l'utilisent par défaut en remplaçant de MySQL. Ça ne me semble déjà pas si mal quand on regarde les grands acteurs de ce marché.

      Rien à battre sur un serveur, pas d'interface graphique…
      Je sais qu'on en arrive de plus en plus a du tout web, mais certains utilisent encore autre chose qu'Android comme Linux pour lancer un navigateur ou des APPS.

      Le marché de la machine du desktop se casse la figure, Les distribution Gnu/Linux n'ont jamais eu un rôle d'incontournable dans ce domaine, mais ça existe et c'est utilisé quand même.

      Donc non, il n'y as pas que du serveur.
      D'autant que pour un serveur en prod, même moi qui suis vraiment un petit bricoleur dans ce domaine, il ne me viendrais pas a l'idée d'aller y mettre de l'ubuntu.

    • [^] # Re: Pitoyable

      Posté par  (site Web personnel) . Évalué à 0.

      As-tu déjà installé un serveur ubuntu ? As-tu déjà installé et maintenu un serveur tout court ?

      Le serveur hébergeant le blog est sous Arch Linux. J'ai géré pendant un temps un serveur sous Debian et j'en gère en ce moment sous Fedora.

      Non parce que citer Fedora et Archlinux pour des serveurs, bravo.

      Je ne conseille pas d'utiliser Arch Linux sur un serveur. Je conseille uniquement Fedora 20 comme alternative en attendant la sortie de CentOS 7. Dès que CentOS 7 sera sorite, il n'y aura plus aucune raison de mettre Fedora sur un serveur.

      RedHat, que tu sembles tant aimer, supporte encore un kernel 2.6.18 en 2014. Je ne crois pas que ce soit encore upstream. Donc cela ne semble pas infaisable.

      Red Hat est particulièrement connu pour avoir à disposition une partie non négligeable des développeurs contribuant au noyau Linux. De plus, le support du noyau 2.6.18 (RHEL 5) est dans la phase 3, ce qui signifie qu'ils ne font plus que les mises à jour de sécurité, ce qui réduit considérablement le travail. De plus, ils sont payés par les entreprises achetant du support pour le faire.

      Comme 95% des sysadmin, je m'en fiche un peu, du moment qu'on peut faire service mescouilles start.

      Si la gestion des services sur un serveur était aussi simple que cela je pense que systemd n'existerai pas.

      J'ai toujours eu l'impression qu'à l'inverse c'est RedHat qui ne les ajoute pas automatiquement. Les autres le font.

      A ma connaissance, les seules distributions activant les services par défaut sont dérivées de Debian.

      Souvent ces services sont inoffensifs tant qu'ils ne sont pas configurés (par exemple Postfix ne relaie pas le courrier). Donc faux problème.

      C'est le « Souvent » qui importe ici.

      Tu peux installer MariaDB à partir des repo

      En effet, c'est une erreur de ma part.

      Très peu de distributions utilisent MariaDB par défaut, donc il ne faut pas pointer du doigt Ubuntu comme si c'était une exception.

      http://en.wikipedia.org/wiki/MariaDB#Prominent_users

      Rien à battre sur un serveur, pas d'interface graphique…

      C'est peut-être pour cela que j'ai mis ça à la fin en précisant bien que cela concernait les machines de bureau ?

      • [^] # Re: Pitoyable

        Posté par  (site Web personnel) . Évalué à 5.

        Le serveur hébergeant le blog est sous Arch Linux.

        Blog, ArchLinux… Tu nous fais rêver là… Et ça vient cracher sur Ubuntu Server après…

        • [^] # Re: Pitoyable

          Posté par  (site Web personnel) . Évalué à 7. Dernière modification le 01/05/14 à 18:58.

          Tout le monde ne cherche pas à avoir un serveur "stable". Siosm critique ici l'hypocrisie d'appeler Ubuntu 14.04 une version LTS et il donne des raisons pas moins argumentées que vos critiques. Le fait qu'il utilise ArchLinux pour son serveur n'enlève rien à ses arguments.

          Vous dîtes que supporter un noyau, c'est possible vu que Red Hat le fait. Il y a quand même une différence MAJEURE entre Canonical et Red Hat, c'est l'implication forte de Red Hat dans le développement de Linux (2ème entreprise la plus contributrice au 3.14, derrière Intel). Comme Canonical n’apparaît jamais dans ces tops, j'ai fait une recherche par auteur dans le commit log et j'ai trouvé 1500 patchs 1, 2. Si on regarde 1500 patchs en arrière pour Red Hat, ça correspond à Décembre 2013! Red Hat a plus contribué au noyau en 5 mois que Canonical depuis 9 ans! Si j'étais un employé Canonical, j'aurai écrit sur mon temps libre en 4 ans 4% des contributions totales à Linux faites par Canonical depuis le début. Ça choque personne ça?

          Red Hat a prouvé qu'il a les compétences pour développer et donc maintenir Linux dans beaucoup de sous systèmes. De son coté, Canonical fait quoi alors? Ils se limitent à backporter des patchs qu'ils ont pas écrit et remplir les bugs reports des projets upstream? C'est ça "maintenir"? Je me pose vraiment des questions là, je suis profondément choqué…

          À priori, ce problème ne se limite pas au noyau vu que en 2010, le ratio des contributions à Gnome entre Red Hat et Canonical était un facteur 16. Coté pile graphique, à part l'excellent travail de Maarten Lankhorst sur TTM et celui de Chase Douglas (qui semble avoir quitté Canonical il y a quelques années) sur le multi-touch et périphériques d'input, je vois pas ce qu'ils ont apporté… Pour une distro orientée desktop, ça choque personne que Canonical ne soit pas impliquée dans les projets couverts par la fondation X.Org? Apple et Oracle sont plus impliqués dans X que Canonical (1, 2)!

          Canonical considère que sa contribution au libre est plus sur l'intégration que sur le code. C'est vrai que Canonical a énormément démocratisé Linux et personne ne lui enlèvera ça! Je suis content que cette entreprise augmente la visibilité de notre noyau favori!

          Cependant, quand Canonical dit il va maintenir une collection de projets dans lesquels elle n'est pas reconnue pour ses contributions, j'ai le droit d'être sceptique, non? Quelqu'un a des arguments factuels sur pourquoi Canonical serait à même de faire un bon travail de maintenance? À moins que vous préfériez me moinser car "je FUD" et "je trolle" et dire que je comprend rien (dans ce cas là, j'aimerai le savoir donc dîtes moi ce que je sais pas!)?

          • [^] # Re: Pitoyable

            Posté par  . Évalué à 6.

            Donc, si je te suis, il ne faut pas utiliser Debian non plus qui ne fait que reprendre les patchs des autres pour maintenir son kernel 3.2. En effet, si on regarde de qui viennent les patch, il s'agit beaucoup de Red Hat ou Oracle https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v3.2.58

            Je pense que, comme il a déjà été dit, maintenir son propre noyau, si on a des gens motivé/payé pour, ça n'est pas trop compliqué.

            Quelqu'un a des arguments factuels sur pourquoi Canonical serait à même de faire un bon travail de maintenance?

            Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle). C'est valable pour Upstart ou pour X.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Pitoyable

              Posté par  (site Web personnel) . Évalué à 3.

              Donc, si je te suis, il ne faut pas utiliser Debian non plus qui ne fait que reprendre les patchs des autres pour maintenir son kernel 3.2.

              Debian n'a rien à faire, ce kernel est une long-term release. Le travail est fait majoritairement par la fondation Linux (Greg Kroah-Hartman). C'est une des raisons qui pousse Siosm à dire que le choix du noyau n'a pas de sens (le 3.12 est supporté). Je pense que la fondation Linux a plus de poids pour demander des informations aux développeurs que Canonical.

              Je pense que, comme il a déjà été dit, maintenir son propre noyau, si on a des gens motivé/payé pour, ça n'est pas trop compliqué.

              Qui est-ce qui va écrire des patchs pour les bugs spécifiques à Linux 3.13? En général, Canonical résout ces problèmes en back-portant des bouts entiers de noyau (c'est le cas pour la pile graphique). Tant que le numéro de version du noyau bouge pas, c'est toujours stable hein?

              Patcher sans comprendre, c'est pas vraiment ce que j'appelle maintenir. Ça donne ce genre de connerie.

              Pour info, je reproche énormément à Debian son manque de coopération avec les développeurs, maintenir des dizaines de patchs dans chaque paquet n'est pas viable et augmente la divergence entre les distros. Les patchs devraient être commités upstream avant qu'une distro les utilise. Ces patchs doivent ensuite être backportés dans les versions encore utilisées par les distros et une nouvelle release doit être faite. De cette façon, les efforts de maintenance sont partagés et tout le monde y gagne! J'ai encore en travers de la gorge les problèmes avec gcc-avr qui marchait très bien sur Debian mais pas dans la version de développement de GCC. Il a fallu que je refasse un paquet pour Arch avec les patchs de debian afin de pouvoir le faire marcher en attendant que les patchs remontent upstream. Ça a prit des années au final! Tu trouves ça normal? Tu trouves que c'est ça maintenir? Pour info, Red Hat et Arch font majoritairement ce que je dis qu'il faut faire.

              Pour en revenir à Ubuntu, tu sais qu'ils utilisent une version modifiée de Wine pour mieux marcher avec pulse audio? Pour info, ils ont 42 patchs pour wine! Il se trouve que pour ce cas là, je comprend la raison, mais patcher de son coté n'est pas une solution!

              Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle). C'est valable pour Upstart ou pour X.

              En utilisant ta logique, je te dirai que ArchLinux est stable. La preuve, j'ai jamais de problèmes alors que je suis toujours à jour. Le fait que JE ne sois impacté par aucune mise à jour ne veut pas dire que quelqu'un d'autre ne le soit pas.

              • [^] # Re: Pitoyable

                Posté par  . Évalué à 3.

                Debian n'a rien à faire, ce kernel est une long-term release. Le travail est fait majoritairement par la fondation Linux (Greg Kroah-Hartman).

                Justement, non, regarde le lien que j'ai donné, le mainteneur du 3.2, ce n'est pas GKH.

                En utilisant ta logique, je te dirai que ArchLinux est stable. La preuve, j'ai jamais de problèmes alors que je suis toujours à jour. Le fait que JE ne sois impacté par aucune mise à jour ne veut pas dire que quelqu'un d'autre ne le soit pas.

                Alors, aucune distribution n'est bonne, Red Hat fait aussi des mises à jours qui font des régressions.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Pitoyable

                  Posté par  (site Web personnel) . Évalué à 3.

                  Justement, non, regarde le lien que j'ai donné, le mainteneur du 3.2, ce n'est pas GKH.

                  My bad, en effet!

                  Quelqu'un a des arguments factuels sur pourquoi Canonical serait à même de faire un bon travail de maintenance?

                  Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle). C'est valable pour Upstart ou pour X.

                  En utilisant ta logique, je te dirai que ArchLinux est stable. La preuve, j'ai jamais de problèmes alors que je suis toujours à jour. Le fait que JE ne sois impacté par aucune mise à jour ne veut pas dire que quelqu'un d'autre ne le soit pas.

                  Alors, aucune distribution n'est bonne, Red Hat fait aussi des mises à jours qui font des régressions.

                  C'est quoi le rapport? J'attend toujours du factuel… Comme je disais, ton expérience personnelle ne peut pas suffire à juger des capacités de Canonical à maintenir sa distribution. Tu as des exemples de bugs qu'ils ont corrigé eux même ou des problèmes rencontrés qui ont nécessités un effort important de leur part? Je dis pas qu'ils en sont incapables, je dis juste qu'il y a de quoi être sceptique et que si on cherche vraiment la stabilité, d'autres distros ont plus de sens (ce qui est exactement ce que ce journal voulait dire).

                  • [^] # Re: Pitoyable

                    Posté par  . Évalué à 5.

                    Comme je disais, ton expérience personnelle ne peut pas suffire à juger des capacités de Canonical à maintenir sa distribution.

                    Je n'ai jamais parlé de mon expérience personnelle (d'ailleurs, je n'ai jamais mis Ubuntu sur un serveur)

                    Je dis pas qu'ils en sont incapables, je dis juste qu'il y a de quoi être sceptique et que si on cherche vraiment la stabilité, d'autres distros ont plus de sens (ce qui est exactement ce que ce journal voulait dire).

                    J'attends des exemples que leurs LTS ne sont pas au niveau de Debian (qui est conseillée par le journal). Alors que ça fait quelques temps qu'ils gèrent leur distrib, on peut quand même se baser sur le passé pour voir si marche ou non.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Pitoyable

              Posté par  (site Web personnel) . Évalué à -3.

              Je pense que, comme il a déjà été dit, maintenir son propre noyau, si on a des gens motivé/payé pour, ça n'est pas trop compliqué.

              Payer quelqu'un ne vas pas en faire automatiquement un bon mainteneur noyau ou un bon décideur de quels patchs doivent intégrer une branche stable.

              Ben Hutchings (http://www.linux.com/news/special-feature/linux-developers/632197-30-linux-kernel-developers-in-30-weeks-ben-hutchings) a déjà contribué au noyau. Je n'ai pas d'opinion sur sa compétence de mainteneur du noyau 3.2.

              Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle).

              Ce qui est beaucoup plus facile vu que le noyau utilisé dans la 10.04 par exemple est le 2.6.32, peut-être le noyau le plus supporté de toute l'histoire de Linux et que RHEL 6 est basé sur à peu près les même logiciels, donc que ceux-ci aussi sont supportés.

  • # beaucoup de FUD au lieu d'un simple lien

    Posté par  . Évalué à 0.

    Comme dit plus haut, c'est du FUD.
    Et puis, ne pas passer à 14.04 LTS parce ce ne serait pas une vraie LTS. Et alors ? Je passerai à 14.10 de toutes façons.

    Pour ce qui est de passer à 14.04, je vais attendre un peu vu les problèmes que certains rencontrent. Voyez plutôt
    https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977

    • [^] # Re: beaucoup de FUD au lieu d'un simple lien

      Posté par  . Évalué à 3.

      Pour ce qui est de passer à 14.04, je vais attendre un peu vu les problèmes que certains rencontrent. Voyez plutôt
      https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977

      Oui enfin quand on lit le bug en question ("symbol 'grub_term_highlight_color' not found"), qui effectivement bloque le boot, mais qu'une solution triviale (pour quasiment quiconque sait installer Ubuntu) existe pour régler le problème :

      It happened to me as well.
      I have a Quantal liveUSB at hand and booted from it. I ran the grub-install from it and fixed the boot.

      J'ai du mal à comprendre en quoi ça t'incite à attendre pour mettre à jour, vu que tu es au courant des problèmes potentiels et de leurs solutions (ce qui est une excellente chose d'ailleurs, c'est un bon réflexe…). Je pense qu'il y a d'autres raisons à ton choix.

  • # bande de geek

    Posté par  . Évalué à 7.

    pour avoir testé un paquet de distrib, je reviens a chaque fois sur ubuntu
    archlinux est très bien mais prends bien trop de temps a être configuré, de plus je me sers également d'ubuntu pour l'installer chez les autres, donc très content qu'une lts soit sortit il ya peu.

    les particuliers en général ne demandent pas a ce qu'un logiciel soit a jour (ils ne font déjà pas les mises a jour sur windows que ce soit de sécurité ou pour les logiciels en général)
    ils veulent quelques chose de fiable , en français et pas compliqué, je trouve que ubuntu et son unity correspondent bien a cela.

    tant que les failles de sécurités comme la dernière pour openssl sont mit a jours dans la lts, sa suffit.

  • # Moi, quand je vois qu'un mec casse de l'Ubuntu pour ensuite écrire "Fedora 20 pour les serveurs"...

    Posté par  . Évalué à 5.

    … je me dis que :
    - hypothèse 1 : le seul serveur qu'il a vu de près est celui qui lui ramène son café au comptoir,
    - hypothèse 2 : sa copine se frotte nue tous les soirs contre un poster de Mark Shuttleworth.

    Plus sérieusement, je trouve qu'Ubuntu fonctionne très bien en environnement professionnel, à la condition de l'installer et l'administrer à la façon Debian, à savoir :
    - installation minimaliste via Debootstrap
    - ajout brique par brique des composants souhaités (facilement scriptable).

    De plus, Ubuntu (en serveur) permet d'avoir des composants relativement à jour, voire très à jour, "out the box" et sans bidouilles contrairement à Debian ("pinnning" parce que les backports sont relativement limités) et CentOS/RedHat pour lesquels la gestion des dépôts relève un peu de la "fête du slip".

    Le premier exemple qui me vient à l'esprit est le cas de LXC.

  • # Masturbation de cerveau ?

    Posté par  . Évalué à 1.

    Bonjour à tous,

    Je lis régulièrement des publication sur linuxfr, et je reste la plupart du temps dubitatif sur le fond des sujet.
    Je poste aujourd'hui pour poser une question : qu'est ce qui vas changer pour moi utilisateur lambda ? Je n'ai strictement rien compris au langage geek utilisé dans l'article à part qu'il ne faut pas l'utiliser pour les experts.
    Soit, je ne suis pas un expert, Ubuntu est la seule distribution que j'ai pu essayer qui marche toute seule sans se casser la tête pour l’installation.
    Toutes les élucubrations d'intégristes au sujets de logiciels pas tout à fait libre, très libre, moins libre me laissent de marbre. J'ai un ordi, je veux qu'il marche, car c'est un outil pour faire des choses, pas pour passer des heures à essayer qu'il marche.
    Donc, j’attends un seul VRAI argument me prouvant qu'Ubuntu est non utilisable, sinon je continuai comme avant et j'assisterai encore et toujours à la dispersion habituelle du monde du libre qui fait si bien les affaires du logiciel propriétaire.

    Pierre

    • [^] # Re: Masturbation de cerveau ?

      Posté par  . Évalué à 5.

      Si tu as lu les commentaires, tu aurais vu que la plupart des gens pensent que ces arguments ne sont pas valables. Et puis, je ne vois pas pourquoi tu suivrais les arguments de quelqu'un d'autre si ta distribution te plaît.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Masturbation de cerveau ?

      Posté par  . Évalué à 3.

      Donc, j’attends un seul VRAI argument me prouvant qu'Ubuntu est non utilisable

      Bof… pas inutilisable, juste pas adaptée aux besoins de tout le monde. En même temps, c'est normal, puisque tout le monde à des besoins différents. Ajoutes à ça le fait que l'auteur soit, selon moi, quasiment un RH fanboy, et voila le bouzin non argumenté ( ou avec des arguments fallacieux ).

      Au passage, si ta distro te plaît, si tu ne lui vois aucun défaut, inutile de changer. Perso j'ai voulu essayer de changer à diverses reprises pour voir autre chose, mais jamais à cause d'un type qui m'a dit "ta distro c'est de la merde". A ceux-la, je leur ris au nez.

  • # Module de gestion de logithèque Ubuntu

    Posté par  (site Web personnel) . Évalué à 1.

    Je sais que l'article évoque plutôt le cas des serveurs avec des arguments techniques. Mais, sans aucunement contester ces arguments (je serais vite noyé), en dehors des serveurs, la grande majorité des utilisateurs se contre-foutent royalement de tous ces arguments et peu importe qu'ils soient justifiés ou pas. Trop technique pour la famille Michu qui veut juste un système orienté "desktop".

    Par contre, je viens de re-tester cette nouvelle version sous VirtualBox et le module de gestion de logithèque Ubuntu est et reste (depuis que je teste sous VBox) un grand foutoir ! Certes, les applications sont classées par rubriques et sous thèmes. Mais la logique ne suit pas :
    * Un classement super bordelique à s'arracher les cheveux : ni classement alphabétique, ni classement par "popularité" des applications ! Le tiercé dans le désordre ! On ne sait quoi chercher …. surtout si on ne connait pas trop l'univers de la Banquise et/ou celui d'Ubuntu (certaines applications étant assez spécifiques à Ubuntu) !
    * Un retour en arrière pénible : Allez en milieu de liste des applications et allez voir les détails d'une (quelconque) application. Revenez ensuite vers l'ensemble de la liste et …. dorbel de [auto-censuré] vous revenez au début de cette foutu liste ! Ce qui oblige à devoir tout se retaper !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.