Est'il prévu un jour d'intégrer une partie du protocle nx dans un serveur X et dans ssh (par exemple comme le module vnc pour X) ? Ce serait utilisable par exemple au travers d'une nouvelle option comme la très pratique option -X de ssh.
La protocole nx étant impressionant, il s'agit plus en pratique d'un accès a un bureau distant comme RDP ou VNC qu'à un shell distant de type ssh. Est'il prévu d'intégrer le protocle nx dans l'outil de connexion tsclient ?
Enfin, ce n'est pas à l'ordre du jour d'après ce que j'ai cru voir récement, mais il serait amusant de pouvoir partager la connexion distante. Je viens de découvrir 'collaborative vnc', c'est le genre d'outil que certains de mes utilisateurs seraient fanatiques. Pour le moment, on utilise un outil ultra propriétaire sous Windows uniquement qui permet de partager applications, voix et vidéo (vignette) : Arel. Et il est vrai qu'il est, lui-aussi, assez bluffant sur des connexions à faible débit.
Cela veut'il dire qu'on n'est plus obligé d'avoir la clef publique du serveur toujours au même endroit sur le poste client ? C'etait un problème jusqu'à présent si on souhaitais se connecter sur différent serveur.
J'aurais bien vu un système 'à la ssh' où on télécharge la première fois la clef publique du serveur en la validant et qu'ensuite, le client ne pose plus de question tant que cette clef ne change pas.
Je ne suis pas d'accord. psfrag ne marche pas avec le pdf. Or je compile a l'heure actuelle tous mes documents avec latex et avec pdflatex.
Je suis d'accord pour dire que xfig est irremplaçable aujourd'hui si on veut faire des schémas avec des vrais flêches fines et propres et SURTOUT si l'on veut y insérer du code LaTeX. Je n'ai pas vu d'autre logiciel permettant cette qualité. Dans xfig, tu peux exporter en PS+LaTeX ou en PDF+LaTeX. Pour ceux qui n'aime pas exporter et aime bien les Makefile, on peut rajouter une règle qui réalise l'exportation automatiquement avec la commande 'fig2dev'.
Pour l'exportation LaTeX, je pense qu'une partie de l'avenir est d'essayer d'utiliser le paquetage 'pgf', moins puissant que 'pstrick' mais compatible avec le postscript et le pdf. C'est le créateur de beamer qui l'a fait. La qualité des trasnparents réalisé avec beamer est impressionante.
Il existe par exemple aap, c'est écrit en Python et ca utilise une syntaxe voisine du makefile.
http://www.a-a-p.org/
Je ne dis pas que je suis fanat non plus ;-) La syntaxe est plus humaine mais à mes derniers essais, il faut écrire des extensions en Python si on souhaite l'étendre. Or je ne suis pas un fan de Python par gout personnel.
Le fichier 'rules' des paquets debian est un exemple de Makefile travaillé avec des extensions par scripts. On se retrouve avec un Makefile relativement simple au bout du compte.
Mais bon, il y a une mode XML...
Sinon, je n'ai pas fait de namespace en YAML car il est vrai que je l'utilise dans des cas assez simple. Mais tout structure arborescente peux s'écrire en YAML tout comme en XML. Donc il est possible en théorie de faire un outils 'yml2xml' et réciproquement.
Avec le bout d'exemple d'un post ci-dessus, c'est typique des nouveaux outils dérivée d'ANT. Du XML partout. C'est super pour les IDE mais horrible pour l'homme.
Honnêtement, un bon vieux Makefile peut être bien plus lisible. Le plus gros défaut du Makefile à mon avis, c'est la tabulation en début des lignes de commande. Je ne comprends pas qu'on ne puisse dire que les lignes commançant par '->' soient équivalentes aux lignes commençant par une tabulation.
L'inconvénient des outils intégrés autour du XML, à part la mauvaise lisibilité, est le manque de souplesse. Ce qui est génial dans un Makefile est le mélange de deux langages dont l'un est très souple et peut être changé (variable SHELL). Rien n'empêche de développer des scripts 'a la Ant' qui rendrait la compilation pour certains langages plus claire que dans un Makefile actuel. Il n'y a pas besoin de se mouler dans un environnement de type Java comme dans Maven ou Ant.
Enfin, j'en remet une couche sur le YAML. Faites du YAML pour vos fichiers de données (configurations ou résultats) qui doivent pouvoir être ouvert par un éditeur et non du XML ;-).
Et pourquoi pas au format YAML. Personnellement, le XML me "gonfle" lorsqu'il s'agit de faire des fichiers de configuration. Avec le YAML, on a quasiment la même chose, mais avec une orientation humaine...
A ma connaissance, Catia tourne sous Linux chez Dassault mais il ne le distribue pas. Pourquoi ?
Je comprenais leur position du temps où il n'était pas facile d'avoir une accélération 3D correcte. Aujourd'hui, c'est possible d'avoir de l'opengl performant au prix de driver non libre. Mais cela, je pense que Dassault n'en a cure...
Nous sommes d'accord. L'INRIA ne semble pas réellement motivé par l'utilisation de son langage...
Que l'équipe de recherche ne veuille pas se charger de ça, je le comprends fort bien. C'est pour cela que j'invoque l'étage au dessus.
Si l'on veut faire du transfert, il faut mettre quelques moyens humains et matériels. Ce n'est pas forcément une tache à rajouter encore aux chercheurs (on les encombre déjà bien assez avec de la paperasse sans intérêt).
Je ne dis pas que c'est trivial. Mais j'évoque l'INRIA, pas une simple association de quartier. Je pense qu'un EPST ayant un forte consonnance informatique est capable de mener ce genre de projet, sinon je trouve cela inquiétant.
Désolé mais ca n'a rien à voir. Sur le CTAN et le CPAN, il y a TOUS les sources. Ce ne sont pas simplement des bases de données de liens.
Avec un système centralisé, tu donnes tes sources à la communauté. Dans le cas "The Caml Hump", tu acceptes que la communauté vienne chez toi. Il t'es facile ensuite de supprimer cet accès. Ce n'est pas un système pérenne.
Personnellement, je ne comprends pas qu'avec ses moyens, l'INRIA ne mette pas en place un "Comprehensive Objective Caml Archive Network", à la manière de Perl et de TeX.
C'est personnellement un de mes principals frein à son utilisation. Allez chercher ici ou là des paquets est franchement ennuyeux et peu fiable dans le temps.
Une archive centralisé permet d'avoir une dynamique communautaire forte. Je ne dis pas que ça marchera mais que serait Perl et TeX sans le CPAN et le CTAN aujourd'hui. A mon avis, peu de chose.
Je ne suis pas sur qu'aujourd'hui, OCaml ai envie de jouer dans la cour des grands...
De ces scripts sont sortis tout un tas d'outils plus ou moins évolués comme baclkupppc si je ne me tompe.
L'idéal est aussi de faire une partition LVM afin de lancer une partition lvm snapshot avant de lancer le script de sauvagarde. Ainsi, on est sur de ne pas avoir de modification des fichiers lors de la sauvegarde.
J'ai vu une autre méthode qui paraissait intéressante utilisant le démon fam pour connaître les fichiers modifiés et les archiver à chaud. Malheureusement, je n'ai pas encore testé et je ne connais pas la robustesse de ce procédé.
C'est possible aussi avec "xvidcap". Ca marche très bien aussi. Cela génère un film au format AVI ou MPEG, on peut même le mettre ensuite sur un serveur de streaming !
L'avantage et ou l'inconvénient, c'est que c'est du natif XWindow.
Ca fait trois ans que j'en fait ! Je regrette juste une chose, ca ne marche pas avec apache2 et ca n'a pas mal de bouger beaucoup ces derniers temps.
Sinon, il faut un peu de temps pour rentrer dans AxKit mais après c'est formidable. Il est très facile de faire des formulaires. Je me suis fait par exemple ma propre extension qui charge le code perl d'une page html si un fichier du même nom existe (dans une arborescence parallèle (faut pas être fou)). Ca parait bête mais la complète dissociation code Perl / code HTML permet de ré-utiliser le code source bien plus facilement.
Il y a un peu trop de variables globales à mon humble avis dans AxKit et c'est parfois pas assez objet. Par exemple, le coup des formulaires, l'idéal aurait été de définir une classe comme nom du formulaire et de simplement connecter les méthodes de la classe au champ du formulaire... Je vais peut être le faire, ca me simplifierai grandement mon code.
C'est un environnement XML en Perl "à la cocoon" (Java). Tu peux mélanger le code Perl et le xhtml mais en général, il y a une complète séparation des deux. Même avec du code Perl embarqué, le xml reste valide !
Dans un reseau formé de machine Linux, nfs est pour le moment plus performant que samba. Par ailleurs, avec l'automounter, c'est une merveille.
Je suis d'accord avec un un post ci-dessus. Au niveau des droits, il manque quelques reglages ici ou là. Par exemple, le nombre de groupe par personne est limité (par nfs notament) et il n'est pas possible de faire de l'imbrication de groupe. Dans la plupart des cas, une meilheure gestion des groupes suffirait.
# SSH, tsclient..
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 1.5.0 de NX. Évalué à 5.
La protocole nx étant impressionant, il s'agit plus en pratique d'un accès a un bureau distant comme RDP ou VNC qu'à un shell distant de type ssh. Est'il prévu d'intégrer le protocle nx dans l'outil de connexion tsclient ?
Enfin, ce n'est pas à l'ordre du jour d'après ce que j'ai cru voir récement, mais il serait amusant de pouvoir partager la connexion distante. Je viens de découvrir 'collaborative vnc', c'est le genre d'outil que certains de mes utilisateurs seraient fanatiques. Pour le moment, on utilise un outil ultra propriétaire sous Windows uniquement qui permet de partager applications, voix et vidéo (vignette) : Arel. Et il est vrai qu'il est, lui-aussi, assez bluffant sur des connexions à faible débit.
[^] # Re: Joie et volupté :)
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 1.5.0 de NX. Évalué à 1.
J'aurais bien vu un système 'à la ssh' où on télécharge la première fois la clef publique du serveur en la validant et qu'ensuite, le client ne pose plus de question tant que cette clef ne change pas.
[^] # Re: Flèches convenables ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Inkscape 0.42. Évalué à 1.
Je suis d'accord pour dire que xfig est irremplaçable aujourd'hui si on veut faire des schémas avec des vrais flêches fines et propres et SURTOUT si l'on veut y insérer du code LaTeX. Je n'ai pas vu d'autre logiciel permettant cette qualité. Dans xfig, tu peux exporter en PS+LaTeX ou en PDF+LaTeX. Pour ceux qui n'aime pas exporter et aime bien les Makefile, on peut rajouter une règle qui réalise l'exportation automatiquement avec la commande 'fig2dev'.
Pour l'exportation LaTeX, je pense qu'une partie de l'avenir est d'essayer d'utiliser le paquetage 'pgf', moins puissant que 'pstrick' mais compatible avec le postscript et le pdf. C'est le créateur de beamer qui l'a fait. La qualité des trasnparents réalisé avec beamer est impressionante.
http://latex-beamer.sourceforge.net/
[^] # Re: Maven ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Un fichier standardisé pour décrire un projet. Évalué à 1.
http://www.a-a-p.org/
Je ne dis pas que je suis fanat non plus ;-) La syntaxe est plus humaine mais à mes derniers essais, il faut écrire des extensions en Python si on souhaite l'étendre. Or je ne suis pas un fan de Python par gout personnel.
Le fichier 'rules' des paquets debian est un exemple de Makefile travaillé avec des extensions par scripts. On se retrouve avec un Makefile relativement simple au bout du compte.
Mais bon, il y a une mode XML...
Sinon, je n'ai pas fait de namespace en YAML car il est vrai que je l'utilise dans des cas assez simple. Mais tout structure arborescente peux s'écrire en YAML tout comme en XML. Donc il est possible en théorie de faire un outils 'yml2xml' et réciproquement.
[^] # Re: Maven ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Un fichier standardisé pour décrire un projet. Évalué à 1.
Honnêtement, un bon vieux Makefile peut être bien plus lisible. Le plus gros défaut du Makefile à mon avis, c'est la tabulation en début des lignes de commande. Je ne comprends pas qu'on ne puisse dire que les lignes commançant par '->' soient équivalentes aux lignes commençant par une tabulation.
L'inconvénient des outils intégrés autour du XML, à part la mauvaise lisibilité, est le manque de souplesse. Ce qui est génial dans un Makefile est le mélange de deux langages dont l'un est très souple et peut être changé (variable SHELL). Rien n'empêche de développer des scripts 'a la Ant' qui rendrait la compilation pour certains langages plus claire que dans un Makefile actuel. Il n'y a pas besoin de se mouler dans un environnement de type Java comme dans Maven ou Ant.
Enfin, j'en remet une couche sur le YAML. Faites du YAML pour vos fichiers de données (configurations ou résultats) qui doivent pouvoir être ouvert par un éditeur et non du XML ;-).
[^] # Re: Dans le même style
Posté par Sytoka Modon (site web personnel) . En réponse au journal Un fichier standardisé pour décrire un projet. Évalué à -2.
[^] # Re: Catia sous linux
Posté par Sytoka Modon (site web personnel) . En réponse au message WINE et multi-processeur sous Debian 3.1. Évalué à 1.
Je comprenais leur position du temps où il n'était pas facile d'avoir une accélération 3D correcte. Aujourd'hui, c'est possible d'avoir de l'opengl performant au prix de driver non libre. Mais cela, je pense que Dassault n'en a cure...
[^] # Re: heu
Posté par Sytoka Modon (site web personnel) . En réponse au message WINE et multi-processeur sous Debian 3.1. Évalué à 1.
La carte graphique n'est pas accélére opengl sous qemu. Ca me parait donc pas intéressant pour Catia.
# XMX ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Xorg dans Sid. Évalué à 3.
http://www.cs.brown.edu/software/xmx/
[^] # Re: COCAN ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vitalité d'Objective Caml ?. Évalué à 1.
Que l'équipe de recherche ne veuille pas se charger de ça, je le comprends fort bien. C'est pour cela que j'invoque l'étage au dessus.
Si l'on veut faire du transfert, il faut mettre quelques moyens humains et matériels. Ce n'est pas forcément une tache à rajouter encore aux chercheurs (on les encombre déjà bien assez avec de la paperasse sans intérêt).
[^] # Re: COCAN ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vitalité d'Objective Caml ?. Évalué à 1.
[^] # Re: COCAN ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vitalité d'Objective Caml ?. Évalué à 1.
Désolé mais ca n'a rien à voir. Sur le CTAN et le CPAN, il y a TOUS les sources. Ce ne sont pas simplement des bases de données de liens.
Avec un système centralisé, tu donnes tes sources à la communauté. Dans le cas "The Caml Hump", tu acceptes que la communauté vienne chez toi. Il t'es facile ensuite de supprimer cet accès. Ce n'est pas un système pérenne.
# COCAN ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vitalité d'Objective Caml ?. Évalué à 3.
C'est personnellement un de mes principals frein à son utilisation. Allez chercher ici ou là des paquets est franchement ennuyeux et peu fiable dans le temps.
Une archive centralisé permet d'avoir une dynamique communautaire forte. Je ne dis pas que ça marchera mais que serait Perl et TeX sans le CPAN et le CTAN aujourd'hui. A mon avis, peu de chose.
Je ne suis pas sur qu'aujourd'hui, OCaml ai envie de jouer dans la cour des grands...
[^] # Re: Charge reseau
Posté par Sytoka Modon (site web personnel) . En réponse au journal Linux, ssh et X11/win. Évalué à 1.
Mais comme disais l'un des posts, c'est dommage de ne pas avoir une authentification classique comme ssh.
Quelqu'un a t'il deja deploye freenx avec 400 utilisateurs ?
[^] # Charge reseau
Posté par Sytoka Modon (site web personnel) . En réponse au journal Linux, ssh et X11/win. Évalué à 1.
ssh -CX toto@computer
Normalement, comprimer le flux ssh devrait avoir a peu pres le meme effet que nx ?
# cp + rsync + ssh
Posté par Sytoka Modon (site web personnel) . En réponse au journal Sauvegarde pour serveur. Évalué à 3.
http://www.mikerubel.org/computers/rsync_snapshots/
De ces scripts sont sortis tout un tas d'outils plus ou moins évolués comme baclkupppc si je ne me tompe.
L'idéal est aussi de faire une partition LVM afin de lancer une partition lvm snapshot avant de lancer le script de sauvagarde. Ainsi, on est sur de ne pas avoir de modification des fichiers lors de la sauvegarde.
J'ai vu une autre méthode qui paraissait intéressante utilisant le démon fam pour connaître les fichiers modifiés et les archiver à chaud. Malheureusement, je n'ai pas encore testé et je ne connais pas la robustesse de ce procédé.
[^] # Re: pwc ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal pwc le retour. Évalué à 5.
Il y a avait deux modules pwc et pwcx. L'un des deux n'etait pas libre. Le développeur a jeté l'éponge il y a un an environ. Depuis, ca vient ca va.
[^] # Re: Vraiment compatible avec Ion ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal conkeror: une extension Mozilla pour les alergiques de la souris. Évalué à 2.
> difficilement d'ailleurs.
J'ai essayé aussi mais ca ne me convenait pas. Depuis je suis sous pwm, simple, léger, controlable au clavier mais plus souple à mon avis.
[^] # Re: onglets
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.13. Évalué à 3.
peckwm, c'est un dérivé de pwm.
pwm, c'est minimaliste, un peu comme ion. Pas d'icone, pas de barre de menu... Des fenêtres que l'on peut mettre en onglet, c'est tout.
Mais il est très facile à configurer. Et pour les lancements rapide d'application, je lance "apwal" via un controle clavier. Très bien ce petit apwal.
[^] # Re: onglets
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.13. Évalué à 1.
[^] # Re: vnc2swf
Posté par Sytoka Modon (site web personnel) . En réponse au journal Formation utilisateur Linux : Alternative a Flash ?. Évalué à 2.
L'avantage et ou l'inconvénient, c'est que c'est du natif XWindow.
# LaTeX ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Formation utilisateur Linux : Alternative a Flash ?. Évalué à 2.
Idée : pdflatex + beamer te génère du pdf, tu places tout ca sur un site web apache ensuite.
Pour info, beamer est un super paquetage LaTeX pour faire des présentations. Il est compatible ps et pdf, ce que ne l'était pas prosper.
Le premier jeu de transparent à mettre au point peu rebuter. Ensuite, ca va presque trop vite à faire...
[^] # Re: Sacré langage!
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Journées Perl 2005. Évalué à 1.
Sinon, il faut un peu de temps pour rentrer dans AxKit mais après c'est formidable. Il est très facile de faire des formulaires. Je me suis fait par exemple ma propre extension qui charge le code perl d'une page html si un fichier du même nom existe (dans une arborescence parallèle (faut pas être fou)). Ca parait bête mais la complète dissociation code Perl / code HTML permet de ré-utiliser le code source bien plus facilement.
Il y a un peu trop de variables globales à mon humble avis dans AxKit et c'est parfois pas assez objet. Par exemple, le coup des formulaires, l'idéal aurait été de définir une classe comme nom du formulaire et de simplement connecter les méthodes de la classe au champ du formulaire... Je vais peut être le faire, ca me simplifierai grandement mon code.
[^] # Re: Sacré langage!
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Journées Perl 2005. Évalué à 2.
http://www.axkit.org/
C'est un environnement XML en Perl "à la cocoon" (Java). Tu peux mélanger le code Perl et le xhtml mais en général, il y a une complète séparation des deux. Même avec du code Perl embarqué, le xml reste valide !
[^] # Re: ACL
Posté par Sytoka Modon (site web personnel) . En réponse au journal Les droits sous Longhorn : un plagiat d'Unix ?. Évalué à 2.
Je suis d'accord avec un un post ci-dessus. Au niveau des droits, il manque quelques reglages ici ou là. Par exemple, le nombre de groupe par personne est limité (par nfs notament) et il n'est pas possible de faire de l'imbrication de groupe. Dans la plupart des cas, une meilheure gestion des groupes suffirait.