Chargement...
 
[Voir/Cacher menus de gauche]
[Voir/Cacher menus de droite]

1 - La documentation et les nouvelles de LinuxMAO

Dernier post
Page : 1/4   -   Aller directement à la page : 1  2  3  4 

[FERMÉ] limits.conf / watchdog

olinuxx utilisateur non connecté France
Coucou, de ce que j'ai compris, les nouvelles debian ont changé l'emplacement du fichier limits.conf, du coup, ça va pas tarder à arriver dans les distributions de cette famille (c'est déjà là sur lucid lynx).
Du coup, je pense qu'il faut centraliser l'info de l'emplacement sur une page et linker à partir des autres pages quand on en a besoin, sinon, ça va être un bordel sans nom à maintenir.
Du coup, l'idée de JY d'une page dédiée à la 10.04? n'est pas la bonne, mais elle a le mérite d'exister. Je pense plus à un paragraphe dans la page PAM

Qu'en pensez vous ?
a+
Olivier

PS : les pages que j'ai repéré et qui sont concernées :
Accès temps réel pour les applications 10_04?
PAM
Débuter - survol du système
Tuto Jack premier lancement
... il y en a surement d'autres, à vos coms' wink

jy_moustache utilisateur non connecté
salut

de manière générale, je trouve que cette page est mal signalisée. beaucoup de retours sur les forums concernent la non-lecture de cette page....

donc oui, il faut impacter les modifs et oui il faut remanier tout ca, et oui il faut centraliser. on ne devrait pouvoir trouver les infos concernant l' accès temps réel que sur cette page. pour l'instant on la trouve plusieurs fois en plusieurs endroits.

je pense qu'il faudrait en fait réorganiser la page complétement afin de la réécrire et de la simplifier, et surtout il faudrait qu'on soit plus pédagogue... wink

jy

PS : tu as oublié les pages optimiser ubuntu...

jy_moustache utilisateur non connecté
Citation :
Il conviendra de faire le tour des pages concernant les distributions car l'info concernant le limits.conf doit être impactée sur un paquet d'entre elles.

je pense que c'est justement ce qu'il ne faut pas faire.
a mon avis, une seule page doit regrouper les méthodes de configuration du limits.conf pour toutes les distributions.
ensuite on crée un lien dès qu'on en a besoin...

jy

olinuxx utilisateur non connecté France
Oui JY, tu as parfaitement raison, j'ai écris mon message trop vite, l'idée est de faire le tour des pages des différentes distributions et de virer les indications concernant limits.conf en linkant vers la page dédiée.

Voilà, c'était ma faute, j'ai écris trop vite lol
Mais heureusement, JY veille wink

a+
Olivier

PS : les pages concernées :


pianolivier utilisateur non connecté France
Citation :
une seule page doit regrouper les méthodes de configuration du limits.conf pour toutes les distributions.

completement d accord, mais ca n est pas aussi facile :

il y a quelques semaines, en visitant la page de mandriva je me suis apercu qu elle contenait des infos tres interressantes sur la configuration du RT, j ai contacte l auteur pour lui demande la permission de deplacer ces infos dans la page concernee, ce qu il a refuse legitimement, mais au dela c est pose le probleme de se contenter de copier les informations sur la bonne page, quitte a avoir un doublon.
l auteur a a nouveau refuse, arguant qu il avait pris de temps de faire ca pour sa distribution et non pour ces retardes ubuntuistes ou autres deviants gentooers

je n ai rien fait, mais ce genre d infos demandent a etres repechees de toute facon, et centralisees pour que les utilisateurs de toutes les distrib aient toutes les infos, et aussi car c est plus facile a linker dans les forums wink

apres, si vous voulez retirer des choses des pages sur les distributions car "c est en double" vous allez vous faire des ennemis
au contraire il en faut un minimum, puis un lien sur la page dediee car avoir une page centrale "RT" pour toutes les distributions a un inconvenniant : elle n est pas integree correctement a la trame de lecture de la doc sur la distribution, mauvaise BOX, ou impossibilite d utiliser la mise en page "page precedente / page suivante"

oliv'

olinuxx utilisateur non connecté France
Coucou zissi !

Je viens de retaper un peu le texte, la mise en forme, et tout le toutim sur la page PAM. Dites moi ce que vous en pensez. Quand ça sera bon, j'impacterai les modifications nécessaires sur les pages connexes.

a+
Olivier

PS :


olinuxx utilisateur non connecté France
Plouplicot !
J'en ai profité pour intégrer une double définition du temps réel dans le glossaire. Je me demande également si les définitions realtime-lsm et realtime preemption ne devraient pas être remise au gout du jour ... (question rhétorique s'il en est wink )

