Linuxien depuis quelques années, j'éprouve de plus en plus l'envie de
changer de système.
Les systèmes basés BSD me semblent être l'alternative la plus crédible à mes
yeux (non, non, je n'ai pas envie de retourner sous Windows).
Cependant, avant de me lancer dans l'aventure BSD, j'aimerais connaître la
liste des principales "distributions" BSD (c'est comme ça qu'on dit ?) et
leurs différences essentielles.
Un lien pourrait suffire, une explication serait au top (je n'ai pas besoin
de détails précis sur les différentes fonctionalités)
Pour information, bien que je sois assez à l'aise en ligne de commande j'ai
encore besoin d'une interface graphique pour certains de mes besoins
(multimedia, internet) et détail important, j'ai une carte video NVidia
(quadro).
Autres questions plus ou moins stupides/naïves en vrac :
- Peut on trouver une liste des matériels incompatibles ?
- Selon vous, quels sont les avantages évident des systèmes BSD sur Linux
(et l'inverse)
- Compile t-on son noyau sous BSD ?
- Quelqu'un a t-il une liste de sites à visiter (tutoriels d'installation,
conseils aux novices...) avant de franchir le pas ?
- J'en passe et des meilleures....
Dans l'attente de vos réponses endiablées, je vous souhaite une bonne
[ ] journée.
[ ] soirée.
[ ] nuit.
(cocher la mention correspondant à votre situation)
Merci d'avance et à bientôt sous BSD.
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le Mon, 30 May 2005 11:08:27 +0000 (UTC), Marwan Burelle a écrit:
In article , Hubert wrote:
Pour un simple recensement : http://www.frbsd.org/fr/liens/systemes.html
C'est dommage de ne pas mettre ceux qui sont dérivés de 4.2BSD, il
Mon intention était surtout de montrer la généalogie des BSD depuis leur portage sur architecture x86 (et j'en ai d'ailleurs sans doute oublié !).
Pour les choses plus anciennes, Eric Levenez avait déjà parfaitement couvert le sujet.
manque au moins AmigaOS, NeXTStep (enfin l'OS des NeXT, je me souviens jamais de son nom) et SunOS ... (d'ailleurs dans ces 3 là je ne suis pas sûr qu'ils soient tous dérivés de 4.2BSD ... )
Dans le cas de NextStep, il me semble vaguement me souvenir de l'existence d''un portage sur x86, mais je n'en suis plus très sur.
Bien cordialement,
Bonjour,
Le Mon, 30 May 2005 11:08:27 +0000 (UTC), Marwan Burelle
<burelle@lri.fr> a écrit:
In article <485f91h9bdt0vnra0e78e7988h046j3s9k@4ax.com>, Hubert wrote:
Pour un simple recensement :
http://www.frbsd.org/fr/liens/systemes.html
C'est dommage de ne pas mettre ceux qui sont dérivés de 4.2BSD, il
Mon intention était surtout de montrer la généalogie des BSD depuis
leur portage sur architecture x86 (et j'en ai d'ailleurs sans doute
oublié !).
Pour les choses plus anciennes, Eric Levenez avait déjà parfaitement
couvert le sujet.
manque au moins AmigaOS, NeXTStep (enfin l'OS des NeXT, je me souviens jamais
de son nom) et SunOS ... (d'ailleurs dans ces 3 là je ne suis pas sûr
qu'ils soient tous dérivés de 4.2BSD ... )
Dans le cas de NextStep, il me semble vaguement me souvenir de
l'existence d''un portage sur x86, mais je n'en suis plus très sur.
Le Mon, 30 May 2005 11:08:27 +0000 (UTC), Marwan Burelle a écrit:
In article , Hubert wrote:
Pour un simple recensement : http://www.frbsd.org/fr/liens/systemes.html
C'est dommage de ne pas mettre ceux qui sont dérivés de 4.2BSD, il
Mon intention était surtout de montrer la généalogie des BSD depuis leur portage sur architecture x86 (et j'en ai d'ailleurs sans doute oublié !).
Pour les choses plus anciennes, Eric Levenez avait déjà parfaitement couvert le sujet.
manque au moins AmigaOS, NeXTStep (enfin l'OS des NeXT, je me souviens jamais de son nom) et SunOS ... (d'ailleurs dans ces 3 là je ne suis pas sûr qu'ils soient tous dérivés de 4.2BSD ... )
Dans le cas de NextStep, il me semble vaguement me souvenir de l'existence d''un portage sur x86, mais je n'en suis plus très sur.
Bien cordialement,
Hubert
Bonjour,
Le Mon, 30 May 2005 14:16:35 +0200, (Xavier) a écrit:
Marwan Burelle wrote:
http://www.frbsd.org/fr/liens/systemes.html C'est dommage de ne pas mettre ceux qui sont dérivés de 4.2BSD,
Pour être exhaustif, consulter <http://www.levenez.com/unix/> et ne
garder que la "bonne" branche.
Les deux sont (étaient ?) plutôt complémentaires, puisque j'avais notamment complété le travail d'Eric sur les "distributions" BSD.
Bien cordialement,
Bonjour,
Le Mon, 30 May 2005 14:16:35 +0200, xavier@groumpf.org (Xavier) a
écrit:
Marwan Burelle <burelle@lri.fr> wrote:
http://www.frbsd.org/fr/liens/systemes.html
C'est dommage de ne pas mettre ceux qui sont dérivés de 4.2BSD,
Pour être exhaustif, consulter <http://www.levenez.com/unix/> et ne
garder que la "bonne" branche.
Les deux sont (étaient ?) plutôt complémentaires, puisque j'avais
notamment complété le travail d'Eric sur les "distributions" BSD.
Dans le cas de NextStep, il me semble vaguement me souvenir de l'existence d''un portage sur x86, mais je n'en suis plus très sur.
NeXTstep a été disponible pour NeXT, x86, sparc et pa-risc.
Laurent Lefevre
Jogo writes:
< plop linux >
charge CPU ne depassait pas 0.4. Les images disques utilisent la capacité de linux à avoir des fichiers à trous, donc n'occupent pas sur le disque physique la taille qu'ils prétendent. Tu peux aussi utiliser des disques réels (fais gaffe quand même).
Ah ? et c'est quoi des fichiers à trous ? Linux en est encore aux cartes perforées ?
-- Laurent
Jogo <jogo@alussinan.org> writes:
< plop linux >
charge CPU ne depassait pas 0.4. Les images disques utilisent la capacité
de linux à avoir des fichiers à trous, donc n'occupent pas sur le disque
physique la taille qu'ils prétendent. Tu peux aussi utiliser des disques
réels (fais gaffe quand même).
Ah ? et c'est quoi des fichiers à trous ? Linux en est encore aux cartes
perforées ?
charge CPU ne depassait pas 0.4. Les images disques utilisent la capacité de linux à avoir des fichiers à trous, donc n'occupent pas sur le disque physique la taille qu'ils prétendent. Tu peux aussi utiliser des disques réels (fais gaffe quand même).
Ah ? et c'est quoi des fichiers à trous ? Linux en est encore aux cartes perforées ?
-- Laurent
Marwan Burelle
In article <d7fe2j$1c9k$, Michel Talon wrote:
Tu m'apprends une nouvelle. "De mon temps" les ports n'étaient pas branchés et tu avais un CURRENT permanent. Il va falloir que je regarde de ce coté là, car à la fin du port freeze et bien avant la publication de la RELEASE les porteurs s'empressent de décharger tous leurs machins en attente, si bien qu'un cvsup au moment de la RELEASE ne te met pas du tout dans un état approprié pour télécharger un maximum de binaires pré compilés.
Il n'y a pas vraiment de branche, mais un tag sur la branche principale pour chaque release (sinon, le dégel des ports n'aurait pas lieu avant la release ... )
Donc tu peux mettre RELEASE_5_4_0 comme tag dans ton supfile si tu veux les ports de la release 5.4. Effectivement ces ports n'évoluent pas (contrairement aux branches RELENG_X_Y), mais ça évite de se coltiner les mouvements post-release ...
Ecoutes, quand Matt Dillon prétendait que le système des ports déconnait complètement et qu'il fallait le reprendre entièrement, je croyais qu'il exagérait, et c'était une époque où je ne voyais pas de problème. Or tu conviendras que Matt est beaucoup plus compétent que toi et moi, et que s'il avait des problèmes, il fallait bien qu'ils viennent de quelque part. La réponse standard quand un truc ne marche pas, c'est de dire que c'est la faute de l'utilisateur qui est incompétent, le résultat c'est qu'on perd peu à peu ses utilisateurs.
Tu as suivie ce que je dis ? je parle d'erreur issue de l'utilisateur mais pas uniquement. Regarde un peu le chaînage des dépendances de la moindre application orientée workstation, à part les applications relativement anciennes qui sont restées avec le même profile de développement, chaque appli dépend d'une quantité affolante de libs et d'autres programmes (et ceux indépendamment des ports) or, ces fameuses libs bougent relativement vite elle même, avec des changements d'API réguliers impliquant à chaque mise à jour une recompilation totale de pas mal d'autres ports (qui à leur tour ... )
Alors soit, peut être que le système des ports n'est plus aussi bien adapté, mais la faute ne vient pas forcément d'eux. Portupgrade était une tentative de réponse à ce problème, pas l'origine du problème. Si la solution ne te plais pas, ben essaie d'avoir un raisonnement constructif, au lieu de crier sur les autres.
Moi ce que je te dis, c'est que pour avoir utilisé FreeBSD-2.2.5 et depuis, il n'y avait *jamais* de problème. On faisait un cvsup, puis un make install dans un port et ça marchait toujours.
Oui et moi, il y a 5 ou 6 ans, j'installais pas mal de chose sur la partoche NFS que l'admin nous laissait (pour que les étudiants aient leurs applis sans l'emmmerder) et tout se passait sans problème, sans être root. Seulement, pour 10 ou 15 applications j'installais parfois une lib et encore (le plus souvent c'était pour faire tourner les applis installer pour les linux sur les solaris/hp-ux qui n'avaient pas la même base d'installée.) Je faisais tout ça sans port, sans package, et les problèmes de dépendance ne se posaient pas comme ils se posent aujourd'hui.
Donc essaies de comparer les choses comparables.
Depuis que quelques gros malins se sont mis à gérer ça en finesse, il y a constamment des problèmes. Je suis désolé, mais à chaque release il y a une floppée de ports dont le binaire n'existe pas, non pas du tout pour des raisons de licence (comme java) mais tout simplement parceque le port est cassé.
As tu regardé pourquoi ces ports étaient cassés ? Peux tu dire que systématiquement cela vient de la gestion des ports ? Soit, un port cassé parce que son plist est incomplet ça paraît être un comportement excessif, malheureusement, poses toi la question des conséquences sur le processus de construction des packages ...
Donc venir dire que c'est la faute des fausses manoeuvres de l'utilisateur, c'est se défausser grossièrement de la réalité. Quand j'ai installé la 5.3 il m'a fallu touiller les Makefile de je ne sais combien de ports pour arriver à les compiler. C'était une installation fraîche donc ça ne dépendait en rien de moi. Et il ne s'agit pas de quoi que ce soit d'exotique, il y avait par exemple qdvdauthor et toutes ses dépendances. Je me souviens avoir passé un bon moment sur ça. Et beaucoup d'autres choses. L'exemple que j'ai cité avec azureus, je ne l'ai pas sorti de mon imagination, il est réél. Dans la situation merdique actuelle de l'arbre des ports je n'ose plus toucher à quoi que ce soit, je vais encore être obligé de tout virer et tout réinstaller à partir des binaires.
Ce que j'aimerais comprendre c'est pourquoi ça marche pour les autres et pas pour toi ? J'ai installé plusieurs 5.1, 5.2 et 5.3 sans avoir à modifier des makefiles, j'ai fait des upgrades sur les ports installés sur ces machines sans problème particulier, les seules manips compliquées étaient liées aux upgrades de gnome (qui nécessite systématiquement une recompilation complète de l'ensemble des dépendances ... ), de teTeX (gros changements de structure) et de perl (répertoires versionés ... ) et à chaque fois en suivant UPDATING je n'ai pas eu de problème et je ne suis pas le seul.
Je te résume le tout avant que tu me redise que j'accuse les utilisateurs : il y a 2 points, d'abord une complexité croissante des dépendances qui entraine systématiquement une série de recompilation et enfin effectivement le fait que pour certains ça marche et que les problèmes que tu décris ne sont pas généraux, mais semblent spécifiques à _ton_ utilisation des ports.
Je ne dis pas que les ports sont parfaits, je me bat avec suffisamment de problème de dépendances qui ne sont pas modélisable dans le modèle actuel pour savoir que l'on peut faire des progrès, mais les problèmes que tu soulèves ne sont pas vraiment des problèmes du système de port.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <d7fe2j$1c9k$1@asmodee.lpthe.jussieu.fr>, Michel Talon wrote:
Tu m'apprends une nouvelle. "De mon temps" les ports n'étaient pas
branchés et tu avais un CURRENT permanent. Il va falloir que je
regarde de ce coté là, car à la fin du port freeze et bien avant la
publication de la RELEASE les porteurs s'empressent de décharger
tous leurs machins en attente, si bien qu'un cvsup au moment de la
RELEASE ne te met pas du tout dans un état approprié pour
télécharger un maximum de binaires pré compilés.
Il n'y a pas vraiment de branche, mais un tag sur la branche
principale pour chaque release (sinon, le dégel des ports n'aurait pas
lieu avant la release ... )
Donc tu peux mettre RELEASE_5_4_0 comme tag dans ton supfile si tu
veux les ports de la release 5.4. Effectivement ces ports n'évoluent
pas (contrairement aux branches RELENG_X_Y), mais ça évite de se
coltiner les mouvements post-release ...
Ecoutes, quand Matt Dillon prétendait que le système des ports
déconnait complètement et qu'il fallait le reprendre entièrement, je
croyais qu'il exagérait, et c'était une époque où je ne voyais pas
de problème. Or tu conviendras que Matt est beaucoup plus compétent
que toi et moi, et que s'il avait des problèmes, il fallait bien
qu'ils viennent de quelque part. La réponse standard quand un truc
ne marche pas, c'est de dire que c'est la faute de l'utilisateur qui
est incompétent, le résultat c'est qu'on perd peu à peu ses
utilisateurs.
Tu as suivie ce que je dis ? je parle d'erreur issue de l'utilisateur
mais pas uniquement. Regarde un peu le chaînage des dépendances de la
moindre application orientée workstation, à part les applications
relativement anciennes qui sont restées avec le même profile de
développement, chaque appli dépend d'une quantité affolante de libs et
d'autres programmes (et ceux indépendamment des ports) or, ces
fameuses libs bougent relativement vite elle même, avec des
changements d'API réguliers impliquant à chaque mise à jour une
recompilation totale de pas mal d'autres ports (qui à leur tour ... )
Alors soit, peut être que le système des ports n'est plus aussi bien
adapté, mais la faute ne vient pas forcément d'eux. Portupgrade était
une tentative de réponse à ce problème, pas l'origine du problème. Si
la solution ne te plais pas, ben essaie d'avoir un raisonnement
constructif, au lieu de crier sur les autres.
Moi ce que je te dis, c'est que pour avoir utilisé FreeBSD-2.2.5 et
depuis, il n'y avait *jamais* de problème. On faisait un cvsup, puis
un make install dans un port et ça marchait toujours.
Oui et moi, il y a 5 ou 6 ans, j'installais pas mal de chose sur la
partoche NFS que l'admin nous laissait (pour que les étudiants aient
leurs applis sans l'emmmerder) et tout se passait sans problème, sans
être root. Seulement, pour 10 ou 15 applications j'installais parfois
une lib et encore (le plus souvent c'était pour faire tourner les
applis installer pour les linux sur les solaris/hp-ux qui n'avaient
pas la même base d'installée.) Je faisais tout ça sans port, sans
package, et les problèmes de dépendance ne se posaient pas comme ils
se posent aujourd'hui.
Donc essaies de comparer les choses comparables.
Depuis que quelques gros malins se sont mis à gérer ça en finesse,
il y a constamment des problèmes. Je suis désolé, mais à chaque
release il y a une floppée de ports dont le binaire n'existe pas,
non pas du tout pour des raisons de licence (comme java) mais tout
simplement parceque le port est cassé.
As tu regardé pourquoi ces ports étaient cassés ? Peux tu dire que
systématiquement cela vient de la gestion des ports ? Soit, un port
cassé parce que son plist est incomplet ça paraît être un comportement
excessif, malheureusement, poses toi la question des conséquences sur
le processus de construction des packages ...
Donc venir dire que c'est la faute des fausses manoeuvres de
l'utilisateur, c'est se défausser grossièrement de la réalité.
Quand j'ai installé la 5.3 il m'a fallu touiller les Makefile de je
ne sais combien de ports pour arriver à les compiler. C'était une
installation fraîche donc ça ne dépendait en rien de moi. Et il ne
s'agit pas de quoi que ce soit d'exotique, il y avait par exemple
qdvdauthor et toutes ses dépendances. Je me souviens avoir passé un
bon moment sur ça. Et beaucoup d'autres choses. L'exemple que j'ai
cité avec azureus, je ne l'ai pas sorti de mon imagination, il est
réél. Dans la situation merdique actuelle de l'arbre des ports je
n'ose plus toucher à quoi que ce soit, je vais encore être obligé de
tout virer et tout réinstaller à partir des binaires.
Ce que j'aimerais comprendre c'est pourquoi ça marche pour les autres
et pas pour toi ? J'ai installé plusieurs 5.1, 5.2 et 5.3 sans avoir à
modifier des makefiles, j'ai fait des upgrades sur les ports installés
sur ces machines sans problème particulier, les seules manips
compliquées étaient liées aux upgrades de gnome (qui nécessite
systématiquement une recompilation complète de l'ensemble des
dépendances ... ), de teTeX (gros changements de structure) et de perl
(répertoires versionés ... ) et à chaque fois en suivant UPDATING je
n'ai pas eu de problème et je ne suis pas le seul.
Je te résume le tout avant que tu me redise que j'accuse les
utilisateurs : il y a 2 points, d'abord une complexité croissante des
dépendances qui entraine systématiquement une série de recompilation
et enfin effectivement le fait que pour certains ça marche et que les
problèmes que tu décris ne sont pas généraux, mais semblent
spécifiques à _ton_ utilisation des ports.
Je ne dis pas que les ports sont parfaits, je me bat avec suffisamment
de problème de dépendances qui ne sont pas modélisable dans le modèle
actuel pour savoir que l'on peut faire des progrès, mais les problèmes
que tu soulèves ne sont pas vraiment des problèmes du système de port.
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Tu m'apprends une nouvelle. "De mon temps" les ports n'étaient pas branchés et tu avais un CURRENT permanent. Il va falloir que je regarde de ce coté là, car à la fin du port freeze et bien avant la publication de la RELEASE les porteurs s'empressent de décharger tous leurs machins en attente, si bien qu'un cvsup au moment de la RELEASE ne te met pas du tout dans un état approprié pour télécharger un maximum de binaires pré compilés.
Il n'y a pas vraiment de branche, mais un tag sur la branche principale pour chaque release (sinon, le dégel des ports n'aurait pas lieu avant la release ... )
Donc tu peux mettre RELEASE_5_4_0 comme tag dans ton supfile si tu veux les ports de la release 5.4. Effectivement ces ports n'évoluent pas (contrairement aux branches RELENG_X_Y), mais ça évite de se coltiner les mouvements post-release ...
Ecoutes, quand Matt Dillon prétendait que le système des ports déconnait complètement et qu'il fallait le reprendre entièrement, je croyais qu'il exagérait, et c'était une époque où je ne voyais pas de problème. Or tu conviendras que Matt est beaucoup plus compétent que toi et moi, et que s'il avait des problèmes, il fallait bien qu'ils viennent de quelque part. La réponse standard quand un truc ne marche pas, c'est de dire que c'est la faute de l'utilisateur qui est incompétent, le résultat c'est qu'on perd peu à peu ses utilisateurs.
Tu as suivie ce que je dis ? je parle d'erreur issue de l'utilisateur mais pas uniquement. Regarde un peu le chaînage des dépendances de la moindre application orientée workstation, à part les applications relativement anciennes qui sont restées avec le même profile de développement, chaque appli dépend d'une quantité affolante de libs et d'autres programmes (et ceux indépendamment des ports) or, ces fameuses libs bougent relativement vite elle même, avec des changements d'API réguliers impliquant à chaque mise à jour une recompilation totale de pas mal d'autres ports (qui à leur tour ... )
Alors soit, peut être que le système des ports n'est plus aussi bien adapté, mais la faute ne vient pas forcément d'eux. Portupgrade était une tentative de réponse à ce problème, pas l'origine du problème. Si la solution ne te plais pas, ben essaie d'avoir un raisonnement constructif, au lieu de crier sur les autres.
Moi ce que je te dis, c'est que pour avoir utilisé FreeBSD-2.2.5 et depuis, il n'y avait *jamais* de problème. On faisait un cvsup, puis un make install dans un port et ça marchait toujours.
Oui et moi, il y a 5 ou 6 ans, j'installais pas mal de chose sur la partoche NFS que l'admin nous laissait (pour que les étudiants aient leurs applis sans l'emmmerder) et tout se passait sans problème, sans être root. Seulement, pour 10 ou 15 applications j'installais parfois une lib et encore (le plus souvent c'était pour faire tourner les applis installer pour les linux sur les solaris/hp-ux qui n'avaient pas la même base d'installée.) Je faisais tout ça sans port, sans package, et les problèmes de dépendance ne se posaient pas comme ils se posent aujourd'hui.
Donc essaies de comparer les choses comparables.
Depuis que quelques gros malins se sont mis à gérer ça en finesse, il y a constamment des problèmes. Je suis désolé, mais à chaque release il y a une floppée de ports dont le binaire n'existe pas, non pas du tout pour des raisons de licence (comme java) mais tout simplement parceque le port est cassé.
As tu regardé pourquoi ces ports étaient cassés ? Peux tu dire que systématiquement cela vient de la gestion des ports ? Soit, un port cassé parce que son plist est incomplet ça paraît être un comportement excessif, malheureusement, poses toi la question des conséquences sur le processus de construction des packages ...
Donc venir dire que c'est la faute des fausses manoeuvres de l'utilisateur, c'est se défausser grossièrement de la réalité. Quand j'ai installé la 5.3 il m'a fallu touiller les Makefile de je ne sais combien de ports pour arriver à les compiler. C'était une installation fraîche donc ça ne dépendait en rien de moi. Et il ne s'agit pas de quoi que ce soit d'exotique, il y avait par exemple qdvdauthor et toutes ses dépendances. Je me souviens avoir passé un bon moment sur ça. Et beaucoup d'autres choses. L'exemple que j'ai cité avec azureus, je ne l'ai pas sorti de mon imagination, il est réél. Dans la situation merdique actuelle de l'arbre des ports je n'ose plus toucher à quoi que ce soit, je vais encore être obligé de tout virer et tout réinstaller à partir des binaires.
Ce que j'aimerais comprendre c'est pourquoi ça marche pour les autres et pas pour toi ? J'ai installé plusieurs 5.1, 5.2 et 5.3 sans avoir à modifier des makefiles, j'ai fait des upgrades sur les ports installés sur ces machines sans problème particulier, les seules manips compliquées étaient liées aux upgrades de gnome (qui nécessite systématiquement une recompilation complète de l'ensemble des dépendances ... ), de teTeX (gros changements de structure) et de perl (répertoires versionés ... ) et à chaque fois en suivant UPDATING je n'ai pas eu de problème et je ne suis pas le seul.
Je te résume le tout avant que tu me redise que j'accuse les utilisateurs : il y a 2 points, d'abord une complexité croissante des dépendances qui entraine systématiquement une série de recompilation et enfin effectivement le fait que pour certains ça marche et que les problèmes que tu décris ne sont pas généraux, mais semblent spécifiques à _ton_ utilisation des ports.
Je ne dis pas que les ports sont parfaits, je me bat avec suffisamment de problème de dépendances qui ne sont pas modélisable dans le modèle actuel pour savoir que l'on peut faire des progrès, mais les problèmes que tu soulèves ne sont pas vraiment des problèmes du système de port.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
talon
Marwan Burelle wrote:
Alors soit, peut être que le système des ports n'est plus aussi bien adapté, mais la faute ne vient pas forcément d'eux. Portupgrade était une tentative de réponse à ce problème, pas l'origine du problème. Si la solution ne te plais pas, ben essaie d'avoir un raisonnement constructif, au lieu de crier sur les autres.
Je veux bien être d'accord avec ça.
Moi ce que je te dis, c'est que pour avoir utilisé FreeBSD-2.2.5 et depuis, il n'y avait *jamais* de problème. On faisait un cvsup, puis un make install dans un port et ça marchait toujours.
Oui et moi, il y a 5 ou 6 ans, j'installais pas mal de chose sur la partoche NFS que l'admin nous laissait (pour que les étudiants aient leurs applis sans l'emmmerder) et tout se passait sans problème, sans être root. Seulement, pour 10 ou 15 applications j'installais parfois une lib et encore (le plus souvent c'était pour faire tourner les applis installer pour les linux sur les solaris/hp-ux qui n'avaient pas la même base d'installée.) Je faisais tout ça sans port, sans package, et les problèmes de dépendance ne se posaient pas comme ils se posent aujourd'hui.
Donc essaies de comparer les choses comparables.
Avec ça aussi. Le plus gros fautif étant, non pas java, comme on veut le faire croire, mais Gnome avec ses dizaines de ports qui marchent la semaine des 4 Jeudis.
As tu regardé pourquoi ces ports étaient cassés ? Peux tu dire que systématiquement cela vient de la gestion des ports ? Soit, un port cassé parce que son plist est incomplet ça paraît être un comportement excessif, malheureusement, poses toi la question des conséquences sur le processus de construction des packages ...
Ca vient *trés* souvent de la gestion des ports. Par exemple mettre une dépendance aussi précise que ${ECLIPSE_VERSION} dans un autre programme c'est pousse au crime. Eclipse lui même va dépendre de Gnome pour fabriquer ses fenêtres, et les fameux plugins. Avec des dépendances précises tu vas immédiatement te mettre à recomiler une partie sinon la totalité de Gnome, ce qui est calamiteux quand tu as une version qui marche sur ta machine, et que tu risques de te retrouver en carafe.
Ce que j'aimerais comprendre c'est pourquoi ça marche pour les autres et pas pour toi ? J'ai installé plusieurs 5.1, 5.2 et 5.3 sans avoir à modifier des makefiles, j'ai fait des upgrades sur les ports installés
Tu pourras trouver autant que tu veux sur les différentes mailing lists d'exemples de gens qui ont eu des gros problèmes.
sur ces machines sans problème particulier, les seules manips compliquées étaient liées aux upgrades de gnome (qui nécessite systématiquement une recompilation complète de l'ensemble des dépendances ... ),
Et voilà, tu viens de citer le principal coupable. Or une énormité de ports sont dépendants de Gnome.
de teTeX (gros changements de structure)
Ca je n'ai jamais eu de problème de TeTex, comme quoi les expériences ...
Je ne dis pas que les ports sont parfaits, je me bat avec suffisamment de problème de dépendances qui ne sont pas modélisable dans le modèle actuel pour savoir que l'on peut faire des progrès, mais les problèmes que tu soulèves ne sont pas vraiment des problèmes du système de port.
Si. En conséquence de tout ce que je veux bien t'accorder, la complexité qui est devenue faramineuse, etc. il faut trouver un autre système pour organiser les choses, en particulier pour organiser la coexistence de plusieurs versions d'un même port, ce qui évite de tout casser quand on fait une nouvelle installation. Comme tu le sais sûrement c'est un des principaux objectifs de Dragonflybsd, d'utiliser de nouveaux mécanismes noyaux pour organiser cette coexistence, faire en sorte qu'un "build" dans l'arbre des ports n'ait qu'une vue tronquée de ce qui existe dans les librairies par exemple. Une autre solution est de fournir des binaires empaquetés dans leur propre directory à la Mac OS X, ou PC-BSD. Le système tel qu'il est actuellement est devenu trop instable, et portupgrade est un emplâtre sur une jambe de bois. Je ne dis pas qu'il est buggué en lui même, simplement que croire qu'il peut marcher est irréaliste vu l'état de l'arbre des ports. Apt-get marche parceque on travaille avec des paquets binaires dans Debian, donc on sait par hypothèse qu'ils existent. Par contre l'existence d'un port dans l'arbre des ports ne prouve rien quand au fait qu'il est compilable. Donc l'information essentielle qui permet à apt-get de travailler manque à portupgrade.
--
Michel TALON
Marwan Burelle <burelle@lri.fr> wrote:
Alors soit, peut être que le système des ports n'est plus aussi bien
adapté, mais la faute ne vient pas forcément d'eux. Portupgrade était
une tentative de réponse à ce problème, pas l'origine du problème. Si
la solution ne te plais pas, ben essaie d'avoir un raisonnement
constructif, au lieu de crier sur les autres.
Je veux bien être d'accord avec ça.
Moi ce que je te dis, c'est que pour avoir utilisé FreeBSD-2.2.5 et
depuis, il n'y avait *jamais* de problème. On faisait un cvsup, puis
un make install dans un port et ça marchait toujours.
Oui et moi, il y a 5 ou 6 ans, j'installais pas mal de chose sur la
partoche NFS que l'admin nous laissait (pour que les étudiants aient
leurs applis sans l'emmmerder) et tout se passait sans problème, sans
être root. Seulement, pour 10 ou 15 applications j'installais parfois
une lib et encore (le plus souvent c'était pour faire tourner les
applis installer pour les linux sur les solaris/hp-ux qui n'avaient
pas la même base d'installée.) Je faisais tout ça sans port, sans
package, et les problèmes de dépendance ne se posaient pas comme ils
se posent aujourd'hui.
Donc essaies de comparer les choses comparables.
Avec ça aussi. Le plus gros fautif étant, non pas java, comme on veut le
faire croire, mais Gnome avec ses dizaines de ports qui marchent la semaine
des 4 Jeudis.
As tu regardé pourquoi ces ports étaient cassés ? Peux tu dire que
systématiquement cela vient de la gestion des ports ? Soit, un port
cassé parce que son plist est incomplet ça paraît être un comportement
excessif, malheureusement, poses toi la question des conséquences sur
le processus de construction des packages ...
Ca vient *trés* souvent de la gestion des ports. Par exemple mettre
une dépendance aussi précise que ${ECLIPSE_VERSION} dans un autre programme
c'est pousse au crime. Eclipse lui même va dépendre de Gnome pour fabriquer
ses fenêtres, et les fameux plugins. Avec des dépendances précises tu vas
immédiatement te mettre à recomiler une partie sinon la totalité de Gnome,
ce qui est calamiteux quand tu as une version qui marche sur ta machine,
et que tu risques de te retrouver en carafe.
Ce que j'aimerais comprendre c'est pourquoi ça marche pour les autres
et pas pour toi ? J'ai installé plusieurs 5.1, 5.2 et 5.3 sans avoir à
modifier des makefiles, j'ai fait des upgrades sur les ports installés
Tu pourras trouver autant que tu veux sur les différentes mailing lists
d'exemples de gens qui ont eu des gros problèmes.
sur ces machines sans problème particulier, les seules manips
compliquées étaient liées aux upgrades de gnome (qui nécessite
systématiquement une recompilation complète de l'ensemble des
dépendances ... ),
Et voilà, tu viens de citer le principal coupable. Or une énormité
de ports sont dépendants de Gnome.
de teTeX (gros changements de structure)
Ca je n'ai jamais eu de problème de TeTex, comme quoi les expériences ...
Je ne dis pas que les ports sont parfaits, je me bat avec suffisamment
de problème de dépendances qui ne sont pas modélisable dans le modèle
actuel pour savoir que l'on peut faire des progrès, mais les problèmes
que tu soulèves ne sont pas vraiment des problèmes du système de port.
Si. En conséquence de tout ce que je veux bien t'accorder, la complexité
qui est devenue faramineuse, etc. il faut trouver un autre système pour
organiser les choses, en particulier pour organiser la coexistence de
plusieurs versions d'un même port, ce qui évite de tout casser quand on
fait une nouvelle installation. Comme tu le sais sûrement c'est un des
principaux objectifs de Dragonflybsd, d'utiliser de nouveaux mécanismes noyaux
pour organiser cette coexistence, faire en sorte qu'un "build" dans l'arbre
des ports n'ait qu'une vue tronquée de ce qui existe dans les librairies par
exemple. Une autre solution est de fournir des binaires empaquetés dans leur
propre directory à la Mac OS X, ou PC-BSD. Le système tel qu'il est
actuellement est devenu trop instable, et portupgrade est un emplâtre sur
une jambe de bois. Je ne dis pas qu'il est buggué en lui même, simplement
que croire qu'il peut marcher est irréaliste vu l'état de l'arbre des ports.
Apt-get marche parceque on travaille avec des paquets binaires dans Debian,
donc on sait par hypothèse qu'ils existent. Par contre l'existence d'un port
dans l'arbre des ports ne prouve rien quand au fait qu'il est compilable.
Donc l'information essentielle qui permet à apt-get de travailler manque à
portupgrade.
Alors soit, peut être que le système des ports n'est plus aussi bien adapté, mais la faute ne vient pas forcément d'eux. Portupgrade était une tentative de réponse à ce problème, pas l'origine du problème. Si la solution ne te plais pas, ben essaie d'avoir un raisonnement constructif, au lieu de crier sur les autres.
Je veux bien être d'accord avec ça.
Moi ce que je te dis, c'est que pour avoir utilisé FreeBSD-2.2.5 et depuis, il n'y avait *jamais* de problème. On faisait un cvsup, puis un make install dans un port et ça marchait toujours.
Oui et moi, il y a 5 ou 6 ans, j'installais pas mal de chose sur la partoche NFS que l'admin nous laissait (pour que les étudiants aient leurs applis sans l'emmmerder) et tout se passait sans problème, sans être root. Seulement, pour 10 ou 15 applications j'installais parfois une lib et encore (le plus souvent c'était pour faire tourner les applis installer pour les linux sur les solaris/hp-ux qui n'avaient pas la même base d'installée.) Je faisais tout ça sans port, sans package, et les problèmes de dépendance ne se posaient pas comme ils se posent aujourd'hui.
Donc essaies de comparer les choses comparables.
Avec ça aussi. Le plus gros fautif étant, non pas java, comme on veut le faire croire, mais Gnome avec ses dizaines de ports qui marchent la semaine des 4 Jeudis.
As tu regardé pourquoi ces ports étaient cassés ? Peux tu dire que systématiquement cela vient de la gestion des ports ? Soit, un port cassé parce que son plist est incomplet ça paraît être un comportement excessif, malheureusement, poses toi la question des conséquences sur le processus de construction des packages ...
Ca vient *trés* souvent de la gestion des ports. Par exemple mettre une dépendance aussi précise que ${ECLIPSE_VERSION} dans un autre programme c'est pousse au crime. Eclipse lui même va dépendre de Gnome pour fabriquer ses fenêtres, et les fameux plugins. Avec des dépendances précises tu vas immédiatement te mettre à recomiler une partie sinon la totalité de Gnome, ce qui est calamiteux quand tu as une version qui marche sur ta machine, et que tu risques de te retrouver en carafe.
Ce que j'aimerais comprendre c'est pourquoi ça marche pour les autres et pas pour toi ? J'ai installé plusieurs 5.1, 5.2 et 5.3 sans avoir à modifier des makefiles, j'ai fait des upgrades sur les ports installés
Tu pourras trouver autant que tu veux sur les différentes mailing lists d'exemples de gens qui ont eu des gros problèmes.
sur ces machines sans problème particulier, les seules manips compliquées étaient liées aux upgrades de gnome (qui nécessite systématiquement une recompilation complète de l'ensemble des dépendances ... ),
Et voilà, tu viens de citer le principal coupable. Or une énormité de ports sont dépendants de Gnome.
de teTeX (gros changements de structure)
Ca je n'ai jamais eu de problème de TeTex, comme quoi les expériences ...
Je ne dis pas que les ports sont parfaits, je me bat avec suffisamment de problème de dépendances qui ne sont pas modélisable dans le modèle actuel pour savoir que l'on peut faire des progrès, mais les problèmes que tu soulèves ne sont pas vraiment des problèmes du système de port.
Si. En conséquence de tout ce que je veux bien t'accorder, la complexité qui est devenue faramineuse, etc. il faut trouver un autre système pour organiser les choses, en particulier pour organiser la coexistence de plusieurs versions d'un même port, ce qui évite de tout casser quand on fait une nouvelle installation. Comme tu le sais sûrement c'est un des principaux objectifs de Dragonflybsd, d'utiliser de nouveaux mécanismes noyaux pour organiser cette coexistence, faire en sorte qu'un "build" dans l'arbre des ports n'ait qu'une vue tronquée de ce qui existe dans les librairies par exemple. Une autre solution est de fournir des binaires empaquetés dans leur propre directory à la Mac OS X, ou PC-BSD. Le système tel qu'il est actuellement est devenu trop instable, et portupgrade est un emplâtre sur une jambe de bois. Je ne dis pas qu'il est buggué en lui même, simplement que croire qu'il peut marcher est irréaliste vu l'état de l'arbre des ports. Apt-get marche parceque on travaille avec des paquets binaires dans Debian, donc on sait par hypothèse qu'ils existent. Par contre l'existence d'un port dans l'arbre des ports ne prouve rien quand au fait qu'il est compilable. Donc l'information essentielle qui permet à apt-get de travailler manque à portupgrade.
--
Michel TALON
xavier
cedric wrote:
Ghein ? Les packets exim et postfix sont incompatibles (un seul 'mail-transport-agent' possible - vérifié sur potatoe, woody et sur sarge).
Oui, justement. Chaque fois que tu veux installer/mettre à jour un truc qui a une dépendance sur 'mail-transport-agent', il voit que tu as Postfix, et insiste lourdement pour le remplacer par Le MTA Recommandé Par La Secte.
D'ailleurs, il l'installe, mais ne l'active pas. La *¨présence* des deux est possible.
-- Xavier HUMBERT
cedric <rixed@free.fr> wrote:
Ghein ? Les packets exim et postfix sont incompatibles (un seul
'mail-transport-agent' possible - vérifié sur potatoe, woody et sur sarge).
Oui, justement. Chaque fois que tu veux installer/mettre à jour un truc
qui a une dépendance sur 'mail-transport-agent', il voit que tu as
Postfix, et insiste lourdement pour le remplacer par Le MTA Recommandé
Par La Secte.
D'ailleurs, il l'installe, mais ne l'active pas. La *¨présence* des deux
est possible.
Ghein ? Les packets exim et postfix sont incompatibles (un seul 'mail-transport-agent' possible - vérifié sur potatoe, woody et sur sarge).
Oui, justement. Chaque fois que tu veux installer/mettre à jour un truc qui a une dépendance sur 'mail-transport-agent', il voit que tu as Postfix, et insiste lourdement pour le remplacer par Le MTA Recommandé Par La Secte.
D'ailleurs, il l'installe, mais ne l'active pas. La *¨présence* des deux est possible.
-- Xavier HUMBERT
xavier
Hubert wrote:
Les deux sont (étaient ?) plutôt complémentaires, puisque j'avais notamment complété le travail d'Eric sur les "distributions" BSD.
Ah, j'ignorais ce détail.
-- Xavier HUMBERT
Hubert <hubert@frbsd.org.invalid> wrote:
Les deux sont (étaient ?) plutôt complémentaires, puisque j'avais
notamment complété le travail d'Eric sur les "distributions" BSD.
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Stephane Dupille
C'est un fichier fabrqiué avec un truc comme: cat /dev/zero > fichier_a_trou.txt les trous sont les trous des "zero"...
Non, ça, c'est un fichier contenant des 0.
Pour faire un fichier à trou, il faut créer un fichier, se déplacer plus loin que la fichier, et y écrire quelque chose. Je n'ai pas d'exemple en shell, il faudrait un petit source en C pour bien montrer ça (mais je n'ai pas trop le temps de vous bricoler un exemple là, maintenant, tout de suite).
Un fichier à trou, c'est un fichier qui est plus grand que la place qu'il occupe sur disque. Par convention, le trou est rempli de zéros, mais un zéro n'est pas un trou.
----> []
Pas mieux.
-- Monsieur gagnerait en credibilite en etayant ses accusations; Tel quel, c'est minable. Bah, yaka attendre - on verra bien a quel gaz est gonflee cette baudruche. -+-TC in : <http://www.le-gnu.net> - Le neuneu se déballonne -+-
C'est un fichier fabrqiué avec un truc comme:
cat /dev/zero > fichier_a_trou.txt
les trous sont les trous des "zero"...
Non, ça, c'est un fichier contenant des 0.
Pour faire un fichier à trou, il faut créer un fichier, se déplacer
plus loin que la fichier, et y écrire quelque chose. Je n'ai pas
d'exemple en shell, il faudrait un petit source en C pour bien
montrer ça (mais je n'ai pas trop le temps de vous bricoler un exemple
là, maintenant, tout de suite).
Un fichier à trou, c'est un fichier qui est plus grand que la place
qu'il occupe sur disque. Par convention, le trou est rempli de zéros,
mais un zéro n'est pas un trou.
----> []
Pas mieux.
--
Monsieur gagnerait en credibilite en etayant ses accusations;
Tel quel, c'est minable. Bah, yaka attendre - on verra bien
a quel gaz est gonflee cette baudruche.
-+-TC in : <http://www.le-gnu.net> - Le neuneu se déballonne -+-
C'est un fichier fabrqiué avec un truc comme: cat /dev/zero > fichier_a_trou.txt les trous sont les trous des "zero"...
Non, ça, c'est un fichier contenant des 0.
Pour faire un fichier à trou, il faut créer un fichier, se déplacer plus loin que la fichier, et y écrire quelque chose. Je n'ai pas d'exemple en shell, il faudrait un petit source en C pour bien montrer ça (mais je n'ai pas trop le temps de vous bricoler un exemple là, maintenant, tout de suite).
Un fichier à trou, c'est un fichier qui est plus grand que la place qu'il occupe sur disque. Par convention, le trou est rempli de zéros, mais un zéro n'est pas un trou.
----> []
Pas mieux.
-- Monsieur gagnerait en credibilite en etayant ses accusations; Tel quel, c'est minable. Bah, yaka attendre - on verra bien a quel gaz est gonflee cette baudruche. -+-TC in : <http://www.le-gnu.net> - Le neuneu se déballonne -+-
