Sytoka Modon a écrit 4544 commentaires

La voie prise par VirtualGL est aussi intéressante. En gros, on inverse X, le client redevient le serveur et le serveur le client ;-)

Je résume ce que j'en ai compris. On se place dans la configuration d'un poste client (serveur X) et d'une station de travail d'accès distant (serveur donc client X). L'affichage normal passe toujours par X sauf pour une fenêtre OpenGL. La résolution OpenGL se fait en local sur la carte graphique, on récupère en sortie de carte l'image calculé qu'on met à disposition du client via un serveur de type stream (Image, VNC...). Avec ce système, le client est bien client pour les fenêtres OpenGL et le serveur reste serveur pour la partie OpenGL !

Ceci marchait mal avant car récupérer l'image en sortie de carte graphique était soit impossible soit très lent. Avec les dernières cartes, il parait que c'est maintenant chose bien plus facile et performant.

Rien n'empêche de faire cela sur une et une seule machine. Imaginer deux machines est parfois plus simple pour les explications.

Bref, avec la voie VirtualGL, l'application envoi sur la bonne carte graphique selon la fenêtre, sinon on utilise le système classique. On pourrait très bien imaginer cela pour les machines a deux processeurs graphiques.

Un des problèmes, c'est qu'on demande de plus en plus à la << session graphique >>. Donc on a des serveurs type dbus qui tournent, tournent... du gconf... Bref, j'appelle cela un comportement de type variable globale par toujours très clair.

Les applications sont de plus en plus basé la dessus. Sans le gnome-settings-daemon, mon iceweasel (firefox) a un mal fou à ouvrir la boite de dialogue des fichiers, bien que je tourne sous wmii !

La notion de changement de groupe primaire (newgroup) est devenu quasiment inutilisable car les utilisateurs ne savent pas comment faire avec leur explorateur de fichier graphique. Du coup, on fait des hack à coup des sgid sur les dossiers partagés.

Bref, on perds cette notion de processus père fils se transmettant des variables d'environnements. Une architecture simple et robuste qui était capable de faire des trucs sympa mais simplement comme l'agent ssh (deux variables d'environnement).

Je trouve excellent le nom choisi par GNU.

Je n'ai jamais utilisé SCCS, mais je sais qu'il y a au moins un chercheur de l'INRIA qui ne jure que par lui !

Pour avoir vu un joli troll GPL/BSD dans un autre fil, je trouve ce projet plus intéressant et plus utile que le projet OpenCVS (BSD) dont l'objectif est de réimplanter un serveur CVS alors qu'il en existe un, certes vieillot, mais qui est suffisant pour faire une migration.

On peut aussi ajouter ikiwiki que j'utilise personnellement et qui marche très bien.

> un outil BSD donne est bien souvent de meilleure qualite que son equivalent GPL.

Tu peux développer s'il te plaît car exprimé ainsi, cela se rapproche plus de la phrase gratuite.

C'est dommage, cela manque à ta culture ;-)

Keith Packard s'est déjà planté. Après un gros travail pour optimiser le traffic réseau de X, il en est arrivé à la conclusion qu'il ne pourrait pas mieux que la compression gzip faite par ssh (ssh -CX) et donc que cela ne vallait pas le coup... Peu de temps après sors NX par no-machine, le truc génial qui rapproche X de RDP en terme d'utilisabilité sur des réseaux lents !

Je me souviens avoir entendus parlé de Berlin et de Y et puis de ne plus les entendre...

Je me souviens du framebuffer et de GdK sur framebuffer et on allait voir ce qu'on allait voir.

Je me souviens qu'au début, on disais Spice c'est génial, c'est ceci, c'est cela. Qui utilise vraiment spice ? J'ai cru voir que spice marchait en 2D et que la 3D est dans la roadmap. Ne crois au roadmap que ceux qui veulent bien y croire.

Bref, moi je serais super intéressé que NX soit intégré dans X et que son utilisation via ssh soit complètement transparente. Au moins, NX, ça marche et en plus depuis déjà des années !

Il y a aussi le couple VirtualGL et TurboVNC qui ont une approche intéressante de la 3D distante. A mettre aussi dans X et dans ssh ;-)

Au contraire, on voit encore ici la grande force de la GPL dont l'objectif est de ne pas enfermer l'utilisateur. La stratégie Apple de verrouiller via un magasin unique est inacceptable, du coup, Apple ne bénéficie pas des logiciels libres développés dans cet esprit.

Si le libre est capable de faire des bons logiciels, Apple perds car les personnes achèteront des portables de marque plus ouverte et le monde y aura gagné en ouverture.

Un des objectifs de la GPL est d'empêcher l'enfermement des utilisateurs et le détournement des bénéfices à un monopole.

Au contraire, je trouve cette licence génial.

Avec une licence BSD, les développeurs amont auraient encore pleuré qu'Apple se fasse plein de tune sur leur dos sans rien contribuer en retour ;-)

