notrya2 a écrit 133 commentaires

"Fun" le début du thread.
Quelqu'un demande l'utilisation de glib pour KDE. Rapidement certains pense que cet élément Gnome va "compremettre" KDE.
glib c'est pas Gnome spécifique ni GTK. C'est maintenant une librairie utilisée par des projets en ligne de commande sans utiliser GDK ni GTK.
Beaucoup de bruit pour rien ...

> au début j'utilisais également Alsa, mais l'problème (mon ignorance peut-être) j'n'avais pas de son pour par exemple le animes Flash, Unreal Tournament, enfin tout c'qui passent par OSS.

Au chargement des modules alsa, le volume du son est à 0.


> j'n'ai jamais réussi à activer l'émulation oss

Les modules de compatibilité oss sont chargés automatiquement. Faut lire la doc et contrôler qu'il y a un truc du style :
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

dans /etc/modules.conf

> Kernel vanilla

Mandrake fourni un kernel autant patché que redhat ou autre. Dans les 100 à 150 patches.

> En ce qui concerne comment kde fonctionne renseigne toi un peu sur leur site et tu verras que je n'ai pas dit de conneries.

Je le sais et je l'ai dit plus haut.

> Ils preferent passer du temps a finir le passage des applis d'une version majeur a l'autre plutot que de sortir un truc batard maintenant tu peux trouver ca aberrant mais au moins ca fonctionne!

Mais c'est très bien pour KDE. Cependant, tu n'as pas compris mon propos. Je sais que les applis KDE sont synchrones avec KDE. Néanmoins, critiquer Gnome sur ce point est "dangereux" car ce "problème" peut aussi arriver à KDE. Le passage Gnome 1.0 à 1.2 puis à 1.4 n'a pas posé ce problème. Porter une applis sous Gnome 2 demande beaucoup de travail. Par exemple, le point de vu du team galeon (
http://galeon.sourceforge.net/galeon2/(...) ) :
- "We decided to do a full rewrite of the our code base because of the huge changes in Gnome architecture, to improve maintainability and stability."

Prends Gnucash. En mai/juin 2002, ils ont pris la décision de faire le portage vers Gnome 2 après la version 1.8 de gnucash. Et la version 1.8.0 est sortie il y a 1 mois ! Que doit faire le projet Gnome ? Forcer le team gnucash à bosser sur le portage et repousser la version 1.8 qui amene des améliorations pour l'utilisateur final qui sont beaucoup plus importantes que le passage à Gnome 2 ? Repousser d'au moins 6 moins la sortie de Gnome 2 ? Faire de l'ingérance (douteux niveau fiabilité pour une applis qui gère du pognon) et bosser sur le portage de gnucash vers Gnome 2 et diminuer temporairement les effort en cours sur Gnome 2 ?

Avec des projets de plus en plus gros qui sont difficiles à synchroniser, plus un changement important dans l'API et/ou l'organisation (ce qui est le cas du passage Gnome 1.4 à Gnome 2), et ce "problème" (pour moi ce n'en est pas un) peu arriver à KDE.
Pour moi, ce qui compte ce sont les applis. Je ne crois pas qu'un toolkit doit fixer les plannings des applis. Et ça ne veut pas dire que Gnome ignore les développeurs d'appli et fait cavalier seul. Les versions Gnome 2.x seront compatibles source et binaire. Et ça, c'est pour les développeurs d'applis pour qu'ils n'aient pas à multiplier les portages. Donc toutes les applis Gnome 2.0 seront dès la sortie de Gnome 2.2, 2.4 etc... portées sur Gnome 2.2, 2.4 etc... Mais les développeurs d'applis n'auront aucun mérite à ça. :-)

> Tu as peut etre 512 mega de ram 256 Mo. Ça roule nickel... > J'ai parle d'organisation allemande car les allemands sont reputes Ils sont réputés, d'accord. Mais regarde IBM par exemple. Ils font preuve d'organisation et sont américains. Regardes du côté des japonais, qui sont à la pointe en terme d'organisation de la production et des bureaux d'étude. Prends les Français avec Ariane/Air liquide/Airbus... Ce que je veux dire, c'est que si KDE est bien organisé, c'est grace aux développeurs et non à cause de leur nationalité. Et quel est le pourcentage de développeur Allemand dans KDE ? 80 %, j'en doute ENORMEMENT... Enfin, le fait que les applis tardent a être portées sous Gnome 2 (qui est sorti il y a 6 mois) n'est pas un indicateur de non organisation. C'est un problème d'agenda, de priorité, de ressources. Certain vont dire qu'il y a plein de librairie, que c'est donc le bordel et prouve un marque d'organisation. N'importe quoi. Tout mettre dans une librairie n'est absolument pas une preuve d'organisation. Bien séparer les librairies pour que chaqu'une n'est qu'un domaine est important et difficile. > Pour ton dernier point non cela n'arrivera pas car le passage d'une version a l'autre se fait uniquement si les applis majeures et une grande partie des autres ont ete porte/teste sur la nouvelle API Le jour où il y aura de grosse changement d'API j'en doute beaucoup. Ce que tu me dis c'est équivalent à : - Linux ne sort pas de nouvelle version si les applis n'ont pas été porté - Apache 2 n'est pas diffusé tant que tout les modules n'ont pas été porté - etc... De plus si l'API n'est pas sortie, comment porter une application ? Pourquoi attendre le portage de toutes les applications avant d'engager d'autres évolutions ? Que ce passe-t-il si une appli c'est pas portée ? On la supprime ? C'est alourdir beaucoup de projet.

