wismerhill a écrit 2603 commentaires

Pourquoi?
Il n'est pas plus démarré que ne l'était pulseaudio.

Il n'y a pas que Gnome qui a une grosse dépendance vis à vis de pulseaudio, KDE l'a tout autant ;).

Non.
Si je fais un test de désinstallation de PA les seuls paquets de KDE4 qui s'en vont sont ceux ayant une dépendance sur mplayer (qui dépend de libesd qui dépend de esound qui est fourni par PA via un paquet de compatibilité).
Les quelques programmes de KDE3 qui me restent partent aussi à cause de libarts qui a aussi une dépendance sur libesb (??).

Et comme je disais dans mon post précédent il faut simplement installer le paquet esound-daemon, qui va du coup forcer la désinstallation de pulseaudio-esound-compat et après on peut désinstaller PA sans virer la moitié des programmes.

D'ailleurs, alliant le geste à la parole, je viens de désinstaller pulseaudio, une fois l'épine esound sortie du pied ça ne désinstalklke plus que 8 paquets, tous explicitement en rapport avec PA.

Pour pulseaudio, tu peux malgré tout le désactiver et utiliser directement alsa (ou un autre seveur de son).
C'est en fait gnome qui a une grosse dépendance dessus parce qu'il remplace esound, via le paquet pulseaudio-esound-compat, je pense que si tu remplace ce dernier par esound-daemon tu devrais pouvoir virer pulseaudio sans que ça entraîne tout gnome (et tout ce qui dépend de esound, comme mplayer).

Dans les install parties, lorsque la personne a du matériel compatible je fais toujours une installation x86_64, et j'ai déjà vu plusieurs fois des gens qui n'y connaissent pas grand chose en informatique, mais qui savaient que leur ordinateur est un 64 bits (because marketing) et voulaient donc un linux (ils ne connaissaient pas non plus le terme distribution) qui utilisera pleinement leur matériel.

Donc si, je t'assure, il y a des gens qui utilisent les version x86_64.

Faudrait savoir, tu veux du 64 bits ou pas?
Moi j'utilise la version x86_64 depuis la 2008.1.

Le packaging permet effectivement d'avoir un mélange de paquets 32 bits sur une installation de base 64 bits et c'est un gros avantage.
Ça permet d'utiliser quand même des programmes qui ne fonctionnent pas en 64 bits (openoffice avait par exemple mis du temps à être fonctionnel, ou encore si tu veux utiliser des logiciels propriétaires).

Il "suffit" de mettre les sources de paquets dans le bon ordre pour donner priorité aux version x86_64 (ça peut encore donner des effets bizarres si tu as une version plus récente d'un paquet dans une source 32 bits, mais si tu reste sur les sources officielles ça ne devrait pas arriver).

* Vu que quasi tout le monde utilise la version 32-bit, il faudrait s'assurer que les paquets 64-bit soient de la même qualité.

D'où viennent tes statistiques?

La RC2 est effectivement toute neuve, mais c'était pareil pour la RC1
http://wiki.mandriva.com/en/2010.0_RC_1#Available_media

La beta n'est sortie quant à elle qu'en DVD et live CD
http://wiki.mandriva.com/en/2010.0_Beta#Available_media

Par contre, énorme point noir, c'est du i586.

C'est parce que tu as installé avec un live CD, qui sont tous des version i586 pour supporter la plus large audience possible.

Si tu veux du X86_64 il faut prendre le DVD version x86_64 (il y a les deux) ou l'ISO mini-dual qui contient le minimum du système pour les deux architectures (et après on installe par internet, ou directement pendant l'installation on choisit des sources distances pour qu'il sélectionne tout directement).

cf http://wiki.mandriva.com/en/2010.0_RC_2#Available_media

BTRFS n'est pas un FS distribué, c'est un FS destiné à gérer physiquement les données sur un support de masse (disque dur, SSD, ...).
Toutes les personnes qui utilisent un ordinateur ont besoin d'un système de fichiers localement, les cas d'utilisations d'un FS distribué sont plus ciblés et concernent beaucoup moins de monde.
Il vaut mieux passer son temps sur un FS qui profitera à tout le monde.

Merci pour les millions de personnes qui doivent continuer à supporter du ie6 à cause de ce genre d'attitude à la con.

Hum, que ça passe par le navigateur, un gestionnaire de fichiers ou un montage le résultat est le même: les données doivent être transférées par le réseau.
Et j'imagine que l'intérêt d'avoir des miniatures est justement de ne pas télécharger toutes les grosses images.

Ce qui pourrait aider, ce serait de faire un job cron qui va aller régulièrement générer les miniatures manquantes, comme ça elles sont disponibles pour quand tu veux les voir.

Je ne sais pas quelle distrib tu utilise, mais moi avec les paquets 4.3.1 non officiels pour mandriva 2009.1 je n'ai jamais eu de plantage de kwin, j'ai eu parfois des plantages de plasma (peut-être 1 par semaine en moyenne) mais il s'est toujours relancé tout seul sans perdre sa configuration et quelques plantages de konqueror mais seulement sur certains sites particulier (du genre écris avec les pieds, ça n'excuse pas un plantage du navigateur, mais on est plus indulgent). Et je n'utilise pas knetworkmanager (l'outil de mdv fonctionne bien).

