Je n'ai pas dis que les ACL c'est mal ! Mais comme d'habitude, tu détournes. J'ai dis que le système dans Windows est trop compliqué et que quasiment personne autour de moi ne sais le gérer. As tu vu un utilisateur l'utiliser ?
La solution dans Linux de mettre un système type SeLinux pour les spécialistes et un système simple par défaut me semble au final plus simple car les personnes l'utilisent.
Pour ce qui est des suid, un bogue est un bogue mais rassuses-toi, il y en a aussi dans Windows et l'élévation de droit existe aussi. Il n'empêche, ce système est simple et a prouvé qu'il marche.
Pour ce qui est des services, pourquoi tournent-ils sous SYSTEM ? Je les fais tourné sous SYSTEM parce que c'est en partie merdique de créer un compte en ligne de commande, que les scripts bat ou vbs sont merdiques et donc les gens vont au plus simple.
Pour ce qui est des variables d'environnements, qui n'a pas bidouiller la valeur d'une variable dans les propriétés du poste de travail ? Par exemple la variable Path ? Cette interface est une des pires que je connaisse.
Je connais pas trop mal le principe des ruches et je peux même te dire que le compte SYSTEM n'en a pas et que cela fout la merde pour un certain nombre de programme (par exemple psexec qui stocke l'eula dans la ruche, mais des trucs qui marche sous le compte admin et pas SYSTEM, il y en a plein...). Que tu est une ou des ruches, ce sont toujours des variables globales. Tu peux comparer la taille du /etc et celle de la ruche du system, je serais amusé de voir leur taille respective...
Pour Adobe, sous Linux, son installation ne fout pas le bordel dans /etc et sous Windows oui. C'est aussi simple que cela, il y a une philosophie de l'environnement sous UNIX qui demande a ne pas faire le bazard chez le voisin. Et c'est globalement respecté ! Je n'ai donc pas dis que l'OS est complètement merdique, je dis que si un grande majorité de développeur font des trucs merdiques, alors l'OS doit se remettre en cause pour essayer de comprendre pourquoi et modifier son comportement pour éviter cela dans le futur. Depuis les débuts de Windows 2000, c'est mieux mais ce n'est pas encore cela. Et je pense que sous Linux, il y a une tendance dangeureuse à prendre la voie de la complexité inutile, j'ai pris l'exemple de GNOME mais c'est effectivement le cas de samba...
Une partie des développeurs autour de GNU/Linux travaille maintenant pour des boites dont l'objectif est de vendre des usines à gaz a installer pour des techniciens cliclodromes... Donc, il faut des cliclodromes pour configurer, des interfaces graphiques de partout, des consoles d'administration... Donc par derrière, le fichier XML ou la base de registre sont parfait. On stocke le bordel du cliclodrome la dedans et on est content.
Je ne suis pas de ce mouvement et je propage/controle mes fichiers de config via cfengine sur mon parc sans soucis. Tout cela est versionner dans subversion. Bref, rien que des outils orthogonaux, simple et robuste. Modifier la configuration d'un logiciel ne doit pas être quelque chose qui a à voir avec le temps réel, si c'est le cas, on n'est plus dans la configuration mais dans la partie données/stockage de l'application. Pour faire un firewall clusterisé, il faut bien évidement que les firewall s'échangent en temps réel les sessions et les états. Ceci n'est pas de la configuration du firewall donc un format binaire, XML, registre... pour faire cela est tout a fait normal.
A mon sens, les gens de samba vont mélanger configuration et partage de fichier (et fonction d'impression...) sur le même port. C'est une très mauvaise démarche. Cela me semble à l'opposé de la stratégie UNIX de la simplicité mais surtout de l'orthogonalité. Qu'un cluster samba échange entre-eux des informations de type redondance, RAID... très bien, mais cela n'a rien a voir avec de la configuration (ni le partage effectif d'ailleurs).
[^] # Re: But?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de ReactOS 0.3.9. Évalué à 7.
La solution dans Linux de mettre un système type SeLinux pour les spécialistes et un système simple par défaut me semble au final plus simple car les personnes l'utilisent.
Pour ce qui est des suid, un bogue est un bogue mais rassuses-toi, il y en a aussi dans Windows et l'élévation de droit existe aussi. Il n'empêche, ce système est simple et a prouvé qu'il marche.
Pour ce qui est des services, pourquoi tournent-ils sous SYSTEM ? Je les fais tourné sous SYSTEM parce que c'est en partie merdique de créer un compte en ligne de commande, que les scripts bat ou vbs sont merdiques et donc les gens vont au plus simple.
Pour ce qui est des variables d'environnements, qui n'a pas bidouiller la valeur d'une variable dans les propriétés du poste de travail ? Par exemple la variable Path ? Cette interface est une des pires que je connaisse.
Je connais pas trop mal le principe des ruches et je peux même te dire que le compte SYSTEM n'en a pas et que cela fout la merde pour un certain nombre de programme (par exemple psexec qui stocke l'eula dans la ruche, mais des trucs qui marche sous le compte admin et pas SYSTEM, il y en a plein...). Que tu est une ou des ruches, ce sont toujours des variables globales. Tu peux comparer la taille du /etc et celle de la ruche du system, je serais amusé de voir leur taille respective...
Pour Adobe, sous Linux, son installation ne fout pas le bordel dans /etc et sous Windows oui. C'est aussi simple que cela, il y a une philosophie de l'environnement sous UNIX qui demande a ne pas faire le bazard chez le voisin. Et c'est globalement respecté ! Je n'ai donc pas dis que l'OS est complètement merdique, je dis que si un grande majorité de développeur font des trucs merdiques, alors l'OS doit se remettre en cause pour essayer de comprendre pourquoi et modifier son comportement pour éviter cela dans le futur. Depuis les débuts de Windows 2000, c'est mieux mais ce n'est pas encore cela. Et je pense que sous Linux, il y a une tendance dangeureuse à prendre la voie de la complexité inutile, j'ai pris l'exemple de GNOME mais c'est effectivement le cas de samba...
Une partie des développeurs autour de GNU/Linux travaille maintenant pour des boites dont l'objectif est de vendre des usines à gaz a installer pour des techniciens cliclodromes... Donc, il faut des cliclodromes pour configurer, des interfaces graphiques de partout, des consoles d'administration... Donc par derrière, le fichier XML ou la base de registre sont parfait. On stocke le bordel du cliclodrome la dedans et on est content.
Je ne suis pas de ce mouvement et je propage/controle mes fichiers de config via cfengine sur mon parc sans soucis. Tout cela est versionner dans subversion. Bref, rien que des outils orthogonaux, simple et robuste. Modifier la configuration d'un logiciel ne doit pas être quelque chose qui a à voir avec le temps réel, si c'est le cas, on n'est plus dans la configuration mais dans la partie données/stockage de l'application. Pour faire un firewall clusterisé, il faut bien évidement que les firewall s'échangent en temps réel les sessions et les états. Ceci n'est pas de la configuration du firewall donc un format binaire, XML, registre... pour faire cela est tout a fait normal.
A mon sens, les gens de samba vont mélanger configuration et partage de fichier (et fonction d'impression...) sur le même port. C'est une très mauvaise démarche. Cela me semble à l'opposé de la stratégie UNIX de la simplicité mais surtout de l'orthogonalité. Qu'un cluster samba échange entre-eux des informations de type redondance, RAID... très bien, mais cela n'a rien a voir avec de la configuration (ni le partage effectif d'ailleurs).