Ramso a écrit 2266 commentaires

Note que le modèle de développement a évolué : les DD se constituent en équipes pour les gros paquets et il y a aussi des sponsors de candidats qui peuvent alors uploader des paquets avec l'aval de leur mécène.

Alioth va encore plus loin parce que l'équipe peut aussi bien inclure des utilisateurs dans l'équipe.

Tu peux utiliser la technique Knoppix qui consiste à récupérer ses fichiers de configurations, surtout XF86Config-4.

Je suis sûr qu'il y a l'équivalent des destructeurs dans l'API du noyau et qui est appelé par exemple quand on retire un module (rmmod).

Ou alors un NDM général dans le corps de l'article (la partie grise) mais là ça fait « ho j'ai oublié de vous parler de ça... et de ça ! et aussi ça ! ».

On a bien senti que vous avez retenu la news pour la compléter avec l'actualité récente.

L'effet n'est sûrement pas le même à 256 Mo qu'à 512 mais viens de me souvenir pourquoi on limitait à 256 : on faisait tourner un deuxième Tomcat avec 256 Mo alloués et un Apache devant avec mod_jk pour répartir la charge. Bien sûr ça fait bricolage par rapport à une véritable solution de haute disponibilité mais ça répondait à notre problème.

J'ajoute « absence d'élements Hx pour hiérarchiser les informations » (vous utilisez font+style) et « blocs de texte qui se baladent hors de P avec des br pour simuler les alinéas » à ce qui sera peut-être mon TODO. :-)

Je sais bien que faire du libre ne signifie pas forcément connaître les standards du web mais là ça la fout mal pour un site neuf.

Vous devriez trouver quelqu'un pour corriger les problèmes suivants :

- doctype non standard ;
- utilisation de l'attribut style ;
- entités pour les accents (on est en 2004 les gars !) ;
- javacript pour des effets de rollover triviaux en CSS ;
- utilisation inconsirée de tables pour caler la mise en page ;
- utilisation de l'élement font (on est en 2004 bis) ;
- images vides pour caler la mise en page (avec désactivation des marges en CSS en plus !) ;
- abus de div pour constituer une liste de liens ;
- mélange de syntaxe HTML et XHTML ;
- presque aucune balise meta pour le référencement ;
- mauvaise sémantique (pour résumer mes points) qui handicapent encore plus ce référencement.

Si personne chez vous peut le faire, je me propose de vous corriger tout ça. La redirection DLFP marche.

On m'a conseillé pour les serveurs de spécifier une taille fixe avec par exemple :

-Xms256M -Xmx256M

Comme ça la VM ne gonfle pas trop et lance le GC avant qu'il ne soit trop tard, avec le blocage qu'on imagine bien pour notre application qui attend son tour d'exécution. La libération se fera petit à petit, avec des latences de quelques secondes au pire.

Ook ?

Bon.

Qu'on joue au chat et à la souris sur Debian c'est une autre et je me suis vite lassé.

Mais que tu me reprennes systématiquement pour parler de conneries, d'arguments ou je ne sais quoi, faut arrêter !

J'ai pas à argumenter ou quoi que ce soit. Je fais pas une démonstration, je donne mon point de vue, je vis ma vie sur le site et si mes propos te plaisent pas, ben c'est con mais c'est la vie. Et je fais de même avec toi : les administrateurs pourront te confirmer que je t'ai rarement moinsé.

Je sais très bien ce qu'il en est d'OSS et d'Alsa et oui j'ai choisi de garder OSS et oui je suis un grand garçon et je sais ce que je fais et non je n'utilise pas les modules snd-*. Que ça te plaise ou non je continuerai comme ça jusqu'à ce que je trouve Alsa utilisable et j'ai traité personne d'abruti ; pourtant tu le mériterais.

Maintenant fous-moi la paix et va jouer ailleurs.

> ... puisque tu le dis...

Ben tu imagines une bibliothèque utilisable par un seul programme à la fois ?

> Renseignes toi un peu avant de dire des conneries. Alsa (alsa-lib en
> fait) fournit dmix. Si tu mets dmix par défaut, tous les programmes
> qui utilisent le son en profite.

Effectivement j'avais perdu de vue que dmix fait partie d'Alsa, donc finalement tout va bien, c'est implémenté comme il faut : mixer matériel pour les chanceux, mixer logiciel pour les autres mais sans sortir d'Alsa.

