Quoi de plus simple à imprimer que du DisplayPostScript. Si mes souvenirs sont bons, Mac est passé au PDFDisplay mais c'est bien pareil.
Je ne vois pas ou est le mal de vouloir imprimer via l'affichage. Au contraire, je trouvais xprint plutôt élégant dans la forme (jamais regardé le code). C'était un backend particulier que Mozilla à utiliser pendant quelques temps. D'ailleurs, à l'époque, on en disait le plus grand bien.
Je ne sais pas. Keith Packard après un gros travail avait dis que c'était inutile de tenter d'améliorer la transparence réseau car il n'obtenait rien de mieux qu'un ssh -CX, en gros gzip suffisait et No-Machine est arrivé 3 mois après avec NX qui marche d'enfer, il faut l'avouer.
De ce que j'en ai compris, NX est une bidouille grandiose qui met en place une espèce de cache proxy à chaque extrémité.
En pratique, avec la 3D, cela merde selon les config sans trop savoir pourquoi (il faut dire que par exemple Ansys Workbench est une merde en boite).
Donc, on enrobe X dans NX (ou X2Go, ce sont les mêmes bibliothèques) et là, c'est que du bonheur.
Bref, tout ça c'est très bien mais c'est dommage que NX n'est jamais été intégré dans X depuis le temps alors que No-Machine avait joué la carte du logiciel libre.
Peut être va t'on voir à terme un serveur parallèle vectoriel ? Paraview a un mode distant, Visit a aussi un mode distant. Tu peux même séparer les choses en trois, un serveur de données, un serveur de rendus et l'affichage client. C'est du spécialisé mais sur des gros maillages, cela marche bien.
Il y a aussi l'approche VirtualGL. J'ai pas suivis depuis longtemps celui-ci…
A 3Go la moindre application, je ne déploie pas toutes les applications sur les postes utilisateurs… L'affichage distant est fondamental, sans cela, point de salut en entreprise.
oui, RDP … (un des rares trucs sortis de chez la firme de Redmond qui marche bien, en fait)
En fait, c'est pas du Microsoft à la base ! Ils ont racheté la technologie à CITRIX à l'époque et le tout est dérivé du T120 utilisé en visio-conférence (H323) pour le transfert des données. Contrairement au H239 actuel, le T120 permettait la prise de contrôle à distance type tableau blanc (si le H239 semble plus basique, il est aussi plus fluide pour le canal des données).
C'est vrai mais une appli que tu gardes 6 ans sans toucher, cela veut dire que la migration va être un boulot de fou. Je suis sur que souvent, il n'y a pas de migration.
Je trouve que le rythme de 2 ans que Debian tient en ce moment est pas mal. Ca oblige à se bouger (mais pas trop) et à maintenir les codes. C'est parfois rude mais évite peut être aussi de reporter, reporter, reporter une ancienne application (qui doit être par elle même bien percée !).
Ce qui serait encore un plus, ce serait de donner votre installation / configuration. Ainsi, il serait simple de faire de l'auto-hébergement pour celui qui veut la même chose. Je sais, la liste des logiciels est classique et votre config doit être la même que celle de nous tous…
OCS, c'est bien pour un inventaire sous GN U/Linux mais pas pour les gérer ! On le fait pour Windaube parce que c'est tout moisis mais pour GNU/Linux, cfengine et ses enfants sont bien plus performant.
Afin de dé-installer (et non seulement dé-activer) le partage de fichier sur l'ensemble de postes clients Windows (c'est bête mais s'avère très efficace en terme de sommeil).
Exact, je m'en suis rendu compte après coup, mais je me suis déjà fait avoir avec mais sur un autre shell…
Et ?
Et bien si tu as des scripts que tu sources au démarrage de session (type ssh) afin de mettre en place ton environnement, il faut aussi les sourcer dans le Xsession. C'est prévu me dira tu sauf que via ssh, tu source avec bash, normal tu as bash comme shell et là, tu source avec dash qui ne ne comporte pas pareil.
Sachant que 100% de mes utilisateurs utilisant X ont bash, je trouve normal que le shell initial d'X soit en bash et non en dash.
Je ne suis pas vraiment d'accord. Debian est passé à dash pour l'init principalement. Un utilisateur lambda a toujours bash et non dash comme shell interactif !
Il y a quand même des choses pratiques en bash comme "a=$(( ${b} + 13 ))" sans avoir besoin de lancer des sous processus. Il manque à mon sens les tables de hash car les tableaux sont peu pratique…
Que le système démarre sous dash et non bash est très bien car dash est plus léger, plus réduit et donc plus sur dans le système d'init. Par contre, c'est pénible que "/etc/X11/Xsession" sous en /bin/sh (je le passe en /bin/bash sur mes postes utilisateurs) car cela signifie que la session X11 n'est pas équivalente à une session ssh pour un utilisateur. Je sais que les environnement de bureau moderne s'en foute car ils mettent tout sous dbus (même le hostname) mais je continue à croire que la philosophie des variables d'environnement est bien plus sur, plus simple et largement suffisante dans bien des cas (voir SSH_AGENT).
Un projet comme Debian, ayant de très nombreux contributeurs en Europe, doit-il suivre les lois américaines. Doit-on tous suivre les lois américaines ?
Qu'est ce qui empêche un dépôt européen non soumis au brevet ? Veut on se battre contre les brevets en Europe ou faire la politique de l'autruche d'interdire les brevets mais de les respecter et donc de dire Amen aux lois américaines. Que je sache, il y a des antennes Debian en Europe…
Combien de libs propose de garder une compatibilité parfaite sur une si longue durée ?
Tu demandes 5 ans. Je fais par exemple marcher Nedit basé sur Motif (donc sur X) qui a je ne sais combien d'année… J'ai encore des programmes en Perl/Tk qui marche sans aucune modif depuis 10 ans.
Je sais qu'on est dans une période ou un certain nombre de personne veulent tout virer, tout modifier ! L'API public de Linux change très peu. Les nouvelles fonctions mettent du temps pour être vraiment utilisé et parfois cela a du bien (permet de virer un truc que l'on croyait bien mais en fait non).
Je ne dis pas qu'il faille rester sur le passé. Je pense simplement que les anciennes API ne sont pas toutes moisis et que les garder quelques années est un plus. J'ai pas envie de développer sur un truc qui change tous les deux ans.
Pour Debian, il faut toujours penser aussi à l'aspect multi-architecture. Combien de programme ont des bogues dès que l'on sors du x86 ?
Il faut dire que ca écrit sous /opt… J'ai horreur des paquets propriétaire (debian) car il écrivent sous /opt. Dernier exemple en date, mendeley. Lui c'est même un virus car il rajoute sa clef et son dépot APT direct. Une installation à la main marche tout aussi bien !
Ca a l'air intéressant mais j'ai quand même des doutes que cela marche en pratique sur des cas complexe comme OpenFoam par exemple… (doit avoir 40 variables d'environnement pour que celui-ci marche). Ce truc me rappelle ThinApp de Vmware après une lecture très rapide…
On installe sous /opt/mon_prog/version/… puis on ajoute les chemins qui vont bien dans des variables d'environnement : PATH, PYTHONPATH… Cela peut être fait de manière module et assez proprement avec "modules" (si celui-ci n'était pas basé sur Tcl que je n'aime pas).
Bref, la très grande majorité des programmes peuvent se contenter de la structure historique d'UNIX avec les variables d'environnement. Il faut que les codes explicites mieux sur leur site comment installer ailleurs (en général via --prefix) et les variables d'environnement importante.
Il faut arrêter de trop programmer en variable global avec des services qui ressemble trop à une base de registre. Sous une apparente simplicité, cela complexifie énormément les installations parallèles et l'utilisation parallèle de X version.
Il y a des personnes qui travaillent sur une version de Xen avec des GNU/Linux autour. En gros, un Linux par fonction (reseau…) afin de séparer les choses. Ensuite, les applications sensibles tournent chacune dans un domU autonome. Bref, du conteneur mais au niveau hyperviseur.
Tout cela est très bien car cela fait avancer les choses et met en évidence des problèmes de perf et de protocole mais c'est pas pour demain chez nous ;-)
c'est pas des chercheurs académiques qui n'ont pas à rendre des comptes qui ont été payés pour le faire
Phrase gratuite absolument fausse sur le domaine des sciences de l'ingénieur, branche dans laquelle je travaille. Les chercheurs passent une grosse partie de leur temps dans les évaluations X ou Y et peu d'industriel en ont conscience !
A une époque, il y a eu ENBD, une amélioration de NBD permettant de faire du RAID1 sur le réseau. La problématique de la reconstruction rapide a alors été prise en compte via un driver noyau fr1.
[^] # Re: Une fois de plus
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 4.
Quoi de plus simple à imprimer que du DisplayPostScript. Si mes souvenirs sont bons, Mac est passé au PDFDisplay mais c'est bien pareil.
Je ne vois pas ou est le mal de vouloir imprimer via l'affichage. Au contraire, je trouvais xprint plutôt élégant dans la forme (jamais regardé le code). C'était un backend particulier que Mozilla à utiliser pendant quelques temps. D'ailleurs, à l'époque, on en disait le plus grand bien.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Je ne sais pas. Keith Packard après un gros travail avait dis que c'était inutile de tenter d'améliorer la transparence réseau car il n'obtenait rien de mieux qu'un ssh -CX, en gros gzip suffisait et No-Machine est arrivé 3 mois après avec NX qui marche d'enfer, il faut l'avouer.
De ce que j'en ai compris, NX est une bidouille grandiose qui met en place une espèce de cache proxy à chaque extrémité.
[^] # Re: Une fois de plus
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 5.
Il sont pas tout jeune tous les deux ;-)
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 7.
Dans mon laboratoire, on l'utilise beaucoup.
En pratique, avec la 3D, cela merde selon les config sans trop savoir pourquoi (il faut dire que par exemple Ansys Workbench est une merde en boite).
Donc, on enrobe X dans NX (ou X2Go, ce sont les mêmes bibliothèques) et là, c'est que du bonheur.
Bref, tout ça c'est très bien mais c'est dommage que NX n'est jamais été intégré dans X depuis le temps alors que No-Machine avait joué la carte du logiciel libre.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Peut être va t'on voir à terme un serveur parallèle vectoriel ? Paraview a un mode distant, Visit a aussi un mode distant. Tu peux même séparer les choses en trois, un serveur de données, un serveur de rendus et l'affichage client. C'est du spécialisé mais sur des gros maillages, cela marche bien.
Il y a aussi l'approche VirtualGL. J'ai pas suivis depuis longtemps celui-ci…
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 5.
A 3Go la moindre application, je ne déploie pas toutes les applications sur les postes utilisateurs… L'affichage distant est fondamental, sans cela, point de salut en entreprise.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 9.
En fait, c'est pas du Microsoft à la base ! Ils ont racheté la technologie à CITRIX à l'époque et le tout est dérivé du T120 utilisé en visio-conférence (H323) pour le transfert des données. Contrairement au H239 actuel, le T120 permettait la prise de contrôle à distance type tableau blanc (si le H239 semble plus basique, il est aussi plus fluide pour le canal des données).
http://en.wikipedia.org/wiki/Remote_Desktop_Protocol
http://en.wikipedia.org/wiki/T.120
[^] # Re: un environnement graphique ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal RHEL 7 utilisera GNOME Shell en mode Classique.... Évalué à 0.
C'est vrai mais une appli que tu gardes 6 ans sans toucher, cela veut dire que la migration va être un boulot de fou. Je suis sur que souvent, il n'y a pas de migration.
Je trouve que le rythme de 2 ans que Debian tient en ce moment est pas mal. Ca oblige à se bouger (mais pas trop) et à maintenir les codes. C'est parfois rude mais évite peut être aussi de reporter, reporter, reporter une ancienne application (qui doit être par elle même bien percée !).
[^] # Re: un environnement graphique ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal RHEL 7 utilisera GNOME Shell en mode Classique.... Évalué à 1.
Et pourquoi RHEL sur les serveurs ? Tous mes serveurs sont sous Debian, mais c'est un exemple.
# Méthode
Posté par Sytoka Modon (site web personnel) . En réponse au message Le projet OpenMailBox.org. Évalué à 3.
Ce qui serait encore un plus, ce serait de donner votre installation / configuration. Ainsi, il serait simple de faire de l'auto-hébergement pour celui qui veut la même chose. Je sais, la liste des logiciels est classique et votre config doit être la même que celle de nous tous…
[^] # Re: Agent d'inventaire...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Libérez vos mises à jour avec UpdatEngine. Évalué à 2.
OCS, c'est bien pour un inventaire sous GN U/Linux mais pas pour les gérer ! On le fait pour Windaube parce que c'est tout moisis mais pour GNU/Linux, cfengine et ses enfants sont bien plus performant.
[^] # Re: Agent d'inventaire...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Libérez vos mises à jour avec UpdatEngine. Évalué à 2.
Pour ne pas avoir de serveur sous Windows
Afin de dé-installer (et non seulement dé-activer) le partage de fichier sur l'ensemble de postes clients Windows (c'est bête mais s'avère très efficace en terme de sommeil).
[^] # Re: Oui
Posté par Sytoka Modon (site web personnel) . En réponse au message Différentes version du shell ?. Évalué à 2.
Exact, je m'en suis rendu compte après coup, mais je me suis déjà fait avoir avec mais sur un autre shell…
Et bien si tu as des scripts que tu sources au démarrage de session (type ssh) afin de mettre en place ton environnement, il faut aussi les sourcer dans le Xsession. C'est prévu me dira tu sauf que via ssh, tu source avec bash, normal tu as bash comme shell et là, tu source avec dash qui ne ne comporte pas pareil.
Sachant que 100% de mes utilisateurs utilisant X ont bash, je trouve normal que le shell initial d'X soit en bash et non en dash.
[^] # Re: Oui
Posté par Sytoka Modon (site web personnel) . En réponse au message Différentes version du shell ?. Évalué à 2.
Je ne suis pas vraiment d'accord. Debian est passé à dash pour l'init principalement. Un utilisateur lambda a toujours bash et non dash comme shell interactif !
Il y a quand même des choses pratiques en bash comme "a=$(( ${b} + 13 ))" sans avoir besoin de lancer des sous processus. Il manque à mon sens les tables de hash car les tableaux sont peu pratique…
Que le système démarre sous dash et non bash est très bien car dash est plus léger, plus réduit et donc plus sur dans le système d'init. Par contre, c'est pénible que "/etc/X11/Xsession" sous en /bin/sh (je le passe en /bin/bash sur mes postes utilisateurs) car cela signifie que la session X11 n'est pas équivalente à une session ssh pour un utilisateur. Je sais que les environnement de bureau moderne s'en foute car ils mettent tout sous dbus (même le hostname) mais je continue à croire que la philosophie des variables d'environnement est bien plus sur, plus simple et largement suffisante dans bien des cas (voir SSH_AGENT).
[^] # Re: Intérêt du dépôt ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention au dépôt debian-multimedia.org !. Évalué à 6.
Je crois que c'était effectivement cela.
Un projet comme Debian, ayant de très nombreux contributeurs en Europe, doit-il suivre les lois américaines. Doit-on tous suivre les lois américaines ?
Qu'est ce qui empêche un dépôt européen non soumis au brevet ? Veut on se battre contre les brevets en Europe ou faire la politique de l'autruche d'interdire les brevets mais de les respecter et donc de dire Amen aux lois américaines. Que je sache, il y a des antennes Debian en Europe…
[^] # Re: Intérêt du dépôt ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention au dépôt debian-multimedia.org !. Évalué à 4.
Il y a non-free et à une époque il y avait non-US…
Rien n'empêche d'avoir un dépôt officiel Debian en Europe pour certain paquetage.
[^] # Re: je suis perplexe
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Distribuer sans distributions ?. Évalué à 3.
Tu demandes 5 ans. Je fais par exemple marcher Nedit basé sur Motif (donc sur X) qui a je ne sais combien d'année… J'ai encore des programmes en Perl/Tk qui marche sans aucune modif depuis 10 ans.
Je sais qu'on est dans une période ou un certain nombre de personne veulent tout virer, tout modifier ! L'API public de Linux change très peu. Les nouvelles fonctions mettent du temps pour être vraiment utilisé et parfois cela a du bien (permet de virer un truc que l'on croyait bien mais en fait non).
Je ne dis pas qu'il faille rester sur le passé. Je pense simplement que les anciennes API ne sont pas toutes moisis et que les garder quelques années est un plus. J'ai pas envie de développer sur un truc qui change tous les deux ans.
Pour Debian, il faut toujours penser aussi à l'aspect multi-architecture. Combien de programme ont des bogues dès que l'on sors du x86 ?
[^] # Re: make --prefix
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Distribuer sans distributions ?. Évalué à 2.
Il faut dire que ca écrit sous /opt… J'ai horreur des paquets propriétaire (debian) car il écrivent sous /opt. Dernier exemple en date, mendeley. Lui c'est même un virus car il rajoute sa clef et son dépot APT direct. Une installation à la main marche tout aussi bien !
[^] # Re: make --prefix
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Distribuer sans distributions ?. Évalué à 3.
Ca a l'air intéressant mais j'ai quand même des doutes que cela marche en pratique sur des cas complexe comme OpenFoam par exemple… (doit avoir 40 variables d'environnement pour que celui-ci marche). Ce truc me rappelle ThinApp de Vmware après une lecture très rapide…
# make --prefix
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Distribuer sans distributions ?. Évalué à 10.
Comment qu'on fait sur les machines de calcul ?
On installe sous /opt/mon_prog/version/… puis on ajoute les chemins qui vont bien dans des variables d'environnement : PATH, PYTHONPATH… Cela peut être fait de manière module et assez proprement avec "modules" (si celui-ci n'était pas basé sur Tcl que je n'aime pas).
Bref, la très grande majorité des programmes peuvent se contenter de la structure historique d'UNIX avec les variables d'environnement. Il faut que les codes explicites mieux sur leur site comment installer ailleurs (en général via --prefix) et les variables d'environnement importante.
Il faut arrêter de trop programmer en variable global avec des services qui ressemble trop à une base de registre. Sous une apparente simplicité, cela complexifie énormément les installations parallèles et l'utilisation parallèle de X version.
[^] # Re: Et les pistaches ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal [Debian GNU/Hurd] 2013. Évalué à 4.
Il y a des personnes qui travaillent sur une version de Xen avec des GNU/Linux autour. En gros, un Linux par fonction (reseau…) afin de séparer les choses. Ensuite, les applications sensibles tournent chacune dans un domU autonome. Bref, du conteneur mais au niveau hyperviseur.
Tout cela est très bien car cela fait avancer les choses et met en évidence des problèmes de perf et de protocole mais c'est pas pour demain chez nous ;-)
[^] # Re: utilisable en production ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Tuleap 6.0. Évalué à 2.
Rien !
Ce truc fait du cache mais il a (avait) bien trop d'effet secondaire pour moi !
Actuellement, j'ai les comptes sous LDAP avec sssd qui fait le cache local pour si le réseau est en rade. Marche relativement bien…
[^] # Re: utilisable en production ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Tuleap 6.0. Évalué à 2.
Première chose à faire sur une machine GNU/Linux : apt-get --purge remove nscd
J'ai jamais aimé ce truc…
[^] # Re: RAID dans BRTFS
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 2.
Phrase gratuite absolument fausse sur le domaine des sciences de l'ingénieur, branche dans laquelle je travaille. Les chercheurs passent une grosse partie de leur temps dans les évaluations X ou Y et peu d'industriel en ont conscience !
[^] # Re: RAID dans BRTFS
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 2.
A une époque, il y a eu ENBD, une amélioration de NBD permettant de faire du RAID1 sur le réseau. La problématique de la reconstruction rapide a alors été prise en compte via un driver noyau fr1.
http://enbd.sourceforge.net/
Tout cela date un peu mais reste intéressant à connaître.