Mouais.
A mon avis, la Slack a le ratio <nb d'utilisateurs/nb de développeurs> le plus élevé de toutes les distributions.Je pense que Patrick Volkerding en vit bien.
A ce propos, je rappelle au passage ici que, si la Slack a été, est et sera toujours en téléchargement libre, essayez au moins une fois de lui en acheter une version, quitte à télécharger les autres. Ce sera sympa et ca assurera qu'il continue. :-)
Ils répondent généralement ca aux emmerdeurs dont la seule critique sur la Slack, que par ailleurs ils ne connaissent pas, est :"dommage que son système de package soit aussi primaire et ne gère pas les dépendances alors que ma Debian/Mandrake/Red Hat avec apt-get/urpmi .....".
Bref essayez avant de critiquer : vous verrez qu'on se passe fort bien du système de dépendances.
Je ne peux donner que mon cas personnel, donc pas représentatif mais je suis venu à la Slack **après** être passé par SuSE, Mandrake, Red Hat et Debian.
Et je connais pas mal d'admin réseau qui ne jurent que par la Slack : sur des serveurs réseaux en prod, tu ne fais que des upgrades de sécurité et tu ne t'amuses surtout pas à bricoler des distribes intermédiaires à coup d'unstable ou de current. Donc, le système de packages supportant les dépendances est pratiquement inutile. Par contre, la simplicité d'administration de la Slack la rend très appropriée pour ce genre de choses.
En fait, la seule source de paquetages, en gros, sous Slack, c'est Volkerding.
Donc, soit tu utilises une version précise de la Slack et dans ce cas, tout est cohérent, soit tu tourne avec la Current et dans ce cas, si tu upgrades régulièrement, tout est cohérent aussi.
Donc, il n'y a pas besoin vraiment de gestion des packetages et comme il n'y a qu'une pu deux releases par an, c'est pas très dur de rester cohérent.
Pour le reste, soit tu compiles, dans ce cas, configure t'indiquera ou non s'il manque une lib, soit du transforme des rpm en tgz slackware mais là, tu peux effectivement avoir quelques problèmes.
Le fait est que :
1/ Si tu n'es pas du genre à updater ta machine, la distrib est plutôt pas mal achalandée et donc tu n'a que peu l'occasion de devoir compiler des trucs. Les trous de sécurités font généralement l'objet de nouveau packages pour ta version de distribe spécifiquement, donc pas vraiment de problème.
2/ Si tu es du genre à vouloir une distribe dernier cri, la Current est stable et colle en général très bien à l'actualité. Donc, tu n'as que rarement des problèmes de dépendances.
Bref, comme les autres, je me passe très bien des dépendances.
Cordialement,
Bien d'accord sur la dernière phrase. A mon avis, Hurd restera confidentiel et je ne serais pas surpris que les premiers benchs sérieux entre Hurd et Linux ne tournent à l'avantage du dernier de manière presque indécente. Mais pour autant, si des gens trouvent leur compte en Hurd, alors pourquoi pas?
Personnellement, je passerai en Hurd si c'est mieux. Pas au niveau de l'architecture ou des trucs de théoriciens à la noix, juste si c'est mieux à l'usage. Et j'espère qu'on me parlera d'autre chose que de monter un serveur ftp distant, parce que pour le moment, ca semble être la seule chose que ca apporte. Et plein d'autres choses que personne ne parvient jamais à nommer. :-)
Ah oui, c'est connu, ca. SuSE le distribuait en 98. Ca avait bonne réputation à l'époque sans toutefois être libre. Ca l'est maintenant, c'est plutôt une bonne nouvelle.
Je vais aller jeter un coup d'oeil, tiens.
Les dépendances sont surtout pour simplifier l'installation de nouveau packages. Si une dépendance d'upgrade un package pour qui la compatibilité ascendante de version est pas parfaite (selon sa compilation, glibc 2.3.1 peut avoir des problèmes de compatibilité ascendante avec glibc 2.2.5), tu peux te retrouver avec des vieux programmes qui ne marchent plus bien ou des nouveaux qui plantent. J'ai eu un problème sur une Red Hat récemment ou l'installation d'un truc genre transcode a poussé à l'upgrade d'ImageMagick. Manque de bol, le convert de la nouvelle version était buggé, problème postscript.
Comme la création des rpms gère automatiquement les dépendances en fonction des links à la compile, tu es marron. Alors que dans bien des cas, un simple lien symbolique vers une version de la librairie partagée un peu plus ancienne suffirait à faire tourner le programme malgré tout.
En bref, tu peux bousiller un système à dépendance même sans faire de truc crade.
>... Par contre, c'est un fait qu'il existe beaucoup plus de paquets pour Debian.
Là, je ne peux que m'incliner. C'est assez simple, cela dit, de convertir un package rpm e package slack. Ca marche en général bien, car la traduction des dépendances n'est pas à faire. :-)
> On parle de l'installation d'un seul programme, meme s'il a tout plein de dépendances, ou de toute la distribution ?
Sur Slack, c'est plus ou moins la même chose.
Et non, il suffit de downgrader le package-de-la-mort-qui-tue, sans toucher aux autres.
Bon, ceci étant dit, tes remarques sont justifiées, bien sur. Si les packages sont bien fait et les dépendances bien prises en compte, un système avec dépendance est plus puissant que les tgz de Volkerding.
Ceci étant dit, la plupart des utilisateurs de Slackware, je suppose, soit se cantonnent à une version de distribution, soit suivent la Slackware-Current, dans laquelle Volkerding fait en sorte de garder une bonne cohérence d'ensemble. Ce qui fait que je n'ai jamais vraiment rencontré de problème de dépendance, et à la vue d'autres messages dans ce forum, les autres non plus.
La situation problématique est surement la conversion de RPM ou, là, les problèmes seront peut-être au rendez-vous. Voila probablement pourquoi les utilisateurs de la Slack, à tout prendre, compile les sources. C'est casse-pied pour KDE ou Xfree (mieux vaut attendre les packages), mais pour xine, c'est pas trop de boulot.
Tout à fait d'accord. Parler de toute façon de "meilleure" distribution est un peu un non-sens, comme parler de "meilleur" éditeur de texte.
J'ai installé il y quelques jours, sans trop réfléchir, une Slack sur un portable Samsung d'un copain. Quand j'eu fini de tout installer à la main (y compris les pilotes graphiques i845 de chez Intel mais sans avoir réussi à faire fonctionner le modem AC97), je me suis dit : j'aurais mieux fait de lui mettre une Mandrake car je ne suis pas sur qu'il s'en sortira tout seul maintenant. En bref, elle marche bien, mais je crains qu'il n'ait eu un premier contact... "inquiet". :-)
Donc, la Slack oui, mais pas pour tout le monde. :-)
et hop t'as un package Slackware.
Et oui, la Slack est cool pour le desktop, je l'affirme car c'est ainsi que je l'utilise. Ma femme fait même un film d'animation dessus sur tablette graphique.
Tu ne chies pas sur la Slack mais en fait, tu ne l'as jamais utilisé. :-)
C'est marrant, vous persistez pour mettre en avant votre debian à comparer une installation de packages avec la compilation des sources.
Quand tu compiles tes sources téléchargées avec ta debian, tu vas avoir les mêmes problèmes que sur la Slack.
Et quand tu installes des packages avec la Slack, t'as pas de problèmes de dépendances car chaque version est cohérente.
Par contre, quant le programme que t'as installé qui t'as upgradé plein de packages, tu te rends compte qu'il ne te convient pas, amuses-toi bien pour le retour en arrière. Avec la Slack aucun problème : downgrader une Slack 9.0rc1 en 8.1, c'est une ligne de commande.
J'utilise la Slack depuis 1 an. Pas vraiment un ancien combattant. J'y ai été initié par un gars de 20 piges (j'en ai 33). Autour de moi, j'en vois un paquet des gars de 20 piges qui bossent sur la Slack. Bref, on n'a pas passé notre jeunesse dedans, on y est venu.
Avant ça, j'ai eu l'occasion à mon boulot de tester la plupart des distributions : Red Hat, SuSE, Caldera, Turbolinux, Mandrake, Debian, Yellow Dog. Il n'y en a pas une que je n'ai pas fini par bousiller dès qu'il y avait gestion des dépendances, avec cette habitude grandiose qu'ont ces systèmes de te faire des dommages collatéraux à tout va : pour installer tel package, ca t'upgrade ImageMagick, mais du coup tu te retrouves avec un "convert" buggé dont tu as besoin, mais pour revenir en arrière, c'est la galère, etc.
La Slack, je n'ai pour le moment pas réussi à la bousiller. Je fait les upgrades au même rythme que Volkerding et quand ca merde, je reviens à la version d'avant. A chaque fois, c'est une ligne de commande.
Et ca merde rarement, car il sait y faire le bonhomme.
Pour ce qui est des scripts, tous les scripts d'init de la Slack sont hyper simples. Donnez-moi de l'init BSD tous les jours, plutôt que du Système V.
En l'occurence d'un point de vue simplicité, je suis assez d'accord sur le fait que la Slack est au final plus simple pour quelqu'un qui triture un peu son système que la plupart des autres distributions dans le sens que les choses y sont organisées de façon très rationnelles. Quand ton script PERL de chez Mandrake ou Red Hat a planté (sans parler de SuSE), c'est pas toujours très simple de savoir ou aller farfouiller, alors que sur la Slack, c'est relativement immédiat, et, surtout, ça respecte les installations typiques des différents projets, ce qui veut dire que les docs desdits projets sont généralement directement applicables, paths et tout, directement avec la Slack.
Ce que tu dis par rapport à la dépendance montre que tu n'utilises jamais une Slack. Les header sont systémtiquement fournis et si tu compiles un package source fourni par Slackware, tu n'auras aucun problème de dépendance puisque ton système est cohérent. Si tu compiles un source téléchargé sur un site, toutes les distribes te poseront le même problème de dépendances.
De plus, si tu suis la Slackware-Currrent, tu serais sous KDE 3.1 depuis 4 mois comme moi, et tu serais déjà sous Xfree 4.3 comme moi, utilisant Gimp 1.3.12 comme moi. Volkerding sort généralement des packages en Current dans la semaine qui suit l'annonce officiel du projet, ce qui est pas loin d'être le plus réactif. Pour Gnome 2, c'est un autre problème, il n'aime pas Gnome et fait pas trop d'effort sur ce sujet.
Enfin bref, je suis loin de souscrire au mail initial auquel tu as répondu, mais je sais que les packages fournis par la Slack sont largement suffisant pour la plupart des utilisations que l'on peut avoir de Linux, et que le système de package de la Slack est tellement simple que faire ses propres packages est accessible au premier venu. Et compiler des sources ne bousillent en rien ta gestion des packages, ce qui est le cas dès que tu fais intervenir des dépendances.
Donc moi, je suis très bien avec ma Slack, comme tous ceux qui l'utilisent, et je ne vois vraiment pas pourquoi les debianistes à la noix viennent la ramener dans un thread qui ne les concernent pas.
Et toc.
Euh non.
Tu vas sur ftp.slackware.org ou sur un miroir (tu peux mettre un signet, ca va un peu plus vite... :-)), tu télécharge les packets que tu veux et là tu fait :
upgradepkg */*
Et vala. Tu peux ainsi upgrader tout ton système en une seule commande.
Comme t'es pas un crétin fini, tu conçois bien que si tu installes KDE3.1, t'auras surement besoin de la glibc de version adaptée et le gcc idoine. Alors tu fais pareil.
En bref, c'estb pas vraiment plus compliqué et il n'y a rien à compiler si les packages slack existe, quelle idée?
D'autre part, le retour en arrière avec la Slack est un bonheur. Un package merde ou ne te convient pas? Tu fait :
upgradepkg <ancien package>
et te revoila avec l'ancien, le nouveau ayant été complètement nettoyé.
M'étant plus galéré qu'autre chose avec les systèmes à dépendance, la slack, c'est parfait pour moi.
La Slack, c'est un CD. Point.
Evenutellement, tu peux mettre un deuxième CD d'extras qui n'est même pas plein d'ailleurs.
Voila en quoi elle est légère. Tu n'as pas huit CD dans lesquels tu te demandes ce qu'il y a, il n'y a pas 50 éditeurs de texte.
Il y a le minimum, bien fait, cohérent et stable. Tu as tout ce qu'il faut pour compiler. C'est le pied. Rien de moins.
Je l'ai chez moi, je l'ai au boulot, et dans les deux cas comme desktop, pas comme serveur, je précise.
Mois je le fais en MJPEG avec ffmpeg, ca permet de capturer directement en PAL/SECAM (768x576).
Bon, faut 20Go pour 1H30 mais ensuite tu peux recompiler en DivX avec le même ffmpeg ou transcode.
On doit pouvoir faire pareil avec mencoder mais il compile pas sur ma slack-current.
> Ce besoin de mettre les projets les uns contre les autres ...
Bon, je veux bien admettre que mon message pouvait être interprêté comme cela mais en fait c'est exactement ce que je reproche aux devs de mplayer. Leur capacité à dénigrer les autres projets du libre de lecteur vidéo, en particulier xine, pour se mettre en avant, et ce sur de nombreuses ML, est dérangeante et pénible quand on voit que leur projet empreinte aux autres autant que les autres empreintent à mplayer. Je considère que l'esprit du libre tient dans le partage plus que dans le fait de frimer avec son code. Est-ce que cela fait pour autant de mplayer un projet à éviter? Certainement pas. Ils ont, comme beaucoup d'autres, beaucoup apporté. Mais quitte à choisir, je préfère le projet développé avec un peu plus d'humilité (c'est très relatif, comme notion, j'en conviens).
Et bon, c'est du libre. Si ca bugge, y'a qu'à remplir des rapports de bugs.
> quand on est satisfait de quelque chose, on se fout un peu de l'ego des concepteurs
Je comprends tout à fait que la plupart des gens s'en foutent. Mais les dernières releases de xine font pratiquement tout tourner sans problème, xine lit parfaitement les DVD, et moi, entre des gars qui développent un truc pour le plaisir de faire un truc propre et les autres pour être les numéros 1, j'ai tendance à préférer les premiers. Tout ca parce que je suis un connard d'intellectuel de gauche.
Cela dit, Thibaut, je lit régulièrement la ML dévelop de xine pour le fun mais peut-être en sais-tu plus sur le sujet : qu'en est-il d'enix (je viens seulement de remarquer que c'est xine à l'envers d'ailleurs)? C'est un projet que Guenter développe seul pour le moment ou vous y travaillez tous? J'attends avec désespoir un projet de montage non linéaire de vidéo sous Linux (non, pas de Cinnerella SVP, j'ai testé les projets existants et aucun ne me convient) et la librairie 'enix' semble très intéressante si elle permet d'avoir rapidement autant de front-end pour le montage que xine en a en tant que player.
Au fait, pourquoi xine ne doit pas prendre de 'x' majuscule? :-)
Ca tombe bien, c'est ce qu'ils cherchent.
C'est pour ca que j'utilise xine, qui marche aussi bien (pas beaucoup d'annonce sur linuxfr d'ailleurs sur xine, qui a aussi un plug-in Mozilla, ben tiens) mais au moins les concepteurs de ce projet n'ont pas la grosse tête.
Bon, mon message est un bête billet d'humeur sans intérêt, mais j'ai horreur des attitudes conquérantes dans le milieu du libre.
xine a un support complet pour les plug-ins de post-effect maintenant. Il est vrai que l'accent n'est pour le moment mis que sur l'aspect player, mais l'aspect édition de flux est peu à peu mise en place et sera sans doute le prochain milepost une fois la version 1.0 de la lib finalisée.
Apparemment, leur API est stable et propre, ce qui fait, qu'entre autres, Rythmbox cité plus haut a pour le moment migré de Gstreamer à xine.
Et xine a déjà un support très important d'interfaces : gnome, gtk, X11, KDE, etc.
Je ne serais donc pas surpris que ce projet coiffe les autres au poteau au final.
Ceci étant dit, il faut rappeler que tous ces projets interragissent beaucoup et que des portions de xine viennent de mplayer et réciproquement, et tous puisent alègrement sur un projet comme ffmpeg. Quelque soit l'API qui s'imposera au final, la contribution des autres projets restera très important et méritera d'être signalée.
Ces précisions sont très intéressantes (en particulier celles concernant les TT que je ne savais pas).
Cela dit, en quoi est-ce en contradiction avec ce que j'ai dit dans le message précédent?
Sous Windows, quand les fontes italique ou gras sont dispos, les logiciels les utilisent par défaut. La déclinaison ne se fait que si les fontes ne sont pas disponibles.
Je ne sais pas sous Linux si les traitements de textes supportent cela.
[^] # Re: KDE 3.11?
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de KDE 3.1.1!. Évalué à 2.
On est pas rendu si on doit attendre KDE 2000 et sa nouvelle architecture.
Cordialement,
[^] # Re: Morte
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de la slackware 9. Évalué à 5.
A mon avis, la Slack a le ratio <nb d'utilisateurs/nb de développeurs> le plus élevé de toutes les distributions.Je pense que Patrick Volkerding en vit bien.
A ce propos, je rappelle au passage ici que, si la Slack a été, est et sera toujours en téléchargement libre, essayez au moins une fois de lui en acheter une version, quitte à télécharger les autres. Ce sera sympa et ca assurera qu'il continue. :-)
Cordialement,
[^] # Re: Sortie de la slackware 9
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de la slackware 9. Évalué à 3.
Bref essayez avant de critiquer : vous verrez qu'on se passe fort bien du système de dépendances.
Cordialement,
[^] # Re: Ca le fait !
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de la slackware 9. Évalué à 3.
Et je connais pas mal d'admin réseau qui ne jurent que par la Slack : sur des serveurs réseaux en prod, tu ne fais que des upgrades de sécurité et tu ne t'amuses surtout pas à bricoler des distribes intermédiaires à coup d'unstable ou de current. Donc, le système de packages supportant les dépendances est pratiquement inutile. Par contre, la simplicité d'administration de la Slack la rend très appropriée pour ce genre de choses.
Cordialement
[^] # Re: Dépendances
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de la slackware 9. Évalué à 7.
[^] # Re: Hurd bientot au niveau de l'Everest !!!
Posté par Richard Van Den Boom . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 1.
Personnellement, je passerai en Hurd si c'est mieux. Pas au niveau de l'architecture ou des trucs de théoriciens à la noix, juste si c'est mieux à l'usage. Et j'espère qu'on me parlera d'autre chose que de monter un serveur ftp distant, parce que pour le moment, ca semble être la seule chose que ca apporte. Et plein d'autres choses que personne ne parvient jamais à nommer. :-)
Cordialement,
[^] # Re: SAPDB 7.4 is out
Posté par Richard Van Den Boom . En réponse à la dépêche SAPDB 7.4 is out. Évalué à 1.
Je vais aller jeter un coup d'oeil, tiens.
Cordialement,
[^] # Re: Slackware 9.0-rc1
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 1.
Comme la création des rpms gère automatiquement les dépendances en fonction des links à la compile, tu es marron. Alors que dans bien des cas, un simple lien symbolique vers une version de la librairie partagée un peu plus ancienne suffirait à faire tourner le programme malgré tout.
En bref, tu peux bousiller un système à dépendance même sans faire de truc crade.
Cordialement,
[^] # Re: Clair que ça va troller
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 2.
Là, je ne peux que m'incliner. C'est assez simple, cela dit, de convertir un package rpm e package slack. Ca marche en général bien, car la traduction des dépendances n'est pas à faire. :-)
> On parle de l'installation d'un seul programme, meme s'il a tout plein de dépendances, ou de toute la distribution ?
Sur Slack, c'est plus ou moins la même chose.
Et non, il suffit de downgrader le package-de-la-mort-qui-tue, sans toucher aux autres.
Bon, ceci étant dit, tes remarques sont justifiées, bien sur. Si les packages sont bien fait et les dépendances bien prises en compte, un système avec dépendance est plus puissant que les tgz de Volkerding.
Ceci étant dit, la plupart des utilisateurs de Slackware, je suppose, soit se cantonnent à une version de distribution, soit suivent la Slackware-Current, dans laquelle Volkerding fait en sorte de garder une bonne cohérence d'ensemble. Ce qui fait que je n'ai jamais vraiment rencontré de problème de dépendance, et à la vue d'autres messages dans ce forum, les autres non plus.
La situation problématique est surement la conversion de RPM ou, là, les problèmes seront peut-être au rendez-vous. Voila probablement pourquoi les utilisateurs de la Slack, à tout prendre, compile les sources. C'est casse-pied pour KDE ou Xfree (mieux vaut attendre les packages), mais pour xine, c'est pas trop de boulot.
Cordialement,
[^] # Re: Clair que ça va troller
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 1.
J'ai installé il y quelques jours, sans trop réfléchir, une Slack sur un portable Samsung d'un copain. Quand j'eu fini de tout installer à la main (y compris les pilotes graphiques i845 de chez Intel mais sans avoir réussi à faire fonctionner le modem AC97), je me suis dit : j'aurais mieux fait de lui mettre une Mandrake car je ne suis pas sur qu'il s'en sortira tout seul maintenant. En bref, elle marche bien, mais je crains qu'il n'ait eu un premier contact... "inquiet". :-)
Donc, la Slack oui, mais pas pour tout le monde. :-)
Cordialement,
[^] # Re: Slackware 9.0-rc1
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 4.
Tu te télécharge un rpm, tu fais :
rpm2tgz package.rpm
et hop t'as un package Slackware.
Et oui, la Slack est cool pour le desktop, je l'affirme car c'est ainsi que je l'utilise. Ma femme fait même un film d'animation dessus sur tablette graphique.
Tu ne chies pas sur la Slack mais en fait, tu ne l'as jamais utilisé. :-)
Cordialement,
[^] # Re: Clair que ça va troller
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 5.
Quand tu compiles tes sources téléchargées avec ta debian, tu vas avoir les mêmes problèmes que sur la Slack.
Et quand tu installes des packages avec la Slack, t'as pas de problèmes de dépendances car chaque version est cohérente.
Par contre, quant le programme que t'as installé qui t'as upgradé plein de packages, tu te rends compte qu'il ne te convient pas, amuses-toi bien pour le retour en arrière. Avec la Slack aucun problème : downgrader une Slack 9.0rc1 en 8.1, c'est une ligne de commande.
Mais bon, chacun voit midi à sa porte.
Cordialement,
[^] # Re: Slackware 9.0-rc1
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 2.
J'utilise la Slack depuis 1 an. Pas vraiment un ancien combattant. J'y ai été initié par un gars de 20 piges (j'en ai 33). Autour de moi, j'en vois un paquet des gars de 20 piges qui bossent sur la Slack. Bref, on n'a pas passé notre jeunesse dedans, on y est venu.
Avant ça, j'ai eu l'occasion à mon boulot de tester la plupart des distributions : Red Hat, SuSE, Caldera, Turbolinux, Mandrake, Debian, Yellow Dog. Il n'y en a pas une que je n'ai pas fini par bousiller dès qu'il y avait gestion des dépendances, avec cette habitude grandiose qu'ont ces systèmes de te faire des dommages collatéraux à tout va : pour installer tel package, ca t'upgrade ImageMagick, mais du coup tu te retrouves avec un "convert" buggé dont tu as besoin, mais pour revenir en arrière, c'est la galère, etc.
La Slack, je n'ai pour le moment pas réussi à la bousiller. Je fait les upgrades au même rythme que Volkerding et quand ca merde, je reviens à la version d'avant. A chaque fois, c'est une ligne de commande.
Et ca merde rarement, car il sait y faire le bonhomme.
Pour ce qui est des scripts, tous les scripts d'init de la Slack sont hyper simples. Donnez-moi de l'init BSD tous les jours, plutôt que du Système V.
Cordialement,
[^] # Re: Clair que ça va troller
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 7.
Ce que tu dis par rapport à la dépendance montre que tu n'utilises jamais une Slack. Les header sont systémtiquement fournis et si tu compiles un package source fourni par Slackware, tu n'auras aucun problème de dépendance puisque ton système est cohérent. Si tu compiles un source téléchargé sur un site, toutes les distribes te poseront le même problème de dépendances.
De plus, si tu suis la Slackware-Currrent, tu serais sous KDE 3.1 depuis 4 mois comme moi, et tu serais déjà sous Xfree 4.3 comme moi, utilisant Gimp 1.3.12 comme moi. Volkerding sort généralement des packages en Current dans la semaine qui suit l'annonce officiel du projet, ce qui est pas loin d'être le plus réactif. Pour Gnome 2, c'est un autre problème, il n'aime pas Gnome et fait pas trop d'effort sur ce sujet.
Enfin bref, je suis loin de souscrire au mail initial auquel tu as répondu, mais je sais que les packages fournis par la Slack sont largement suffisant pour la plupart des utilisations que l'on peut avoir de Linux, et que le système de package de la Slack est tellement simple que faire ses propres packages est accessible au premier venu. Et compiler des sources ne bousillent en rien ta gestion des packages, ce qui est le cas dès que tu fais intervenir des dépendances.
Donc moi, je suis très bien avec ma Slack, comme tous ceux qui l'utilisent, et je ne vois vraiment pas pourquoi les debianistes à la noix viennent la ramener dans un thread qui ne les concernent pas.
Et toc.
Cordialement,
[^] # Re: Question bête...
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 2.
Tu vas sur ftp.slackware.org ou sur un miroir (tu peux mettre un signet, ca va un peu plus vite... :-)), tu télécharge les packets que tu veux et là tu fait :
upgradepkg */*
Et vala. Tu peux ainsi upgrader tout ton système en une seule commande.
Comme t'es pas un crétin fini, tu conçois bien que si tu installes KDE3.1, t'auras surement besoin de la glibc de version adaptée et le gcc idoine. Alors tu fais pareil.
En bref, c'estb pas vraiment plus compliqué et il n'y a rien à compiler si les packages slack existe, quelle idée?
D'autre part, le retour en arrière avec la Slack est un bonheur. Un package merde ou ne te convient pas? Tu fait :
upgradepkg <ancien package>
et te revoila avec l'ancien, le nouveau ayant été complètement nettoyé.
M'étant plus galéré qu'autre chose avec les systèmes à dépendance, la slack, c'est parfait pour moi.
Cordialement,
[^] # Re: Slackware 9.0-rc1
Posté par Richard Van Den Boom . En réponse à la dépêche Slackware 9.0-rc1. Évalué à 5.
Evenutellement, tu peux mettre un deuxième CD d'extras qui n'est même pas plein d'ailleurs.
Voila en quoi elle est légère. Tu n'as pas huit CD dans lesquels tu te demandes ce qu'il y a, il n'y a pas 50 éditeurs de texte.
Il y a le minimum, bien fait, cohérent et stable. Tu as tout ce qu'il faut pour compiler. C'est le pied. Rien de moins.
Je l'ai chez moi, je l'ai au boulot, et dans les deux cas comme desktop, pas comme serveur, je précise.
Cordialement,
[^] # Re: Xfree 4.3.0 est arrivée
Posté par Richard Van Den Boom . En réponse à la dépêche Xfree 4.3.0 est arrivée. Évalué à 6.
Cordialement,
[^] # Re: Xfree 4.3.0 est arrivée
Posté par Richard Van Den Boom . En réponse à la dépêche Xfree 4.3.0 est arrivée. Évalué à 4.
Bon, faut 20Go pour 1H30 mais ensuite tu peux recompiler en DivX avec le même ffmpeg ou transcode.
On doit pouvoir faire pareil avec mencoder mais il compile pas sur ma slack-current.
Cordialement,
[^] # Re: Avidemux
Posté par Richard Van Den Boom . En réponse à la dépêche Solutions logicielles pour la vidéo sous Linux. Évalué à 2.
[^] # Re: La domination totale est en marche
Posté par Richard Van Den Boom . En réponse à la dépêche Plugin MPlayer pour Mozilla et Konqueror. Évalué à 0.
Bon, je veux bien admettre que mon message pouvait être interprêté comme cela mais en fait c'est exactement ce que je reproche aux devs de mplayer. Leur capacité à dénigrer les autres projets du libre de lecteur vidéo, en particulier xine, pour se mettre en avant, et ce sur de nombreuses ML, est dérangeante et pénible quand on voit que leur projet empreinte aux autres autant que les autres empreintent à mplayer. Je considère que l'esprit du libre tient dans le partage plus que dans le fait de frimer avec son code. Est-ce que cela fait pour autant de mplayer un projet à éviter? Certainement pas. Ils ont, comme beaucoup d'autres, beaucoup apporté. Mais quitte à choisir, je préfère le projet développé avec un peu plus d'humilité (c'est très relatif, comme notion, j'en conviens).
Et bon, c'est du libre. Si ca bugge, y'a qu'à remplir des rapports de bugs.
Cordialement,
[^] # Re: La domination totale est en marche
Posté par Richard Van Den Boom . En réponse à la dépêche Plugin MPlayer pour Mozilla et Konqueror. Évalué à 2.
Je comprends tout à fait que la plupart des gens s'en foutent. Mais les dernières releases de xine font pratiquement tout tourner sans problème, xine lit parfaitement les DVD, et moi, entre des gars qui développent un truc pour le plaisir de faire un truc propre et les autres pour être les numéros 1, j'ai tendance à préférer les premiers. Tout ca parce que je suis un connard d'intellectuel de gauche.
Cela dit, Thibaut, je lit régulièrement la ML dévelop de xine pour le fun mais peut-être en sais-tu plus sur le sujet : qu'en est-il d'enix (je viens seulement de remarquer que c'est xine à l'envers d'ailleurs)? C'est un projet que Guenter développe seul pour le moment ou vous y travaillez tous? J'attends avec désespoir un projet de montage non linéaire de vidéo sous Linux (non, pas de Cinnerella SVP, j'ai testé les projets existants et aucun ne me convient) et la librairie 'enix' semble très intéressante si elle permet d'avoir rapidement autant de front-end pour le montage que xine en a en tant que player.
Au fait, pourquoi xine ne doit pas prendre de 'x' majuscule? :-)
Cordialement,
[^] # Re: La domination totale est en marche
Posté par Richard Van Den Boom . En réponse à la dépêche Plugin MPlayer pour Mozilla et Konqueror. Évalué à 7.
C'est pour ca que j'utilise xine, qui marche aussi bien (pas beaucoup d'annonce sur linuxfr d'ailleurs sur xine, qui a aussi un plug-in Mozilla, ben tiens) mais au moins les concepteurs de ce projet n'ont pas la grosse tête.
Bon, mon message est un bête billet d'humeur sans intérêt, mais j'ai horreur des attitudes conquérantes dans le milieu du libre.
Richard Van Den Boom
[^] # Re: Sortie de GStreamer 0.6.0
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de GStreamer 0.6.0. Évalué à 1.
Apparemment, leur API est stable et propre, ce qui fait, qu'entre autres, Rythmbox cité plus haut a pour le moment migré de Gstreamer à xine.
Et xine a déjà un support très important d'interfaces : gnome, gtk, X11, KDE, etc.
Je ne serais donc pas surpris que ce projet coiffe les autres au poteau au final.
Ceci étant dit, il faut rappeler que tous ces projets interragissent beaucoup et que des portions de xine viennent de mplayer et réciproquement, et tous puisent alègrement sur un projet comme ffmpeg. Quelque soit l'API qui s'imposera au final, la contribution des autres projets restera très important et méritera d'être signalée.
Cordialement,
[^] # Re: 10 polices de caractères pour les Logiciels Libres
Posté par Richard Van Den Boom . En réponse à la dépêche 10 polices de caractères pour les Logiciels Libres. Évalué à 2.
Cela dit, en quoi est-ce en contradiction avec ce que j'ai dit dans le message précédent?
Richard Van Den Boom
[^] # Re: Screenshots
Posté par Richard Van Den Boom . En réponse à la dépêche 10 polices de caractères pour les Logiciels Libres. Évalué à 4.
Je ne sais pas sous Linux si les traitements de textes supportent cela.
Richard Van Den Boom