Je suis intéressé par des vrais concurrent à ssh -X qui marche.

Ensuite, j'ai pris l'exemple du TOP 500 pour marquer les esprits. Il est clair que souvent seule la frontale a X mais on peux lancer des sessions batch interactive sur certains clusters...

L'esprit de la réponse était de dire que le noyau linux est le même sur ta petite machine que sur celle du TOP500, aujourd'hui c'est pareil pour X. Toi tu ne vois que ton nombril et ton petit gadget. Moi, je trouve génial que ces morceaux de code soit aussi souple pour marcher sur des configurations aussi large. Le petit bout de code que je développe sur mon netbook, je peux le balancer tel quel sur notre cluster, c'est y pas beau ? Idem pour l'IHM de post-traitement.

Personnellement, je préfère que les efforts soient mis sur une amélioration du code mais rester dans cette optique d'un code qui va de la petite machine à la grosse. Le risque que la couche graphique soit incompatible est trop grande et tu auras de nouveau gagné une dispersion des efforts et un vol en éclat de l'unité.

Qui fait tourner sur son PC des applications développées pour Androïd aujourd'hui ?

J'avoue que la macmania sur les "stores" me laisse d'un grand froid. Je suis bien rechauffé lorsque je vois les efforts de debian pour que la future squeeze marche sur toutes ces plate-formes avec le même code générique de départ.

Bref, je ne suis pas contre l'évolution, mais je ne suis pas fanatique de la conception aujourd'hui de système ne prenant pas en compte les aspects multi-tache, multi-utilisateur et réseau.

Faire des weberies de type web2, c'est en un certain sens traiter du problème réseau... Je ne sais pas si le web2 est mieux ou moins bien que X ? Bref, on verra ce que l'avenir nous prépare...

L'avantage de X est que cela tourne sur tous les vrai UNIX. Tu fais un ssh -X sur une autre machine et la fenêtre s'ouvre sur ton poste sans avoir rien d'autre à faire. C'est tout simplement génial. Pas besoin d'ouvrir un bureau distant et de ce coltiner tout ce qui va avec (et tout le train train de la pensée globale).

L'avantage de X est que si tu gères ton poste ou un parc de 150 machines, tout marche pareil et tout est accessible de la même manière...

L'avantage de X, c'est que tu petit poste de travail a 200E à la machine de calcul du TOP500, c'est pareil.

Essayes de faire de l'affichage distant d'application native sur Mac ;-)

Essayes d'administrer un poste XP en RDP pendant que quelqu'un travaille dessus...

La grande force de X, c'est que c'est le même système sur une toute petite machine et une très grosse. Cette uniformité est une chance pour le libre qui assure que cela marche partout le plus facilement possible. Remettre cela en cause, c'est la porte ouverte à la fermeture généralisée via des AppStore ou les choses marcheront sur les machines personnelles et plus sur les machines du boulot !

Ceci dis, si Wayland est multi-utilisateur et compatible avec le protocole réseau X, pourquoi pas.

Ma belle mère en a un suite à mes conseils pour plusieurs raisons. Elle n'avait jamais fait d'ordinateur, ne se sentait pas à l'aise du tout avec cela et je ne voulais absolument pas avoir à faire le support technique à distance.

Au final, après un an d'utilisation, a 78 ans passé, elle en est très contente. C'est exactement ce qui lui fallait.

Ceci-dis, je te rassure, intellectuellement, elle a toute sa tête ;-)

Je suis d'accord mais il ne faut pas dire non plus que les français sont contre un parlement plus démocratique car ils ont dis non à un referendum.

C'est comme pour linux, le traité aurait été découpé en patch plus petit, à la fin, on aurait eu un truc peut être mieux ;-) A noter que le patch pour un dom0 sous Xen qui n'était pas passé car trop gros à changer de stratégie et est en passe de passer au fil de l'eau découpé en petit morceau beaucoup plus acceptable.

Les suisses votent souvent, je ne vois pas pourquoi on nous demande si peu notre avis ;-)

Je suis sur que si on pose une question claire au français du style : Acceptez vous de renforcer le pouvoir du parlement Européen pour une Europe plus démocratique, les français seront pour !

A question tordues, mauvais débat. Les français ont eu raison de refuser un mélange des genres.

Je suis a 3 aussi car je trouve que c'est le meilleur compromis entre la lisibilité et ne pas trop prendre en largeur.

J'ai codé avec 2 aussi mais je trouve que c'est moins lisible.

Moi j'ai ça sur mon navigateur... J'avoue ne pas avoir été plus loin.


Erreur d'analyse XML : mal formé
Emplacement : http://www.microsoftpdc.com/2009/P09-20
Numéro de ligne 135, Colonne 61 :

A vrai dire, les journaux de Carl se retrouve sur tous les planets ou Carl publie son blog avec un peu de retard car contrairement aux planets, ici ce n'est pas automatique.