Pour ce que tu dis pianoliv', je comprends tout a fait ce que pensent les gens qui font les pages, et je pense qu'il faut respecter ça dans la mesure où ils respectent aussi le fait qu'ici c'est un wiki. Du coup, pour couper la poire en 2, je pense qu'il faut simplement insérer un lien vers la page PAM dans les pages des distributions dans un style "pour plus d'informations, veuillez consulter la page Accès temps réel pour les applications". C'est OK pour vous ?


a+
Olivier

toujours PS :


youki utilisateur non connecté
Citation :
il y a quelques semaines, en visitant la page de mandriva je me suis apercu qu elle contenait des infos tres interressantes sur la configuration du RT, j ai contacte l auteur pour lui demande la permission de deplacer ces infos dans la page concernee, ce qu il a refuse legitimement, mais au dela c est pose le probleme de se contenter de copier les informations sur la bonne page, quitte a avoir un doublon.
l auteur a a nouveau refuse, arguant qu il avait pris de temps de faire ca pour sa distribution et non pour ces retardes ubuntuistes ou autres deviants gentooers

je n ai rien fait, mais ce genre d infos demandent a etres repechees de toute facon, et centralisees pour que les utilisateurs de toutes les distrib aient toutes les infos, et aussi car c est plus facile a linker dans les forums wink

apres, si vous voulez retirer des choses des pages sur les distributions car "c est en double" vous allez vous faire des ennemis
au contraire il en faut un minimum, puis un lien sur la page dediee car avoir une page centrale "RT" pour toutes les distributions a un inconvenniant : elle n est pas integree correctement a la trame de lecture de la doc sur la distribution, mauvaise BOX, ou impossibilite d utiliser la mise en page "page precedente / page suivante"

oliv'


eek Reaction bizarre tout de meme... enfin bon je vais pas entamer une polemique. Mais a partir du moment ou les infos sont sur le site, elles n'appartiennent pas a leurs auteurs non? Qu'on demande a un auteur pour faire des modifications, soit, mais si c'est si clairement anti-coommunautaire je pense qu'on peut passer outre, voire juste paraphraser l'original? Et puis bon tout le temps (et pas qu'un peu) qu'ont passe Olinuxxx et les autres sur ce site meritent bien des retours d'ascenseurs...
bon bref, si y'a le moidre truc qui peut vous servir dans ce que j'ai fait ou que je ferais, n'hesitez pas.

olinuxx utilisateur non connecté France
copie d'un message privé de youki :
Citation :
Salut, j'ai regarde vite fait la page en question. J'ai juste 2-3 remarques.

Citation :
Ce fichier s'appelle pour la majorité des distributions : limits.conf, mais il peut également se nommer audio.conf dans certaines distributions. De plus, il ne se trouve pas au même endroit selon votre système, il va donc falloir le localiser


C'est peut-etre un peu compliquer les choses, meme si je suppose que c'est ecrit dans l'idee d'avoir une doc qu'il n'y aura plus a retoucher plus tard.

Tout simplement (sauf erreur de ma part), dans Debian le fichier qui regle les priorites pour le temps reel des applications audio s'est vu attribuer un fichier specifique. /etc/security/limits.d/audio.conf, ca s'est fait apres discussion avec d'autres devs Debian pour des raisons de "debian policy", securite, etc... mais je ne retrouve plus le fil sur http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/ ou il y avait eu ce debat (liste de discussion interessante a suivre d'ailleurs puisqu'elle concerne non seulement Debian mais aussi du coup tout ses derivees, particulierement Ubuntu puisque les packageurs Ubuntu et les devs Debian ont de plus en plus tendance a y bosser ensemble).

