aide





[ Précédent :: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]

Re: Des nouvelles de la prochaine version de Linux Slackware

Posté par Richard Van Den Boom () le 19/09/2003 à 16:20. (lien). Évalué à 1.

Sympa merci. Les codecs Real, c'est effectivement utile. :-)

A peluche!

[ Répondre ]

Re: Des nouvelles de la prochaine version de Linux Slackware

Posté par Richard Van Den Boom () le 19/09/2003 à 06:11. (lien). Évalué à 3.

En général, la meilleure doc, c'est celle du projet Open Source lui-même. Pour poursuivre ton exemple de XFree, la lecture de la doc Xfree apprend que depuis la 4.0, tu peut lancer "xfree86 -configure" et ca autodetecte plus ou moins ton matos et génère un fichier XF86Config dans ton /root que tu peux copier dans /etc/X11.
La Slack ne change pratiquement rien à la manière de configurer l'un quelconque des logiciels Open Source, ce qui fait que les instructions de configuration desdits projets y sont pratiquement toujours valables.
La seule chose à regarder en détail, c'est les scripts d'init mais ils sont très bien anotés et vraiment pas dur à comprendre.

Pour mplayer, j'ai jamais réussi à le compiler sur ma Slack mais ca doit être possible puisque des packages sont disponibles sur www.linuxpackages.net.
Perso, j'utilise xine, ca compile très bien et ca marche très bien. C'est même dans la distribution maintenant.
Pour les polices, j'ai eu aussi beaucoup de problèmes avec ces derniers temps, qui viennent d'être miraculeusement résolus hier avec la dernière upgrade de la Current, qui incorpore la dernière version de freetype et une recompilation d'Xfree avec cette nouvelle version. Quelque chose me dit qu'il y avait quek'chose de pas catholique.
Sinon, voila quelques petits liens Slack :

http://www.linuxpackages.net/(...) (des packages en plus)
http://slackware.tuxfamily.org/(...) (site en français)
http://www.audioslack.com/(...) (Hé oui, des packages audios pour la Slack, dont ardour)
http://www.linuxquestions.org/questions/forumdisplay.php?forumid=14(...) (forum en anglais dédié à la Slack)

A peluche!

[ Répondre ]

Re: Des nouvelles de la prochaine version de Linux Slackware

Posté par Richard Van Den Boom () le 18/09/2003 à 15:59. (lien). Évalué à 1.

Je viens de me mettre à swaret aussi et je dois dire que je trouve ca vraiment pas mal. Il y a même un début de gestions de dépendances à l'installation pour les librairies.

[ Répondre ]

Re: Des nouvelles de la prochaine version de Linux Slackware

Posté par Richard Van Den Boom () le 18/09/2003 à 15:58. (lien). Évalué à 5.

