Sommaire
- Raison 1 : Noyau Linux non supporté
- Raison 2 : Upstart
- Raison 3 : Les services sont démarrés et ajoutés au démarrage par défaut lors de leur l'installation
- Raison 4 : MySQL
- Raison 5 : Choix de sécurité discutables
- Raison 6 : Compiz & Mir
- Autres supposées raisons devant vous pousser à choisir Ubuntu
- Conclusion
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 :
- 2013-05-12 : Mir in Kubuntu ;
- 2013-06-19 : Mir, the Canonical CLA and skewing the playing field ;
- 2013-07-15 : How XMir and Mir fit together ;
- 2013-08-22 : If you ever use text VTs, don't run XMir right now ;
- 2013-10-02 : The state of XMir ;
- 2014-03-24 : Why the Display Server DOES matter.
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
#12 – Ubuntu is the majority of public cloud workloads : Et Microsoft Windows est installé sur la majorité des PC de bureau donc je devrais m'en servir sur toute mes machines ? Je sais que je suis un peu malhonnête dans ma comparaison, mais les nombres ne nous ont jamais rien dit sur la qualité d'un logiciel (OpenSSL ?). L'argument « Tout le monde l'utilise/le fait donc cela doit être bien » n'est pas valide.
#11 – Ubuntu is the #1 platform for production OpenStack deployments : Et nous revoilà avec l'argument « Le plus, le mieux », mais cette fois avec des chiffres intentionnellement truqués, tirés d'un sondage sur les systèmes d'exploitation utilisés en production pour les instances d'OpenStack. Essayons de refaire les calculs à partir des sources:
| 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 :).
- #10 Ubuntu is built on IAAS for IAAS users : Buzzword mania, aucune fonctionnalité mentionnée.
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 tuxicoman (site web personnel) . Évalué à 10. Dernière modification le 29 avril 2014 à 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 Reihar . É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 Marc Quinton . Évalué à 10. Dernière modification le 29 avril 2014 à 10:52.
bah, compte le nombre de clics pour arriver jusqu'à ca : http://cdimage.debian.org/debian-cd/7.5.0/ia64/iso-cd/
salutations.
[^] # Re: OSEF
Posté par Anonyme . Évalué à 8.
Attend, il faut cliquer ?
Je veux installer Deubianne moi, pas faire de l'Internet.
[^] # Re: OSEF
Posté par Marc Quinton . É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 Reihar . Évalué à -10.
En fait, en dehors de la France, les gens sont capables de parler anglais.
[^] # Re: OSEF
Posté par zul (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 Albert_ . É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 SpaceFox (site web personnel, Mastodon) . Évalué à 10.
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 Albert_ . É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 karteum59 . Évalué à 7.
Je vois au moins deux autres explications:
[^] # Re: OSEF
Posté par Larry Cow . É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 Albert_ . É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 Dr BG (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 freem . É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 Dr BG (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 SpaceFox (site web personnel, Mastodon) . É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 Albert_ . É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 Renault (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 Albert_ . Évalué à 3. Dernière modification le 30 avril 2014 à 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 SpaceFox (site web personnel, Mastodon) . É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 :
La connaissance libre : https://zestedesavoir.com
[^] # Re: OSEF
Posté par Renault (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 Albert_ . É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 Renault (site web personnel) . Évalué à 3.
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 SpaceFox (site web personnel, Mastodon) . É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 claudex . É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 freem . É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 Dr BG (site web personnel) . Évalué à 3.
Ce que tu cherches : la pierre de Rosette.
[^] # Re: OSEF
Posté par freem . É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 gst . Évalué à 1.
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 Dr BG (site web personnel) . Évalué à 7.
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 Jiel (site web personnel) . Évalué à 1.
Les scandinaves ont de nombreux films en V.O. sans sous-titrage.
[^] # Re: OSEF
Posté par Jiel (site web personnel) . Évalué à 3.
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 reynum (site web personnel) . Évalué à 1.
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 reynum (site web personnel) . Évalué à 3.
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 zebra3 . Évalué à 4.
Ç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 reynum (site web personnel) . Évalué à 1.
SI!
kentoc'h mervel eget bezan saotred
[^] # Re: OSEF
Posté par Zenitram (site web personnel) . Évalué à -9. Dernière modification le 29 avril 2014 à 23:55.
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 Thomas Douillard . Évalué à 2.
Et on s'arrête au constat ? Si on s'arrête là on a aucune solution.
[^] # Re: OSEF
Posté par Zenitram (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 Thomas Douillard . É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 mael . Évalué à 3.
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 Jiel (site web personnel) . Évalué à 4.
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 Jiel (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 freem . É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 Reihar . Évalué à 6.
Le truc, c'est que c'était pire avant.
[^] # Re: OSEF
Posté par khivapia . É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 Marc Quinton . Évalué à 8.
CQFD.
[^] # Re: OSEF
Posté par thomasv . É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 Marc Quinton . É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 Le Gab . Évalué à 4. Dernière modification le 29 avril 2014 à 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 zebra3 . Évalué à 8.
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 Le Gab . É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 CHP . Évalué à 0.
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 Le Gab . Évalué à 5. Dernière modification le 30 avril 2014 à 13:59.
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 Albert_ . É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 Le Gab . Évalué à 2.
Je saute dedans ou pas? Mmm… non. :)
[^] # Re: OSEF
Posté par Albert_ . É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 Le Gab . Évalué à 0.
Kamoulox!
[^] # Re: OSEF
Posté par lenod . É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 clique sur le gros bouton vert "Télécharger Debian 7.5"
Voilà.
[^] # Re: OSEF
Posté par Dr BG (site web personnel) . Évalué à 8. Dernière modification le 29 avril 2014 à 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 Professeur Méphisto . Évalué à 10.
bin, j'ai cliqué une seule fois sur ton lien et j'y suis arrivé.
[^] # Re: OSEF
Posté par zebra3 . É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 Reihar . Évalué à 1.
https://i.imgur.com/5nXG2ud.jpg
[^] # Re: OSEF
Posté par zebra3 . É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 barmic . É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 Misc (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 zebra3 . É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 Astaoth . É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™.
Emacs le fait depuis 30 ans.
[^] # Re: OSEF
Posté par Anonyme . Évalué à 2.
[^] # Re: OSEF
Posté par freem . Évalué à 1.
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. )
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 Anonyme . Évalué à 9.
À é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 KiKouN . Évalué à 5.
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 freem . É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 morphalus . É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 freem . É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 Anonyme . Évalué à 3.
En fait,
screengère des sessions que tu peux détacher du shell courant et rattacher à un ou plusieurs autres shells.[^] # Re: OSEF
Posté par freem . É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 Sytoka Modon (site web personnel) . Évalué à 6.
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 Fabimaru (site web personnel) . Évalué à 10.
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 Siosm (site web personnel) . Évalué à -5.
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.
Ont-il attendu que Debian passe sur Upstart pour passer sur Upstart ?
[^] # Re: Upstart, Debian
Posté par gnumdk (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 Siosm (site web personnel) . Évalué à -5. Dernière modification le 30 avril 2014 à 02:55.
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 Malizor . É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 Siosm (site web personnel) . Évalué à -2.
Si tu as un lien avec des informations à ce sujet je suis intéressé.
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/.
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 Albert_ . É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 Siosm (site web personnel) . Évalué à 0.
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 777tous 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 gnumdk (site web personnel) . Évalué à 7.
Tiens, cadeau:
https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd
[^] # Re: Upstart, Debian
Posté par Siosm (site web personnel) . Évalué à 0.
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 Malizor . Évalué à 3.
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.
« 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.
En fait je répondais à cette partie de ton commentaire précédent :
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 Siosm (site web personnel) . Évalué à -4.
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 :
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).
Merci d'énoncer l'évident, tout logiciel a des bugs. Cf commentaire au dessus qui explique le problème avec ces bugs.
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.
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 claudex . Évalué à 6. Dernière modification le 06 mai 2014 à 11:55.
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 Siosm (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 claudex . É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 Albert_ . É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 M.Poil (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 !!!
[^] # Re: é è ai
Posté par oinkoink_daotter . Évalué à 3.
Dans le même genre, il faut remplacer tous les "inclue" par des "inclut" dans le nourjal. Inclure, 3ème groupe 3ème personne du singulier.
[^] # Re: é è ai
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigés (et plein d'autres), merci.
[^] # Re: é è ai
Posté par Francky (site web personnel) . Évalué à 1.
Cela aurait aussi évit é beaucoup de travail
[^] # Re: é è ai
Posté par Francky (site web personnel) . Évalué à 1.
Vous pourriez être tenté de me rétorquer que cela risquerait de rendre le travail des administrateurs plus complex e
# Plus supporté
Posté par Khaos (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 Marc Quinton . É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 Siosm (site web personnel) . Évalué à -5.
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).
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 Khaos (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 CHP . Évalué à 6.
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 patrick_g (site web personnel) . Évalué à 10. Dernière modification le 29 avril 2014 à 10:33.
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 ?
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 ?
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.
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/pollinatedonc il n'est nullement nécessaire de faire confiance aux serveurs de Canonical.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).
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 ?
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 Psychofox (Mastodon) . É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 Albert_ . Évalué à 10. Dernière modification le 29 avril 2014 à 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 kowalsky . É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 Renault (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 Malizor . É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 Siosm (site web personnel) . Évalué à -5.
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.
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 Sébastien Koechlin . Évalué à 4.
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 patrick_g (site web personnel) . Évalué à 10. Dernière modification le 29 avril 2014 à 11:35.
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 Siosm (site web personnel) . Évalué à -5.
Parce que la décision n'as pas été prise arbitrairement sans concertation avec les autres projets. Le noyau 3.2 est supporté à la fois par Debian et Ubuntu ce qui réduit certainement la charge de travail. Si Debian base la version 8 sur le noyau 3.13, alors mon argument n'aura plus de poids. Ce n'est pas encore le cas.
Voici une liste de bugs qui pointe vers des problèmes techniques dans Upstart (https://lwn.net/Articles/582585/). Ces bugs ont été acceptés par le mainteneur d'Upstart (à l'époque) comme valides. Cela aurait peut-être dû les pousser à envisager une alternative plus tôt.
Plusieurs choix s'offraient à eux, et ce n'est pas comme si cette décision n'était pas pressentie depuis un moment au vu du mouvement général des distributions vers systemd. Ils auraient pu aussi prévoir le coup et avoir gardé un paquet systemd à peu près fonctionnel sans le mettre par défaut (une grosse partie du boulot a été déjà fait par les autres distributions).
Les projets annoncés comme « morts » n'ont jamais attirés une foule de contributeurs volontaires. Les bugs mentionnés ci dessus datent pour certains de plusieurs années. Permets moi de douter fortement qu'ils soient corrigés dans Ubuntu 14.04.
Je n'avais pas connaissance de ce fait. Merci pour la précision, cette réserve n'a donc plus lieu d'être.
C'est un argument auquel je réponds dans la suite : les options de configurations par défaut ne sont pas souvent changées et il est très peu probable qu'elles ne le soient jamais sur les clouds qui ne changent déjà pas les seeds des machines virtuelles.
Ce n'est pas ce point que je critique. Je ne parle pas de la validation du certificat mais de la session TLS elle même.
Si il est possible de mettre un serveur local pour le faire alors les autres solutions bien moins intrusives et tout aussi efficaces sont aussi réalisables.
Le problème ici est qu'un attaquant aura connaissance d'une partie importante des données qui seront ajoutée dans la « pool » d'entropie, et peut potentiellement bruteforcer le reste des données dont il n'as pas connaissance.
Contacter inconditionnellement un serveur au démarrage d'une machine n'est pas non plus une action neutre en terme de sécurité. Que se passe-t-il si ce certificat est volé ou si une faille de sécurité est trouvée dans curl ?
La quasi totalité des développeurs de la pile graphique sous Linux ne travaillent pas sous Ubuntu. Les projets annoncés comme morts n'attirent pas les contributeurs. De plus il leur faudra supporter à la fois Compiz et Mir pour les années à venir. Comme tous les projets, les ressources ne sont pas illimités et ils vont devoir faire de plus en plus de travail sans aide extérieure, ce qui impactera nécessairement le nombre de bugs qui seront corrigés.
Je veux bien des exemples. GNOME 3 n'en est pas un.
Non, parce qu'il est tout à fait possible de se passer de firewalld qui est chargé de la gestion des règles iptables. Trois commandes simples suffisent pour s'en débarrasser et rester dans une configuration complètement supportée :
systemctl stop frewalld
systemctl disable firewalld
systemctl mask firewalld
Il n'est pas du tout aussi facile de se débarrasser des modifications faites dans la pile graphique sous Ubuntu (il faut au minimum changer le noyau et mesa). Je veux bien un lien vers cette discussion sur firewalld.
Je mentionne juste après la raison pour laquelle cet ajout affecte aussi ceux qui n'utilisent pas Mir sur Ubuntu.
Si mon texte est du FUD, où sont les arguments contre Fedora 20 sur un serveur ?
[^] # Re: Fallait attendre vendredi
Posté par Albert_ . É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 freem . É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! ):
Intègre vite. Donc, peu de test, donc de bugfixes.
Ici, c'est expliqué pourquoi en prod c'est moyen… je vais pas paraphraser.
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.
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 Siosm (site web personnel) . Évalué à -3.
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.
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.
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.
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 freem . Évalué à 1.
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.
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.
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 groumly . Évalué à 2.
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 Siosm (site web personnel) . Évalué à -4. Dernière modification le 03 mai 2014 à 21:43.
Encore une fois, ce n'est pas du tout de cela dont je parle.
Rappels sur l'établissement d'une session TLS :
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.
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 André Rodier . Évalué à 2. Dernière modification le 29 avril 2014 à 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…
[^] # Re: Mr Pernickety
Posté par Siosm (site web personnel) . Évalué à 1.
Merci, c'est corrigé.
# Mouarf
Posté par claudex . Évalué à 10.
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 zebra3 . É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 Siosm (site web personnel) . Évalué à -3.
J'attends les arguments contre le format de paquet RPM :).
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 freem . Évalué à 3.
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 Albert_ . É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 freem . É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 Albert_ . Évalué à 2.
les delta rpm fait que tu ne download que la difference entre deux versions de paquet.
[^] # Re: Mouarf
Posté par freem . É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 Albert_ . É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 CrEv (site web personnel) . Évalué à 2.
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
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 Albert_ . É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 freem . Évalué à 1. Dernière modification le 02 mai 2014 à 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.
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 Albert_ . É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 Renault (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 claudex . É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 Renault (site web personnel) . Évalué à 2.
Oui mais finalement tu retombes sur du rpm ou dpkg.
[^] # Re: Mouarf
Posté par claudex . É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 Albert_ . É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 Dr BG (site web personnel) . Évalué à 2.
Et quel serait le problème de RPM qui en serait la cause ?
[^] # Re: Mouarf
Posté par Albert_ . É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 CrEv (site web personnel) . Évalué à 5.
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.
Heu, ça c'est des arguments ??
[^] # Re: Mouarf
Posté par Albert_ . Évalué à 4. Dernière modification le 30 avril 2014 à 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 flan (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 Albert_ . Évalué à 1.
Le facon de gerer les dependances peut etre?
[^] # Re: Mouarf
Posté par flan (site web personnel) . Évalué à 3. Dernière modification le 30 avril 2014 à 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 Anonyme . Évalué à 2.
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 flan (site web personnel) . Évalué à 1.
Oui, il y a de ça aussi, en effet.
[^] # Re: Mouarf
Posté par zebra3 . É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 CrEv (site web personnel) . Évalué à 2.
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 Frank-N-Furter . É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 Albert_ . É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 CrEv (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 Albert_ . É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 Renault (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 CrEv (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 Albert_ . É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 Renault (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 Albert_ . Évalué à 2. Dernière modification le 30 avril 2014 à 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 Renault (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 Albert_ . É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 Renault (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 Albert_ . Évalué à 1. Dernière modification le 30 avril 2014 à 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 Anonyme . É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 Albert_ . É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 Anonyme . É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 Albert_ . É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 Anonyme . É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 freem . É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 Anonyme . Évalué à 2.
Oui, c'est ce que je voulais dire. Merci.
# systemd-login
Posté par inico (site web personnel) . Évalué à 7. Dernière modification le 29 avril 2014 à 21:59.
Il n'y a pas qu'Ubuntu qui fournis systemd-logind avec un init classique:
[^] # Re: systemd-login
Posté par Siosm (site web personnel) . Évalué à 0.
Tout à fait, si l'on n'utilise pas systemd. Ce que je ne recommande pas dans l'article.
# Raison 3
Posté par barmic . Évalué à 10.
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.
Ce n'est pas permanent parce qu'ils n'ont pas décris qu'il est tout à fait possible d'utiliser
DPkg::Pre-InvokeetDPkg::Post-Invokedans/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 Psychofox (Mastodon) . É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 st3rk (site web personnel) . Évalué à 1.
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 barmic . É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 freem . É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 Siosm (site web personnel) . Évalué à 0.
Cela résout en effet une partie du problème. Je vais mettre à jour avec cette remarque.
Je ne connaissais pas. Merci pour cette précision.
# Pitoyable
Posté par MTux . É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 :
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.
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.
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.
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.
Rien à battre sur un serveur, pas d'interface graphique…
[^] # Re: Pitoyable
Posté par Misc (site web personnel) . Évalué à 4.
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.
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 SlowBrain (site web personnel) . Évalué à 2.
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.
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.
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é.
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 Siosm (site web personnel) . Évalué à 0.
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.
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.
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.
Si la gestion des services sur un serveur était aussi simple que cela je pense que systemd n'existerai pas.
A ma connaissance, les seules distributions activant les services par défaut sont dérivées de Debian.
C'est le « Souvent » qui importe ici.
En effet, c'est une erreur de ma part.
http://en.wikipedia.org/wiki/MariaDB#Prominent_users
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 gnumdk (site web personnel) . Évalué à 5.
Blog, ArchLinux… Tu nous fais rêver là… Et ça vient cracher sur Ubuntu Server après…
[^] # Re: Pitoyable
Posté par Martin Peres (site web personnel) . Évalué à 7. Dernière modification le 01 mai 2014 à 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 claudex . É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é.
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 Martin Peres (site web personnel) . É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). 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.
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!
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 claudex . Évalué à 3.
Justement, non, regarde le lien que j'ai donné, le mainteneur du 3.2, ce n'est pas GKH.
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 Martin Peres (site web personnel) . Évalué à 3.
My bad, en effet!
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 claudex . Évalué à 5.
Je n'ai jamais parlé de mon expérience personnelle (d'ailleurs, je n'ai jamais mis Ubuntu sur un serveur)
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 Siosm (site web personnel) . Évalué à -3.
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.
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 undeuxtroisout . É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 Marotte ⛧ . Évalué à 3.
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 :
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 s3boun3t . É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 BuckFuck . É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 piemchien . É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 claudex . É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 freem . Évalué à 3.
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 Teutates (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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.