Pour moi, un des principaux avantages de GNU/Linux est qu'il n'est pas besoin de réinstaller le système régulièrement, sauf cas extrême.
Pour l'instant, je tourne sous une Mandrake 9.1, et je souhaite ardemment installer quelques logiciels récents, comme gnome 2.6, gimp 2, le noyau 2.6.4, et quelques autres de moindre « ampleur ». Le problème est que je ne trouve aucun paquet adapté à ma distribution. Concernant l'installation à partir des sources, je tombe sur des avertissements inquiétants concernant le risque de casser des choses en mettant à jour gtk, ou des risques de problème avec tel lib etc.
Ce n'est pas un troll, mais le système des rpms me paraît bien faiblard sur le coup (1 an après la sortie de la distrib, on ne trouve quasimment plus rien de récent, même texstar et plf ne suivent plus). Là, sur ma mdk 9.1, j'ai de plus en plus de logiciels installés à partir des sources, ce qui fait que ma base rpm avec gestion de dépendances perd de l'intérêt.
Si la seule solution consiste installer la dernière version de ma distrib (la maj à partdes cds n'a jamais été réputée fiable), je me dit qu'il vaut autant mieux en profiter pour passer à autre chose qui me correspondrait mieux. J'en reviens donc, au bout de plus de deux ans, à la questions existentielle originelle et universelle : quelle distrib pour mon bonheur ?
Mes besoins impératifs :
- distribution communautaire sous licence Libre.
- une distrib qu'on peut mettre à jour (installer des logiciels) sans avoir à ne serais-ce que penser à la réinstaller. On n'est pas sous Windows, flûte !
- des logiciels « relativement » récents « rapidement » disponibles (guillemets parce que c'est subjectif, disons quelque chose de raisonnable).
- quelque chose de relativement stable malgré tout (les branches de développement ne sont pas prévu pour de l'utilisation bureautique)
Compromis possibles :
- pas besoin d'outils clic-partout tant que le système de gestion est clair.
- l'autodétection du matériel peut être secondaire tant que, là encore tout est clair.
Mon système :
- portable armada compaq
- pII 400 avec 192 Mo de RAM
- disque dur 40 Go
- config « changeante » (réseau pcmcia pas toujours branché, graveur externe, etc.)
Comme je connais assez peu les distributions autres que mandrake, c'est là que je vais avoir besoin de vous pour corriger le résultat de mes recherches le plus objectivement possible :-) :
Gentoo
D'après ce que j'ai compris, les paquets récents sont au rendez-vous. Comme tout vient de sources, la cohérence du système est assurée. Mais mon système risque d'être un peu lent pour que les temps de compilation soient suportables. Y a-t-il des versions binaires pour au moins les logiciels « majeurs » ?
Debian
Sid me fait un peu peur quant aux compétences requises pour garder un système fonctionnel, par exemple quand des choses sont cassées. Sarge est plus stable et il semble qu'il existe des cds d'installation pour éviter de partir de woody. Mais un logiciel comme gimp2, par exemple, est-il déjà tombé dans sarge. Sinon, combien de temps compter en moyenne entre la sortie et l'arrivée dans sarge pour un soft majeur ?
slackware
La première distrib que j'ai jamais installée \o/ (un presqu'offert en 95 je crois). Il parait qu'il n'y a (toujours) aucune fioriture, mais au moins, tout est clair : logiciels fournis sans aucune modification, pas gestion de dépendance qu'on risque de casser. Le site linuxpackages.net me montre que gimp 2 est disponible. Mais peut-on garder une slackware toujours à jour sans réinstaller ? Par exemple, passer de 9.0 en 9.1 et ainsi profiter des derniers logiciels packagés ? Installer gnome 2.6 peut-il se faire sans trop de problème ? Et le noyau 2.6 ?
Beaucoup de questions pour quelqu'un qui cherche à y voir plus clair dans ce qui est une véritable jungle :-)
Journal éternel dilemne
12
avr.
2004
# Re: éternel dilemne
Posté par gawal . Évalué à 3.
Sarge est a déconseillé, tu trouveras moins facilement de l'aide qu'avec une woody et certains paquets mettent beaucoup de temps à passer (par exemple, pour gnome 2, ca a pris plus de six mois).
Dernière chose, installer un nouveau noyeau est très facile même s'il n'est pas officiellement dans debian grace à make-kpkg.
# Re: éternel dilemne
Posté par Florent Bayle (site web personnel) . Évalué à 3.
Pour ce qui est de la stabilité, je suis en sid depuis qq temps (plus d'un mois il me semble), et j'ai jamais eu de gros problèmes, sachant que si il y a des dépendances non-résolues, apt ne fait pas la mise à jour et ne casse donc rien... Sinon, j'ai été en testing pendant un bon bout de temps, et j'ai jamais eu de problèmes non plus. Je suis passé à sid juste pour tester KDE 3.2. En ce qui concerne le temps de passage, je crois qu'il faut compter une semaine pour qqu'un logiciel qui vient de sortir soit en sid, et plus d'un mois pour qu'il soit en testing (je parle en terme de temps réel, et non théorique).
Il faut savoir que des packets classés Testing ou Unstable sur la Debian sont souvent déjà dans les versions boite des autres distributions.
Pour Gimp, la version 2.0 est déjà en sid, mais je sait pas si elle est en testing. Je sait pas si elle aura le temps de passer en testing avant le gel de celle-ci pour la sortie de la Sarge...
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
> testing. Je sait pas si elle aura le temps de passer en testing avant le gel
> de celle-ci pour la sortie de la Sarge...
Trop gros, passera pas
On a déja fait le coup pour gnome2.4 l'année dernière...
# Re: éternel dilemne
Posté par M. Vandemar . Évalué à 3.
Si ça ne concerne que quelques paquets, regarde si un petit mix sarge/sid ne te ramène pas trop de dépendances de sid.
# Re: éternel dilemne
Posté par Franck . Évalué à 1.
[^] # Re: éternel dilemne
Posté par Cyberdivad . Évalué à 1.
[^] # Re: éternel dilemne
Posté par Moby-Dik . Évalué à 3.
Oui.
Mais n'est-ce pas dangeureux d'avoir un système « hybride » ?
Non (mais planque ton chien dans une cage de Faraday quand même, on sait jamais).
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
Si tu veut utiliser cooker, prends tout cooker.
[^] # Re: éternel dilemne
Posté par liberforce (site web personnel) . Évalué à 1.
Donc oui, cooker, ou bien mdk 10CE + updates dès que les miroirs seront de retour (incessamment sous peu)
La méthode:
urpmi urpmi pour mettre à jour urpmi
urpmi --auto-select --keep pour tout mettre à jour, et va boire un café...
# Re: éternel dilemne
Posté par Pascal . Évalué à 1.
Pas de problemes de dépendances (et oui y'en a pas).
Tout est très simple. En plus tu peux la garder à jour à la manière d'une Debian Sid avec la distribution slackware-current qui est mise à jour environ toutes les semaines.
[^] # Re: éternel dilemne
Posté par Cyberdivad . Évalué à 1.
Je suppose qu'on passe en slackware current après avoir installé la 9.1 à partir des cds et qu'il y a un outil/script quelconque qui permet de gérer les maj ?
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 1.
bin il faut savoir ce que l'on cherche aussi :-)
Toutes les versions de devel que j'ai utilisées etaient plus ou moins utilisable, après il faut avoir une bonne raison pour aller chercher les ennuis.
Ahma ce que tu cherches correspond plus a gentoo ou sourcemage. Cela te permettra de garder un base saine sans te prendre la tete et d'integrer ce que tu veux assez facilement.
Mais encore une fois si tout ce que tu veux c'est juste disposer des derniers logiciels pourquoi ne pas mettre a jour ?!!
[^] # Re: éternel dilemne
Posté par Cyberdivad . Évalué à 1.
Je cherche à installer des logiciels (stables) tout simplement.
Mais encore une fois si tout ce que tu veux c'est juste disposer des derniers logiciels pourquoi ne pas mettre a jour ?!!
Ma Mandrake, de 9.1 vers 10 ? J'aimerais ne pas reformater mon / pour une simple mise à jour et surtout pour deux-trois logiciels seulement que je souhaite vraiment.
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: éternel dilemne
Posté par M. Vandemar . Évalué à 6.
[^] # Re: éternel dilemne
Posté par Alexandre . Évalué à 0.
[^] # Re: éternel dilemne
Posté par Jean Roc Morreale . Évalué à 1.
oops :p
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 1.
Mais au pire tu gardes ta liste de rpm installés et tu la redonnes a manger a l'instalation...
Formater / on s'en fou si tes partitions sont bien pensées. Les données que tu as modifiées tu les gardes et c'est rétabli en 2 minutes.
Autrement n'utilise pas une distrib binaire... C'est aussi simple que cela !
Si tes 2/3 applications comme tu dis sont gnome 2.6 & co alors ces 2/3 applications ca risque quand meme d'etre 60% du système :-)
Pour ce qui est de slackware tres peu pour moi personellement je ne vois pas l'apport de la chose. Regarde du coté de gentoo ou sourcemage ou xxxx
[^] # Re: éternel dilemne
Posté par modr12 . Évalué à 1.
pour la stabilité , ça va
pour gnome soit tu utilise garnome et c'est long ( mettre a jour sgmt-tool version 0.6.9 ) soit tu utilise dropline ( problème de desinstallation ?) ou tu attends qu'ils sortent dans current
pour le 2.6 pas de problème , mais il faut mieux avoir une version récente de hotplug
[^] # Re: éternel dilemne
Posté par modr12 . Évalué à 1.
DocBook-utils version 0.6.9 (jw version 1.1)
pour gnome 2.6
[^] # Re: éternel dilemne
Posté par Éric (site web personnel) . Évalué à 4.
ah ? je peux retirer ma glibc sans que rien ne casse ?
Ce n'est pas qu'il n'y en a pas, c'est que rien ne t'aide à les gérer.
Et écrit comme ça c'est tout de suite moins intéressant tu crois pas ?
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à -1.
Ce n'est pas qu'il n'y en a pas, c'est que rien ne t'aide à les gérer.
Et écrit comme ça c'est tout de suite moins intéressant tu crois pas ?
Non, moi je ne crois pas. Deja, ca ne me semble pas terrible de desinstaller un package sans savoir ce que c'est, rpm, deb ou tgz. C'est une question de bon sens.
D'autant plus que ce ne sont pas les dependances qui font forcement la necessite d'un logiciel (desinstalle lilo ou le bash qu'on rigole). RPM va-t-il se plaindre ? Donc dans ce cas, la gestion des dependances est inutile. Ca n'empeche pas les betises.
J'ajoute que sur la slack, les logiciels sont regroupe en serie (a, ap, d, e, f, gnome, k, kde, kdei, l, n, t, tcl, x, xap, y et extra). Ce qui vient de 'a' est essentiel en general et suffisant pour faire tourner le systeme, donc tu touches pas sans savoir :-) Au moins c'est clair.
D'autre part, les gestions sont souvent mal ficelees avec les rpms ou deb. Ce n'est pas parce qu'un logiciel A a une dependance avec B qu'il ne va plus marcher du tout si je retire B. Dans la plupart des cas, le logiciel marche, simplement avec une fonctionnalite en moins. Dans les autres cas, il met un message d'erreur parce qu'il ne trouve pas B, qu'il suffit d'installer. Bref, la meme chose que ce que dit rpm a part qu'on a pas besoin d'installer les logiciels dans un ordre particulier exclusif. Utilite d'une base de donnee ? Limitee. Je passe sur les dependances circulaires qui me font toujours hurler de rire.
L'utilisation de dependances oblige egalement a fractionner grandement tous les paquets ce qui augmente a la complexite du systeme et tres souvent a sa coherence. Et si on a pas besoin des include ou des libs, et bien tant pis, tous le monde ne bosse pas sur de l'embarque ou des serveurs i486, il y a de la place sur les disques quand meme. Quand j'installe A, j'estime normal d'avoir tout A. C'est incroyable de proposer ce genre d'economie avec des distribs qui font plus de 3 CD de binaires.
Enfin, une base de donnee qui plante pose souvent de serieux problemes et met en jeux la sanite de tout le systeme. Je suis desole de choquer mais cela me semble tres similaire a la base de registre de Windows. Ca ne me semble pas solide comme methode.
A l'oppose, Slackware mise sur la simplicite. Chaque package (un simple tgz) ecrit la liste de ses fichiers dans un bete fichier texte. Tu peux upgrader/downgrader sans problemes. C'est incassable.
Pour ma part, j'ai fait slack 8.0 -> 8.1 -> 9.0 -> 9.1 sans soucis. Bon, il y a un sacre bazar dans /etc, /home/*/ et /usr/local mais ca ronronne toujours. Je ferai probablement le menage en passant a XFS avec la prochaine slack.
La seule critique que j'ai contre le systeme de la slack, c'est que sur une vieille becane qui a beaucoup de packages, retirer ou upgrader un package prend du temps car le script scanne toutes les autres listes de fichiers pour voir si il y a des fichiers communs avec un autre package et donc garder le-dit fichier.
Le systeme de la slack est honnetement le plus fiable a l'utilisation meme si ce n'est pas forcement le plus simple du point de vue utilisateur (quoique...).
PS: Tu as oublie Fedora dans ta liste.
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 1.
Bin si rm /**/fichier texte... :-)
Rigole pas j'ai fait parreil avec ma sourcemage.
Il suffit simplement de savoir se servir de ses outils...
La comparaison avec la base de registre est ridicule, tout logiciel pour fonctionner a besoin de données, si tu retires ces donnees ca marche plus c'est aussi con que ca !
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 0.
1. Tu as un backup des fichiers
ou
2. Tu reinstalles les packages qui manquent
En general, un rm /* c'est jamais bon, quelque soit le systeme de package.
La comparaison avec la base de registre est ridicule, tout logiciel pour fonctionner a besoin de données, si tu retires ces donnees ca marche plus c'est aussi con que ca !
Oui, mais que les donnees d'installation soient dans une base binaire c'est hautement discutable. C'est bien ca le probleme. D'autant plus qu'il existe des formats rpms pour RH, MKK, SuSE etc. C'est pas portable.
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 0.
Ouai c'est clair que d'un seul coup ca discredite totalement la base rpm que tu ne peux pas backuper !
2. Tu reinstalles les packages qui manquent
Ca non plus ce n'est pas faisable autre part que sur mandrake
3. En general, un rm /*
Y'a un peu une difference entre rm /* et rm /**/xxx mais bon passons
4. Oui, mais que les donnees d'installation soient dans une base binaire c'est hautement discutable.
C'est clair que ca change completement tout ! Je suis con de pas y avoir pensé avant
5. D'autant plus qu'il existe des formats rpms pour RH, MKK, SuSE etc. C'est pas portable.
C'est vrai que slackware et ses fichiers textes c'est carrement plus portable.
bon allez j'ai bien rigolé c'est bon tu as gagné ta journée :)
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 1.
J'ai jamais dit le contraire, ca prouve que ton argument est non avenu puisque valable dans les deux cas
C'est clair que ca change completement tout !
Un unique binaire modifie est moins stable qu'un fichier ascii modifie parmi plusieurs. Je suis oblige de l'ecrire parce qu'apparement...
Je suis con de pas y avoir pensé avant
Si tu le dis
C'est vrai que slackware et ses fichiers textes c'est carrement plus portable.
Je ne vois rien de plus portable qu'une liste de fichier dans un fichier ascii. C'est exploitable avec n'importe quelle becane, humainement lisible et comprehensible et ca ne demande que des outils de bases pour etre exploite.
C'est a croire que tu n'as jamais eu a compiler RPM pour croire que c'est plus portable.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 1.
http://linuxfr.org/~cykl/3203.html(...)
Comme quoi c'est pas toujours super top cool les apt-get.
Les commentaires sont d'ailleurs eloquents
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 1.
tu critiques un principe, tes critiques sont infondées .|
allez j'ai pas que ca a foutre.
(note: en connaissant son systeme de packaging tu as toujours moyen de recuperer le tout, la debian j'en ai jamais rien eu a foutre hormis connaitre apt. Enfin de mémoire j'avais pas réinstallé donc y'avait bien une solution... Après c'est sur suprimer la gestion de package enlève tout les bugs du gestionaire de package tu viens pas d'inventer l'eau chaude en disant ca....)
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
[^] # Re: éternel dilemne
Posté par Uvoguine . Évalué à 1.
et je sors parceque Linux fait pas partie du projet GNU donc mablague marche même po :-(
-> []
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à -2.
Ton probleme n'en aurait pas ete un sur un systeme sans dependance comme la Slack ou les packages sont des simples zip.
Mais ca te fait trop mal de l'avouer.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 2.
Sur windows, ça me fait :
rm command not found
Donc windows rox
=>[]
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . Évalué à 3.
Tu peux savoir ce que c'est sans savoir si un logiciel installé en a besoin. Par exemple j'ai libxml1 et libxml2, je sais très bien ce que c'est, mais comment savoir si j'ai des logiciels qui utilisent libxml1 ?
Je pourrais, effectivement, compter sur ma mémoire, mais je préfère laisser l'ordinateur faire ça, perso...
«ce ne sont pas les dependances qui font forcement la necessite d'un logiciel»
Les dépendances ne résolvent pas tous les problèmes, donc elles ne servent à rien ?
«D'autre part, les gestions sont souvent mal ficelees avec les rpms ou deb.»
C'est idiot comme argument. Pour montrer que les dépendances sont inutiles, tu expliques qu'elles sont mal faites. Donc si elles étaient bien faites, elles seraient utiles ?
«Ce n'est pas parce qu'un logiciel A a une dependance avec B qu'il ne va plus marcher du tout si je retire B. Dans la plupart des cas, le logiciel marche, simplement avec une fonctionnalite en moins»
Sais-tu que l'on peut faire une distinction entre dépendances requises et optionelles ? Dans un paquet bien fait, si tu retires une dépendance requise, c'est cassé.
«Et si on a pas besoin des include ou des libs, et bien tant pis, tous le monde ne bosse pas sur de l'embarque ou des serveurs i486, il y a de la place sur les disques quand meme.»
"Moi j'installe tout, donc pas de problèmes de dépendances", ah ben oui, vu comme ça :-)
«Enfin, une base de donnee qui plante pose souvent de serieux problemes et met en jeux la sanite de tout le systeme. Je suis desole de choquer mais cela me semble tres similaire a la base de registre de Windows. Ca ne me semble pas solide comme methode.»
Mouahaha :-)
Les bases de données, c'est d'la merde, si ça plante c'est planté. Et ton système de fichier aussi, s'il plante tu es mal, vu que c'est une sorte de base de données. Le truc c'est que ça n'a quasiment aucune raison de planter, et que dans tous les cas la base de paquets peut être reconstruite.
Le défaut de la base de registres c'est que c'est un format obscur qui plante tout le temps et qui n'est jamais nettoyé. Rien à voir avec une vraie base de données bien gérée.
Là c'est plus les systemes de gestion de paquets que tu jettes à la poubelle, c'est tout ce qui utilise une BdD...
«Le systeme de la slack est honnetement le plus fiable a l'utilisation»
Pourquoi ?
(Je veux bien te croire, j'ai été utilisateur de Slackware, mais au moins explique pourquoi. Je considère que ton "incassable" n'est pas un argument vu que la base de paquets de slack c'est aussi une base de données :-)
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 0.
Et bien si tu connais effectivement ce que c'est, tu n'as pas besoin de connaitre autre chose. Si tu as vraiment des probleme, tu regardes la description du paquet (slack-desc):
libxml2: libxml2 (XML parser library)
libxml2:
libxml2: XML parser library. This is required by GNOME and KDE.
Primo, tu desinstalles pas des bibliotheques tous les jours (enfin...). Deuxio, tu es sense savoir un peu ce que tu fais quand tu vires des trucs. Tertio, si tu as la memoire qui flanche, 'head /var/log/packages/nomdupackage' .
C'est vrai que si tu as une distrib avec 2000 paquets d'installe, tu ne dois pas etre habituer a voir les choses simplement.
Les dépendances ne résolvent pas tous les problèmes, donc elles ne servent à rien ?
Heu... relis le debut de ma phrase pour eviter de dire des aneries:
Donc dans ce cas, la gestion des dependances est inutile
Pour montrer que les dépendances sont inutiles, tu expliques qu'elles sont mal faites
Hum...Tu ferais bien de vraiment relire mon poste, j'ai ecrit:
les gestions sont souvent mal ficelees avec les rpms ou deb
S'il-te-plait, arrete d'ecrire que je trouve les dependances inutiles. J'ai simplement pointes des problemes precis concernant leur utilisation via rpm ou deb et le fait qu'elle soient tres souvent inutiles, voire dangereuses. Tu m'accuses de parti pris, apparemment. Moi j'aimerais voir un peu plus de rigueur dans tes commentaires.
Sais-tu que l'on peut faire une distinction entre dépendances requises et optionelles ?
Ah bah si on peut alors, le monde est sauve. Montre moi un exemple pour voir ce que ca donne en pratique. Parce que moi j'ai utilise dselect pour la knoppix (copier sur le hd) et la reponse c'etait tout ou rien. Peut-etre que je suis trop ignorant pour utiliser les gestionnaires de packages ? Pourtant, c'est sense etre simple...
Moi j'installe tout, donc pas de problèmes de dépendances
Bah, oui pas de probleme. Et il ne manque jamais rien. On en a pour son argent ;-) Je confirme que fractionner les paquets, a cause des dependances, pose plus de probleme qu'autre chose. Combien de fois a-t-on vu des newbies se faire repondre "forcement, ca marche pas, il faut truc-dev ou machin-lib". C'est plus simple ?
[...] ton système de fichier [...]
Hors-sujet
Le truc c'est que ça n'a quasiment aucune raison de planter
Tu es serieux ? Parce que la ta credibilite vient d'en prendre un coup.
http://www.google.com/search?q=rpm+corruption(...)
Là c'est plus les systemes de gestion de paquets que tu jettes à la poubelle, c'est tout ce qui utilise une BdD...
Tout depend de la DB, mais ceci n'est qu'un probleme parmi tant d'autres. Utiliser une DB pour gerer la base du systeme, ca me parait dangereusement complique. Peut-on installer une distrib RPM sans la DB ?
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 2.
>
> http://www.google.com/search?q=rpm+corruption(...(...))
Depuis quand une recherche sur google devient un argument ?
> Tout depend de la DB, mais ceci n'est qu'un probleme parmi tant d'autres.
> Utiliser une DB pour gerer la base du systeme, ca me parait
> dangereusement complique. Peut-on installer une distrib RPM sans la DB ?
Non. Maintenant, les db, ça sert à plein de choses. Tu doit sans doute savoir que ta banque utilise une db pour tes comptes, ça me semble bien plus dangereux pour toi que ton argent depende d'une base de données, plutot que la liste des softs de ton pc.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 1.
Moui, les corruptions de DB, c'est vraiment une idee surfaite, c'est sur. Dommage, google renvoyait beaucoup d'exemple montrant les dangers de l'utilisation d'une DB rpm mais apparemment, ce n'est pas un argument recevable.
Non. Maintenant, les db, ça sert à plein de choses. Tu doit sans doute savoir que ta banque utilise une db pour tes comptes, ça me semble bien plus dangereux pour toi que ton argent depende d'une base de données, plutot que la liste des softs de ton pc.
Tu compares deux choses non comparables. Ce n'est pas parce que c'est moins dangereux que ce n'est pas dangereux. Et l'obligation d'utiliser la DB est pour moi une serieuse limitation. Pense que la slack c'est une LFS avec des tonnes de scripts bien rodes. Il n'y a pas plus flexibles et stable et il n'y a pas de soucis de perennite avec la gestion des packages. J'aurai du le dire avant d'ailleurs, c'est un argument important.
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . Évalué à 2.
C'est profondément ridicule. Je sais très bien à quoi sert libxml1, en quoi est-ce que ça me permet de savoir si j'ai des logiciels qui l'utilisent ?
J'ai environ 1500 paquets installés sur ma machine perso, je suis censé me souvenir des dépe^Wbibliothèques utilisées par chacun d'entre eux ? Non merci :-)
«C'est vrai que si tu as une distrib avec 2000 paquets d'installe, tu ne dois pas etre habituer a voir les choses simplement.»
Si pour toi, voir les choses simplement, c'est savoir ce que chaque programme utilise comme bibliothèques, je ne vois certainement pas les choses simplement :-)
«S'il-te-plait, arrete d'ecrire que je trouve les dependances inutiles.»
Moi c'est l'impression que me laisse ton post même après re(re)lecture.
«Tu m'accuses de parti pris, apparemment.»
Non je t'accuse de raconter n'importe quoi, c'est pas pareil. Tu peux très bien être convaincu du bien fondé de tes arguments :-)
«Ah bah si on peut alors, le monde est sauve. Montre moi un exemple pour voir ce que ca donne en pratique.»
Et voilà, la dérision pour contourner l'argument, merci pour cet exemple de rigueur.
Remise dans le contexte: tu reproches que certaines dépendances ne sont pas requises, car le logiciel fonctionne sans. Je te dis qu'effectivement, on peut définir des dépendances non-requises, sans lesquelles le logiciel s'installe et fonctionne. En effet, "le monde est sauvé", ton problème n'en est pas un. Qu'est-ce que tu ne comprends pas là dedans ?
Je te donne un exemple que j'ai rencontré hier, puisque c'est trop abstrait: si tu installes libsoap-ruby, tu obtiens de quoi faire du SOAP en ruby. Cette bibliothèque n'exige pas que tu possèdes webrick (une bibli pour faire un serveur web en ruby), mais si tu la possèdes, alors tu as accès à plus de fonctions de libsoap-ruby.
C'est bien ce dont tu parlais non ?
«Je confirme que fractionner les paquets, a cause des dependances, pose plus de probleme qu'autre chose.»
Je confirme le contraire, et on est bien avancés...
«C'est plus simple ?»
Oui, sauf si tu t'amuses à faire la gestion des dépendances à la main. N'importe quel système bien foutu les gère à ta place, et donc installe ce dont le paquet a besoin. Pas de "ça marche pas, il faut libtruc-machin" si les paquets sont bien faits (et ils doivent l'être vu que je n'ai pas encore eu de problèmes depuis que j'utilise ma debian).
«Hors-sujet»
Certainement pas, analogie. Ton système de fichier est une base de données, s'il casse tu es mal. Un système de gestion de paquets utilise une base de données, s'il casse tu es mal (mais beaucoup moins).
En suivant ton raisonnement, il est dangereux d'utiliser un système de fichier. C'est absurde donc ton raisonnement est faux.
Si c'est moi qui me trompe, merci de m'expliquer pourquoi avec autre chose qu'un Hors-sujet.
«Tu es serieux ? Parce que la ta credibilite vient d'en prendre un coup.»
Tout à fait. Si les bases RPM plantent c'est dommage (jamais vu, mais je fais confiance à google), par contre ta généralisation est abusive. Partir d'un exemple d'un truc foireux pour démontrer que tout est foireux, c'est comme dire que l'informatique ça plante parce que Windows ça plante.
Il y a des tas d'application qui utilisent des bases de données et qui ont besoin de fiabilité, alors si tu peux démontrer que les BdD c'est pas fiable, tu vas révolutionner l'industrie de l'informatique, je tiens à te prévenir :-)
Le truc que tu as coupé dans ce que je dis, c'est aussi qu'un plantage de la BdD de gestion des paquets, ça ne casse pas le système. Ça peut être assez lourd à reconstruire, mais le système continue de tourner sans s'en préoccuper. C'est juste genant quand tu veux installer un nouveau paquet. Alors qu'un plantage de la base de registres de Windows, c'est le système qui ne boot plus.
«Peut-on installer une distrib RPM sans la DB ?»
Je ne vois pas l'intérêt, mais oui, un RPM ce n'est qu'un paquet semblable à ceux de Slack avec en plus des infos de dépendances. Déjà, si tu n'aimes pas les dépendances, tu peux forcer l'installation sans vérification. Ensuite, si tu n'aimes pas la BdD tu peux utiliser le RPM comme un .tar.gz, mais ça ne sert à rien. Autant prendre les .tar.gz.
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 3.
As tu administré une série de serveur Linux avec une spécificité différente pour chacune (l'un fera du mail, l'autre serveur de fichier, un autre web etc etc) ?
Pour le reste, je doute que le jour ou tu administrera un park d'une centaine de serveurs tu tienne le même discours... ;-)
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à -1.
Ah ? RPM/deb est indispensable ?
Quelle malheur pour tous ces serveurs slackware dont les administrateurs souffrent le martyre. Encore un argument tres fort pour la gestion automatique des dependances.
Si tu es administrateur, j'ose espere que tu fasses plus confiance a tes scripts perso qu'a une methode automatique et que tu ne fais pas des mises a jours tous les trois jours.
le jour ou tu administrera un park
Risque pas, j'aime pas Disneyland
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 3.
Et bien disons que c'est comme de faire Paris Marseille, une voiture n'est pas indispensable, on peut très bien y aller en roller, je ne contredis pas du tout ce point.
Quelle malheur pour tous ces serveurs slackware dont les administrateurs souffrent le martyre.
J'aimerais connaitre le nombre de parc serveur conséquent entièrement en Slackware.
J'aimerais savoir si Slackware permet de :
- Effectuer une installation automatique en 3 mouvements, 3 secondes, dépendemment du type de serveur à installer et du hardware.
- Effectuer un mirroir interne à des fin d'économie de bande passante mais aussi de temps de téléchargement à l'installation.
- Compiler ses propres packages et les installer/upgrader de façon automatique via le système de gestion de package
- Installer en 3 secondes tout logiciels sans avoir à chercher les dépendances.
- Construire un package du kernel et l'installer automatiquement sur tout un ensemble de serveurs
Tout ça, non seulement c'est possible avec Debian, mais en plus c'est faisable sans devoir écrire une ligne de code. Et tout ça, lorsque l'on administre un parc de serveurs conséquent sous Linux, c'est vraiment très pratique mais effictivement, ce n'est pas indispensable).
Si tu es administrateur, j'ose espere que tu fasses plus confiance a tes scripts perso qu'a une methode automatique et que tu ne fais pas des mises a jours tous les trois jours.
Je ne fais confiance à rien, j'ai écrit moi même les applications que j'utilise, du serveur web au shell. J'aime réinventer la roue, j'aime passer mon temps à écrire des scripts de gestion alors qu'il en existe déjà, bien plus rodé que les miens et souviens bien plus complet que les miens.
Risque pas, j'aime pas Disneyland
Vu ta vision de l'administration de serveur, j'ai plutôt l'impression que tu aime le burlesque :-)
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 0.
Ce qui suit est un vilain troll Slack/Debian qui montre une meconnaissance assez eleve du systeme donc je saute vers le sujet du thread
Compiler ses propres packages et les installer/upgrader de façon automatique via le système de gestion de package
Compiler un package sans ecrire une ligne de code je demande avoir. Le systeme choisi lui-meme les tags et les variables d'environnement ? Pour slack, tu changes les tags dans le script fourni avec les sources et tu lances. Je vois difficilement plus difficile
Installer en 3 secondes tout logiciels sans avoir à chercher les dépendances.
J'espere que tu n'installes pas "tout logiciel" sur un serveur. En ce qui concerne la slack, les logiciels sont tous coherents et classes par categorie. Pour un logiciel externe, tres souvent il faut compiler. Trop dur pour un administrateur de savoir quoi faire ?
Ton argumentation m'amuse beaucoup car tu nous prend l'exemple d'une installation, avec Debian, sur des serveurs. Chose que bien entendu, on fait tout les jours en temps limite et sans aucune connaissance du shell ou d'idee sur les logiciels et dependances que l'on installe.
Ca montre surtout les dangers de la gestion des dependances. On peut tres vite faire n'importe quoi par pure paresse et on n'est jamais completement maitre de son systeme.
Je ne fais confiance à rien
A mon avis, tu n'es pas encore assez parano. A ta place, je me ferai ma petite distro perso adaptee a ma boite base exclusivement sur les sources des softs officiels avec un systeme de package a la slack. Rigole pas, c'est tres serieux, et ca ne prendrai pas tellement de temps si tu n'as pas 2000 softs ;-)
j'ai plutôt l'impression que tu aime le burlesque :-)
C'est toi qui a commence, non :-)
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 2.
Ce qui suit est un vilain troll Slack/Debian qui montre une meconnaissance assez eleve du systeme donc je saute vers le sujet du thread
Histoire de bien recentrer la discution, loin de moi l'idée de vouloir dire "Debian c'est mieux que le reste du monde" ou "le système de dépendance c'est mieux que le reste du monde", j'essaye simplement de dire que quotidiennement un Linux basé sur un système de dépendances est plus agréable/rapide à administrer sur un nombre conséquent de serveurs.
Compiler un package sans ecrire une ligne de code je demande avoir.
Remplir un fichier texte de valeurs concernant la version, l'auteur du packages et autre, ce n'est pas coder.
Le systeme choisi lui-meme les tags et les variables d'environnement ? Pour slack, tu changes les tags dans le script fourni avec les sources et tu lances. Je vois difficilement plus difficile
Plus simple tu voulais dire ?
Tout à fait.
Sauf que tu répond à une parti de ma ligne en passant sous silence le reste : "et les installer/upgrader de façon automatique via le système de gestion de package". J'aurais même du préciser sur tout un parc de serveurs.
J'espere que tu n'installes pas "tout logiciel" sur un serveur.
C'est une tournure de phrase, pour expliquer plus simplement, si j'ai besoin d'installer un soft, je n'ai pas envie et pas besoin d'avoir à chercher et installer les dépendance y z et j'en passe. Sans compter bien sûr que la démarche est plus longue et fastidieuse sur un linux qui ne gère pas les dépendances.
Un apt-get install "Soft X" sera toujours plus rapide est simple qu'une installation avec recherche et installation de toutes les dépendances. Et je ne parle même pas de la gestion des conflits. Ni même du respect de l'architecture sous Debian (les fichiers de config sont toujours au même endroits), ni encore la gestion de groupes (comme par exemple la désinstalation automatique dun MTA lors de l'installation d'un autre.
En ce qui concerne la slack, les logiciels sont tous coherents et classes par categorie.
Je n'ai jamais remis cela en cause.
Pour un logiciel externe, tres souvent il faut compiler
C'est bien là que ce situe le gros problème...
Trop dur pour un administrateur de savoir quoi faire ?
Ce sera toujours plus difficile qu'un apt-get install. Alors pourquoi ce compliquer la vie ? Si c'est parceque tu aime compiler, soit, je n'ai rien contre et conçoit pleinement que la compilation puisse être un passe temps aussi agréable que la pêche. Sauf que lorsque l'on administre un parc de serveurs, on a sérieusement autre chose à faire de compiler un soft, chercher ses dépendances, compiler ses dépendances et tout cela dans l'hypothèse que tout se passe bien du premier coup, ce dont personnellement je doute pour de nombreux obscure programmes. Et bien sûr, ne parlons même pas de la mise à jours...
Ton argumentation m'amuse beaucoup car tu nous prend l'exemple d'une installation, avec Debian, sur des serveurs. Chose que bien entendu, on fait tout les jours en temps limite et sans aucune connaissance du shell ou d'idee sur les logiciels et dependances que l'on installe.
Vois tu, la encore tu parle et argumente sur un domaine que tu ne connais pas et sur lequel tu n'a jamais d'expérience.
Même si j'install 1 serveur durant l'année, je préfére le faire d'une façon optimal, simple et rapide. Passer du temps à chercher des dépendances, compiler, et installer ne m'amuse pas. Je préfére passer ce temps la à faire autre chose.
Bien sûr, dès que l'installation de serveurs devient régulière, que la configuration logiciel n'est pas toujours la même, on apprend vite à aprécier l'automatisation et à ne pas se prendre la tête.
Et oui, ça m'arrive d'installer des logiciels sans connaitres les dépendances, je n'aime pas remplir mon cerveau d'un savoir totalement inutile. Il existe au moins un très bon système de gestion de dépendance qui permet de décharger un administrateur de tout ce travail fastidieux (dans l'hypothèse ou contrairement à toi l'on a pas un seul ordinateur à administrer), alors pourquoi se priver ? Parceque ce n'est pas difficile ? Cela n'a jamais été un problème de difficulté de tâche fastidieuse.
Ca montre surtout les dangers de la gestion des dependances.
Tu ne montre rien du tout.
On peut tres vite faire n'importe quoi par pure paresse et on n'est jamais completement maitre de son systeme.
C'est un peu comme vouloir construire soit même sa voiture pour connaitre le moindre boulon, la façon dont il est serré et qui l'a serré pour oser la conduire. Irrémédiablement dans ta vie tu serra obligé de te reposer sur quelque chose que tu ne contrôle pas, fait par d'autres et il faudra irrémédiablement que tu leur fasse confiance. Mais cela ne veut pas dire donner aveuglement sa confiance, cela veut dire en connaissance de cause. Et en connaissance de cause, je donne ma confiance au système de package de Debian.
Pour le reste, si tu estime que c'est de la paresse que de vouloir se simplifier la vie, alors je présume que tu construis toi même ta voiture...
A mon avis, tu n'es pas encore assez parano. A ta place, je me ferai ma petite distro perso adaptee a ma boite base exclusivement sur les sources des softs officiels avec un systeme de package a la slack. Rigole pas, c'est tres serieux, et ca ne prendrai pas tellement de temps si tu n'as pas 2000 softs ;-)
J'aimerais beaucoup avoir un peu plus d'une année à y concentrer exclusivement. Mais ce n'est pas le cas. Et puis on en reviens à l'argumentation du système de package à la Slack, et tu sais bien que j'y suis opposé (à defaut d'avoir compris mon argumentation, tu ne peux tout de même pas l'ignorer :-)
C'est toi qui a commence, non :-)
Non non, regarde le premier commentaire de notre discution, il est de toi (qui répondait à un commentaire d'une autre personne).
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 0.
Et les flags ? Pourquoi dois-tu rentrer d'autres informations ? ce sont des sources modifiees ? Ca me semble plus long que de changer 3 flags dans :
ftp://ftp.slackware.at/slackware-9.1/source/a/bash/bash.SlackBuild(...)
installer/upgrader de façon automatique via le système de gestion de package
# upgradepkg --install-new *.tgz
Avec swaret, tu peux meme te faire un miroir local. Tous tes serveurs se mettront gentiment a jour tout seul. Et tu sais quoi ? C'est juste un script que tu peux lire et comprendre...
Alors pourquoi ce compliquer la vie ?
Pourquoi utiliser Linux ? Pourquoi compiler son kernel ? Pourquoi utiliser de l'open-source ? Utilise Windows 2003, c'est surement plus simple. Y a windows update. La question porte sur le controle
dans ta vie tu serra obligé de te reposer sur quelque chose que tu ne contrôle pas
Tes patrons, si tu en as, doivent se marrer. C'est une elegante maniere de rejeter la responsabilite sur les autres. Tu as un contrat de service avec Debian ? Qu'est-ce qui se passe si un deb foireux plante tes serveurs. Parce que la, apparement, ils plantent tous en meme temps si tu fais la mise a jour en simultanee. Ta boite va attaquer debian ? C'est pas serieux comme argument, en tant qu'administrateur, tu es sense maitriser ce que tu fais. Saipamafotesaidebian
je présume que tu construis toi même ta voiture..
J'ai plus besoin de ma voiture. Je n'etais pas responsable de son bon fonctionnement vis-a-vis de tiers (si on parle pas d'accident, l'exemple est pas terrible ;-). Donc si elle ne marche pas bien ca ne gene personne d'autre. Libre a moi d'en faire ce que je veux, ne pas ouvrir ou ouvrir. Dans un cadre professionnel, c'est different. Pense au garagiste. Si tu es aussi professionnel que tu semble vouloir l'etre, ton argumentaire m'effraie quelque peu.
avoir un peu plus d'une année à y concentrer exclusivement
Heu, si tu sais ce que tu veux, il te faut beaucoup moins que ca. Il y a tous les morceaux un peu partout
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
Avec swaret, tu peux meme te faire un miroir local. Tous tes serveurs se mettront gentiment a jour tout seul. Et tu sais quoi ? C'est juste un script que tu peux lire et comprendre...
Et ça va automatiquement mettre à jours toutes les dépendances ?
Ou est la différence avec un système de dépendance que tu décris tellement alors ?
Pourquoi utiliser Linux ? Pourquoi compiler son kernel ? Pourquoi utiliser de l'open-source ? Utilise Windows 2003, c'est surement plus simple. Y a windows update. La question porte sur le controle
Parceque tu crois que simplement en compilant ou en installant toi même toutes les dépendances tu crontrôle quoi que ce soit ?
Mais quand j'install un package et ses dépendances, moi aussi j'ai la liste de ses dernière et je sais donc ce qui est installé.
C'est une elegante maniere de rejeter la responsabilite sur les autres.
Il ne s'agit pas de rejeter la faute sur qui que ce soit, tu es exaspérant à ne comprendre que ce que tu veux vraiment comprendre (enfin tu le fais surement exprès).
Ce que tu essaye de me dire, c'est que lors d'un accident, vouloir rejeter la faute sur la voiture. Si celle ci est defectueuse, c'est effectivement de sa faute, si c'est une erreur de conduite, il n'y a pas à rejeter la faute sur qui/quoi que ce soit.
Moi, ce que désespérement j'essaye de te faire comprendre, c'est que contre l'argument "installer les packages à la main c'est mieux car je contrôle mon système" je te répond "que tu ne contrôle pas tout (par exemple relis tu les sources du package que tu install ?), et que donc il y a un momment ou tu dois compter sur certainne chose". Quand tu install un Kernel, tu compte irrémédiablement sur celui ci. Quand ton patron te dit de faire quelque chose, il compte sur toi. Et j'espere pour toi qu'il ne controle pas tous tes faits et gestes (sinon je te pleins). Et si, dans l'accomplissement de ton travail tu te plante, et bien c'est de ta faute. Si un serveur plante, que c'est parcequ'un soft est mal écrit, que son upgrade s'est mal passé, c'est de la faute du système/soft, et si ça se produit trop souvent, ce sera de ma faute d'avoir choisi un système non fiable.
Concernant la mise à jours des serveurs, tout se passe, bien évidemment après test sur un serveur à part, mais tu semble associé "se compliquer la vie à vouloir connaitre tout les softs installer sur un serveur" et irresponsabilité.
en tant qu'administrateur, tu es sense maitriser ce que tu fais.
Justement, que ce passe t il le jours ou tu install un soft buggué ? Ne me dit pas que tout les softs de la Slackware sont bugless. Et ne me dit pas non plus que tout les softs installé a partir de sources sont bugless. Et la non gestion de dépendance d'apporte quoi la dedans ? A part te compliquer inutilement la vie, rien...
Donc si elle ne marche pas bien ca ne gene personne d'autre
C'est clair que le jour ou ses freins lâches, que tu fais une embardé sur la route et fauche une petite fille, ça ne gêne personne.
Tu es aussi le style de personne à penser que conduire vite n'implique que toi ?
Si tu es aussi professionnel que tu semble vouloir l'etre, ton argumentaire m'effraie quelque peu.
Bof, vu que tu comprend tout de travers, je pense que tu t'effrais tout seul pour un rien.
Heu, si tu sais ce que tu veux, il te faut beaucoup moins que ca. Il y a tous les morceaux un peu partout
Ah ben oui mais je ne contrôlerais alors pas ce morceau.
Si après dans un des morceau il y a une faille ou un problème, mon patron risque de m'engueuler. Alors moi, je préfére TOUT faire moi même, c'est mieux, je contrôle.
En fait si je résume, tu ne veux pas d'une gestion de packages parceque tu ne contrôle pas ton Linux, mais tu veux bien te baser sur d'autres élèments, même si tu ne les contrôle pas. Donc en fait, le plus critique dans un Linux pour toi, c'est son système de package ? Si tu ne contrôle pas le Kernel, peut importe, s'il est buggué, remplis de faille, peut importe car ce n'est pas critique ?
Tu accepte de remettre ton sors aux mains d'un concepteur de Kernel mais pas d'un système de package...
Je ne sais pas si tu es au courant, mais il y a eu d'avantage de failles critiques découvertes dans le Kernel que dans le système de package de Debian, Mandrake ou Suse additionné.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 1.
Il y a un support (partiel ?) des dependances
Ou est la différence avec un système de dépendance que tu décris tellement alors ?
Tu as le choix de ne pas l'utiliser et ce n'est pas une usine a gaz.
tu crois que simplement en compilant ou en installant toi même toutes les dépendances tu crontrôle quoi que ce soit ?
Je controle l'implementation et l'adaptation.
tu ne contrôle pas tout
Bravo. Mais avec une gestion des dependances tu as moins de controle. C'est indubitable.
tu install un soft buggué
C'est effectivement pareil dans les deux cas. Mais les bugs RPM ou deb, dans slack on les a pas :-)
C'est clair que le jour ou ses freins lâches, que tu fais une embardé sur la route et fauche une petite fille, ça ne gêne personne.
Tu es aussi le style de personne à penser que conduire vite n'implique que toi ?
C'est ridicule d'associer de telles propos. On ne parle pas de vie ou de mort. C'est pour ca que j'avais explicitement mis le cote accident a part car il n'est pas transposable, bien evidemment. C'etait probablement trop subtil...
Dommage, changeons d'exemple, on va prendre un frigo. Pour un particulier, il peut demonter ou non. Pour un professionnel, il doit savoir reparer autrement que simplement en telephonant au specialiste de la marque. Il doit savoir ce qui se passe precisement, sinon, c'est de l'incompetence.
Ah ben oui mais je ne contrôlerais alors pas ce morceau.
Heu, je parle de doc, de script. Rassure-moi, tu as deja monte une LFS/BLFS ou un Linux embarque ? Pour les sources, tu as l'embarras du choix, derniere version, version de debian stable etc. Avec un systeme de mise a jour, ce n'est pas un probleme.
tu ne veux pas d'une gestion de packages parceque tu ne contrôle pas ton Linux
Je suis contre le fait d'imposer l'utilisation d'un systeme de dependance, non portable et soumis a faille. On parle bien ici de choix et de leur consequence. Je n'ai pas choisi un systeme libre pour me voir imposer un systeme plus ou moins standard pour gerer le systeme quand des alternatives simples, je dirais meme unixiennes, existent.
il y a eu d'avantage de failles critiques découvertes dans le Kernel que dans le système de package de Debian, Mandrake ou Suse additionné
Il y a eu combien de faille dans les pkgtools ?
[^] # Re: éternel dilemne
Posté par Anonyme . Évalué à 2.
Ha bon, un cuisinier doit savoir réparer tout seul un frigo sinon c'est un incompetent ?
Et je vois pas trop le rapport en fait :)
Je suis contre le fait d'imposer l'utilisation d'un systeme de dependance, non portable et soumis a faille. On parle bien ici de choix et de leur consequence. Je n'ai pas choisi un systeme libre pour me voir imposer un systeme plus ou moins standard pour gerer le systeme quand des alternatives simples, je dirais meme unixiennes, existent.
Ou est ce que tu as vu que le système de package t'est imposé ?
Tu peux très bien compiler et installer quelques programmes à partir des sources, apt-get ne t'est pas plus imposé sur une debian que swaret sur une slackware.
Il y a eu combien de faille dans les pkgtools ?
Quel rapport ?
Ce qu'il te dit, c'est que tu acceptes sans controle le noyau Linux, dans lequel des failles sont trouvées de temps en temps, mais que tu refuses de faire confiance à un système de packages qui n'en a quasiment jamais.
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 2.
uhuhuh :-)
Je controle l'implementation et l'adaptation.
On tourne en rond.
Bravo. Mais avec une gestion des dependances tu as moins de controle. C'est indubitable.
Non, tu n'a pas moins de contrôle, simplement tu te repose sur un système d'automatisation, mais sur Debian, tu peux contrôler tout les packages que tu install en gardant le système de dépendance. Tu peux même les scruter pour savoir quels sont les fichiers installé. Simplement tu n'es pas obligé de le faire, si par exemple tu estime que tu peux tranquillement te reposer sur un système fiable.
C'est effectivement pareil dans les deux cas. Mais les bugs RPM ou deb, dans slack on les a pas :-)
Une question de statistiques, sur 100 packages, tu as clairement des chances d'avoir un nombre de bug moins élevé que sur 15000 packages.
Pour le reste on en revient à ce que tu aime te compliquer la vie par goût, ce qui ne me dérange pas, mais essayer de le justifier en prétendant que le système de Debian n'est pas fiable dénote une complète méconnaissance du système et une complète absence d'expérience de l'administration d'un parc de serveurs conséquents.
J'ai beau essayer de te l'expliquer, ça ne passe pas, alors tant pis.
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . Évalué à 3.
Ah mince, moi à la lecture il m'avait semblé voir une question plutôt qu'une affirmation. Étonnant que tu confondes, tu sembles bien calé niveau affirmations.
«qui montre une meconnaissance assez eleve du systeme»
Amusant de voir à quel point le bas niveau de tes interlocuteurs te permet d'éviter de répondre :-)
«Chose que bien entendu, on fait tout les jours en temps limite»
Sous prétexte que les tâches d'administration ne se font pas tous les jours, on devrait les rendre plus fastidieuses ? Je ne pense pas.
Effectivement ce que dit le monsieur au dessus est pertinent. Tu me disais ailleurs que je devais pouvoir mémoriser moi même les dépendances entre logiciels (ne pas effacer telle lib si elle est requise ailleurs), car il faut "savoir ce qu'on fait". Mais si tu administres un paquet de machines différentes, tu dois aussi tout mémoriser pour chacune d'entre elles ? Savoir que la libtruc est requise sur la machine 42, mais pas sur la machine 36 ?
[^] # Re: éternel dilemne
Posté par Vincent P (site web personnel) . Évalué à 2.
Tous tes arguments sont retournables en faveur d'un systeme de gestion de dependances.
La gestion automatique des dependances n'empeche pas de faire des conneries, elle les limite cependant. Essaie de supprimer un composant essentiel au systeme sous deb et tu verras que tu auras ete prevenu que tu allais faire une betise.
Globalement ton argumentation est bonne si elle part du principe que les dependances entre les paquets sont mal faite, ce que tu as l'air de croire pour Les distribs debian et les autres basees sur RPM. Je pense que ce n'est pas le cas, et pour debian a mon avis c'est justement une des tres grande force de cette distribution. Les paquets et leurs dependances sont de grande qualite.
Il y a egalement des categories de paquets (base par ex. pour les composants essentiels). Les dependances circulaires je me souviens pas en avoir vues, et c'est tres rapidement corrigé en général. Il y a aussi dans les dependances la notion de paquets suggeres qui est interessante et qui compense en partie le fractionnement des paquets (on peut demander d'installer automatiquement les paquets suggeres). De plus ce n'est pas parce qu'on a de l'espace disque qu'on doit le remplir de choses inutiles notamment sur toutes les machines qui ne sont pas des postes de travail ( serveurs, embarqué, applications spécifiques...)
Concernant l'aspect base de donnée de paquets je ne vois absolument pas en quoi ca pose probleme. C'est juste une maniere de stocker les informations sur les paquets. Que ce soit une bdd ou des simples fichiers ca revient strictement au meme, sauf que la base de donnee sera certainement plus efficace. Il n'y a pas de raison pour qu'une base de donnée soit plus corrompue que les simples fichiers textes. Et la base de registre windows n'a strictement rien a voir avec ça.
Enfin pour revenir sur debian, quand tu sais utiliser les quelques commandes de gestion de paquets, tu peux amha faire difficilement plus simple pour installer/desinstaller des logiciels facilement. Sans compter que c'est déployable, automatisable...
Bref si ton post est un troll il est de qualité, sinon il risque fort de ne convaincre personne.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à -1.
Donc ca depend de la qualite des dependances ? C'est pas tres rassurant de savoir qu'une dependance ne peut pas etre parfaite et pour le coup c'est un tres bon argument contre son utilisation. Une distribution qui ne les gere pas sera toujours parfaite dans ce cadre.
Mon point de vue est qu'il vaut mieux ne pas gerer les dependances plutot que de prendre le risque de mal les gerer (ce qui est malheureusement frequent, GETA).
les machines qui ne sont pas des postes de travail ( serveurs, embarqué, applications spécifiques...)
Les sytemes rpm/deb sont a vise generaliste, c'est clair. Pour un serveur ca passe mais tu ne va quand meme pas nous faire croire qu'on installe une DB pour faire de l'embarque :-) C'est l'equipe uClinux qui va etre contente. Il faut etre serieux. Meme les applications specifiques sont rarement bases sur un systeme de dependance generaliste, c'est pas logique d'ailleurs.
Il n'y a pas de raison pour qu'une base de donnée soit plus corrompue que les simples fichiers textes
Je repete ce que j'ai ecrit plus haut:
Un unique binaire modifie est moins stable qu'un fichier ascii modifie parmi plusieurs. Qu'est-ce qui se passe si ton systeme plante a l'installation d'un logiciel ? Sur slack, tu le reinstalles, c'est tout. Il remplace le fichier texte. Sur une distrib avec RPM/deb ?
Sans compter que c'est déployable, automatisable..
Comme tout systeme scriptable et surtout flexible. Je ne vois pas de difference avec la slack a part peut-etre qu'il faut utiliser un peu plus ces neurones.
Sinon, merci pour ce post, il sort du lot par sa pertinence.
[^] # Re: éternel dilemne
Posté par Vincent P (site web personnel) . Évalué à 2.
Et bien evidemment il n'y a pas de systeme parfait, sinon slackware n'existerait meme pas. Il y a juste des systemes meilleurs que les autres ( suivez mon regard ). Et une distribution qui gere bien les dependances (mais peut etre pas parfaitement effectivement, un bug par mois est possible...) sera toujours meilleur que pas de systeme du tout. Du moins pour celui qui s'est rendu compte que le silex n'est pas l'outil le plus efficace qui soit...
Mon point de vue est qu'il vaut mieux ne pas gerer les dependances plutot que de prendre le risque de mal les gerer (ce qui est malheureusement frequent, GETA).
Tu parles de frequence, montre moi les chiffres, les exemples, moi je suis pas d'accord. J'ai tres rarement eu de problemes en debian sid, qui rappelons le est tout de meme appellee "unstable".
Concernant les bases de données, apprends ce que c'est, a quoi ca sert et comment c'est utilisé et on en reparle.
Sous deb, si ca plante a l'install d'un logiciel (ca arrive, notamment dans les scripts post/pre install), ca ne corrompt pas la base de donnée. Ca ne m'est jamais arrivé d'ailleurs ca, et il existe des outils pour récupérer/réparer la base. Tu t es deja demande pourquoi les bases de données sont utilisées dans une foultitude d'application a la place des fichiers texte ?
Sur la scriptabilité (ouch barbarisme), la difference avec la slack doit tenir en environ un petit millier de lignes de perl a écrire. Si t'as que ca a faire pourquoi pas... (cf la roue, la réutilisation, tout ca...)
Merci pour le compliment, mais je suis pas sur que tu aies tout saisi.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à 0.
L'humanite a commence avec un silex. C'est a partir de ca que l'on a fait tout le reste. Aujourd'hui, je ne connais personne capable de faire un trou dans un silex comme les anciens faisaient. En cas de guerre atomique, on fait comment ;-)
Serieusement, releguer la slack au silex c'est du troll pur jus.
Ca me fait penser a des posts de Windowsiens qui critique Linux parce que c'est "moche et complique, prehistorique".
[...]sera toujours meilleur[...]
Purement subjectif.
Tu parles de frequence
C'est toi meme qui a parler de qualite variable, pas moi. J'ai pas lance de sondage pour mesurer mais si tu ne connais pas un seul cas de corruption de DB, je serai dubitatif.
ca ne corrompt pas la base de donnée
Tu as de la chance
la difference avec la slack doit tenir en environ un petit millier de lignes de perl a écrire
Tu peux installer dpkg sur slack. Tu peux installer rpm sur slack. Tu peux tout virer. Bref, tu as le choix et c'est le plus important. Sur les distribs RPM/deb on t'impose un systeme qui n'est pas sans faille. Tu vois le probleme ?
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . Évalué à 3.
Je suppose que tu voulais dire "peut ne pas etre parfaite", et je répondrais en ce sens: une dépendance peut ne pas être parfaite comme un logiciel peut ne pas être parfait. Je ne me refuse pas le droit d'utiliser des logiciels faits par d'autres sous prétexte qu'ils peuvent ne pas être parfaits. Idem pour les paquets avec gestion des dépendances.
D'autant plus qu'une dépendance foireuse est presque sans conséquences. Au pire ça installe des choses en trop, sinon tu dois installer la dépendance toi même (comme avec un système sans gestion des dépendances donc).
Si on était constamment confrontés à des paquets foireux qui refusent de s'installer à tort, je ne dis pas, mais j'ai dû rencontrer un paquet foireux en deux ans d'utilisation de Debian unstable. Comparé au temps que j'ai gagné à ne pas aller télécharger tous les paquets à la main...
[^] # Re: éternel dilemne
Posté par Éric (site web personnel) . Évalué à 2.
> Ca n'empeche pas les betises.
Rien n'empêche les bétises de l'utilisateur, mais ça ne veux pas dire que c'est inutile de les limiter.
> (desinstalle lilo ou le bash qu'on rigole). RPM va-t-il se plaindre ? Donc dans ce
> cas, la gestion des dependances est inutile. Ca n'empeche pas les betises.
moi ça me répond "La désinstallation du paquetage basesystem-10.0-0.2mdk.i586 rendra votre système instable"
Bon, on peut arguer que bash n'est pas indispensable en théorie et qu'il suffit de laisser un bête sh mais ça c'est l'orientation de la distrib d'utiliser du gros soft fonctionnel ou du minimum. Toujours est-il que le système de paquet fonctionne comme il faut.
> J'ajoute que sur la slack, les logiciels sont regroupe en serie
Et ? sur ma mandrake aussi j'ai des catégorie (sisi).
> Quand j'installe A, j'estime normal d'avoir tout A.
Moi quand j'installe A j'attend d'avoir automatiquement tout ce qui est nécessaire à A, rien de plus rien de moins. (non, je n'aime pas avoir à "connaitre" un soft de type OOo pour savoir de quelles libs il a besoin).
Si je peux exécuter et utiliser A sans une partie des fichiers ça ne me gêne pas que ça ne soit pas installé.
> Enfin, une base de donnee qui plante pose souvent de serieux problemes et
> met en jeux la sanite de tout le systeme. Je suis desole de choquer mais cela
> me semble tres similaire a la base de registre de Windows. Ca ne me semble
> pas solide comme methode.
C'est connu, c'est pas solide une db, tous des cons ceux qui utilisent des bases de données alors qu'on peut tout mettre dans des fichiers textes. Quand ton fichier texte est corrompu il se passe exactement la même chose qu'avec ta db. Dans les deux cas une sauvegarde règle le pb, et dans les deux cas si un soft est mal foutu il peut te corrompre ton bordel (fichier ou db, peu importe).
> Le systeme de la slack est honnetement le plus fiable a l'utilisation meme si ce
> n'est pas forcement le plus simple du point de vue utilisateur (quoique...).
Pourquoi "plus fiable" ? là tout ce que je vois ce sont des choses qu'il gère "en moins", rien qu'il gère "en plus". La liste des fichiers utilisés par un paquet je l'ai aussi sur ma debian ou ma mandrake
> PS: Tu as oublie Fedora dans ta liste.
J'en ai oublié plus que ça, je n'ai pas pour objectif d'être exhaustif.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . Évalué à -4.
il y a des --nodep et --force.
Je demande a voir la coherence de ton systeme apres plusieurs actions comme celle-ci. Ca ne regle rien. Le probleme est que la DB est necessaire, c'est la base de la distro et c'est bien le probleme.
La désinstallation du paquetage basesystem-10.0-0.2mdk.i586 rendra votre système instable
En general sous MDK, c'est plutot l'installation qui rend instable. Le message n'est pas clair, on ne sait pas quel est le probleme. C'est mieux que de pouvoir tout virer pour un newbie mais ca ne lui apprend rien.
sur ma mandrake aussi j'ai des catégorie
Tant mieux. Pour la slack c'est un moyen de garder un systeme coherent.
j'attend d'avoir automatiquement tout ce qui est nécessaire
Comme X quand tu installes Emacs (ah non, c'est Debian, ca) ?
Ne pas savoir ce qui se passe te semble rassurant ?
tous des cons ceux qui utilisent des bases de données alors qu'on peut tout mettre dans des fichiers textes
Donc tu preferes une base de registre a la windows plutot qu'un /etc rempli de fichier texte ? Pourtant, un /etc est bien plus complique qu'une liste de programme, y aurait de quoi faire une DB utile. Une distrib RPM, c'est surtout un bon moyen de limiter la portabilite contre la concurrence.
rien qu'il gère "en plus"
Si, le fait d'etre completement affranchi d'un systeme RPM et d'etre 100% portable. J'ajoute que RPM et dpkg peuvent etre installe sur slack mais ca sert pas souvent :-)
[^] # Re: éternel dilemne
Posté par Yusei (Mastodon) . Évalué à 3.
Là excuse moi mais c'est du foutage de gueule, un peu =)
Tu vantes les systèmes sans gestion de dépendances, et quand on te montre comment faire ça avec des RPMS, tu dis que le système risque de ne pas être cohérent...
La DB est nécessaire uniquement pour garder la liste des paquets installés, dans ce cas. De mémoire, il me semble que Slack se souvient aussi de la base des paquets installés.
«Comme X quand tu installes Emacs (ah non, c'est Debian, ca) ?»
Non:
http://packages.debian.org/unstable/editors/emacs21-nox(...)
[^] # Re: éternel dilemne
Posté par Éric (site web personnel) . Évalué à 2.
La même que celle d'une slack puisque ça revient uniquement à virer le système de dépendance que tu décries tant, rien d'autre.
> Ca ne regle rien. Le probleme est que la DB est necessaire, c'est la base de la distro et c'est bien le probleme.
Nécessaire pour quoi ? pour gérer les dépendances et conflits, mais comme toi tu ne veux pas les laisser gérer par l'outil ça n'est pas nécessaire du tout.
> En general sous MDK, c'est plutot l'installation qui rend instable.
Oh le joli troll, un argument, quelque chose de concret ou c'est juste un "moi j'utilise slack je suis plus fort" ?
> Le message n'est pas clair
Et c'est toi qui plus haut dis que le professionnel est sencé tout savoir de ce qu'il installe ? Sans avoir besoin de forcément connaitre toutes les dépendances de tous mes softs de tête, celui qui ne comprend pas ce message est bon pour la porte direct. Dire que "La désinstallation du paquetage XXX rendra votre système instable" n'est pas un message clair me parait tout de même être abusé.
> C'est mieux que de pouvoir tout virer pour un newbie mais ca ne lui apprend rien.
Pourquoi "pour un newbie" ? pour moi aussi, qui n'ai rien d'un newbie.
Ça ne lui apprend rien ? et alors ? faut voir que le but de la plupart des gens c'est d'utiliser le système, ou à la limite le rendre utilisable pour d'autres, pas d'apprendre. Moi j'ai arrêté gentoo le jour où j'ai constaté que je prenais plus de temps à configurer et gérer le système qu'à l'utiliser. Depuis je contrôle toujours autant mon système mais je ne m'emmerde plus pour ce que je n'ai pas envie de gérer. Apprendre ? ça n'entre pas en ligne de compte, apprendre je le fais si j'ai envie ou si j'ai besoin, je ne vais pas me compliquer volontairement la vie en permanence parce que des gens veulent apprendre.
> Ne pas savoir ce qui se passe te semble rassurant ?
Je peux savoir ... si je le veux. J'ai tout ce qu'il me faut pour savoir les dépendances, les fichiers utilisés ou modifiés ... j'ai même probablement plus d'infos que sur ta slack.
Par contre je suis honnête : je ne connais pas tout (et n'ai pas pour but de tout connaitre), je suis faillible, et je n'ai pas un temps infini à ma disposition. Je n'ai pas la prétention de faire forcément mieux que les X personnes qui gèrent la distrib et la testent en permanence.
Je fais globalement confiance à la distrib car je n'ai pas la prétention de faire ou connaitre mieux qu'eux ce qu'ils font. Maintenant ça ne m'empêche pas de vérifier si je veux, ou de gérer certaines choses à la main (les paquets qui sont dans mon domaine il y en a certains que je compile moi-même à la main).
Te crois tu tellement supérieur à tous les autres pour ne pas faire confiance à ta distrib ?
> Donc tu preferes une base de registre a la windows plutot qu'un /etc rempli de fichier texte ?
Qui parle d'une base Windows ? évites de troller.
On parle d'un coté d'une db avec une structure tout à fait connue, qui gère tout ce qu'il faut de manière efficace et correcte, pas d'un format non documenté.
Quand à la miriade de fichiers textes de /etc si je puis me permettre, c'est la dernière chose que je veux : tous dans des formats différents, avec des syntaxes différentes, des noms d'option différents ....
> Une distrib RPM, c'est surtout un bon moyen de limiter la portabilite contre la concurrence.
Le format RPM est tout à fait documenté, non obligatoire. La db est une base tout à fait standard sous Unix, documentée, portable, extractible, manipulable ...
C'est largement aussi manipulable que ton fichier texte qui a "la syntaxe slack", donc finalement un format proprio (ben oui, que du texte, mais sous un format propre qu'il va me falloir mapper à la main).
Et puis un système de dépendance n'implique pas forcément une db. Gentoo se sert de fichiers textes aussi (même si sa base de dépendance est encore assez restreinte vu qu'elle ne gère pas les inverses) mais son outil a bien une gestion de dep. Il y a une DB là simplement parce que contrairement à ce que tu dis c'est ce qu'il y avait de plus pertinent pour gérer ce genre d'infos (et pas des fichiers textes dans un format proprio)
# Re: éternel dilemne
Posté par ckyl . Évalué à 1.
- On ne veut pas mettre a jour sa distrib mais on veut mettre a jour les logiciels ! Une distrib linux c'est juste un packaging de soft (plus ou moins :-)... Si tu rajoutes toujours des nouveaux softs a un mdk 9.1 qui sera donc toujours a jour quel serait l'interet pour mdk de sortir une autre version ?
- "Si la seule solution consiste installer la dernière version de ma distrib (la maj à partdes cds n'a jamais été réputée fiable), je me dit qu'il vaut autant mieux en profiter pour passer à autre chose qui me correspondrait mieux". Donc ta super solution c'est d'au lieu de mettre a jour une distrib (chose qui est censé être certifiée bien que mdk...) tu prèferes passer sur la version de developpement ! C'est clair que c'est super vachement plus sur :-)
Tout ce que tu fais la c'est que tu enleves l'idée de version en utilisant des versions de devel qui évoluent constament.
Bref tout ca pour dire qu'il faut savoir ce qu'on veut. Si on veut quelque chose de solide on utilise des versions stables ou les logiciels sont figés et quand une nouvelle version stable est la on met a jour.
Autrement on se risque a utiliser du devel et si ca casse... c'est un risque que l'on choisi de prendre.
Toute distrib sera comme ca a l'exception que les distribs sources passent plus facilement les mises a jour et tolère plus les mix entre version que les distrib binaires.
Voila tout ca pour dire que si tu changes pour utiliser sid tu ferais mieux de mettre a jour en cooker c'est la même chose.
Sur ce choisi bien ta nouvelle distrib :)
[^] # Re: éternel dilemne
Posté par Cyberdivad . Évalué à 1.
Le problème que je rencontre est que ma mandrake 9.1 est obsolète et qu'il devient de plus en plus difficile de trouver des logiciels packagés pour cette distrib là. Il est quand même un peu malheureux de se sentir forcé de réinstaller sa distrib uniquement parce qu'on souhaite profiter de quelques logiciels libres récents.
A mon sens, un des avantages des outils style rpm est (devrait être ?) quand même l'existence d'une base de données qui contient la liste de tout ce qui est installé sur le système ! Ce qui devrait permettre de faire tout ce qu'on veut (maj, réinstallation etc.) sans douleur et avec facilité.
Je n'ai pas dit que je souhaite une version de développement. Si j'ai la possibilité d'envisager une distrib avec laquelle il est possible de mettre à jour avec des logiciels (stables, comme gimp 2) sans se casser la tête, tant mieux ! installer gimp 2 à partir des sources, je n'aurais pas été contre, mais je pers progressivement l'intérêt du rpm avec chaque logiciel que j'installe comme ça. Ce qui est déjà un peu le cas car j'ai déjà du le faire, et la gestion de ma base rpm devient de plus en plus problématique, ce qui me broute passablement.
Ce que je souhaite est une distribution Libre que je peux garder plusieurs années si je veux sans la réinstaller à partir de zéro (ou gardant juste le /home) et en pouvant toujours installer des logiciels récents de temps en temps si ça me chante. Avec la mandrake, je constate justement que ça n'a pas vraiment l'air d'être le cas et que la solution consiste (justement encore) à passer par la case cooker.
Tu joue sur les mots entre mettre à jour sa distrib et ses logiciels. Bon, si tu veux, mais mon problème reste le même. Comment sur une mdk 9.1 installer tous les derniers logiciels stables comme gimp2 et gnome 2.6 en gardant l'utilité des rpms ?
[^] # Re: éternel dilemne
Posté par Jllc . Évalué à 2.
A mon sens, un des avantages des outils style rpm est (devrait être ?) quand même l'existence d'une base de données qui contient la liste de tout ce qui est installé sur le système ! Ce qui devrait permettre de faire tout ce qu'on veut (maj, réinstallation etc.) sans douleur et avec facilité.
Je connais le même problème. La solution que j'ai trouvé, c'est de créer les RPM moi mêmes à partir des sources. Je peux avoir des logiciles récents, mais je garde une base de données des RPM cohérente.
En fait, le problème vient de 2 choses :
- beaucoup de programmes profitent des dernières évolutions des librairies, forçant les utilisateurs à suivre cette même évolution.
- tous les programmes et bibliothèques sont développés indépendamment, et il y a tant de composants inter-dépendants, qu'il est impossible de figer une base commune sur laquelle évoluerait les logiciles.
Peut être qu'un jour suffisament de bibliothèques seront stabilisées dans les fonctionnalités et dans les bugs pour garder longtemps un même système, mais en attendant ...
[^] # Re: éternel dilemne
Posté par Anonyme . Évalué à 2.
C'est censé marcher sans trop de problèmes si on le fait comme il faut.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
> tu veux, mais mon problème reste le même. Comment sur une mdk 9.1
> installer tous les derniers logiciels stables comme gimp2 et gnome 2.6 en
> gardant l'utilité des rpms ?
Tu m'arrete ou j'ai mal compris, mais :
Tu veut mettre tout les paquets de gnome2.6 sur la 9.1.
Ok.
Quitte à faire pareil, on va faire suivre kde, ok, pour ceux qui veulent kde.
Bon.
Et puis, il y a surement des paquets qui vont dépendre sur python plus récent, on va mettre python. Et tout les softs qui dependent de python aussi. De toute façon tu as dit : "installer tous les derniers logiciels stables".
En bref, remettre à jour _tout_ les rpms, sur la 9.1, parce que en plus quelqu'un voudra surement un paquet plus à jour de tel soft. On va pas faire de jaloux, hein, parce que sinon, on a autant ne rien faire si on doit exclure certaines personnes, ça serait pas très égalitaire.
Mais euh, attends. C'est plus une 9.1, c'est une 9.2 ou 10 que tu va avoir si tu mets à jours tout les rpms.
Damn. Et oui, voila le truc.
SI tu veut , tu peut te refaire des backports. Si tu veut, tu peut même lancer un projet pour les redistribuer.
Je suis sur qu'en demandant à des groupes annexes à mdk ( en 3 lettres ) et en offrant ta bonne volonté et en ayant des idées et surtout de la bonne volontés, et que tu la mets en oeuvre, tu peut avoir un compte sur un serveur pour commencer à bosser et à chercher d'autres personnes pour t'aider.
Pour ma part, je trouve que les backports ne sont que sources de problémes, mais bon si tu arrive à prouver le contraire, je changerais d'avis.
[^] # Re: éternel dilemne
Posté par Erwan . Évalué à 3.
Et telecharger des ISOs, avec Debian, Gentoo ou encore *BSD on le fait une seule fois et on peut vivre des annees avec un systeme a jour en permanence sans maj brutale.
"mise a jour incrementale" n'a rien a voir avec "version de developpement", meme si les utilisateurs de Mandrake ont tendance a confondre (vu que pour eux, maj incrementale => cooker = devel).
[^] # Re: éternel dilemne
Posté par Jérôme FIX (site web personnel) . Évalué à 3.
Bon bien sûr elle se passe généralement trés bien, mais quand tous les logiciels sautent 4 ou 5 versions ca reste brutal !!
KDE 2.2.1 => KDE 3.2.1 : Ca ne se fera pas sans heurt ...
GNOME 1.4 => GNOME 2.4 non plus
Sinon concernant la MDK, moi je fonctionne une copie des RPMS de la version que je veux installer, je rajoute la source (urpmi.addmedia ....) et je fais un simple urpmi -v urpmi; urpmi -v --auto-select).
Et je passe de la version X à la X+1 sans plus de douleurs (sur un poste de travail, sur un serveur c'est sans doute trés différent.)
Jérôme.
[^] # Re: éternel dilemne
Posté par Erwan . Évalué à 1.
[^] # Re: éternel dilemne
Posté par Yann Hodique (site web personnel) . Évalué à 3.
Non, il suffit d'ajouter les sources urpmi contenant les paquets à jour. Évidemment il s'agit souvent des sources officielles des distributions suivantes, ce qui n'est pas un problème en soi. Installer des paquets depuis ces sources n'oblige nullement à remplacer tous les paquets pré-existants, seulement on doit mettre à jour les dépendances (ce sont des distributions binaires, tout cela est logique). Le fait qu'il n'existe pas de rpm de tel logiciel compilé avec telle version d'une bibliothèque n'est pas une faiblesse de la distributions, mais un choix nécessaire, et n'a en tout cas rien à voir avec la faisabilité de la chose.
pour ca faut telecharger les ISOs et souvent ca marche mal, faut reinstaller.
Encore une fois non, le chargement d'isos n'a rien d'obligatoire, on peut mettre à jour depuis le net, un réseau local, ou encore des cd (sans booter dessus) sans souci : la seule contrainte est de disposer par un biais quelconque des paquets concernés, rien d'extraordinaire en somme. Par ailleurs je n'ai jamais vu de cas où la mise à jour se soit passée si mal qu'une réinstallation soit nécessaire, même si j'admets volontiers que tout le monde n'a pas les connaissances requises pour réparer, le cas échéant.
Et telecharger des ISOs, avec Debian, Gentoo ou encore *BSD on le fait une seule fois et on peut vivre des annees avec un systeme a jour en permanence sans maj brutale.
J'imagine que ça dépend de ce qu'on appelle mise à jour brutale, mais par exemple un changement de libc est tout aussi brutal sous debian que sous mandrake. (peut-être moins fréquent, mais c'est un autre troll ;-))
"mise a jour incrementale" n'a rien a voir avec "version de developpement", meme si les utilisateurs de Mandrake ont tendance a confondre (vu que pour eux, maj incrementale => cooker = devel).
Entièrement d'accord avec la première partie: ça n'a rien à voir. Et entièrement en désaccord avec la deuxième: utilisateur de Mandrake ne rime pas avec neuneu.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 2.
> une seule fois et on peut vivre des annees avec un systeme a jour en
> permanence sans maj brutale
Bah j'ai une machine sur mdk 9.1 que j'ai mis à jour depuis la 8.2, sans passer par cooker et sans prendre les isos. J'ai pas plus mis à jour parce que j'ai pas le temps de le faire sur ma pauvre ligne adsl, à 500 Km de distance de mon logement actuel, mais ça passe.
Faut arréter de croire qu'on est "obligé" de passer par les isos, et que seuls les distributions qui ne sont pas destinés au grand public offrent ça.
C'est quand même incroyable cette idée de se convaincre de la supériorité d'un systéme plus dur à installer en se disant qu'on est récompensé de notre perséverance par le fait de pouvoir faire une mise à jour sans les cds...
Et puis tu parle de mises à jours incrémentals et debian, mais si l'incrément, c'est moins que tout les 2 ans, c'est que tu utilise une unstable/testing, et c'est des versions de développement...
Donc, autant pour gentoo et bsd, ok, autant pour debian on me le fera pas gober.
# Re: éternel dilemne
Posté par Pinaraf . Évalué à 0.
Tu peux à mon avis passer en mandrake 10 avec gimp 2, par contre tu ne bénéficie pas actuellement de Gnome 2.6 ni du noyau 2.6.3...
Mais sur la cooker, il y a gnome 2.6 et j'ai vu traîner un paquet kernel-tmb-2.6.4
Un serveur qui contient les paquets de la 10.0 :
ftp://ftp.sunet.se/pub/Linux/distributions/mandrakelinux/devel/(...)
Un conseil : attendez les miroirs avant de vous précipiter dessus !
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à -1.
# Re: éternel dilemne
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
En général, un paquet met 10-15 jours pour passer de unstable en testing. Mais ceux avec beaucoup de dépendances peuvent mettre plusieurs mois.
L'usage de la testing est à déconseiller en règle général. sauf dans les mois qui précèdent la sortie d'une stable (comme maintenant)
En effet, tu as "presque" une stable et les bugs sont rapidement corrigés.
Sinon, une Sid que tu mets à jour pas trop souvent devrait être tout à fait ton bonheur....
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: éternel dilemne
Posté par Anonyme . Évalué à 1.
Pourquoi la testing est elle déconseillée ?
[^] # Re: éternel dilemne
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
On a donc parfois de très vieux paquets qui trainent, des nouveaux avec des dépendances pas trop satisfaites, etc...
Il est dit qqpart sur le site de Debian de ne PAS utiliser testing à moins de savoir ce que l'on fait. (sauf en période de freeze, où justement, on cherche des chasseurs de bugs ;) )
soit on ne prend pas de risques et on reste en stable.
soit on veut un système à jour sans trop de risques, on installe sid et on fait faire la mise à jour une fois par mois (ou moins si on est satisfait et qu'on est pas hyper concerné par la sécurité) par le geek du quartier (ou de la maison dans le cas de mes parents)
soit on est geek et on passe en sid et on dist-upgrade chaque matin :)
Notons que pour le moment, je conseille la Sarge, vu qu'elle est presque stable et qu'elle va bientot freezer.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: éternel dilemne
Posté par Vincent P (site web personnel) . Évalué à 1.
Les vrais font les maj le soir juste quand les miroirs sont a jour :) (vers 22-23h en gal).
Pour apporter ma modeste experience, en sid avec des mises a jour quotidienne, il n'y a vraiment pas énormément de probleme. Cela doit arriver en moyenne une fois tous les deux mois et c'est corrigé dans la maj suivante.
Donc avec des mises a jour hebdomadaires on est à peu pres a l'abri d'une debian toute cassée. Encore plus si on jette un coup d'oeil régulier aux mailings listes dediees.
Voila mes 2 c
[^] # Re: éternel dilemne
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Et si tu espaces d'une semaine à chaque mise à jour, c'est encore mieux.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
http://www.debian.org/devel/testing(...)
"Les simples utilisateurs et les développeurs de testing doivent savoir que les mises à jour de sécurité pour testing ne sont pas gérées par l'équipe chargée de la sécurité".
Maintenant, c'est un risque à prendre.
# Re: éternel dilemne
Posté par Éric (site web personnel) . Évalué à 6.
- soit tu utilises une distrib binaire qui marche par release et à ce moment là le jeu des dépendances fera forcément que à un moment à un autre il te faudra "mettre à jour" (ce qui ne veut pas du tout dire faire une install from scratch contrairement à ce que tu dis, et ce qui marche globalement toujours très bien chez moi avec mdk). Que ce soit mandrake, debian, fedora ou autres, il y a un moment où les gens ne vont pas faire de paquet pour toi car ils concentreront leurs efforts sur des dépendances plus récentes.
- soit tu utilises une distrib binaire en développement continu et au final ce n'est pas que tu n'as pas de phase de mise à jour, c'est qu'elle est permanente. Avec tous les ennuis que ça peut comporter si c'est une version en phase de développement, et avec la nécessité d'avoir une connexion au net correcte pour tout télécharger en permanence.
- soit tu utilises une distrib source (type gentoo) qui te permettra de mixer au mieux en dépendant des versions de logiciel que tu veux. Maintenant il y a un besoin d'un minimum de compétences, d'une bonne connexion internet pour tout télécharger, et d'un gros proc pour tout compiler. Je ne peux parler que de gentoo mais en plus dans ce cas tu perd les dépendances inverses quand tu veux effacer quelque chose
- soit tu gardes ta distrib classiques et tu compiles au cas par cas ce qui n'est pas dispo (il y a des paquets sources que tu sois sous rpm ou sous deb, qui t'aideront à faire ça simplement, au pire tu prend les tarball officiels). Le problème c'est que tu perd la cohérence de ta distrib avec potentiellement des incompatibilité, et compiler certaines "grosses choses" avec les tarball officiels n'est pas toujours simple.
Passer à Debian (autre que sid) ne résoudra pas ton problème, au contraire puisqu'ils sont globalement plus stricts pour intégrer des paquets que peut l'être Mandrake. Quand à passer en SID, tu peux aussi passer en Cooker, sans problèmes. Et si tu peux te permettre d'utiliser une distrib source type gentoo c'est aussi probablement que tu peux te permettre de rajouter la dernière mdk en date dans urpmi et mettre à jour d'un coup ta distrib (ce qui se fait très bien)
# Re: éternel dilemne
Posté par Temsa (site web personnel) . Évalué à 2.
la plupart des paquets "long" se trouvent en version binaire (mozilla firefox, openoffice, etc.) néanmoins il y a tout de même des paquets long a compiler nécessaire pour gnome: mozilla, voir qt (tout depend de tes USE)
pour te montrer que c'est possible, j'ai un ami avec un p2 300 qui a une gentoo et gnome 2.6 (mozilla lui a couté une nuit de compilation -mais il n'y a pas besoin d'être devant-) l'autre pauet long c'est XFree et gcc (je te conseil d'ailleurs de commencer au stage3) est lui aussi plutot long. pour le reste rien n'est vraiment long.
l'avantage de la gentoo est qu'elle est super simple a mettre a jour, et qu'ellle a unebase de donnée de logiciel (même farfelus) très grande! j'entends parler d'un logiciel ici, je fait "emerge nomdulogiciel -p" et oh! il connaît :) :)
[^] # Re: éternel dilemne
Posté par Florent Bayle (site web personnel) . Évalué à 1.
Sinon, je trouve les paquets Debian très bien compilé : je connais quelqu'un qui utilise Debian/Gnome/Gimp sur un Pentium 75 ! C'est un peu long au chargement, mais après c'est nickel !
[^] # Re: éternel dilemne
Posté par Florent Bayle (site web personnel) . Évalué à 3.
$apt-cache show vrms
Package: vrms
Priority: optional
Section: admin
Installed-Size: 96
Maintainer: Stephen M Moraco <stephen@debian.org>
Architecture: all
Version: 1.9
Filename: pool/main/v/vrms/vrms_1.9_all.deb
Size: 8712
MD5sum: baaf02bb1643a3484bf0c12a80a4c543
Description: Virtual Richard M. Stallman
The vrms program will analyze the set of currently-installed packages on a
Debian GNU/Linux system, and report all of the packages from the non-free
tree which are currently installed.
.
Future versions of vrms will include an option to also display text from the
public writings of RMS and others that explain why use of each of the
installed non-free packages might cause moral issues for some in the Free
Software community. This functionality is not yet included.
[^] # Re: éternel dilemne
Posté par Franck . Évalué à 3.
...
The vrms program will analyze the set of currently-installed packages on a
Debian GNU/Linux system
Pas étonnant qu'il n'existe pas sur Gentoo ;-)
[^] # Re: éternel dilemne
Posté par Arachne . Évalué à 1.
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
Sur Stable, c'est normal et pas étonnant, sur Sid, c'est un peu plus étonnant.
[^] # Re: éternel dilemne
Posté par Arachne . Évalué à 1.
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 3.
Le bon vieux retour de la légende urbaine qui prétend que compiler soit même ses applications les optimises.
Si tu as une véritable argumentation pour soutenir tes dires, je suis preneur, mais sinon il peut être judicieux de s'abstenir de répandre de telles inepties.
PS : Tu conseil quelles options pour optimiser VI à sa compilation ?
[^] # Re: éternel dilemne
Posté par Pinaraf . Évalué à -1.
Ok je --> []
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 1.
Pour tout ceux que ca interesse cf performance-freebsd ml.
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
Pour le reste, KDE se lancera-t-il plus rapidement ?
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 2.
C'est surtout ca l'idée amha :-)
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
Prenons un exemple simple :
Soit A le paquet binaire, compilé avec des options
Soit toi, qui veut compiler soit via une option 1 qui réduit la taille ( -Os ) ou via des optimisations en plus ( -O2 ) ( option 2 ).
Il y a des différences dans les 2 approches. Le paquet bianire de A ne peut pas prendre les deux options, car on peut pas à la fois le code le plus rapide et le plus compacte ( exemple, le fait de dérouler les boucles ).
Donc, si A privilégie la taille, alors compiler via l'option 2 sera plus proche de ce qu'on veut si on veut les optimisations et donc plus proche du paquet optimum.
Et inversement, si le paquet binaire privilégie les optims de gcc, on aura notre binaire compilé par nos mimines plus proche de ce qu'on veut si on veut avoir des binaires plus petits qui chargent plus vite, et prennent moins de ram.
Conclusion, les sources, ça permet d'avoir ce qu'on veut. Et je parle pas encore d'avoir ce qu'on veut au niveau des dépendances.
Maintenant, c'est vrai que compiler au dela de i586 tout les programmes, ça donne pas des masses de gains sauf si le soft est prévu pour, via des instructions en assembleurs, et la plupart des paquets binaires suffisent très largement.
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
Sauf que :
1 - ça n'oblige pas d'utiliser une distrib entierement voué à la compilation (c'est faisable avec toutes)
2 - Combien d'utilisateurs de Gentoo le font ?
3 - Sur bon nombres d'applications, en supprimant ce qui ne nous sert pas, peut on vraiment arriver à un gain de temps conséquent ? A tu des exemples ?
Personnellement je ne suis pas convaincu (et tant que je ne l'aurais pas vu de me yeux lorsque j'aurais trouvé une 40aines d'heures pour compiler un système) que le fait de tout compiler tel quel, seulement avec des des options d'optimisation générique le résultat soit flagrant. Et personnellement, passer 10 heures à compiler KDE pour gagner 20 dixièmes de seconde au demarrage ne m'interesse pas. Sans parler que pour moi il est inconcevable de mettre en production un serveur disposant d'un envirronement de compilation.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
> peut on vraiment arriver à un gain de temps conséquent ? A tu des
> exemples ?
En l'occurence, j'ai terminé par le fait que le binaire suffit, je ne suis pas plus convaincu que toi sur les gains en question, car ils sont anéantis par le fait que tu as besoin des entêtes de tes libs. Par exemple, qt, ça prends quand meme ~ 80Mo
J'ai une gentoo avec juste plone et deux trois softs annexes qui prennent 1go de place sur un chroot. 1go , il y a de quoi placer X et icewm plus de quoi travailler sur une mdk ou une debian. Et j'ai pas mis des optimisations de fou, j'ai mis en -Os justement pour ça.
Donc, non j'ai pas d'exemple :)
> Sans parler que pour moi il est inconcevable de mettre en production un
> serveur disposant d'un envirronement de compilation.
Bof. Une fois qu'on est root dessus, si le truc c'est juste de faire un yum install gcc, ça me semble pas être trés dure à contourner comme protection...
Sans compter que les languages de script, ça permet beaucoup aussi ( bon oui, on fait pas de modules kernels en python ou perl :) )
[^] # Re: éternel dilemne
Posté par Mr F . Évalué à 1.
Ben déjà il faut être root (il n'y a pas des failles dans le kernel permettant d'être root toutes les semaines non plus :-) et ensuite, c'est surtout une habitude de ne pas mettre quelque chose d'inutile. Par exemple, je n'install pas de serveur ftp sur un serveur web. Après, si l'on veut vraiment efficacement empecher gcc d'être installé via apt-get, c'est possible, bien qu'effectivement ce ne soit peut être que de la parano inutile...
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
( et rpm aussi, il y a meme un script rpm2cpio en perl sur netbsd qui fait ça )
# Re: éternel dilemne
Posté par nufsitting . Évalué à -2.
Quelque exemples :
Aprés une mise à jour, étant sous Sid, xmule ce met à crasher au bout d'un certain temps, qui peut être plus ou moin long, alors qu'avant la mise à jour xmule se tenait tranquille
L'an dernier s'était avec xfree, probléme de suppression de fichier...
Et aujourd'hui, voulant voir si les mainteneurs du package k3b s'étaient enfin réveillés (car on pouvait pas graver en même temps que de construire l'iso. Bug répertorié et corrigé depuis un bout de temps par les dev de k3b), j'ai fais un upgrade et je suis tombé dans un melimelo de dépendances inexistantes, et le serveur debian renvoyait un "not found" sur un packé, alors que je venais à l'instant d'effectuer un update...
Enfin bref ça fais plus d'1 ans que je suis sous debian, et je vais aller voir ailleur, car j'ai vraiment pas envie de réinstaller et reconfigurer. Mais bon je garde comme même une deb sur un de mes pc pour ne pas être rancunier.
Maintenant le probléme et de choisir une autre distrib.
# Gentoo, mouéééé, avec le temps que met mon pc à compiler, je ressemblerais a R. Stallman avec la barbe. Et puis quand j'ai un pote qui se raméne à l'improviste, jme vois mal lui dire : "attends jdois compiler clanbomber, 15min quoi !" remarque qu'on peut aller boire un coup pendant, comme sa, sa rend plu difficile la partie, étant bouré.
# Mdk, j'ai eu des prob aussi avec. Car les outils de configuration sympatoche à trop vouloir configuer font que mon pc s'épuise.
# slack, j'ai tjs eu l'image de la bonne veille slack, bien veille, tenu par une seul personne : son auteur. Mais bon maintenant je sais pas ce qu'elle vaut, apparament elle semble bien marcher.
# suse, j'ai peur qu'en installant un suse, j'ai le droit à de superbes menus en allemand...
# fedora, bin c'est la seul distrib que je n'est pas encore tester, je crois que je vais le faire d'ailleur.
[^] # Re: éternel dilemne
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Et pourtant, je n'ai aucun problème et j'ai un système très stable (sauf amule)
Simplement parce que j'ai appris à utiliser apt-get pour résoudre un problème, à attendre si un paquet est cassé.
C'est clair que c'est pas à la portée de n'importe qui. Mais si on fait un upgrade en Sid, il faut savoir à quoi on s'expose. Inutile de raler sur Sid...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
Donc faudrait savoir.
[^] # Re: éternel dilemne
Posté par ckyl . Évalué à 1.
Le premier comprend les gens qui n'ont pas encore eu de probleme et qui disent "bof pas de problemes" et le second correspond a tout les autres :-)
En utilisant un grimoire experimental (le mien en l'occurence) j'ai flinger mes coreutils y'a 20 minutes comme quoi c'est dangereux :-p
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 0.
> sympatoche à trop vouloir configuer font que mon pc s'épuise.
Les outils se lancent pas tout seul sauf erreur de ma part.
> suse, j'ai peur qu'en installant un suse, j'ai le droit à de superbes menus
> en allemand...
Euh, c'est pas conectiva non plus, la suse est au moins traduite en anglais, et en francais.
# Re: éternel dilemne
Posté par Nap . Évalué à 1.
[^] # éternel dilemme
Posté par DiEu . Évalué à 1.
# Re: éternel dilemne
Posté par ours Ours (site web personnel) . Évalué à 1.
- cohérent
- mis à jour régulièrement et facilement (portupgrade)
- tu as le choix entre la compilation (avec les options que tu veux) et le téléchargement de package déjà compilés
- stable
bref de la balle
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.