Bref, tout ce blablah (que tu connaissais sans doute deja) non seulement pour etaler ma science, mais surtout pour dire que ca ne devrait concerner que Debian et ses derives cette histoire de /etc/security/limits.d/audio.conf, du coup faudrait peut-etre juste le preciser.

Citation :
cd / locate limits.conf


Ben ca veut dire qu'il faut mettre a jour la base de donnee, donc faire un # updatedb ou un sudo updatedb avant. Et le cd / avant ne me semble pas indispensable.
Bref c'est peut-etre compliquer un peu les choses pour un debutant, je sais pas. J'aime beaucoup la commande locate qui est tres efficace, mais est-elle utile dans ce cas a partir du moment ou l'utilisateur sait qu'il doit regarder soit /etc/security/limits.conf, soit /etc/security/limits.d/audio.conf? Y'a pas des milliards de possibilites.

Normalement pour Debian et les prochaines Ubuntu, /etc/security/limits.d/audio.conf devrait etre automatiquement cree ou active a l'installation de jackd1 ou jackd2 (sous reserve que l'utilisateur reponde oui a la question posee) ou par la commande # dpkg-reconfigure jackd1 (ou jackd2 si c'est celui qu'on utilise). En fait dans tout ca c'est Ubuntu qui complique un peu les choses puisque ca change selon la version qu'on utilise. Mais dans les prochaines versions ca devrait etre identique.

Mais du coup je comprends que c'est pas simple a expliquer simplement tout ca, et je sais pas trop comment le faire. Bon courage.

PS. J'ai retrouve je crois la discussion qui a mene a ce changement dans les pages de bugs de Debian :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23507248


olinuxx utilisateur non connecté France
Merci youki pour ce retour, en effet, il est possible de faire plus simple, je vais re-ré-écrire (!) en tenant compte de tes remarques. Merci pour le lien chez bugs.debian

je vais remplacer le locate limits.conf par un find / -name limits.conf

a+
Olivier, qui part de ce pas re-ré-écrire la page wink
on lâche rien michel !!!

encore PS :


youki utilisateur non connecté
Citation :
je vais remplacer le locate limits.conf par un find / -name limits.conf

Hum, c'est vrai que je suis un tres debianocentre, sur le moment j'avais pas pense que le fichier pouvait etre encore ailleurs sur d'autres distributions, d'ou la necessite d'une commande. Au temps pour moi.

olinuxx utilisateur non connecté France
Citation :
Hum, c'est vrai que je suis un tres debianocentre, sur le moment j'avais pas pense que le fichier pouvait etre encore ailleurs sur d'autres distributions, d'ou la necessite d'une commande. Au temps pour moi.


Ca serait bien si des gens qui utilisent d'autres distributions que debian et ubuntu nous disent où se situe ce fichier chez eux. wink

En fait j'ai surtout modifié/remplacé le locate par le find pour le coup du updatedb car si la commande find... mettra plus de temps que le locate, elle sera juste et ponctuelle alors que, comme tu l'as précisé, si le updatedb n'est pas fait régulièrement, le locate, même s'il est bien plus rapide que le find, retournera une fausse réponse. Et vue que cette page doit s'adresser surtout aux débutants... cool

a+
Olivier

c'est moi le PS :


olinuxx utilisateur non connecté France
Coucou !

Je viens de rédiger une petite intro à but explicative/pédagogique.

J'ai quelques questions dont les réponses me permettront de continuer cette page :

  1. existe-t'il d'autre(s) méthode(s) pour l'attribution de droits spéciaux ? (Je pense notamment à l'ancienne méthode realtime-lsm)
  2. Sont-elles encore d'actualité ?
  3. Je pense que dans cette page devrait figurer une explication sur la gestion de priorité concernant le watchdog interne à Jack, du coup :
    1. Ce watchdog est-il lancé automatiquement par Jack ?
    2. comment fonctionne l'histoire de sa priorité ?
    3. Il me semble avoir compris que ce watchdog doit avoir une priorité de 99, est-ce exact ?
    4. du coup, comment régler les priorités des autres applications par rapport à ce watchdog ?
    5. Est-ce que l'on doit voir ça de la manière suivante :
      • watchdog = priorité 99
      • jack = priorité 89
      • autres applications = priorié 79
      • qu'en est-il des ALSA et autres serveurs son (pulse, esd,phonon, ...)