Par contre j'ai plus de problèmes sur mon portable, mais il a une carte graphique intel, et les drivers intel pour le moment ils peuvent t'exploser à la gueule sans préavis.

Ça c'est parce que cp ou rsync, avec les options qui vont bien (typiquement un -a) vont explicitement changer les permissions du fichier de destination pour correspondre à ceux d'origine.
Si on veut éviter ça il faut exclure ces options.

Pour rsync le -a est équivalent à -rlptgoD, duquel il faut retirer o (owner) g (group) et p (perms)
Pour cp le -a est équivalent à -dR --preserve=all, on peut ajouter un --no-preserve=mode (pour enlever mode du all) et éventuellement --no-preserve=ownership (pour le propriétaire)

Le problème est d'ailleurs le même avec la plupart des gestionnaires de fichier/clients (s)ftp (j'ai régulièrement le problème au boulot avec des clients sftp sous windows qui forcent les permissions alors que j'ai tuner sur mesure celles par défaut).

Je pense que les ACL permettent de faire ce que tu veux (à vérifier, je n'ai pas beaucoup utilisé).

Il y a aussi l'option d'avoir un script qui passe régulièrement pour remettre les droit qui vont bien, mais c'est assez crade.
Dans la même idée en moins crade, si tu as un noyau pas trop ancien tu peux utiliser incron (cf http://inotify.aiken.cz/ ) pour déclencher automatiquement le changement de droits.

S'il n'a pas besoin de justifier sa demande, je ne vois pas pourquoi je devrais justifier ma réponse, ni pourquoi je m'emmerde à en faire une d'ailleurs!

Peut-être la raison pour laquelle on ne veut pas de la nouvelle version?

Si ça avait été indiqué dans cette demande (plutôt que dans un journal qui n'est arrivé qu'après) on aurait pu éviter ce fil sans intérêt.

Oui, maintenant j'ai vu ce journal et je comprend mieux l'intérêt de rester avec la version qt3, mais ce journal a été posté (11h15) deux minutes avant ma première réponse (11h17) et je n'avais donc pas eu le temps d'en prendre connaissance.

Et oui, je persiste, si la version qt4 était opérationnelle (ce qu'elle n'est pas si j'en crois son autre journal) ça aurait été la meilleure chose à faire.

Ben, c'est logique!
Il utilise KDE4 qui est basé sur qt4, autant utiliser une version récente de scribus qui soit aussi basée sur qt4 et s'intégrera bien au reste de l'environnement.

Sinon il configure son qt3 pour utiliser un thème qui lui plaît.

Installe une version récente basée sur qt4.

En fait, il faut surtout espérer que ça ne donnera pas envie à des personnes d'ajouter des rues au hasard juste pour pouvoir les acheter.

Encore faut-il voir si MCS a l'intention de remettre à jour les données d'OSM où s'ils vont rester pendant plusieurs mois/années avec les données actuelles (car les nouvelles rues OK, mais si certaines disparaissent les joueurs vont se plaindre).

Ça n'empêche pas d'être poli...

alors, si le mainteneur n'a plus le temps, il dégage et laisse sa place à un autre.

Bonjour la reconnaissance!
Les développeurs ne sont pas des kleenex que l'on jette après usage.

Ah?
Moi j'avais compris l'extrait " nous n'avons pas changé la valeur de l'option 'data' sur 'writeback'" comme voulant dire qu'ils ont laissé la valeur par défaut, qui est maintenant à writeback.
Mais si cela signifie qu'ils ont remis l'ancienne valeur par défaut qui était ordered alors le reste est cohérent.

Le point concernant ext3 est erronné.
Avant, l'option par défaut était data=ordered qui est justement plus robuste que la variante data=writeback car elle garanti une écriture dans l'ordre et permettait aux programmes de faire les écritures en dilettante car le FS avait un mode quasi transactionnel.
Le mode writeback lui se rapproche plus du fonctionnement de ext4 en ne garantissant pas l'ordre des écritures, ce qui lui permet d'être plus performant.

Ce changement a été fait pour forcer la main aux développeurs à utiliser fsync() (qui a été optimisé) chaque fois que c'est nécessaire.

[mode=raleur]
C'est dommage de donner le lien vers l'article en disant le contraire.
[/mode]

un exemple de logiciel non commercial alors ?

Les freeware?

Mais c'est quoi alors ce problème? (vrai question)

Parce que tu ne le dis pas plus...