Sytoka Modon a écrit 4538 commentaires

Il suffit simplement de mettre windows en veillle plutôt que de l'arréter. La première fois, on le fait sans l'option snapshot, de même que les fois où l'on désire installer d'autres logiciels. En temps normal, je ne travaille jamais sur le disque dur local à la machine. Une image en lecture seule est largement suffisante.

Sinon, il est vrai que pour tester certains développements, c'est vachement pratique. Pour le moment, j'y teste personnellement mes scripts .bat d'installation automatique ;-)

Dommage que le port USB ne fonctionne pas encore ;-( J'ai besoin pour le boulot d'un client qui utilise ma webcam !

Désolé mais je n'ai pas vu la version 1.0.6 en zip pour win32. C'était cela le but de ma question.

Il ont cassé les pieds de pleins d'administrateurs le jour ou ils ont arrété le format zip. Pourquoi ne donnent t'ils pas les options de la ligne de commande de leur .exe ?

On pourrait peut être arrêter d'avoir 36 journaux sur le même sujet à chaque fois...

Pourquoi ne pas commenter les journaux précédents pour y apporter du contenu ?

Je parlais des versions originelles de, par exemple, Firefox ;-) Ou trouver Firefox en zip aujourd'hui ? Idem pour les autres logiciels de cette super clef comme OpenOffice.

En gros, la même chose que la FramaKey mais pour un bon vieux disque dur. De préférence en zip et surtout sans installateur graphique ;-(

Je trouve cette initiative super.

En fouillant un peu, on vois qu'il y a une dynamique pour faire des paquets au format zip des composants mozilla ainsi qu'openoffice. Ces paquets se regoupe sous l'appellation Portable.

C'est génial car il n'y a pas besoin d'être administrateur pour essayer/utiliser un logiciel. Pas besoin non plus d'aller bidouiller cette 'foutue' base de registre.

Par ailleurs, pour les administrateurs systèmes, il devient très simple d'installer le logiciel sur tout plein de machines sans intervention humaines.

Question, peux t'on trouver les versions originelles sous format zip ? Si j'ai bien compris, les versions 'Portables' sont orientés pour les clef USB donc pour les disques fragiles.

Pour Firefox, j'ai vue plusieurs fois qu'il fallait prendre la version nightly mais de quel jour ? Idem pour openoffice.

Je trouve que le format zip a beaucoup d'avantage pour windows en plus de ne rien installer. Il est dommage de ne pas en voir plus.

Sinon, l'autre point dommage, c'est que les options des .exe ou des .msi ne sont que très rarement explicitées sur les sites web. Notament les installations silencieuses, les options d'installations possibles ainsi que les mises à jour. Par exemple, on nous demande de parfois supprimer une version précédente mais comment le faire de manière automatique ?

Je dis souvent aux thésards et aux stagiaires qui rédigent leur rapport qu'une image non commentée ne sert à rien.

Je retourne donc ma phrase. Un commentaire vers une image qu'on aurait supprimé est'il compréhensible ?

Bilan : si on veut réellement quelque chose de libre, c'est tout ou c'est rien. Ou alors, la barrière n'est pas entre texte et image mais il faudrait pouvoir rajouter un contenu non libre à la base libre, contenu non libre qui contiendrait à la fois le texte et l'image associés. Un peu comme l'autorise la LGPL qui permet d'associer du contenu libre et non libre via des modules séparés et *séparable*.

Si tu maîtrises le compte root sur les postes clients, nfs n'est pas si mal (root_squash, netgroup...). /A priori/, il est plus performant que samba. Par ailleurs, il ne se perds pas a faire du partage d'impression.

Autre avantage de nfs, pour une machine multi-utlisateurs, il y a un seul point de montage pour toutes les personnes qui accèdent aux mêmes fichiers. Et puis, il s'interface super bien avec un auto mounter comme autofs.

Question : pourquoi mélanger partage de fichier et impression dans le même protocole ?

J'ajouterais que l'écriture de formules mathématiques sous LaTeX est formidable. Le fait de pouvoir créer facilement ses macros commandes aussi.

Au niveau de la création des styles et des packages, il est vrai que ce n'est pas toujours compréhensible. J'avoue avoir, comme certainement pas mal de monde, copier coller des bouts de codes TeX sans trop comprendre les lignes, mais ca marche ;-). Beaucoup de progrès ont été fait de ce coté là mais il reste à en faire.