Voilou, pas mal de question car c'est quelque chose que je n'ai jamais fouillé et je ne veux pas écrire de bêtise dans une page de documentation aussi critique que celle là.

Mesdames et messieurs, à vos claviers ! Rendez moi (et nous tous d'ailleurs) plus intelligent ! cool

a+
Olivier

c'est moi le PS :


youki utilisateur non connecté
Citation :
En fait j'ai surtout modifié/remplacé le locate par le find pour le coup du updatedb car si la commande find... mettra plus de temps que le locate, elle sera juste et ponctuelle alors que, comme tu l'as précisé, si le updatedb n'est pas fait régulièrement, le locate, même s'il est bien plus rapide que le find, retournera une fausse réponse. Et vue que cette page doit s'adresser surtout aux débutants... cool

Entierement d'accord. Peut-etre meme conseiller de l'utiliser en mode administrateur/root pour eviter ces resultats :
find: "/proc/325/fd": Permission non accordée
find: "/proc/325/fdinfo": Permission non accordée
find: "/proc/326/task/326/fd": Permission non accordée
find: "/proc/326/task/326/fdinfo": Permission non accordée
find: "/proc/326/fd": Permission non accordée
find: "/proc/326/fdinfo": Permission non accordée
find: "/proc/327/task/327/fd": Permission non accordée
find: "/proc/327/task/327/fdinfo": Permission non accordée
find: "/proc/327/fd": Permission non accordée
find: "/proc/327/fdinfo": Permission non accordée
find: "/proc/328/task/328/fd": Permission non accordée
find: "/proc/328/task/328/fdinfo": Permission non accordée
find: "/proc/328/fd": Permission non accordée
find: "/proc/328/fdinfo": Permission non accordée
find: "/proc/329/task/329/fd": Permission non accordée
find: "/proc/329/task/329/fdinfo": Permission non accordée
find: "/proc/329/fd": Permission non accordée
find: "/proc/329/fdinfo": Permission non accordée
find: "/proc/330/task/330/fd": Permission non accordée
find: "/proc/330/task/330/fdinfo": Permission non accordée
find: "/proc/330/fd": Permission non accordée
find: "/proc/330/fdinfo": Permission non accordée
find: "/proc/466/task/466/fd": Permission non accordée
find: "/proc/466/task/466/fdinfo": Permission non accordée
find: "/proc/466/fd": Permission non accordée
find: "/proc/466/fdinfo": Permission non accordée
find: "/proc/473/task/473/fd": Permission non accordée
find: "/proc/473/task/473/fdinfo": Permission non accordée


Et je n'en ai mis qu'une petite partie. Alors qu'en root :
# find / -name limits.conf
/etc/security/limits.conf


olinuxx utilisateur non connecté France
Récapitulatif :
  • Vérifier l'emplacement du limits.conf sur un maximum de systèmes
    • sur les anciennes debian /etc/security/limits.conf
    • sur les nouvelles debian et dérivé (à partir d'ubuntu 10.04) /etc/security/limits.d/audio.conf
    • sous gentoo : /etc/security/limits.conf (merci pianolivier)
    • sous mandriva cooker x86_64 : /etc/security/limits.conf (merci shikamaru)
    • sous Zenwalk : /etc/security/limits.conf (merci Ejis)
    • sous Archlinux : /etc/security/limits.conf (merci acieroid et gegarchie)
    • sous slackware : pas de PAM donc de limits.conf d'origine, il faut utiliser set_rlimits (réglage direct dans le kernel) par l'interméiaire de etc/set_rlimits.conf (merci appzer0)
  • Ecrire quelque chose sur le watchog de Jack :
  1. existe-t'il d'autre(s) méthode(s) pour l'attribution de droits spéciaux ? (Je pense notamment à l'ancienne méthode realtime-lsm)
  2. Sont-elles encore d'actualité ?
  3. Je pense que dans cette page devrait figurer une explication sur la gestion de priorité concernant le watchdog interne à Jack, du coup :
    • Ce watchdog est-il lancé automatiquement par Jack ?
    • comment fonctionne l'histoire de sa priorité ? Il me semble avoir compris que ce watchdog doit avoir une priorité de 99, est-ce exact ?
    • du coup, comment régler les priorités des autres applications par rapport à ce watchdog ? Est-ce que l'on doit voir ça de la manière suivante :
      • watchdog = priorité 99
      • jack = priorité 89
      • autres applications = priorité 79
      • qu'en est-il des ALSA et autres serveurs son (pulse, esd,phonon, ...)

a+
Olivier

toujours ce foutu péhèsse :


pianolivier utilisateur non connecté France
Citation :
Vérifier l'emplacement du limits.conf sur un maximum de systèmes

sur gentoo : /etc/security/limits.conf
Citation :
existe-t'il d'autre(s) méthode(s) pour l'attribution de droits spéciaux ? (Je pense notamment à l'ancienne méthode realtime-lsm)

