Bonjour,
c'est la première fois que j'écris ici alors soyez indulgents SVP !
Je viens ici pour proposer une idée de distribution Linux (à moins qu'elle n'existe déjà, auquel cas je serai ravi de la connaître).
Voici mon idée : en tant qu'utilisateur de distributions Linux depuis de nombreuses années (dans l'ordre : Slackware, RedHat, Fedora, Debian, Ubuntu), j'ai le problème suivant, assez classique il me semble :
soit je dispose d'un système très stable (Debian stable, par exemple) et je dois attendre deux ans pour qu'une nouvelle version d'une application dont j'ai besoin (parce qu'elle apporte une nouvelle fonctionnalité ou corrige des bugs) soit disponible. Ou bien, il me faut la compiler, jongler avec les dépendances, chercher des paquets dans d'autres distributions et les adapter, etc. Bref, c'est long et pénible ou frustrant…
soit je dispose d'un système un peu moins stable (Ubuntu par exemple), qui change tous les six mois. J'ai les nouvelles versions des applications mais il y a des bugs au niveau du système ou des petits problèmes au niveau du bureau, des bidouilles à faire, des personnalisations à reprendre et ça prend un temps fou, sans parler de l'énervement…
il existe aussi les "rolling release", mais un tel système ne doit pas être très stable (je n'ai jamais essayé). En tous cas, ça ne m'inspire pas confiance…
Donc, j'aimerais bien pouvoir disposer d'un système stable, qui ne change que tous les deux ans (par exemple) et d'applications qui évoluent au gré des améliorations de celles-ci et des corrections de bugs… Ce serait une distribution plutôt orientée Desktop, car le besoin me semble plus coller à ce type de distributions.
Par exemple, le noyau, le bureau, les bibliothèques système pourraient rester inchangés pendant deux ans et par ailleurs, on pourrait installer la dernière version de Gimp quand elle sort, ou le dernier LibreOffice, etc.
La distribution serait divisée en deux : une partie Système, et une parties Applications. La première serait stable et n'évoluerait que tous les deux ans. La deuxième suivrait les nouvelles versions des applications. L'utilisateur ne serait bien sûr pas obligé d'installer une nouvelle vesrion s'il est satisfait de celle qu'il utilise.
Ce serait la distribution qui proposerait les nouvelles versions et pas l'utilisateur qui devrait farfouiller sur le Net et installer des ppa ou compiler des applis. Le but est bien sûr de simplifier au maximum la tâche de l'utilisateur.
Bien entendu, lorsque de nouvelles bibliothèques systèmes sont nécessaires au fonctionnement de la nouvelle version d'une appli, celles-ci seraient installées localement avec l'appli et non au niveau global système. Même si ça promet de la redondance, cela ne me semble pas bien grave : aujourd'hui il y a de la place sur les disques et le giga-octet n'est pas cher…
Je précise que je n'ai aucune compétence pour faire cela. Je programme un peu et je bidouille le système, mais ce qu'il faudrait faire ici me dépasse de très loin…
Par contre, j'aimerais bien connaître votre avis sur cette idée. Peut-être que ça a déjà été proposé, ou même que cela existe déjà. Peut-être que c'est idiot ou pas réalisable car trop compliqué…
Bref, vos avis de "pros" de l'informatique et du logiciel libre m'intéressent…
D'avance, merci.
# Le problème est là...
Posté par ʭ ☯ . Évalué à 10.
Bravo, tu viens de créer un trou de sécurité : bien que la bibliothèque système soit corrigée, la bibliothèque embarquée dans l'appli sera toujours vulnérable. C'est pour ça que les distributions bien faites séparent les bibliothèques des applications.
Pour le reste, tu ignores visiblement que les développeurs préfèrent programmer avec les dernières versions des bibliothèques pour simplifier le code. Il faut donc toujours TOUT très récent pour avoir des logiciels récents.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Le problème est là...
Posté par bibifric05 . Évalué à 2.
Oui, c'est un problème en effet… Mais si les applications utilisent des bibliothèques systèmes récentes et si des failles de sécurité ont été corrigées dans ces bibliothèques, il doit être faisable de répercuter les corrections dans les applications…
[^] # Re: Le problème est là...
Posté par Anonyme . Évalué à 7.
faisable oui, humain non
[^] # Re: Le problème est là...
Posté par flagos . Évalué à -1.
Tu veux dire qu'on est pas capable de patcher une application avec une faille de sécurité ?
On peut très bien lister toutes les dépendances de chaque appli, et de relancer les compiles correspondantes lorsqu'une faille est découverte.
Pour moi, c'est plus un choix disque dur occupe/taille des binaires lors des mises a jour VS flexibilité du système.
[^] # Re: Le problème est là...
Posté par kursus_hc . Évalué à 6.
Non il dit que personne ne veut le faire, vu l'ampleur et le côté très ennuyeux de la chose.
[^] # Re: Le problème est là...
Posté par totof2000 . Évalué à 3.
C'est pour ça qu'il dit que ça peut s'automatiser. Et si c'est vrai que c'est un travail de longue haleine, on peut créer un outil qui automatisera la génération de conf de l'outil d'automatisation.
[^] # Re: Le problème est là...
Posté par flagos . Évalué à 3.
En fait, ya deja les dependances de chaque paquet. On sait deja sur quels libs s'appuient chaque paquet, il suffit d'inverser la liste. Ca devrait couvrir pas mal de cas.
Bon après, c'est du yaka fokon, j'ai aucune envie de passer du temps a faire ca, mais j'ai toujours été très surpris qu'aucune distrib ne parte sur une solution dans le genre.
[^] # Re: Le problème est là...
Posté par NeoX . Évalué à 7.
peut-etre parce que tous ce sont dit :
[^] # Re: Le problème est là...
Posté par claudex . Évalué à 10. Dernière modification le 03 novembre 2014 à 22:30.
Comme dit ailleurs, les distribs ont déjà du mal à sécuriser une version de paquet, alors plusieurs, il n'y a carrément pas la main d’œuvre.
« 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: Le problème est là...
Posté par BAud (site web personnel) . Évalué à 5. Dernière modification le 04 novembre 2014 à 22:40.
il faudrait le remonter au projet MANCOOSI, ils seraient très intéressés (surtout par le "il suffit" àmha…).
Une solution par parcours de graphe, dans le cas général, est par nature NP-complexe et dépendant de la qualité des données, influant la complexité de ce graphe.
Il y a un peu de littérature (et d'analyse) sur le sujet :
Je te laisse chercher les apports de la démarche que ton intuition ou "bon sens" n'aurait su entrevoir. Tu as une chance de soulever un coin du grand voile :-)
[^] # Re: Le problème est là...
Posté par barmic . Évalué à 2.
Je ne sais pas ce que fait MANCOOSI, mais lancer un
rdependsur l'ensemble des paquets Debian, c'est probablement long, mais pas vraiment insurmontable. Si c'est vraiment ça, je trouve dommage que l'UE dépense beaucoup d'argent là dedans.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le problème est là...
Posté par BAud (site web personnel) . Évalué à 4.
Ils ont fourni en libre des outils (pas que pour Debian, pour Mandriva Linux aussi) : http://www.mancoosi.org/software/
Ils ont aussi contribué aux mass-rebuild de distributions (s'assurer que tous les paquets recompilent bien d'une version à l'autre de la distribution, enlever les paquets ne passant pas). Dans leurs outils, il y en a qui détectent les boucles (bidule a machin comme prérequis et machin a bidule comme prérequis), ce qui complique le bootstrap et correspond au problème de l’œuf et de la poule. Cela a permis de fiabiliser les paquets et les outils à disposition des empaqueteurs de distribution.
Un solveur de dépendances n'est pas aussi simple que vous semblez le croire… Quelques cas particuliers sont simples, c'est le cas général qui est plus compliqué
[^] # Re: Le problème est là...
Posté par barmic . Évalué à 4.
Sauf que ce n'est pas ce dont il était question. Il n'était pas question de faire de la résolution de dépendance, mais de faire une inversion de dépendance (note moi je réponds à "On sait deja sur quels libs s'appuient chaque paquet, il suffit d'inverser la liste"). Pour faire ça tu prend la représentation de ton graphe (le graphe est connu et limité ce graphe), tu inverse tous les arcs et tu fait la résolution de dépendance. Ce n'est pas simple, mais tu as un super outil pour le faire qui s'appelle
aptqui le fait déjà.Encore une fois il n'est pas de problématique générale, mais d'une utilisation précise qui est déjà adressée par les outils Debian (cf la sous commande
rdependd'APT). Et non pas de résolution d'un 3SAT bien poilus.MANCOOSI fait des choses très bien j'en suis sûr mais pour ce qui est de l'inversion de dépendance, soit ils ont déjà résolu le problème soit c'est un problème qui était résolu avant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le problème est là...
Posté par hervé Couvelard . Évalué à 10.
Il était tellement compliqué de répondre un truc comme cela :
"Ce que tu cherches est le saint graal que l'on ne peut obtenir, juste s'en approcher.
Parce que applications et système sont intrinsèquement liés : les applications se "lient" avec des bibliothèques système particulières. Elles ont vraiment besoin que les bibliothèques soient présentes dans les bonnes versions pour fonctionner (par exemple parce qu'il y a une fonction nouvelle qui n'est pas présente dans la version précédente.)
On peut effectivement embarquer, compilées dans le logiciel les versions particulières des bibliothèques que l'on utilise (compilées statiquement), mais dans ce cas lors d'une mise à jour de la bibliothèque pour des problèmes de sécurité, celle embarquée dans ton application ne sera pas mise à jour lorsque celle du système le sera. Il faudrait alors recompiler ton logiciel avec la bibliothèque mise à jour.
De plus avec ce système, chaque logiciel emporte ses propres versions des bibliothèques, ce qui pose un soucis en terme de place et de dispersion des efforts.
On ne peut pas avoir liberté et sécurité en même temps, on ne peut pas avoir stabilité et toutes dernières versions. chaque distribution fait des choix qui posent sur ces 2 lignes un curseur à l'endroit qui leur semble optimal. Chaque utilisateur peut alors choisir le compromis qui lui convient le mieux : debian stable ou debian unbstable, ubuntu, fedora, mageïa, arch ou gentoo.
"
C'était plus long, moins cassant, plus enrichissant, moins hautain. Ce que l'on serait en droit d'attendre d'une communauté, mais il ne faut pas trop en demander… donc ne pas trop en attendre.
[^] # Re: Le problème est là...
Posté par bibifric05 . Évalué à 2.
Merci pour cette réponse détaillée et argumentée.
Je n'ai évidemment pas testé toutes les distributions Linux, même si ça fait vingt ans que j'utilise ce système. Mais je pense quand même que le modèle des paquets séparant applications et bibliothèques a ses limites et est bien contraignant pour l'utilisateur.
Quand on voit la facilité d'installation d'une application sous Windows (bien sûr ce système est un nid à virus), on rêve d'avoir la même chose sous Linux. Les ppa, ça peut dépanner, mais ce qu'il faut à mon avis c'est carrément un autre modèle de distribution des logiciels. Peut-être pas celui auquel j'ai pensé, mais le modèle actuel me semble limité…
[^] # Re: Le problème est là...
Posté par coid . Évalué à 9.
Ce n’est un nid à virus que si tu installes n’importe quoi. Autrement, non, pas de souci.
Je suis totalement de ton avis, lier les applications au système est une erreur. Mais la solution arrive (pas vite):
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
[^] # Re: Le problème est là...
Posté par kursus_hc . Évalué à 2.
Tu peux développer ? Ou donner une liste des logiciels que tu as galéré à installer ? Parce que je ne vois pas là.
[^] # Re: Le problème est là...
Posté par JGO . Évalué à 7.
Tout au contraire, l'installation de logiciels sous windows est bien plus complexe (l'utilisateur est livré à lui-même pour trouver des logiciels, il n'y a aucune cohérence dans les procédures d'installation, et les dépendances en particuliers de drivers sont infernales). Le modèle des distributions linux du gestionnaire de paquets est tellement meilleur qu'il s'est généralisé sur tous les systèmes récents, juste traduit en langage de marketeux : appstore.
[^] # Re: Le problème est là...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
une grosse distrib static pour ne pas s’embêter sur les versions de lib utilisé par les softs ?
"La première sécurité est la liberté"
[^] # Re: Le problème est là...
Posté par Misc (site web personnel) . Évalué à 3.
Il reste plus que les soucis autre que les libs à régler :
- interface dbus
- langage de script
[^] # Re: Le problème est là...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est chaud ça oui. Un protocole qui change, ce n'est pas évident.
Il faut avoir l'interpréteur qui va avec, c'est ça le souci ?
"La première sécurité est la liberté"
[^] # Re: Le problème est là...
Posté par Misc (site web personnel) . Évalué à 2.
Il a des modules en C. Tu veux les lier statiquement à l'interpréteur ?
[^] # Re: Le problème est là...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne comprends pas le problème. Qu'est-ce qui t'empèche de le livrer comme avant ?
Le "statique" n'est pas une religion, c'est juste un moyen de casser les dépendances.
"La première sécurité est la liberté"
[^] # Re: Le problème est là...
Posté par Misc (site web personnel) . Évalué à 2.
Les modules sont liés en dynamiques avec l’interpréteur python pour lequels ils sont compilés, et avec les deps en dynamiques aussi. Si maintenant, tu veux mettre du statique, faudra en mettre d'un coté ou de l'autre ( genre soit le module python, soit l’interpréteur, soit les 2 ). Et dans tout les cas, tu va avoir des risques de conflits de symboles sauf si tu fait du dynamique et qu'ils utilisent la même version.
Genre j'utilise la libpcre dans mon module python et dans l’interpréteur, et manque de bol, c'est pas la même version, ça va coincer.
# Containers
Posté par celedhrim . Évalué à 9.
En gros il faudrait un container par appli
Tu as ton système installé et les appli dans des container avec leur petit :)
Par contre niveau disque ça peux vitre être violent !
[^] # Re: Containers
Posté par Tonton Benoit . Évalué à 3. Dernière modification le 03 novembre 2014 à 14:26.
Une version Desktop de CoreOS quoi.
C'est pas si violent que ça niveau espace, Docker utilise intelligemment les snapshots.
# NixOS
Posté par Gilles Crettenand (site web personnel) . Évalué à 9.
Je pense qu'il doit être possible de faire ce que tu décris avec NixOS : http://nixos.org/
Sur cette distrib, tu peux facilement créer un environnement avec les librairies dont tu as besoin pour une application donnée sans changer les librairies utilisées par le reste du système.
Ma connaissance de cette distribution est en revanche très théorique, je n'ai pas encore fais le pas depuis Debian.
# Rolling release et Chakra Linux
Posté par Paul . Évalué à 8. Dernière modification le 03 novembre 2014 à 11:26.
ArchLinux est très stable. Il y a eu quelques petits problèmes lors de la transition vers systemd, mais rien de bien méchant. En tous cas c'est moins bordélique et moins sujet à problème qu'une mise-à-jour d'Ubuntu tous les 6 mois.
Et je crois que la distribution de tes rêves existe, et s'appelle Chakra
Edit: ajout de la citation
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 03 novembre 2014 à 11:42.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Rolling release et Chakra Linux
Posté par bibifric05 . Évalué à 1.
C'est vrai que je n'ai jamais testé Archlinux, il faudra peut-être que j'essaie…
Et merci pour le lien vers Chakra, je vais regarder attentivement.
[^] # Re: Rolling release et Chakra Linux
Posté par kursus_hc . Évalué à 6.
Si t'aimes pas trop la bidouille ce n'est pas nécessaire d'essayer Arch je pense..
Par contre en effet Chakra fait exactement ce que tu demandes, avec le système de "bundles" qui sont en fait des petits disques virtuels avec toutes les dépendances embarquées. On aime ou on aime pas le principe mais ça fonctionne ! J'aime Chakra aussi parce que c'est vraiment une des distribs qui pousse le plus loin la finition dans KDE.
[^] # Re: Rolling release et Chakra Linux
Posté par woprandi . Évalué à -3.
Il n'y a que l'installation d'un peu tendu
[^] # Re: Rolling release et Chakra Linux
Posté par barmic . Évalué à 8.
Non, avec Arch il est recommandé de se tenir au courant (par exemple via le site officiel) avant les mises à jour car la mise à jour automatique ne ferra pas un certain nombre de choses pour toi (notamment pour tout ce qui est correction des fichiers de conf). Non ça n'est pas compliqué, mais oui c'est de la bidouille. Ce n'est pas un mal c'est juste un choix des mainteneurs de la distro qui ne veulent pas prendre le risque de modifier eux-même ce qu'ils trouvent un peu touchy et laisser l'utilisateur faire car il est sensé comprendre ce qu'il touche.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rolling release et Chakra Linux
Posté par Spyhawk . Évalué à 3.
Tu as entendu parler de KaOS? A lire la FAQ, ça ressemble à ce qu'aurait pu devenir Chakra avant qu'ils ne se perdent à réécrire des outils spécifiques ou des bundles CCR: simple, avec une sélection limitée mais bien intégrée d'applications Qt, sans être anti-GTK non plus.
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Kohadon . Évalué à 1.
Je ne peux que recommander manjaro, basé sur Archlinux, cette distribution est tout simplement géniale. Classée 20ème sur distrowatch, elle offre un système stable, 6 mois d'utilisation au quotidien et pas un problème.
Elle est agréable aussi bien pour les débutants (installé chez un ami qui m'a demandé si Linux était nouveau, preuve que l'interface est sympa ;), que pour les utilisateurs avancés.
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Spyhawk . Évalué à 0.
Heu, Manjaro, c'est probablement la pire des distrib dérivée d'Arch. Alors oui, c'est joli avec un beau fond d'écran, mais le principe sur lequel elle se base est complètement bancal àmha.
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Kohadon . Évalué à 4.
La pire induit que toutes les autres sont mieux, sous quels critères ? Le lien vers ton propre commentaire et les liens disponibles dans celui-ci n'indiquent en rien une supériorité des autres distributions dérivés d'Arch, ils indiquent seulement qu'Arch est plus vite mis à jour que Manjaro…
Un peu plus de précision dans ton commentaire serait la bien venu pour éclaircir tes dires.
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par kursus_hc . Évalué à 4.
C'est bien ça je pense.
Citation du dev Arch dans l'article :
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Spyhawk . Évalué à 5.
Pardon, qu'est ce qui n'est pas clair dans "Ils essaient de stabiliser une rolling release en retardant les updates… et les plus importants bugfix de sécurité" (l'emphase est évidemment sur la fin de phrase) ?
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Kohadon . Évalué à 2.
Ma question l'est tout autant, qu'est ce qui te pousse à dire que cette distribution est la "pire" des dérivées d'Arch?
Le seul critère que tu donnes est la fréquence/rapidité des mises à jour par rapport à Arch elle-même et non pas ses dérivées…
J'attends donc de savoir si c'est ton seul critère de comparaison et en quoi Antergos, Chakra, Frugalware ou autres sont meilleures.
Retarder les bugfixs de 2 semaines pour une utilisation desktop/dev ne me dérange pas, as tu eu le temps de t'amuser avec HeartBleed, TripleShake lorsque ces failles sont apparues ? Je ne pense pas.
Manjaro pour une utilisation personnelle convient parfaitement, après les convictions personnelles de chacun, on ne peut y faire grand chose sans arguments valables et pertinents ;)
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Spyhawk . Évalué à 5.
Oui, pour moi, être à jour niveau sécurité est important. Au même titre que je ne vois pas l'avantage d'être sur un Windows troué, une "rolling release" qui est moins à jour au niveau sécu qu'une vrai distribution stable ça craint.
Et c'est là que le bat blesse: Stabiliser une distribution, ça demande beaucoup de temps et de travail. L'effort de backport fait par Debian, Fedora et autre openSUSE est conséquent et une vrai distribution rolling release s'affranchit de celui-ci en s'appuyant directement sur upstream, en envoyant les nouveaux paquets corrigés upstream le plus rapidement possible dans les dépôts. Une "rolling release différée" comme Manjaro, pusique c'est de ceci qu'il s'agit, n'obtient au final ni l'avantage d'une rolling release, ni celui d'une distribution stable (les changements les plus importants demandent de toute façon une intervention de l'utilisateur).
Au passage, Frugalware n'est pas dérivée d'Arch (au plus inspirée avec un fork de pacman), et il y a longtemps que Chakra n'a plus grand chose à voir avec Arch. Reste Antergos, Bridge Linux et quelques autres moins connues qui elles ne sont pas différées.
Mais bon, si l'argument au dessus ne te concerne pas, peut être que le manque de sérieux de Manjaro te ferait reconsidérer la soit disante qualité de cette distribution. Commentaire de dev Arch, au sujet du choix de s'appuyer sur une fonctionnalité dépréciée:
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
6 mois ne permettent pas de se faire une idée de la stabilité d’une distribution, par exemple une Ubuntu non LTS dure 6 mois et par définition en 6 mois elle ne bouge que très peu.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Kohadon . Évalué à -1.
6 mois d'utilisation au quotidien valent mieux que 24 avec une utilisation tout les 2 mois sans mise à jour… De plus on ne commence pas souvent à utiliser une distribution à la date de publication de celle-ci, il y a donc au minimum 2 releases entre le début d'utilisation et l'avis donné 6 mois plus tard (pour le cas Ubuntu)…
Après je ne donne que mon humble avis, et ne m'appuie que sur mon avis, bien que d'autres avant moi aie conseiller cette distribution. Pour ma part j'en suis très satisfait.
[^] # Re: Rolling release et Chakra Linux ET Manjaro
Posté par Astaoth . Évalué à 7.
Avec Manjaro j'ai exactement les mêmes problèmes que j'aurais avec Arch. Je les subis juste avec un peu de retard.
Emacs le fait depuis 30 ans.
[^] # Re: Rolling release et Chakra Linux
Posté par Astaoth . Évalué à 5.
Genre un système qui ne démarre plus à cause du changement d'init c'est pas méchant ? Et si, c'est arrivé à certains (sûrement une malheureuse minorité) qui n'avaient pas spécialement bidouillé leur init.
Arch c'est stable quand il n'y a pas de changement majeur du système, autrement vaut mieux être au courant. Ce qui est un peu idiot, c'est qu'il n'y a pas d'alerte ni rien dans le gestionnaire de paquet, contrairement à equo par exemple (Sabayon, roll-release basée sur Gentoo) qui intègre un lecteur RSS dedans et qui permet d'être bien mis au courant des changements majeurs du système.
Emacs le fait depuis 30 ans.
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à 0.
Arch c'est stable quand tu ne fais pas de mise à jour.
Sinon, soit ça passe, soit ça casse.
[^] # Re: Rolling release et Chakra Linux
Posté par xcomcmdr . Évalué à 5. Dernière modification le 03 novembre 2014 à 18:59.
Euh, juste non. Je fais des mises à jours tous les jours depuis 4 ans (donc depuis le temps où on utilisait SysV, et où /lib n'était pas un lien symbolique, etc…).
Ça passe toujours, parce que ça se fait ainsi :
0.prendre son temps
1.un tour sur archlinux.org pour voir si y'a des instructions spéciales à appliquer (99% du temps ce n'est pas le cas)
2.Faire la mise à jour, merger les .pacnew si y'en a.
Je suis passé de SysV à systemd (par exemple) sans problème.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rolling release et Chakra Linux
Posté par Anonyme . Évalué à 8.
3.ne pas attendre trop longtemps entre les mise à jour, sinon risque de conflit majeur entre 2 ou plus version.
[^] # Re: Rolling release et Chakra Linux
Posté par xcomcmdr . Évalué à 1. Dernière modification le 03 novembre 2014 à 20:00.
Bah oui, c'est même marqué sur le wiki
Comme ce que j'ai dit au dessus, d'ailleurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à -2. Dernière modification le 03 novembre 2014 à 20:57.
Génial, je vais consacrer un ordinateur pour faire des mises à jour. Et je l'utilise quand ? Faire des mises à jour, ce n'est pas à mon avis la raison d'être d'une machine de bureau.
[^] # Re: Rolling release et Chakra Linux
Posté par xcomcmdr . Évalué à 1.
3 à 5 minutes tous les deux jours, ça va pas te tuer…
Perso je préfère largement ça à mettre des PPAs partout sur une Ubuntu et puis m'arracher les cheveux quand il faut mettre à niveau la LTS au bout de 3 ans / 5 ans, mais bon.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rolling release et Chakra Linux
Posté par Paul . Évalué à 7.
Holàlà pourquoi tant de haine.
Je ne voulais sûrement pas conseiller Arch à l'auteur du journal, l'info intéressante de mon commentaire c'était l'existence de Chakra. Mais il a parlé d'Arch, donc j'ai donné un vague avis.
Arch ça casse pas beaucoup (j'ai tendance à dire vraiment rarement pour quelqu'un qui prend la peine de lire et comprendre), c'est pas mal de lecture surtout au début, mais c'est pas du tout à conseiller à quelqu'un qui n'a pas vraiment envie d'y aller.
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à 2.
Disons qu'au vu de mon utilisation et de mes besoins, je ne peux prendre le risque de passer 3 à 5 mn par jour qui sont suceptibles de se transformer en 3 à 5h.
[^] # Re: Rolling release et Chakra Linux
Posté par xcomcmdr . Évalué à -2.
Ça ne s'est jamais transformé en plus de 10 minutes en 4 ans chez moi (vu que je m'en occupe plusieurs fois par semaine pendant 3 minutes à chaque fois… Et encore souvent c'est moins vu que y'a pas d'intervention à faire 8 fois sur 10).
Donc bon: bullshit, monsieur ! bullshit !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à 2.
Personnellement il m'est déjà arrivé de ne pas pouvoir terminer une mise à jour un jour J, et de relancer la manip deux ou trois jours après et miracle, ça marche. J'étais probablement tombé sur un bug qui a été résolu peu de temps après, mais je n'&ai pas eu le temps de m'y remettre. peut-être qu'en cherchant j'aurais trouvé, mais c'était un soir très tard, j'ai préféré aller me coucher.
Tout ça pour dire que je ne dis pas que ça va se transformer en 2 heures systématiquement, mais que potentiellement, il est possible que ça se transforme en une indisponibilité de longue durée. Et ça je ne peux me le permettre.
[^] # Re: Rolling release et Chakra Linux
Posté par Thrillseeker . Évalué à 6.
Cette distribution s'adresse à des personnes qui s'y "connaissent" et tout problème est à cause de l'utilisateur car il n'aura pas fait attention à tel ou tel message dans les logs, ou car il n'a pas suivi les news, ou pas lu le wiki, ou seulement lu à moitié.
Partant de ce principe, en ajoutant le classique "chez moi ça marche", il est difficile d'affirmer ici qu'il peut exister des problèmes car tout problème provient de l'interface chaise/clavier (de l'utilisateur).
Il faut savoir que les problèmes dépendent aussi des paquets installés, en particulier la source (AUR, community, extra?). Car tous les mainteneurs ne font pas la chose correctement et se reposent souvent sur l'idée que c'est une distribution pour des gens qui s'y connaissent (du coup ils peuvent faire de la merde plus facilement).
A part quelques problèmes liés aux mainteneurs/paquets (oui ça existe vraiment), tous les autres problèmes que j'ai eu proviennent d'upstream. Par exemple, avec GTK3, TrueCrypt (update de wxgtk de 2.8 vers 3.0) veut m'ouvrir nautilus au lieu de dolphin comme cela avait toujours été le cas avant (car je suis sur KDE). Une sorte de /bin/nautilus codé en dur dans le code, c'était une énorme régression, mais ce n'était pas la faute d'Archlinux dont l'objectif est de proposer des logiciels à jour…
Ceci dit, ils font quand même des tests, l'ouverture de l'explorateur de fichiers par wxgtk sur KDE n'avait pas du être testé. Ce problème qui date d'avril n'est toujours pas corrigé upstream, je ne sais pas si c'est à cause de wxgtk qui possède "/bin/nautilus" en dur (je n'ai pas trouvé cette chaine dans le code source), ou GTK3 (je penche plus vers cela). Quoi qu'il en soit, c'est un problème upstream. La solution consiste à créer une sorte de lien symbolique de /bin/nautilus vers dolphin. Mais j'aurai pu pester en disant qu'un mainteneur aurait pu prévoir ce lien symbolique pour moi xD
J'ai également eu d'autres problèmes, comme une mise à jour du driver nvidia qui a empêché le serveur X de se lancer au prochain démarrage. En attendant de trouver plus de temps, j'ai interdit la mise à jour des paquets concernés.
Tout ça pour dire qu'avec Archlinux, le problème n'est pas tout le temps entre l'interface chaise/clavier, le problème n'est pas Archlinux non plus, mais surtout les logiciels. C'est surement pour cette raison que certaines distributions patchent à mort les logiciels intégrés.
Et je confirme donc que chaque mise à jour peut potentiellement faire perdre du temps. Cela n'arrive pas souvent, à vu de nez pour moi c'est un petit problème tous les trois mois et un gros par an.
[^] # Re: Rolling release et Chakra Linux
Posté par BAud (site web personnel) . Évalué à 3.
c'est bien pour un utilisateur de ArchLinux de reconnaître qu'il se comporte comme un packageur ou testeur de distribution en cours de mise en cohérence au niveau des packages, avec un environnement diversifié, s'écartant parfois de la moyenne. C'est tout à l'honneur de Arch de former tant de gens à cela (ceux qui sont sur rawhide, cooker, cauldron, sid en sont plus ou moins conscients mais ne le documentent pas toujours via un wiki).
Ayant été utilisateur de cooker et cauldron quelques années, cela ne me choque pas de m'y reprendre à 2 fois pour réussir une mise à jour (ou que ce soit cassé en attendant que tous les paquets xorg/gnome atteignent les dépôts…), pour autant ce sont des réflexes qui s'acquièrent (et un parcours de la ML de dév' : plus de 100 messages dans la semaine, ne pas mettre à jour : autant backlogguer, moins de 10 messages, ne pas mettre à jour : tout le monde est en attente que ça se corrige…).
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à 0.
Le problème n'est donc pas de "s'y connaitre", mais d'avoir le temps de lire toutes les docs disponibles avant de faire la mise à jour, et là on arrive à plus de 5 mn par jour.
Ca vient surtout du temps que l'utilisateur a à consacrer pour ces taches de maintenance. Et en comptant le temps de lecture des forums, et de la doc n en arrive facilement à 30 mn par jour.
[^] # Re: Rolling release et Chakra Linux
Posté par xcomcmdr . Évalué à 5.
Non, la seule doc éventuelle provient de la page d'accueil d'archlinux.org
Il n'y a absolument pas besoin de lire le wiki. ça n'atteint jamais 30 minutes par jour.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rolling release et Chakra Linux
Posté par Dinosaure (site web personnel) . Évalué à 5.
"Ecoutez moi, Archlinux c'est trop bien. Chez moi, une mise à jour va à la vitesse de la lumière."
Rien que le fait d'aller sur archlinux.org avant de faire une mise à jour, tu peux concevoir que ça ne plaît pas à tout le monde. Et si Archlinux est stable, je me demande ce qu'est Debian stable (une stable over 9000 mthrfckr).
J'ai longtemps été sur Archlinux et il faut bien se rendre compte que c'est une distribution où tu dois serrer les fesses à chaque grosse mise à jour. Mais c'est dans la définition même d'Archlinux car vu l'entropie que les mainteneurs accordent à l'utilisateur final fait que sur une mise à jour simple, pas mal de gens vont se planter (mais c'est le jeux). Au début, c'est cool d'essayer de retrouver le son après un une màj ou de réparer son système après un kernel panic.
Maintenant, tout le monde n'a pas envie de faire ça. Tout le monde n'a pas envie d'ouvrir archlinux.org tout les matins, tout le monde n'a pas envie de passer 1 heure au travail à réparer son système parce qu'il a fait un pacman -Syu trop tôt. Tout le monde n'a pas envie d'avoir systemd (on est pas vendredi ?).
Donc non, Archlinux n'est pas stable est c'est bien sa raison et si tu me dis le contraire, t'as rien compris à la distribution (j'entends déjà au loin le: "C'est toi qui a rien compris, c'est une distribution KISS" - et c'est sur ça qu'on clôturera le débat).
[^] # Re: Rolling release et Chakra Linux
Posté par xcomcmdr . Évalué à 4. Dernière modification le 06 novembre 2014 à 07:29.
Soit. Mais ça reste simple comme bonjour de suivre les instructions, s'il y en a (et la plupart du temps il n'y a rien de spécial à faire)
Archlinux est fiable. Pas stable au sens de Debian stable (vu que c'est un rolling release).
Et non, je suis pas un enculeur de mamans.
Mouais bof. D'une part ça fait longtemps que y'a pas eu de grosse mise à jour. Je veux dire une vraiment grosse du genre le passage de SysV à systemd.
Le dernier truc à la limite du serrage de fesses (et encore, pas vraiment soutenu), c'était une intervention manuel avant de mettre à jour java-common. Sauf que comme marqué sur la page, si on a pas ce paquet installé on est pas concerné. Et j'étais pas concerné.
Jamais arrivé (le son fait partie du kernel, et j'utilise le paquet linux officiel)
Tous les matins, faut être con aussi. Une fois par semaine suffit largement, au vu de l'activité sur archlinux.org…
Jamais arrivé. Vous êtes sûr de pas confondre avec l'AUR là ?
Forcément si on utilise yaourt --sucre, faut pas se plaindre…
Euh… C'est les utilisateurs de systemd les enculeurs de mamans ?
(j'essaie de comprendre)
Par définition, elle n'est pas stable. Mais ce n'est pas parce que c'est Archlinux. C'est pareil pour toutes les rolling release.
Par contre, elle est fiable.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Rolling release et Chakra Linux
Posté par Funigtor (site web personnel) . Évalué à 5.
Je réponds ici puisque tu en parles mais ça peut s'adresser à tout le monde.
Personnellement, je ne regarde jamais archlinux.org avant un pacman -Syu (Ou yaourt -Syua pour avoir en plus les mises à jours de l'AUR.). Par contre, je suis abonné à la mailing-list [arch-announce] qui m'envoie un mail en cas de changement à faire pour l'utilisateur. De fait, si je n'ai rien reçu je sais que je peux lancer la mise à jour les yeux fermés.
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . Évalué à 1.
Et si tu as peur de balancer ton adresse mail dans la nature, les flux RSS c'est le bien.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Rolling release et Chakra Linux
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
Hypothèses basses : tes mises à jour te prennent 3 minutes tous les 2 jours depuis 4 ans, soit 730 fois 3 minutes.
Tu as donc passé 36.5 heures à mettre à jour ta distribution. Plus de 9 heures par an. Je trouve ça énorme et ne suis pas certain que ce soit vraiment rentable par rapport à une distribution à releases (en terme de temps passé à mettre à jour uniquement).
La connaissance libre : https://zestedesavoir.com
[^] # Arch or not Arch
Posté par Arthur Accroc . Évalué à 5.
Avec Arch, on passe certainement plus de temps avec les mises à jour, mais c’est réparti.
Avec une RedHat/CentOS, pas de mise à jour, il faut réinstaller. La sortie d’une nouvelle version n’est pas très fréquente, mais pour tout reparamétrer et de réinstaller les logiciels qu’on utilise, il faut y consacrer beaucoup de temps d’un coup.
Avec une Ubuntu, la mise à jour vers la version suivante de la distribution peut foirer, en particulier caler en cours de mise à jour avec ton système dans un état incohérent. Même si une sauvegarde peut permettre de retrouver l’ancien système en état, il faut réinstaller pour avoir le nouveau.
Avec Fedora, la mise à jour de la distribution qui cale au milieu était la grande spécialité (c’était beaucoup plus fréquent qu’avec Ubuntu), mais le nouvel outil de mise à jour a enfin réglé le problème. Par contre, il faut disposer d’une place phénoménale dans /var pour pouvoir mettre à jour. Cela dit, comme le gestionnaire de paquets ne différencie pas les paquets installés pour dépendance, donc ne propose pas de les supprimer quand ils ne sont plus utiles, le système a tendance à enfler. Donc mieux vaut réinstaller quand même au bout d’un certain nombre de mises à jour de version de la distribution.
Les manipulations demandées par Arch (et documentées sur le wiki) sont avec Fedora et Ubuntu repoussées à la version suivante de la distribution, puis faites automatiquement par l’outil de mise à jour, mais du coup elles sont toutes faites en même temps, il y en a éventuellement qui ratent et la résolution de ces problèmes peut prendre du temps.
Autant pour le boulot, je n’ai pas mis d’Arch parce que je préfère que les mises à jour délicates soient regroupées à un moment bien déterminé où je prépare le nouveau système, autant pour ma machine perso, je suis passé à Arch pour ne pas avoir à bloquer périodiquement une demi-journée ou plus pour la mise à jour de version de la distribution.
Par ailleurs, Arch me permet de me préparer aux changements amonts qui tomberont plus tard sur les distributions que j’installe au boulot.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Arch or not Arch
Posté par freem . Évalué à 3.
Je pense que c'est une erreur de ne pas citer Debian dans ton listing (très intéressant ceci dit). Debian à la réputation d'être stable, et franchement, ce n'est pas usurpé. Je n'ai que peu de système sur une stable pure (seulement mes machines "sérieuses", donc les serveurs. Même le PC du boulot est mâtiné de testing/unstable, histoire d'avoir un peu de fun de temps en temps) mais je n'ai strictement jamais eu d'emmerdes sur ce type de système.
Même avec du testing/unstable, je n'ai jamais eu beaucoup de problèmes, excepté, il faut l'avouer, depuis quelques mois (ce qui m'a poussé à downgrader au maximum vers stable, ce qui se fait de manière tout de même stable), peu m'importe la cause, les effets sont là (entres autres, un délai de 30s d'udev au boot, une indispo de la TTY sur laquelle on à lancé startx. Non, je n'ai pas de source ni de bug, juste une expérience perso que je suis peut-être le seul à avoir).
Bon, après, ce n'est que mon expérience qui n'est même pas de 5 ans… surtout sur des stables pures. Et ce, sans DE, ce qui doit jouer énormément. Ah, je fais également attention à garder un système relativement clean (je ne suis pas parti de windows pour avoir un système plus crade, faut pas déconner), et je profite des MaJ pour nettoyer: un paquet que j'ai installé pour un test qui nécessite un MaJ saute directement (aptitude est quand même pratique pour ça, malgré ses problèmes de performance).
Tout ça pour dire qu'au final, je pense qu'en terme de facilité de MaJ sans prise de tête, Debian est quand même très sympa, et montre bien la force des distros "periodic-release". Après, à voir pour des machines de bureau "classiques" avec gnome ou KDE…
Par contre, on parle de Debian: les logiciels de la stable sont, en moyenne, vieux d'un an et demi (3-4 mois au début de la stable, âge de la période de freeze, et jusqu'à 2 ans et demi en fin de vie d'une stable, en sachant que les versions qui étaient dans testing au freeze ne sont pas forcément les toutes dernières versions elle-mêmes…).
C'est l'inconvénient de ce type de distro: on ne peut pas avoir du "ultra-stable" "ultra-récent"… tout comme on ne peut pas avoir le beurre, l'argent du beurre et le sourire de la crémière (quoique…)
[^] # Re: Arch or not Arch
Posté par totof2000 . Évalué à 1.
Ca ne m'est jamais arrivé. Ah si une fois ou la mise a jour a calé, mais le système de package est assez bien fichu pour réparer lorsqu'on lui envoie la bonne commande. En général le problème que j'ai avec les mises à jour, ce sont des régressions (style la fermeture du couvercle du portable qui ne met plus la machine en hibernation, ou un nouveau soft qui ne marche pas, ou une conf qui a sauté, mais ça ce n'est pas le problème de la mise à jour en ellemême et ça peut arriver ave cn'importe quelle distribution)
Question de choix et de disponibilité. Personnellement je préfère me bloquer 2 jours en une fois.
[^] # Re: Rolling release et Chakra Linux
Posté par Spyhawk . Évalué à 1.
La seconde phrase est un tantinet exagérée :), mais je suis d'accord avec la première: Arch n'a pas les moyens de faire le travail de stabilisation que les "grandes" distrib font, et ça se saurait si celui-ci était totalement inutile.
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à -5.
Elle est en rien exagérée, c'est du vécu.
[^] # Re: Rolling release et Chakra Linux
Posté par Spyhawk . Évalué à 6.
Bah on a pas du ẽtre dans la même réalité ces 8 dernières années, ou alors c'est l'interface chaise clavier qui bugge en faisant des updates les yeux fermés de ton côté.
[^] # Re: Rolling release et Chakra Linux
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Mon vécu depuis de nombreuses années avec arch, c'est 1 intervention manuelle de temps en temps après avoir lu la page principale de archlinux.org, sinon, ça roule vraiment tout seul.
Tu peux nous en dire un peu plus sur tous les soucis que tu rencontres ?
[^] # Re: Rolling release et Chakra Linux
Posté par totof2000 . Évalué à 0.
J'en ai déjà parlé ici même.
[^] # Re: Rolling release et Chakra Linux
Posté par woprandi . Évalué à 0.
On a pas dû utilisé la même Arch, c'est très stable Arch
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . Évalué à -1.
Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
--forceen routine, il y a un problème.--forcedans n'importe quel contexte, il y a probablement un problème.--sucrede yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres)--force.Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Rolling release et Chakra Linux
Posté par Spyhawk . Évalué à 2.
Il existe des wrappers pour ceci, comme pacmatic. C'est pas intégré dans pacman directement pour cause de portabilité. Tout les patches "distribution spécifique" sont refusés.
[^] # Re: Rolling release et Chakra Linux
Posté par Astaoth . Évalué à 1.
Je ne vois pas en quoi ce genre d'alertes intégrées dans le gestionnaire de paquet n'est pas portable.
Emacs le fait depuis 30 ans.
# Le beurre et l'argent du beurre
Posté par Marotte ⛧ . Évalué à 4.
Est-ce que tu ne voudrais pas aussi le cul de la crémière et le sourire du crémier ? ;)
Nouvelles fonctionnalités clairement. Corrige des bugs c'est très relatif. Les applications d'une stable n'ont généralement pas de bug grave à la sortie de la distribution, si par la suite on découvre des bugs ils sont soit mineurs et contournables, soit critiques, et dans ce cas corrigés dans la version stable actuelle.
Et sinon quel est le problème avec les PPA ou encore les backports Debian ?
[^] # Re: Le beurre et l'argent du beurre
Posté par bibifric05 . Évalué à 3.
Pas de bug grave, peut-être… De petits bugs gênants, ça oui. Et il faut penser que tout le monde n'a pas le niveau pour les contourner ou appliquer une recette un peu complexe.
Quant aux ppa, je les utilise bien sûr mais le moins possible : souvent ils ne sont pas à jour, ou plus maintenus. Quand on met à jour Ubuntu, il faut revoir si les ppa peuvent être conservés ou pas, c'est long…
[^] # Re: Le beurre et l'argent du beurre
Posté par Anonyme . Évalué à 1.
tu as un exemple de bug gênant ?
[^] # Re: Le beurre et l'argent du beurre
Posté par claudex . Évalué à 5.
Il y en a plein sur https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;severity=grave ou https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;severity=critical . Par exemple (au hasard) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698537 ou https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735935
« 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: Le beurre et l'argent du beurre
Posté par Anonyme . Évalué à 1.
Ouais, ouais ok, la plupart ne sont pas genant. Il y a des solutions donne, Tiens je me souviens d un bug genant, une version ISO de debian avait oubliez grub et lilo sur le cd1, vraiment casse bonbon !
[^] # Re: Le beurre et l'argent du beurre
Posté par claudex . Évalué à 10.
Le seul problème avec les backports Debian, c'est que les mainteneurs Debian n'ont pas encore le statut d'esclave, du coup ça traîne un peu.
« 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
# distrib stable + /opt
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Plutôt que de vouloir réinventer une distrib, pourquoi ne pas étendre une existante?
Aujourd'hui je travaille avec une Ubuntu LTS et beaucoup de logiciels installés à la main dans ~/opt…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: distrib stable + /opt
Posté par bibifric05 . Évalué à 3.
Oui, moi aussi je fais ça. Je me débrouille comme je peux, mais là encore il faut penser (me semble t-il) aux utilisateurs qui ne savent pas bidouiller et s'accomoder des limites du modèle existant.
[^] # Re: distrib stable + /opt
Posté par Syvolc (site web personnel) . Évalué à 2.
C'est aussi un peu ce que j'ai. Une openSUSE qui va se mettre à jour tous les ans, donc plutôt stable, mais quelques dépôts logiciels pour avoir quelques outils pour utilisateur final bien à jour, ça fait toujours plaisir.
# Debian stable + backports
Posté par vv222 (site web personnel) . Évalué à 8.
C’est la solution que je privilégie pour lier une base système stable avec des applications récentes.
Son principal inconvénient reste le nombre restreint de paquets proposés dans la branche stable-backports, qui fait que je dois parfois revenir à la compilation et à ses déboires (dépendances en cascade…).
[^] # Re: Debian stable + pinning
Posté par Kioob (site web personnel) . Évalué à 1.
Je suis surpris de ne pas voir ça évoqué, mais parfois du pinning APT suffit pour mixer stable/testing/unstable/experimental sur une machine.
Typiquement c'est ce que j'utilise au boulot pour avoir Iceweasel en version 33.
alf.life
[^] # Re: Debian stable + pinning
Posté par Anonyme . Évalué à 3.
certe mais c'est pas super user friendly pour ne pas tout casser :).
[^] # Re: Debian stable + pinning
Posté par Almin (site web personnel) . Évalué à 0.
C’est un peu casse-pied, mais pas si compliqué que ça non plus. Il ne faut pas mixer l’option Default-Release et un épinglage personnalisé, il faut épingler à 990 la release par défaut à la place. Puis on spécifie les règles pour les paquets que l’on veut. Ça permet de jongler avec plusieurs dépôts sans faire n’importe quoi et tout casser pendant une màj.
Je me suis remis récemment à l’épinglage apt, parce que openvz n’est plus supporté dans wheezy, et surtout à cause de la faille de bash.
http://almin.tf/blog/2014/09/26/epinglage-apt-pinning/
Sinon quand j’installe une machine de bureau, je mets Debian stable et les backports, ça suffit pour une grande partie des utilisateurs. Pour ceux qui ont besoin d’installer des logiciels qui ne sont pas dans les backports, il faut faire un chroot sid.
[^] # Re: Debian stable + pinning
Posté par vv222 (site web personnel) . Évalué à 2.
Pour la situation particulière d’Iceweasel, je te recommande de passer par les dépôts proposés sur ce site plutôt que par la méthode du pinning :
http://mozilla.debian.net/
[^] # Re: Debian stable + pinning
Posté par Kioob (site web personnel) . Évalué à -1.
En fait c'est ce qu'on faisait au début, mais on rencontré un problème (je ne sais plus lequel), et on a constaté que le pinning marchait wachement mieux.
alf.life
[^] # Re: Debian stable + pinning
Posté par claudex . Évalué à 6.
Alors que les packageur Debian d'Iceweasel font un dépôt pour ça http://mozilla.debian.net/
« 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
# Debian testing/unstable.
Posté par freem . Évalué à 5. Dernière modification le 03 novembre 2014 à 12:38.
Vu que personne ne l'a encore faite, ben je m'en occupe.
En gros, Debian ne se limite pas à Debian stable, qui est plutôt à conseiller pour les serveurs. Officieusement, pour un desktop, je conseillerais plutôt une testing, bien que certains sur les ML conseilleraient plutôt unstable pour des raisons de sécurité (les versions et bugfix arrivent moins vite dans testing).
Et si tu tiens à conserver une base de Debian stable, ben, comme dis plus haut, debian stable + backports.
Autre solution: machines virtuelles. Tu démarres les machines virtuelles qui elles utilisent les dernières versions, puis tu utilises par exemple
ssh -X me@myvm foopour lancer l'application foo de la vm myvm (via l'utilisateur me) en déportant l'affichage sur ta machine stable.Évidemment, les performances vont prendre un coup avec cette solution, et il faut savoir utiliser un minimum une solution de virtualisation, avec Xen la plus complexe à priori, mais qui permets aussi d'avoir le moins d'impact en terme de performances (jamais testé, ceci dit, c'est ceci dit un de mes items les plus hauts sur la todolist…).
[^] # Re: Debian testing/unstable.
Posté par saltimbanque (site web personnel) . Évalué à 2.
j'ai utilisé debian sid, "still in development", qui est une rolling release, en bon gros noob pendant des années. Malgré les millions d'avertissements, cette distribution s'est avérée en réalité particulièrement stable - peut être cela dit du fait d'un matériel un peu ancien?
Quoi qu'il en soit cela reste une référence à mes yeux ; je l'ai certes quitté pour avoir du plus récent, mais au prix de moins de stabilité et de la perte de rolling release. Et les logiciels "anciens" ne l'étaient que relativement ; ce n'était pas d'un différentiel de deux ans dont l'on parlait, mais plutôt de six mois…
[^] # Re: Debian testing/unstable.
Posté par Maxime (site web personnel) . Évalué à 2.
Je tourne sur toutes mes machines en Debian Jessie (pour le desktop), certains pensent que je suis fou car une mise à jour pourrait tout casser…
Alors oui ça arrive (très rare) et donc je ne peux pas le conseiller à un débutant qui fait tout seul ses mises à jour (car parfois il faut downgrader le package et c'est pas toujours évident). Je préfère également ne pas automatiser les mises à jour au cas où. Et je ne lance pas une mise à jour si je n'ai pas le temps de corriger une éventuelle erreur.
J'ai l'impression d'utiliser une distro en Rolling Release. Et je me demande donc : est-ce qu'une arch est vraiment plus stable qu'une debian testing ?
[^] # Re: Debian testing/unstable.
Posté par bibifric05 . Évalué à 2.
J'ai utilisé longtemps une Debian testing mais au final, j'ai fini par revenir en stable. Il y a souvent des problèmes de paquets / dépendances cassés ou pas disponibles et j'ai trouvé ça pénible…
[^] # Re: Debian testing/unstable.
Posté par KiKouN . Évalué à 9.
Perso, j'utilise les snapshots de LVM ( ou autre au choix ) pour contourner le problème :
[^] # Re: Debian testing/unstable.
Posté par Spyhawk . Évalué à 3.
Mais Debian testing est une rolling release, sauf en période de freeze :)
La réponse officielle à ta question serait quelques chose comme "Arch est aussi stable que tu la rends stable."
Arch n'est pas casse tronche si l'utilisateur adopte un comportement responsable - exactement comme celui que tu décris - puisque toute la responsabilité des mises à jour et autres intégrations complexes lui revient.
[^] # Re: Debian testing/unstable.
Posté par woprandi . Évalué à 2.
Testing n'est pas conseillé par Debian eux-mêmes car en cas de soucis, le correctif mets du temps à arriver. A mon avis Arch est bien mieux niveau rolling-release car c'est une distribution faite pour ça
# Oublie Linux pour ça ....
Posté par totof2000 . Évalué à 10. Dernière modification le 03 novembre 2014 à 12:57.
… les distributions ne sont pas pensées ainsi. Une distribution est pensée et testée comme un tout (pas de séparation système/userland).
Utilise un système comme FreeBSD par exemple. Il y a une nette séparation entre le système et les applications qui sont disponible via les ports.
Sinon, tu t'installes une distrib LTS (avec support 2ans) et tu installes tes softs via pkgsrc (issu de NetBSD mais dispo sur un tas de plateformes). pkgsrc est régulièrement mis à jour (4 fois par an environs). Tu ne disposes pas forcément de la toute dernière version des softs, et tous les softs Linux ne sont pas forcément dispo, mais si tu y trouves ton bonheur, ça peut faire un bon compromis.
[^] # Re: Oublie Linux pour ça ....
Posté par freem . Évalué à 0.
Hum… vu que tu mentionnes une BSD ou il me semble qu'il faille compiler la plupart des paquets, je dirais, peut-être qu'il peut aller chercher du gentoo, ou d'autres distributions source style lunar linux, sorcerer ou source mage?
Je sais que du côté de gentoo, ce n'est pas spécialement trivial, mais peut-être que les autres sont plus simples (jamais testées)?
[^] # Re: Oublie Linux pour ça ....
Posté par barmic . Évalué à 7.
Ça n'a rien avoir. D'une part sur FreeBSD tu n'es plus obligé de compiler tes ports, d'autre part le fait de penser la distribution comme 2 ensembles distincts n'est pas lié au coté source ou non.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oublie Linux pour ça ....
Posté par totof2000 . Évalué à 4.
Depuis longtemps sous freeBSD : pkg_add et depuis peu pkg.
Mais il arrive parfois de devoir recompiler un petit truc mais c'est assez rare.
[^] # Re: Oublie Linux pour ça ....
Posté par Astaoth . Évalué à 2.
Devoir compiler un paquet ou non n'est pas ce qui différencie les BSD des GNU/Linux. Et ce n'est pas parce qu'on compile des paquets avec certaines distribution que la séparation système et logiciels est possible.
Emacs le fait depuis 30 ans.
[^] # Re: Oublie Linux pour ça ....
Posté par claudex . Évalué à 3.
Comment sont gérées les versions des ports ? Prenons un cas concret, j'ai Apache httpd en version 2.2.21, je veux mettre à jour, puis-je passer à la version 2.2.22 ou suis-je obligé de passer à la version 2.4.10 ?
« 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: Oublie Linux pour ça ....
Posté par totof2000 . Évalué à 3. Dernière modification le 03 novembre 2014 à 21:09.
Soit la version a été intégrée dans les ports et tu l'installes, soit tu fais toi-même lla compilation, et vu que tu es gentil tu le mets à disposition ;)
Plus sérieusement : je ne sais pas à quel rythme sortent les versions de ports sous FreeBSD (je ne me suis mis sérieusement il y a peu de temps). Pour apache par exemple : http://www.freshports.org/www/apache24/ Mais d'après ce que j'en ai lu, ça ressemble à du rolling release.
[^] # Re: Oublie Linux pour ça ....
Posté par claudex . Évalué à 2.
Bon, ben je reste partisan des backports à la Debian, vous n'aurez pas mes ports compilés :)
« 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: Oublie Linux pour ça ....
Posté par Enj0lras . Évalué à 3. Dernière modification le 04 novembre 2014 à 02:48.
Dans la pratique, ça dépend des ports, si c'est un port plutôt orienté bureau/utilisateur final, ou un port plus utile pour un serveur ou du développement. Pour ce qui est "utilisateur final", et donc plutôt ce qui est mentionné dans cette dépêche, c'est une rolling release, avec seulement la dernière version fournie, un peu à la arch.
Pour les logiciels qui nécessitent plus de maintenance, comme apache, bind, php, ou postgresql, il y a en général la dernière version mineure des 2 ou 3 dernières versions majeures, dont l'une est le "défaut".
Par exemple, il y a en ce moment :
Mais c'est encore plus compliqué que ça, car certains paquets, mettons, php pgsql, dépendent des libs de postgresql, et il y a parfois des changements d'ABI etre versions majeures. Donc, il y a une version qui est le défaut. Donc même si des paquets binaires sont fournis pour chacune de ces versions, si tu veux installer un paquet binaire qui dépend de la bibliothèque pgsql, le paquet sera compilée contre la version par défaut. Si tu veux l'utiliser avec une autre version, il faudra que tu recompiles le port en question.
Cela dit, maintenir des dépots avec des versions par défaut différentes s'avère très très très simple sous FreeBSD grace à poudriere, tu peux continuer à utiliser les paquets binaires officiels et compiler juste automatiquement tout les ports qui vont être modifiés par ton changement, puis ajouté le dépot créer dans ta conf de pkg pour qu'il installe les dépendances depuis ce dépot en priorité.
[^] # Re: Oublie Linux pour ça ....
Posté par Enj0lras . Évalué à 2.
Tiens d'ailleurs je me rends compte qu'il y a aussi postgresql84. Mais bon, postgresql c'est un cas particulier où les utilisateurs ont pas forcément envie de maj leur infra quand ça marche vu que c'est assez lourd à faire.
[^] # Re: Oublie Linux pour ça ....
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
En général pour les softs majeurs tu as plusieurs versions. Par exemple là tu as le choix entre 2.2.29 et 2.4.10 pour apache.
# Merci
Posté par bibifric05 . Évalué à 3.
Merci à tous pour vos commentaires. Il me reste à méditer tout ça…
# Dibab ?
Posté par papap (site web personnel) . Évalué à 2.
Sinon, je t'aurais proposé l'outil Dibab,qui permet de se faire une distribution aux petits oignons (enfin presque, il faut savoir mettre les doigts dans le cambouis)
[^] # Re: Dibab ?
Posté par Yann LD . Évalué à 1.
Effectivement, on fonctionne comme ça :
[^] # Re: Dibab ?
Posté par groumly . Évalué à 3.
Une question que je me pose depuis un bail, a chaque que j'entends cette expression en fait: c'est quoi au juste une "distrib au petits oignons"?
Nan parce qu'autant quand on parle de cuisine, j'ai une bonne idee, mais quand on parle d'installation/configuration de logiciels automatisables (et automatises), j'ai du mal a comprendre l'analogie.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Dibab ?
Posté par freeze . Évalué à 9.
Ben c'est pareil:
1. Tu commences, t'es enthousiaste
2. Et le temps de couper les oignons … tu pleures
[^] # Re: Dibab ?
Posté par papap (site web personnel) . Évalué à 3.
Oui, c'est un peu ça , il faut avouer.
# Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 2.
On pourrais même séparer en 3 parties:
Bref, c'est un jeu de repo à mettre en place, techniquement, ça doit pas être très compliqué, reste à voir le suivi. Il faut déjà une bonne petite équipe pour gérer ça:
- Une équipe Core Stable pour les mises-à-jour de sécurité;
- Une équipe Core Unstable pour le développement de la prochaine version du Core;
Une équipe par Desktop;
Un tas de mainteneurs pour les applications.
On se lance?
[^] # Re: Séparation en 3
Posté par freeze . Évalué à 4.
ça ressemble beaucoup à une proposition de Lennart qui parlait plus de Système/Framework/App, mais ça serait assez intéressant à creuser (mais pas par moi ;))
[^] # Re: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 3.
C'est ce qui me trotte dans la tête depuis un moment.. J'utilise Linux (Debian/Ubuntu) depuis plus de 10ans maintenant en tant qu'OS principal (enfin OS tout court, puisque j'en utilise pas d'autre), et je suis toujours confronter aux mêmes problèmes.
Si je veux les dernières versions des apps, je suis obligé de bricoler.
Si je veux la dernière version (ou juste une version plus récente) d'un DM, je suis obligé de mettre toute la distrib' à jour, et là, je perd un jour ou deux car y a toujours un truc qui "casse". Du coup, j'ose plus mettre à jour ou changer de versions car, et bas mon pc, il faut que je bosse avec et que j'ai pas que ça à faire..
Pourtant, mon besoin me semble pas extraordinaire:
Je veux que la gestion de mon matos soit stable;
Je veux un bureau non buggué et moderne (par exemple, Gnome 3.10 dans Ubuntu 14.04 a rien à voir niveau finition par rapport à la 3.12 ou la 3.14. Pas de version stable de Gnome dispo, juste une version "snapshot", la dernière qui était sortie au moment de la sortie de la LTS. Pas la meilleure, pas la plus stable, non juste la dernière..
Je veux pouvoir utiliser la dernière version des applications, car je pense qu'une application peut pas casser mon système.
Bref, je suis plus tellement heureux sous Linux au bout de toutes ses années car il y a 10 ans, ces défauts pouvait passé pour des défauts de jeunesse. Aujourd'hui, pas grand chose n'a changé.
[^] # Re: Séparation en 3
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il faut une base stable, puis proposer les derniers soft en mode "compilé statique" ?
Ou alors, inventer un gestionnaire de paquet à embarquer dans n'importe quelle distribution qui redistribue des paquets autoporteur qui ne casse pas tout.
La partie core/système est géré par la distribution, et le up-to-date, par le nouveau système externalisé.
(d'ailleurs, j'ai jamais compris pourquoi on ne laissait pas firefox se mettre à jour tout seul)
"La première sécurité est la liberté"
[^] # Re: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 2. Dernière modification le 03 novembre 2014 à 17:20.
Vue qu'on a une base stable, pas de "gros" soucis pour recompiler les applications avec les librairies de cette base.
Voir, sortir de la base toutes les librairies qui ne sont pas système, et les inclure dans la partie up-to-date.
La base serait se concentrerait vraiment sur les aspects Hardware / Système. Pas besoin de libsexy2 ou libqtcore4 par exemple dans la base, ils auraient leur place plutôt dans la partie DE, qui imposerait lui les dépendances des applications.
Le gros défaut je pense actuellement dans les distributions les plus répandues, c'est de tout mettre au même niveau. Clementine (et ses dépendances) n'est pas dans la même problématique vis-à-vis des mises à jour que systemd, ou même apache. On mélange les choux et les carottes, et au final, on a une soupe qu'on a du mal à améliorer efficacement.
[^] # Re: Séparation en 3
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 03 novembre 2014 à 17:46.
Le problème est que si la dernière version de clémentine utilise la dernière version de boost, tu n'as pas envie de mettre en risque le reste de la distribution. Ou alors, il faut attendre la mise à jour de tout.
Mon idée est d'avoir une distrib classique, et de pouvoir mettre du chaud démoulé du four, totalement séparé du reste. Le problème n'est pas d'avoir core/desktop, le problème est d'avoir un truc neuf qui nécessite plein de mise à jour avec un risque de péter l'ancien.
D'ailleurs, je me demandais quelle serait la difficulté de faire un outils elf to elf qui réécrirait un elf en collant tous les bouts de library partagé qu'il a besoin, voir en utilisant uniquement les symboles nécessaires. En gros, écrire un loader spécial qui fait un gros dump dans un fichier.
"La première sécurité est la liberté"
[^] # Re: Séparation en 3
Posté par Moonz . Évalué à 3. Dernière modification le 03 novembre 2014 à 18:23.
Tu veux dire, un peu comme ça ?
Sinon tu peux aussi distribuer les libs nécessaires et jouer avec
LD_LIBRARY_PATH[^] # Re: Séparation en 3
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui mais en optimisant un peu, en gardant uniquement les symboles nécessaires.
"La première sécurité est la liberté"
[^] # Re: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 1.
On retombe dans le modèle windows si on distribue les libs avec l'application.
Après, rien nous empêche d'avoir plusieurs versions de la même lib sur le système.
Boost 1.1 pour clementine.
Boost 0.9 pour amarok.
etc..
[^] # Re: Séparation en 3
Posté par claudex . Évalué à 5.
Il faut donc des mainteneurs pour surveiller toutes les versions possibles dans la distribution, ça en fait du monde.
« 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: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 1.
Dans debian, à un moment ou un autre, chaque paquet a un mainteneur qui met à jour le paquet dans unstable par exemple? Donc ça change pas grand chose, faut toujours des mainteneurs de paquets. La différence serait comment on passe à la version suivante: pas tout d'un coup, mais par bloc (Core/DM/Environnement applicatif).
[^] # Re: Séparation en 3
Posté par claudex . Évalué à 3.
Je ne vois pas où tu veux en venir, dans Debian, les paquets de stables, oldstable(-lts) sont surveillé et patché en cas de faille de sécurité, ça fait une version pour l'équipe sécurité (stable (et un an d'oldstable)), et une version pour l'équipe LTS. Ce que tu propose, c'est plein de versions en même à surveiller et patcher, il faut donc du monde pour faire ce boulot. Je ne vois pas ce qu'unstable vient faire là-dedans alors qu'elle n'est pas vraiment surveillée par l'équipe de sécurité (un peu quand même, ils ne vont pas fermer les yeux pour le plaisir).
« 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: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 1.
Effectivement, ça montre une limite au niveau du support de plusieurs versions d'une librairie.
Après, concrètement, pour la plupart des applications Desktop (car on parle du monde desktop), ce qui gênerai surtout cela serait d'avoir des applications qui utilisent des versions des libs, et donc nous obligerai à les supporter. Mais sachant qu'on parle de l'applicatif, donc de l'espace utilisateur, ça limite déjà pas mal les dégâts. On se retrouve dans la même situation que l'utilisation de /opt (compilation à la main) ou autre système du genre.
[^] # Re: Séparation en 3
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela ne passe pas à l'échelle, tu prends l'ancien système et tu rajoutes plein de boulot.
"La première sécurité est la liberté"
[^] # Re: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 1.
D'ailleurs, si on regarde un peu comment fonctionne windows, y a un exemple à prendre je pense:
Si on sépare correctement tout, CORE/DM d'un coté, et applications et les libs de l'autre, on aura toujours une base qui tourne correct sur la machine (bref, on peut l'utiliser, c'est le but!). La partie applications elle peut évoluer, dans tous les cas mon système tourne, démarre, redémarre et ne plante pas après une mise à jour parce que j'avais besoin de d'utiliser la dernière version de telle appli.
ça me semble pas techniquement insurmontable comme problème de mettre d'un coté le Core/DM et ses dépendances, et les applications et leur dépendances de l'autre. D'ailleurs, ça se fait déjà à la main (/opt et compagnie), alors pourquoi on pourrait pas automatiser ça?
On est en 2014 merde ;) !
[^] # Re: Séparation en 3
Posté par claudex . Évalué à 3.
On ne doit pas fréquenter les mêmes Windows. Les seuls qui commencent à être à jour, ce sont les navigateurs, il a même fallu que ces derniers désactive manuellement les vielles version de Java (qui est loin d'être le plus discret pour se mettre à jour).
« 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: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 1.
Je rectifie: je peux mettre mon application à jour sans mettre à jour les 3/4 ou 100% de mon système.
[^] # Re: Séparation en 3
Posté par claudex . Évalué à 3.
Uniquement ceux qui ne viennent pas des dépôts de Windows (comme IE, IIS, AD…), comme sous Linux avec pkgsrc, ZeroInstal, ou un targz. Les solutions existent pour ne pas passer par les dépôts, elles n'ont pas l'air d'intéresser les distributeurs ou les utilisateurs.
« 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: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 2.
Les solutions existent, aucune ne fait partie d'une distribution (y a les ppa aussi à rajouter du coté Debian/Ubuntu). Bref, ça reste du "bricolage" d'une distribution qu'on modifie à sa sauce.
[^] # Re: Séparation en 3
Posté par claudex . Évalué à 4.
Les solutions de Windows n'y sont pas intégrées non plus (les MSI ne sont pas très fréquent hors du monde pro).
« 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: Séparation en 3
Posté par bibifric05 . Évalué à 1. Dernière modification le 03 novembre 2014 à 20:17.
Oui, c'est exactement mon sentiment. Bon, on est au moins deux… Euh, trois en fait…
Mais oui, vous avez bien compris : c'est exactement ce que je voudrais. Si jamais vous vous y mettez, faites moi signe !
[^] # Re: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à 2.
Bas écoutes, ça m'intéresse oui, on peut en discuter, ça serait déjà un bon début :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Séparation en 3
Posté par Jérôme (site web personnel) . Évalué à -3.
Merci Maîtresse.
[^] # Re: Séparation en 3
Posté par PachaFonk . Évalué à 1.
Ta règle ne marche que pour les verbes du 1er groupe et le verbe aller !
Il y a également l'exception kivabien:
Manges-en, vas-y…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Séparation en 3
Posté par vv222 (site web personnel) . Évalué à 2.
Wikipédia propose une astuce intéressante pour s’en souvenir :
"Contrairement au présent de l'indicatif, il n'y a pas de désinence -s à la deuxième personne du singulier. Le meilleur moyen d'éviter cette faute grammaticale courante consiste à considérer que cette forme correspond à la première forme de l'impératif, à assimiler grammaticalement à une première personne."
source : https://fr.wikipedia.org/wiki/Imp%C3%A9ratif_%28grammaire%29#Verbes_du_premier_groupe
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 06 novembre 2014 à 11:02.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Séparation en 3
Posté par jyes . Évalué à 3.
C’est un peu facile comme réponse, sachant que le troisième groupe ne contient en fait que des exceptions (leur seul point commun est de ne pas rentrer dans les deux autres groupes). On peut résumer les règles de conjugaison française à ça « marche pour tous les groupes, et oui, a des exceptions ». En vrai, les exceptions sont légion (à défaut d’être anonymes) et cette formulation occulte complètement la complexité réelle de la conjugaison.
Prends ça dans les dents ! :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 06 novembre 2014 à 11:27.
Ce commentaire a été supprimé par l’équipe de modération.
# Ubuntu
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
En fait, Ubuntu n'es pas si loin de ça : les outils de base changent tous les 6 ou 18 mois selon si tu utilises une LTS ou pas, mais certains soft sont mis à jour quand même (par exemple Firefox qui arrive dans les mises à jour stables d'Ubuntu dans les jours qui suivent la sortie de chaque version de Firefox).
[^] # Re: Ubuntu
Posté par bibifric05 . Évalué à 1.
En effet, Ubuntu n'est pas si loin du concept et j'aime bien notamment les mises à jour régulières de Firefox.
Par contre, si on reste en LTS, les utilisateurs râlent parce qu'ils n'ont pas les dernières applis…
[^] # Re: Ubuntu
Posté par zurvan . Évalué à 1.
en LTS il y a quand même pas mal d'applis qui nécessitent d'avoir des mises à jour récentes (par exemple firefox, libreoffice etc) qui continuent d'être justement à jour même au bout de plusieurs années.
Après, il y a aussi PCBSD : http://www.pcbsd.org/
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Ubuntu
Posté par woprandi . Évalué à 1.
Quand j'était en 12.04 (avant la sortie de la 14.04), libreoffice était toujours en version 3.5…
# FreeBSD
Posté par MTux . Évalué à 9.
Ce que tu recherches, c'est un fonctionnement similaire à Windows non ?
Une base stable et figée mais des logiciels disponibles dans leur dernière version et maintenus à jour.
Hum, je dirais que ce qui s'en approche le plus dans le libre c'est FreeBSD.
En effet la base est stable mais les ports sont mis à jour et montent en version.
Maintenant a voir si la compatibilité matérielle de FreeBSD (ou PC-BSD) est suffisante pour ta machine…
Ou sinon rien ne t'empêche d'installer Debian stable et d'utiliser ensuite pkgsrc pour avoir des logiciels récents (je n'ai jamais tenté mais cela doit être intéressant).
# Modules
Posté par SChauveau . Évalué à 10.
Beaucoups de systemes professionels (les supercalculateurs) utilisent Modules
http://modules.sourceforge.net/
L'idée de Modules est que la distribution fournit l'OS et les utilitaires de base mais que les applications sont gérées séparément par Modules. Les applications sont ajoutées à l'environnement par la commande shell 'module' (en fait un alias qui manipule l'environnement PATH, LD_LIBRARY_PATH, …).
Par exemple, pour avoir gcc faire
# module add gcc
# gcc foo.c -o foo
L'intérêt et que plusieurs versions de la même application peuvent être installés sur le même systèmes.
# module add gcc/4.7.1
# … gcc est maintenant gcc/4.7.1
# module switch gcc/4.8.2
# … gcc est maintenant gcc/4.8.2
Ce système est très pratique pour un environnement avec plusieurs dizaines ou centaines d'utilisateurs utilisant des applications différentes.
L'exemple de gcc n'est pas très bon car c'est une des rare applications pouvant exister en plusieurs versions dans quasiment toutes les distributions.
Le problème est que les modules doivent être installé manuellement en recompilant les applications. Les labos et les entreprises utilisant module disposent d'administrateurs systèmes capable de faire cela mais c'est plus dur pour un utilisateur lamba.
Je ne connais pas de distribution basée sur module mais cela serait assez cool. L'idéal serait que l'OS soit standard (Ubuntu/Debian, Centos, … ) et que les Modules soient recompilés lors de leur installation (comme dans Gentoo).
[^] # Re: Modules
Posté par jyes . Évalué à 2.
Modules est loin d’être la panacée, ça déporte la gestion des dépendances vers l’utilisateur final, ce qui fonctionne effectivement sur des machines très centralisées avec des administrateurs qui y passent beaucoup de temps, et des utilisateurs de bonne volonté (pas toujours très bonne, mais un utilisateur qui a accès à une machine HPC sait qu’il va devoir se familiariser avec ses particularités).
Je prends l’exemple du petit cluster le plus proche de moi, il contient plusieurs versions d’OpenMPI, plusieurs versions d’HDF5, compilées pour plusieurs versions de GCC… et au final quand je charge mes modules pour compiler mon programme, je dois embarquer ma propre bibliothèque pour HDF5 car par le jeu des dépendances croisées, il n’y a pas la combinaison qui me convient.
Sur mon poste de travail, je suis bien content de ne pas avoir à m’en préoccuper à chaque mise à jour d’Octave, de Paraview, de Gimp ou de SuperTuxKart. Je ne pense vraiment pas que les modules puissent apporter quoi que ce soit pour résoudre un problème d’utilisateur final. Sauf à faire des modules complètement autonomes, ce qui ne diffère pas de binaires statiques simples ou fournis avec leurs wrappers pour positionner correctement les variables d’environnement (et c’est déjà ce que se fait pour la plupart des programmes distribués hors gestionnaire de paquets que j’ai vus).
# Sinon
Posté par N3oTraX . Évalué à -2.
LOL, vu que tout le monde y met de sa distrib…
[Folie]
Personnellement même noob j'opetrais pour une Gentoo :D
Rock Stable en rolling release, tout se compile et la manipulation des USES sont simplement magiques ! Tu veux prendre une autre librairie en compte avec ton logiciel, bah tu recompile avec les nouveaux paramètres !
La distrib est optimisée aux petits oignons, puis faut dire qu'une fois installée tu sauras presque tout faire dessus.
Vu que le Giga Octet n'est pas cher pour toi, tu te monte un env supplémentaire dans un repertoire que tu chroot pour tester tes bidouilles que tu tiens tant à amener à ton système et c'est pas plus compliqué.
Tu peux meme transformer tout ca en disque kvm et lancer nativement une VM pour faire le tour d'autres sujets avec un systeme isolé de ton hote…
Optionnellement tu peux meme inclure certaines librairies compilées dans ton environnement chrooté à ton system hote, que demande le peuple !
[/Folie]
On peut vraiment faire n'importe quoi sous linux le but étant de te donner le moyens de les réaliser bibifric05.
Ceci étant je t'assure que si tu t'intéresse de près, à ce genre de touche tout dans ton OS, tu ne trouvera jamais ton bonheur préfait et livré clef en main _, le mieux étant de partir d'une base comme gentoo, arch, LFS voir meme debian et de monter ton system toi meme pour qu'il colle le mieux possible à ton utilisation et tes attentes qui sembles plus ou moins bien définies de ton coté :)
Voila pourquoi des sabayon, ubuntu, arch, funtoo et j'en passe naissent… car meme avec des systemes que tu optimise toi meme il y a toujours quelque chose qui ne plait pas au tout à chacun…
Biensur ce que je te propose la et le chemin de dures et longues heures de prises de tête mais pourtant tellement formatrice et jouissives :D
[^] # Re: Sinon
Posté par bibifric05 . Évalué à 4.
Le problème c'est que je voudrais un système où il n'y ait pas besoin de tout ce bidouillage (les chroot je connais, c'est bien pratique pour développer et compiler, mais ce n'est pas pour la vie de tous les jours) et où l'on pourrait simplement installer ses applications sans se prendre le chou…
[^] # Re: Sinon
Posté par JGO . Évalué à 3. Dernière modification le 05 novembre 2014 à 23:26.
Tu veux un système à la fois stable et mis à jour, et comme tu l'as remarqué ces deux contraintes sont en principe incompatibles. Cependant, la distribution qui est conçue justement pour ce cas s'appelle Gentoo.
Pour chaque paquet, plusieurs versions existent à tout instant. Si tu ne te préoccupes de rien, tu disposes de la version que les développeurs ont marquée comme stable. Quand tu mets à jour (rolling release), ça met à jour l'ensemble de tes logiciels vers la version stable courante (qui marche tout aussi bien qu'avec une autre distrib en version stable). Si tu as besoin d'un certain logiciel en version récente, tu peux l'autoriser individuellement en ajoutant 1 ligne à un fichier de configuration (éventuellement, une de ses dépendances peut avoir besoin de monter en version pour accompagner le logiciel en question, dans ce cas tu en es informé et il faut aussi ajouter sa ligne aux paquets autorisés à avoir une version supérieure à la stable). Gentoo te permet de contrôler bien d'autres choses mais tu n'es pas obligé de jouer avec toutes les options si ça ne t'amuse pas, sachant que ton cas d'utilisation est déjà résolu.
# openSUSE le fait (presque)
Posté par Janfi . Évalué à 2.
Je suis utilisateur de Fedora, mais je fais quelques incartades sur openSUSE, et un changement majeur est en cours : il va y avoir une version rolling release d'opensuse une fois la 13.2 sortie. Cela ne répond certes pas à tes exigences, mais cela diversifie l'offre des distributions rolling release et cela peut répondre en partie à ton problème (reste à voir, comme évoqué, la stabilité globale de la chose).
En gros, la version Tumbleweed actuelle disparait, et la version Factory devient une distribution considérée comme utilisable "en production" et rolling release qui va s'appeler… Tumbleweed…
Plus d'infos ici :
https://news.opensuse.org/2014/07/29/factory-rolling-release/
https://www.alionet.org/content.php?659-Tumbleweed-et-Factory-fusionnent
[^] # Re: openSUSE le fait (presque)
Posté par Spyhawk . Évalué à 2.
C'est pas plutôt un changement mineur, puisque Tumbleweed existait déjà, comme tu le dis? Juste plus de tests et un peu moins de flexibilité au niveau développement pour s'assurer que Factory est moins cassée?
[^] # Re: openSUSE le fait (presque)
Posté par Janfi . Évalué à 2.
Ah, c'est vrai, je me suis probablement laissé emporter :-)
Vu de l'extérieur, il me semble toutefois que Tumbleweed ancienne version restait une branche un peu en retrait, là il semblerait qu'on passe à la vitesse supérieure avec bien plus de visibilité et sans doute une adoption plus massive.
# Une distribution pour les gouverner tous.
Posté par Le Gab . Évalué à -10.
Une distribution (Debian) et un framework - comprendre "suite de règles et d'outils", attirer le max de dev en leur assurant visibilité et stabilité puis STOP!
Des 37 500 revendiqués par Debian, en supprimer les 2 tiers voire plus, par exemple sur ma machine desktop plutôt multi-tâche, j'en suis à 2319.
Bref stop avec l'argument d'exhaustivité dans LL, il s'agit plus de duplicité plus ou moins riche qu'une logithèque à la OS X.
[^] # Re: Une distribution pour les gouverner tous.
Posté par totof2000 . Évalué à 9.
Rien compris …
[^] # Re: Une distribution pour les gouverner tous.
Posté par Le Gab . Évalué à -9.
Tu as bien compris. J'en ai juste fait un peu trop. Frustrations toussa… :)
Ça ne sert à rien de prendre les gens de cons, dit le simplement que je suis hors-sujet.
[^] # Re: Une distribution pour les gouverner tous.
Posté par gUI (Mastodon) . Évalué à 5.
Hein ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Une distribution pour les gouverner tous.
Posté par totof2000 . Évalué à 8.
Je suis sérieux : je n'ai absolument pas compris ou tu voulais en venir, ce que tu voulais dire.
[^] # Re: Une distribution pour les gouverner tous.
Posté par jelo . Évalué à 0.
STOP!!!
# Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 4.
Bibifric05 a soulevé un défaut important de nos distributions: leur caractère monolithique.
Bien que cette caractéristique présent un avantage majeur, l'uniformité du système et la facilité de maintenance des différentes librairies partagées, il impose une grande difficulté à mettre à jour des applications.
D'un point de vue serveur, la chose convient. Mais d'un point de vue Desktop, elle est plus problématique.
De nombreuses solutions existent, mais aucune de fournit de solution clef en main pour l'utilisateur final. Il s'agit toujours d'un rajout à une distribution, avec les limitations que l'on connait.
C'est la richesse de notre OS, il n'est pas un OS mais de nombreux OS. La diversité fait par contre une victime: l'utilisateur final. La simplicité d'utilisation de l'OS en prend un coup: les applications évoluent rapidement, peut-être plus rapidement dans le monde du Libre que sous Windows/MacOsX, et l'utilisateur final, pour pouvoir profiter au maximum des possibilités de sa machine se retrouve toujours à jongler, bidouiller, rechercher (et souvent réparer).
Nous sommes tous des Utilisateurs Avancés, mais personnellement, je commence à être lassé de devoir passer du temps à faire marcher mon système dès que je sort des limites de la distribution (qui sont vites atteintes).
Le modèle actuel des distributions est, je pense, inadapté au desktop, et c'est probablement une raison majeure de l'échec de Linux en dehors du monde serveur. Google l'a bien montré. Il a fournit un environnement propre à l'épanouissement de l'utilisateur (aka: utiliser sa machine).
Quelles solutions à ce problème? une nouvelle distribution? Des dépots pour étendre une version stable d'une distribution existante?
[^] # Re: Recentrons le débat!
Posté par mac_is_mac (site web personnel) . Évalué à 1.
Je ne suis pas trop d'accord. Les utilisateurs avancés ont des problèmes d'utilisateurs avancés s'ils veulent avoir le beurre, l'argent du beurre et les faveurs de la crémière.
C'est sûr que si on installe des applications vitales (genre le serveur de vidéos pour les momes) sur un ordinateur qui a besoin par ailleurs que certains trucs soient bleeding edge, alors un jour, on va avoir un problème.
Si de fait, un ordinateur @home a besoin de la stabilité d'un serveur, il faut avoir la même prudence dans sa gestion.
Si on n'a pas les moyens, la place d'avoir 36 ordis @home, comme déjà dit, les chroot peuvent être une solution.
Par définition, je pense qu'aucun OS ne peut jamais être prêt pour le desktop d'un utilisateur avancé qui a des exigences d'utilisateur avancé en termes de disponibilité des logiciels.
Mais la masse des utilisateurs vit très bien avec une Debian stable ou avec une Ubuntu LTS. D'ailleurs vu les cycles de release actuels de ces deux distros, il me semble que quelqu'un qui alternerait Debian stable et Ubuntu LTS aurait des logiciels vieux d'un an au plus. Pas si mal.
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 2.
Pas d'accord. Je prends un exemple vécu : ma fille avait besoin d'openshot pour un projet video. J'étais alors en Debian stable et la version d'openshot disponible sur cette distrib était inutilisable car buguée à mort. J'ai dû compiler une version récente en recherchant les dépendances et en les compilant une à une.
Évidemment, entre temps ma fille est passée sous Windows où elle a pu télécharger et installer une application équivalente en 5 minutes.
Depuis, je suis passé à Ubuntu et pour le même problème je pourrais rechercher un ppa avec la dernière version d'openshot et l'installer. Mais une telle manip est hors de portée d'un utilisateur lambda, qui restera bloqué avec sa version buguée.
[^] # Re: Recentrons le débat!
Posté par xcomcmdr . Évalué à 1.
Euh j'ai vu plein d'utilisateurs lambda découvrant Ubuntu (et linux) se débrouiller très bien avec les PPAs, qui sont documentés depuis bien longtemps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
C'est vrai que c'est vraiment facile et intuitif à utiliser les ppa… ouvrir une console, taper des commandes obscures pour le néophyte, répondre à des messages en anglais. Facile!
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
Sans parler du fait qu'il faut savoir que ça existe et comprendre ce que s'est. Combien de temps ça prend du coup pour installer une application? une demi journée de recherche et de documentation, d'apprentissage?
[^] # Re: Recentrons le débat!
Posté par N3oTraX . Évalué à 2.
Je suis bien d'accord avec toi, le probleme est dans cette recherche incessante de cette information (que l'utilisateur lambda n'a jamais).
Il faut la chercher pour un temps X, et mettre la solution en place prend aussi un temps certain pour le commun des windowsien par exemple.
La vision que les gens ont de l'informatique, qui est faite pour leur simplfier la vie, se complique généralement vite sous toutes les distribution GNU/Linux orientées desktop dès qu'ils ont besoin de sortir de l'utilisation prévue de leur OS.
Nous commaissons tous les moyens détournés, pour arriver à nos fins, et avons tous cette expérience qui fait que nos recherche vont vite s'orienter vers la bonne direction, mais la vision pervertie de windows ou "toutes les manip sont possibles n'importe comment" entache la stabilité et la sécurité avec laquelle c'est possible sous GNU/Linux.
Je ne pense pas qu'une solution idéale clef en main existera un jour, tant l'expérience et les exigences de chacun diffèrent, voila pourquoi toutes nos chères distributions sont pléthore et on donc chacun leur force dédiée !
[^] # Re: Recentrons le débat!
Posté par totof2000 . Évalué à 6.
C'est loin d'être un problème propre au monde Linux. Essaie de sortir des sentiers battus sur un MAC par exemple, et tu verras.
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
L'avantage sous Mac (et Windows), si je veux la dernière version d'un logiciel, je la télécharge/achète, et c'est bon. Je peux l'utiliser.
Sous linux, c'est une autre paire de manche, et c'est bien là le problème. Le système de paquet est vraiment en avance (enfin était car maintenant les divers "market" ont rattrapé le retard), mais l'offre proposée est au mieux à jour au moment de la sortie de la distribution. Ensuite, si on veut évolué à partir de là, soit on attend, soit on bidouille.
[^] # Re: Recentrons le débat!
Posté par xcomcmdr . Évalué à 3.
Quand on voit que les "markets" Android et Windows (voire Apple) sont bourrés de scamwares et autres cochonneries, je dirais que non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 1.
C'est deux problèmes différents, d'un coté la sécurité, de l'autre la disponibilité des applications
[^] # Re: Recentrons le débat!
Posté par totof2000 . Évalué à 1.
1/ Ce n'est pas toujours si simple.
2/ si tu ne raques pas un max pour chaque mise à jour de chaque logiciel, tu n'as rien, ou alors tu dois supporter un tas de crapware avec les softs "gratuits". Et pour enlever ces pourritures, c'est la galère.
3/ l'offre proposée est au mieux à jour au moment de la sortie de la distribution. Ensuite, si on veut évolué à partir de là, soit on attend, soit on bidouille.
C'est la même chose pour Windows ou mac : tu dois attendre que l'éditeur te fournisse une version suffisamment stable et testée (à moins d'avoir un éditeur pas sérieux), ce qui prend du temps.
[^] # Re: Recentrons le débat!
Posté par Dr BG (site web personnel) . Évalué à 3.
Sous Mac, je ne sais pas si ça a changé, mais chez moi bof. J'ai un Macbook de mi-2007 et je ne peux pas forcément installer toutes les dernières versions car :
[^] # Re: Recentrons le débat!
Posté par j-c_32 . Évalué à 0.
Ce problème n'est-il pas résolu sous, par exemple, OpenSuse, avec le 1-clic-install ?
Si on veut aller plus loin que ce qui est proposé dans le gestionnaire de paquets, on va sur http://packman.links2linux.org/search et on installe le dépôt alternatif sans aucun problème.
Ça reste bien plus simple pour l'utilisateur lambda que la méthode sous Windows/Mac où il faut trouver le bon site pour chaque logiciel différent et ensuite s'occuper des mises à jour.
[^] # Re: Recentrons le débat!
Posté par Spyhawk . Évalué à 2.
Le OCI d'openSUSE apporte plus de problème qu'il n'en résoud, àmha. Les dépôts additionnels sont ajoutés trop facilement, les librairies qui vont avec finissent par provoquer des "dependencies hell" sans fin à cause de mauvaises priorités. L'une des features la plus demandée depuis très longtemps est un "One-Click-Uninstall", preuve qu'il y a bel et bien un problème pour l'utilisateur lambda.
La seule issue pour sortir de ce modèle monolithique des distributions Linux est à mon avis de proposer les applications compilées en statique, ou de se cantonner à une audience plus "power users" seulement.
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 3. Dernière modification le 04 novembre 2014 à 15:35.
Je sais pas si la compilation statique est la meilleure solution, c'est la plus évidente forcément, mais niveau maintenance / sécurité, c'est un grand pas en arrière.
Depuis hier, l'idée me trotte dans la tête, et ce que je commence à avoir en tête, c'est d'avoir 2 ou 3 jeux de librairies (qui peuvent avoir certaines en commun). 1 jeu pour le système, qui reste stable, et soit un jeu pour le DM + applications (donc les applications dépendront du DM), soit un jeu pour le DM et un jeu pour la couche application.
ça impliquerait de devoir toujours avoir des applications plus ou moins à jour pour pas qu'une vieille version d'un application bloque tout le monde avec une vieille version de librairie, mais c'est le but rechercher, et au moins, ça permettrai d'avancer plus vite qu'avec le modèle monolithique (et surtout de faire sauter mon wifi sur une mise à jour de la distribution seulement parce que je voulais un DM plus récent).
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 1.
Oui, c'est aussi ce que j'avais en tête…
Au fait, ils font comment Firefox ou LibreOffice pour proposer un binaire qui fonctionne sur toutes les distribs ? C'est quand même pas une compilation en statique ?
[^] # Re: Recentrons le débat!
Posté par Spyhawk . Évalué à 3.
Si, statique.
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 1.
Ah, ok. Mais il y a a quand même pas mal de libs qui sont distribuées avec le binaire…
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 1.
C'est marrant, je viens de regarder si je télécharge le tar.bz2 sur le site de firefox, et la taille du paquet sous Ubuntu 14.04, y a que 6mo de différences (40mo contre 36mo).
Sinon bibifric05, t'as déjà réfléchit un peu comment on pourrait explorer cette idée? Je me demandais si c'était pas possible d'explorer / analyser les dépots de debian pour voir si on pouvait construire un arbre de dépendances (cf debtree :http://collab-maint.alioth.debian.org/debtree/). Il doit être possible déjà à partir de ça de voir comment cassé l'arbre global de tous les paquets debian pour voir ce qu'on peut regrouper/séparer en plus sous-unité (je reprend mon Core/Dm/Apps).
[^] # Re: Recentrons le débat!
Posté par ʭ ☯ . Évalué à 2.
Peut-être qu'Ubuntu n'enlève pas les librairies incluses dans le source de Firefox?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 1.
Non, je n'ai pas réfléchi en détail. Je ne pense pas avoir le niveau nécessaire pour bâtir l'architecture d'une distribution Linux. J'ai juste l'intuition que ça doit être faisable et intéressant…
J'imagine qu'il faudrait s'appuyer sur une distribution existante pour la prendre comme base stable. Pour le reste je ne sais pas trop…
[^] # Re: Recentrons le débat!
Posté par BAud (site web personnel) . Évalué à 2.
ah bah ça… c'est la notion de « Real Machine » : ya tout ce qu'il faut qui vient avec (et ça peut être du lourd).
[^] # Re: Recentrons le débat!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le problème est toujours que la mise à jour de la lib "desktop" peut te casser la plus part des autres soft. Si tu changes une lib partagé, tu as besoin de tester "n" softs, si tu compiles en statique, tu n'a besoin de tester qu'un seul logiciel.
En cas de problème de sécurité, cela fait plein d'upgrade au lieu d'une seul lib, c'est vrai. J'imagine que les lib de sécurité serait dans le "core".
"La première sécurité est la liberté"
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 1.
On peut résoudre ça assez facilement, en mettant les variables d'environnement qui vont bien (Si je change la lib du DM, je vérifie qu'aucune app en dépend, et je la retire.
Ou si on a un environnement librairie juste pour les applications, le problème se pose pas (ça fait 3 jeux de lib: Core/lib, DM/lib, App/lib.
[^] # Re: Recentrons le débat!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu veux dire que tu gère un jeu de lib pour chaque logiciel à mettre à jour ?
Dans ce cas, c'est bien plus performant de tout faire en statique, le loader sera beaucoup plus rapide.
"La première sécurité est la liberté"
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 1.
Non, un jeu de lib pour le Core (système), un jeu de lib pour le DM, et un jeu de lib pour les applications. Trois environnements de librairies, donc 3 versions de librairies max.
On pourrait avoir le Core en Release régulière (tous les ans, ect..), les DM quand ils sortent (pour Gnome, tous les 6 mois), et les applications en Rolling Release.
[^] # Re: Recentrons le débat!
Posté par BAud (site web personnel) . Évalué à 4.
mieux vaut aller en bibliothèque : plutôt que de payer les bouquins, tu peux les emprunter ;-)
[^] # Re: Recentrons le débat!
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
DM ?
Dans ton cas, cela ne règle pas du tout le problème. Il y a toujours un boulot de dingue pour vérifier que rien n'a cassé sur le tier des applications lors d'une mise à jour.
"La première sécurité est la liberté"
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
Y a un boulot de dingue si on considère que les applications utilisent toutes les "bibliothèques", or, c'est loin d'être le cas:
jerome@io:~$ apt-cache depends clementine
clementine
Dépend: libc6
Dépend: libfftw3-double3
Dépend: libgcc1
|Dépend: libgl1-mesa-glx
Dépend:
libgl1-mesa-glx
Dépend: libglew1.10
Dépend: libglib2.0-0
Dépend: libgpod4
Dépend: libgstreamer-plugins-base0.10-0
Dépend: libgstreamer0.10-0
Dépend: liblastfm1
Dépend: libmtp9
Dépend: libprotobuf8
Dépend: libqca2
Dépend: libqjson0
Dépend: libqt4-dbus
Dépend: libqt4-network
Dépend: libqt4-opengl
Dépend: libqt4-sql
Dépend: libqtcore4
Dépend: libqtgui4
Dépend: libstdc++6
Dépend: libtag1c2a
Dépend: libx11-6
Dépend: zlib1g
Dépend: gconf2
gconf2:i386
Dépend: libqt4-sql-sqlite
Dépend: gstreamer0.10-plugins-base
Dépend: gstreamer0.10-plugins-good
|Dépend: gstreamer0.10-alsa
Dépend:
gstreamer0.10-alsa
gstreamer0.10-plugins-bad
gstreamer0.10-plugins-good
gstreamer0.10-pulseaudio
Dépend: gstreamer0.10-plugins-ugly
|Dépend:
Dépend: projectm-data
Dépend: libqca2-plugin-ossl
qgis
Dépend: libc6
Dépend: libgcc1
Dépend: libgdal1h
Dépend: libgeos-c1
Dépend: libgsl0ldbl
Dépend: libpq5
Dépend: libproj0
Dépend: libqgis-analysis2.0.1
Dépend: libqgis-core2.0.1
Dépend: libqgis-gui2.0.1
Dépend: libqgis-networkanalysis2.0.1
Dépend: libqt4-network
Dépend: libqt4-sql
Dépend: libqt4-svg
Dépend: libqt4-xml
Dépend: libqtcore4
Dépend: libqtgui4
Dépend: libqtwebkit4
Dépend: libqwt6
Dépend: libspatialite5
Dépend: libsqlite3-0
Dépend: libstdc++6
Dépend: qgis-providers
Dépend: qgis-common
on a pas grand chose grand chose en commun ..
[^] # Re: Recentrons le débat!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu prends la lib Qt, cela fait déjà un paquet de truc. D'ailleurs tu prends le problème à l'envers. Il faut voir combien de paquet dépende de libqtgui4 ou de libgcc1, pas l'inverse.
"La première sécurité est la liberté"
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 1.
Je suis bien d'accord, il y a une poignée de librairies clefs, qui occupent un rôle centrale.
Donc grosso modo, tout va dépendre d'elles pour avoir des applications à jour.
A voir donc:
- à quelle fréquence elles sont mises à jour;
- les cas des applications pas mises à jour (et donc qui vont empêcher le passage à une versions supérieures de ces librairies, et donc des autres applications).
Pour le deuxième cas, je vois une solution assez triviale : on laisse les applications pas mise à jour dans le DM, les autres, on les met dans la partie Bleeding Edge. mais bon, ça reste à voir.
J'ai pas spécialement de temps en ce moment, mais dès que j'ai un petit moment, je ferai joujou en analysant les dépots debian (on doit pouvoir utiliser la théorie des graphes pour voir un peu tout ça).
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 1.
(Desktop Manager: Gnome, KDE, ect..).
Sinon, un exemple plus concrêt (qu'on doit pouvoir mettre en place san trop de difficultés):
Mon Core (système + Xorg) (et ses bibliothèques) est issue de paquet de Debian Stable;
Mon Desktop (et ses bibliothèque) est issue des paquet de Debian Testing ou SID;
Mes applications (et leur bibliothèques) sont issue de SID;
On a déjà des bases qui fonctionnent, on a prend les morceaux qui nous intéresse, et on les colle ensemble.
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 0.
Oui, ça serait déjà pas mal, ça… Il faudrait aussi pouvoir installer plusieurs versions d'une même appli, si elle bugue, mais là j'en demande un peu trop peut-être…
[^] # Re: Recentrons le débat!
Posté par ʭ ☯ . Évalué à -3.
Le problème est là : pourquoi vouloir précisément cette application? Par exemple, Kdenlive est très stable, et permet de travailler en attendant qu'Openshot devienne stable.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Recentrons le débat!
Posté par coid . Évalué à 0.
Quels crétins, ces utilisateurs, de vouloir utiliser une autre application que celle prévue par la distrib…
Avec une telle attitude, m’est avis que Linux n’est pas prêt de percer sur le Bureau.
[^] # Re: Recentrons le débat!
Posté par Moonz . Évalué à 4.
Faudrait se décider un jour : le problème de Linux sur le bureau c’est qu’on a 50 applications qui font la même chose ou bien qu’on puisse pas choisir son application parmi les 50 qui font la même chose ?
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 4.
Sachant que l'essence même du logiciel libre, c'est la liberté, je vote 2.on puisse pas choisir son application parmi les 50 qui font la même chose
[^] # Re: Recentrons le débat!
Posté par ʭ ☯ . Évalué à 3.
"Pouvoir choisir" est différent de "mélanger facilement". L'exemple d'OpenShot : tu "peux choisir" d'utiliser le dernier OpenShot, en utilisant Debian Sid par exemple. Par contre les distributions ne te permettent pas de "mélanger facilement" le dernier OpenShot, le premier Kde et le Firefox de 2003.
M'enfin, c'est pourquoi cette longue discussion parlait d'un système permettant facilement ça, et la conclusion est que ça demandera une main d'œuvre immense pour les 20.000 paquets d'une bonne distribution.
C'est pourquoi seuls les gros projets proposent des solutions autonomes, comme Firefox, LibreOffice ou Supertuxkart ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
C'est pourquoi Linux n'est pas prêt pour le Desktop et ne le sera pas tant que ce problème ne sera pas résolu
[^] # Re: Recentrons le débat!
Posté par Spyhawk . Évalué à 4.
Au passage, Linus Torvalds avait abordé ce problème lors de la DebConf14 (par contre je ne sais plus exactement où dans la vidéo..)
[^] # Re: Recentrons le débat!
Posté par coid . Évalué à 2.
5:45
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 4.
Merci (du coup, je viens de regarder la vidéo en entier, je recommande).
Donc pour résumer, les distributions actuelles rendent les choses:
Bref, on est dans l'impasse pour le desktop j'ai bien l'impression?
[^] # Re: Recentrons le débat!
Posté par BAud (site web personnel) . Évalué à 1.
il suffit de trouver quelqu'un qui n'est pas au courant et y arrive tout de même… (c'est pas comme si Slackware, Gentoo, Emmabuntu, Mageia, Debian GNU/Linux stable, FreeBSD, PC-BSD, rawhide, openSUSE… étaient inutilisables au jour le jour).
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 0.
c'est pas comme si elles étaient vraiment utilisés non plus, comparativement aux OS majeurs
[^] # Re: Recentrons le débat!
Posté par BAud (site web personnel) . Évalué à 0.
tu compares à android ?
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
Windows, MacOsX, Android, ChromeOs, iOS
[^] # Re: Recentrons le débat!
Posté par ʭ ☯ . Évalué à 5.
Va installer le logiciel que tu veux en dehors des dépôts des ces 3 OS, et reviens nous raconter ;-)
La seule différence, c'est que leur succès a attiré beaucoup de développeurs, qui s'embêtent à faire des paquets eux-mêmes et à les faire accepter dans les dépôts officiels. Il y a plein d'apps qui marchent pas sur mon téléphone Android 2.3 qui ne date que de 2011!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
Téléphone Android ou Samsung/Sony/ect Android ?
[^] # Re: Recentrons le débat!
Posté par Spyhawk . Évalué à 3.
Il a besoin d'utiliser des libs partagées aussi? (c'est une vrai question, je n'y connais rien à l'écosystème des smartphones).
[^] # Re: Recentrons le débat!
Posté par claudex . Évalué à 7.
Comme toute application Java (même si Android, ce n'est pas vraiment Java), la plupart des libs sont embarquées dans l'appli (ce qui veut dire que hors des grosses applications, il n'y a aucun suivi de la sécurité).
« 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: Recentrons le débat!
Posté par Spyhawk . Évalué à 3.
Merci. Donc simplicité versus sécurité.
[^] # Re: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 2.
Hmm, même si il est vrai que l'on peut utiliser des applications externes, il y a quand même un SDK qui comprend beaucoup beaucoup beaucoup de chose, et qui doit être suffisant à 90% des applications. SDK géré et mis à jour par Google/le fabricant.
[^] # Re: Recentrons le débat!
Posté par claudex . Évalué à 4.
Rien que le truc de compatibilité ou Google Analytics, c'est à part.
« 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: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 3.
Relis bien stp, j'ai pas dit que tout était inclus, j'ai dis "Quasiment tout". C'est un autre monde par rapport à nos desktops linux je pense?
En passant, un peu fatiguant ses discussions sur Linuxfr, ça tourne systématiquement en enculage de mouche. J'avais pas participé depuis longtemps, maintenant je me rappelle pour quoi.
[^] # Re: Recentrons le débat!
Posté par claudex . Évalué à 3.
Quasiment toutes les distribs Linux incluent Qt (c'est même dans la LSB), ce n'est pas très loin du framework fournit de base par Android. Je ne vois pas bien le monde de différence.
Si tu viens poster après un long thread, il ne faut pas se plaindre de l'enculage de mouche, sinon tu te limite aux premiers commentaires d'un thread.
« 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: Recentrons le débat!
Posté par Jérôme (site web personnel) . Évalué à 0.
Le sdk android comprend un peut plus de chose que QT quand même : https://developer.android.com/reference/packages.html
[^] # Re: Recentrons le débat!
Posté par claudex . Évalué à 3.
Je vois du net, du sql, du xml et de la gui, tout ce qu'on retrouve dans Qt.
« 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: Recentrons le débat!
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Pourtant ce serait si simple pour les distribs de mettre un dépôt maven dans /usr/lib/java !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Recentrons le débat!
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il faudrait peut être directement en parler avec des contributeurs de distribution qui s'occupe de java, par exemple dans Mageia. Cela sort sans doute de leur habitude, il faut donc bien leur "vendre".
"La première sécurité est la liberté"
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 0.
Oui, c'est sans doute un boulot énorme. Ou alors, il doit être fait en amont avec un format de paquet "universel". Il me semble qu'il y avait eu une tentative en ce sens il y a quelques années. Je ne me rappelle plus le nom du format de paquet, mais ça n'avait pas pris…
[^] # Re: Recentrons le débat!
Posté par ʭ ☯ . Évalué à 3.
Tu n'as toujours pas compris que le problème n'est pas dans le format de paquet : un deb ou un rpm fait l'affaire, le problème est qu'est-ce que tu embarques dans ton binaire pour être vraiment autonome? Firefox par exemple exige la glibc 2.3 minimum, tu ne peux donc pas l'utiliser sur une distrib de 2007.
Ceci sans aborder les bus de communication entre applications : un jeu s'en fiche, mais une application de chat bien faite va communiquer avec l'application de mail, et elle va donc devoir utiliser la même version de dbus par exemple.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Recentrons le débat!
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour les jeux, un conteneur plus ou moins sécurisé (machine virtuelle, chroot ou autre) ferait l'affaire.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Recentrons le débat!
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il faudrait définir les propriétés que tu attends de tels conteneur. Parce que discuter entre applications peut devenir très compliqué (gestion du son, d'un programme audio externe, d'échange de donnés, de sauvegarde des sauvegardes, etc…).
"La première sécurité est la liberté"
[^] # Re: Recentrons le débat!
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Il faudrait bien réfléchir en effet. Je pense que http://www.libretro.com/ fait à peu près ce que j'attends sauf la sécurité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Recentrons le débat!
Posté par bibifric05 . Évalué à 1.
Je suis allé un peu vite : un format de paquet universel permettrait aux développeurs de proposer des versions installables sur les dernières distributions. Ce serait déjà ça même si ça ne résout pas le problème de fond,
[^] # Re: Recentrons le débat!
Posté par ʭ ☯ . Évalué à 3.
Tu es encore allé trop vite : ce format existe déjà : un rpm est installable partout, avec alien dans les distributions basées sur deb. C'est le mode de distribution de flashplayerplugin, realplayer, oracle, etc.
Mais sans dépôt central, c'est plus compliqué qu'Android à utiliser.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Recentrons le débat!
Posté par claudex . Évalué à 4.
Il n'y a surtout aucune garantie qu'il fonctionne s'il n'embarque pas toutes les libs nécessaires. Et la gestion des dépendances ne marchera pas (pas les mêmes noms dans les différentes distributions, pas forcément les mêmes version non plus (backport, options de compilation…)).
« 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: Recentrons le débat!
Posté par bibifric05 . Évalué à -5.
C'est ce que me dit ma copine aussi : je vais toujours trop vite ;)
# Click package
Posté par matteli . Évalué à 1.
Est ce que ce n'est pas le principe du click package que va proposer ubuntu sur ces prochaines versions ?
# Et 0install ça n'irait pas ?
Posté par fasthm . Évalué à 3.
J'ai ce truc dans mes bookmarks depuis des années, mais jamais testé :
http://0install.net/
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# Autopackage
Posté par bibifric05 . Évalué à 1.
Au fait, j'ai retrouvé le nom du système de paquets universel qui était testé il y a quelques années : c'était autopackage.
# Paquet universel
Posté par claudex . Évalué à 3.
Je vais quand même écrire mes réflexions sur un format de paquet qui marcherait sur toutes les distribution. Premièrement, il faut un format source (on peut imaginer que le dépôt compile automatiquement pour les distribution les plus connue), ensuite il faut une base de données de correspondance des noms de paquets entre distribution, il faut aussi faire la liste des options de compilation (si on a besoin d'openssl avec openldap, ça ne marchera pas avec les distributions qui utilise gnutls). Enfin, il faut un système de permission à la Android (en utilisant LSM, LXC, Docker…) appliqué par défaut pour éviter que les applis n'aient trop de permission (bon, ce dernier point n'est pas nécessaire, mais je pense qu'il serait un plus qui rendrait ces paquets intéressants).
Le point qui me semble le plus difficile est les informations de compilation, mais pas du point de vue de la récolte (c'est relativement automatisable) mais que les développeurs fasse la liste de ce dont ils ont vraiment besoin. Et je doute que la plupart de ceux à l'origine des applications hors dépôt en ai une idée suffisamment précise.
« 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
# Une réalisation simple ?
Posté par bibifric05 . Évalué à 1.
Bon, après réflexion et suite à vos remarques, ne pourrait-on pas faire la chose comme ceci :
on installe une Debian stable avec la base du système, ses outils de configuration et le bureau de son choix
on crée un chroot contenant Debian sid
dans ce chroot on installe les applis que l'on veut. Ce seront donc les versions les plus récentes des applis.
L'utilisateur a bien sûr la possibilité de choisir les versions des applications qu'il souhaite (ce serait géré par un programme spécifique de la distribution). Soit la version stable, soit la version récente. Par défaut, la version récente par exemple.
Tout ça se met à jour et se maintient grâce au système apt de la Debian sous jacente. Les mises à jour de sécurité sont faites aussi via apt.
Au final, le travail à faire par la distribution semble minimal et la sécurité semble respectée.
Qu'en pensez-vous ?
[^] # Re: Une réalisation simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Faire cohabiter totalement 2 distributions, sans quelles se marchent sur les pieds ? Cela se tente, je dirais.
"La première sécurité est la liberté"
[^] # Re: Une réalisation simple ?
Posté par ʭ ☯ . Évalué à 2.
C'est même possible en mélangeant les distributions, genre un chroot Mageia dans une Ubuntu, mais tu oublies qu'il faudra lancer les applications graphiques par ssh pour gérer xauth & co…
Bref, essaye par toi-même et viens nous raconter, beaucoup ici ont déjà essayé tout ça.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Une réalisation simple ?
Posté par kna . Évalué à 1.
C'est là qu'il y aura un peu de boulot, il faudra aussi gérer les lanceurs qui fassent automatiquement chroot /chemin/vers/sid /chemin/vers/appli.
Une autre solution, qui donnerait plus de boulot pour le mainteneur, mais rien à dev, serait de faire un dépôt backport avec les applis (on peut s'appuyer sur les paquets source de sid), en gardant les libs et la base du système du dépôt stable. On met une haute priorité à ce dépôt. L'utilisateur avancé peut même décider d'utiliser une version stable d'une appli particulière en faisant du pinning.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.