> plus d'un an apres la sortie de la premiere version STABLE de gtk2 ils vont sortir une version beta? Putain sont en avance les gars... MOUARRFFFF J'ai apporté une information pour ceux qui veulent tester evolution pour Gnome2. D'ailleur je n'ai pas testé cette version... Je n'ai pas parlé d'avance, de retard, etc... J'ai indiqué qu'evolution pour Gnome 2 est tout proche. De plus, je ne vois pas en quoi le fait d'utiliser Gnome 1 ou 2 est important. Evolution 1.2 satisfait beaucoup d'utilisateurs et aussi ceux qui utilisent KDE. Une application n'a pas pour objectif premier d'être "up to date" avec les libs qu'elle utilise mais d'être une bonne appli. Je suis sûr que la majorité des utilisateurs de Gnome 2 ne savent pas qu'evolution utilise les libs Gnome 1 et en ont rien à faire. Si les applis "lourdes" de Gnome ne sont pas portées rapidement sous Gnome 2 c'est que celà représente un travail important en charge et n'apporte pas beaucoup à l'utilisateur. > Je repete que sur le coup l'organisation allemande de kde est beaucoup plus efficace que celle de gnome!!!! Allemande... Il y a des organisations en fonction des nationalités. N'importe quoi... Les applis KDE sont synchrones avec la dernière version de KDE. Mais faites attention. Une jour KDE sortira une version avec des modifications importantes avec la version précédente et aura le même "problème" (si c'est un problème).

Plus que sur les rails. Il est en phase de debugage. Voir ici pour tester : ftp://ftp.ximian.com/pub/evolution-devel-snapshot/

C'est une interview de développeurs de KDE et GNOME. KDE : - Aaron J. Seigo - Waldo Bastian GNOME : - Havoc Pennington On voit que manifestement ils collaborent. Les projets n'ont pas exactement les même objectifs, mais ils s'entre-aident à mille Km des trolls...

> gnome en comparaison est super compliqué à installer

La majorité des utilisateurs ne compile/installe pas Gnome ou KDE. Ça ne peut être un critère pour juger ces Bureaux. Sinon ils ne sont vraiement pas "user friendly"...

> Pour l'homogénéité, si tu veux parler de mélange gtk1/gtk2

Gnome 2 a apporté des améliorations et une grosse réorganisation par rapport à Gnome 1. C'est aussi un changement d'approche, moins d'option, simplification ...
Gnome 2 inaugure une API qui sera longtemps utilisée. Gnome 2.2 est compatible source/binaire avec 2.0 et Gnome 2.4 le sera aussi. Il semble qu'avant Gnome 3.0, qui sera imcompatible Gnome 2, il y aura un Gnome 2.6. Donc Gnome 2 a une bonne pérénité et prend en compte le fait que les développeurs d'appli ont autre chose à faire que de suivre tout les changements d'API. Le nombre d'appli non encore porté sous Gnome 2 le prouve.

> Un exemple: vous pariez combien qu'il y aura des gens pour pousser à l'utilisation de c# comme langage de base pour gnome?

Il n'y a que MDI qui a dit ça et il est revenu est arrière.

Même problème.
Néanmoins :
ogg123 : j'obtien le même son que mplayer
oggdec : pour avoir un .wav. Le .wav a un son métallique comme xmms et alsaplayer mais reste ok avec mplayer et avec aplay (de alsa-utils). Le problème se rencontre en utilisant l'interface OSS ou alsa.

Il doit y avoir un traitement réalisé par mplayer, ogg123, aplay que ne font pas les autres.

J'ai fouillé la doc mplayer pour virer les filtres mais je n'y arrive pas. Faut utilise -af-dev selon la doc mais l'option n'est pas reconnue par le binaire.

Prog de freshrpms pour rh 8.0.

Sympat comme vidéo. J'ai passé un bon moment.
La vidéo est entrelacée. Avec "-vop pp=0x20000" c'est un poil mieux avec mplayer.

Je ne peut pas nier que je suis satisfait par de Villpin. Néanmoins, la position de la France est tenable car elle est suivit pas la russie, la chine parmit les membres permanents et aussi de façon plus large.

http://www.sco.com/scosource/complaint3.06.03.html

Ou plus directement depuis un shell :
realplay http://www.tv-radio.com/station/public_senat/public_senat-150k.ram(...)

D'après ces journaux, y en a qui lui cherche des poux. Il l'a peut-être cherché, je ne connais pas toute l'histoire.

> Le x86 a un avantage, c'est qu'il coute pas cher pour les particuliers. C'est le seul.

Et de belle performance par rapport au prix.

> Linus dit lui-meme qu'il a longtemps hesite a passer a x86 (avant de commencer linux) et qu'il a lache son ordinateur d'avant (je ne sais plus ce que c'etait) avec beaucoup de peine.

