J'ai pas dis que c'était tout mieux avant... En plus smiley !
Les capabilities, c'est le bit suid coupés en rondelle de saucisson. Est-ce vraiment mieux que x petits programmes bien fait ? Au final, 95% des admin systèmes n'y comprendront plus rien. Les ACL, c'est beau sur le papier mais très peu d'utilisateur savent réellement les utiliser (par ailleurs, il y a un vrai problème pour les visualiser sur une grande arborescence). Les xattr, trop d'outil les gère mal et ils sont trop souvent perdus à la copie, cela sers surtout pour le système aujourd'hui. Il est préférable si cela est possible de tout mettre directement dans le fichier (commentaire dans le jpeg par exemple).
Policykit si j'ai bien compris, c'est une lib, alors que sudo, tu envoies des sous programmes donc des contextes différents. Tout dans ton post montre que tu raisonnes en variable globale... Je ne dis pas que tout est mal dans policy-kit mais pour faire un shutdown, je ne vois pas le plus !
Tu as une vison simplifié de la notion de groupe. Sous UNIX, on a un groupe primaire. Si tu fait newgroup toto, tu bascule sur le groupe primaire toto et tous les fichiers que tu vas éditer ensuite appartiendront au groupe toto. Il n'y a pas que root dans la vie ;-) D'ailleurs, je remplace cela par le bit suid sur le dossier partagé, c'est la seule méthode que j'ai trouvé utilisable de nos jours.
Les variables d'environnements, c'est fondamental. C'est pour cela que Windows est une daube avec sa base de registre (bien que pour être honnête, on arrive à contourner via des .bat dans certain cas). C'est grâce à cela que tu peux installer X version du même programme et les lancer en parallèle. En plus c'est propre et tu ne mélanges pas configuration et stockage de données...
Quand on les vire, on se retrouve avec un registre ;-) Et on n'arrive plus facilement a lancer deux instances du même programme, il faut que celui-ci gère les thread et les onglets... Bref, on est partis exactement sur la voie de Windows NT qu'on a tant critiqué...
La gestion des processus père fils est une merveille de simplicité et en cas de grand changement de configuration, un restart de la session ou un kill -HUP des applications les re-configuraient... Cela ne pose aucun soucis aux utilisateurs. D'ailleurs, je vois de plus en plus d'admin système dire à leur utilisateurs de rebooter leur Linux ce qui est encore bien pire.
Je suis d'accord pour dire qu'il faille un bus d'échange, un copié-coller étendu ! Ce qui me dérange, c'est sa généralisation pour un peu (trop) tout... Et puis, avec un bon bus qui gère bien les notifications, on pourrait très bien lancés X instance de firefox et X instance de geany... Pourquoi les nouvelles applications de bureau se lancent systématiquement en mode serveur ? Ca emmerde qui que j'ai 10 instances de vim d'ouverte sur ma session ? Ou est le problème d'avoir 4 firefox en // avec un bon BUS de session ? Le format ELF a été fait pour gérer cela.
Mais tout n'est pas noir. Pendant longtemps, GNOME avait une sur-couche réseau pour accéder aux fichier distants qui n'était pas utilisable aux applications non GNOME (idem pour KDE). Tout est maintenant possible sans discrimination avec gvfs-fuse. Ce genre de chose est pour moi la bonne voie.
Vu la quantité d'heure de passée à développer tout cela, heureusement que cela marche mieux qu'avant. J'ai juste un doute parfois sur la direction prise par certains bureaux graphiques. Heureusement, des développeurs font des corrections de trajectoires ;-) Ceci dis et pour finir, je ne suis pas du tout un spécialiste du développement d'un environnement de bureau, il y a certainement des contraintes que je ne vois pas.
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 5.
J'ai pas dis que c'était tout mieux avant... En plus smiley !
Les capabilities, c'est le bit suid coupés en rondelle de saucisson. Est-ce vraiment mieux que x petits programmes bien fait ? Au final, 95% des admin systèmes n'y comprendront plus rien. Les ACL, c'est beau sur le papier mais très peu d'utilisateur savent réellement les utiliser (par ailleurs, il y a un vrai problème pour les visualiser sur une grande arborescence). Les xattr, trop d'outil les gère mal et ils sont trop souvent perdus à la copie, cela sers surtout pour le système aujourd'hui. Il est préférable si cela est possible de tout mettre directement dans le fichier (commentaire dans le jpeg par exemple).
Policykit si j'ai bien compris, c'est une lib, alors que sudo, tu envoies des sous programmes donc des contextes différents. Tout dans ton post montre que tu raisonnes en variable globale... Je ne dis pas que tout est mal dans policy-kit mais pour faire un shutdown, je ne vois pas le plus !
Tu as une vison simplifié de la notion de groupe. Sous UNIX, on a un groupe primaire. Si tu fait newgroup toto, tu bascule sur le groupe primaire toto et tous les fichiers que tu vas éditer ensuite appartiendront au groupe toto. Il n'y a pas que root dans la vie ;-) D'ailleurs, je remplace cela par le bit suid sur le dossier partagé, c'est la seule méthode que j'ai trouvé utilisable de nos jours.
Les variables d'environnements, c'est fondamental. C'est pour cela que Windows est une daube avec sa base de registre (bien que pour être honnête, on arrive à contourner via des .bat dans certain cas). C'est grâce à cela que tu peux installer X version du même programme et les lancer en parallèle. En plus c'est propre et tu ne mélanges pas configuration et stockage de données...
Quand on les vire, on se retrouve avec un registre ;-) Et on n'arrive plus facilement a lancer deux instances du même programme, il faut que celui-ci gère les thread et les onglets... Bref, on est partis exactement sur la voie de Windows NT qu'on a tant critiqué...
La gestion des processus père fils est une merveille de simplicité et en cas de grand changement de configuration, un restart de la session ou un kill -HUP des applications les re-configuraient... Cela ne pose aucun soucis aux utilisateurs. D'ailleurs, je vois de plus en plus d'admin système dire à leur utilisateurs de rebooter leur Linux ce qui est encore bien pire.
Je suis d'accord pour dire qu'il faille un bus d'échange, un copié-coller étendu ! Ce qui me dérange, c'est sa généralisation pour un peu (trop) tout... Et puis, avec un bon bus qui gère bien les notifications, on pourrait très bien lancés X instance de firefox et X instance de geany... Pourquoi les nouvelles applications de bureau se lancent systématiquement en mode serveur ? Ca emmerde qui que j'ai 10 instances de vim d'ouverte sur ma session ? Ou est le problème d'avoir 4 firefox en // avec un bon BUS de session ? Le format ELF a été fait pour gérer cela.
Mais tout n'est pas noir. Pendant longtemps, GNOME avait une sur-couche réseau pour accéder aux fichier distants qui n'était pas utilisable aux applications non GNOME (idem pour KDE). Tout est maintenant possible sans discrimination avec gvfs-fuse. Ce genre de chose est pour moi la bonne voie.
Vu la quantité d'heure de passée à développer tout cela, heureusement que cela marche mieux qu'avant. J'ai juste un doute parfois sur la direction prise par certains bureaux graphiques. Heureusement, des développeurs font des corrections de trajectoires ;-) Ceci dis et pour finir, je ne suis pas du tout un spécialiste du développement d'un environnement de bureau, il y a certainement des contraintes que je ne vois pas.