ca vaudrait le coup de citer realtime-lsm, pour des raisons "historiques" ?
sinon d apres ce que je comprend, la methode d appzer avec set_rlimits est bien une alternative a PAM non ?
ca vaudrait aussi le coup de citer ca

Citation :
Je pense que dans cette page devrait figurer une explication sur la gestion de priorité concernant le watchdog interne à Jack, du coup :
Ce watchdog est-il lancé automatiquement par Jack ?
qu'en est-il des ALSA et autres serveurs son (pulse, esd,phonon, ...)

bonne question, aucune reponse

et voici un truc repeche dans le wiki de mandriva pour complement d'infos et peut etre a integrer :
Citation :
Vous pouvez avec le seul fichier limits.conf, par exemple :
* cet utilisateur à le droit de se réserver (tant) de mémoire vive.
* ce groupe d'utilisateur voit tout ses process obtenir (telle) priorité.
Une priorité se définit dans l' ensemble des processus actifs : chaque processus en fonction des autres

...

Memlock positionné à "sans limite" fait qu' il est possible pour toute application lancée par l' utilisateur "musicien" de s' attribuer autant de mémoire vive que possible physiquement. (attention à cette valeur : elle doit être ajustée pour votre système physiquement. À 2 Go de mémoire vive, vous pouvez peut-être attribuer 1 Go et plus à un utilisateur de station de travail de son. En dessous, pensez à toujours laisser environ 300 Mo pour le système, et bloquez le reste pour l' utilisateur audio. Au-delà de 2 Go, le "unlimited" ne devrait jamais poser de problème.) Sur l' exemple pris depuis le début, un système avec 2 processeurs de 3 GHz et 3 Go de mémoire vive, un /tmp de 1 Go et un /dev/shm de 500 Mo en TMPFS sont montés, la valeur de memlock est sur "unlimited" et tout semble ok.

...

La valeur nice définit cette priorité dans l' ensemble des processus actifs. Cette valeur à -15 fait que seules les applications ayant de -15 à -20 (aucune par défaut, puisque * tous positionnés à égalité à 0) seront prioritaires sur celles lancées par tout membre du groupe AUDIO. À noter qu' une page MAN est spécifique pour le fichier limits.conf. Veuillez vous reportez à la documentation sur PAM et ses divers fichiers pour en apprendre davantage.


bon a part ca ca avance doucement....smile

pianolivier utilisateur non connecté France
autre chose : on pourrai en profiter pour renommer cette page ?
PAM, limits.conf, temps_reel, que sais-je mais un truc plus simple a linker.... rolleyes

olinuxx utilisateur non connecté France
Citation :
autre chose : on pourrai en profiter pour renommer cette page ?
PAM, limits.conf, temps_reel, que sais-je mais un truc plus simple a linker.... rolleyes