Selon mes souvenirs, Linus à commencé Linux pour ses étude. Il devait étudier le mode étendu du i386. Il a au début utilise minix (qui n'utilisait pas le mode étendu à l'époque) puis a créé Linux. A l'époque il n'envisagait pas que Linux puisse tourner sur autre chose que i386 avec disque dure IDE.

> Sans x86, Linus aurait tout bonnement patiente un peu plus et nous aurait pondu un noyau chiade pour autre chose. Ca n'aurait pas empeche linux.

ça m'aurait empêché d'utilisé un système libre. Le chois du x86 est le meilleur. Pas cher sur une architecture ouverte. C'est mille foi mieux que toutes les autres solutions propriétaires.

Connait pas mdk mais ça doit être comme redhat.
Pratiquement tout ce qui se configure avec une interface graphique se retrouve dans /etc/sysconfig/. On y trouve aussi plein d'infos.

cat /etc/sysconfig/rawdevices
# raw device bindings
# format:
#
# example: /dev/raw/raw1 /dev/sda1
# /dev/raw/raw2 8 5

Pour la doc, c'est par là :
/usr/share/doc/initscripts-6.95/sysconfig.txt

Et franchement, c'est beaucoup plus simple que d'apprendre ifconfig, route, raw etc... ça rend les choses beaucoups plus visible que les "hacks" des fichiers /etc/inet etc... Le paramétrage est dans des fichiers qui ne contiennent pas de code. La modification des scripts standards empêche aussi les mises à jours sans risquer de perdre les adaptations concoctées avec amour. Pour moi, ces "hacks", sont définitivement à éviter.

Ils surfent sur le côté flateur de rc. Et pourquoi cette poussée soudaine de rc ? Ceux qui font des rapports de bug savent que le nombre de bug se chiffre presque en centaine et même lorsque la dernière rc^H^H beta sort, il y a encore une centaine de bug non corrigée et connue. De plus, n'est-il pas incohérent de prétendre de sortie une distribe tous les 6 mois et de faire du "elle sortira quand elle sera prête" ? Si l'appellation rc est correctement utilisée, pourquoi faire des versions serveur prétendument plus débuggé ?

Juste pour dire ce que j'ai aussi dit pour la Gentoo 1.4rc3 . Pourquoi utiliser le terme Release Candidate ? C'est Marcelo (peut-être php) qui a popularisé les rc. maintenant c'est utilisé à la place de beta et pollue ceux qui respecte réellement l'appellation rc.

Les distribes qui utilisent rc au-lieu de beta, c'est lourd. Actuellement, liste non-exaustive : Gentoo, Mandrake, Slackware. Notons que ce sont des boîtes commerciales. Elles ont planning de pressage, de mise en boîte, de doc etc. Si c'est Debian, ça peut être justifié. Mais des boîtes commerciales, j'en doute beaucoup. Elles doivent composer entre temps de mise au point et impératif économique. Elle ne peuvent pas ce permettrent de sortie un rc en pensant qu'il n'y a pas de bugs et laisser du mode buller en attende d'un rapport de bug.

Pour bien comprendre les rc, voir les changes log de linux v2.4 :
http://www.fr.kernel.org/pub/linux/kernel/v2.4/(...)
Pour 2.4.19 et 2.4.20 :
final:
- 2.4.19-rc5 was released as 2.4.19 with no changes.
final:
- 2.4.20-rc4 was released as 2.4.20 with no changes.

Je doute qu'il y ait jamais de tels changelog dans une distribe commerciale.

> Au niveau de la rapidité, je trouve la redhat même plus rapide que ma gentoo, pourtant compilée pour athlon-mp.

La redhat est compatible i386. Mais optimisé i686 (pII ppro). Elle se limite au jeu d'instruction i386. voir /usr/lib/rpm/i386-linux/macros . L'optimisation est "seulement" -O2. Mais une news ici disait que c'était suffisant pour la majorité des cas.

ya abus de release candidate, mis à la mode avec Marcelo. Je dis pas ça uniquement pour Gentoo. Mdk fait la même chose. Une rc est la version finale s'il n'y a pas de problème. On a ici des rc plannifiées et il y a donc tromperie. Alors qu'ils utilisent les anciens "qualificatifs" : beta, ou pre-release .
Cet abus nuit aux projets qui respectent l'appellation release candidate.

Je vois le problème.
faut que l'appli soit autorisée à se connecter au serveur. Çà limite déjà beaucoup.
Le document date de 95. Je pense qu'il y a eu des évolutions.

> ça devait être «user friendly»

Personne n'a dit que c'était pas "user friendly".

> ~$ X :1 -xf86config Mon.XF86Config

Ça marche toujours pas avec les terminaux X. Donc RandR apporte un plus et sans la séquence délogin/login. C'est pas parce que ça existe sous Windows qu'il faut s'en priver.