Le package Slack correspond à ce que tu obtiens avec "make install" dans les sources de xine (comme dans la plupart des packages slack d'ailleurs).
Donc, il y a tout sauf la libdvdcss qui permet de lire les DVD cryptés et les codecs Windows, comme tu le dis, mais ils sont finalement peut utilisé car xine lit la plupart des codec en natif, y compris Quicktime/Sorenson.
Pour les dvd cryptés, il suffit de télécharger la librairie libdvdcss sur le site de videolan, la compiler et l'installer, xine l'utilise si elle est disponible, même si elle n'était pas présente à la compilation.
Vali valou.

[ Répondre ]

Re: Interview de Gaël Duval

Posté par Richard Van Den Boom () le 17/09/2003 à 10:28. (lien). Évalué à 1.

Un package Slackware est généralement équivalent au résultat de la compilation d'un package source du projet. En gros, il incorpore tout ce qu'installe un "make install", donc les headers et autres.
En dehors de quelques packets tordus genre javadsk, il est rarissime qu'ils dépassent 2 ou 3 Mo. Et je ne vois pas l'intérêt de n'avoir que des petits packages de 500ko s'il faut en télécharger 5 ou 6 à chaque fois pour faire fonctionner une appli.
C'est d'ailleurs ce qui rend la crétion d'un package Slackware trivial à partir de source. :-)

A peluche!

[ Répondre ]

Re: Interview de Gaël Duval

Posté par Richard Van Den Boom () le 16/09/2003 à 10:50. (lien). Évalué à 4.

Pfff, laisse tomber, il y en aura toujours pour fuir la lumière...
Personnellement, je trouve de plus en plus que c'est la simplicité des fichiers de conf qui fait la beauté de la slack : pas de fichiers ésotériques mis dans des sous-répertoires improbables comme sur la Debian : tout est à l'endroit où les développeurs du projet Open Source ont prévu que leurs fichiers de conf devaient être. C'est simple et les scripts d'init BSD sont triviaux à comprendre.

Pour les packages, Volkerding vient de mettre dans la Current en Extra Swaret, qui fonctionne en gros comme apt-get. Un seul fichier de conf, /etc/swaret.conf, bien documenté et super-fastoche à éditer.
Je viens d'updater ma Slack en Current avec en une seule ligne de commande. Ca vérifie même des dépendances de base (les librairies essentiellement).
Rien de nouveau, bien entendu, mais qu'on aille pu me gaver avec apt-get ou urpmi.

Donc des trolls comme celui de notre ami ci-dessus ne montrent qu'une chose : il n'a jamais essayé et ne fait que répéter les habituels lieux-communs.
Bon, ceci étant dit, pourquoi ce thread sur la Mandrake dérive encore sur la Debian? La bonne distribe, c'est celle qu'on connait et qu'on maîtrise, ca me parait évident.

[ Répondre ]

Re: GNOME Desktop 2.4 Release Candidate 1

Posté par Richard Van Den Boom () le 05/09/2003 à 13:04. (lien). Évalué à 3.

>totem ne fait pas partie de la release car le backend gstreamer ne
>marche pas suffisamment bien
Mouais. Un communautairmse déplacé, vu que Totem marche très bien avec xine. Donc, ne mettons rien plutôt que de mettre au autre projet que celui qu'on défend, mais qui, lui, marche.
Dommage pour les utilisateurs.

Richard.

[ Répondre ]

Re: KOffice utilisera le format de fichiers de OpenOffice

Posté par Richard Van Den Boom () le 01/09/2003 à 05:46. (lien). Évalué à 2.

Le dernier format d'OpenOffice (j'arrive pas à mettre le .org, je trouve ca débile) est il me semble un zip d'un répertoire ou se trouve un fichier XML, les images et d'autres trucs. C'est plus sur l'interpretation des tags XML que va se faire la compatibilité et je suppose que cela n'est pas si simple.

Cordialement,

[ Répondre ]

Re: KDE 3.1.3

Posté par Richard Van Den Boom () le 01/08/2003 à 13:47. (lien). Évalué à 2.

C'est sur que c'est pas encore totalement au point. Pour les images, j'utilise Kuickshow qui est fourni avec KDE et est à la fois plus stable et plus rapide que Kview. Je l'ai configuré pour servir d'afficheur systématique et j'en suis assez content.
Pour le multimédia, moi, j'utilise xine, mais si tu veux un utilitaire KDE, alors il faut recompiler kdemultimedia avec le xine-arts plugin (et tes libxine installées). De cette manière, Noatun peut utiliser les libs xine pour lire les fichiers multimédias et les DVD et ca marche plutôt bien. Tu peux aussi installer Kaffeine, qui est un front-end graphique KDE pour xine, ou l'équivalent chez Mplayer mais là, je ne peux rien en dire car je n'utilise pas Mplayer.

Bref, c'est pas encore tellement du "out-of-the-box" mais avec un peu d'efforts, on arrive tout de même bien à avoir un système exploitable.

Cordialement,

[ Répondre ]

Re: Kernel Submit 2003

Posté par Richard Van Den Boom () le 01/08/2003 à 08:20. (lien). Évalué à 1.

S'il a froid, il a qu'à mettre des godillots au lieu de sandales..;

Bon, j'ai besoin de vacances, moi. Allons lire l'article au lieu de dire des conneries.

Cordialement,

[ Répondre ]

Re: Mimi o sumaseba

