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é.
Peut-être avec Outlook, mais j'ai eu pas mal de problèmes avec des combinaisons courier et mozilla/thunderbird.
Pas de bol.
Aucun problème ici, ni avec Mozilla (1.6, 1.7.*, 1.8.*) ni avec aucune version de TB depuis la 0.6 (pas testé avant) aussi bien en pop, qu'en imap et dans les version ssl.
Ça fonctionne aussi très bien avec Apple Mail, Outloock, OE, Gnus et sûrement d'autres :)
Le seul avec lequel j'ai des problèmes, c'est SnapperMail sur mon Palm en imap-ssl.
-- CHC
Francois Tigeot <ftigeot@nospam.free.fr> writes:
Peut-être avec Outlook, mais j'ai eu pas mal de problèmes avec des
combinaisons courier et mozilla/thunderbird.
Pas de bol.
Aucun problème ici, ni avec Mozilla (1.6, 1.7.*, 1.8.*) ni avec aucune
version de TB depuis la 0.6 (pas testé avant) aussi bien en pop, qu'en
imap et dans les version ssl.
Ça fonctionne aussi très bien avec Apple Mail, Outloock, OE, Gnus et
sûrement d'autres :)
Le seul avec lequel j'ai des problèmes, c'est SnapperMail sur mon Palm
en imap-ssl.
Peut-être avec Outlook, mais j'ai eu pas mal de problèmes avec des combinaisons courier et mozilla/thunderbird.
Pas de bol.
Aucun problème ici, ni avec Mozilla (1.6, 1.7.*, 1.8.*) ni avec aucune version de TB depuis la 0.6 (pas testé avant) aussi bien en pop, qu'en imap et dans les version ssl.
Ça fonctionne aussi très bien avec Apple Mail, Outloock, OE, Gnus et sûrement d'autres :)
Le seul avec lequel j'ai des problèmes, c'est SnapperMail sur mon Palm en imap-ssl.
-- CHC
Christophe Cuq
Marwan Burelle writes:
De toute façon, un serveur imap ça doit juste être une commande imapd que l'on peut lancer en standalone depuis n'importe quel shell, l'imap over ssh, c'est quand même bien plus agréable ...
Si tu le dis, je veux bien le croire :)
-- CHC
Marwan Burelle <burelle@lri.fr> writes:
De toute façon, un serveur imap ça doit juste être une commande imapd
que l'on peut lancer en standalone depuis n'importe quel shell, l'imap
over ssh, c'est quand même bien plus agréable ...
De toute façon, un serveur imap ça doit juste être une commande imapd que l'on peut lancer en standalone depuis n'importe quel shell, l'imap over ssh, c'est quand même bien plus agréable ...
Si tu le dis, je veux bien le croire :)
-- CHC
Marwan Burelle
On Thu, 20 Jan 2005 14:01:24 +0000 Stephane Chazelas wrote:
Je repondais a quelqu'un qui disait que bash n'etait pas un "sh"
A moi, justement ;)
au contraire du /bin/sh des BSD. Je reponds que bash est plus un "sh" (au sens defini par la Single Unix Specification) que le /bin/sh des BSD.
Ce n'est pas tout à fait ce que je disais, bash, en soit n'est pas qu'un "sh", c'est un shell à usage autant interactif (le sh de base n'est pas franchement ce que j'appellerai un shell interactif ... ) qu'en script, par contre la raison d'être de sh sur les BSD est quasiment uniquement l'usage dans les scripts, il essaie, un minimum de respecter la syntaxe et le comportement que l'on attend d'un tel shell.
Ça me paraît une bonne méthode pour définir un sh, un truc pas utilisable (ou presque pas) interactivement, et par contre qui fait ce qu'on veut en temps qu'interpréteur de script. C'est un peu réducteur, je te l'accorde, mais vu que presque personne ne respecte complètement les normes POSIX et SUS, c'est plus "effectif" comme définition ...
Pour aller plus loin, j'aurais tendance à penser qu'un /bin/sh qui accepte une syntaxe étendue n'est pas un bon sh, j'ai eu plusieurs fois affaire avec des scripts écrit avec bash, mais "prévus" pour bin/sh qui posaient des problèmes sur des machines ou bin/sh n'est pas bash. C'est fatiguant, surtout que souvent il s'agit de détail de syntaxe qui ne changent pas grand chose à l'exprissivité du shell ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Thu, 20 Jan 2005 14:01:24 +0000
Stephane Chazelas <cette.adresse@est.invalid> wrote:
Je repondais a quelqu'un qui disait que bash n'etait pas un "sh"
A moi, justement ;)
au contraire du /bin/sh des BSD. Je reponds que bash est plus un
"sh" (au sens defini par la Single Unix Specification) que le
/bin/sh des BSD.
Ce n'est pas tout à fait ce que je disais, bash, en soit n'est pas qu'un
"sh", c'est un shell à usage autant interactif (le sh de base n'est pas
franchement ce que j'appellerai un shell interactif ... ) qu'en script,
par contre la raison d'être de sh sur les BSD est quasiment uniquement
l'usage dans les scripts, il essaie, un minimum de respecter la syntaxe
et le comportement que l'on attend d'un tel shell.
Ça me paraît une bonne méthode pour définir un sh, un truc pas
utilisable (ou presque pas) interactivement, et par contre qui fait ce
qu'on veut en temps qu'interpréteur de script. C'est un peu réducteur,
je te l'accorde, mais vu que presque personne ne respecte complètement
les normes POSIX et SUS, c'est plus "effectif" comme définition ...
Pour aller plus loin, j'aurais tendance à penser qu'un /bin/sh qui
accepte une syntaxe étendue n'est pas un bon sh, j'ai eu plusieurs fois
affaire avec des scripts écrit avec bash, mais "prévus" pour bin/sh qui
posaient des problèmes sur des machines ou bin/sh n'est pas bash. C'est
fatiguant, surtout que souvent il s'agit de détail de syntaxe qui ne
changent pas grand chose à l'exprissivité du shell ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Thu, 20 Jan 2005 14:01:24 +0000 Stephane Chazelas wrote:
Je repondais a quelqu'un qui disait que bash n'etait pas un "sh"
A moi, justement ;)
au contraire du /bin/sh des BSD. Je reponds que bash est plus un "sh" (au sens defini par la Single Unix Specification) que le /bin/sh des BSD.
Ce n'est pas tout à fait ce que je disais, bash, en soit n'est pas qu'un "sh", c'est un shell à usage autant interactif (le sh de base n'est pas franchement ce que j'appellerai un shell interactif ... ) qu'en script, par contre la raison d'être de sh sur les BSD est quasiment uniquement l'usage dans les scripts, il essaie, un minimum de respecter la syntaxe et le comportement que l'on attend d'un tel shell.
Ça me paraît une bonne méthode pour définir un sh, un truc pas utilisable (ou presque pas) interactivement, et par contre qui fait ce qu'on veut en temps qu'interpréteur de script. C'est un peu réducteur, je te l'accorde, mais vu que presque personne ne respecte complètement les normes POSIX et SUS, c'est plus "effectif" comme définition ...
Pour aller plus loin, j'aurais tendance à penser qu'un /bin/sh qui accepte une syntaxe étendue n'est pas un bon sh, j'ai eu plusieurs fois affaire avec des scripts écrit avec bash, mais "prévus" pour bin/sh qui posaient des problèmes sur des machines ou bin/sh n'est pas bash. C'est fatiguant, surtout que souvent il s'agit de détail de syntaxe qui ne changent pas grand chose à l'exprissivité du shell ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Stephane Chazelas
2005-01-20, 16:49(+01), Marwan Burelle: [...]
Ce n'est pas tout à fait ce que je disais, bash, en soit n'est pas qu'un "sh", c'est un shell à usage autant interactif (le sh de base n'est pas franchement ce que j'appellerai un shell interactif ... ) qu'en script, par contre la raison d'être de sh sur les BSD est quasiment uniquement l'usage dans les scripts, il essaie, un minimum de respecter la syntaxe et le comportement que l'on attend d'un tel shell. [...]
Oui, encore que SUS definit un mode vi pour "sh" et differencie le comportement en mode interactif et en mode non-interactif.
Ça me paraît une bonne méthode pour définir un sh, un truc pas utilisable (ou presque pas) interactivement, et par contre qui fait ce qu'on veut en temps qu'interpréteur de script. C'est un peu réducteur, je te l'accorde, mais vu que presque personne ne respecte complètement les normes POSIX et SUS, c'est plus "effectif" comme définition ...
Pour aller plus loin, j'aurais tendance à penser qu'un /bin/sh qui accepte une syntaxe étendue n'est pas un bon sh, j'ai eu plusieurs fois affaire avec des scripts écrit avec bash, mais "prévus" pour bin/sh qui posaient des problèmes sur des machines ou bin/sh n'est pas bash. C'est fatiguant, surtout que souvent il s'agit de détail de syntaxe qui ne changent pas grand chose à l'exprissivité du shell ...
C'est un probleme des gens qui ecrivent des scripts, pas des shells mais je suis d'accord que c'est un probleme bien reel, et qu'on y serait moins confronté si le /bin/sh de Linux etait dans le genre de celui des BSDs.
-- Stéphane
2005-01-20, 16:49(+01), Marwan Burelle:
[...]
Ce n'est pas tout à fait ce que je disais, bash, en soit n'est pas qu'un
"sh", c'est un shell à usage autant interactif (le sh de base n'est pas
franchement ce que j'appellerai un shell interactif ... ) qu'en script,
par contre la raison d'être de sh sur les BSD est quasiment uniquement
l'usage dans les scripts, il essaie, un minimum de respecter la syntaxe
et le comportement que l'on attend d'un tel shell.
[...]
Oui, encore que SUS definit un mode vi pour "sh" et differencie
le comportement en mode interactif et en mode non-interactif.
Ça me paraît une bonne méthode pour définir un sh, un truc pas
utilisable (ou presque pas) interactivement, et par contre qui fait ce
qu'on veut en temps qu'interpréteur de script. C'est un peu réducteur,
je te l'accorde, mais vu que presque personne ne respecte complètement
les normes POSIX et SUS, c'est plus "effectif" comme définition ...
Pour aller plus loin, j'aurais tendance à penser qu'un /bin/sh qui
accepte une syntaxe étendue n'est pas un bon sh, j'ai eu plusieurs fois
affaire avec des scripts écrit avec bash, mais "prévus" pour bin/sh qui
posaient des problèmes sur des machines ou bin/sh n'est pas bash. C'est
fatiguant, surtout que souvent il s'agit de détail de syntaxe qui ne
changent pas grand chose à l'exprissivité du shell ...
C'est un probleme des gens qui ecrivent des scripts, pas des
shells mais je suis d'accord que c'est un probleme bien reel, et
qu'on y serait moins confronté si le /bin/sh de Linux etait dans
le genre de celui des BSDs.
Ce n'est pas tout à fait ce que je disais, bash, en soit n'est pas qu'un "sh", c'est un shell à usage autant interactif (le sh de base n'est pas franchement ce que j'appellerai un shell interactif ... ) qu'en script, par contre la raison d'être de sh sur les BSD est quasiment uniquement l'usage dans les scripts, il essaie, un minimum de respecter la syntaxe et le comportement que l'on attend d'un tel shell. [...]
Oui, encore que SUS definit un mode vi pour "sh" et differencie le comportement en mode interactif et en mode non-interactif.
Ça me paraît une bonne méthode pour définir un sh, un truc pas utilisable (ou presque pas) interactivement, et par contre qui fait ce qu'on veut en temps qu'interpréteur de script. C'est un peu réducteur, je te l'accorde, mais vu que presque personne ne respecte complètement les normes POSIX et SUS, c'est plus "effectif" comme définition ...
Pour aller plus loin, j'aurais tendance à penser qu'un /bin/sh qui accepte une syntaxe étendue n'est pas un bon sh, j'ai eu plusieurs fois affaire avec des scripts écrit avec bash, mais "prévus" pour bin/sh qui posaient des problèmes sur des machines ou bin/sh n'est pas bash. C'est fatiguant, surtout que souvent il s'agit de détail de syntaxe qui ne changent pas grand chose à l'exprissivité du shell ...
C'est un probleme des gens qui ecrivent des scripts, pas des shells mais je suis d'accord que c'est un probleme bien reel, et qu'on y serait moins confronté si le /bin/sh de Linux etait dans le genre de celui des BSDs.
-- Stéphane
Arnaud Launay
Le Thu, 20 Jan 2005 14:13:40 +0100, DINH Viêt Hoà écrivit:
Ah oui ya des trucs. Mais dans le genre c'est super compliqué. Rarement vu une doc aussi mal branlée :) c'est un serveur d'homme.
Avec une paire de couilles comme ça, et une grosse barbe.
Pour plus d'explication, c'est le serveur le plus performant (temps d'utilisation processeur) parmi ceux qui existent. Mais effectivement sans doute un peu compliqué à mettre en place.
Tiens, d'ailleurs, je cherchais un moyen de faire en sorte que le login des users soit leur adresse mail, donc plutôt que toto.coin.com, quelqu'un saurait comment faire ?
Le Thu, 20 Jan 2005 14:13:40 +0100, DINH Viêt Hoà écrivit:
Ah oui ya des trucs. Mais dans le genre c'est super compliqué.
Rarement vu une doc aussi mal branlée :)
c'est un serveur d'homme.
Avec une paire de couilles comme ça, et une grosse barbe.
Pour plus d'explication, c'est le serveur le plus performant (temps
d'utilisation processeur) parmi ceux qui existent.
Mais effectivement sans doute un peu compliqué à mettre en place.
Tiens, d'ailleurs, je cherchais un moyen de faire en sorte que le
login des users soit leur adresse mail, donc toto@coin.com plutôt
que toto.coin.com, quelqu'un saurait comment faire ?
Le Thu, 20 Jan 2005 14:13:40 +0100, DINH Viêt Hoà écrivit:
Ah oui ya des trucs. Mais dans le genre c'est super compliqué. Rarement vu une doc aussi mal branlée :) c'est un serveur d'homme.
Avec une paire de couilles comme ça, et une grosse barbe.
Pour plus d'explication, c'est le serveur le plus performant (temps d'utilisation processeur) parmi ceux qui existent. Mais effectivement sans doute un peu compliqué à mettre en place.
Tiens, d'ailleurs, je cherchais un moyen de faire en sorte que le login des users soit leur adresse mail, donc plutôt que toto.coin.com, quelqu'un saurait comment faire ?
ce point m'intéresse: j'ai un PC qui n'est pas récent. j'ai choisi FreeBSD, et délaissé linux pour des raisons de performances. j'ai lu et eu des avis concordants sur ces aspects de bsd: noyau léger (économie de RAM), version de kde lite (même si je ne vois pas trop de difference avec KDE3 version complète) etc...
quel shell préconiseriez vous dans ce contexte ?
Le shell ne devrait pas faire de différence sensible. À moins que le PC "pas récent" soit du genre 80486 à 33 MHz... mais même dans ce cas, il y a plus urgent que le shell à réformer.
Je parlais du temps de lancement dans le cas des scripts. Un script est un petit programme écrit en langage "shell" ; c'est en interne un fichier texte et la première ligne commence par une invocation du shell en question, de la forme "#! /bin/sh" ou équivalent. Un tel script, lancé un grand nombre de fois, peut avoir des problèmes de performances si le shell est lent au démarrage ; évidemment, ça dépend de ce que fait le script, et le cas est assez rare. Cette histoire de temps de lancement justifie qu'on veuille un /bin/sh qui n'est pas bash.
Pour le shell interactif, on le lance beaucoup moins souvent (il est interactif, donc sa vie et sa mort ne vont pas plus vite que l'humain qui est devant le clavier) donc le temps de lancement est négligeable.
En tant que shell interactif, j'utilise zsh et j'en suis content.
Pour ce qui est des performances : dans mon expérience, FreeBSD a tendance à être un peu meilleur que Linux quand la mémoire est restreinte. Je veux dire que le noyau semble se débrouiller un peu mieux avec le swap pour garder à la machine sa réactivité. À noter que mon expérience me dit aussi que Solaris est meilleur que FreeBSD et Linux pour ça.
Pour le reste, il ne devrait pas y avoir de différence sensible entre Linux et FreeBSD. Les applications sont les mêmes et leur consommation mémoire aussi.
corollaire: j'ai installé Fbsd 5.3 sur une partion de 4 Go (dont swap = 600 Mo) et, actuellement, 86% (!!) de ma partition (hors swap) sont utilisés alors que je n'ai installé que thunderbird (firefox est installé alors que je ne l'ai jamais demandé: il s'installerait avec thunderbird ?)), acrobat et qques fonts, et suis passé de kde3 à kde lite.... j'ai dû me planter à l'install. comment puis je faire de la place sans casser quelquechose ? le handbook n'aborde pas ces aspects.
Pour la place prise, il y a : -- les packages -- les trucs temporaires qui traînent
Pour les packages installés, "pkg_info" en donne la liste. On peut en virer avec pkg_delete ; s'il y a des dépendances (le package est utilisé par d'autres), pkg_delete râlera et ne virera pas le package (sauf si on indique le flag -f, ce qui n'est pas conseillé). Ça permet de faire du ménage sans tout casser.
Pour les trucs temporaires :
-- vérifier que /tmp et /var/tmp ne sont pas pleins de bêtises ;
-- virer le contenu de /usr/obj (c'est là qu'est compilé le système de base quand on le met à jour) ;
-- vérifier qu'on n'a pas d'arbres de compilation dans /usr/ports. Quand on installe un package via un port, ça se fait par une compilation, et si on n'est pas passé par portupgrade ou portinstall, les arbres de compilation temporaires ont tendance à rester. Pour les chercher, je fais ça : find /usr/ports -type d -name work et ensuite je fais du "rm -rf" sur ces répertoires "work". Il y a une commande magique (avec make) qui fait ça mais je ne m'en rappelle jamais.
-- voir le contenu de /usr/ports/distfiles. C'est là qu'arrivent les archives téléchargées pour l'installation des ports. Ça peut se virer sans remord.
Bon, sinon, il faut voir que : KDE, c'est gros sur le disque. Thunderbird et Firefox, c'est gros sur le disque. Acrobat, c'est un binaire Linux, donc il vient avec la couche de compatibilité Linux, donc des bibliothèques Linux, donc c'est gros sur le disque. Tout ça utilise X11, et X11, c'est gros sur le disque.
--Thomas Pornin
According to claude <nospam@nospam.fr>:
ce point m'intéresse: j'ai un PC qui n'est pas récent. j'ai choisi
FreeBSD, et délaissé linux pour des raisons de performances. j'ai lu et
eu des avis concordants sur ces aspects de bsd: noyau léger (économie de
RAM), version de kde lite (même si je ne vois pas trop de difference
avec KDE3 version complète) etc...
quel shell préconiseriez vous dans ce contexte ?
Le shell ne devrait pas faire de différence sensible. À moins que le PC
"pas récent" soit du genre 80486 à 33 MHz... mais même dans ce cas, il y
a plus urgent que le shell à réformer.
Je parlais du temps de lancement dans le cas des scripts. Un script
est un petit programme écrit en langage "shell" ; c'est en interne un
fichier texte et la première ligne commence par une invocation du shell
en question, de la forme "#! /bin/sh" ou équivalent. Un tel script,
lancé un grand nombre de fois, peut avoir des problèmes de performances
si le shell est lent au démarrage ; évidemment, ça dépend de ce que
fait le script, et le cas est assez rare. Cette histoire de temps de
lancement justifie qu'on veuille un /bin/sh qui n'est pas bash.
Pour le shell interactif, on le lance beaucoup moins souvent (il est
interactif, donc sa vie et sa mort ne vont pas plus vite que l'humain
qui est devant le clavier) donc le temps de lancement est négligeable.
En tant que shell interactif, j'utilise zsh et j'en suis content.
Pour ce qui est des performances : dans mon expérience, FreeBSD
a tendance à être un peu meilleur que Linux quand la mémoire est
restreinte. Je veux dire que le noyau semble se débrouiller un peu mieux
avec le swap pour garder à la machine sa réactivité. À noter que mon
expérience me dit aussi que Solaris est meilleur que FreeBSD et Linux
pour ça.
Pour le reste, il ne devrait pas y avoir de différence sensible entre
Linux et FreeBSD. Les applications sont les mêmes et leur consommation
mémoire aussi.
corollaire: j'ai installé Fbsd 5.3 sur une partion de 4 Go (dont swap =
600 Mo) et, actuellement, 86% (!!) de ma partition (hors swap) sont
utilisés alors que je n'ai installé que thunderbird (firefox est
installé alors que je ne l'ai jamais demandé: il s'installerait avec
thunderbird ?)), acrobat et qques fonts, et suis passé de kde3 à kde
lite.... j'ai dû me planter à l'install.
comment puis je faire de la place sans casser quelquechose ? le handbook
n'aborde pas ces aspects.
Pour la place prise, il y a :
-- les packages
-- les trucs temporaires qui traînent
Pour les packages installés, "pkg_info" en donne la liste. On peut en
virer avec pkg_delete ; s'il y a des dépendances (le package est utilisé
par d'autres), pkg_delete râlera et ne virera pas le package (sauf si on
indique le flag -f, ce qui n'est pas conseillé). Ça permet de faire du
ménage sans tout casser.
Pour les trucs temporaires :
-- vérifier que /tmp et /var/tmp ne sont pas pleins de bêtises ;
-- virer le contenu de /usr/obj (c'est là qu'est compilé le système de
base quand on le met à jour) ;
-- vérifier qu'on n'a pas d'arbres de compilation dans /usr/ports. Quand
on installe un package via un port, ça se fait par une compilation, et
si on n'est pas passé par portupgrade ou portinstall, les arbres de
compilation temporaires ont tendance à rester. Pour les chercher, je fais
ça :
find /usr/ports -type d -name work
et ensuite je fais du "rm -rf" sur ces répertoires "work". Il y a une
commande magique (avec make) qui fait ça mais je ne m'en rappelle jamais.
-- voir le contenu de /usr/ports/distfiles. C'est là qu'arrivent les
archives téléchargées pour l'installation des ports. Ça peut se virer
sans remord.
Bon, sinon, il faut voir que :
KDE, c'est gros sur le disque.
Thunderbird et Firefox, c'est gros sur le disque.
Acrobat, c'est un binaire Linux, donc il vient avec la couche de
compatibilité Linux, donc des bibliothèques Linux, donc c'est gros
sur le disque.
Tout ça utilise X11, et X11, c'est gros sur le disque.
ce point m'intéresse: j'ai un PC qui n'est pas récent. j'ai choisi FreeBSD, et délaissé linux pour des raisons de performances. j'ai lu et eu des avis concordants sur ces aspects de bsd: noyau léger (économie de RAM), version de kde lite (même si je ne vois pas trop de difference avec KDE3 version complète) etc...
quel shell préconiseriez vous dans ce contexte ?
Le shell ne devrait pas faire de différence sensible. À moins que le PC "pas récent" soit du genre 80486 à 33 MHz... mais même dans ce cas, il y a plus urgent que le shell à réformer.
Je parlais du temps de lancement dans le cas des scripts. Un script est un petit programme écrit en langage "shell" ; c'est en interne un fichier texte et la première ligne commence par une invocation du shell en question, de la forme "#! /bin/sh" ou équivalent. Un tel script, lancé un grand nombre de fois, peut avoir des problèmes de performances si le shell est lent au démarrage ; évidemment, ça dépend de ce que fait le script, et le cas est assez rare. Cette histoire de temps de lancement justifie qu'on veuille un /bin/sh qui n'est pas bash.
Pour le shell interactif, on le lance beaucoup moins souvent (il est interactif, donc sa vie et sa mort ne vont pas plus vite que l'humain qui est devant le clavier) donc le temps de lancement est négligeable.
En tant que shell interactif, j'utilise zsh et j'en suis content.
Pour ce qui est des performances : dans mon expérience, FreeBSD a tendance à être un peu meilleur que Linux quand la mémoire est restreinte. Je veux dire que le noyau semble se débrouiller un peu mieux avec le swap pour garder à la machine sa réactivité. À noter que mon expérience me dit aussi que Solaris est meilleur que FreeBSD et Linux pour ça.
Pour le reste, il ne devrait pas y avoir de différence sensible entre Linux et FreeBSD. Les applications sont les mêmes et leur consommation mémoire aussi.
corollaire: j'ai installé Fbsd 5.3 sur une partion de 4 Go (dont swap = 600 Mo) et, actuellement, 86% (!!) de ma partition (hors swap) sont utilisés alors que je n'ai installé que thunderbird (firefox est installé alors que je ne l'ai jamais demandé: il s'installerait avec thunderbird ?)), acrobat et qques fonts, et suis passé de kde3 à kde lite.... j'ai dû me planter à l'install. comment puis je faire de la place sans casser quelquechose ? le handbook n'aborde pas ces aspects.
Pour la place prise, il y a : -- les packages -- les trucs temporaires qui traînent
Pour les packages installés, "pkg_info" en donne la liste. On peut en virer avec pkg_delete ; s'il y a des dépendances (le package est utilisé par d'autres), pkg_delete râlera et ne virera pas le package (sauf si on indique le flag -f, ce qui n'est pas conseillé). Ça permet de faire du ménage sans tout casser.
Pour les trucs temporaires :
-- vérifier que /tmp et /var/tmp ne sont pas pleins de bêtises ;
-- virer le contenu de /usr/obj (c'est là qu'est compilé le système de base quand on le met à jour) ;
-- vérifier qu'on n'a pas d'arbres de compilation dans /usr/ports. Quand on installe un package via un port, ça se fait par une compilation, et si on n'est pas passé par portupgrade ou portinstall, les arbres de compilation temporaires ont tendance à rester. Pour les chercher, je fais ça : find /usr/ports -type d -name work et ensuite je fais du "rm -rf" sur ces répertoires "work". Il y a une commande magique (avec make) qui fait ça mais je ne m'en rappelle jamais.
-- voir le contenu de /usr/ports/distfiles. C'est là qu'arrivent les archives téléchargées pour l'installation des ports. Ça peut se virer sans remord.
Bon, sinon, il faut voir que : KDE, c'est gros sur le disque. Thunderbird et Firefox, c'est gros sur le disque. Acrobat, c'est un binaire Linux, donc il vient avec la couche de compatibilité Linux, donc des bibliothèques Linux, donc c'est gros sur le disque. Tout ça utilise X11, et X11, c'est gros sur le disque.
--Thomas Pornin
DINH Viêt Hoà
Peut-être avec Outlook, mais j'ai eu pas mal de problèmes avec des combinaisons courier et mozilla/thunderbird.
Pas de bol.
Aucun problème ici, ni avec Mozilla (1.6, 1.7.*, 1.8.*) ni avec aucune version de TB depuis la 0.6 (pas testé avant) aussi bien en pop, qu'en imap et dans les version ssl.
Ça fonctionne aussi très bien avec Apple Mail, Outloock, OE, Gnus et sûrement d'autres :)
Le seul avec lequel j'ai des problèmes, c'est SnapperMail sur mon Palm en imap-ssl.
effectivement, c'est pour ça qu'il y a des standards comme IMAP (que seul Courier ne semble pas respecter complètement).
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Peut-être avec Outlook, mais j'ai eu pas mal de problèmes avec des
combinaisons courier et mozilla/thunderbird.
Pas de bol.
Aucun problème ici, ni avec Mozilla (1.6, 1.7.*, 1.8.*) ni avec aucune
version de TB depuis la 0.6 (pas testé avant) aussi bien en pop, qu'en
imap et dans les version ssl.
Ça fonctionne aussi très bien avec Apple Mail, Outloock, OE, Gnus et
sûrement d'autres :)
Le seul avec lequel j'ai des problèmes, c'est SnapperMail sur mon Palm
en imap-ssl.
effectivement, c'est pour ça qu'il y a des standards comme IMAP
(que seul Courier ne semble pas respecter complètement).
--
DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
Peut-être avec Outlook, mais j'ai eu pas mal de problèmes avec des combinaisons courier et mozilla/thunderbird.
Pas de bol.
Aucun problème ici, ni avec Mozilla (1.6, 1.7.*, 1.8.*) ni avec aucune version de TB depuis la 0.6 (pas testé avant) aussi bien en pop, qu'en imap et dans les version ssl.
Ça fonctionne aussi très bien avec Apple Mail, Outloock, OE, Gnus et sûrement d'autres :)
Le seul avec lequel j'ai des problèmes, c'est SnapperMail sur mon Palm en imap-ssl.
effectivement, c'est pour ça qu'il y a des standards comme IMAP (que seul Courier ne semble pas respecter complètement).
-- DINH V. Hoa,
"Vu que t'es physiquement intelligente, tu viens avec moi ?" - Brice
claude
Stephane Chazelas wrote:
ben oui... s'ils existent :( et c'est ma question: pourquoi avec bash-3.0.0, ces fichiers ne sont ni sous ma home, ni sous celle de root ?
Si tu n'en as pas besoin, inutile de les creer.
Ces fichiers ne sont en aucune facon necessaire au fonctionnement de bash.
mais ~/.bashrc est le SEUL fichier lu en mode intéractif, donc, il m'est
impossible de personnaliser mon environnement (sauf au login). je ne peux que personnaliser celui de root.
Stephane Chazelas wrote:
ben oui... s'ils existent :(
et c'est ma question: pourquoi avec bash-3.0.0, ces fichiers ne sont ni sous
ma home, ni sous celle de root ?
Si tu n'en as pas besoin, inutile de les creer.
Ces fichiers ne sont en aucune facon necessaire au
fonctionnement de bash.
mais ~/.bashrc est le SEUL fichier lu en mode intéractif, donc, il m'est
impossible de personnaliser mon environnement (sauf au login). je ne
peux que personnaliser celui de root.
