Linux? - Page 145

Zerosquare (./4320) :
Si c'est temporaire, pourquoi le stocker explicitement sur un média qui est la plupart du temps persistant, au lieu d'utiliser un mécanisme prévu pour ?

Parce que les fichiers temporaires ne rentreraient pas dans la RAM ?
Parce que ca permet de faire communiquer des applications pas conçus pour ?
Parce qu'en cas de crash au milieu du traitement tu peux récupérer tes données temporaires et éviter de tout recommencer ?

auto ((Tu ne réponds pas à pourquoi ce n'est pas propre))[];

Quand tu fais du traitement video t'as parfois besoin de fichiers temporaires qui font des dizaines de Go.
Du coup, sachant que le /tmp n'est plus un bon endroit sur la plupart des distribs ajd pour ca, les applis ont tendance a coller ces fichiers temporaires dans le $HOME/.appli .
Ca marche (enfin tant que le $HOME n'est pas deporte), mais c'est un peu aberrant comme situation quand meme.

Zerosquare (./4320) :
flanker > ça sert à quoi pour kerberos ?

Le client kerberos crée un fichier temporaire quand tu fais un kinit, nommé de façon déterministe (en fonction de ton login essentiellement).
Ensuite, chaque application qui a besoin de s'authentifier va lire le fichier en question (en gros un mot de passe temporaire).

PpHd (./4322) :
Parce que les fichiers temporaires ne rentreraient pas dans la RAM ?

Ça revient à réinventer le swapping.

PpHd (./4322) :
Parce que ca permet de faire communiquer des applications pas conçus pour ?

OK, mais ça reste un hack

PpHd (./4322) :
Parce qu'en cas de crash au milieu du traitement tu peux récupérer tes données temporaires et éviter de tout recommencer ?

Admettons.

PpHd (./4322) :
auto ((Tu ne réponds pas à pourquoi ce n'est pas propre))[];

Parce que dans la plupart des cas, il y a moyen de faire ça plus proprement avec d'autres mécanismes plus adaptés.

Zerosquare (./4324) :

PpHd (./4322) :
Parce que les fichiers temporaires ne rentreraient pas dans la RAM ?

Ça revient à réinventer le swapping.

Sauf lorsque tu traites des fichiers >4Gio sur une machine 32 bits. Là, aucun swapping ne pourra t-aider

spectras (./4322) :
Quand tu fais du traitement video t'as parfois besoin de fichiers temporaires qui font des dizaines de Go.
Du coup, sachant que le /tmp n'est plus un bon endroit sur la plupart des distribs ajd pour ca, les applis ont tendance a coller ces fichiers temporaires dans le $HOME/.appli .
Ca marche (enfin tant que le $HOME n'est pas deporte), mais c'est un peu aberrant comme situation quand meme.

Oué c'est pas très fun. D'un autre coté, il vaut mieux un endroit plus sûr et persistant que /tmp lorsque tu traites des dizaines de Go de donnée.
(et $HOME/.cache ou plutôt $XDG_CACHE_HOME est conçu pour cf. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html )

PAE

Zerosquare (./4327) :
PAE

PAE ne résoud absolument pas le problème. C'est un problème d'espace virtuel pas réel

PpHd (./4322) :
Parce qu'en cas de crash au milieu du traitement tu peux récupérer tes données temporaires et éviter de tout recommencer ?

Autant les mettre dans $XDG_CACHE_HOME, non ?

(enfin, d'après Kevin, ce standard freedesktop ne vaut rien, tu ne devrais pas t'y fier)

Zerosquare (./4327) :
PAE

PAE permet à plusieurs processus d'utiliser plus que 4 Go, mais un seul processus reste limité à 4 Go, me semble-t-il.

flanker (./4329) :
Autant les mettre dans $XDG_CACHE_HOME, non ?

Oui

(enfin, d'après Kevin, ce standard freedesktop ne vaut rien, tu ne devrais pas t'y fier)

Parce que KDE ne le respecte pas entièrement. Mais ne t’inquiètes pas. Le jour où KDE le respectera, Kevin dira que ce standard est à appliquer absolument

C'est moi ou t'es en train de troller, PpHd ?

Il pleut dehors

Exact pour PAE, j'ai mélangé
Mais en 2013, la majorité des machines sont en 64 bits, surtout chez ceux qui ont besoin de plus de 4 Go par processus

C'est vrai, toutes les vraies machines le sont.

spectras (./4322) :
Quand tu fais du traitement video t'as parfois besoin de fichiers temporaires qui font des dizaines de Go.
Du coup, sachant que le /tmp n'est plus un bon endroit sur la plupart des distribs ajd pour ca, les applis ont tendance a coller ces fichiers temporaires dans le $HOME/.appli .
Ca marche (enfin tant que le $HOME n'est pas deporte), mais c'est un peu aberrant comme situation quand meme.

Ben c'est simple, sur une installation Unix classique / est relativement petit (genre 200 a 500Mo), et /tmp est dedans

Bref.

Sinon tmpfs justement limite la taille contrairement a ramfs

Zerosquare (./4324) :

PpHd (./4322) :
Parce que les fichiers temporaires ne rentreraient pas dans la RAM ?

Ça revient à réinventer le swapping.

Un logiciel qui utilise des fichiers temporaires avec les APIs prévues pour les fichiers a tendance à être beaucoup plus rapide en pratique qu'un logiciel qui passe son temps à swapper.

PpHd (./4326) :

spectras (./4322) :
Quand tu fais du traitement video t'as parfois besoin de fichiers temporaires qui font des dizaines de Go.
Du coup, sachant que le /tmp n'est plus un bon endroit sur la plupart des distribs ajd pour ca, les applis ont tendance a coller ces fichiers temporaires dans le $HOME/.appli .
Ca marche (enfin tant que le $HOME n'est pas deporte), mais c'est un peu aberrant comme situation quand meme.

Oué c'est pas très fun. D'un autre coté, il vaut mieux un endroit plus sûr et persistant que /tmp lorsque tu traites des dizaines de Go de donnée.

La recommandation officielle de Fedora est d'utiliser /var/tmp pour ça.

(et $HOME/.cache ou plutôt $XDG_CACHE_HOME est conçu pour cf. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html )

Une fois de plus: cache ≠ fichier temporaire!

PpHd (./4332) :
Il pleut dehors

Pas ici.

Kevin Kofler (./4336) :
La recommandation officielle de Fedora est d'utilisé /var/tmp pour ça.

/var/tmp est bien souvent dans / qui est bien souvent une partition de 10-20 Gio, ce qui fait que c'est insuffisant pour traiter des disaines de Gio,
surtout comparé à un /home de Tio!

Kevin Kofler (./4336) :
Une fois de plus: cache ≠ fichier temporaire!

==>

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

Hmmmm, tout ça dépend de beaucoup de paramètres... d'ailleurs ce n'est pas pour rien si on a plusieurs localisations temporaires pour Windows... il y a des éléments qui n'ont rien à faire dans le home directory, et d'autres qui n'ont rien à faire dans un dossier général au système.
En outre, les home directories (que ça soit sous Windows ou Linux) montés depuis un nfs ou du smb (depuis un NAS ou autre) ont souvent des quotas qui font qu'il y a un risque de saturation de l'espace de travail (et il y avait dans le passé dans les implémentations de SMB/CIFS qui avaient des répercussions dramatiques pour la cohérence des données d'un volume saturé). J'y ajoute le problème des performances (même dans un environnement au giga, si tout le monde fait circuler 4Go de données vers un SAN pour du travail, ça va vite créer des soucis). Du coup, trouver une règle universelle qui contente tout le monde est mission impossible (ce qui fait le booooonheur des admins système \o/).

Rien n’empêche un admin système de positionner XDG_CACHE_HOME sur un autre répertoire USER mais pas en réseau ( /opt/cache/$USER)

et si pour le /tmpfs on utilise un mmap NUMA sur le cache level 2 d'un cluster SAN monté en NAS? complètement glucose!

PpHd (./4339) :
Rien n’empêche un admin système de positionner XDG_CACHE_HOME sur un autre répertoire USER mais pas en réseau ( /opt/cache/$USER)

Oui, mais dans ce cas, si un utilisateur a besoin de certaines données temporaires (typiquement, son poste meurt et il se reconnecte sur un autre poste), ça perd de son intérêt.
En réalité, il y a au moins trois types de fichiers temporaires concomitants :
- Ceux générés par un service ou un processus système
- Ceux générés par un utilisateur ou une application lancée par un utilisateur, et qui ont tout intérêt (pour des raisons de confort d'utilisation) à être stockées dans l'espace de travail utilisateur, sans se préoccuper du côté local ou distant du point de montage
- Ceux générés par un utilisateur ou une application lancée par un utilisateur, et qui ont tout intérêt (pour des raisons de performances) à être stockées sur le poste physique où s'exécute le processus générateur

Après, on peut toujours jongler avec des liens symboliques à l'intérieur d'un sous dossier de XDG_CACHE_HOME (ce qui est quasi impossible facilement sous Windows, et n'est pas forcément géré par le vfs réseau en cas de montage réseau), mais c'est très très vite l'enfer pour les administrateurs.
Ici, depuis qu'on a des home directories avec des profils distants, on reparamètre le cas échéant certaines applications spécifiques pour que ça aille dans un dossier temporaire en dur sur la machine.

http://nicubunu.blogspot.com/2013/06/photoshop-versus-gimp.html
(Résumé: L'interface utilisateurs de GIMP est désormais nettement meilleure que celle de Photoshop.)

Nil (./4341) :
- Ceux générés par un utilisateur ou une application lancée par un utilisateur, et qui ont tout intérêt (pour des raisons de confort d'utilisation) à être stockées dans l'espace de travail utilisateur, sans se préoccuper du côté local ou distant du point de montage

Dans ce cas, c'est plutôt

XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

Kevin Kofler (./4342) :
http://nicubunu.blogspot.com/2013/06/photoshop-versus-gimp.html
(Résumé: L'interface utilisateurs de GIMP est désormais nettement meilleure que celle de Photoshop.)

In GIMP is more useful: while you can Backspace and delete segments, you can also adjust previously put nodes, so deletion is not needed. Similarly, in GIMP's scissors selection tool, you can adjust previously added nodes, unlike Photoshp's magnetic lasso.

Non, c'est vrai ? Photoshop ne gère pas la modification des points déjà posés du lasso avant de valider la forme ?????
C'est pas possible. C'est quand même super basique comme fonctionnalité

PpHd (./4344) :
Non, c'est vrai ? Photoshop ne gère pas la modification des points déjà posés du lasso avant de valider la forme ?????
C'est pas possible. C'est quand même super basique comme fonctionnalité

Tu peux toujours modifier ta sélection, au moins en y ajoutant des morceaux ou en en enlevant...

Sinon, cette comparaison, en plus de n'être faite que sur un ensemble pour le moins anecdotique de fonctions, est erronée sur certains points :

• Pour avoir la taille en pixels du document, il suffit de cliquer sur le bandeau en bas de la fenêtre (là où est indiqué « Exposure works in 32-bits only » sur sa capture) pour la faire apparaître. La flèche sur la droite de ce bandeau permet de choisir quelles informations on souhaite voir affichées sur ce bandeau. Ha tiens, il semble que c'est justement la taille de l'image que ce bandeau affiche par défaut. L'a-t-il modifié volontairement ?
• Le curseur par défaut n'est pas celui qu'il montre. Je ne sais pas si c'est dû à l'obsolescence de la version de Photoshop qu'il utilise (auquel cas il aurait dû comparer avec une version obsolète de GIMP pour être équitable) ou bien à la configuration qu'il aura involontairement modifiée, ou pas. En tout cas, ça se configure.
• Pour les sélections, on a toutes les informations qu'on veut et on peut faire les transformations qu'on veut. C'est dans un menu, car ça ne se limite pas à arrondir les angles
• Contrairement à ce qui est dit, l'outil de découpe permet de forcer le format d'origine de l'image.
• Je ne sais pas ce qu'il trouve WYSIWYG dans la fenêtre de redimensionnement de l'espace de travail dans GIMP... La miniature est confuse : le rebord autour de l'image, représente-t-il le nouvel espace de travail ou s'agit-il d'un cadre quelconque ? La couleur de fond devrait être modifiée. Il manque des informations importantes. Où se trouve l'ancienne taille ? Bon, elle est toujours dans le titre de la fenêtre, mais ça me semble tout sauf naturel d'aller la chercher à cet endroit et heureusement que le nom du fichier n'est pas trop long, sinon la taille ne serait plus affichée du tout.

Bon tout ça pour dire que cette comparaison est mal faite et il est évident qu'on va préférer un outil qu'on connait à un autre qu'on ne connait pas du tout comme c'est le cas ici.

RHJPP (./4345) :
Je ne sais pas ce qu'il trouve WYSIWYG dans la fenêtre de redimensionnement de l'espace de travail dans GIMP... La miniature est confuse : le rebord autour de l'image, représente-t-il le nouvel espace de travail ou s'agit-il d'un cadre quelconque ? La couleur de fond devrait être modifiée. Il manque des informations importantes. Où se trouve l'ancienne taille ? Bon, elle est toujours dans le titre de la fenêtre, mais ça me semble tout sauf naturel d'aller la chercher à cet endroit et heureusement que le nom du fichier n'est pas trop long, sinon la taille ne serait plus affichée du tout.

C'est sur que balancer péremptoirement qu'une interface est meilleure sur une application aussi complexe, n'est pas une bonne idée, chacun ayant ces préférences et accordera plus d'interet a certains points que d'autre

Mais ce que je retiens, c'est surtout que l'interface de Gimp c'est vraiment améliorée et n'est plus une horreur comme elle l'était il n'y a pas encore si longtemps. Ça doit faire 10 ans que le mode mono-fenêtre était réclamés.

./4342
rien que

GIMP being Free software, released under GPL is vastly superior

ça me donne pas envie de lire la suite

Amusant comment y'en aura toujours pour décréter que merdasse-1.0beta.tar.gz sera toujours mieux que trucgenial-win32-4.2.zip

squalyl (./4347) :
./4342
rien que

GIMP being Free software, released under GPL is vastly superior

ça me donne pas envie de lire la suite

Amusant comment y'en aura toujours pour décréter que merdasse-1.0beta.tar.gz sera toujours mieux que trucgenial-win32-4.2.zip

Heu... Je ne vois pas ce qu'il dit de faux ni de partial si on remet la phrase dans le contexte :

And of course from a licensing point of view, GIMP being Free software, released under GPL is vastly superior

Mais si quelqu'un veut faire une comparaison détaillé des licences de Photoshop et de gimp, je serai ravi de la lire

Ce n'est pas parce qu'il y a potentiellement plus de personnes qui vont regarder sous le capot que ça va en faire un produit de qualité.

Oui, tout à fait. Mais on ne compare pas là la qualité des logiciels, mais la qualité des licences là.