Pour ton exemple de code play_sound() & co, je suis d'accord avec toi. Mais là tu balance le problème au serveur de son, qui lui va bien devoir tenir compte du fait que c'est multi-utilisateur ou alors tu vas encore devoir lancer plusieurs serveurs son... et pour moi le serveur son ne fait pas parti de l'OS (pas du kernel) donc il y a bien une appli qui doit en tenir comtpe à un moment ou un autre.
L'appli n'a pas à s'occuper du multi-utilisateur.
Sauf si elle veut l'exprimer à l'utilisateur pour par exemple lui proposer la possibilité de changer d'utilisateur, de lacner une appli en tant qu'autre utilisateur, etc.
sudo ne fait pas parti de l'OS, c'est une appli, et pourtant elle tien parfaitement compte du fait que l'OS est multi-utilisateur, d'ailleur c'est sa raison d'être.
Pour la plupart des applications effectivement elles n'ont pas à se soucier du côté multi-utilisateur, mais certaines appli comme sudo, les serveurs, et toutes les GUI qui les exploitent (cad les interfaces graphiques pour serveur, ou bien Gnome et KDE qui pourrait très bien exploiter sudo plutôt que de laisser l'utilisateur taper ca à la main)
[^] # Re: ?
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
L'appli n'a pas à s'occuper du multi-utilisateur.
Sauf si elle veut l'exprimer à l'utilisateur pour par exemple lui proposer la possibilité de changer d'utilisateur, de lacner une appli en tant qu'autre utilisateur, etc.
sudo ne fait pas parti de l'OS, c'est une appli, et pourtant elle tien parfaitement compte du fait que l'OS est multi-utilisateur, d'ailleur c'est sa raison d'être.
Pour la plupart des applications effectivement elles n'ont pas à se soucier du côté multi-utilisateur, mais certaines appli comme sudo, les serveurs, et toutes les GUI qui les exploitent (cad les interfaces graphiques pour serveur, ou bien Gnome et KDE qui pourrait très bien exploiter sudo plutôt que de laisser l'utilisateur taper ca à la main)