Sytoka Modon a écrit 4565 commentaires

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).

http://en.wikipedia.org/wiki/Remote_Desktop_Protocol
http://en.wikipedia.org/wiki/T.120

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 !).

Et pourquoi RHEL sur les serveurs ? Tous mes serveurs sont sous Debian, mais c'est un exemple.

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.

• 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).

Qui est une syntaxe shell standard !

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).

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…

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.

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…

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.

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 ;-)

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…

Première chose à faire sur une machine GNU/Linux : apt-get --purge remove nscd

J'ai jamais aimé ce truc…

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.

http://enbd.sourceforge.net/

Tout cela date un peu mais reste intéressant à connaître.

Je parlais de faire des QCM de 10 minutes en début de séance de TD

Si on parle d'étudiant, on parle de personne ayant plus de 18 ans (en général). En tant qu'enseignant, je ne suis pas là pour faire garderie. S'ils ne bossent pas, je ne vais pas leur prendre la main pour voir s'ils ont travaillé via un QCM…

Un QCM peut être un très bon outil pour vérifier des apprentissages fondamentaux

En tant qu'enseignant, j'ai fait quelques QCM. Pour moi, c'était une horreur à fabriquer. Je trouve cela pernicieux voire vicieux. Plutôt que de faire un beau sujet construit qui mène à une réflexion d'ensemble, tu passes ton temps a essayer de cacher la réponse bonne et à trouver des réponses qui paraissent bonne mais sont fausses ! Pour le droit ou le code de la route ou…, cela a son utilité mais en sciences pour l'ingénieur, son domaine d'utilisation est faible.

Je suis assez d'accord. J'ai eu pendant des années un serveur Norton (Symantec) sous NT4 avec zéro soucis… Les attaques du moment ne marchait plus sous NT4 !

C'est pas forcément quelque chose de bien et c'est surtout pas à généraliser mais localement, c'est vrai que cela marche pas si mal.

Matworks y arrive bien avec Matlab, idem Ansys… Attention quand même à la 3D mais c'est tout.

Il suffit soit de compiler en statique, soit de mettre toutes les bibliothèques dans l'archive et d'avoir un script de lancement qui configure LD_LIBRARY_PATH et autre…

A savoir, les logiciels propriétaires embarque java, python, mesa… Bref tout pour être le plus tranquille !