Boa Treize a écrit 3449 commentaires

Le SuSE 9.1 sortira le 23 avril, d'après un communiqué de SuSE. Le tests visibles sur le net se basent sur des versions beta qui ne sont pas rendues publiques.

Pour ! C'est pas génial, mais c'est pire dans l'autre sens.

Oui moi, j'en ai un dans le PC avec lequel j'écris ces lignes.

Essaye directement http://linuxfr.org/pub/(...) ou http://linuxfr.org/my/(...) si tu es connecté. Accepte les cookies si tu ne le fais pas déjà.

J'espère bien qu'il l'a dit, puisque c'est vrai. (Suggestion : lis les commentaires avant de poster un message.)

Oui je sais, j'avais hésité à acheter des polices Adobe à un moment ($99.00), sauf qu'en Europe ils les vendent quelque chose comme 120 euros... hors taxes, et en Irlande (21 % de TVA ou quelque chose dans le genre, plus qu'en France en tout cas). Enfin bref, on était à près du double du taux d'échange euro/dollar à la fin. ;-(

Si tu dépasses un certain montant (on va dire 170 euros, mais je n'ai aucune source à citer), tu dois payer la TVA et une taxe de douane (quelques autres pourcents, parfois zéro), sur l'ensemble de la transaction (objet, éventuelle taxe USA, éventuelle assurance, frais de ports). Pour l'instant, il n'y a pas de taxe aux USA sur les transactions effectuées sur des sites web.

Monsieur imr, chapeau bas, je vous salue.

s/fous/chercheurs/

Si tu uploades au fin fond du trou du cul du monde, on peut supposer que ton correspondant n'a qu'une ligne analogique pour faire le téléchargement, soit disons 4 Ko/sec. Dans ce cas, il faudra 347 jours pour effectuer le transfert. Je pense que la Poste (ou tout autre transporteur de paquet) est très avantageuse dans ce cas.

par DHL ou UPS ça peut donner un bon taux de transfert, par La Poste je ne crois pas

120 Go par ligne ADSL (64 Ko/sec d'upload, plutôt rare/optimiste/cher) : 21 jours et demi. Penser à multiplier par 4 pour les lignes ADSL les plus courantes. Je pense que la Poste bat ce délai à plate couture dans l'immense majorité des cas.

On a l'octet, le Ko (1000), le Mo (1000x1000), le Go (1000x1000x1000), etc.
On a aussi l'octet, le Kio (1024), le Mio (1024x1024), le Gio (1024x1024x1024), etc.
Bien sûr, rien n'empêche les fabricant de proposer des disques de 120 KMio...

Ne pas confondre expériences rigolotes et poissons d'avril ! Les modérateurs n'ont manifestement pas suivi le lien donné pour « Le Wifi over Pigeons » puisqu'on n'y parle pas du tout de WiFi mais de transfert de données par pigeons voyageurs (au moyen de DiskOnChips de 64 Mo chacun).

Résultat : sur une distance de 100 km, avec trois pigeons et un total de 4 Go transportés, les expérimenteurs ont obtenu 2,27 mbps soit mieux que de la plupart des lignes ADSL !

Tous les détails :
http://www.notes.co.il/benbasat/5240.asp(...)

(Dans le même genre, envoyer un disque dur de 120 Go par la Poste, ça donne un bon taux de transfert.)

Et alors ? Bientôt les poissons de Mai ! Pas de poissons en Mai ? Mais... en Mai, fais ce qu'il te plait ! Sans compter que le poisson, traditionnellement, c'est tous les vendredi.

Dans la famille "je dessers les interêts du Libre", je demande le petit dernier.

Où dans son mail peut-on croire qu'il fait du Libre ? C'est juste un utilisateur qui crache à la tronche de Microsoft...

Excellent ! Merci ! Je cours tester ça de ce pas. :-)

Sinon pour les lecteurs audio, XMMS utilise GTK+ 1, aRts 1.2 (dans KDE 3.2) utilise GTK+ 2, XMMS + KDE 3.2 = crash.

http://linuxfr.org/~boa13/9235.html(...)

Normaliser le son (s'assurer que l'échantillon de plus grande intensité a la plus grand valeur permise et mettre les autres échantillons à l'échelle) ne corrige pas les problèmes de volume sonore. Normaliser les volumes avant le codage Vorbis est tout sauf élégant.

ReplayGain (calculer l'énergie audible du signal à tout instant -- sur des durées de 20 ms seconde en fait -- et la ramener à une énergie standard -- 83 dB) corrige les problèmes de volume sonore. Stocker le ReplayGain en tant que métadonnée est une solution élégante, qui permet aux utilisateurs de modifier le ReplayGain sans avoir à reprendre toute la chaîne d'encodage depuis la source, et qui permet d'ignorer le ReplayGain si on en a envie, quand on veut écouter un album dans des conditions idéales par exemple.

Faire passer Esound par aRts (ou aRts par Esound, mais prenons le moins pire des deux) fonctionne effectivement, mais est un vaste gâchis de ressources, surtout sur les machines où c'est nécessaire, celles qui ont une vieille carte son, qui sont donc vieilles, et ont donc mieux à faire de leur CPU que de copier un flux audio en plusieurs endroits de la RAM.

Enfin bref, retour à la question initiale : qu'en est-il du support de ReplayGain sous Linux ?

Les logos jouent à cache-cache.

Information complémentaire intéressante : le champ MX (mail exchanger) du domaine gmail.com pointe sur les machines gsmtp51.google.com et gsmtp57.google.com. Il semble bien qu'il y ait toute une infrastructure en place.

Bon, alors, à quand la boîte email de 1 Go ? :)

À partir du moment où les exécutables KDE contiennent du code qui a besoin de libxinerama, alors libxinerama est nécessaire. Le fait que le code soit exécuté ou pas (cas d'un seul écran, et encore, y'en a peut-être besoin) n'a aucun rapport avec le fait que cette bibliothèque soit nécessaire ou pas.

Installer des paquets en provenance de Slackware-current sur une Slackware 9.1 n'est pas une bonne idée : ils peuvent nécessiter des versions de logiciels qui ne sont pas présentes dans Slackware 9.1, car apparues après sa sortie (précisément le problème qui t'arrive). Le seul moyen d'être sûr que ça marche sans clash c'est d'installer tous les paquets Slackware-current mis à jour depuis la sortie de Slackware 9.1 (c'est à dire en fait de passer à Slackware-current). Ce n'est pas non plus forcément une bonne idée, à moins que tu aimes l'instabilité relative du bleeding-edge.

Dans ton cas précis, il faut que tu installes XFree86 4.4, car c'est lui qui fournit libxinerama.so (et cette bibliothèque n'était pas fournie dans XFree86 4.3 sous Slackware 9.1). Ou alors, installe les paquets fournis sur le site de KDE, car ils ont eux été compilés sous Slackware 9.1, et fonctionnent directement dessus. (Tu peux tout à fait faire un upgradepkg entre les paquets KDE 3.2.1 de Slackware-current et ceux fournis par kde.org ; tu auras peut-être besoin de forcer l'upgrade s'ils ont exactement le même nom et la même version, ou d'indiquer le nom de « l'ancien » et du « nouveau » paquet s'ils ont des noms différents.)

Au fait, n'hésite pas à aller faire un tour sur http://www.slack-fr.org/(...) :)

Ça fait environ un an et demi que ça existe. Ceci dit, ça ne fait que quelque jours que Google l'a mis en première page.

Celle que je vous invite le plus à découvrir : Le Mur de Pan, de Philippe Mouchel (trois volumes géniaux).

Ensuite, j'ai tendance à lire un peu tout ce que scénarise Jean Dufaux, notamment Monsieur Noir (deux volumes), Beatifica Blues (intégrale, car la fin n'a jamais été publiée ailleurs), Samba Bugatti (trois volumes, plus un début de suite), Fox (cinq premiers volumes, puis des histoires plus indépendantes), Sang-de-Lune (au moins quatre volumes) ... et d'autres auxquels je ne suis pas encore arrivé.

Par ailleurs, une très grosse claque : Les Eaux de Mortelune. Les cinq premiers tomes sont un élément majeur de la BD moderne, les cinq suivants forment une histoire indépendante plus faible que la première partie, que l'on a beaucoup de mal à commencer vu le contraste avec la fin éblouissante de la première partie, mais qui s'améliore au fur et à mesure que l'on avance.

Également Finkel (cinq premiers tomes sympas, puis j'ai arrêté), Aquablue.

En mange, Akira bien sûr (un must), Gunnm aussi, et surtout Nausicaä. J'avais commencé à acheter Lone Wolf and Cub, mais je me suis arrêté pour cause de pognon (100 F par tome, 25 ou 27 tomes prévus).

(Bon, ça c'est que pour les miennes... Mon frérot en a des pas mal aussi - Mémoire de Sable, notamment, et puis il y a bien sûr tous les classiques...)

On passe à Slackware ! :-D

Les français ont choisi des conseillers régionaux et des conseillers généraux.