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é.
Cette version existe aussi sous linux sans doute, non ? Enfin, KDE reste lourd et encombrant en version lite ou pas, il vaut mieux choisir de te tourner vers des gestionnaire de fenetre tout betes plutot qu'un environnement de bureau complet, par exemple fluxbox ou WindowMaker. Euh ? je vais pas relancer de troll, mais pourquoi WindowMaker est
classé dans les window managers légers ? parce que ce n'est pas un
J'ai pas écris qu'il était léger :-) Je disais que c'était juste un gestionnaire de fenetre.
gestionnaire de bureau et que par conséquent il semble plus léger que kde ou gnome ? Je n'arrive pas à comprendre, WindowMaker est _très_ gourmant en mémoire (et en ressource chez moi depuis quelques jours mais
Il est quand meme plus leger que KDE ou Gnome quoi qu'il arrive, sauf bug, meme s'il est plus lourd que blackbox... N'aurais tu pas un fond d'écran en jpg de 250 Mo ?
-- Nicolas Le Scouarnec
Cette version existe aussi sous linux sans doute, non ? Enfin, KDE
reste lourd et encombrant en version lite ou pas, il vaut mieux
choisir de te tourner vers des gestionnaire de fenetre tout betes
plutot qu'un environnement de bureau complet, par exemple fluxbox ou
WindowMaker.
Euh ? je vais pas relancer de troll, mais pourquoi WindowMaker est
classé dans les window managers légers ? parce que ce n'est pas un
J'ai pas écris qu'il était léger :-) Je disais que c'était juste un
gestionnaire de fenetre.
gestionnaire de bureau et que par conséquent il semble plus léger que
kde ou gnome ? Je n'arrive pas à comprendre, WindowMaker est _très_
gourmant en mémoire (et en ressource chez moi depuis quelques jours mais
Il est quand meme plus leger que KDE ou Gnome quoi qu'il arrive, sauf
bug, meme s'il est plus lourd que blackbox... N'aurais tu pas un fond
d'écran en jpg de 250 Mo ?
Cette version existe aussi sous linux sans doute, non ? Enfin, KDE reste lourd et encombrant en version lite ou pas, il vaut mieux choisir de te tourner vers des gestionnaire de fenetre tout betes plutot qu'un environnement de bureau complet, par exemple fluxbox ou WindowMaker. Euh ? je vais pas relancer de troll, mais pourquoi WindowMaker est
classé dans les window managers légers ? parce que ce n'est pas un
J'ai pas écris qu'il était léger :-) Je disais que c'était juste un gestionnaire de fenetre.
gestionnaire de bureau et que par conséquent il semble plus léger que kde ou gnome ? Je n'arrive pas à comprendre, WindowMaker est _très_ gourmant en mémoire (et en ressource chez moi depuis quelques jours mais
Il est quand meme plus leger que KDE ou Gnome quoi qu'il arrive, sauf bug, meme s'il est plus lourd que blackbox... N'aurais tu pas un fond d'écran en jpg de 250 Mo ?
-- Nicolas Le Scouarnec
talon
Marwan Burelle wrote:
Pour certains, c'est moins important, mais ça l'est pour moi, les reader libre de pdf ne supporte pas (ou mal) les anims (et quelques autres détails utiles.) Donc pour faire une présentation à base de pdf (avec prosper ou beamer) il n'y a que acroread ... (en plus je ne suis pas sûr que xpdf et gv fasse du fullscreen ... )
Tu as raison, j'oubliais ça aussi.
--
Michel TALON
Marwan Burelle <burelle@lri.fr> wrote:
Pour certains, c'est moins important, mais ça l'est pour moi, les reader
libre de pdf ne supporte pas (ou mal) les anims (et quelques autres
détails utiles.) Donc pour faire une présentation à base de pdf (avec
prosper ou beamer) il n'y a que acroread ... (en plus je ne suis pas sûr
que xpdf et gv fasse du fullscreen ... )
Pour certains, c'est moins important, mais ça l'est pour moi, les reader libre de pdf ne supporte pas (ou mal) les anims (et quelques autres détails utiles.) Donc pour faire une présentation à base de pdf (avec prosper ou beamer) il n'y a que acroread ... (en plus je ne suis pas sûr que xpdf et gv fasse du fullscreen ... )
Tu as raison, j'oubliais ça aussi.
--
Michel TALON
Benoit Izac
Bonjour,
le 21/01/2005 à 11:37, Marc Espie a écrit dans le message <csqm23$1he$ :
(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...
Selon toi, il devrait se trouver où ce caché ?
-- Benoit Izac
Bonjour,
le 21/01/2005 à 11:37, Marc Espie a écrit
dans le message <csqm23$1he$1@biggoron.nerim.net> :
(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...
le 21/01/2005 à 11:37, Marc Espie a écrit dans le message <csqm23$1he$ :
(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...
Selon toi, il devrait se trouver où ce caché ?
-- Benoit Izac
Nicolas Le Scouarnec
Zsh, puisque le confort est supérieur pour un coup mémoire très faiblement supérieur. Bash, tcsh, zsh oscillent entre 2 Mo et 3Mo. Tu peux voir cela en utilisant top. je vais commencer par tcsh, puis verrai zsh ultérieurement.
Je ferrais l'inverse comme la plupart des contributeurs, j'utilise tcsh parce que c'est mon shell de login sur mon compte étudiant, et que je ne peux pas le changer, c'est l'unique raison...
Solution violente: rm -rf /usr/ports rm -rf /usr/src je préfère garder les ports et les sources.
Dommage :-)
Ce sont les sources et les moyens d'installer/mettre a jour des applications, c'est un peu handicapant: tu ne peux plus faire de mise a jour depuis les sources, mais je supposes que tu n'as pas le processeur ou la place disque pour le faire... faut pas exagérer !! :-) j'ai un PII 233 Mhz et 2 DD (8 Go, 2 Go) avec
C'est très très utilisable, j'avais ca jusqu'a l'année dernière, sauf que pour tout mettre a jour par les sources faut etre courageux, surtout depuis que FreeBSD est passé a Gcc 3.x et comme ma patience est très limité, je faisais des mises a jour binaires a partir des CD...
Et la doc, ca ne sert jamais a rien... rm -rf /usr/share/doc # La doc, si tu la lis sur internet rm -rf /usr/local/share/doc un man en ligne, c'est qd meme confortable.
Les pages de manuel ne sont pas effacé, que feront on sans man. Enfin, si les gens les lisent :-/
-- Nicolas Le Scouarnec
Zsh, puisque le confort est supérieur pour un coup mémoire très
faiblement supérieur. Bash, tcsh, zsh oscillent entre 2 Mo et 3Mo.
Tu peux voir cela en utilisant top.
je vais commencer par tcsh, puis verrai zsh ultérieurement.
Je ferrais l'inverse comme la plupart des contributeurs, j'utilise tcsh
parce que c'est mon shell de login sur mon compte étudiant, et que je
ne peux pas le changer, c'est l'unique raison...
Solution violente:
rm -rf /usr/ports
rm -rf /usr/src
je préfère garder les ports et les sources.
Dommage :-)
Ce sont les sources et les moyens d'installer/mettre a jour des
applications, c'est un peu handicapant: tu ne peux plus faire de mise a
jour depuis les sources, mais je supposes que tu n'as pas le processeur
ou la place disque pour le faire...
faut pas exagérer !! :-) j'ai un PII 233 Mhz et 2 DD (8 Go, 2 Go) avec
C'est très très utilisable, j'avais ca jusqu'a l'année dernière, sauf
que pour tout mettre a jour par les sources faut etre courageux,
surtout depuis que FreeBSD est passé a Gcc 3.x et comme ma patience est
très limité, je faisais des mises a jour binaires a partir des CD...
Et la doc, ca ne sert jamais a rien...
rm -rf /usr/share/doc # La doc, si tu la lis sur internet
rm -rf /usr/local/share/doc
un man en ligne, c'est qd meme confortable.
Les pages de manuel ne sont pas effacé, que feront on sans man. Enfin,
si les gens les lisent :-/
Zsh, puisque le confort est supérieur pour un coup mémoire très faiblement supérieur. Bash, tcsh, zsh oscillent entre 2 Mo et 3Mo. Tu peux voir cela en utilisant top. je vais commencer par tcsh, puis verrai zsh ultérieurement.
Je ferrais l'inverse comme la plupart des contributeurs, j'utilise tcsh parce que c'est mon shell de login sur mon compte étudiant, et que je ne peux pas le changer, c'est l'unique raison...
Solution violente: rm -rf /usr/ports rm -rf /usr/src je préfère garder les ports et les sources.
Dommage :-)
Ce sont les sources et les moyens d'installer/mettre a jour des applications, c'est un peu handicapant: tu ne peux plus faire de mise a jour depuis les sources, mais je supposes que tu n'as pas le processeur ou la place disque pour le faire... faut pas exagérer !! :-) j'ai un PII 233 Mhz et 2 DD (8 Go, 2 Go) avec
C'est très très utilisable, j'avais ca jusqu'a l'année dernière, sauf que pour tout mettre a jour par les sources faut etre courageux, surtout depuis que FreeBSD est passé a Gcc 3.x et comme ma patience est très limité, je faisais des mises a jour binaires a partir des CD...
Et la doc, ca ne sert jamais a rien... rm -rf /usr/share/doc # La doc, si tu la lis sur internet rm -rf /usr/local/share/doc un man en ligne, c'est qd meme confortable.
Les pages de manuel ne sont pas effacé, que feront on sans man. Enfin, si les gens les lisent :-/
-- Nicolas Le Scouarnec
pornin
According to Michel Talon :
C'est quoi les Type3, du bitmap encapsulé?
En Type3, chaque caractère est un bout de code PostScript qui n'est pas restreint (alors qu'en Type1, il est très restreint). Acrobat gère ça en faisant un rendu en mémoire une fois pour chaque caractère, et en faisant ensuite un scaling bitmap. Le rendu final est effectivement le même que celui d'une police bitmap, mais c'est artificiel et c'est la faute d'Acrobat. À l'impression, tout va bien.
Acrobat pourrait interpréter le PostScript à chaque fois pour chaque caractère, mais ça ramerait à fond. La solution propre, ce serait de faire le rendu de chaque caractère une fois, en en gardant une trace _vectorielle_ en interne ; en gros, convertir la police Type3 en police Type1 au vol. Je crois que c'est ce que fait xpdf ; en tous cas, xpdf fait un rendu très correct des polices Type3.
Celà étant, celui qui utilise TeX pour produire des documents pdf avec des fontes bitmap incluses n'a qu'à s'en prendre à lui même d'être un vrai cochon.
Ce qui se passe, c'est que TeX ne contient à la base de police Type1 pour la police CMR que pour la version américaine. Les caractères accentués sont dans European-CMR, qu'il faut installer à part(*). En l'absence d'European-CMR en Type1, TeX génère une police de Type3 pour avoir ses caractères accentués.
Il existe un package-rustine nommé aeguill, qui remplace les caractères accentués par la lettre de base, et un accent rajouté après coup au bon endroit. Ça peut poser quelques problèmes (copy-paste dans le PDF, par exemple) mais au moins ça permet un rendu correct sous les viewer PDF usuels, même les vieux Acrobat Readers.
--Thomas Pornin
(*) Il est possible que les teTeX récentes contiennent ce qu'il faut.
According to Michel Talon <talon@lpthe.jussieu.fr>:
C'est quoi les Type3, du bitmap encapsulé?
En Type3, chaque caractère est un bout de code PostScript qui n'est
pas restreint (alors qu'en Type1, il est très restreint). Acrobat gère
ça en faisant un rendu en mémoire une fois pour chaque caractère, et
en faisant ensuite un scaling bitmap. Le rendu final est effectivement
le même que celui d'une police bitmap, mais c'est artificiel et c'est
la faute d'Acrobat. À l'impression, tout va bien.
Acrobat pourrait interpréter le PostScript à chaque fois pour chaque
caractère, mais ça ramerait à fond. La solution propre, ce serait de
faire le rendu de chaque caractère une fois, en en gardant une trace
_vectorielle_ en interne ; en gros, convertir la police Type3 en
police Type1 au vol. Je crois que c'est ce que fait xpdf ; en tous
cas, xpdf fait un rendu très correct des polices Type3.
Celà étant, celui qui utilise TeX pour produire des documents pdf avec
des fontes bitmap incluses n'a qu'à s'en prendre à lui même d'être un
vrai cochon.
Ce qui se passe, c'est que TeX ne contient à la base de police Type1
pour la police CMR que pour la version américaine. Les caractères
accentués sont dans European-CMR, qu'il faut installer à part(*). En
l'absence d'European-CMR en Type1, TeX génère une police de Type3 pour
avoir ses caractères accentués.
Il existe un package-rustine nommé aeguill, qui remplace les caractères
accentués par la lettre de base, et un accent rajouté après coup au bon
endroit. Ça peut poser quelques problèmes (copy-paste dans le PDF, par
exemple) mais au moins ça permet un rendu correct sous les viewer PDF
usuels, même les vieux Acrobat Readers.
--Thomas Pornin
(*) Il est possible que les teTeX récentes contiennent ce qu'il faut.
En Type3, chaque caractère est un bout de code PostScript qui n'est pas restreint (alors qu'en Type1, il est très restreint). Acrobat gère ça en faisant un rendu en mémoire une fois pour chaque caractère, et en faisant ensuite un scaling bitmap. Le rendu final est effectivement le même que celui d'une police bitmap, mais c'est artificiel et c'est la faute d'Acrobat. À l'impression, tout va bien.
Acrobat pourrait interpréter le PostScript à chaque fois pour chaque caractère, mais ça ramerait à fond. La solution propre, ce serait de faire le rendu de chaque caractère une fois, en en gardant une trace _vectorielle_ en interne ; en gros, convertir la police Type3 en police Type1 au vol. Je crois que c'est ce que fait xpdf ; en tous cas, xpdf fait un rendu très correct des polices Type3.
Celà étant, celui qui utilise TeX pour produire des documents pdf avec des fontes bitmap incluses n'a qu'à s'en prendre à lui même d'être un vrai cochon.
Ce qui se passe, c'est que TeX ne contient à la base de police Type1 pour la police CMR que pour la version américaine. Les caractères accentués sont dans European-CMR, qu'il faut installer à part(*). En l'absence d'European-CMR en Type1, TeX génère une police de Type3 pour avoir ses caractères accentués.
Il existe un package-rustine nommé aeguill, qui remplace les caractères accentués par la lettre de base, et un accent rajouté après coup au bon endroit. Ça peut poser quelques problèmes (copy-paste dans le PDF, par exemple) mais au moins ça permet un rendu correct sous les viewer PDF usuels, même les vieux Acrobat Readers.
--Thomas Pornin
(*) Il est possible que les teTeX récentes contiennent ce qu'il faut.
pornin
According to Marwan Burelle :
(en plus je ne suis pas sûr que xpdf et gv fasse du fullscreen ... )
xpdf fait du fullscreen, et peut être utilisé pour des présentations. Mais il n'est pas forcément évident de faire une présentation avec des fioritures graphiques qui passe bien aussi bien sous xpdf que sous Acrobat Reader, ce qui pose un problème si, après une présentation réussie, le client veut aussi une copie du PDF pour se la repasser chez lui.
--Thomas Pornin
According to Marwan Burelle <burelle@lri.fr>:
(en plus je ne suis pas sûr
que xpdf et gv fasse du fullscreen ... )
xpdf fait du fullscreen, et peut être utilisé pour des présentations.
Mais il n'est pas forcément évident de faire une présentation avec des
fioritures graphiques qui passe bien aussi bien sous xpdf que sous
Acrobat Reader, ce qui pose un problème si, après une présentation
réussie, le client veut aussi une copie du PDF pour se la repasser chez
lui.
(en plus je ne suis pas sûr que xpdf et gv fasse du fullscreen ... )
xpdf fait du fullscreen, et peut être utilisé pour des présentations. Mais il n'est pas forcément évident de faire une présentation avec des fioritures graphiques qui passe bien aussi bien sous xpdf que sous Acrobat Reader, ce qui pose un problème si, après une présentation réussie, le client veut aussi une copie du PDF pour se la repasser chez lui.
--Thomas Pornin
pornin
According to Stephane Chazelas :
Tu peux ameliorer ca legerement en remplacant ces 4 xterms par un xterm avec screen dedans...
Pas tout-à-fait. Je vois mes 4 xterms simultanément ; ils ne se recouvrent pas, même partiellement. C'est important dans mon mode de travail.
Si j'avais un bel écran 22", j'aurais probablement 9 xterms, en 3x3.
--Thomas Pornin
According to Stephane Chazelas <cette.adresse@est.invalid>:
Tu peux ameliorer ca legerement en remplacant ces 4 xterms par
un xterm avec screen dedans...
Pas tout-à-fait. Je vois mes 4 xterms simultanément ; ils ne se
recouvrent pas, même partiellement. C'est important dans mon mode
de travail.
Si j'avais un bel écran 22", j'aurais probablement 9 xterms, en 3x3.
Tu peux ameliorer ca legerement en remplacant ces 4 xterms par un xterm avec screen dedans...
Pas tout-à-fait. Je vois mes 4 xterms simultanément ; ils ne se recouvrent pas, même partiellement. C'est important dans mon mode de travail.
Si j'avais un bel écran 22", j'aurais probablement 9 xterms, en 3x3.
--Thomas Pornin
espie
In article , Benoit Izac wrote:
Bonjour,
le 21/01/2005 à 11:37, Marc Espie a écrit dans le message <csqm23$1he$ :
(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...
Selon toi, il devrait se trouver où ce caché ?
Quelque part derriere une appli commune a tout le systeme qui te donne les fichiers quand tu les veux.
D'ailleurs, a la limite, devrait pas y avoir de cache disque. Un proxy local sur sockets Unix, ca serait bien.
In article <w53zmz290ul@message.id>, Benoit Izac <benoit.izac@free.fr> wrote:
Bonjour,
le 21/01/2005 à 11:37, Marc Espie a écrit
dans le message <csqm23$1he$1@biggoron.nerim.net> :
(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...
Selon toi, il devrait se trouver où ce caché ?
Quelque part derriere une appli commune a tout le systeme qui te donne
les fichiers quand tu les veux.
D'ailleurs, a la limite, devrait pas y avoir de cache disque. Un proxy
local sur sockets Unix, ca serait bien.
le 21/01/2005 à 11:37, Marc Espie a écrit dans le message <csqm23$1he$ :
(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...
Selon toi, il devrait se trouver où ce caché ?
Quelque part derriere une appli commune a tout le systeme qui te donne les fichiers quand tu les veux.
D'ailleurs, a la limite, devrait pas y avoir de cache disque. Un proxy local sur sockets Unix, ca serait bien.
espie
In article <csrgo2$cqg$, Marc Espie wrote:
D'ailleurs, a la limite, devrait pas y avoir de cache disque. Un proxy local sur sockets Unix, ca serait bien.
Une autre tres bonne raison pour cela: si tu as le malheur d'utiliser deux ou trois navigateurs, ils ont tous un cache different. Et pouf 50M de mozilla par ci, 50M de firefox par la, 50M de konqueror a cote. Ca te bouffe vite ton disque tout ca...
In article <csrgo2$cqg$1@biggoron.nerim.net>,
Marc Espie <espie@nerim.net> wrote:
D'ailleurs, a la limite, devrait pas y avoir de cache disque. Un proxy
local sur sockets Unix, ca serait bien.
Une autre tres bonne raison pour cela: si tu as le malheur d'utiliser
deux ou trois navigateurs, ils ont tous un cache different. Et pouf
50M de mozilla par ci, 50M de firefox par la, 50M de konqueror a cote.
Ca te bouffe vite ton disque tout ca...
D'ailleurs, a la limite, devrait pas y avoir de cache disque. Un proxy local sur sockets Unix, ca serait bien.
Une autre tres bonne raison pour cela: si tu as le malheur d'utiliser deux ou trois navigateurs, ils ont tous un cache different. Et pouf 50M de mozilla par ci, 50M de firefox par la, 50M de konqueror a cote. Ca te bouffe vite ton disque tout ca...
Nicolas Le Scouarnec
(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... Selon toi, il devrait se trouver où ce caché ?
/tmp/user/mozilla-cache ?
-- Nicolas Le Scouarnec
(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...
Selon toi, il devrait se trouver où ce caché ?
(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... Selon toi, il devrait se trouver où ce caché ?
