au détail prs que je prends un ReiserFS, un kernel 2.6.5 et gcc 3.4
Ah bah forcement, pourtant c'est ecrit assez gros sur le site: FBBG (Follow Book, Book Good). Faut t'attendre a des surprises si tu changes les logiciels.
Sur la FAQ, tu aurais pu lire ca aussi:
---- I want to use linux-2.6.x in LFS-5.x?
Currently, you can't build an LFS system by using linux-2.6.x instead of linux-2.4.x. This is because the kernel headers from 2.6.x are incompatible with other programs in LFS-5.x and will lead to compile errors.
----
Pour ma part, j'ai monte les deux dernieres releases de LFS/BLFS et il n'y a eu aucun probleme en suivant exactement le livre.
J'ai egalement monte une LFS 5 a partir d'un noyau 2.6.0-test4 sur XFS, en sachant ce qui m'attendait. Il m'a fallu patcher pas mal d'applications (notamment les utils-linux). Ceci dit, ca fonctionne correctement, mais il a fallu mettre les mains dans le cambouis.
Pourquoi utilises-tu une Knoppix ? Ca peut etre une source de probleme a mon avis.
Et ça va automatiquement mettre à jours toutes les dépendances ?
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é
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
Il y a beaucoup de points sur lesquels j'ai deja repondu plus haut mais:
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 :-)
le silex n'est pas l'outil le plus efficace qui soit..
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 ?
Depuis quand une recherche sur google devient un argument ?
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.
J'aimerais connaitre le nombre de parc serveur conséquent entièrement en Slackware
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 :-)
Les paquets et leurs dependances sont de grande qualite.
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.
Ouai c'est clair que d'un seul coup ca discredite totalement la base rpm que tu ne peux pas backuper !
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.
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) ?
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.
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 ?
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.
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 ?
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.
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 ?
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...).
# Trop tard
Posté par Jérôme Pinot (site web personnel) . En réponse au journal GNU/Linux kernel 2.6.6 released. Évalué à 2.
http://linuxfr.org/~ngc891/12544.html(...)
[^] # Re: Mais aussi...
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Eclipse. Évalué à 0.
C'etait pas une bonne idee de trainer dans les magasins aujourd'hui.
[^] # Re: Merci
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Eclipse. Évalué à 0.
Ici, en Coree, elle etait bien a l'ouest :-)
Ceci dit, j'ai bien vu le debut mais ca s'est vite gate a cause des nuages. En plus, il faisait jour a 5h10, alors...
[^] # Re: FUD de Sun
Posté par Jérôme Pinot (site web personnel) . En réponse au journal FUD de Sun. Évalué à 1.
Donc, non, meme la LFS n'est pas vierge. Lis le bouquin.
[^] # Re: Poulet rôti
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Poulet rôti. Évalué à 1.
- sing
- lay an egg
Mais le voir jouer au base-ball, c'est pas mal:
- do sport
# Re: Marre de ces sites
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Marre de ces sites. Évalué à 2.
L'auteur du site est Cedric Louvrier
# Re: Open office abérent ?
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Open office abérent ?. Évalué à 1.
# Re: LFS qui foire avant d'avoir commencé ...
Posté par Jérôme Pinot (site web personnel) . En réponse au journal LFS qui foire avant d'avoir commencé .... Évalué à 2.
Ah bah forcement, pourtant c'est ecrit assez gros sur le site: FBBG (Follow Book, Book Good). Faut t'attendre a des surprises si tu changes les logiciels.
Sur la FAQ, tu aurais pu lire ca aussi:
----
I want to use linux-2.6.x in LFS-5.x?
Currently, you can't build an LFS system by using linux-2.6.x instead of linux-2.4.x. This is because the kernel headers from 2.6.x are incompatible with other programs in LFS-5.x and will lead to compile errors.
----
Pour ma part, j'ai monte les deux dernieres releases de LFS/BLFS et il n'y a eu aucun probleme en suivant exactement le livre.
J'ai egalement monte une LFS 5 a partir d'un noyau 2.6.0-test4 sur XFS, en sachant ce qui m'attendait. Il m'a fallu patcher pas mal d'applications (notamment les utils-linux). Ceci dit, ca fonctionne correctement, mais il a fallu mettre les mains dans le cambouis.
Pourquoi utilises-tu une Knoppix ? Ca peut etre une source de probleme a mon avis.
[^] # Re: éternel dilemne
Posté par Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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 Jérôme Pinot (site web personnel) . En réponse au journal éternel dilemne. É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: Comparaison entre les noyaux 2.4.25 et 2.6.4
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Comparaison entre les noyaux 2.4.25 et 2.6.4. Évalué à 1.
Il y a les sources. Si tu connais bien le sujet, tu devrais pouvoir te faire ta propre opinion.
[^] # Re: manipulation rapide de photo numérique
Posté par Jérôme Pinot (site web personnel) . En réponse au journal manipulation rapide de photo numérique. Évalué à 1.
# Re: manipulation rapide de photo numérique
Posté par Jérôme Pinot (site web personnel) . En réponse au journal manipulation rapide de photo numérique. Évalué à 2.
http://www.imagemagick.org/(...)
En standard sur les distribs ?
NB: tu aurais du poster sur la tribune, ou, a la limite, en seconde page.