Oui, mais cela ne marche pas avec les applications gnome et les bonnes vielles applications. Bilan, gnome développe sa propre couche et donc on a tout en double et les bonnes vielles applications sont mises petits à petits de coté alors qu'elles marchent super bien et sont super utiles dans les scripts.
Bref, ta vision est une vision un peu égoiste des choses. Et comme je l'ai dis plus haut, on peut très bien monter un système de fichier nfs en asynchrone.
Moi ce que je vois, c'est qu'une partie des personnes de kde et de gnome ont pour objectif d'enfermer les utilisateurs dans leur environnement. Moi, cela ne me gène pas d'utiliser une application kde avec une application gnome au coté d'un bon vieux gv qui a une interface pas du tout gnome ou kde mais qui est, à mon sens, pas égalé pour lire des fichiers postscripts.
Rien n'empêche de concevoir un système au niveau du noyau qui gère les systèmes lents... Intermezzo ou Codafs ont par exemple des options pour marcher même si la connection est déconnecté.
Ensuite sur la latence, NFS marchait très bien sur des hub a 10Mb il y a 10 ans. Donc pas besoin d'avoir un réseau gigabit (même si c'est mieux). Toujours avec NFS, il y a une option async pour être en asynchrone et une option intr pour que la connection ne soit pas bloquante. On peux certes mieux faire et c'est justement là ou c'est dommage, car la plupart des développeurs de gnome-vfs et de kio ont, j'en suis sur, des compétences pointus en informatique pour faire ce genre de chose.
Il y a aussi plan9 qui a l'air de faire tout un tas de chose sympathique...
Bref, les API systèmes ne demandent qu'a être améliorer si on arrive effectivement avec quelque chose de cohérent.
Ce qui est vrai pour Corba/bonobo, DCOP -> DBUS ne l'est pas forcément sur les systèmes de fichiers.
D'un coté, on a un bus orienté bureau avec un savoir faire pas énorme à l'époque. De l'autre, on a affaire a des systèmes de fichiers distribués. NFS, Samba... ce ne sont pas des trucs qui n'existaient pas en 2000 ! Ca marchait déjà très bien.
Au niveau des automounteurs, il y avait déjà autofs et amd qui marchaient aussi + ou - bien. Mais enfin, ils sont utilisés en production depuis des années.
Tout ca pour dire qu'il y a une base de personnes très compétentes en systèmes de fichiers qui auraient pu se pencher la dessus plutôt que de construire des trucs très liés au environnement de bureau.
Fuse est du kernel space comme tu le dis pour une partie. En pratique, a pars le noyau fuse, tout est renvoyé en mode utilisateur ! C'est pour cela que tu as des modules fuse en python par exemple. Il y a aussi des modules d'autoversionning...
La partie kernel space est donc juste une interface. Le plus gros problème est donc le passage d'un mode à l'autre qui grève les performances. C'est pour cela qu'il y a un nouveau système de fichier dans les derniers noyaux (je ne me souviens plus de son nom) pour améliorer tout cela.
Question bête : avec les changements dans gcc, est-il possible de compiler la version 3.0 et la version 3.5 avec le même compilateur ?
En effet, gcc ayant pas mal évolué, on a été obliger de modifier le code source pour tenir compte de cette évolution. Il n'est donc effectivement pas sur que si l'API n'ait pas changé, le code soit en pratique compatible.
Heureusement, le C++ est un peu plus stable aujourd'hui.
> donc l'os ne pouvait pas founir ce service à l'époque de l'intégration
> systèmatique de gnome-vfs et kioslave
Sauf qu'on pouvait à l'époque mettre toute l'énergie disponible à construire une API propre (en gros Fuse) plutôt que de développer deux solutions transitoires.
Personnellement, j'utilise Linux depuis 10 ans tous les jours et je ne me suis quasiment jamais servis ni de l'un ni de l'autre. Ne pas les avoir n'aurait en aucune façon modifier mon utilisation de Linux.
Si tu veux un système qui marche pour tous, il n'y a pas le choix, seulement deux solutions :
- une gestion par le noyau
- une gestion par bibliothèque
La gestion en mode noyau peut être faite le mieux possible, c'est à dire mettre le plus de code possible en mode utilisateur. C'est justement le cas de Fuse.
La gestion par bibliothèque a peu de chance d'être générique. Si on souhaite que cela marche quasiment partout, il faut l'intégrer au coeur de la libc. En effet, la libc est linké avec 99% des executables (au pif). Aucune autre bibliothèque n'a cette possibilité.
Mais il y a aussi d'autre problème, les fichiers de type fish:/..., cela est-il conforme à la norme POSIX ? On a critiqué pendant longtemps les C:, D: ... de Microsoft, les UNIX préférant le système de fichier unifié où tout est sous /.
Personnellement, je trouve cela génial de pouvoir intégrer un serveur ftp distant dans mon arborescence / et que l'accès au serveur ftp soit transparent, un peu comme NFS qu'on oublie facilement en tant qu'utilisateur.
Il faut effectivement améliorer la facilité pour un utilisateur de monter un système de fichier distant, améliorer la robustesse de l'ensemble mais cela me parait bien plus positif que de travailler sur les VFS de gnome ou de kde.
Après, on va me dire que, ragnagna, Fuse ne marche pas sur tous les UNIX propriétaire, ne marche pas sous Windows... Et bien tant pis pour eux ! Ils n'ont qu'a faire le portage. Le code source est accessible à la lecture pour tous ;-)
Non, j'ai l'impression d'être cohérent dans l'ensemble ;-)
le VFS de gnome et celui de kde ne sont pas compatibles et ne sont pas utilsables par des applications tierces. Ce n'est au "framework" utilisateur de faire ce genre de chose. Par exemple, "vi" sais-t-il utiliser les url kde du type fish:// ? Bref, ces VFS sont des doublons qui enferment les utilsateurs dans l'un ou l'autre des environnements. Fuse au contraire, malgré des défauts, à l'avantage de s'ouvrir à tous et d'enfermer personne. Bref, je pense que les développeurs des VFS de gnome et de kde devraient mieux travailler sur une couche de plus bas niveau qui puisse servir a TOUS les programmes de manière transparente (je ne veux pas de gconfd, oaf, kdeinit... lorsque je lance vi ou latex !).
Pour la partie son, je ne suis pas sur qu'esd soit beaucoup mieux qu'arts. J'ai l'impression que jackd est de plus en plus utilisé ! Tout cela n'est en rien lié au serveur X. Pourtant, il est logique que le son suive par défaut la même route que X.
Bref, je ne critique pas le fait d'unifié les systèmes, je critique le fait que gnome et kde ont par le passé unifié leur système respectif mais par la même un peu exclu le reste. Compte le nombre de fois ou sur dlfp des personnes ont réclamés un version équivalente gnome d'un logiciel kde et réciproquement. Personnellement, je me fiche pas mal de l'aspect bureau unifié pour le look des applications que j'utilise mais j'en ai un peu marre, il est vrai, que gnome et kde cherchent à m'enfermer sur leur bureau.
Je suis d'accord. Le couche VFS dans gnome et kde est une très mauvaise chose. Les développeurs feraient mieux de travailler sur fuse sous linux et quelque chose d'équivalent sous les BSD...
Idem pour le serveur de son... Chaque aplication doit avoir son backend (oss, alsa, arts, esd...) alors qu'en tant que simple utilisateur, on demande juste à pouvoir entendre le son ! C'est tellement le bordel que ce n'est pas intégré dans ssh. Je ne sais pas pour vous, mais l'unification du protocole X est vraiment une merveille pour tous les UNIX depuis DES ANNEES. Il suffit de faire un ssh -X pour ne plus pouvoir s'en passer. Ecouter du son sur une machine distante est bien plus complexe, tellement complexe que bien peu l'utilise.
Heureusement, freedestop essaye de mettre pas mal de chose à plat. Cependant, cela prend pas mal de temps à se mettre en place. Le son serait plus compliqué que l'affichage graphique ? Je trouve dommage cette dépense d'énergie dans les deux environnements gnome et kde qui pourrait être bien plus bénéfique pour tous si elle était faite de manière communautaire comme X-Windows.
A ma décharge, je n'y connais pas grand chose en multi-média. Je suis un utilisateur plus que lambda. Mes propos sont peut être un amas de bétises.
Avec le premier ssh, tu lances un netcat (ou un socat) sur la machine distante et hop, tu as un acces sur la machine distance avec redirection de terminal...
Bref, d'après ce que j'ai compris de ton truc, j'irais voir de ce coté là.
J'avoue que je suis personnellement en 2.6.15 et que qemu+kqemu marche vraiment très bien. WindowsXP est d'une réactivité surprenante dans la machine virtuelle Linux ;-)
Faut pas exagérer non plus. Ca fait pas mal d'année que les modules Perl utilise le YAML pour spécifier leur fonctionalité.
Bref, le YAML est un truc qui tourne et n'est pas près de s'arréter. Cela m'étonnerais fort que les développeurs Perl remplacent les fichiers YAML par du XML !
Pour ma part, tous mes fichiers de configuration sont en YAML (ou sont un simple systeme clef=valeur). Il est hors de question d'utiliser du XML ou du gconf.
Mais tu as déjà tout cela dans Perl dés aujourd'hui et dans toute distribution linux (et en plus généralement installé par défaut).
Tu ne fais pas de la ligne de commande pour te prendre un objet illisible en retour. Il y a donc bien de la place entre le shell et le langage de script. Le problème de Microsoft est que son shell est minable et que son langage de script n'est pas beaucoup mieux...
Ca marche très bien et il est très facile de mettre une structure d'arbre la dedans.
Pour ceux qui n'y crois pas et pense que dans deux ans, le YAML est mort, ils se trompent. Tous les paquetages perl du CPAN sont décrit par un fichier YAML qui décrit le contenu du paquet. A comparer avec les fichiers abscons des modules de Tomcat...
On voit vite les limites du XML pour faire des fichiers de configuration. Je suis persuadé qu'on mets moins de temps à faire un fichier YAML de config pour un paquetage Perl que faire le fichier XML du module applicatif Tomcat. D'autant plus que sur mes serveurs, il n'y a aucun outils graphique.
Sur une debian, il n'y a pas besoin de modifier pam pour prendre en compte l'identification ldap ! Il suffit en effet de modifier comme tu l'as fait le fichier /etc/nsswitch.conf et de configurer le fichier /etc/libnss-ldap.conf
Comme on est obliger de modifier ces fichiers pour que le systeme connaisse son identité (commande id), il est absolument inutile de rajouter une ligne ldap dans pam, ou si cela est nécessaire, merci de me dire pourquoi car j'ai 20 machines qui fonctionne parfaitement sans ! Bref, pam c'est bien mais ce n'est pas encore suffisant, ce nsswitch traine encore...
Au niveau d'apache, cela n'a rien a voir. Apache tourne sous son identité propre et il n'y a aucun besoin que l'identification sous apache ai un quelconque rapport avec celle du système. Les deux problèmes sont donc dissociés à 100%. A mon avis, tu as une erreur dans ta configuration ldap au niveau d'apache.
D'un autre coté, on peux aussi chiffrer avec des algorithmes assez léger en ressources comme bowfish. Par exemple
ssh -c blowfish
Sur un réseau local dont on est quasi-sur, chiffrer de la sorte évite de tout faire passer en clair ce qui peut tout de même être dangereux et offre une garantie en générale suffisante.
J'ai utilisé LTSP (version 3) pendant quelques temps. Ca marche plutôt bien mais, il ne fallait pas utiliser gnome ou kde. Trop lourd. Cela surcharge le serveur central inutilement.
J'avais fait une configuration aux petits oignons pour mes utilisateurs avec icewm et rox-filer. C'est moins beau mais tu peux alors facilement doubler ou tripler le nombre d'utilisateur sur le serveur central !
Un autre solution à LTSP consiste avec mettre un serveur XVNC sur le serveur central et à installer un client vnc sur les postes des utilisateurs. Cela permet d'éviter de rebooter. Cela n'a pas le même objectif non plus mais permet d'augmenter encore le taux d'utilisation du serveur central (en plus au niveau de la configuration du serveur X du serveur central, c'est quasiment la même chose).
Enfin, plutôt que d'utliser ssh -CX pour chiffrer les transactions, on pourrait aussi mettre freenx. Ca gère une bonne partie de la problèmatique (et ca s'appuie sur ssh). D'ailleurs, ce serait bien que freenx fusionne dans les projets xorg et ssh.
Non, ce n'est pas un projet de gestion de projet mais de gestion des collaborations. Au sein d'un projet, il est clair que l'on peux s'arranger.
Maintenant, essayes de mettre tout le CPAN dans un seul projet ! Ca explose. Le but d'un "namespace" est de permette à des projets différents de mutualiser du code source. c'est pour cela que l'approche java qui préconise de prendre les noms de domaine DNS a l'envers n'est pas bonne et que l'approche du CPAN de Perl est excelente. Elle permet de mutualiser un maximum le code des bibliothèques entre projet.
C'est pas ton Makefile, si bien fait soit-il, qui va te faire cela. Comme je le dis depuis le début, ce n'est pas un problème technique, c'est un problème sociologique. Il fait donc intervenir de multiples personnes. Si vous souhaitez que Lisaac marche, il faut tenir compte un minimum des problèmes sociologiques.
Par exemple, il faut savoir que l'héritage de code et d'interface sont dissociés en Sather. Lorsqu'on dis qu'une classe hérite d'une autre, elle n'hérite que de l'interface. L'héritage de code doit être explcité avec le mot clef "include".
Ca fait bizarre la première fois mais dans les fait, c'est pas du tout génant, c'est même mieux car très clair. Et maintenant, pas mal de langage rajoute la notion d'interface à la notion de classe (Eiffel compris) quand elle n'ajoute pas aussi l'inclusion de code ! Bref, la aussi, Sather en séparant les rôles a finalement simplifié et se montre au final plus souple.
Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel. Ca ne l'aide pas non plus. A cela s'ajoute qu'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN". Le C s'en sors très bien sans mais pour des raisons historiques.
IIl parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac. S'il est vrai que cela n'a aucun intérêt technique pour le compilateur, ca a un intérêt social énorme pour les développeurs.
> ça oblige à continuer avec les mauvais choix de design qui ont été
> faits au début. Et il ne faut pas se leurrer, on fait toujours des
> mauvais choix au début :)
Je ne suis pas d'accord. On fait effectivement des mauvais choix mais on fait aussi des bons choix à l'instant t qui s'avère être des mauvais choix à l'instant t+1. C'est normal, inévitable et même une bonne chose, cela signifie tout simplement que l'objet technique évolue et est vivant (cf Bruno Latour).
C'est donc dans la conception du langage, des bibliothèques... qu'il faut s'accorder des espaces de liberté et ne pas trop contraindre le langage, les bibliothèques... Sinon ceux-ci auront du mal à évoluer et seront donc condannés à une mort quasi-certaine.
C'est d'ailleurs ce que je critique un peu dans Eiffel, il est très beau mais trop contraint.
Meyer se fait parfois le chantre de la programmation objet, notament dans son bouquin. Il a cherché a faire un langage unifié et cohérent. Il passe beaucoup de temps a fusionné le concept de "thread" et celui d'objet dans scoop (toujours pas implémenté à ma connaissance) et il laisse un brèche ouverte avec le concept de covariance qui, tu es d'accord, peut rendre les programmes invalides !
Les personnes qui ont développés Sather ont montré que les exemples de Meyer était "bidon" et qu'on pouvait très bien les refaire en contravariant en utilisant la généricité. Je ne suis pas spécialiste des langages mais je n'aime pas le sacrifice qu'a fait Eiffel, ce trous dans le langage, surtout s'il y a une autre possibilité, qui elle n'a aucun trous !
Par ailleurs, il ne faut pas en faire un plat non plus. Le C++ n'a pas de variance du tout et des milliers d'applications réelles sont développés avec. Eiffel est un nain négligeable à coté, Sather étant lui même un nain à coté d'Eiffel.
Sather est malheureusement virtuellement mort aujourd'hui, l'équipe de recherche qui le développait aux états unis ayant vu ses crédits arrétés. Au moment de son arrêt, vers 1999 d'après mes souvenirs, l'environnement de développement était pas si mal (il y avait même une option de compilation pour activer la reflexivité).
Je me suis amusé un peu sur Eiffel vers 1998 puis j'avais essayé Sather. Il a lui aussi des défauts mais comparativement, quel bonheur. Le langage semble bien moins lourds ;-) Il est clair que pour celui qui débite du code Eiffel à longueur de journée, ce type d'argument n'est pas valable.
Si je parle de Sather ici, ce n'est pas pour changer Eiffel, la suppression de la covariance dans Eiffel reviendrait à refaire un autre langage. Mais justement l'INRIA avec Lisaac fait un nouveau langage et ils trainent sur ce forum. Mes quelques post de néophite ne sont que des messages subliminaux ;-)
Pour en revenir au compilateur Sather, il existe toujours et doit toujours marcher. Le paquet debian a été malheurement enlevé de l'archive. Je ne conseille à personne de développer un gros projet en Sather aujourd'hui. Cela n'empêche pas de voir en lui un petit frère d'Eiffel qui a trouvé un voie intéressante mais non finit.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
Bref, ta vision est une vision un peu égoiste des choses. Et comme je l'ai dis plus haut, on peut très bien monter un système de fichier nfs en asynchrone.
Moi ce que je vois, c'est qu'une partie des personnes de kde et de gnome ont pour objectif d'enfermer les utilisateurs dans leur environnement. Moi, cela ne me gène pas d'utiliser une application kde avec une application gnome au coté d'un bon vieux gv qui a une interface pas du tout gnome ou kde mais qui est, à mon sens, pas égalé pour lire des fichiers postscripts.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
Ensuite sur la latence, NFS marchait très bien sur des hub a 10Mb il y a 10 ans. Donc pas besoin d'avoir un réseau gigabit (même si c'est mieux). Toujours avec NFS, il y a une option async pour être en asynchrone et une option intr pour que la connection ne soit pas bloquante. On peux certes mieux faire et c'est justement là ou c'est dommage, car la plupart des développeurs de gnome-vfs et de kio ont, j'en suis sur, des compétences pointus en informatique pour faire ce genre de chose.
Il y a aussi plan9 qui a l'air de faire tout un tas de chose sympathique...
Bref, les API systèmes ne demandent qu'a être améliorer si on arrive effectivement avec quelque chose de cohérent.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
D'un coté, on a un bus orienté bureau avec un savoir faire pas énorme à l'époque. De l'autre, on a affaire a des systèmes de fichiers distribués. NFS, Samba... ce ne sont pas des trucs qui n'existaient pas en 2000 ! Ca marchait déjà très bien.
Au niveau des automounteurs, il y avait déjà autofs et amd qui marchaient aussi + ou - bien. Mais enfin, ils sont utilisés en production depuis des années.
Tout ca pour dire qu'il y a une base de personnes très compétentes en systèmes de fichiers qui auraient pu se pencher la dessus plutôt que de construire des trucs très liés au environnement de bureau.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
La partie kernel space est donc juste une interface. Le plus gros problème est donc le passage d'un mode à l'autre qui grève les performances. C'est pour cela qu'il y a un nouveau système de fichier dans les derniers noyaux (je ne me souviens plus de son nom) pour améliorer tout cela.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 4.
[^] # Re: durée de vie de KDE.
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
En effet, gcc ayant pas mal évolué, on a été obliger de modifier le code source pour tenir compte de cette évolution. Il n'est donc effectivement pas sur que si l'API n'ait pas changé, le code soit en pratique compatible.
Heureusement, le C++ est un peu plus stable aujourd'hui.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
> systèmatique de gnome-vfs et kioslave
Sauf qu'on pouvait à l'époque mettre toute l'énergie disponible à construire une API propre (en gros Fuse) plutôt que de développer deux solutions transitoires.
Personnellement, j'utilise Linux depuis 10 ans tous les jours et je ne me suis quasiment jamais servis ni de l'un ni de l'autre. Ne pas les avoir n'aurait en aucune façon modifier mon utilisation de Linux.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
- une gestion par le noyau
- une gestion par bibliothèque
La gestion en mode noyau peut être faite le mieux possible, c'est à dire mettre le plus de code possible en mode utilisateur. C'est justement le cas de Fuse.
La gestion par bibliothèque a peu de chance d'être générique. Si on souhaite que cela marche quasiment partout, il faut l'intégrer au coeur de la libc. En effet, la libc est linké avec 99% des executables (au pif). Aucune autre bibliothèque n'a cette possibilité.
Mais il y a aussi d'autre problème, les fichiers de type fish:/..., cela est-il conforme à la norme POSIX ? On a critiqué pendant longtemps les C:, D: ... de Microsoft, les UNIX préférant le système de fichier unifié où tout est sous /.
Personnellement, je trouve cela génial de pouvoir intégrer un serveur ftp distant dans mon arborescence / et que l'accès au serveur ftp soit transparent, un peu comme NFS qu'on oublie facilement en tant qu'utilisateur.
Il faut effectivement améliorer la facilité pour un utilisateur de monter un système de fichier distant, améliorer la robustesse de l'ensemble mais cela me parait bien plus positif que de travailler sur les VFS de gnome ou de kde.
Après, on va me dire que, ragnagna, Fuse ne marche pas sur tous les UNIX propriétaire, ne marche pas sous Windows... Et bien tant pis pour eux ! Ils n'ont qu'a faire le portage. Le code source est accessible à la lecture pour tous ;-)
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
le VFS de gnome et celui de kde ne sont pas compatibles et ne sont pas utilsables par des applications tierces. Ce n'est au "framework" utilisateur de faire ce genre de chose. Par exemple, "vi" sais-t-il utiliser les url kde du type fish:// ? Bref, ces VFS sont des doublons qui enferment les utilsateurs dans l'un ou l'autre des environnements. Fuse au contraire, malgré des défauts, à l'avantage de s'ouvrir à tous et d'enfermer personne. Bref, je pense que les développeurs des VFS de gnome et de kde devraient mieux travailler sur une couche de plus bas niveau qui puisse servir a TOUS les programmes de manière transparente (je ne veux pas de gconfd, oaf, kdeinit... lorsque je lance vi ou latex !).
Pour la partie son, je ne suis pas sur qu'esd soit beaucoup mieux qu'arts. J'ai l'impression que jackd est de plus en plus utilisé ! Tout cela n'est en rien lié au serveur X. Pourtant, il est logique que le son suive par défaut la même route que X.
Bref, je ne critique pas le fait d'unifié les systèmes, je critique le fait que gnome et kde ont par le passé unifié leur système respectif mais par la même un peu exclu le reste. Compte le nombre de fois ou sur dlfp des personnes ont réclamés un version équivalente gnome d'un logiciel kde et réciproquement. Personnellement, je me fiche pas mal de l'aspect bureau unifié pour le look des applications que j'utilise mais j'en ai un peu marre, il est vrai, que gnome et kde cherchent à m'enfermer sur leur bureau.
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 4.
Idem pour le serveur de son... Chaque aplication doit avoir son backend (oss, alsa, arts, esd...) alors qu'en tant que simple utilisateur, on demande juste à pouvoir entendre le son ! C'est tellement le bordel que ce n'est pas intégré dans ssh. Je ne sais pas pour vous, mais l'unification du protocole X est vraiment une merveille pour tous les UNIX depuis DES ANNEES. Il suffit de faire un ssh -X pour ne plus pouvoir s'en passer. Ecouter du son sur une machine distante est bien plus complexe, tellement complexe que bien peu l'utilise.
Heureusement, freedestop essaye de mettre pas mal de chose à plat. Cependant, cela prend pas mal de temps à se mettre en place. Le son serait plus compliqué que l'affichage graphique ? Je trouve dommage cette dépense d'énergie dans les deux environnements gnome et kde qui pourrait être bien plus bénéfique pour tous si elle était faite de manière communautaire comme X-Windows.
A ma décharge, je n'y connais pas grand chose en multi-média. Je suis un utilisateur plus que lambda. Mes propos sont peut être un amas de bétises.
# netcat
Posté par Sytoka Modon (site web personnel) . En réponse au message ececution de commande dans un shell distant. Évalué à 2.
Bref, d'après ce que j'ai compris de ton truc, j'irais voir de ce coté là.
[^] # Re: Très sain
Posté par Sytoka Modon (site web personnel) . En réponse au journal Les programmes compilés par EiffelStudio doivent être en GPL. Évalué à 2.
Donc, cela n'empêche pas /a priori/ l'utilisation de bibliothèque sous licence BSD avec l'IDE EiffelStudio.
Je pense qu'il en ai de même avec les licences de type MIT ?
# Changement de nom
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Sylpheed-Claws 2.2.0. Évalué à 6.
Pourquoi pas Sylclaws !
[^] # Re: Module d'accélération kqemu pour qemu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Module d'accélération kqemu pour qemu. Évalué à 4.
[^] # Re: XML c'est bien
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 4.
Pour les grosses structures, les scientifiques ont aussi des solutions qui marchent depuis des années, binaire et multiplateforme : HDF par exemple.
Je ne dis pas que HDF résoud tous les problèmes, simplement qu'il faut arréter de nous mettre du XML partout.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 3.
Bref, le YAML est un truc qui tourne et n'est pas près de s'arréter. Cela m'étonnerais fort que les développeurs Perl remplacent les fichiers YAML par du XML !
Pour ma part, tous mes fichiers de configuration sont en YAML (ou sont un simple systeme clef=valeur). Il est hors de question d'utiliser du XML ou du gconf.
[^] # Re: /proc
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 4.
Tu ne fais pas de la ligne de commande pour te prendre un objet illisible en retour. Il y a donc bien de la place entre le shell et le langage de script. Le problème de Microsoft est que son shell est minable et que son langage de script n'est pas beaucoup mieux...
[^] # Re: Uniformisation des formats ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 3.
Ca marche très bien et il est très facile de mettre une structure d'arbre la dedans.
Pour ceux qui n'y crois pas et pense que dans deux ans, le YAML est mort, ils se trompent. Tous les paquetages perl du CPAN sont décrit par un fichier YAML qui décrit le contenu du paquet. A comparer avec les fichiers abscons des modules de Tomcat...
On voit vite les limites du XML pour faire des fichiers de configuration. Je suis persuadé qu'on mets moins de temps à faire un fichier YAML de config pour un paquetage Perl que faire le fichier XML du module applicatif Tomcat. D'autant plus que sur mes serveurs, il n'y a aucun outils graphique.
# identification ldap
Posté par Sytoka Modon (site web personnel) . En réponse au message soucis d'authentification sur apache et ldap. Évalué à 2.
Comme on est obliger de modifier ces fichiers pour que le systeme connaisse son identité (commande id), il est absolument inutile de rajouter une ligne ldap dans pam, ou si cela est nécessaire, merci de me dire pourquoi car j'ai 20 machines qui fonctionne parfaitement sans ! Bref, pam c'est bien mais ce n'est pas encore suffisant, ce nsswitch traine encore...
Au niveau d'apache, cela n'a rien a voir. Apache tourne sous son identité propre et il n'y a aucun besoin que l'identification sous apache ai un quelconque rapport avec celle du système. Les deux problèmes sont donc dissociés à 100%. A mon avis, tu as une erreur dans ta configuration ldap au niveau d'apache.
Bon courage
[^] # Re: Soft ou distrib complète?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux Terminal Server Project 4.2. Évalué à 3.
ssh -c blowfish
Sur un réseau local dont on est quasi-sur, chiffrer de la sorte évite de tout faire passer en clair ce qui peut tout de même être dangereux et offre une garantie en générale suffisante.
[^] # Re: Mythes...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux Terminal Server Project 4.2. Évalué à 6.
J'avais fait une configuration aux petits oignons pour mes utilisateurs avec icewm et rox-filer. C'est moins beau mais tu peux alors facilement doubler ou tripler le nombre d'utilisateur sur le serveur central !
Un autre solution à LTSP consiste avec mettre un serveur XVNC sur le serveur central et à installer un client vnc sur les postes des utilisateurs. Cela permet d'éviter de rebooter. Cela n'a pas le même objectif non plus mais permet d'augmenter encore le taux d'utilisation du serveur central (en plus au niveau de la configuration du serveur X du serveur central, c'est quasiment la même chose).
Enfin, plutôt que d'utliser ssh -CX pour chiffrer les transactions, on pourrait aussi mettre freenx. Ca gère une bonne partie de la problèmatique (et ca s'appuie sur ssh). D'ailleurs, ce serait bien que freenx fusionne dans les projets xorg et ssh.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 7.
Maintenant, essayes de mettre tout le CPAN dans un seul projet ! Ca explose. Le but d'un "namespace" est de permette à des projets différents de mutualiser du code source. c'est pour cela que l'approche java qui préconise de prendre les noms de domaine DNS a l'envers n'est pas bonne et que l'approche du CPAN de Perl est excelente. Elle permet de mutualiser un maximum le code des bibliothèques entre projet.
C'est pas ton Makefile, si bien fait soit-il, qui va te faire cela. Comme je le dis depuis le début, ce n'est pas un problème technique, c'est un problème sociologique. Il fait donc intervenir de multiples personnes. Si vous souhaitez que Lisaac marche, il faut tenir compte un minimum des problèmes sociologiques.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
En voici un sorti de la documentation de Sather. Il est vrai qu'il vaut mieux comprendre un peu le système de type de Sather pour tout piger.
http://www.icsi.berkeley.edu/~sather/Documentation/EclecticT(...)
Par exemple, il faut savoir que l'héritage de code et d'interface sont dissociés en Sather. Lorsqu'on dis qu'une classe hérite d'une autre, elle n'hérite que de l'interface. L'héritage de code doit être explcité avec le mot clef "include".
Ca fait bizarre la première fois mais dans les fait, c'est pas du tout génant, c'est même mieux car très clair. Et maintenant, pas mal de langage rajoute la notion d'interface à la notion de classe (Eiffel compris) quand elle n'ajoute pas aussi l'inclusion de code ! Bref, la aussi, Sather en séparant les rôles a finalement simplifié et se montre au final plus souple.
Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel. Ca ne l'aide pas non plus. A cela s'ajoute qu'Eiffel ne gère pas les "namespace" et ce point là est très génant si on veut avoir une grosse bibliothèque "a la CPAN". Le C s'en sors très bien sans mais pour des raisons historiques.
IIl parait que Benoit Sonntag n'est pas chaud pour rajouter cette fonctionalité dans Lisaac. S'il est vrai que cela n'a aucun intérêt technique pour le compilateur, ca a un intérêt social énorme pour les développeurs.
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 6.
> faits au début. Et il ne faut pas se leurrer, on fait toujours des
> mauvais choix au début :)
Je ne suis pas d'accord. On fait effectivement des mauvais choix mais on fait aussi des bons choix à l'instant t qui s'avère être des mauvais choix à l'instant t+1. C'est normal, inévitable et même une bonne chose, cela signifie tout simplement que l'objet technique évolue et est vivant (cf Bruno Latour).
C'est donc dans la conception du langage, des bibliothèques... qu'il faut s'accorder des espaces de liberté et ne pas trop contraindre le langage, les bibliothèques... Sinon ceux-ci auront du mal à évoluer et seront donc condannés à une mort quasi-certaine.
C'est d'ailleurs ce que je critique un peu dans Eiffel, il est très beau mais trop contraint.
[^] # Re: Goûtez-y !
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 3.
Les personnes qui ont développés Sather ont montré que les exemples de Meyer était "bidon" et qu'on pouvait très bien les refaire en contravariant en utilisant la généricité. Je ne suis pas spécialiste des langages mais je n'aime pas le sacrifice qu'a fait Eiffel, ce trous dans le langage, surtout s'il y a une autre possibilité, qui elle n'a aucun trous !
Par ailleurs, il ne faut pas en faire un plat non plus. Le C++ n'a pas de variance du tout et des milliers d'applications réelles sont développés avec. Eiffel est un nain négligeable à coté, Sather étant lui même un nain à coté d'Eiffel.
Sather est malheureusement virtuellement mort aujourd'hui, l'équipe de recherche qui le développait aux états unis ayant vu ses crédits arrétés. Au moment de son arrêt, vers 1999 d'après mes souvenirs, l'environnement de développement était pas si mal (il y avait même une option de compilation pour activer la reflexivité).
Je me suis amusé un peu sur Eiffel vers 1998 puis j'avais essayé Sather. Il a lui aussi des défauts mais comparativement, quel bonheur. Le langage semble bien moins lourds ;-) Il est clair que pour celui qui débite du code Eiffel à longueur de journée, ce type d'argument n'est pas valable.
Si je parle de Sather ici, ce n'est pas pour changer Eiffel, la suppression de la covariance dans Eiffel reviendrait à refaire un autre langage. Mais justement l'INRIA avec Lisaac fait un nouveau langage et ils trainent sur ce forum. Mes quelques post de néophite ne sont que des messages subliminaux ;-)
Pour en revenir au compilateur Sather, il existe toujours et doit toujours marcher. Le paquet debian a été malheurement enlevé de l'archive. Je ne conseille à personne de développer un gros projet en Sather aujourd'hui. Cela n'empêche pas de voir en lui un petit frère d'Eiffel qui a trouvé un voie intéressante mais non finit.