Du coup, pour moi, ce sont des journaux que j'ai déjà lu.

Je ne sais pas s'il existe des agrégateurs de commentaires comme il y a des agrégateurs de blog (planet). Enfin si, les serveurs de newsgroup interconnectés...

Bref, merci Carl de communiquer sur le sujet en langue française car tout le monde n'est pas comme moi accro de debian pour aller tous les planets sur debian et faire le trie.

A noter en ce moment la série de Raphael Hertzog sur la philosophie de l'empaquetage selon debian, un peu comme ceux de Carl mais axés uniquement sur les .deb et dpkg

http://raphaelhertzog.com/

C'est technique et c'est à suivre si on souhaite comprendre le boulot que représente la construction d'une distribution aussi complexe que debian.

Ils ont beaucoup bossé !

C'est pas un portage réalisé en trois mois. Ca fait longtemps qu'il a démarré, c'est donc un aboutissement.

A noter pour ceux qui ne le savent pas encore que debian contribue énormément à l'aspect multi-plateforme des logiciels plus qu'au développement amont. On ne peux pas tout faire. Ces multiples architectures permettent de ne pas s'enfermer dans la seule plateforme intel x86 et apporte énormément de robustesse aux logiciels. Tout cela prends du temps et explique en partie pourquoi les versions des logiciels sont souvent un peu en retard.

Malheureusement, il y a très peu de gros chantier de génie civil sans décès. Heureusement, les chiffres sont à la baisse pour des ouvrages plus important qu'avant. Par exemple, le premier tunnel avait été une hécatombe (177 victimes).

On attend toujours le début du percement du tunnel entre la France et l'Italie qui devrait faire à peu près la même longueur et qui rapprocherait énormément Lyon de Turin.

> C'est la première fois (à ma connaissance du moins) que "l'Europe spatiale" fait quelque
> chose, participe à un projet, qui ne soit pas purement mercantile.

C'est complètement faux. L'Europe participe à énormément d'expériences scientifiques dans l'espace dont des satellites concernant l'astronomie.

A ma connaissance, l'astronomie et l'étude des galaxies lointaines ne se monnayent pas facilement à la bourse de Paris !

Je me suis posé la même question que toi mais un courriel partis ne signifie par un courriel dans sa boite. Le protocole SMTP ne garantis rien sur la réception par la personne. Par exemple, sur mon relais SMTP, un trop gros pourriel va directement dans /dev/null sans rien dire...

Donc, en passant par le FAI et sa boite au lettre, HADOPI est assuré que l'internaute a reçu le courriel. Cela ne veut pas dire qu'il l'aura lu car je ne lis pas la boite à courriel de mon FAI mais cela, HADOPI n'en a que faire.

Je ne dis pas le contraire mais mon hébergeur ne fait que des pages statiques.

De plus, pour mes chercheurs, je ne leur offre aussi que des pages statiques pour leurs pages perso, j'ai pas envie de "reviewer" leur code php, perl, python... et de passer mon temps à boucher les trous de sécurité.

C'est à peu de chose la même méthode que moi sauf que je traite en local avec jigl et j'upload ensuite car je veux un site statique sans php.

Voila mon script


DESTDIR=$HOME/monsite/gallery/sousdossier

mkdir -p $DESTDIR

# refaire gallery.dat en partant des commentaires des photos.
jigl -cg -uec

# Force regenerate slide
jigl -fs

cat <> gallery.dat
INDEX-TITLE ---- Mariage de machin truc
INDEX-HEADER ---- Machin et Bidule se sont mariés le 1 octobre...
END

# pas mal d'image merde via jigl donc je force ?
for f in *.jpg
do
convert -geometry x400 $f slides/slide_$f
done

# Créer la gallery
jigl -uec -sy 400 \
-gb -gbs 'Accueil' -gburl 'http://www.monsite.fr/' \
-wd $DESTDIR \
--noslide-kbsize \
--noslide-xysize \
--nogenerate-info \
--theme monthemeamoi

x-www-browser $DESTDIR/index.html

Personnellement, j'utilise jigl qui est dans debian depuis un certain temps. C'est aussi un générateur d'album statique qui pour ce que j'en fait marche bien.

http://xome.net/projects/jigl/

J'utlise jbrout pour ajouter des commentaires aux photos et gqview pour les tourner dans le non sens, éliminer les mauvaises et refaire la miniature s'il le faut. Parfois un petit coup de gimp comme tout le monde mais le moins possible. jigl récupère tout cela pour remplir le commentaire de chaque photo.

Bref, c'est une chaîne assez manuelle ou chaque logiciel s'occupe d'une chose...

Ce serait intéressant d'avoir une comparaison entre ces générateurs. Si quelqu'un a une URL ?

A noter qu'il vaut mieux ajouter à la fin par défaut donc en général faire

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$NEW_PATH