j'ai choisi bash-3.0.0 lors de l'installation de bsd 5.3. or, sous ma
home j'ai des fichiers de config de shells, mais pas .bashrc, ni
.bash_profile. le seul fichier faisant reference à bash est
.bash_history ! en revanche, j'ai .cshrc, .shrc... donc, au login, bash
ne peut trouver .bashrc et .bash_profile comme indiqué ds le man.
ds /etc/passwd, le shell pour root est /bin/csh, pour moi, c'est
/usr/local/bin/bash: pourquoi cette discrimination ?
comment faire pour utiliser .bashrc en user comme en root ? changer le
bash de root ds /etc/passwd ne semble pas suffire. un chsh pourrait sans
doute résoudre la chose, mais cela semble un peu alambiqué.
mais ce qui est troublant, c'est que bash ne prévoit pas de mettre en place SES propres fichiers lorsqu'un user décide de l'installer.
Mais il le fait !
Bash met en place ses fichiers _optionnels_ sous une forme parfaitement admise et standard pour un fichier optionnel, à savoir un fichier absent. Bash fait en sorte de ne pas créer de .bashrc parce que, par défaut, l'absence de .bashrc le rend content.
Ça n'empêche pas l'utilisateur de modifier un tel fichier optionnel (par exemple en le créant), s'il en a l'envie et comme il est décrit dans la documentation. C'est le comportement traditionnel de tout un tas d'applications usuelles sous Unix. Bash, sous Linux comme sous FreeBSD, ne fait pas exception.
Apparté : il existe aussi des applications qui ont _besoin_ de fichiers de configuration. Pour celles-là, ces fichiers ne sont pas optionnels. Afin d'aider l'utilisateur, il est en général prévu par ces applications de créer des fichiers de configuration "par défaut" au premier lancement. C'est typiquement ce que fait un Mozilla : il crée le .mozilla (et il le remplit) si ce fichier n'est pas présent au démarrage.
Il s'avère que certains systèmes d'exploitation, dans leur configuration par défaut, considèrent que même si un programme tel que bash serait tout content dans son mode par défaut (sans .bashrc), l'utilisateur serait encore plus heureux s'il avait dès le départ un .bashrc avec une configuration spéciale qui active des fonctionnalités sympathiques. Ces systèmes d'exploitation s'assurent alors que la procédure usuelle de création de compte produit ce .bashrc pour l'utilisateur. C'est un choix qui est dépendant de ce qui est utilisé pour créer un compte ("adduser" ou n'importe quel outil d'administration), pas du bash lui-même. FreeBSD fait ce choix pour ses shells "natifs", ceux qui viennent avec le système de base et qu'on trouve dans /bin (donc sh et csh/tcsh).
--Thomas Pornin
According to Claude <nospam@nospam.fr>:
mais ce qui est troublant, c'est que bash ne prévoit pas de
mettre en place SES propres fichiers lorsqu'un user décide de l'installer.
Mais il le fait !
Bash met en place ses fichiers _optionnels_ sous une forme parfaitement
admise et standard pour un fichier optionnel, à savoir un fichier
absent. Bash fait en sorte de ne pas créer de .bashrc parce que, par
défaut, l'absence de .bashrc le rend content.
Ça n'empêche pas l'utilisateur de modifier un tel fichier optionnel
(par exemple en le créant), s'il en a l'envie et comme il est décrit
dans la documentation. C'est le comportement traditionnel de tout un
tas d'applications usuelles sous Unix. Bash, sous Linux comme sous
FreeBSD, ne fait pas exception.
Apparté : il existe aussi des applications qui ont _besoin_ de
fichiers de configuration. Pour celles-là, ces fichiers ne sont pas
optionnels. Afin d'aider l'utilisateur, il est en général prévu par
ces applications de créer des fichiers de configuration "par défaut"
au premier lancement. C'est typiquement ce que fait un Mozilla : il
crée le .mozilla (et il le remplit) si ce fichier n'est pas présent au
démarrage.
Il s'avère que certains systèmes d'exploitation, dans leur configuration
par défaut, considèrent que même si un programme tel que bash serait
tout content dans son mode par défaut (sans .bashrc), l'utilisateur
serait encore plus heureux s'il avait dès le départ un .bashrc avec une
configuration spéciale qui active des fonctionnalités sympathiques. Ces
systèmes d'exploitation s'assurent alors que la procédure usuelle de
création de compte produit ce .bashrc pour l'utilisateur. C'est un choix
qui est dépendant de ce qui est utilisé pour créer un compte ("adduser"
ou n'importe quel outil d'administration), pas du bash lui-même. FreeBSD
fait ce choix pour ses shells "natifs", ceux qui viennent avec le
système de base et qu'on trouve dans /bin (donc sh et csh/tcsh).
mais ce qui est troublant, c'est que bash ne prévoit pas de mettre en place SES propres fichiers lorsqu'un user décide de l'installer.
Mais il le fait !
Bash met en place ses fichiers _optionnels_ sous une forme parfaitement admise et standard pour un fichier optionnel, à savoir un fichier absent. Bash fait en sorte de ne pas créer de .bashrc parce que, par défaut, l'absence de .bashrc le rend content.
Ça n'empêche pas l'utilisateur de modifier un tel fichier optionnel (par exemple en le créant), s'il en a l'envie et comme il est décrit dans la documentation. C'est le comportement traditionnel de tout un tas d'applications usuelles sous Unix. Bash, sous Linux comme sous FreeBSD, ne fait pas exception.
Apparté : il existe aussi des applications qui ont _besoin_ de fichiers de configuration. Pour celles-là, ces fichiers ne sont pas optionnels. Afin d'aider l'utilisateur, il est en général prévu par ces applications de créer des fichiers de configuration "par défaut" au premier lancement. C'est typiquement ce que fait un Mozilla : il crée le .mozilla (et il le remplit) si ce fichier n'est pas présent au démarrage.
Il s'avère que certains systèmes d'exploitation, dans leur configuration par défaut, considèrent que même si un programme tel que bash serait tout content dans son mode par défaut (sans .bashrc), l'utilisateur serait encore plus heureux s'il avait dès le départ un .bashrc avec une configuration spéciale qui active des fonctionnalités sympathiques. Ces systèmes d'exploitation s'assurent alors que la procédure usuelle de création de compte produit ce .bashrc pour l'utilisateur. C'est un choix qui est dépendant de ce qui est utilisé pour créer un compte ("adduser" ou n'importe quel outil d'administration), pas du bash lui-même. FreeBSD fait ce choix pour ses shells "natifs", ceux qui viennent avec le système de base et qu'on trouve dans /bin (donc sh et csh/tcsh).
--Thomas Pornin
pornin
According to claude :
y'a pas un reader pour bsd ? il faut passer par la couche linux ?
"Acroread" est le logiciel produit par Adobe. Ce n'est pas du logiciel libre ; seules les versions créées par Adobe existent. Adobe ne fabrique pas de binaires pour FreeBSD ; ils en font pour un certain nombre de plateformes, avec des degrés divers de support, mais pas pour FreeBSD. Donc, pour le lancer, il faut une couche d'émulation. Celle qui marche le mieux pour ça, c'est la couche Linux. D'expérience, ça marche bien.
Bon, maintenant, pour visualiser des fichiers PDF, il y a aussi des outils libres qui existent en version native pour FreeBSD ; par exemple, gv et xpdf. Ça marche pas mal aussi, même si je trouve qu'Acrobat Reader 5 est plus rapide à l'affichage.
oui, beaucoup + beaucoup, ça devient important. je vais réfléchir à d'autres environnements de bureau
Moi qui commence à subir les assauts du temps, j'utilise ma configuration que je me suis patiemment optimisée à la main il y a bientôt dix ans : X11 + fvwm(*), avec 4 terminaux (xterm) affichés simultanément et ne se recouvrant pas. Il y a eu quelques améliorations graduelles (par exemple, ce sont maintenant des terminaux _en couleur_) mais pas de changement majeur. Ce n'est pas très flashy, mais c'est ergonomique : je travaille efficacement sous cet environnement(**). Et comme cette config a été prévu, à la base, pour des Sparc 1+ à 25 MHz avec 8 Mo de RAM, je n'ai aucun problème de performances sur le banal PC de mon bureau (Athlon à 1533 MHz, 256 Mo de RAM...).
--Thomas Pornin
(*) Fvwm2 maintenant, mais c'est une pure traduction de ma configuration sous fvwm1, sans changement apparent. Je n'ai fait cette traduction que parce que certains OS boudent fvwm1 et ne proposent pas de package facilement installable.
(**) Attention : l'ergonomie dépend de l'utilisateur. _Je_ suis efficace avec mon environnement spartiate. Je ne prétends pas du tout que ce serait le cas pour tout le monde ! Et inversement, j'ai déjà rencontré quelqu'un qui est très efficace avec le bureau Windows, tout le contraire de mon cas.
According to claude <nospam@nospam.fr>:
y'a pas un reader pour bsd ? il faut passer par la couche linux ?
"Acroread" est le logiciel produit par Adobe. Ce n'est pas du logiciel
libre ; seules les versions créées par Adobe existent. Adobe ne fabrique
pas de binaires pour FreeBSD ; ils en font pour un certain nombre de
plateformes, avec des degrés divers de support, mais pas pour FreeBSD.
Donc, pour le lancer, il faut une couche d'émulation. Celle qui marche
le mieux pour ça, c'est la couche Linux. D'expérience, ça marche bien.
Bon, maintenant, pour visualiser des fichiers PDF, il y a aussi des
outils libres qui existent en version native pour FreeBSD ; par exemple,
gv et xpdf. Ça marche pas mal aussi, même si je trouve qu'Acrobat Reader
5 est plus rapide à l'affichage.
oui, beaucoup + beaucoup, ça devient important. je vais réfléchir à
d'autres environnements de bureau
Moi qui commence à subir les assauts du temps, j'utilise ma
configuration que je me suis patiemment optimisée à la main il y
a bientôt dix ans : X11 + fvwm(*), avec 4 terminaux (xterm) affichés
simultanément et ne se recouvrant pas. Il y a eu quelques améliorations
graduelles (par exemple, ce sont maintenant des terminaux _en couleur_)
mais pas de changement majeur. Ce n'est pas très flashy, mais c'est
ergonomique : je travaille efficacement sous cet environnement(**). Et
comme cette config a été prévu, à la base, pour des Sparc 1+ à 25 MHz
avec 8 Mo de RAM, je n'ai aucun problème de performances sur le banal
PC de mon bureau (Athlon à 1533 MHz, 256 Mo de RAM...).
--Thomas Pornin
(*) Fvwm2 maintenant, mais c'est une pure traduction de ma configuration
sous fvwm1, sans changement apparent. Je n'ai fait cette traduction
que parce que certains OS boudent fvwm1 et ne proposent pas de package
facilement installable.
(**) Attention : l'ergonomie dépend de l'utilisateur. _Je_ suis efficace
avec mon environnement spartiate. Je ne prétends pas du tout que ce
serait le cas pour tout le monde ! Et inversement, j'ai déjà rencontré
quelqu'un qui est très efficace avec le bureau Windows, tout le
contraire de mon cas.
y'a pas un reader pour bsd ? il faut passer par la couche linux ?
"Acroread" est le logiciel produit par Adobe. Ce n'est pas du logiciel libre ; seules les versions créées par Adobe existent. Adobe ne fabrique pas de binaires pour FreeBSD ; ils en font pour un certain nombre de plateformes, avec des degrés divers de support, mais pas pour FreeBSD. Donc, pour le lancer, il faut une couche d'émulation. Celle qui marche le mieux pour ça, c'est la couche Linux. D'expérience, ça marche bien.
Bon, maintenant, pour visualiser des fichiers PDF, il y a aussi des outils libres qui existent en version native pour FreeBSD ; par exemple, gv et xpdf. Ça marche pas mal aussi, même si je trouve qu'Acrobat Reader 5 est plus rapide à l'affichage.
oui, beaucoup + beaucoup, ça devient important. je vais réfléchir à d'autres environnements de bureau
Moi qui commence à subir les assauts du temps, j'utilise ma configuration que je me suis patiemment optimisée à la main il y a bientôt dix ans : X11 + fvwm(*), avec 4 terminaux (xterm) affichés simultanément et ne se recouvrant pas. Il y a eu quelques améliorations graduelles (par exemple, ce sont maintenant des terminaux _en couleur_) mais pas de changement majeur. Ce n'est pas très flashy, mais c'est ergonomique : je travaille efficacement sous cet environnement(**). Et comme cette config a été prévu, à la base, pour des Sparc 1+ à 25 MHz avec 8 Mo de RAM, je n'ai aucun problème de performances sur le banal PC de mon bureau (Athlon à 1533 MHz, 256 Mo de RAM...).
--Thomas Pornin
(*) Fvwm2 maintenant, mais c'est une pure traduction de ma configuration sous fvwm1, sans changement apparent. Je n'ai fait cette traduction que parce que certains OS boudent fvwm1 et ne proposent pas de package facilement installable.
(**) Attention : l'ergonomie dépend de l'utilisateur. _Je_ suis efficace avec mon environnement spartiate. Je ne prétends pas du tout que ce serait le cas pour tout le monde ! Et inversement, j'ai déjà rencontré quelqu'un qui est très efficace avec le bureau Windows, tout le contraire de mon cas.
Claude
"Thomas Pornin" a écrit dans le message de news:csqgab$2vkk$
According to Claude :
mais ce qui est troublant, c'est que bash ne prévoit pas de mettre en place SES propres fichiers lorsqu'un user décide de l'installer.
Mais il le fait !
Bash met en place ses fichiers _optionnels_ sous une forme parfaitement admise et standard pour un fichier optionnel, à savoir un fichier absent.
"mettre en place un fichier absent...." alors là, je note cet aphorisme! je soupçonne un mathematicien derriere ces lignes! ça me rappelle en effet le "vrai par vacuité" distillé ds les cours de maths.
Bash fait en sorte de ne pas créer de .bashrc parce que, par défaut, l'absence de .bashrc le rend content.
introduire de la libido ds unix n'est pas non plus très commun ;) je verrai désormais unix sous un autre oeil !
"Thomas Pornin" <pornin@nerim.net> a écrit dans le message de
news:csqgab$2vkk$1@biggoron.nerim.net...
According to Claude <nospam@nospam.fr>:
mais ce qui est troublant, c'est que bash ne prévoit pas de
mettre en place SES propres fichiers lorsqu'un user décide de
l'installer.
Mais il le fait !
Bash met en place ses fichiers _optionnels_ sous une forme parfaitement
admise et standard pour un fichier optionnel, à savoir un fichier
absent.
"mettre en place un fichier absent...." alors là, je note cet aphorisme!
je soupçonne un mathematicien derriere ces lignes! ça me rappelle en effet
le "vrai par vacuité" distillé ds les cours de maths.
Bash fait en sorte de ne pas créer de .bashrc parce que, par
défaut, l'absence de .bashrc le rend content.
introduire de la libido ds unix n'est pas non plus très commun ;) je verrai
désormais unix sous un autre oeil !
"Thomas Pornin" a écrit dans le message de news:csqgab$2vkk$
According to Claude :
mais ce qui est troublant, c'est que bash ne prévoit pas de mettre en place SES propres fichiers lorsqu'un user décide de l'installer.
Mais il le fait !
Bash met en place ses fichiers _optionnels_ sous une forme parfaitement admise et standard pour un fichier optionnel, à savoir un fichier absent.
"mettre en place un fichier absent...." alors là, je note cet aphorisme! je soupçonne un mathematicien derriere ces lignes! ça me rappelle en effet le "vrai par vacuité" distillé ds les cours de maths.
Bash fait en sorte de ne pas créer de .bashrc parce que, par défaut, l'absence de .bashrc le rend content.
introduire de la libido ds unix n'est pas non plus très commun ;) je verrai désormais unix sous un autre oeil !
Francois Tigeot
Xavier wrote:
Francois Tigeot wrote:
Ey le support POP3 il est où,la dedans ? Déja qu'il faut faire des trucs sales pour avoir APOP dans courier ...
Ben je ne fais que de l'imap avec.
Il m'arrive de faire du pop3, mais je le mets à part sur un serveur teapop.
-- Francois Tigeot
Xavier wrote:
Francois Tigeot <ftigeot@nospam.free.fr> wrote:
Ey le support POP3 il est où,la dedans ? Déja qu'il faut faire des trucs
sales pour avoir APOP dans courier ...
Ben je ne fais que de l'imap avec.
Il m'arrive de faire du pop3, mais je le mets à part sur un serveur teapop.
Ey le support POP3 il est où,la dedans ? Déja qu'il faut faire des trucs sales pour avoir APOP dans courier ...
Ben je ne fais que de l'imap avec.
Il m'arrive de faire du pop3, mais je le mets à part sur un serveur teapop.
-- Francois Tigeot
talon
Thomas Pornin wrote:
According to claude :
y'a pas un reader pour bsd ? il faut passer par la couche linux ?
"Acroread" est le logiciel produit par Adobe. Ce n'est pas du logiciel libre ; seules les versions créées par Adobe existent. Adobe ne fabrique pas de binaires pour FreeBSD ; ils en font pour un certain nombre de plateformes, avec des degrés divers de support, mais pas pour FreeBSD. Donc, pour le lancer, il faut une couche d'émulation. Celle qui marche le mieux pour ça, c'est la couche Linux. D'expérience, ça marche bien.
Bon, maintenant, pour visualiser des fichiers PDF, il y a aussi des outils libres qui existent en version native pour FreeBSD ; par exemple, gv et xpdf. Ça marche pas mal aussi, même si je trouve qu'Acrobat Reader 5 est plus rapide à l'affichage.
Oui, ça ce n'est pas trés important. par contre la différence fondamentale entre acroread et les autres, c'est qu'il rend beaucoup mieux les fontes de Type1. Je viens de faire un essai avec gv, xpdf et acroread cote à cote, avec toutes les possibilités pour xpdf (usage de libtype1 ou de freetype2 avec ou sans antialiasing), c'est la nuit et le jour. Seul Adobe a un bon rasterizer pour les fontes de type1. Avec les fontes truetype la librairie freetype se débrouille à peu prés grace au hinting contenu dans les fontes.
--
Michel TALON
Thomas Pornin <pornin@nerim.net> wrote:
According to claude <nospam@nospam.fr>:
y'a pas un reader pour bsd ? il faut passer par la couche linux ?
"Acroread" est le logiciel produit par Adobe. Ce n'est pas du logiciel
libre ; seules les versions créées par Adobe existent. Adobe ne fabrique
pas de binaires pour FreeBSD ; ils en font pour un certain nombre de
plateformes, avec des degrés divers de support, mais pas pour FreeBSD.
Donc, pour le lancer, il faut une couche d'émulation. Celle qui marche
le mieux pour ça, c'est la couche Linux. D'expérience, ça marche bien.
Bon, maintenant, pour visualiser des fichiers PDF, il y a aussi des
outils libres qui existent en version native pour FreeBSD ; par exemple,
gv et xpdf. Ça marche pas mal aussi, même si je trouve qu'Acrobat Reader
5 est plus rapide à l'affichage.
Oui, ça ce n'est pas trés important. par contre la différence fondamentale
entre acroread et les autres, c'est qu'il rend beaucoup mieux les fontes de
Type1. Je viens de faire un essai avec gv, xpdf et acroread cote à cote, avec
toutes les possibilités pour xpdf (usage de libtype1 ou de freetype2 avec ou
sans antialiasing), c'est la nuit et le jour. Seul Adobe a un bon rasterizer
pour les fontes de type1. Avec les fontes truetype la librairie freetype se
débrouille à peu prés grace au hinting contenu dans les fontes.
y'a pas un reader pour bsd ? il faut passer par la couche linux ?
"Acroread" est le logiciel produit par Adobe. Ce n'est pas du logiciel libre ; seules les versions créées par Adobe existent. Adobe ne fabrique pas de binaires pour FreeBSD ; ils en font pour un certain nombre de plateformes, avec des degrés divers de support, mais pas pour FreeBSD. Donc, pour le lancer, il faut une couche d'émulation. Celle qui marche le mieux pour ça, c'est la couche Linux. D'expérience, ça marche bien.
Bon, maintenant, pour visualiser des fichiers PDF, il y a aussi des outils libres qui existent en version native pour FreeBSD ; par exemple, gv et xpdf. Ça marche pas mal aussi, même si je trouve qu'Acrobat Reader 5 est plus rapide à l'affichage.
Oui, ça ce n'est pas trés important. par contre la différence fondamentale entre acroread et les autres, c'est qu'il rend beaucoup mieux les fontes de Type1. Je viens de faire un essai avec gv, xpdf et acroread cote à cote, avec toutes les possibilités pour xpdf (usage de libtype1 ou de freetype2 avec ou sans antialiasing), c'est la nuit et le jour. Seul Adobe a un bon rasterizer pour les fontes de type1. Avec les fontes truetype la librairie freetype se débrouille à peu prés grace au hinting contenu dans les fontes.
--
Michel TALON
claude
F. Senault wrote:
Mmmh... Quand tu dis que le noyeau fait 19Mo, c'est le répertoire /boot/kernel, ou le fichier /boot/kernel/kernel ? Si c'est le répertoire, c'est normal - tu as tous les modules dedans. Le fichier kernel en lui-même sans option de debug fait entre 3 et 4 Mo.
noyau de 2.6 Mo. ouf!
F. Senault wrote:
Mmmh... Quand tu dis que le noyeau fait 19Mo, c'est le répertoire
/boot/kernel, ou le fichier /boot/kernel/kernel ? Si c'est le
répertoire, c'est normal - tu as tous les modules dedans. Le fichier
kernel en lui-même sans option de debug fait entre 3 et 4 Mo.
Mmmh... Quand tu dis que le noyeau fait 19Mo, c'est le répertoire /boot/kernel, ou le fichier /boot/kernel/kernel ? Si c'est le répertoire, c'est normal - tu as tous les modules dedans. Le fichier kernel en lui-même sans option de debug fait entre 3 et 4 Mo.
noyau de 2.6 Mo. ouf!
espie
In article <csqgab$2vkk$, Thomas Pornin wrote:
Apparté : il existe aussi des applications qui ont _besoin_ de fichiers de configuration. Pour celles-là, ces fichiers ne sont pas optionnels. Afin d'aider l'utilisateur, il est en général prévu par ces applications de créer des fichiers de configuration "par défaut" au premier lancement. C'est typiquement ce que fait un Mozilla : il crée le .mozilla (et il le remplit) si ce fichier n'est pas présent au démarrage.
C'est d'ailleurs assez souvent le genre de comportement qui est d'une stupidite sans borne, et laisse le newbie perplexe: il se retrouve devant une floppee de fichiers avec lesquels il n'a rien a faire. Certains virent les fichiers de maniere plus ou moins sauvage (ce qui les laisse avec un environnement un peu casse), d'autres renoncent a jamais a bidouiller leurs configs. Sans oublier les applis qui resauvent les trucs toutes seules et donc qui plantent le jour ou le disque est plein, ou bien ou on a depasse son quota.
Sans compter l'effet extremement deletere de ce genre de choses sur les comptes geres par NFS, avec foultitude de petits fichiers de config.
(sans compter le modele debile windowsesque de mozilla, ou tout est stocke chez l'utilisateur, y compris le cache de fichiers internet et sa taille monstrueuse... comprend pas que ca ait toujours pas ete corrige, alors que c'est le gag qui plombe les installations collectives le plus souvent).
Typiquement, kde a corrige pas mal de problemes lors du passage a la derniere version: son systeme de fichiers de config ne stocke plus QUE les differences par rapport a la config par defaut, ce qui a reduit de, oh 99%, le poids d'une config kde (et c'est un modele qu'il est bon, avec trois etages de fichiers: config par defaut, customisation du systeme, config utilisateur).
Je me suis aussi plongee dans la config de gnome il y a peu, et certains trucs m'ont laisse perplexe: leur control-panel cree des fichiers de config quand on ajoute des entrees de menu, mais ces fichiers de config ont des noms qui ressemblent a des hash crypto, et ne sont PAS transposables d'un utilisateur a l'autre.... La technique classique consistant a avoir un compte utilisateur, le customiser, et sauver dans skel/ l'etat qu'on voudrait garder ne fonctionne pas.
Bref, c'etait bien mieux avant.
Heureusement que Windows a les conneries genre profils itinerants mal configures (par defaut) qui pesent 100 a 300Mo, sinon ca ramerait moins qu'Unix (mutatis mutandi, avec toutes les jolies applications sexy ET super-lourdes auxquelles le neuneu moyen veut avoir acces).
In article <csqgab$2vkk$1@biggoron.nerim.net>,
Thomas Pornin <pornin@nerim.net> wrote:
Apparté : il existe aussi des applications qui ont _besoin_ de
fichiers de configuration. Pour celles-là, ces fichiers ne sont pas
optionnels. Afin d'aider l'utilisateur, il est en général prévu par
ces applications de créer des fichiers de configuration "par défaut"
au premier lancement. C'est typiquement ce que fait un Mozilla : il
crée le .mozilla (et il le remplit) si ce fichier n'est pas présent au
démarrage.
C'est d'ailleurs assez souvent le genre de comportement qui est d'une
stupidite sans borne, et laisse le newbie perplexe: il se retrouve
devant une floppee de fichiers avec lesquels il n'a rien a faire.
Certains virent les fichiers de maniere plus ou moins sauvage (ce qui
les laisse avec un environnement un peu casse), d'autres renoncent a jamais
a bidouiller leurs configs. Sans oublier les applis qui resauvent les trucs
toutes seules et donc qui plantent le jour ou le disque est plein, ou bien
ou on a depasse son quota.
Sans compter l'effet extremement deletere de ce genre de choses sur les
comptes geres par NFS, avec foultitude de petits fichiers de config.
(sans compter le modele debile windowsesque de mozilla, ou tout est
stocke chez l'utilisateur, y compris le cache de fichiers internet et
sa taille monstrueuse... comprend pas que ca ait toujours pas ete corrige,
alors que c'est le gag qui plombe les installations collectives le plus
souvent).
Typiquement, kde a corrige pas mal de problemes lors du passage a
la derniere version: son systeme de fichiers de config ne stocke
plus QUE les differences par rapport a la config par defaut, ce qui a
reduit de, oh 99%, le poids d'une config kde (et c'est un modele qu'il
est bon, avec trois etages de fichiers:
config par defaut, customisation du systeme, config utilisateur).
Je me suis aussi plongee dans la config de gnome il y a peu, et certains
trucs m'ont laisse perplexe: leur control-panel cree des fichiers de config
quand on ajoute des entrees de menu, mais ces fichiers de config ont des
noms qui ressemblent a des hash crypto, et ne sont PAS transposables d'un
utilisateur a l'autre.... La technique classique consistant a avoir un
compte utilisateur, le customiser, et sauver dans skel/ l'etat qu'on
voudrait garder ne fonctionne pas.
Bref, c'etait bien mieux avant.
Heureusement que Windows a les conneries genre profils itinerants mal
configures (par defaut) qui pesent 100 a 300Mo, sinon ca ramerait moins
qu'Unix (mutatis mutandi, avec toutes les jolies applications sexy ET
super-lourdes auxquelles le neuneu moyen veut avoir acces).
Apparté : il existe aussi des applications qui ont _besoin_ de fichiers de configuration. Pour celles-là, ces fichiers ne sont pas optionnels. Afin d'aider l'utilisateur, il est en général prévu par ces applications de créer des fichiers de configuration "par défaut" au premier lancement. C'est typiquement ce que fait un Mozilla : il crée le .mozilla (et il le remplit) si ce fichier n'est pas présent au démarrage.
C'est d'ailleurs assez souvent le genre de comportement qui est d'une stupidite sans borne, et laisse le newbie perplexe: il se retrouve devant une floppee de fichiers avec lesquels il n'a rien a faire. Certains virent les fichiers de maniere plus ou moins sauvage (ce qui les laisse avec un environnement un peu casse), d'autres renoncent a jamais a bidouiller leurs configs. Sans oublier les applis qui resauvent les trucs toutes seules et donc qui plantent le jour ou le disque est plein, ou bien ou on a depasse son quota.
Sans compter l'effet extremement deletere de ce genre de choses sur les comptes geres par NFS, avec foultitude de petits fichiers de config.
(sans compter le modele debile windowsesque de mozilla, ou tout est stocke chez l'utilisateur, y compris le cache de fichiers internet et sa taille monstrueuse... comprend pas que ca ait toujours pas ete corrige, alors que c'est le gag qui plombe les installations collectives le plus souvent).
Typiquement, kde a corrige pas mal de problemes lors du passage a la derniere version: son systeme de fichiers de config ne stocke plus QUE les differences par rapport a la config par defaut, ce qui a reduit de, oh 99%, le poids d'une config kde (et c'est un modele qu'il est bon, avec trois etages de fichiers: config par defaut, customisation du systeme, config utilisateur).
Je me suis aussi plongee dans la config de gnome il y a peu, et certains trucs m'ont laisse perplexe: leur control-panel cree des fichiers de config quand on ajoute des entrees de menu, mais ces fichiers de config ont des noms qui ressemblent a des hash crypto, et ne sont PAS transposables d'un utilisateur a l'autre.... La technique classique consistant a avoir un compte utilisateur, le customiser, et sauver dans skel/ l'etat qu'on voudrait garder ne fonctionne pas.
Bref, c'etait bien mieux avant.
Heureusement que Windows a les conneries genre profils itinerants mal configures (par defaut) qui pesent 100 a 300Mo, sinon ca ramerait moins qu'Unix (mutatis mutandi, avec toutes les jolies applications sexy ET super-lourdes auxquelles le neuneu moyen veut avoir acces).
espie
In article <41f0be9e$0$1042$, Claude wrote:
je n'ai pas bash ds /usr/src/bin. pourtant j'ai:
ls -al /var/db/pkg/ | grep bash drwxr-xr-x 2 root wheel 512 Jan 13 01:07 bash-2.05b.007_2
Dis, tu le fais expres ?
Tu veux pas aller lire un peu la doc, pkg_add(1) en tete, et apres tu reviendras poser tes questions ?
In article <41f0be9e$0$1042$626a14ce@news.free.fr>,
Claude <nospam@nospam.fr> wrote:
je n'ai pas bash ds /usr/src/bin. pourtant j'ai:
ls -al /var/db/pkg/ | grep bash
drwxr-xr-x 2 root wheel 512 Jan 13 01:07 bash-2.05b.007_2
Dis, tu le fais expres ?
Tu veux pas aller lire un peu la doc, pkg_add(1) en tete, et apres tu
reviendras poser tes questions ?
ls -al /var/db/pkg/ | grep bash drwxr-xr-x 2 root wheel 512 Jan 13 01:07 bash-2.05b.007_2
Dis, tu le fais expres ?
Tu veux pas aller lire un peu la doc, pkg_add(1) en tete, et apres tu reviendras poser tes questions ?
espie
In article <1gqp9ud.1ez2rrpefhr28N%, Xavier wrote:
A propos de perl, si c'est une installe neuve, il ne fauit *surtout pas* installer la 5.6.1 : les sectaires gnutiens ont collé une dépendance à la 5.8.x dans leur autoconf/automake de mes deux.
Tiens, je n'avais pas remarque. C'est a quel niveau que ca s'est fait, ca ?
In article <1gqp9ud.1ez2rrpefhr28N%xavier@groumpf.org>,
Xavier <xavier@groumpf.org> wrote:
A propos de perl, si c'est une installe neuve, il ne fauit *surtout pas*
installer la 5.6.1 : les sectaires gnutiens ont collé une dépendance à
la 5.8.x dans leur autoconf/automake de mes deux.
Tiens, je n'avais pas remarque. C'est a quel niveau que ca s'est fait, ca ?
In article <1gqp9ud.1ez2rrpefhr28N%, Xavier wrote:
A propos de perl, si c'est une installe neuve, il ne fauit *surtout pas* installer la 5.6.1 : les sectaires gnutiens ont collé une dépendance à la 5.8.x dans leur autoconf/automake de mes deux.
Tiens, je n'avais pas remarque. C'est a quel niveau que ca s'est fait, ca ?
espie
In article <csqitq$14qe$, Michel Talon wrote:
Oui, ça ce n'est pas trés important. par contre la différence fondamentale entre acroread et les autres, c'est qu'il rend beaucoup mieux les fontes de Type1. Je viens de faire un essai avec gv, xpdf et acroread cote à cote, avec toutes les possibilités pour xpdf (usage de libtype1 ou de freetype2 avec ou sans antialiasing), c'est la nuit et le jour. Seul Adobe a un bon rasterizer pour les fontes de type1. Avec les fontes truetype la librairie freetype se débrouille à peu prés grace au hinting contenu dans les fontes.
Tu es au courant de l'existence d'un *brevet* sur le systeme d'ajustement des pixels des polices truetype, du fait que la bibliotheque freetype inclut du code source permettant d'exploiter ce systeme, mais que celui-ci est generalement desactive dans la plupart des distributions pour eviter tout probleme ?
In article <csqitq$14qe$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Oui, ça ce n'est pas trés important. par contre la différence fondamentale
entre acroread et les autres, c'est qu'il rend beaucoup mieux les fontes de
Type1. Je viens de faire un essai avec gv, xpdf et acroread cote à cote, avec
toutes les possibilités pour xpdf (usage de libtype1 ou de freetype2 avec ou
sans antialiasing), c'est la nuit et le jour. Seul Adobe a un bon rasterizer
pour les fontes de type1. Avec les fontes truetype la librairie freetype se
débrouille à peu prés grace au hinting contenu dans les fontes.
Tu es au courant de l'existence d'un *brevet* sur le systeme d'ajustement
des pixels des polices truetype, du fait que la bibliotheque freetype
inclut du code source permettant d'exploiter ce systeme, mais que celui-ci
est generalement desactive dans la plupart des distributions pour eviter
tout probleme ?
Oui, ça ce n'est pas trés important. par contre la différence fondamentale entre acroread et les autres, c'est qu'il rend beaucoup mieux les fontes de Type1. Je viens de faire un essai avec gv, xpdf et acroread cote à cote, avec toutes les possibilités pour xpdf (usage de libtype1 ou de freetype2 avec ou sans antialiasing), c'est la nuit et le jour. Seul Adobe a un bon rasterizer pour les fontes de type1. Avec les fontes truetype la librairie freetype se débrouille à peu prés grace au hinting contenu dans les fontes.
Tu es au courant de l'existence d'un *brevet* sur le systeme d'ajustement des pixels des polices truetype, du fait que la bibliotheque freetype inclut du code source permettant d'exploiter ce systeme, mais que celui-ci est generalement desactive dans la plupart des distributions pour eviter tout probleme ?