Quelques trus qui me gènent dans LaTex et qu'il n'est pas évident de corriger :

- impossibilité de mettre un nombre dans le nom d'une commande
- pas de "namespace"

C'est normal, ca provient du monde Ada, langage qui ressemble assez au Pascal dans sa mise en forme.

Je suis d'accord pour dire qu'il y a plus d'ACL sous windows que sous UNIX.

Mais, il n'y a pas d'ACL sur les périphériques sous windows (device). Donc généralement, ca bloque a ce niveau...

Par ailleurs, la base de registres a ses propres règles et ses propres commandes. Quel sont les registres dont les ACL sont à modifier ?

Bref, l'OS pourrait être mieux si les logiciels étaient vraiment bien développés. J'ai très rarement vu un service tourner sous un autre nom que l'utilisateur SYSTEM !

Effectivement, j'avais oublié ce détail important. Le pdf gère en natif le jpeg et le png. C'est l'une des raisons qui me font l'utilisé pour les transparents.

Pour les hyperliens, je suis d'accord avec les post ci-dessus, mais j'ai le souvenir que par défaut et sans rien faire, il y a plus d'hyperliens qui se font tout seul via pdflatex.

En conclusion, je m'arrange pour que mes fichiers compilent avec les deux commandes latex et pdflatex (J'ai un Makefile qui me convertis les figures au format le plus proche). Pour un néophyte comme moi, beamer et pdf n'ont pas encore finit de m'apprendre des choses. En plus beamer gère les thèmes, on peut facilement changer la forme de sa présentation.

Par contre, je vais quand même faire un tour plus sérieux du coté de métapost.

A propos de xfig, il est vrai qu'il est déroutant au début. Notament car un seul clic sur un outil met cet outil par défaut alors que dans les autres logiciel de ce type, il faut faire un double clic. Avec un seul clic, on repasse automatiquement en mode déplacement ce qui n'est pas idiot dans l'absolue. Par contre, une fois qu'on a l'outil xfig en main, on est très producif.

Je ne suis pas un spécialiste ni du postscript, ni du pdf...

Manisfestement, d'aprés la personne qui a fait beamer, il y a des subtilités possibles en postscript qui ne sont pas réalisable en pdf (et inversement ?).

Par contre, la moulinette ps2pdf ne donne pas le même résulat que la moulinette pdflatex à mes souvenirs. Notament, on perds la table des matières.

Pour ce qui est des présentations avec beamer, en compilant avec pdflatex, on fait très rapidement quelque chose de propre, interactif, avec des liens croisés. J'ai vu qu'il est même possible de rajouter du contenu multimédia (non testé). En compilant ta présentation avec LaTeX, tu peux intégrer de bouts de cette présentation dans un autre document qui serait lui papier.

Je crois que les deux formats ne sont pas destinés au même usage final. Mais autant pouvoir les compiler en natif directement, c'est là où il y a le moins de perte. Il est vrai qu'il est dommage que 'xdvi n'évolue plus beaucoup et qu'avec les commandes \special, il doit être possible de ne garder en théorie que LaTeX.

Autre chose, tu ne pourras pas compiler tes commandes pstrick avec pdflatex. Mais comme avec pgf, tu as une grande partie de pstrick, je ne vois pas le problème (il est vrai que je n'ai fait que des choses simples avec pstrick). Je ne suis pas sur qu'encapsuler du postscript dans du pdf soit la même chose que faire du pdf en natif. Y a t'il un spécialiste en ligne ?

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.

http://latex-beamer.sourceforge.net/

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

> Pourquoi pas un qemu ?

La carte graphique n'est pas accélére opengl sous qemu. Ca me parait donc pas intéressant pour Catia.

Quelqu'un sais si la version debian de xorg est compilée avec le support XMX permettant le multiplexage ?

http://www.cs.brown.edu/software/xmx/

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.

> Ça existe déjà, ça s'appelle The Caml Hump

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