Put... ! J'adore me dire que les zitouns communiquent d'une façon mystique entre eux wink Je vote pour applis RT car limits.conf ou PAM ne sont que la façon actuelle de gérer le temps réel pour les applications. Du coup au niveau temps réel, on aurait :
ça me semble cohérent et enclin à expliquer qu'il y a 2 niveaux de RT sous Linux : les applis et les noyaux. Ça vous va ? J'ai fais le changement, histoire de faire avancer le biniou, si ça ne vous va pas, c'est facile pour moi (en tant qu'admin général) de revenir à l'ancien nom ou à un autre, la discussion reste ouverte, ça n'est qu'une proposition.

Citation :
ca vaudrait le coup de citer realtime-lsm, pour des raisons "historiques" ?
sinon d apres ce que je comprend, la methode d appzer avec set_rlimits est bien une alternative a PAM non ?
ca vaudrait aussi le coup de citer ca

+1 pour citer le côté historique. C'est fait. Pour la méthode set_rlimits j'ai cru comprendre que ça pourrait générer des conflits. C'est donc à vérifier.

Citation :
Vous pouvez avec le seul fichier limits.conf, par exemple :
* cet utilisateur à le droit de se réserver (tant) de mémoire vive.
* ce groupe d'utilisateur voit tout ses process obtenir (telle) priorité.
Une priorité se définit dans l' ensemble des processus actifs : chaque processus en fonction des autres

...

Memlock positionné à "sans limite" fait qu' il est possible pour toute application lancée par l' utilisateur "musicien" de s' attribuer autant de mémoire vive que possible physiquement. (attention à cette valeur : elle doit être ajustée pour votre système physiquement. À 2 Go de mémoire vive, vous pouvez peut-être attribuer 1 Go et plus à un utilisateur de station de travail de son. En dessous, pensez à toujours laisser environ 300 Mo pour le système, et bloquez le reste pour l' utilisateur audio. Au-delà de 2 Go, le "unlimited" ne devrait jamais poser de problème.) Sur l' exemple pris depuis le début, un système avec 2 processeurs de 3 GHz et 3 Go de mémoire vive, un /tmp de 1 Go et un /dev/shm de 500 Mo en TMPFS sont montés, la valeur de memlock est sur "unlimited" et tout semble ok.

...

La valeur nice définit cette priorité dans l' ensemble des processus actifs. Cette valeur à -15 fait que seules les applications ayant de -15 à -20 (aucune par défaut, puisque * tous positionnés à égalité à 0) seront prioritaires sur celles lancées par tout membre du groupe AUDIO. À noter qu' une page MAN est spécifique pour le fichier limits.conf. Veuillez vous reportez à la documentation sur PAM et ses divers fichiers pour en apprendre davantage.

Cool, ça fait une bonne base explicative pour la page ! Merci pianoliv' (et aussi à celui qui à écrit ça sur le wiki de mandriva wink ) C'est intégré à la page PAM avec quelques modifs légères. Il faudra repasser dessus histoire d'être cohérent sur toute cette doc.


J'ai aussi démarré un début d'explication sur le watchdog interne de Jack pêché dans un forum.


Récapitulatif de ce qu'il reste à faire :

  • Vérifier l'emplacement du fichier de conf de PAM sur un maximum de systèmes
    • /etc/security/limits.conf : sur les anciennes debian, ancienne ubuntu, sous gentoo (merci pianolivier), mandriva cooker x86_64 (merci shikamaru), Zenwalk (merci Ejis), Archlinux (merci acieroid et gegarchie)
    • sur les nouvelles debian et dérivée (à partir d'ubuntu 10.04) /etc/security/limits.d/audio.conf
    • sous slackware : pas de PAM donc de limits.conf d'origine, il faut utiliser set_rlimits (réglage direct dans le kernel) par l'intermédiaire de etc/set_rlimits.conf (merci appzer0)
  • Au niveau de l'accès temps réel pour les applications
    1. existe-t'il d'autre(s) méthode(s) pour l'attribution de droits spéciaux ? (Je pense notamment à l'ancienne méthode realtime-lsm)
    2. Sont-elles encore d'actualité ?
  • Écrire quelque chose sur le watchdog de Jack : Je pense que dans cette page devrait figurer une explication sur la gestion de priorité concernant le watchdog interne à Jack, du coup :
    • Ce watchdog est-il lancé automatiquement par Jack ?
    • comment fonctionne l'histoire de sa priorité ? Il me semble avoir compris que ce watchdog doit avoir une priorité de 99, est-ce exact ?
    • du coup, comment régler les priorités des autres applications par rapport à ce watchdog ? Est-ce que l'on doit voir ça de la manière suivante :
      • watchdog = priorité 99
      • jack = priorité 89
      • autres applications = priorité 79
      • qu'en est-il des ALSA et autres serveurs son (pulse, esd,phonon, ...)
  • vérifier la méthode set_rlimits
  • comprendre/expliquer l'histoire du nice : http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-March/067904.html (merci Autostatic pour le lien)