Posté par Richard Van Den Boom () le 31/07/2003 à 16:18. (lien). Évalué à 1.

Si, ca s'appelle "Si tu tends l' oreille". Je crois que le DVD est commandable à la FNAC en import pour 66,01 euros.
Mais ca à l'air d'être bêtement la traduction littérale du nom japonais.

Cordialement,

[ Répondre ]

Re: La Chine s'apprete à construire le 3eme SuperComputer le plus puissant au monde

Posté par Richard Van Den Boom () le 29/07/2003 à 06:08. (lien). Évalué à 1.

RedStorm aussi utilise des Opterons. :-)
La grande nouveauté me semble être plutôt que c'est un Supercalculateur chinois. On est plus habitué à voir ca en Europe, US ou Japon.

Cordialement,

[ Répondre ]

Re: Présentation de Kwave, un éditeur de sons pour KDE

Posté par Richard Van Den Boom () le 26/07/2003 à 09:06. (lien). Évalué à 1.

Y a-t-il un utilitaire de traitement de son multipiste scriptable en ligne de commande? Le support de module LADSPA serait bien.

Cordialement,

[ Répondre ]

Re: Présentation de Kwave, un éditeur de sons pour KDE

Posté par Richard Van Den Boom () le 26/07/2003 à 09:03. (lien). Évalué à 2.

Tu n'as pas tort mais vu que ca supporte aussi les plugins LADSPA et toutes les fonctionnalités de traitement audio, tu peux très bien l'utiliser pour cela. Sauf qu'en plus, tu peux t'amuser à du mixage grâce au multipiste.
Bon, c'est un peu la différence entre Gimp et KPaint mais qui peut le plus peut le moins, non? :-)

Cordialement,

[ Répondre ]

Re: Présentation de Kwave, un éditeur de sons pour KDE

Posté par Richard Van Den Boom () le 25/07/2003 à 14:46. (lien). Évalué à 4.

Un conseil, va voir ardour (ardour.sourceforge.net). Parce qu'il enterre tous les autres.

Cordialement,

[ Répondre ]

Re: La LGPL s'applique à Java exactement comme pour C/C++

Posté par Richard Van Den Boom () le 24/07/2003 à 05:38. (lien). Évalué à 2.

Bon, je ne suis pas un expert mais d'après ce que je comprends de la dépêche, elle prétend exactement ce que tu entends être une croyance erronée : un point-jar LGPL peut être importé par un code non LGPL. Mais si tu modifies le .jar importé, alors tu dois publier les modifications.
C'est exactement la même chose que "linker" avec une bibliothèque LGPL, autant que je comprenne.
On dirait que cette news ne dissipe pas tous les doutes :-)

Cordialement,

[ Répondre ]

Re: X86 contre PPC : Un article fait le point

Posté par Richard Van Den Boom () le 19/07/2003 à 09:26. (lien). Évalué à 1.

No, pas que je sache, c'est juste que plus tu as de refroidissements liés à des ventilateurs, plus tu as de risques de panne sur le long terme de quelques uns de tes ventilateurs et du coup un mauvais refroidissement de l'ensemble de la machine.
Je rêve d'une retour à un refroidissement passif, sans ventilos. Ca, ca ne tombe jamais en panne.

Cordialement,

[ Répondre ]

Re: Mouarf...

Posté par Richard Van Den Boom () le 19/07/2003 à 09:15. (lien). Évalué à 2.

Quelles affirmations? infirmées par qui? Apple?
Peux tu m'expliquer :

1/ Pourquoi Apple choisit justement gcc apparemment connu pour être assez médiocre sur P4?
2/ Pour ils ont visiblement selon le rapport de Veritest passer beaucoup de temps à faire des tests de flags, à optimiser une librairie malloc spécifique, et à choisir un flag -freorder-block-and-partition qui permet de l'optimisation en feedback, tout cela pour la plateforme G5 mais pas P4?
3/ Pourquoi ils utilisent le compilateur Fortran NAG qui est bien connu comme étant entre 30% et 40% plus lent que tous les autres compilateurs, y compris Portland et Lahey?

