Utilisateur de Linux depuis plusieurs années je découvre petit à petit
le monde FreeBSD. Je voudrais tout d'abord saluer le travail fait autour
du handbook qui est assez exceptionnel.
Cela dit, je suis un peu perdu dans gestion des paquets sous ce système.
Je constate qu'il existe plusieurs dépots binaires sur le serveur FTP:
D'après ce j'ai compris, reprenez moi si je me trompe, le suffixe
"-stable" indique que les paquets on été construit avec un version
"-stable" du système. Même chose pour "-release" et "-current".
Ce que j'ignore pour le moment c'est la fréquence à laquelle ces
paquetages sont mis à jour. (Je suppose que "-release" ne bouge jamais,
même pas pour des correctifs touchant à la sécurité du système).
Voici ce que j'envisage de faire pour la première installation du
système. Installer FreeBSD à partir du CD sans installer aucun package.
Installation des "gros" paquets genre Xorg, firefox, etc via le dépot
"packages-6-stable" du FTP. Mis à jour régulière via les ports avec
portmanager. Ma démarche est-elle correcte ?
Samedi 08 décembre 2007 à 22:15 GMT, Michel Talon a écrit :
L'un des endroits les plus scabreux est ce qui se passe quand un port a disparu et a été remplacé par un autre. Portupgrade soit demande à l'opérateur le nom du nouveau port (et il est évident qu'il a 90% de chances de se planter) soit il va chercher la pythie pour inventer ce nom. J'ai déjà vu des cas particulièrement cocasses. Je suis à peu près
Non : portupgrade va lire ports/MOVED et s'en débrouille bien.
Je n'en ai pas un souvenir clair, mais je n'aurais pas pensé que portupgrade se sert de MOVED. Mon pkgupgrade se sert de MOVED et n'a *jamais* besoin de poser des questions à l'opérateur. J'ai par contre le souvenir très clair d'un passage de portupgrade où il recherche comment un port a pu changer de nom en regardant tous les noms et en comptant combien ils ont de caractères en commun. C'est quand il imprime "Guessing ...". Inutile de dire que pour ethereal -> wireshark çane risque pas de marcher.
sûr que dans le cas d'une installation typique de M. Lambda (et non pas d'un développeur FreeBSD comme toi) le pkgdb se trouve rapidement faux dans les grandes largeurs, et donc que pkgupgrade n'a plus qu'une vision fantaisiste des dépendances.
Ça peut arriver si on panache des mises à jours manuelles (make deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
Non, ça ne peut pas arriver si on utilise systématiquement MOVED (comme le fait aussi portmaster). Si ça arrive,etçam'est souvent arrivé, c'est que portupgrade est complètement buggué.
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la version par défaut *et* qu'on n'a pas indiqué quelle version on voulait dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes être un peu long...
Le problème n'est pas que c'est long,c'estque M. Lambda (pas toi) va forcément se planter. Il ne devrait *jamais* y avoir de pkgdb interactif.
En cas de mise à jour de gettext (ou libpng ou n'importe quel port utilisé presque partout), soit la nouvelle version est compatible avec l'ancienne, soit le committer chargé de la migration incrémente les PORTREVISION de tout ce qui doit être réinstallé (ou s'il ne veut pas saturer le CVS il indique juset dans le ports/UPDATING de faire
Et voici le bug gros comme une maison. Il ne devrait *jamais* y avoir à lire UPDATING. Demander aux gens de lire un fichier et de faire des manips manuelles ça veut dire que le système est complètement merdique. Je n'ai jamais vu apt-get me demander de faire des choses spécifiques.
Par chance, on ne fait ce genre de chose qu'en cas de montée de version du système, et dans ces cas là il de toute façon conseillé de mettre à jour *tous* les ports.
Bien d'accord.
--
Michel TALON
Thierry Thomas <tthomas@mail.dotcom.fr> wrote:
Samedi 08 décembre 2007 à 22:15 GMT, Michel Talon a écrit :
L'un des endroits les plus scabreux est ce qui se passe quand un port a
disparu et a été remplacé par un autre. Portupgrade soit demande à
l'opérateur le nom du nouveau port (et il est évident qu'il a 90% de
chances de se planter) soit il va chercher la pythie pour inventer ce
nom. J'ai déjà vu des cas particulièrement cocasses. Je suis à peu près
Non : portupgrade va lire ports/MOVED et s'en débrouille bien.
Je n'en ai pas un souvenir clair, mais je n'aurais pas pensé
que portupgrade se sert de MOVED. Mon pkgupgrade se sert de MOVED et n'a
*jamais* besoin de poser des questions à l'opérateur. J'ai par contre le
souvenir très clair d'un passage de portupgrade où il recherche comment
un port a pu changer de nom en regardant tous les noms et en comptant
combien ils ont de caractères en commun. C'est quand il imprime
"Guessing ...". Inutile de dire que pour ethereal -> wireshark çane
risque pas de marcher.
sûr que dans le cas d'une installation typique de M. Lambda (et non pas
d'un développeur FreeBSD comme toi) le pkgdb se trouve rapidement faux
dans les grandes largeurs, et donc que pkgupgrade n'a plus qu'une vision
fantaisiste des dépendances.
Ça peut arriver si on panache des mises à jours manuelles (make
deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
Non, ça ne peut pas arriver si on utilise systématiquement MOVED (comme
le fait aussi portmaster). Si ça arrive,etçam'est souvent arrivé, c'est
que portupgrade est complètement buggué.
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la
version par défaut *et* qu'on n'a pas indiqué quelle version on voulait
dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là
tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes
être un peu long...
Le problème n'est pas que c'est long,c'estque M. Lambda (pas toi) va
forcément se planter. Il ne devrait *jamais* y avoir de pkgdb
interactif.
En cas de mise à jour de gettext (ou libpng ou n'importe quel port
utilisé presque partout), soit la nouvelle version est compatible avec
l'ancienne, soit le committer chargé de la migration incrémente les
PORTREVISION de tout ce qui doit être réinstallé (ou s'il ne veut pas
saturer le CVS il indique juset dans le ports/UPDATING de faire
Et voici le bug gros comme une maison. Il ne devrait *jamais* y avoir
à lire UPDATING. Demander aux gens de lire un fichier et de faire des
manips manuelles ça veut dire que le système est complètement merdique.
Je n'ai jamais vu apt-get me demander de faire des choses spécifiques.
Par chance, on ne fait ce genre de chose qu'en cas de montée de version
du système, et dans ces cas là il de toute façon conseillé de mettre à
jour *tous* les ports.
Samedi 08 décembre 2007 à 22:15 GMT, Michel Talon a écrit :
L'un des endroits les plus scabreux est ce qui se passe quand un port a disparu et a été remplacé par un autre. Portupgrade soit demande à l'opérateur le nom du nouveau port (et il est évident qu'il a 90% de chances de se planter) soit il va chercher la pythie pour inventer ce nom. J'ai déjà vu des cas particulièrement cocasses. Je suis à peu près
Non : portupgrade va lire ports/MOVED et s'en débrouille bien.
Je n'en ai pas un souvenir clair, mais je n'aurais pas pensé que portupgrade se sert de MOVED. Mon pkgupgrade se sert de MOVED et n'a *jamais* besoin de poser des questions à l'opérateur. J'ai par contre le souvenir très clair d'un passage de portupgrade où il recherche comment un port a pu changer de nom en regardant tous les noms et en comptant combien ils ont de caractères en commun. C'est quand il imprime "Guessing ...". Inutile de dire que pour ethereal -> wireshark çane risque pas de marcher.
sûr que dans le cas d'une installation typique de M. Lambda (et non pas d'un développeur FreeBSD comme toi) le pkgdb se trouve rapidement faux dans les grandes largeurs, et donc que pkgupgrade n'a plus qu'une vision fantaisiste des dépendances.
Ça peut arriver si on panache des mises à jours manuelles (make deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
Non, ça ne peut pas arriver si on utilise systématiquement MOVED (comme le fait aussi portmaster). Si ça arrive,etçam'est souvent arrivé, c'est que portupgrade est complètement buggué.
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la version par défaut *et* qu'on n'a pas indiqué quelle version on voulait dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes être un peu long...
Le problème n'est pas que c'est long,c'estque M. Lambda (pas toi) va forcément se planter. Il ne devrait *jamais* y avoir de pkgdb interactif.
En cas de mise à jour de gettext (ou libpng ou n'importe quel port utilisé presque partout), soit la nouvelle version est compatible avec l'ancienne, soit le committer chargé de la migration incrémente les PORTREVISION de tout ce qui doit être réinstallé (ou s'il ne veut pas saturer le CVS il indique juset dans le ports/UPDATING de faire
Et voici le bug gros comme une maison. Il ne devrait *jamais* y avoir à lire UPDATING. Demander aux gens de lire un fichier et de faire des manips manuelles ça veut dire que le système est complètement merdique. Je n'ai jamais vu apt-get me demander de faire des choses spécifiques.
Par chance, on ne fait ce genre de chose qu'en cas de montée de version du système, et dans ces cas là il de toute façon conseillé de mettre à jour *tous* les ports.
Bien d'accord.
--
Michel TALON
Thierry Thomas
Dimanche 09 décembre 2007 à 10:08 GMT, totof2000 a écrit :
Ça peut arriver si on panache des mises à jours manuelles (make deinstall / reinstall) et des portupgrade, ou dans les cas où il y a plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la version par défaut *et* qu'on n'a pas indiqué quelle version on voulait dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes être un peu long...
C'est l'approche que je n'aime pas trop dans FreeBSD (ou dans Debian). Parfois faut utiliser make deinstall/reinstall ou d'autres il faut utiliser portupgrade (avec dpkg et apt-get pour Debian), et si on utilise pas la bonne commande, on corromp son référentiel.
Je n'ai pas dit qu'il fallait utiliser make deinstall/reinstall, au contraire, si on utilise portupgrade, il est conseillé de s'y tenir. -- Th. Thomas.
Dimanche 09 décembre 2007 à 10:08 GMT, totof2000 a écrit :
Ça peut arriver si on panache des mises à jours manuelles (make
deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la
version par défaut *et* qu'on n'a pas indiqué quelle version on voulait
dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là
tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes
être un peu long...
C'est l'approche que je n'aime pas trop dans FreeBSD (ou dans Debian).
Parfois faut utiliser make deinstall/reinstall ou d'autres il faut
utiliser portupgrade (avec dpkg et apt-get pour Debian), et si on
utilise pas la bonne commande, on corromp son référentiel.
Je n'ai pas dit qu'il fallait utiliser make deinstall/reinstall, au
contraire, si on utilise portupgrade, il est conseillé de s'y tenir.
--
Th. Thomas.
Dimanche 09 décembre 2007 à 10:08 GMT, totof2000 a écrit :
Ça peut arriver si on panache des mises à jours manuelles (make deinstall / reinstall) et des portupgrade, ou dans les cas où il y a plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la version par défaut *et* qu'on n'a pas indiqué quelle version on voulait dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes être un peu long...
C'est l'approche que je n'aime pas trop dans FreeBSD (ou dans Debian). Parfois faut utiliser make deinstall/reinstall ou d'autres il faut utiliser portupgrade (avec dpkg et apt-get pour Debian), et si on utilise pas la bonne commande, on corromp son référentiel.
Je n'ai pas dit qu'il fallait utiliser make deinstall/reinstall, au contraire, si on utilise portupgrade, il est conseillé de s'y tenir. -- Th. Thomas.
talon
Xavier wrote:
Michel Talon wrote:
Et voici le bug gros comme une maison. Il ne devrait *jamais* y avoir à lire UPDATING. Demander aux gens de lire un fichier et de faire des manips manuelles ça veut dire que le système est complètement merdique. Je n'ai jamais vu apt-get me demander de faire des choses spécifiques.
Sepuis le temps que je te lis ici, et ne le prends pas comme une agression personnell, pourquoi continues-tu à utiliser FreeBSD ? Linux se débrouille très bien dans le calcul scientifique, et la clusterisation est même en avance sur celle de FreeBSD...
Il est marrant ton argument. Il vaut bien celui des 95% des gens qui disent, pourquoi s'emmerder à utiliser Linux quand Windows marche très bien. Même si ça ne te plaît pas, il y a un problème évident dans FreeBSD au niveau de la *mise à jour* (*) des ports. FreeBSD est un bon système, donc il gagnerait à résoudre ce problème. Ce n'est pas en mettant la tête dans le sable et en prétendant que le problème n'existe pas que les choses iront mieux. En ce qui concerne OpenBSD, Marc Espie a eu le courage de dire "le système actuel ne fonctionne pas correctement" il avait parfaitement raison, et il a tout repris de fond en comble. A l'entendre, maintenant ça marche.
Je n'utilise pas FreeBSD pour du calcul scientifique, les machines du labo sont sous Fedora (et ce n'est pas moi qui ai choisi ...). La clusterisation n'y est d'ailleurs pas utilisée (si ce n'est de façon complètement triviale).
(*) L'installation, elle, ne pose pas de problème. Malheureusement le standard pour les mises à jour est Debian, et il est beaucoup plus haut que celui de FreeBSD.
--
Michel TALON
Xavier <xavier@groumpf.org> wrote:
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Et voici le bug gros comme une maison. Il ne devrait *jamais* y avoir
à lire UPDATING. Demander aux gens de lire un fichier et de faire des
manips manuelles ça veut dire que le système est complètement merdique.
Je n'ai jamais vu apt-get me demander de faire des choses spécifiques.
Sepuis le temps que je te lis ici, et ne le prends pas comme une
agression personnell, pourquoi continues-tu à utiliser FreeBSD ? Linux
se débrouille très bien dans le calcul scientifique, et la
clusterisation est même en avance sur celle de FreeBSD...
Il est marrant ton argument. Il vaut bien celui des 95% des gens qui
disent, pourquoi s'emmerder à utiliser Linux quand Windows marche très
bien. Même si ça ne te plaît pas, il y a un problème évident dans
FreeBSD au niveau de la *mise à jour* (*) des ports. FreeBSD est un bon
système, donc il gagnerait à résoudre ce problème. Ce n'est pas en
mettant la tête dans le sable et en prétendant que le problème n'existe
pas que les choses iront mieux. En ce qui concerne OpenBSD, Marc Espie
a eu le courage de dire "le système actuel ne fonctionne pas correctement"
il avait parfaitement raison, et il a tout repris de fond en comble. A
l'entendre, maintenant ça marche.
Je n'utilise pas FreeBSD pour du calcul scientifique, les machines du
labo sont sous Fedora (et ce n'est pas moi qui ai choisi ...). La
clusterisation n'y est d'ailleurs pas utilisée (si ce n'est de façon
complètement triviale).
(*) L'installation, elle, ne pose pas de problème. Malheureusement le
standard pour les mises à jour est Debian, et il est beaucoup plus haut
que celui de FreeBSD.
Et voici le bug gros comme une maison. Il ne devrait *jamais* y avoir à lire UPDATING. Demander aux gens de lire un fichier et de faire des manips manuelles ça veut dire que le système est complètement merdique. Je n'ai jamais vu apt-get me demander de faire des choses spécifiques.
Sepuis le temps que je te lis ici, et ne le prends pas comme une agression personnell, pourquoi continues-tu à utiliser FreeBSD ? Linux se débrouille très bien dans le calcul scientifique, et la clusterisation est même en avance sur celle de FreeBSD...
Il est marrant ton argument. Il vaut bien celui des 95% des gens qui disent, pourquoi s'emmerder à utiliser Linux quand Windows marche très bien. Même si ça ne te plaît pas, il y a un problème évident dans FreeBSD au niveau de la *mise à jour* (*) des ports. FreeBSD est un bon système, donc il gagnerait à résoudre ce problème. Ce n'est pas en mettant la tête dans le sable et en prétendant que le problème n'existe pas que les choses iront mieux. En ce qui concerne OpenBSD, Marc Espie a eu le courage de dire "le système actuel ne fonctionne pas correctement" il avait parfaitement raison, et il a tout repris de fond en comble. A l'entendre, maintenant ça marche.
Je n'utilise pas FreeBSD pour du calcul scientifique, les machines du labo sont sous Fedora (et ce n'est pas moi qui ai choisi ...). La clusterisation n'y est d'ailleurs pas utilisée (si ce n'est de façon complètement triviale).
(*) L'installation, elle, ne pose pas de problème. Malheureusement le standard pour les mises à jour est Debian, et il est beaucoup plus haut que celui de FreeBSD.
--
Michel TALON
talon
Xavier wrote:
Thierry Thomas wrote:
Non : portupgrade va lire ports/MOVED et s'en débrouille bien. [...]
pkgtools.conf. Mais il me semble que dans ces cas là tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes être un peu long...
Je confirme, ça fait une demi-douzaine d'années que je fais comme ça -sur des serveurs, certes, mais aussi une station- sans *jamais* aucun souci.
Portupgrade date de 2001, je ne te crois pas une seconde quand tu dis que tu n'as *jamais* eu aucun souci de 2001 à 2007. Il y a tous les soucis que tu as eus et oubliés. Pendant au moins la moitié de ce temps portupgrade était buggué comme l'enfer. Maintenant il est probablement plus fiable (encore que je sais pertinemment qu'il est suceptible de causer des problèmes), mais une chose certaine est qu'il est d'une lenteur encore plus infernale, et en conséquence inutilisable par les gens qui ont autre chose à faire que passer leur vie à le contempler. Ce n'est quand même pas pour rien que D. Barton s'est mis à développer portmaster. Et je ne parle même pas des problèmes intrinsèques à portupgrade qui se posent chaque fois qu'il y a un upgrade soit de ruby, soit de la base de données soit du connecteur, et qui mènent immanquablement à des problèmes sévères. Je ne parle pas du fait que, contrairement à apt-get, il est impossible de savoir à l'avance qu'est-ce qui va être upgradé et comment quand on lance portupgrade, et donc faire un choix informé sur l'opportunité dudit upgrade. Ni du fait que si l'upgrade rate en plein milieu parcequ'un port ne se construit pas, tu es baisé jusqu'au trognon, à moins de te lancer dans de la chirurgie sur les Makefile, chose qui m'est arrivée des *dizaines* de fois.
--
Michel TALON
Xavier <xavier@groumpf.org> wrote:
Thierry Thomas <tthomas@mail.dotcom.fr> wrote:
Non : portupgrade va lire ports/MOVED et s'en débrouille bien.
[...]
pkgtools.conf. Mais il me semble que dans ces cas là
tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes
être un peu long...
Je confirme, ça fait une demi-douzaine d'années que je fais comme ça
-sur des serveurs, certes, mais aussi une station- sans *jamais* aucun
souci.
Portupgrade date de 2001, je ne te crois pas une seconde quand tu dis
que tu n'as *jamais* eu aucun souci de 2001 à 2007. Il y a tous les soucis
que tu as eus et oubliés. Pendant au moins la moitié de ce temps
portupgrade était buggué comme l'enfer. Maintenant il est probablement
plus fiable (encore que je sais pertinemment qu'il est suceptible de
causer des problèmes), mais une chose certaine est qu'il est d'une lenteur
encore plus infernale, et en conséquence inutilisable par les gens qui
ont autre chose à faire que passer leur vie à le contempler. Ce n'est
quand même pas pour rien que D. Barton s'est mis à développer
portmaster. Et je ne parle même pas des problèmes intrinsèques à
portupgrade qui se posent chaque fois qu'il y a un upgrade soit de ruby,
soit de la base de données soit du connecteur, et qui mènent
immanquablement à des problèmes sévères. Je ne parle pas du fait que,
contrairement à apt-get, il est impossible de savoir à l'avance
qu'est-ce qui va être upgradé et comment quand on lance portupgrade, et
donc faire un choix informé sur l'opportunité dudit upgrade. Ni du fait
que si l'upgrade rate en plein milieu parcequ'un port ne se construit
pas, tu es baisé jusqu'au trognon, à moins de te lancer dans de
la chirurgie sur les Makefile, chose qui m'est arrivée des *dizaines*
de fois.
Non : portupgrade va lire ports/MOVED et s'en débrouille bien. [...]
pkgtools.conf. Mais il me semble que dans ces cas là tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes être un peu long...
Je confirme, ça fait une demi-douzaine d'années que je fais comme ça -sur des serveurs, certes, mais aussi une station- sans *jamais* aucun souci.
Portupgrade date de 2001, je ne te crois pas une seconde quand tu dis que tu n'as *jamais* eu aucun souci de 2001 à 2007. Il y a tous les soucis que tu as eus et oubliés. Pendant au moins la moitié de ce temps portupgrade était buggué comme l'enfer. Maintenant il est probablement plus fiable (encore que je sais pertinemment qu'il est suceptible de causer des problèmes), mais une chose certaine est qu'il est d'une lenteur encore plus infernale, et en conséquence inutilisable par les gens qui ont autre chose à faire que passer leur vie à le contempler. Ce n'est quand même pas pour rien que D. Barton s'est mis à développer portmaster. Et je ne parle même pas des problèmes intrinsèques à portupgrade qui se posent chaque fois qu'il y a un upgrade soit de ruby, soit de la base de données soit du connecteur, et qui mènent immanquablement à des problèmes sévères. Je ne parle pas du fait que, contrairement à apt-get, il est impossible de savoir à l'avance qu'est-ce qui va être upgradé et comment quand on lance portupgrade, et donc faire un choix informé sur l'opportunité dudit upgrade. Ni du fait que si l'upgrade rate en plein milieu parcequ'un port ne se construit pas, tu es baisé jusqu'au trognon, à moins de te lancer dans de la chirurgie sur les Makefile, chose qui m'est arrivée des *dizaines* de fois.
--
Michel TALON
Ollivier Robert
Dans l'article <fjdo0q$dok$, Michel Talon disait :
Pareil pour moi. Je ne me sens pas une âme à recompiler tous mes ports tous les jours comme les maniaques de portupgrade ou portmaster. Donc
Évidemment, ça ne sert à rien de recompiler ou mettre à jour en permanence les ports, a fortiori sur un système en production. Que certains veuillent le faire et que le système le permette est important par contre.
j'attends la sortie de 7.0 pour tout réinstaller en bloc avec les binaires de la release. C'est de loin la solution la plus fiable et qui fait perdre le moins de temps.
En conclusion, les systèmes Debian-like sont à des années lumière en avant des *BSD en ce qui concerne la facilité de mise à jour ( excepté peut être OpenBSD, mais là la pauvreté de l'offre de ports est tellement évidente que ça fait presque pleurer).
Je voudrais quand même signaler à tout le monde l'existence -- bien cachée malheureusement -- de freebsd-update, disponible dans /usr/sbin sur un 6 récent (évidemment dans 7.0 et 8-CURRENT), ça permet facilement la mise à jour du système à la « apt-get upgrade ».
Je viens de m'y mettre très récemment pour faire des mises à jour de machines distantes pour passer de branche 6 en branche 7 et bien c'est impressionant de facilité.
J'encourage donc les freebsd-istes à le regarder et l'utiliser.
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <fjdo0q$dok$2@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :
Pareil pour moi. Je ne me sens pas une âme à recompiler tous mes ports
tous les jours comme les maniaques de portupgrade ou portmaster. Donc
Évidemment, ça ne sert à rien de recompiler ou mettre à jour en permanence les
ports, a fortiori sur un système en production. Que certains veuillent le
faire et que le système le permette est important par contre.
j'attends la sortie de 7.0 pour tout réinstaller en bloc avec les
binaires de la release. C'est de loin la solution la plus fiable et
qui fait perdre le moins de temps.
En conclusion, les systèmes Debian-like sont à des années lumière en
avant des *BSD en ce qui concerne la facilité de mise à jour (
excepté peut être OpenBSD, mais là la pauvreté de l'offre de ports est
tellement évidente que ça fait presque pleurer).
Je voudrais quand même signaler à tout le monde l'existence -- bien cachée
malheureusement -- de freebsd-update, disponible dans /usr/sbin sur un 6
récent (évidemment dans 7.0 et 8-CURRENT), ça permet facilement la mise à jour
du système à la « apt-get upgrade ».
Je viens de m'y mettre très récemment pour faire des mises à jour de machines
distantes pour passer de branche 6 en branche 7 et bien c'est impressionant de
facilité.
J'encourage donc les freebsd-istes à le regarder et l'utiliser.
Dans l'article <fjdo0q$dok$, Michel Talon disait :
Pareil pour moi. Je ne me sens pas une âme à recompiler tous mes ports tous les jours comme les maniaques de portupgrade ou portmaster. Donc
Évidemment, ça ne sert à rien de recompiler ou mettre à jour en permanence les ports, a fortiori sur un système en production. Que certains veuillent le faire et que le système le permette est important par contre.
j'attends la sortie de 7.0 pour tout réinstaller en bloc avec les binaires de la release. C'est de loin la solution la plus fiable et qui fait perdre le moins de temps.
En conclusion, les systèmes Debian-like sont à des années lumière en avant des *BSD en ce qui concerne la facilité de mise à jour ( excepté peut être OpenBSD, mais là la pauvreté de l'offre de ports est tellement évidente que ça fait presque pleurer).
Je voudrais quand même signaler à tout le monde l'existence -- bien cachée malheureusement -- de freebsd-update, disponible dans /usr/sbin sur un 6 récent (évidemment dans 7.0 et 8-CURRENT), ça permet facilement la mise à jour du système à la « apt-get upgrade ».
Je viens de m'y mettre très récemment pour faire des mises à jour de machines distantes pour passer de branche 6 en branche 7 et bien c'est impressionant de facilité.
J'encourage donc les freebsd-istes à le regarder et l'utiliser.
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
TeXitoi
(Marc Espie) writes:
- quelles sont les appli que tu utilises qui ne sont pas dans nos (bientot) 5000 packages ?
La question n'était pas pour moi, mais bon, ca coute rien d'y répondre : - gutenprint (dans -current et 4.3 o/) - rxvt-unicode (http://software.schmorp.de/pkg/rxvt-unicode.html) - OUnit (bibliothèque de tests pour OCaml, mais bon, ca commence à être exotique, là ;-) http://www.xs4all.nl/~mmzeeman/ocaml/) - shell-fm (http://nex.scrapping.cc/shell-fm/) - tuareg-mode (mode emacs pour OCaml http://www-rocq.inria.fr/~acohen/tuareg/) - Quarry (un editeur sgf en GTK http://home.gna.org/quarry/) - midori (mais là, j'abuse un peu... http://software.twotoasts.de/?page=midori)
Finalement, ça fait pas grand chose.
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable, c'est le non support de WPA et la gestion des umass propre en user space (genre à la pmount, mais j'ai pas trop cherché pour ce second point).
``Computers are good at following instructions, but not at reading your mind.'' -- Donald E. Knuth, the TeXbook
() ASCII ribbon campaign -- Against HTML e-mail / http://www.asciiribbon.org -- Against proprietary attachments
espie@lain.home (Marc Espie) writes:
- quelles sont les appli que tu utilises qui ne sont pas dans nos (bientot)
5000 packages ?
La question n'était pas pour moi, mais bon, ca coute rien d'y
répondre :
- gutenprint (dans -current et 4.3 o/)
- rxvt-unicode (http://software.schmorp.de/pkg/rxvt-unicode.html)
- OUnit (bibliothèque de tests pour OCaml, mais bon, ca commence à
être exotique, là ;-) http://www.xs4all.nl/~mmzeeman/ocaml/)
- shell-fm (http://nex.scrapping.cc/shell-fm/)
- tuareg-mode (mode emacs pour OCaml
http://www-rocq.inria.fr/~acohen/tuareg/)
- Quarry (un editeur sgf en GTK http://home.gna.org/quarry/)
- midori (mais là, j'abuse un peu...
http://software.twotoasts.de/?page=midori)
Finalement, ça fait pas grand chose.
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable,
c'est le non support de WPA et la gestion des umass propre en user
space (genre à la pmount, mais j'ai pas trop cherché pour ce second
point).
- quelles sont les appli que tu utilises qui ne sont pas dans nos (bientot) 5000 packages ?
La question n'était pas pour moi, mais bon, ca coute rien d'y répondre : - gutenprint (dans -current et 4.3 o/) - rxvt-unicode (http://software.schmorp.de/pkg/rxvt-unicode.html) - OUnit (bibliothèque de tests pour OCaml, mais bon, ca commence à être exotique, là ;-) http://www.xs4all.nl/~mmzeeman/ocaml/) - shell-fm (http://nex.scrapping.cc/shell-fm/) - tuareg-mode (mode emacs pour OCaml http://www-rocq.inria.fr/~acohen/tuareg/) - Quarry (un editeur sgf en GTK http://home.gna.org/quarry/) - midori (mais là, j'abuse un peu... http://software.twotoasts.de/?page=midori)
Finalement, ça fait pas grand chose.
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable, c'est le non support de WPA et la gestion des umass propre en user space (genre à la pmount, mais j'ai pas trop cherché pour ce second point).
``Computers are good at following instructions, but not at reading your mind.'' -- Donald E. Knuth, the TeXbook
() ASCII ribbon campaign -- Against HTML e-mail / http://www.asciiribbon.org -- Against proprietary attachments
espie
In article , TeXitoi wrote:
- rxvt-unicode (http://software.schmorp.de/pkg/rxvt-unicode.html) Ca je verrai.
- OUnit (bibliothèque de tests pour OCaml, mais bon, ca commence à être exotique, là ;-) http://www.xs4all.nl/~mmzeeman/ocaml/) Peu de chance que j'ai le temps de tester.
- shell-fm (http://nex.scrapping.cc/shell-fm/) Ca devrait pas etre TRES dur a porter, ca... on a toutes les dependances.
- tuareg-mode (mode emacs pour OCaml http://www-rocq.inria.fr/~acohen/tuareg/) Ca, se sera pas moi... vim uniquement ;-)
- Quarry (un editeur sgf en GTK http://home.gna.org/quarry/) Ca pourrait etre marrant ca...
- midori (mais là, j'abuse un peu... http://software.twotoasts.de/?page=midori) Oui, t'abuse un peu... c'est quand meme marque en alpha sur leur page.
Ca marche et c'est utilisable ?
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable, c'est le non support de WPA Je sais qu'on a des gens qui bossent sur wpa, je sais pas ou ca en est...
et la gestion des umass propre en user space (genre à la pmount, mais j'ai pas trop cherché pour ce second >point).
Ca, je sais pas trop bien ce qu'on pourrait faire la-dessus... faudra voir. C'est certainement complique cote securite.
In article <8763z6x1vg.fsf@epiano.appart>,
TeXitoi <texitoiNO@SPAMtexitoi.homelinux.org.invalid> wrote:
- rxvt-unicode (http://software.schmorp.de/pkg/rxvt-unicode.html)
Ca je verrai.
- OUnit (bibliothèque de tests pour OCaml, mais bon, ca commence à
être exotique, là ;-) http://www.xs4all.nl/~mmzeeman/ocaml/)
Peu de chance que j'ai le temps de tester.
- shell-fm (http://nex.scrapping.cc/shell-fm/)
Ca devrait pas etre TRES dur a porter, ca... on a toutes les dependances.
- tuareg-mode (mode emacs pour OCaml
http://www-rocq.inria.fr/~acohen/tuareg/)
Ca, se sera pas moi... vim uniquement ;-)
- Quarry (un editeur sgf en GTK http://home.gna.org/quarry/)
Ca pourrait etre marrant ca...
- midori (mais là, j'abuse un peu...
http://software.twotoasts.de/?page=midori)
Oui, t'abuse un peu... c'est quand meme marque en alpha sur leur page.
Ca marche et c'est utilisable ?
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable,
c'est le non support de WPA
Je sais qu'on a des gens qui bossent sur wpa, je sais pas ou ca en est...
et la gestion des umass propre en user space (genre à la pmount, mais
j'ai pas trop cherché pour ce second >point).
Ca, je sais pas trop bien ce qu'on pourrait faire la-dessus... faudra
voir. C'est certainement complique cote securite.
- rxvt-unicode (http://software.schmorp.de/pkg/rxvt-unicode.html) Ca je verrai.
- OUnit (bibliothèque de tests pour OCaml, mais bon, ca commence à être exotique, là ;-) http://www.xs4all.nl/~mmzeeman/ocaml/) Peu de chance que j'ai le temps de tester.
- shell-fm (http://nex.scrapping.cc/shell-fm/) Ca devrait pas etre TRES dur a porter, ca... on a toutes les dependances.
- tuareg-mode (mode emacs pour OCaml http://www-rocq.inria.fr/~acohen/tuareg/) Ca, se sera pas moi... vim uniquement ;-)
- Quarry (un editeur sgf en GTK http://home.gna.org/quarry/) Ca pourrait etre marrant ca...
- midori (mais là, j'abuse un peu... http://software.twotoasts.de/?page=midori) Oui, t'abuse un peu... c'est quand meme marque en alpha sur leur page.
Ca marche et c'est utilisable ?
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable, c'est le non support de WPA Je sais qu'on a des gens qui bossent sur wpa, je sais pas ou ca en est...
et la gestion des umass propre en user space (genre à la pmount, mais j'ai pas trop cherché pour ce second >point).
Ca, je sais pas trop bien ce qu'on pourrait faire la-dessus... faudra voir. C'est certainement complique cote securite.
Benoit Izac
Bonjour,
le 10/12/2007 à 18:23, Marc Espie a écrit dans le message <fjjsn0$10ds$ :
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable, c'est le non support de WPA
+1
Je sais qu'on a des gens qui bossent sur wpa, je sais pas ou ca en est...
Puisqu'on est dans les doléances, à quand un support des locales ?
-- Benoit Izac
Bonjour,
le 10/12/2007 à 18:23, Marc Espie a écrit dans le message
<fjjsn0$10ds$1@biggoron.nerim.net> :
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable,
c'est le non support de WPA
+1
Je sais qu'on a des gens qui bossent sur wpa, je sais pas ou ca en
est...
Puisqu'on est dans les doléances, à quand un support des locales ?
le 10/12/2007 à 18:23, Marc Espie a écrit dans le message <fjjsn0$10ds$ :
Mais ce qui m'empêche vraiment de passer à OpenBSD sur mon portable, c'est le non support de WPA
+1
Je sais qu'on a des gens qui bossent sur wpa, je sais pas ou ca en est...
Puisqu'on est dans les doléances, à quand un support des locales ?
Un support *complet* tu veux dire... parce qu'on a deja un support partiel, hein. meme si c'est pas forcement apparent.
Ca depend en grande partie du temps dont je dispose pour continuer le debut de boulot...
Benoit Izac
Bonjour,
le 10/12/2007 à 20:40, Marc Espie a écrit dans le message <fjk4ml$13e8$ :
Puisqu'on est dans les doléances, à quand un support des locales ?
Un support *complet* tu veux dire... parce qu'on a deja un support partiel, hein. meme si c'est pas forcement apparent.
La première commande me venant à l'esprit est locale(1) qui n'existe pas. Quand tu parles de support partiel, tu veux dire qu'un « LC_COLLATE=fr_FR.ISO8859-15 sort un_fichier_avec_des_accents » ou un « echo "à" | LC_TYPE=fr_FR.ISO8859-15 grep '[[:alpha:]] » fonctionnent comme attendu ?
-- Benoit Izac
Bonjour,
le 10/12/2007 à 20:40, Marc Espie a écrit dans le message
<fjk4ml$13e8$1@biggoron.nerim.net> :
Puisqu'on est dans les doléances, à quand un support des locales ?
Un support *complet* tu veux dire... parce qu'on a deja un support
partiel, hein. meme si c'est pas forcement apparent.
La première commande me venant à l'esprit est locale(1) qui n'existe
pas. Quand tu parles de support partiel, tu veux dire qu'un
« LC_COLLATE=fr_FR.ISO8859-15 sort un_fichier_avec_des_accents »
ou un « echo "à" | LC_TYPE=fr_FR.ISO8859-15 grep '[[:alpha:]] »
fonctionnent comme attendu ?
le 10/12/2007 à 20:40, Marc Espie a écrit dans le message <fjk4ml$13e8$ :
Puisqu'on est dans les doléances, à quand un support des locales ?
Un support *complet* tu veux dire... parce qu'on a deja un support partiel, hein. meme si c'est pas forcement apparent.
La première commande me venant à l'esprit est locale(1) qui n'existe pas. Quand tu parles de support partiel, tu veux dire qu'un « LC_COLLATE=fr_FR.ISO8859-15 sort un_fichier_avec_des_accents » ou un « echo "à" | LC_TYPE=fr_FR.ISO8859-15 grep '[[:alpha:]] » fonctionnent comme attendu ?
