Un serveur est différent car généralement il doit gérer des accès parallèles et/ou différents utilisateurs.
Il est souvent soit proche du système multi-utilisateur de l'OS ou a son propre système multi-utilisateur.
Néanmoins, tu trouves des serveurs qui ne sont pas multi-utilisateurs ou qui ne gérent pas des requêtes en parallèle.
Par exemple, bittorrent n'a pas de notion d'utilisateurs et inetd peut t'éviter de rentrer dans l'enfer de faire un programme qui support des connections parallèles. Idem pour bind (sauf quelque cas) qui n'a pas de notion d'utilisateur.
Mais si tu insistes, tu peux aussi installer apache ou bind ou mysql (ce que tu veux) dans ton $HOME (ou /tmp, gnagnagna) et l'excécuter (faudrat utiliser un port supérieur à 1024).
Mais pour mysql et apache :
* propre gestion multi-utilisateur (pour apache c'est .htpasswd par exemple)
* gestion de requête en parallèle (apache peut tourner derrière inetd. Dans ce cas il te faut aussi ton propre inetd si tu installes apache dans ton $HOME).
* apache peut "binder" vers les comptes systèmes (http://.../~compte/(...)). Il doit être super utilisateur dans cas, idem pour utiliser suexec et d'autres "bricoles".
Bref, rien à voir avec gimp ou evolution ou tout un tas d'applis clientes que lance l'utilisateur.
L'utilisateur ne lance pas apache/mysql/bind/dbus. Ou alors c'est un développeur.
> Tout le monde a acces a /tmp
> /tmp est accessible a tout le monde
> il peut tout a fait faire un ftok("/tmp/monfichier",...)
> sachant que /tmp est accessible a tout le monde ?
J'ai déjà dit que "/tmp" est un problème.
T'as trouvé ton os à ronger, t'es content, tu remus la queue.
btw, windows a aussi son "/tmp".
Notes aussi :
man hier
/tmpCe répertoire sert à contenir des fichiers temporaires que l’on peut détruire régulièrement, par un script périodique, ou au démarrage du système.
Mais t'es libre de foutre des données dedans. C'est un défaut d'Unix, j'y reviens pas.
Si le développeur ne remarque pas qu'à chaque boot il perd la configuration de son programme, c'est à désespérer.
> Ce sont des utilisateurs, ils ne peuvent pas se logger mais le kernel ne fait absolument aucune difference entre nobody, root et logindemaman, ils sont tous traites de la meme maniere.
....
Je peut me loguer sur ma bécane, nobody non.
Je peut faire http://...../~moi/(...) mais http://..../~nobody/(...) ne marche pas.
ftp sur le compte nobody ne marche pas.
"su nobody" me retourne "This account is currently not available."
Certe au niveau noyau c'est le même chose mais un noyau ne fait pas un OS.
Donc mets tous les id de /etc/passwd à 0 et tu me feras plus chié.
> Super, je te fais un 'ls' modifie qui n'affiche jamais le repertoire .monrepertoire, subitement ca n'est plus un repertoire ?
Ben envoies un mail aux utilisateurs apache et nobody puisque t'as pas compris la différence. Au mieux le mail arrivera sur le compte root.
> C'est bien ce dont je te parles depuis le debut, ca se produit, et ca prouve que laisser qq'un ecrire un soft en lui disant que c'est mono-utilisateur peut aboutir a un soft qui ne tourne pas en multi-utilisateur.
Ben si je vire /tmp, tu n'as plus aucun argument.
Bref, t'as démonstration tient à l'existance de /tmp .
Bravo. Et ""bravo"" à ceux qui ont avalé ta ""démonstration"".
Mais avant (je fais dans le nostalgique), lorsqu'on entrait dans un forum, on enlevait ses chaussures :-)
Maintenant n'importe qui a un avis sur tout :
- Linux c'est trop GPL, ils ont viré pwc.
- ext3 c'est vieu et pourri comme conception, reiser4 roxor.
- Les développeurs Gnome sont nuls car ils utilisent gobject.
- Les développeurs Linux se foutent de notre gueule : la branche 2.6 prend trop de temps à se stabiliser.
- etc
Bref, une belle brochette d'expert.
Je n'ai pas le quart du huitième du niveau d'expertise de Linux ou Gnome et j'y réfléchis à 20 fois avant de critiquer leur choix.
Ben maintenant n'importe qui peut critiquer de façon virulente même s'il n'y comprend rien.
J'arrête pas de voir des commentaires avec des gros mensonges dedans qui ont des scores positifs.
Avant si je voyais un commentaire avancer un concept erroné, je le corrigais. Maintenant j'ai plus envis.
Avant on pouvait "ramener" l'ordre.
Maintenant il faut dire "amen" aux conneries les plus populaires :
- Les virus c'est une fatalité et Linux aura besoin d'un anti-virus comme Windows.
- Il faut faire comme les logiciels proprios et taire les trous de sécurité.
- etc.
Je ne serait pas étonné qu'un mec qui raisonne de façon favorable au proprio et à MS (pB pG pour le nommer) soit beaucoup plus plébiscité que si RMS ou Torvalds s'exprimait de façon anonyme sur linuxfr.
Et pB pG qui m'expliquait qu'il n'y avait rien à améliorer ici ...
Pire, il ne comprend pas qu'on puisse faire des recherches sur ça.
> Je connais plus d'un débutant qui a fait un programme qui stockait dans /tmp ou /home/debutant
Certe. J'ai moi même sur ma bécane quelques scripts avec les paths en dure.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Mais le non usage de $HOME se détecte très très vite.
Il faut être "réaliste".
Les problèmes de "/tmp" sont beaucoup plus importants car beaucoup plus difficile à trouver.
Biensûr on peut utiliser tmpfile() etc... Mais si le développeur ne connait pas ces fonctions son programme marchera sur plusieurs postes. La détection de l'erreur n'est pas "fulgurante" comme pour l'oublie de $HOME.
Enfin, les crakers adorent profiter de la mauvaise utilisation de /tmp.
Si le développeur ne connait pas tmpfile() et qu'il a besoin d'écrire des données temporaires il va peut être utiliser directement /tmp.
S'il ne prend pas quelques précautions de _sa propre initiative_ pour prendre en compte l'aspect multi-utilisateur, son programme ne sera pas multi-utilisateur compliant.
C'est LE point faible d'Unix.
Les autres trucs :
- IPC
- écriture dans /usr/share/no_where_and_ro
- non utilisation de $HOME
- etc
se détectent très très vites ou sont des erreurs de programmations (Par exemple une vérification du retour des appels système permet de localiser l'erreur).
Ces problèmes de sécurités sont en général fait par des programmes pas très multi-utilisateur compliant.
Tu vas dire que je suis en contradiction avec moi-même car je dis que les programmes n'ont pas à être multi-utilisateur compliant sous Unix !
Ben oui. Le problème de /tmp avec Unix est qu'il demande un effort de la part du développeur (ou ne le contraint pas) pour que le programme soit multi-utilisateur compliant.
Les dégâts se font très vite sentir et les problèmes de "/tmp" sont n°1 pour les trous de sécurité.
Voir cet article lwn : http://lwn.net/2000/1221/security.php3(...)
L'article est vieux et "presque faux" par endroit. Mais reste valable.
Unix a fait ici un erreur de conception assez grave et on peut se demander si ce problème sera corriger un jour (compatiblité oblige).
Il n'y a pas de fumé sans feu.
NB : je ne dis pas que c'est de la fautes des développeurs pour cacher une erreur de conception d'Unix...
> comme ça tous les utilisateurs peuvent avoir un temp différent. Ca évite les conneries à la /tmp.
Cool.
> C'est le fait d'être obligé d'utiliser une variable et pas un path absolu qui fait que tu es obligé de considérer que c'est du multi-utilisateur.
Imagines un appareil photo qui tourne sous Unix. Tout est en read-only sur l'appareil photo sauf /home/user (un cartouche flash).
Et comme le monde est bien fait, c'est $HOME. Dingue.
Si tu as gimp sur l'appareil photo, tu peux jouer avec.
Mieux, tu as deux cartouches flash.
Le second est sur /home/user2.
Pour que gimp marche alors que le premier cartouche n'est pas là, il suffit d'avoir HOME=/home/user2.
Même pas besoin d'un second compte !
Plus fort, tu peux lancer en parallèle :
- HOME=/home/user gimp
et
- HOME=/home/user2 gimp
C'est le même utilisateur et tu as deux gimp totalement séparés. C'est courant comme usage de $HOME.
En fait, pas besoin de compte du tout. Tout peut tourner en root (ce qui est généralement fait dans l'embarqué).
HOME n'est pas une variable qui dit :
- attention, système multi-utilisateur et c'est l'emplacement pour les données de l'utilisateur.
HOME dit :
- ici est l'emplacement pour les données. Et c'est tout ! Système multi-utilisateur ou pas.
Si tu veux deux gimp avec deux configurations différentes, il suffit de changer HOME.
Quoiqu'il en soit, coder en dure un chemin n'est JAMAIS une bonne idée.
$HOME/qqc car il y est obligé.
J'ai pas dit une appli mono-utilisateur pour toto dont le seul répertoire en écriture est /home/toto.
Sous unix que l'appli soit mono-utilisateur ou non (ce qui n'a pas de sens sous Unix...) c'est $HOME qu'il faut utilser.
> il va utiliser les IPC pour les communications inter-process
Et ?
Tu connais rien à IPC.
Pour avoir un identifiant ipc, tu utilises ftok(3) (c'est dans la doc).
ftok : Convertir un nom de fichier et un identificateur de projet en clé IPC système V.
Comme il n'y a que $HOME de dispo, tu utiliseras ftok ($HOME/ipc, ...).
T'es obligé. Terminé.
Si tu fais un serveur il faut utiliser /tmp/... . Mais je n'es jamais parlé pour le cas des serveurs !
> il va pas mettre de permissions dessus vu que c'est mono-utilisateur
Et pourquoi ?
Pour rien.
Si t'as besoin de changer les permissions, c'est (par exemple) :
chmod +w toto
L'umask est toujours respecté (la libc fait de même).
Toujours pas de problème.
> Developpeur Unix depuis 7 ans t'as dit, c'est bien ca ?
Ouais. T'as encore prouvé que t'y connais en rien Unix.
> Alors un programme qui utilise un nom fixe pour son fichier d'IPC(plutot qu'un nom d'user)
Si ce n'est pas un serveur, c'est stupide.
Si c'est pour un utilisateur (donc ce n'est pas un serveur), le fichier IPC sera basé sur $HOME/... . C'est obligé (voir plus haut).
> hors non, ca ne marche pas, sauf si le _programme_ tient compte du fait que plusieurs utilisateurs peuvent lancer le soft en meme temps.
Ben non. T'as faux.
Sauf si tu veux que les processus de plusieurs utilitsateurs _différents_ communiquent entre eux.
Donc c'est un serveur... et ce n'est pas le propos ici.
Suivant.
> Si, toutes celles ecrivant dans des fichiers fixes dans des repertoires accessibles a tous.
Et encore un couche.
Hors /tmp (et je reconnais que c'est un _réel_ problème) où peux écrire un utilisateur ?
Dans $HOME.
Donc si ce n'est pas un serveur il n'y a pas de problème.
L'appli ne va pas coder :
open("/usr/titi", O_CREAT)
Et ce car même pour le développeur ça ne marche pas !
> Faux, meme sans que personne se logge plusieurs utilisateurs ont des softs tournant sur un Linux, typiquement Apache qui tourne en nobody et d'autres process en root, meme chose pour les autres daemons.
Ce se sont pas des utilisateurs...
grep apache /etc/passwd :
apache:x:48:48:Apache:/var/www:/sbin/nologin
Nuance.
si je fais "who", j'ai jamais apache, named, etc.
Puis on voit que ça fait depuis longtemps que tu n'as pas utiliser apache car nobody n'est plus utilisé par apache depuis... j'ai oublié.
Conclusion :
Tu considères que le développeur fait un sabotage pour défendre ton point de vu.
Actuellement, il y a que le problème de /tmp qui tient la route.
Mais si. C'est indiqué avec la variable TEMP je crois.
Sous windows c'est C:\windows\system\temp.
Bref, il y a /tmp et dire le contraire, c'est se foutre de la gueule du monde.
Qu'on me dise pas que Windows est merdique au point de ne pas proposer l'équivalent de /tmp.
> pourquoi il faut dire aux développeurs de programmer en penssant multi-utlisateurs, pour qu'ils y pensent, même si c'est pas toujours utile.
Ben demande à un développeur de faire une appli pour Unix et lui disant bien que c'est pour une système avec un seul utilisateur. Tu vas voir, l'applis sera multi-utilisateur compliant. Marrant ça.
> Un programme comme Gnome qui ne propose pas la possibilité de lancer un programme en tant que autre utilisateur n'est pour moi pas multi-utilisateur.
Bravo. Gnome est un programme.
Tu as quelle version du programme Gnome ?
> ça c'est du multi-tâches et on s'en balance.
Manifestement, tu n'y comprend rien.
* Win 95 est multi-tâches et pas multi-utilisateur.
Tu vois la différence ? Impossible d'être plusieurs utilisateurs sur Win 95. Impossible d'avoir 2 explorateurs de fichier pour deux utilisateurs ,etc.
> Un programme multi-utilisateur, c'est un programme qui tient compte du fait qu'il y a plusieurs utilisateurs !!!
C'est l'OS qui est multi-utilisateur et pas un programme !
> Certaines applications doivent par contre être multi-utlisateurs,parcque c'est leur rôle d'en tenir compte, et je pense t'avoir donner suffisament d'exemple (Gnome, KDE, gdm, sudo, etc.)
Tu mélanges tout.
Bon, heureusement que depuis 30 ans, Unix ne fait pas ce que tu dis.
> sinon l'appli est mono-utilisateur
Il n'y a pas d'appli mono-utilisateur sous Unix (sauf serveur, et encore...).
> multi-threadé
T'es dans le brouillard le plus complet.
On peut être multi-utilisateur et pas multi-threadé. Ça existe.
On peut être multi-threadé et pas multi-utilisateur (win 95). etc.
Ça n'a rien à voir.
Sous Linux tant que personne se loggue, c'est mono-utilisateur et parfaitement multi-tache.
Et btw, Linux est aussi mono-utilisateur :
- boote avec "-init 1" ou "init=/bin/bash".
> Donc le programme utilise bien un des principes du multi-utilisateurs : l'isolation des données.
Qui n'est pas un principe multi-utilisateur (windows l'a fait:-)).
Ce marrant, aujourd'hui tout est multi-utilisateur. Protection de fichier, variable d'environnement, etc
Dans ce cas, oui tous les programmes sont fait spécifiquement pour le multi-utilisateur.
Pardon.
Le truc est que certains disent :
- Un OS multi-utilisateur a besoin d'applis faites spécifiquement pour le multi-utilisateur. Si l'appli n'est pas fait pour le multi-utilisateur alors l'appli ne peut pas être utilisées par plusieurs personnes à la foi.
Je dis qu'avec OS multi-utilisateur bien foutu, l'appli n'a pas à être codé spécifiquement multi-utilisateur pour être utilisé par plusieurs personnes à la foi (sauf sabotage du développeur qui stockent les données dans /tmp).
Tu donnes les raisons de $HOME. Mais le pouquoi pour un développeur ne t'intéresse pas.
Tu développes sous Unix ?
Si tu développes sous Unix et que tu te dis "où stocker mes donnée ?".
La réponse est $HOME car tu n'as pas le chois. multi-utilisateur ou pas.
Tu ne te dis pas :
- Je vais mettre mes données dans $HOME, ça va être super cool dans un contexte multi-utilisateur.
De même, avant de développer une applis, tu ne te dis pas :
- multi-utilisateur ou mono-utilisateur ?
Si multi-utilisateur alors faire ça, ça et ça et pour mono-utilisateur faire ça, ça et ça.
Dans 99 % les applis pour Unix sont développées sans penser à multi-utilisateur ou mono-utilisateur et qu'on utilise $HOME n'y change rien.
Restons sur $HOME.
Les gens disent :
- Si tu ne peux pas écrire partout mais seulement dans $HOME, c'est le preuve que tu tiens compte du multi-utilisateur ou que tu es sur un système multi-utilisateur.
Pourquoi ?
1- $HOME est obligatoire
2- Même sur un système mono-utilisateur il peut y avoir des parties en lecture seule. (montage en ro, ROM)
3- avoir un "truc" qui dit "ici tu peux stocker, ne perd pas ton temps ailleur" est bien pratique
$HOME est nécessaire même si ce n'est pas dans un contexte multi-utilisateur.
D'ailleur il est possible de booter sous Linux en mono-utilisateur et sans être root. Dans ce cas il y a pas de contexe multi-utilisateur et c'est toujours dans $HOME que tu peux stocker des données (si les conventions sont respectée).
> Réponse de 007 : ah mais sous linux c'est super con de faire ça, une appli qui écrit sa conf dans /tmp/
Ton exemple est con car même sous Windows c'est super con de faire ça et personne le fait.
Sous Windows il y a /tmp, pardon "C:\temp" et pourtant les développeurs windows ne mettent pas la configuration des applis dans "C:\temp". D'ailleur il y a depuis très très longtemps une variable d'environnement sous windows (depuis MS-DOS) pour indiquer où est le répertoire tmp.
Comme l'emploi de /tmp est évident pour tout le monde, je l'ignore.
Il n'y a pas de multi-utilisateur dans ton problème !
La question est :
- Où stocker mes données ?
Durant longtemps sous windows la réponse était :
- n'importe où
Sous Unix c'est :
- $HOME et d'ailleurs tu n'as pas le chois
> ah mais sous windows c'est super con de faire ça, une appli qui écrit sa conf dans un endroit qui ne dépend pas de l'utilisateur.
Encore très con.
Sous windows jusqu'à millénium (sorti en 2000 !) tu pouvais stocker tes données partout.
Sous Unix depuis 30 ans => $HOME.
Autre exemple, et ce n'est pas moi qui le dit :
- sous Windows il faut souvent être admin pour développer. Sinon tu ne peux pas enregistre un bidule machin dans la base de registre et l'applis ne marche pas. Il parait que c'est très courant et aussi pour Windows 2000/XP !SVP Utilisateur Windows confirmer ça car je ne suis pas un gros utilisateur de Windows. Mais ce que je peut dire de mon expérience, c'est qu'il faut être admin pour faire un paquet (installsheild) diffusable sous Win Xp. Donc pour faire du VB, j'étais admin...
Sous Unix tout est développé sans prévilège admin. Mes paquets rpm sont fait sous mon compte. Je peux compiler et utiliser tout Gnome sans jamais être admin. C'est comme ça pour tous les programmes (sauf les programmes qui réserve des "ressources sensibles", port réseau, etc).
> a fait que les développeurs font n'importe quoi, parfois, en écrivant dans le registre, dans Program Files ou ailleurs.
Les développeurs Unix ont souvent, très très souvent commencé par Windows.
Tu m'expliques le truc ?
> Mais tout ça n'a rien de technique !
Oui et non. C'est surtout historique. Or l'historique de Windows n'est pas brillant techniquement sur ce point.
Mais et je le reconnait volontier, MS avance à grand pas et les dernières moutures sont presques "parfaites" (sur ce point :-)).
> Sous linux un développeur peut parfaitement coder avec ses pieds et nous pondre un truc qui n'EST PAS multi-utilisateurs.
Comment ?
A part l'emploie de /tmp, vous ramez un peu.
On trouve des entreprises qui ont vendu des programmes qui merdaient dans un environnement multi-utilisateur Windows.
On trouve ça sous Unix ? Non.
C'est quoi alors le truc ?
Les développeurs Windows sont nuls ?
Non.
La culture des développeurs Windows ?
Non. 98 % des unixiens on commencés windowsiens.
La raison est simple :
Windows n'était pas multi-utilisateur. Puis Windows a eu un modèle multi-utilisateur très mal foutu (Win 95). Le tout sans protection au niveau système de fichier.
Après MS a voulu rectifier le tir. Mais il a fallu faire avec l'énorme base installée de programme, etc. On obtient pas la maturité d'unix (presque 30 ans!) en quelques mois et il y a des accrocs . Normal.
Il a fallu attendre Win XP/2000 (année 2000 !) pour que Windows ne diffuse plus de "mauvais" OS.
Le "problème" est là.
Mais fasse à ce problème, il y a des gus qui disent n'importe quoi (et pire, ils sont applaudis) :
- C'est aux applis d'être multi-utilisateurs (et l'OS ? non ?).
- Les développeurs Unix sont géniaux et ne font pas les conneries de développeurs Windows.
- Faut éduquer les développeurs Windows qui sont vraiment nuls.
- etc
L'environnement technique de Windows semble (preque) bon maintenant sur ce point.
Dans quelques années (3 ou 4 ans) on ne parlera plus d'"éduquer les développeurs" et autres bêtises pour Windows.
Ceci dit, je m'en branle de Windows.
Ce qui me fait chier, c'est que des raisonnement à la con (généralement pour nier les défauts techniques (vieu de plus) de Windows) s'installent tranquillement ici.
Tu va finir par regretter MS-DOS.
Oui sur un OS multi-utilisateur il y a des programmes qui tiennent compte de cet aspect.
Sinon tu vires gdm, login, who, etc et tu bootes en single user.
Quel est le but d'un OS multi-utilisateur ?
1- S'occuper de l'aspect multi-utilisateur
2- Demander aux applis de s'occuper de l'aspect multi-utilisateur
La réponse est 1).
Prends tous les sources de GNOME et compte le nombre de ligne qui s'occupe de l'aspect multi-utilisateur. Ça doit être ridicule. Moins de 0.001 %.
Mais continuez à affirmer que c'est le role des applis d'être multi-utilisateur. Quelle doivent être codée pour être multi-utilisateur, etc.
Lorsqu'une applis stocke des données dans $HOME, elle ne se dit pas :
- je suis sur un OS multi-utilisateur donc je dois utiliser $HOME pour ne pas mettre le bordel chez les autres.
Et "se dit" :
- où je peut stocker mes données => dans $HOME et d'ailleur je n'ai pas le choi.
Où tu vois une logique multi-utilisateur ici ?
Qu'il y ait un compte ou 50 000 comptes sur la machine, c'est comme ça qu'il faut faire.
> Je ne vais pas m'attaquer aux problèmes des bases de données
> conclusion : ls a été pensé et programmé pour fonctionner en environnement multiutilisateur.
Non. La commande dir de MS-DOS a aussi des messages d'erreurs.
Sous MS-DOS on pouvait rendre le fichier protégé en lecture (avec "chattr").
ben sous MS-DOS :
$ type fichier_illisible message d'erreur
ls n'est pas multi-utilisateur.
La commande ls comme la commande dir de MS-DOS (qui n'est pas un os multi-utilisateur) fait : if (!open(fichier)) {
perror(fichier) ;
}
Où vois tu dans des lignes de code du multi-utilisateur ?
En programmation, il faut tester tous les appels systèmes. Que l'OS soit multi-utilisateur ou non.
C'est dingue, t'as un score positif alors que tu as dit une connerie.
C'est désespérant.
Prends le programme "ls" qui doit être le programme le plus utilisé sous Unix et trouves une partie qui tient compte d'un aspect multi-utilisateur.
Regardes vi aussi si t'as rien à foutre.
99 % des applis Unix ne s'occupe pas de l'aspet multi-utilisateur.
> Mais là tu balance le problème au serveur de son
Je n'ai pas abordé les serveurs car c'est un autre domaine.
Les serveurs doivent gérer eux-même le multi-utilisateur. Pas forcément le multi-utilisateur au niveau de l'OS (id utilisateur) mais déjà le multi-utilisateur à leur niveau (par définition).
> donc il y a bien une appli qui doit en tenir comtpe à un moment ou un autre.
Pas forcément. Par exemple utilise le groupe audio et le plugin dmix d'alsa par défaut.
Là tu auras plusieurs utilisateurs (et/ou applis) qui pourront faire du bruit en même temps. L'horreur quoi :-).
> sudo ne fait pas parti de l'OS
Oui. Mais il y a toujours la difficulté de savoir ce qui fait parti de l'OS ou non.
X11 fait-il parti de l'OS ?
Ben une appli Gnome doit faire comme si X11 fait parti de l'OS.
Ou commence et s'arrête l'OS, n'est pas toujours évident.
> Si tu recommences à me dire 'POINT BARRE' ou un truc dans le genre pour imposer ton opinion, on ne va pas pouvoir discuter longtemps ;-)
D'accord certaines applis doivent prendre en compte le multi-utilisateur (par exemple la commande who :-)).
Mais une appli "normal" (non spécialisée sur l'aspect multi-utilisateur) n'a pas à s'occuper de ça.
Exemple à la con :
$ ls /root
ls: /root/: Permission non accordée
C'est l'OS qui a dit au programme ls : "Permission non accordée".
Ce n'est pas ls, qui serait programme multi-utilisateur, qui est regardé l'id de l'utilisateur en cours et qui a décidé de ne pas lister /root car l'id de l'utilisateur est différent de 0.
ls n'a pas à être programmé pour être multi-utilisateur.
D'accord ?
Idem pour Gnome. Sauf quelques cas particuliers soigneusement choisi :-)
PS : je répète encore une fois, ça ne concerne pas les serveurs.
Que le multi-utilisateur d'Unix ne soit pas parfait, et est limite "casse couille" par moment, je l'admets parfaitement.
> mais c'est aux appli de bien s'intégrer dans cet environnement justement
Ben non.
L'appli fait : play_sound()
Et rien de plus.
L'appli n'a pas à faire :
if !(sound_system_dispo() &&
uid == copine à TImaniac &&
sound_system_used_by() == TImaniac ) {
grant_admin() ;
eject_user(TImaniac) ;
}
play_sound() ;
L'appli n'a pas à s'occuper du multi-utilisateur.
> mais le fait est que le multi-sessions avec basculement rapide sous Windows XP est bien plus agréable
Qui est responsable de ça ?
L'appli ou l'OS ?
L'OS.
> Gnome et KDE qui ont l'air de se moquer eperdumetn de ce problème
Oui. C'est à l'OS de s'occuper de ça.
btw, tu peux ajouter le group snd par exemple à tes utilisateurs.
Tu peux utiliser par défaut dmix. Une solution existe (pas "out of box").
Peut-être que l'OS Windows est meilleur et que l'OS Linux doit en prendre de la graine. Mais ce n'est pas aux applis de s'occuper de ça.
> Donc c'est clairement la faute aux developpeurs. Mais d'apres 007, il ne faut pas eduquer les developpeurs...
J'adore votre façon d'être en contradiction tout le temps. Selon vous, ce n'est pas à l'OS d'être multi-utilisateur, c'est à l'applis (donc au développeur de faire attention). Ben bizarrement, Windows (l'OS) est de plus de plus multi-utilisateur.
Vous êtes en désaccord avec l'évolution de Windows ?
Vous passez en continu de :
- "Ce n'est pas un problème (ou ça ne conserne pas l'OS), c'est aux développeurs de faire attention."
à
- "C'est corrigé dans la dernière version de Windows."
Comme MS peut corriger ce qui n'est pas un problème selon vous ?
Pourquoi MS ajoute un truc à l'OS qui selon vous ne conserne que le développeur de l'appli ?
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
J'ai oublié ce truc.
Un serveur est différent car généralement il doit gérer des accès parallèles et/ou différents utilisateurs.
Il est souvent soit proche du système multi-utilisateur de l'OS ou a son propre système multi-utilisateur.
Néanmoins, tu trouves des serveurs qui ne sont pas multi-utilisateurs ou qui ne gérent pas des requêtes en parallèle.
Par exemple, bittorrent n'a pas de notion d'utilisateurs et inetd peut t'éviter de rentrer dans l'enfer de faire un programme qui support des connections parallèles. Idem pour bind (sauf quelque cas) qui n'a pas de notion d'utilisateur.
Mais si tu insistes, tu peux aussi installer apache ou bind ou mysql (ce que tu veux) dans ton $HOME (ou /tmp, gnagnagna) et l'excécuter (faudrat utiliser un port supérieur à 1024).
Mais pour mysql et apache :
* propre gestion multi-utilisateur (pour apache c'est .htpasswd par exemple)
* gestion de requête en parallèle (apache peut tourner derrière inetd. Dans ce cas il te faut aussi ton propre inetd si tu installes apache dans ton $HOME).
* apache peut "binder" vers les comptes systèmes (http://.../~compte/(...)). Il doit être super utilisateur dans cas, idem pour utiliser suexec et d'autres "bricoles".
Bref, rien à voir avec gimp ou evolution ou tout un tas d'applis clientes que lance l'utilisateur.
L'utilisateur ne lance pas apache/mysql/bind/dbus. Ou alors c'est un développeur.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
> /tmp est accessible a tout le monde
> il peut tout a fait faire un ftok("/tmp/monfichier",...)
> sachant que /tmp est accessible a tout le monde ?
J'ai déjà dit que "/tmp" est un problème.
T'as trouvé ton os à ronger, t'es content, tu remus la queue.
btw, windows a aussi son "/tmp".
Notes aussi :
man hier
/tmp Ce répertoire sert à contenir des fichiers temporaires que l’on peut détruire régulièrement, par un script périodique, ou au démarrage du système.
Mais t'es libre de foutre des données dedans. C'est un défaut d'Unix, j'y reviens pas.
Si le développeur ne remarque pas qu'à chaque boot il perd la configuration de son programme, c'est à désespérer.
> Ce sont des utilisateurs, ils ne peuvent pas se logger mais le kernel ne fait absolument aucune difference entre nobody, root et logindemaman, ils sont tous traites de la meme maniere.
....
Je peut me loguer sur ma bécane, nobody non.
Je peut faire http://...../~moi/(...) mais http://..../~nobody/(...) ne marche pas.
ftp sur le compte nobody ne marche pas.
"su nobody" me retourne "This account is currently not available."
Certe au niveau noyau c'est le même chose mais un noyau ne fait pas un OS.
Donc mets tous les id de /etc/passwd à 0 et tu me feras plus chié.
> Super, je te fais un 'ls' modifie qui n'affiche jamais le repertoire .monrepertoire, subitement ca n'est plus un repertoire ?
Ben envoies un mail aux utilisateurs apache et nobody puisque t'as pas compris la différence. Au mieux le mail arrivera sur le compte root.
> C'est bien ce dont je te parles depuis le debut, ca se produit, et ca prouve que laisser qq'un ecrire un soft en lui disant que c'est mono-utilisateur peut aboutir a un soft qui ne tourne pas en multi-utilisateur.
Ben si je vire /tmp, tu n'as plus aucun argument.
Bref, t'as démonstration tient à l'existance de /tmp .
Bravo. Et ""bravo"" à ceux qui ont avalé ta ""démonstration"".
[^] # Re: Plutôt une bonne nouvelle ?
Posté par 007 . En réponse au journal Linux trop populaire.. Évalué à 4.
Oui.
Mais avant (je fais dans le nostalgique), lorsqu'on entrait dans un forum, on enlevait ses chaussures :-)
Maintenant n'importe qui a un avis sur tout :
- Linux c'est trop GPL, ils ont viré pwc.
- ext3 c'est vieu et pourri comme conception, reiser4 roxor.
- Les développeurs Gnome sont nuls car ils utilisent gobject.
- Les développeurs Linux se foutent de notre gueule : la branche 2.6 prend trop de temps à se stabiliser.
- etc
Bref, une belle brochette d'expert.
Je n'ai pas le quart du huitième du niveau d'expertise de Linux ou Gnome et j'y réfléchis à 20 fois avant de critiquer leur choix.
Ben maintenant n'importe qui peut critiquer de façon virulente même s'il n'y comprend rien.
J'arrête pas de voir des commentaires avec des gros mensonges dedans qui ont des scores positifs.
Avant si je voyais un commentaire avancer un concept erroné, je le corrigais. Maintenant j'ai plus envis.
Avant on pouvait "ramener" l'ordre.
Maintenant il faut dire "amen" aux conneries les plus populaires :
- Les virus c'est une fatalité et Linux aura besoin d'un anti-virus comme Windows.
- Il faut faire comme les logiciels proprios et taire les trous de sécurité.
- etc.
Je ne serait pas étonné qu'un mec qui raisonne de façon favorable au proprio et à MS (pB pG pour le nommer) soit beaucoup plus plébiscité que si RMS ou Torvalds s'exprimait de façon anonyme sur linuxfr.
Maintenant c'est trop...
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Et pB pG qui m'expliquait qu'il n'y avait rien à améliorer ici ...
Pire, il ne comprend pas qu'on puisse faire des recherches sur ça.
> Je connais plus d'un débutant qui a fait un programme qui stockait dans /tmp ou /home/debutant
Certe. J'ai moi même sur ma bécane quelques scripts avec les paths en dure.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Mais le non usage de $HOME se détecte très très vite.
Il faut être "réaliste".
Les problèmes de "/tmp" sont beaucoup plus importants car beaucoup plus difficile à trouver.
Biensûr on peut utiliser tmpfile() etc... Mais si le développeur ne connait pas ces fonctions son programme marchera sur plusieurs postes. La détection de l'erreur n'est pas "fulgurante" comme pour l'oublie de $HOME.
Enfin, les crakers adorent profiter de la mauvaise utilisation de /tmp.
Si le développeur ne connait pas tmpfile() et qu'il a besoin d'écrire des données temporaires il va peut être utiliser directement /tmp.
S'il ne prend pas quelques précautions de _sa propre initiative_ pour prendre en compte l'aspect multi-utilisateur, son programme ne sera pas multi-utilisateur compliant.
C'est LE point faible d'Unix.
Les autres trucs :
- IPC
- écriture dans /usr/share/no_where_and_ro
- non utilisation de $HOME
- etc
se détectent très très vites ou sont des erreurs de programmations (Par exemple une vérification du retour des appels système permet de localiser l'erreur).
Une recherche rapide des trous sécurités avec /tmp montre que c'est très courant (limité à lwn.net):
http://www.google.fr/search?hl=fr&ie=UTF-8&q=site%3Alwn.net(...)
Ces problèmes de sécurités sont en général fait par des programmes pas très multi-utilisateur compliant.
Tu vas dire que je suis en contradiction avec moi-même car je dis que les programmes n'ont pas à être multi-utilisateur compliant sous Unix !
Ben oui. Le problème de /tmp avec Unix est qu'il demande un effort de la part du développeur (ou ne le contraint pas) pour que le programme soit multi-utilisateur compliant.
Les dégâts se font très vite sentir et les problèmes de "/tmp" sont n°1 pour les trous de sécurité.
Voir cet article lwn :
http://lwn.net/2000/1221/security.php3(...)
L'article est vieux et "presque faux" par endroit. Mais reste valable.
Unix a fait ici un erreur de conception assez grave et on peut se demander si ce problème sera corriger un jour (compatiblité oblige).
Il n'y a pas de fumé sans feu.
NB : je ne dis pas que c'est de la fautes des développeurs pour cacher une erreur de conception d'Unix...
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Il me suffit de prouver que une fois tu as eu tord pour que tu aies tout le temps tord ?
Tu trouves un exemples qui ne marche pas et ça tu donnes le droit d'ignorer les 1000 autres exemples qui marchent.
Merveilleux.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Cool.
> C'est le fait d'être obligé d'utiliser une variable et pas un path absolu qui fait que tu es obligé de considérer que c'est du multi-utilisateur.
Imagines un appareil photo qui tourne sous Unix. Tout est en read-only sur l'appareil photo sauf /home/user (un cartouche flash).
Et comme le monde est bien fait, c'est $HOME. Dingue.
Si tu as gimp sur l'appareil photo, tu peux jouer avec.
Mieux, tu as deux cartouches flash.
Le second est sur /home/user2.
Pour que gimp marche alors que le premier cartouche n'est pas là, il suffit d'avoir HOME=/home/user2.
Même pas besoin d'un second compte !
Plus fort, tu peux lancer en parallèle :
- HOME=/home/user gimp
et
- HOME=/home/user2 gimp
C'est le même utilisateur et tu as deux gimp totalement séparés. C'est courant comme usage de $HOME.
En fait, pas besoin de compte du tout. Tout peut tourner en root (ce qui est généralement fait dans l'embarqué).
HOME n'est pas une variable qui dit :
- attention, système multi-utilisateur et c'est l'emplacement pour les données de l'utilisateur.
HOME dit :
- ici est l'emplacement pour les données. Et c'est tout ! Système multi-utilisateur ou pas.
Si tu veux deux gimp avec deux configurations différentes, il suffit de changer HOME.
Quoiqu'il en soit, coder en dure un chemin n'est JAMAIS une bonne idée.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Ya aussi les distributions live cd.
Les modes rescue.
Je dis ça, je dis rien.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 0.
De plus OOo est multi-plateforme et parfois il faut trainer les boulets des autres plateformes.
Puis t'as trouvé 1 programme qui pose problème alors que des programmes pour linux, c'est par millier qu'on les comptent.
Il y a quoi à conclure ?
Que c'est bug.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
$HOME/qqc car il y est obligé.
J'ai pas dit une appli mono-utilisateur pour toto dont le seul répertoire en écriture est /home/toto.
Sous unix que l'appli soit mono-utilisateur ou non (ce qui n'a pas de sens sous Unix...) c'est $HOME qu'il faut utilser.
> il va utiliser les IPC pour les communications inter-process
Et ?
Tu connais rien à IPC.
Pour avoir un identifiant ipc, tu utilises ftok(3) (c'est dans la doc).
ftok : Convertir un nom de fichier et un identificateur de projet en clé IPC système V.
Comme il n'y a que $HOME de dispo, tu utiliseras ftok ($HOME/ipc, ...).
T'es obligé. Terminé.
Si tu fais un serveur il faut utiliser /tmp/... . Mais je n'es jamais parlé pour le cas des serveurs !
> il va pas mettre de permissions dessus vu que c'est mono-utilisateur
Et pourquoi ?
Pour rien.
Si t'as besoin de changer les permissions, c'est (par exemple) :
chmod +w toto
L'umask est toujours respecté (la libc fait de même).
Toujours pas de problème.
> Developpeur Unix depuis 7 ans t'as dit, c'est bien ca ?
Ouais. T'as encore prouvé que t'y connais en rien Unix.
> Alors un programme qui utilise un nom fixe pour son fichier d'IPC(plutot qu'un nom d'user)
Si ce n'est pas un serveur, c'est stupide.
Si c'est pour un utilisateur (donc ce n'est pas un serveur), le fichier IPC sera basé sur $HOME/... . C'est obligé (voir plus haut).
> hors non, ca ne marche pas, sauf si le _programme_ tient compte du fait que plusieurs utilisateurs peuvent lancer le soft en meme temps.
Ben non. T'as faux.
Sauf si tu veux que les processus de plusieurs utilitsateurs _différents_ communiquent entre eux.
Donc c'est un serveur... et ce n'est pas le propos ici.
Suivant.
> Si, toutes celles ecrivant dans des fichiers fixes dans des repertoires accessibles a tous.
Et encore un couche.
Hors /tmp (et je reconnais que c'est un _réel_ problème) où peux écrire un utilisateur ?
Dans $HOME.
Donc si ce n'est pas un serveur il n'y a pas de problème.
L'appli ne va pas coder :
open("/usr/titi", O_CREAT)
Et ce car même pour le développeur ça ne marche pas !
> Faux, meme sans que personne se logge plusieurs utilisateurs ont des softs tournant sur un Linux, typiquement Apache qui tourne en nobody et d'autres process en root, meme chose pour les autres daemons.
Ce se sont pas des utilisateurs...
grep apache /etc/passwd :
apache:x:48:48:Apache:/var/www:/sbin/nologin
Nuance.
si je fais "who", j'ai jamais apache, named, etc.
Puis on voit que ça fait depuis longtemps que tu n'as pas utiliser apache car nobody n'est plus utilisé par apache depuis... j'ai oublié.
Conclusion :
Tu considères que le développeur fait un sabotage pour défendre ton point de vu.
Actuellement, il y a que le problème de /tmp qui tient la route.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
J'ai dit ailleur que /tmp est un problème et tu le sais.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Mais si. C'est indiqué avec la variable TEMP je crois.
Sous windows c'est C:\windows\system\temp.
Bref, il y a /tmp et dire le contraire, c'est se foutre de la gueule du monde.
Qu'on me dise pas que Windows est merdique au point de ne pas proposer l'équivalent de /tmp.
> pourquoi il faut dire aux développeurs de programmer en penssant multi-utlisateurs, pour qu'ils y pensent, même si c'est pas toujours utile.
Ben demande à un développeur de faire une appli pour Unix et lui disant bien que c'est pour une système avec un seul utilisateur. Tu vas voir, l'applis sera multi-utilisateur compliant. Marrant ça.
> Un programme comme Gnome qui ne propose pas la possibilité de lancer un programme en tant que autre utilisateur n'est pour moi pas multi-utilisateur.
Bravo. Gnome est un programme.
Tu as quelle version du programme Gnome ?
> ça c'est du multi-tâches et on s'en balance.
Manifestement, tu n'y comprend rien.
* Win 95 est multi-tâches et pas multi-utilisateur.
Tu vois la différence ? Impossible d'être plusieurs utilisateurs sur Win 95. Impossible d'avoir 2 explorateurs de fichier pour deux utilisateurs ,etc.
> Un programme multi-utilisateur, c'est un programme qui tient compte du fait qu'il y a plusieurs utilisateurs !!!
C'est l'OS qui est multi-utilisateur et pas un programme !
> Certaines applications doivent par contre être multi-utlisateurs,parcque c'est leur rôle d'en tenir compte, et je pense t'avoir donner suffisament d'exemple (Gnome, KDE, gdm, sudo, etc.)
Tu mélanges tout.
Bon, heureusement que depuis 30 ans, Unix ne fait pas ce que tu dis.
> sinon l'appli est mono-utilisateur
Il n'y a pas d'appli mono-utilisateur sous Unix (sauf serveur, et encore...).
> multi-threadé
T'es dans le brouillard le plus complet.
On peut être multi-utilisateur et pas multi-threadé. Ça existe.
On peut être multi-threadé et pas multi-utilisateur (win 95). etc.
Ça n'a rien à voir.
Sous Linux tant que personne se loggue, c'est mono-utilisateur et parfaitement multi-tache.
Et btw, Linux est aussi mono-utilisateur :
- boote avec "-init 1" ou "init=/bin/bash".
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à -1.
Qui n'est pas un principe multi-utilisateur (windows l'a fait:-)).
Ce marrant, aujourd'hui tout est multi-utilisateur. Protection de fichier, variable d'environnement, etc
Dans ce cas, oui tous les programmes sont fait spécifiquement pour le multi-utilisateur.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
D'ailleur, le programme hello_world peut-être lancé par plusieurs utilisateurs à la fois. Enfin sous un OS multi-utilisateur.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Pardon.
Le truc est que certains disent :
- Un OS multi-utilisateur a besoin d'applis faites spécifiquement pour le multi-utilisateur. Si l'appli n'est pas fait pour le multi-utilisateur alors l'appli ne peut pas être utilisées par plusieurs personnes à la foi.
Je dis qu'avec OS multi-utilisateur bien foutu, l'appli n'a pas à être codé spécifiquement multi-utilisateur pour être utilisé par plusieurs personnes à la foi (sauf sabotage du développeur qui stockent les données dans /tmp).
Tu vois la nuance ?
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Tu développes sous Unix ?
Si tu développes sous Unix et que tu te dis "où stocker mes donnée ?".
La réponse est $HOME car tu n'as pas le chois. multi-utilisateur ou pas.
Tu ne te dis pas :
- Je vais mettre mes données dans $HOME, ça va être super cool dans un contexte multi-utilisateur.
De même, avant de développer une applis, tu ne te dis pas :
- multi-utilisateur ou mono-utilisateur ?
Si multi-utilisateur alors faire ça, ça et ça et pour mono-utilisateur faire ça, ça et ça.
Dans 99 % les applis pour Unix sont développées sans penser à multi-utilisateur ou mono-utilisateur et qu'on utilise $HOME n'y change rien.
Restons sur $HOME.
Les gens disent :
- Si tu ne peux pas écrire partout mais seulement dans $HOME, c'est le preuve que tu tiens compte du multi-utilisateur ou que tu es sur un système multi-utilisateur.
Pourquoi ?
1- $HOME est obligatoire
2- Même sur un système mono-utilisateur il peut y avoir des parties en lecture seule. (montage en ro, ROM)
3- avoir un "truc" qui dit "ici tu peux stocker, ne perd pas ton temps ailleur" est bien pratique
$HOME est nécessaire même si ce n'est pas dans un contexte multi-utilisateur.
D'ailleur il est possible de booter sous Linux en mono-utilisateur et sans être root. Dans ce cas il y a pas de contexe multi-utilisateur et c'est toujours dans $HOME que tu peux stocker des données (si les conventions sont respectée).
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Arrêtez de tout mélanger.
Si ls n'affiche pas ces infos, ls reste multi-utilisateur. Il est inutile qu'il affiche ces infos pour être multi-utilisateurs.
[^] # Re: 007 versus Rest Of The World
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 0.
Ton exemple est con car même sous Windows c'est super con de faire ça et personne le fait.
Sous Windows il y a /tmp, pardon "C:\temp" et pourtant les développeurs windows ne mettent pas la configuration des applis dans "C:\temp". D'ailleur il y a depuis très très longtemps une variable d'environnement sous windows (depuis MS-DOS) pour indiquer où est le répertoire tmp.
Comme l'emploi de /tmp est évident pour tout le monde, je l'ignore.
Il n'y a pas de multi-utilisateur dans ton problème !
La question est :
- Où stocker mes données ?
Durant longtemps sous windows la réponse était :
- n'importe où
Sous Unix c'est :
- $HOME et d'ailleurs tu n'as pas le chois
> ah mais sous windows c'est super con de faire ça, une appli qui écrit sa conf dans un endroit qui ne dépend pas de l'utilisateur.
Encore très con.
Sous windows jusqu'à millénium (sorti en 2000 !) tu pouvais stocker tes données partout.
Sous Unix depuis 30 ans => $HOME.
Autre exemple, et ce n'est pas moi qui le dit :
- sous Windows il faut souvent être admin pour développer. Sinon tu ne peux pas enregistre un bidule machin dans la base de registre et l'applis ne marche pas. Il parait que c'est très courant et aussi pour Windows 2000/XP !SVP Utilisateur Windows confirmer ça car je ne suis pas un gros utilisateur de Windows. Mais ce que je peut dire de mon expérience, c'est qu'il faut être admin pour faire un paquet (installsheild) diffusable sous Win Xp. Donc pour faire du VB, j'étais admin...
Sous Unix tout est développé sans prévilège admin. Mes paquets rpm sont fait sous mon compte. Je peux compiler et utiliser tout Gnome sans jamais être admin. C'est comme ça pour tous les programmes (sauf les programmes qui réserve des "ressources sensibles", port réseau, etc).
> a fait que les développeurs font n'importe quoi, parfois, en écrivant dans le registre, dans Program Files ou ailleurs.
Les développeurs Unix ont souvent, très très souvent commencé par Windows.
Tu m'expliques le truc ?
> Mais tout ça n'a rien de technique !
Oui et non. C'est surtout historique. Or l'historique de Windows n'est pas brillant techniquement sur ce point.
Mais et je le reconnait volontier, MS avance à grand pas et les dernières moutures sont presques "parfaites" (sur ce point :-)).
> Sous linux un développeur peut parfaitement coder avec ses pieds et nous pondre un truc qui n'EST PAS multi-utilisateurs.
Comment ?
A part l'emploie de /tmp, vous ramez un peu.
On trouve des entreprises qui ont vendu des programmes qui merdaient dans un environnement multi-utilisateur Windows.
On trouve ça sous Unix ? Non.
C'est quoi alors le truc ?
Les développeurs Windows sont nuls ?
Non.
La culture des développeurs Windows ?
Non. 98 % des unixiens on commencés windowsiens.
La raison est simple :
Windows n'était pas multi-utilisateur. Puis Windows a eu un modèle multi-utilisateur très mal foutu (Win 95). Le tout sans protection au niveau système de fichier.
Après MS a voulu rectifier le tir. Mais il a fallu faire avec l'énorme base installée de programme, etc. On obtient pas la maturité d'unix (presque 30 ans!) en quelques mois et il y a des accrocs . Normal.
Il a fallu attendre Win XP/2000 (année 2000 !) pour que Windows ne diffuse plus de "mauvais" OS.
Le "problème" est là.
Mais fasse à ce problème, il y a des gus qui disent n'importe quoi (et pire, ils sont applaudis) :
- C'est aux applis d'être multi-utilisateurs (et l'OS ? non ?).
- Les développeurs Unix sont géniaux et ne font pas les conneries de développeurs Windows.
- Faut éduquer les développeurs Windows qui sont vraiment nuls.
- etc
L'environnement technique de Windows semble (preque) bon maintenant sur ce point.
Dans quelques années (3 ou 4 ans) on ne parlera plus d'"éduquer les développeurs" et autres bêtises pour Windows.
Ceci dit, je m'en branle de Windows.
Ce qui me fait chier, c'est que des raisonnement à la con (généralement pour nier les défauts techniques (vieu de plus) de Windows) s'installent tranquillement ici.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à -1.
On peut le voir comme ça. Mais un kernel sans libc, c'est dure.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Oui sur un OS multi-utilisateur il y a des programmes qui tiennent compte de cet aspect.
Sinon tu vires gdm, login, who, etc et tu bootes en single user.
Quel est le but d'un OS multi-utilisateur ?
1- S'occuper de l'aspect multi-utilisateur
2- Demander aux applis de s'occuper de l'aspect multi-utilisateur
La réponse est 1).
Prends tous les sources de GNOME et compte le nombre de ligne qui s'occupe de l'aspect multi-utilisateur. Ça doit être ridicule. Moins de 0.001 %.
Mais continuez à affirmer que c'est le role des applis d'être multi-utilisateur. Quelle doivent être codée pour être multi-utilisateur, etc.
Lorsqu'une applis stocke des données dans $HOME, elle ne se dit pas :
- je suis sur un OS multi-utilisateur donc je dois utiliser $HOME pour ne pas mettre le bordel chez les autres.
Et "se dit" :
- où je peut stocker mes données => dans $HOME et d'ailleur je n'ai pas le choi.
Où tu vois une logique multi-utilisateur ici ?
Qu'il y ait un compte ou 50 000 comptes sur la machine, c'est comme ça qu'il faut faire.
> Je ne vais pas m'attaquer aux problèmes des bases de données
Problèmatique serveur, rien à voir.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Non. La commande dir de MS-DOS a aussi des messages d'erreurs.
Sous MS-DOS on pouvait rendre le fichier protégé en lecture (avec "chattr").
ben sous MS-DOS :
$ type fichier_illisible
message d'erreur
ls n'est pas multi-utilisateur.
La commande ls comme la commande dir de MS-DOS (qui n'est pas un os multi-utilisateur) fait :
if (!open(fichier)) {
perror(fichier) ;
}
Où vois tu dans des lignes de code du multi-utilisateur ?
En programmation, il faut tester tous les appels systèmes. Que l'OS soit multi-utilisateur ou non.
C'est dingue, t'as un score positif alors que tu as dit une connerie.
C'est désespérant.
[^] # Re: exemple plus précis?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Regardes vi aussi si t'as rien à foutre.
99 % des applis Unix ne s'occupe pas de l'aspet multi-utilisateur.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
Je n'ai pas abordé les serveurs car c'est un autre domaine.
Les serveurs doivent gérer eux-même le multi-utilisateur. Pas forcément le multi-utilisateur au niveau de l'OS (id utilisateur) mais déjà le multi-utilisateur à leur niveau (par définition).
> donc il y a bien une appli qui doit en tenir comtpe à un moment ou un autre.
Pas forcément. Par exemple utilise le groupe audio et le plugin dmix d'alsa par défaut.
Là tu auras plusieurs utilisateurs (et/ou applis) qui pourront faire du bruit en même temps. L'horreur quoi :-).
> sudo ne fait pas parti de l'OS
Oui. Mais il y a toujours la difficulté de savoir ce qui fait parti de l'OS ou non.
X11 fait-il parti de l'OS ?
Ben une appli Gnome doit faire comme si X11 fait parti de l'OS.
Ou commence et s'arrête l'OS, n'est pas toujours évident.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
D'accord certaines applis doivent prendre en compte le multi-utilisateur (par exemple la commande who :-)).
Mais une appli "normal" (non spécialisée sur l'aspect multi-utilisateur) n'a pas à s'occuper de ça.
Exemple à la con :
$ ls /root
ls: /root/: Permission non accordée
C'est l'OS qui a dit au programme ls : "Permission non accordée".
Ce n'est pas ls, qui serait programme multi-utilisateur, qui est regardé l'id de l'utilisateur en cours et qui a décidé de ne pas lister /root car l'id de l'utilisateur est différent de 0.
ls n'a pas à être programmé pour être multi-utilisateur.
D'accord ?
Idem pour Gnome. Sauf quelques cas particuliers soigneusement choisi :-)
PS : je répète encore une fois, ça ne concerne pas les serveurs.
[^] # Re: ?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 0.
Que le multi-utilisateur d'Unix ne soit pas parfait, et est limite "casse couille" par moment, je l'admets parfaitement.
> mais c'est aux appli de bien s'intégrer dans cet environnement justement
Ben non.
L'appli fait :
play_sound()
Et rien de plus.
L'appli n'a pas à faire :
if !(sound_system_dispo() &&
uid == copine à TImaniac &&
sound_system_used_by() == TImaniac ) {
grant_admin() ;
eject_user(TImaniac) ;
}
play_sound() ;
L'appli n'a pas à s'occuper du multi-utilisateur.
> mais le fait est que le multi-sessions avec basculement rapide sous Windows XP est bien plus agréable
Qui est responsable de ça ?
L'appli ou l'OS ?
L'OS.
> Gnome et KDE qui ont l'air de se moquer eperdumetn de ce problème
Oui. C'est à l'OS de s'occuper de ça.
btw, tu peux ajouter le group snd par exemple à tes utilisateurs.
Tu peux utiliser par défaut dmix. Une solution existe (pas "out of box").
Peut-être que l'OS Windows est meilleur et que l'OS Linux doit en prendre de la graine. Mais ce n'est pas aux applis de s'occuper de ça.
[^] # Re: exemple plus précis?
Posté par 007 . En réponse au journal Unix : ton esprit fout le camp. Évalué à 1.
J'adore votre façon d'être en contradiction tout le temps. Selon vous, ce n'est pas à l'OS d'être multi-utilisateur, c'est à l'applis (donc au développeur de faire attention). Ben bizarrement, Windows (l'OS) est de plus de plus multi-utilisateur.
Vous êtes en désaccord avec l'évolution de Windows ?
Vous passez en continu de :
- "Ce n'est pas un problème (ou ça ne conserne pas l'OS), c'est aux développeurs de faire attention."
à
- "C'est corrigé dans la dernière version de Windows."
Comme MS peut corriger ce qui n'est pas un problème selon vous ?
Pourquoi MS ajoute un truc à l'OS qui selon vous ne conserne que le développeur de l'appli ?
Je suis très curieux de connaitre votre réponse.