Citation :
bon a part ca ca avance doucement....

et sûrement cool

a+
Olivier

et un p'tit slogan de manif' pour le PS :


olinuxx utilisateur non connecté France
allez, on change, un petit Anté Scriptum :


  • Je considère la vérification de l'emplacement du limits.conf terminée, c'est à présent expliqué dans la page PAM.
  • Concernant les méthodes alternatives, il faudra vérifier l'utilisation des set_rlimits (comme dans slackware), la méthode realtime_lsm est, pour moi, obsolète. J'ai ajouté le lien du site officiel de cette méthode dans le glossaire : Realtime_lsm, la dernière mise à jour e ce patch date de 2006 ... j'en conclue que c'est à l'abandon.


Récapitulatif de ce qu'il reste à faire :
  • Écrire quelque chose sur le watchdog de Jack : Je pense que dans cette page devrait figurer une explication sur la gestion de priorité concernant le watchdog interne à Jack, du coup :
    • Ce watchdog est-il lancé automatiquement par Jack ?
    • comment fonctionne l'histoire de sa priorité ? Il me semble avoir compris que ce watchdog doit avoir une priorité de 99, est-ce exact ?
    • du coup, comment régler les priorités des autres applications par rapport à ce watchdog ? Est-ce que l'on doit voir ça de la manière suivante :
      • watchdog = priorité 99
      • jack = priorité 89
      • autres applications = priorité 79
      • qu'en est-il des ALSA et autres serveurs son (pulse, esd,phonon, ...)
  • arrow lire ceci concernant le watchdog : http://tapas.affenbande.org/wordpress/?page_id=40
  • vérifier la méthode set_rlimits
  • comprendre/expliquer l'histoire du nice : http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-March/067904.html (merci Autostatic pour le lien)

a+
Olivier, qui attend la fin de sa lessive avant de décoller pour Aurillac !

Page : 1/4  [Suivant]
1  2  3  4 
Afficher les articles :
Aller au forum :

Documentation [Afficher / Cacher]

Faire un don
[Afficher / Cacher]

Connexion
[Afficher / Cacher]



Mégaphone [Afficher / Cacher]

calixtus06, 14:33, jeu. 28 mars 2024: Bonjour et bienvenue à b.vl :-)
calixtus06, 09:30, mer. 27 mars 2024: Bonjour et bienvenue à Noar :-)
olinuxx, 18:50, lun. 25 mars 2024: Bonjour et bienvenue à Ted Demore cool
olinuxx, 17:52, dim. 24 mars 2024: Bonjour et bienvenue à Noitavon cool
calixtus06, 11:07, jeu. 21 mars 2024: Bonjour et bienvenue à obds, ceric :-)
obds, 16:12, mar. 19 mars 2024: Cet édito est juste parfait. Trop beau !
olinuxx, 11:48, ven. 15 mars 2024: Bonjour et bienvenue à Jerry cool
calixtus06, 18:03, mer. 13 mars 2024: Bonjour et bienvenue à tanguero :-)
olinuxx, 11:01, dim. 10 mars 2024: Bonjour et bienvenue à lolo cool
bda, 16:59, sam. 09 mars 2024: Chapeau pour l'édito. Vous êtes au top les gars :-)
allany, 07:20, jeu. 07 mars 2024: Ça ne fait jamais de mal, c'est l'éditorial ! [Lien]
olinuxx, 19:52, mer. 06 mars 2024: Bonjour et bienvenue à TrkNrk cool