007 a écrit 2187 commentaires

C'est oublier la nature libre de Linux.
Si avoir des drivers un C++ était un gros avantage, il y aura un fork "populaire" de linux avec une interface C++. Mais ça n'existe pas...

Le noyau fixe un gestionnaire de signaux par défaut. D'où le comportement sur SIGTERM, etc... init n'a pas ce gestionnaire par défaut mais init peut installer un gestionnaire de signaux (via signal() ou sigaction()...).

Par contre, tu as raison, les signaux SIGKILL et SIGSTOP ne peuvent normalement être ignoré par un processus et c'est donc le noyau qui inihibe ces signaux pour init. C'est un cas particulier de init (une fois qu'il a installé un gestionnaire de signaux).

man 2 kill

It is impossible to send a signal to task number one, the init process,
for which it has not installed a signal handler. This is done to
assure the system is not brought down accidentally.

Par défaut il n'y a pas de gestionnaire de signaux pour init. Libre à init de l'installer.

J'ignorais que connaitre OpenBSD était un prérequis pour faire un commentaire ici.

Je ne connais pas OpenBSD et je me branle de ce truc laid comme poux.
Moinsser moi.

Ce n'est pas la peine de le moisser comme des oufs.
Quand une distribution sort, il y a toujours (ou presque) des screenshots (dans la news ou les commentaires).
Sa requête est totalement légitime même si elle est déplacée dans le cas d'OpenBSD.

> Il existe une communauté qui souhaite rester sur de vieilles méthodes

Ben regardes le code de Linux pour voir comment code les "vieux" (dont la moyen d'âge ne doit pas dépasser les 35 ans).

Conseil : Prévois du café et une boîte d'aspirine.

Et si c'est compliqué, ce n'est pas à cause du C mais car un noyau est compliqué.

Tout est dans le titre.

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/(...)

Ben utilises Alsa.

Les gens n'ont pas d'humour. Je n'ai dit pas que le C était meilleur que le C++ ou l'inverse.
Il est piquant de voir qu'un commentaire neure peut déchainer autant de [-].
Sûr que les pro C ont autant noté [-] que les pro C++.

Apparament la présence de "KDE" et "Gnome" ou "C" et "C++" en même temps braque les gens. Même si on ne dit rien.

Je voulais dire que discuter des avantages du C par rapport aux avantages du C++ et vice versa relève de la "guerre de religion".

Je l'ai dit et vous le démontrez avec la pluie de [-] que j'ai reçu.

T'aimes pas KDE ?

Ben au moins on sait que ce que tu dis compte pour du flan. Puisque tu te fous d'argumenter quoi que ce soit et fais des jugements à l'emporte-pièce, monsieur Hervé Cauwelier .

> Mais je suis pas sûr de très bien comprendre.

Si t'as toujours pas compris quel est le meilleur des deux languages, j'y suis pour rien.
Compte pas sur moi pour nourrir le troll.

> C'est pour ça que j'ai viré Alsa

Trop fort.
De tout manière, OSS sera viré du noyau Linux (à partir de la branche 2.7).
Et si OSS a été mis en obsolete depuis Linux 2.5, ce n'est pas car les développeurs linux sont des abrutis.
De plus, je ne serais pas étonné que tu utilises OSS via l'émulateur alsa. En gros tu utilises alsa sans le savoir...

Merveilleux la pertinence de tes arguments.

Surtout n'argument pas tu pourrais te ridiculiser.

Pourquoi la version ppc et amd64 pour 10.1 n'est pas sortie en même temps que la version i386 ?

> Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?

Excellente question.
Fesons une analogie.
KDE => C++
Gnome => C

Voilà, tu as ta réponse.

Tu parles d'un problème de standard qui n'a rien à voir avec alsa.
Gnome utilise gstreamer (qui utilise esd ou arts ou alsa ou OSS et bientôt mad).
La tendance de fond ("voulue" par freedesktop) est d'avoir gstreamer (qui n'est pas un serveur de son) et mad (qui est un serveur de son en cours de développement).

Donc si tu fais une applis "freedesktop" compliant, tu as le choix entre gstreamer et ... rien d'autre.

Mad permet d'avoir du son pour un post X11 distant. Alsa ne marche qu'en local.

> 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.

... puisque tu le dis...

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.

Exemple de /etc/asound.conf (ou ~/.asoundrc):
pcm.!default {
type plug
slave.pcm {
type dmix
ipc_key 1234
slave {
pcm "hw:0,0"
period_time 0
period_size 8192
rate 44100
}
}
}

Lance plusieurs applis en même temps qui utilise la sortie par défaut.
Ça marche et t'as pas à changer d'API.

alsa permet aussi d'attaquer chaque voie d'une carte son.
Exemple "tout con" ici :

$aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AudioPCI [Ensoniq AudioPCI], device 0: ES1371/1 [ES1371 DAC2/ADC]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AudioPCI [Ensoniq AudioPCI], device 1: ES1371/2 [ES1371 DAC1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: V8233Pre [VIA 8233-Pre], device 0: VIA 8233-Pre [VIA 8233-Pre]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
card 1: V8233Pre [VIA 8233-Pre], device 1: VIA 8233-Pre [VIA 8233-Pre]
Subdevices: 1/1
Subdevice #0: subdevice #0

J'ai deux cartes avec 2 sorties dont une avec multiplexage (4 voies).
Pour utiliser la seconde voie de la première carte j'utilise (pour aplay) :
aplay --device=hw:0,1 ...

Pour la seconde carte, je peux lancer en parallèle 4 "aplay --device=hw:1,0". Le cinquième attendra qu'une voie soit disponible.

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

Donc alsa ROX et n'a pas de problème de conception. Par contre il manque peut-être une appli pour configurer asound.conf. Il manque peut-être à esd (ou n'importe quoi d'autre) de tirer profit des toutes les voies disponibles.

Il est possible d'"enrober" un drivers en C++ dans un module Linux. C'est "ugly".

> non ?

Oui. Mais c'est quoi le rapport ?
Si tu dis que esd doit être amélioré pour utiler au mieux les multiples sorties de la carte son (fournis par alsa), je suis d'accord.
Sûr que le mainteneur de esd accèptera des patchs pour avoir cette fonctionnalité.

> ton analogie ne marche pas du tout

Ben prends un terminal (sans screen), une carte graphique (sans _serveur_ x11) etc... si tu préfères.

> alors pourquoi on fait pas ça avec les cartes son ?

Rien à voir avec le réseau. Lorsque tu as une connexion réseau elle n'interfère pas avec le reste. T'as déjà mélangé t'as connexion linuxfr avec autre chose ?
Si la carte son a (par exemple) 3 sorties haut-parleur, il est logique (et c'est ce qui est _déjà_ fait) que le noyau mette à disposition des programmes 3 sorties. Si tu veux mélanger les entrées, ce n'est pas au noyau de faire ça.
Beaucoup de cartes sons ont plusieurs sorties (pcm) qui utilisent une seule sortie "physique". C'est le choix de la carte son. Ces cartes sons sont supportées et exploitées par les drivers alsa.

J'entend bien ton argument, le comprend parfaitement et pour tout dire, je suis d'accord.
Mais je trouve que tu "abuses" de cet argument.

> de mon point de vue une critique est la bienvenue, mais faut-il encore que celle-ci soit un tant soit peu constructive. Pour cela il faut nécessairement que cette dernière se base sur des observations ayant un minimum d'objectivité et un minimum de connaissances effectives sur le sujet faisant l'objet de la critique.

Il n'y a jamais de critique "ojective" et "constructive" de Debian ?
Un "ancien" de Debian trouve que le modèle Debian (testing/unstable/experimental) sucks :
http://lists.debian.org/debian-devel/2004/10/msg01353.html(...)
Puisque qu'il critique Debian, il ne peut pas être "objectif" et "contructif" ?
A partir de quand on est "objectif" et "contructif" ? Avec Debian on a souvent l'impression que la barre est placée très très très haut.

> l'objectif principal pour Debian

Certe. Mais les objectifs de Debian peuvent être critiqués. Si on ne peut pas critiquer les objectifs ou le mode de fonctionnement de Debian, si dès qu'il y a quelque chose qui "sucks" on l'explique par les objectifs de Debian, alors (encore un fois) on ne peut pas critiquer Debian (ou alors les développeurs mais c'est un coup bas).

> le nouvel installateur

J'espère qu'il a pris compte des critiques :-)

> L'objectif principal pour Debian est d'offrir avant tout un maximum de liberté

L'objectif est fort respectable.
Mais Debian ne me donne pas la "liberté" d'installer la distribution sur AMD64. Debian ne me permet pas d'avoir des logiciels récents et supporté, etc...
Donc la critique sur ces points est tout à fait justifiées et aussi en tenant compte des objectifs de Debian.

> il n'est pas question de _favoriser_ l'une plutôt que l'autre de quelque façon que ce soit

Mais c'est incohérent dans la pratique et aussi vu les objectifs. Actuellement on peut installer de "vieux" programmes partout sauf sur AMD64. Tu trouveras _beaucoup_ plus de personne qui aimerais avoir le choix (la libertée) entre i386 et AMD64 que entre arm et m68k. Tu trouves que la libertée y gagne en proposant arm au-lieu de AMD64 ?
Qu'on soit bien d'accord, j'ai rien contre le port de Debian sur arm. Par contre je trouve "abhérant" de restreindre la liberté d'une majorité de personne (ou d'alourdir le projet) pour une minorité de personnes.

> La liberté offerte par Debian la rend hautement modulable (il suffit de voir le nombre de sous-projets ou de distributions basées sur Debian) ; maintenant il est vrai qu'une telle modularité peut rebuter et apparaître complexe aux yeux de certains utilisateurs.

Bof... Gentoo est plus "modulaire" et offre plus de liberté (moins de port par contre). Fedora est très utilisé comme base pour d'autres distributions, etc.

Je suis bien d'accord avec la prise en compte des objectifs de Debian. Je ne les ignores pas. D'ailleur je m'éforce toujours de prendre en compte les objectifs.
J'ai testé une Gentoo alors que les distributions sources ne sont pas ma tasse de thé et qu'il est très probable que je n'installe pas à nouveau une Gentoo. Mais en tenant compte des objectifs de la distribution, Gentoo est une réussite (le "long" compte rendu est ici : http://linuxfr.org/~ehoebadoag/15732.html(...) ).
En tenant compte des objectifs de Debian, désolé, mais pour moi Debian "sucks" (pour faire court :-)).
Si l'objectif de Debian est de faire un "terrain" de jeux pour les développeurs/testeurs avec testing/unstable/experimental alors Debian est bien. Mais je n'ai pas vu ça dans les objectifs.

Et ?

La concurrence d'accès pour le son est gérée. Si la carte ne supporte qu'un son à la foi, il n'y en a qu'un qui peut utiliser la carte. Point barre.

Si t'as une carte TV, tu vas pas demander au noyau de permettre l'accès concurrent à la carte TV pour regarder en même temps TF1 et CANAL+ si t'as carte TV n'as pas deux tuner. Ça n'a pas de sens. C'est la même chose pour les cartes sons. Si au niveau noyau il n'y a qu'une sortie son ... alors il n'y a qu'une sortie son...

> Pourquoi devrait-on avoir besoin d´un serveur de son ?

... J'ai même pas envis de répondre tellement ça me souâle comme remarque.

> On est en 2004

Merci pour l'info

> il serait temps que Linux fasse son boulot de système d´exploitation et virtualise le matériel pour qu´on ait pas à ce soucier de combien d´applications l´utilise en même temps.

Dans un OS, il y a deux partie. La partie utilisateur (par exemple esd) et la partie "basse", proche du noyau. Pour toucher ajouter des fonctionnalités à la partie "basse" du système il faut de SOLIDES raisons. Si le mixage peut-être fait un userland, il faut le faire un userland. Je n'ai pas envis d'un freeze système car le mixeur de son c'est mélangé les crayons. Ceci est vrai maintenant et sera toujours vrai en 2184.

> C´est ridicule qu´un système d´exploitation si moderne ait une gestion de son aussi archaique.

Tu juges alsa archaïque _uniquement_ car il n'y a pas de mixer par défaut. Bravo.

> Imaginez que deux applications ne puissent pas accéder au disque dur en même temps et qu´on doive passer par un "serveur de disque" !

Ou tu veux en venir ?

> Oui je sais Alsa fait cela quand le matériel le permet, mais il ne le permet pas toujours.

Si la carte ne le permet pas, alsa ne le permet pas. Je ne vois pas le problème.

> Oui je sais, il y a le plugin dmix qui est censé pouvoir faire cela, mais ca ne semble pas etre souvent installé par défaut et configuré de manière générique.

Voilà, on tombe sur un problème de configuration par les distributions et non sur l'OS (par basse). C'est beaucoup mieux.

Pour info, dmix n'est pas fait par le noyau mais pas la librairie alsa. Ça ne demande pas de "virtualisation" niveau noyau. Tant mieux.

PS : dmix sucks avec mplayer. Je ne sais pas pourquoi.