> Si ta carte n'a pas de multiplexage, utilise dmix (alsa-lib).

Qu'est-ce que j'en sais ! Enfin si je le sais, mais pensons aux utilisateurs de Fedora ou Ubuntu.

> Par contre il manque peut-être une appli pour configurer
> asound.conf

C'est pour ça que j'ai viré Alsa, marre de me battre avec 80 canaux à régler et au moindre écart, plus de son !

> beattles

Argh !! C'est pas un jeu de mots avec battle leur nom ! :-)

> Pour la sauvegarde j'hésite beaucoup je trouve que le format n'est
> pas génial et j'aurais bien fait un beau format en xml :D....

Je suppose que le format de Guitar Pro n'est pas librement utilisable ? Sinon tu devrais voir avec l'auteur de Gnometab pour utiliser un format commun ; peut-être même qu'il utilise déjà XML.

À noter l'intérêt de Supercopier : il est bien plus efficace pour copier de grands volumes de données et plus résistant à une interruption.

N'est-ce le cas pour les outils KDE ? Typiquement, en cas de problème, tu as le choix entre « Ok » ou « suivant / annuler » ?

Sans ouvrir beaucoup d'onglets, j'avais ce problème : crash systématique en cas de clic pour voter sur linuxfr et autres joyeusetés javascriptiennes.

Je suis bien content d'être revenu à la version 0.9.3 avec Ubuntu mais je crois savoir qu'ils ont backporté quelques corrections aussi. Je les laisse tester la RC, on verra bien s'ils l'estiment bonne pour le service (je suis passé en Hoary depuis).

Alsa offre un service d'entrée/sortie son avec API et tout . Si l'implémentation ne permet pas à Alsa d'être utilisée par plusieurs programmes en même temps, il y a un grave problème de conception. Ce n'est pas la première fois qu'une fonctionnalité qui n'est pas disponible matériellement est émulée logiciellement. Cf. les pilotes 2D et 3D.


je préfère utiliser l'API d'Alsa que d'avoir à choisir entre l'API d'ESD, Artsd, Dmix, etc.

C'est pour ça qu'ils sont aussi aigris quand ils deviennent avocats !

Et comment sont financés les artistes ?

Je te propose de remplacer ta souris par un vélo d'appartement et de faire du sport en musique. :-)

Le kernel même, le noyau dur, je suis d'accord.

Mais quand j'ai dans mon noyau un module de gestion de ma carte son (interface matériel/logiciel, transport de données, tout ça) et que la dite carte gère le mixage elle-même (hardware mixer), la moindre des choses pour un pilote c'est d'exploiter les capacités de mon matériel !

Je suis bien content que le module emu10k1, pas celui d'Alsa mais OSS -- j'ai jeté Alsa depuis des mois --, gère le mixage matériel et de ne pas avoir besoin d'ESD ou de 300 surcouches à la Jack qui ajoutent de la latence.

Maintenant effectivement, la question se pose pour les cartes son qui ne proposent pas de mixer matériel : implémenter un mixer par pilote, un module de mixer générique, un daemon en userspace ? Tant qu'on jette ESD on aura déjà fait un grand pas. :-)

> PAM ?
> Red Hat y a beaucoup bossé aussi.

Y'a pas de quoi se vanter ! :-D

> imprimerie

Ça m'intéresse particulièrement, j'aimerais avoir l'avis objectif d'un maquettiste sur Scribus.

J'insiste sur le côté objectif, je ne veux pas lire l'équivalent du test du Gimp par un intégriste de Toshop.

J'aurais déplacé la virgule au bon endroit :

« Bien entendu elle propose aussi un environnement complet, sous KDE 3.2.3 »

La joyeuse incertitude du français. :-)

>> Hmm, kmodule, c pas un truc vieux sous RedHat?

> Non, ça été fait pour FC3 comme indiqué précédement (à cause de
> udev).

Je sais pourquoi il dit ça : c'était le nom du système de chargement des modules dans le noyau 2.0 ou 2.2.

Je me souviens d'une page qui recensait les mauvaises utilisations de cat et autres outils d'Unix.

On devrait aussi faire une page sur les mauvaises utilisations de dist-upgrade. :-)

> Dans la debian, c'est XFree 4.3 :/

Tu peux te documenter avant de propager des conneries ?