"Debian ne cherche pas vraiment à évoluer mais à rester compatible"
Pourquoi Debian devrait faire evoluer quoi que ce soit ? C'est une distrib. Ca prend les sources chez les developpeurs, les mets dans leur système de package et met les packages à disposition sur le net.
Quand il y a un problème sur un packages, le mainteneur Debian règle le problème. Quand c'est un problème sur le soft (secu, bug...), ca remonte chez le developpeur avec, eventuellement, la solution pour redescendre ensuite.
C'est ca debian. Ce n'est pas, directement en tous cas, son boulot d'"abandonner les vieilles habitudes UNIXiennes"
"LDAP...un peu plus pratiques à administrer"
La plupart des softs (smtp,httpd,pop,imap) ont un support pour identification sur ldap via pam ou sans pam (heureusement).
Lors de la conception, tu te rends compte que tes besoins, les besoins d'une entreprise quelconque ou d'un isp sont radicalement differents. En clair, que la structure de ton arbre sera radicalement differente et idem pour les acl sur cet arbre. (1ere difficulté).
Bref, une fois que ta structure d'arbre et tes ACLs sont arretées, on peut passer au dev de l'IHM. Scripts shell ? Java ? via interface web html? gtk ? ... ? (2eme difficulté)
Ici tu peux me dire Il suffit de faire un truc générique pour l'arbre puis, pour l'IHM, des gens la feront dans leur domaine de predilection.
Prenons par exemple les serveurs smtp qui gerent le ldap (courier-mta, exim, postfix, qmail, cyrus, sendmail...). Et bein, pour avoir essayé, il est impossible d'utiliser un arbre ldap compatible avec tout ceux là puisqu'ils ne font pas tous la même chose (exim gere les quota, pas postfix sans patch non maintenu), et pas de la même façon (virtual hosting pour qmail/exim par exemple).
Ce qui peut etre vrai pour un truc 100% microsoft, ne le sera pas dans le monde du libre avant que l'on décide d'un standard... Mais qui ? Debian ? Je ne pense pas que cela soit son boulot.
Bref, pas de standard (3eme difficulté).
Il y a un tas d'autres difficultés comme: un password unique pour tous les services ? un password different ? des passwords communs pour certains ? Les services gerent-ils de la même façon les password ? (tout ca depend du besoin). Dans certain cas on peut avoir besoin de transaction. Dommage, pas de transaction dans le standard ldap. Ca veut dire implementer les transactions au niveau applicatif... Ca veut dire de la doc pour ceux qui font les IHM dans leur langage respectif. Il faut aussi gerer le faillover qui n'aura pas la même tête si tu as 1,2 ,3 ou 4 machines dediées (cf les docs sur le HA sous linux).
Bon, hamorniser les services, c'est pas gagné puisque Wietse Venema (postfix) ne veut pas entendre parler de quota pour un smtp, et toute modification se traduira par le x millièmes patch pour Dane Bernstein (qmail)... Et oui, il y a des gens au bout, et il ne faut pas heurter leur sensibilité ou la conception de leur bébé.
Harmoniser les besoins ? Hahem... J'ai rien ecrit.
Pour terminer, on constate que ldap entré dans la norme, ce n'est pas pour demain.
Maintenant si tu souhaites faire un outils pour migrer et gerer tes machines, je suis certain que tu auras beaucoup de soutien (le mien en tout cas), et qu'il ne mettra pas beaucoup de temps a entrer en sid.
Reste à definir le besoin le plus courant (suffit de regarder ce que fait microsoft et les groupes de news à ce propos) et avec quels softs tu vas faire ton système.
Je conclurais en disant que le libre joue la carte de la souplesse et de la diversité des solutions qui est SA force, et qu'il faudrait certainement une coordination autours de certains logiciels, pour justement prendre en compte les besoins les plus communs, et d'etre mieux armée pour chasser sur le territoire des solutions proprios dites "clef en main".
[^] # Re: Debian pour débutants.... une blague !!!
Posté par Gloo . En réponse à la dépêche Le futur installeur Debian. Évalué à 3.
Pourquoi Debian devrait faire evoluer quoi que ce soit ? C'est une distrib. Ca prend les sources chez les developpeurs, les mets dans leur système de package et met les packages à disposition sur le net.
Quand il y a un problème sur un packages, le mainteneur Debian règle le problème. Quand c'est un problème sur le soft (secu, bug...), ca remonte chez le developpeur avec, eventuellement, la solution pour redescendre ensuite.
C'est ca debian. Ce n'est pas, directement en tous cas, son boulot d'"abandonner les vieilles habitudes UNIXiennes"
"LDAP...un peu plus pratiques à administrer"
La plupart des softs (smtp,httpd,pop,imap) ont un support pour identification sur ldap via pam ou sans pam (heureusement).
Lors de la conception, tu te rends compte que tes besoins, les besoins d'une entreprise quelconque ou d'un isp sont radicalement differents. En clair, que la structure de ton arbre sera radicalement differente et idem pour les acl sur cet arbre. (1ere difficulté).
Bref, une fois que ta structure d'arbre et tes ACLs sont arretées, on peut passer au dev de l'IHM. Scripts shell ? Java ? via interface web html? gtk ? ... ? (2eme difficulté)
Ici tu peux me dire Il suffit de faire un truc générique pour l'arbre puis, pour l'IHM, des gens la feront dans leur domaine de predilection.
Prenons par exemple les serveurs smtp qui gerent le ldap (courier-mta, exim, postfix, qmail, cyrus, sendmail...). Et bein, pour avoir essayé, il est impossible d'utiliser un arbre ldap compatible avec tout ceux là puisqu'ils ne font pas tous la même chose (exim gere les quota, pas postfix sans patch non maintenu), et pas de la même façon (virtual hosting pour qmail/exim par exemple).
Ce qui peut etre vrai pour un truc 100% microsoft, ne le sera pas dans le monde du libre avant que l'on décide d'un standard... Mais qui ? Debian ? Je ne pense pas que cela soit son boulot.
Bref, pas de standard (3eme difficulté).
Il y a un tas d'autres difficultés comme: un password unique pour tous les services ? un password different ? des passwords communs pour certains ? Les services gerent-ils de la même façon les password ? (tout ca depend du besoin). Dans certain cas on peut avoir besoin de transaction. Dommage, pas de transaction dans le standard ldap. Ca veut dire implementer les transactions au niveau applicatif... Ca veut dire de la doc pour ceux qui font les IHM dans leur langage respectif. Il faut aussi gerer le faillover qui n'aura pas la même tête si tu as 1,2 ,3 ou 4 machines dediées (cf les docs sur le HA sous linux).
Bon, hamorniser les services, c'est pas gagné puisque Wietse Venema (postfix) ne veut pas entendre parler de quota pour un smtp, et toute modification se traduira par le x millièmes patch pour Dane Bernstein (qmail)... Et oui, il y a des gens au bout, et il ne faut pas heurter leur sensibilité ou la conception de leur bébé.
Harmoniser les besoins ? Hahem... J'ai rien ecrit.
Pour terminer, on constate que ldap entré dans la norme, ce n'est pas pour demain.
Maintenant si tu souhaites faire un outils pour migrer et gerer tes machines, je suis certain que tu auras beaucoup de soutien (le mien en tout cas), et qu'il ne mettra pas beaucoup de temps a entrer en sid.
Reste à definir le besoin le plus courant (suffit de regarder ce que fait microsoft et les groupes de news à ce propos) et avec quels softs tu vas faire ton système.
Je conclurais en disant que le libre joue la carte de la souplesse et de la diversité des solutions qui est SA force, et qu'il faudrait certainement une coordination autours de certains logiciels, pour justement prendre en compte les besoins les plus communs, et d'etre mieux armée pour chasser sur le territoire des solutions proprios dites "clef en main".