Va-y, je t'écoutes, avec mon 'foie inébranlable' (je ne te le fais pas dire. Me prendrais bien une bière :-)).
Pour finir, dès que tu as 5000 euros à me donner, je me prend une mono-proc IA-64. En attendant, je me contenterai d'un dual-Opteron pour moins de 1000 euros.

Si tu avais bien lu mes messages, tu aurais vu que je considère le PPC970 comme un très bon processeur. Mais que je m'offusque de ceux qui essayent de faire croire qu'il 'pulvérise' les x86, ce qui est juste complètement faux. Ils le font avec des arguments qui oscillent entre le FUD (la news) et le mensonge et la malhonnêteté patentés (Apple). Si tu veux des infos fiables sur le PPC970, prends les chez IBM, pas chez Apple. Ils savent de quoi ils parlent, eux.

Cordialement,

[ Répondre ]

Re: Mouarf...

Posté par Richard Van Den Boom () le 19/07/2003 à 09:02. (lien). Évalué à 2.

Juste pour indiquer ce lien sur les benchs d'Apple. Paul Hsieh est un peu virulent ici, ce qui surprenant vu que c'est généralement un grand spécialiste de soft reconnu qui fait entre autres des soumissions aux commités Spec. Il n'empêche que ces arguments sont convaincants :

http://www.azillionmonkeys.com/qed/apple.html(...)

Pour ce qui est de gcc, je pense que tu as raison pour les x86 en général (gcc est plus optimisé), mais cela ne semble pas être le cas pour le P4 en particulier, qui a une architecture bien spécifique. C'est pourquoi une comparaison avec l'Opteron est plus intéressante.

J'ai lu ton lien (rapidement, je l'avoue). Il dit que la PPC 970 est 32% plus rapide à fréquence équivalente sans l'Altivec que le P4 en flottant scalaire. Sachant que le P4 a 50% de fréquence en plus, je te laisse imaginer qui sort vainqueur de l'affaire. Sachant que l'Opteron est plus rapide à 1.8GHz en flottant que le P4 à 3GHz, ben voila.
De plus, il utilise le compilateur du Portland group qui dans sa version 4 est bien loin derrière le compilateur Intel et semble avoir du mal avec le SSE2.
Je note, cela dit, que l'auteur précise bien qu'il s'intéressait surtout à voir l'évolution entre G4 et G5, donc on ne peut pas non plus trop lui reprocher ces différences. De plus, sur le code vectoriel, je ne suis effectivement pas convaincu qu'en utilisant par exemple le dernier compilateur Portland qui semble s'approcher du niveau de performance du compilateur Intel tout en étant plus solide, un P4 ou un Opteron atteindrait le gain observé avec l'Altivec.

Je suis convaincu comme toi que le PPC970 est un très bon processeur, très performant. Et comme toute architecture, il a ses situations privilégiées et ses situations plus problématiques. Pour ce qui est de Spec, il ne faut pas oublier qu'il s'agit d'un ensemble d'applications réelles, comme gcc, gzip ou bzip2. Le score est une moyenne géométrique mais il est aussi intéressant de regarder les scores individuels des applications pour voir justement les situations particulières de chaque architecture.

Ma prochaine machine sera une bi-Opteron. Si une carte mère bi-PPC970 avec les processeurs adaptés était disponible à des prix comparables, je pense que mon choix serait beaucoup moins évident.

Cordialement,

[ Répondre ]

Re: X86 contre PPC : Un article fait le point

Posté par Richard Van Den Boom () le 19/07/2003 à 08:29. (lien). Évalué à 4.

Faux. Ces estimations de performance sont par IBM sous AIX avec un compilateur PPC d'IBM bien optimisé. Ils sont ce que l'on peut avoir de mieux pour la plateforme PPC et Apple ne fait pas de compilateur : elle prendra ce qui est disponible. Donc cette comparaison est valable.
Avec GCC, le PPC870 atteint 800 SpecINT sous MacOSX avec gcc contre 950 pour un Opteron 1.8GHz sous Linux. Donc, avec gcc, la différence est encore plus flagrante!

Cordialement,

[ Répondre ]

[ Précédent :: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]