ch'tites questions newbie

1) Free ou Net ?

Je ne peux pas apporter de réponse objective à cette question.

J'ai vu sur le ng (VD il y a 4 jours, à propos d'un G4) que NetBSD
aurait «l'émulation linux».
Qu'est ce que ça signifie ?

Cela signifie qu'il permet de faire fonctionner les binaires Linux non
modifiés, sous réserve de disponibilité d'une émulation des appels
systèmes Linux (certains peuvent manquer) et que le support existe pour
ton architecture (FreeBSD et OpenBSD ne peuvent faire fonctionner des
binaires Linux que sur x86, tandis que NetBSD le permet aussi sur ppc et
arm32, entre autres).

Qu'on peut utiliser des applis dans le usr du pingouin qu'on monterait
dans le root de NetBSD ?

Voir compat_linux(8) en ligne pour de plus amples détails.

Dans la section 2.9.9 du HandBook de Free, il est dit «...will allow
running Linux software on FreeBSD.» et je sais qu'on peut compiler en
dur dans le noyau de FriBi, le support de l'ext2 pour monter mon home.

Tous les *BSD sérieux sont capables de lire de l'ext2 (et donc de l'ext3
sans gérer le journal).

2) Les ports ?
Si j'ai bien compris, c'est ainsi qu'on appelle les sources des
applications en y ajoutant une gestion des dépendances et une
automatisation de l'installation et des upgrades. J'ai bon ?

Grosso modo, oui.

(D'ailleurs en RTFMant, j'ai appris que les packages binaires étaient
plus petits que les sources, c'est marrant j'ai toujours été persuadé
du contraire. Quelqu'un explique ?)

Ces cons de programmeurs modernes commentent leur code. Aucune éthique.

3) Bootloader ?

Là, je passe. Joker.

4) Taille des slices ?
J'ai pas très bien compris la distinction entre une partition et un
slice...

C'est la même chose.

Sauf que, dans la tas de boue immonde qu'est l'architecture
x86-en-boîtes-d'allumettes, il y a deux niveaux de partitions : celles
au niveau de la PROM, pardon, du BIOS, qui sont limitées à 4 (plus une
joyeuse farce qu'on nomme partitions logiques). Traditionnellement, par
souci de bienveillante cohabitation avec d'autres systèmes, les BSD
s'installent dans une partition (au sens BIOS) dans laquelles ils
composent leurs slice (partitions au sens BSD, donc).

C'est un joyeux bordel, mais c'est la faute du souci de compatibilité
avec les systèmes de sous-développé dont on équipe habituellement les
x86.

Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?

Il est possible de mettre aussi peu de swap que l'on le désire.
Cependant, dans l'hypothèse absurde où l'on souhaiterai pouvoir obtenir
un coredump de son noyau après un malheureux plantage, il est nécessaire
que la taille du slice de dump, qui est aussi celui de swap principal,
soit supérieure à la quantité de mémoire de la machine.

Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?

Oui, mais si je ne m'abuse, Linux a besoin qu'on lui tienne la main avec
un mkswap ou quelque chose dans ce genre pour qu'il puisse utiliser cet
espace ; il faut donc faire un mkswap systématique au démarrage.

5) AfterStep ?
Est-ce qu'il a été porté sous FriBi ?
Oui.

J'ai les sources Linux, je peux le recompiler sans modif ?
En théorie, oui. En pratique, bienvenue dans le monde du logiciel

soi-disant portable qui ne fonctionne que sur Linux/x86/ELF.

Si oui est-ce généralisable à toutes les applis dont j'ai les sources ?
Ma remarque précédente est généralisable à tous les logiciels dont tu as

les sources.

6) Mais où est passé TP ?
Il se fait rare.

Je croyais que ce cher Pinuche était passé du coté du daemon, mais je ne
Ah, je pensais que tu parlais de Thomas Pornin. Alors dans ce cas : il

se fait _très_ rare.

Vous savez quoi ? 'BSD' est dans le dico américain et pas 'SysV'.
``SystemV does everything Unix does, only not as well.''

Amis du 'Berkeley Screen of Death' bonjour.

Oui, l'écran bleu c'est OpenBSD au boot ;^)

C'est vrai. Bien que cela puisse se changer par simple recompilation.
NetBSD a choisi le rouge, afin d'inciter ses troupes à travailler sur
NetBSD/taureau ...

Le vrai écran bleu Unix, reste tout de même la console SRM sur Alpha.

1) Free ou Net ?
J'ai vu sur le ng (VD il y a 4 jours, à propos d'un G4) que NetBSD
aurait «l'émulation linux».
Qu'est ce que ça signifie ?

Net essaie en vain de suivre Free sur ce terrain. Certains s'en plaignent
d'autres pas du tout.

Aurais-tu des arguments justifiant cette prise de position péremptoire ?

Cyril Guibourg <plonk-o-matic@teaser.fr> wrote:

Pour la 'a', c'est OK: 100 MB.

Perso je met 128 pour être tranquille lors des installworld

Avec >FreeBSD-5 il vaut mieux compter large! 150M

Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?
Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?

Cela a peut-etre changé mais il me semble qu'à une époque les swap
linux devaient être initialisés pour être fonctionnels. Ecraser les
structures de données via le noyal BSD pourrait avoir des conséquences.

Pas de problème je l'ai fait régulièrement. Il suffit de refaire un
mkswap sur la partition de swap linux à chaque boot (placer ça dans
un script de démarrage).



--

Michel TALON

On 2004-01-13, Miod Vallat <miod@online.fr> wrote:

C'est vrai. Bien que cela puisse se changer par simple recompilation.
NetBSD a choisi le rouge, afin d'inciter ses troupes à travailler sur
NetBSD/taureau ...

s/rouge/vert/ (par default)

Le vrai écran bleu Unix, reste tout de même la console SRM sur Alpha.

Toujours mieux que blanc!

Hugolino <hugolino@free.fr> wrote:

1) Free ou Net ?
J'ai vu sur le ng (VD il y a 4 jours, à propos d'un G4) que NetBSD
aurait «l'émulation linux».
Qu'est ce que ça signifie ?

Que NetBSD sait executer les binaires Linux. Les binaires telles
quelles, sans qu'il soit necesssaire de les recompiler.

Qu'on peut utiliser des applis dans le usr du pingouin qu'on monterait
dans le root de NetBSD ?

Voila. Enfin les applis dont on a pas les sources, parceque les autres,
on préfère les compiler natives.

Dans la section 2.9.9 du HandBook de Free, il est dit «...will allow
running Linux software on FreeBSD.» et je sais qu'on peut compiler en
dur dans le noyau de FriBi, le support de l'ext2 pour monter mon home.

Les 3 BSD savent monter de l'ext2fs.

Alors Free ou Net ?

Ben NetBSD en ce qui me concerne. D'autres diront FreeBSD, question de
goût.

2) Les ports ?
Si j'ai bien compris, c'est ainsi qu'on appelle les sources des
applications en y ajoutant une gestion des dépendances et une
automatisation de l'installation et des upgrades. J'ai bon ?

En terminologie FreeBSD. Chez NetBSD ca s'appelle des packages. Et les
packages de FreeBSD s'appellent des packages binaires sous NetBSD.

(D'ailleurs en RTFMant, j'ai appris que les packages binaires étaient
plus petits que les sources, c'est marrant j'ai toujours été persuadé
du contraire. Quelqu'un explique ?)

Ben les sources, ca prends plus de place que les programmes compilés.

3) Bootloader ?
La section 2.5.3 du handbook n'est pas très claire. Si j'installe le
boot manager de FreeBSD, est-ce qu'il me proposera de gérer mon win et
mon tux ?
Faut-il au contraire choisir "Leave the MBR untouched" ? Et dans ce cas,
est-il possible de configurer mon lilo pour booter FriBi ?

Tout est possible, il suffit de choisir un bootloader pour te faire le
menu de demarrage. Celui de BSD ou celui de Linux, les deux savent le
faire.

4) Taille des slices ?
J'ai pas très bien compris la distinction entre une partition et un
slice...

Une slice c'est une partition au sens du MBR. Dans cette partition on
découpe des partitions BSD.

Pour la 'a', c'est OK: 100 MB.
Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?

Sous FreeBSD je ne sais pas, sous NetBSD non, on peut mettre ce qu'on
veut comme swap.

Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?

Oui, je pense que ca ne devrait pas poser de problèmes.

Pour la 'e', OK.
Pour /usr, quelle taille prévoir ? Sous Linux, il fait 2 GB, mais je
pense y aller calmement au départ et j'imagine qu'il y a un outil pour
redimensionner les partitions si nécessaire.

Ca c'est ton choix. Moi je ne sépare pas /usr comme ca je n'ai pas de
soucis de / trop petite après coup.

5) AfterStep ?
Est-ce qu'il a été porté sous FriBi ?

Il est dispo pour les 3 BSD.

J'ai les sources Linux, je peux le recompiler sans modif ?

Presque sans modifs, il y a parfois un truc ou deux à ajuster, mais
disons oui en général. De toute façon il est dispo dans le système de
packages donc la recompilation peut être automatisée.

Si oui est-ce généralisable à toutes les applis dont j'ai les sources ?

Oui. Du moins celle qui sont bien ecrites.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

manu@netbsd.org (Emmanuel Dreyfus) écrivait :

Voila. Enfin les applis dont on a pas les sources, parceque les autres,
on préfère les compiler natives.

Quand ces sources ne sont pas bourrés de linuxismes...

--
Erwan

Michel Talon <talon@lpthe.jussieu.fr> wrote:

Cyril Guibourg <plonk-o-matic@teaser.fr> wrote:

Pour la 'a', c'est OK: 100 MB.

Perso je met 128 pour être tranquille lors des installworld

Avec >FreeBSD-5 il vaut mieux compter large! 150M

Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?
Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?

Cela a peut-etre changé mais il me semble qu'à une époque les swap
linux devaient être initialisés pour être fonctionnels. Ecraser les
structures de données via le noyal BSD pourrait avoir des conséquences.

Pas de problème je l'ai fait régulièrement. Il suffit de refaire un
mkswap sur la partition de swap linux à chaque boot (placer ça dans
un script de démarrage).


En fait je dois dire que dans mon cas le swap était dans la zone FreeBSD

et Linux n'avait pas le sien en propre. JE ne pense pas que le contraire
soit commode. Il faut se méfier de ce que Linux n'écrase pas le
disklabel de BSD.

--

Michel TALON

Cyril Guibourg <plonk-o-matic@teaser.fr> wrote:

talon@lpthe.jussieu.fr (Michel Talon) writes:

Avec >FreeBSD-5 il vaut mieux compter large! 150M

Rha zut... j'ai une upgrade 4.8 => 5.2R pour demain qui va foirer.

Ca ne va pas foirer. Là en ce moment, mon / fait 62 Megs. J'ai dit
150 pour voir large et prévoir le futur.

--

Michel TALON

According to Hugolino <hugolino@free.fr>:

1) Free ou Net ?
J'ai vu sur le ng (VD il y a 4 jours, à propos d'un G4) que NetBSD
aurait «l'émulation linux».
Qu'est ce que ça signifie ?

Dans un FreeBSD, NetBSD ou Linux, il y a un composant qui s'appelle
le noyau ; c'est lui qui s'occupe de dialoguer avec le matériel, et
qui fait l'essentiel du boulot semi-magique dans le système. Les
applications parlent au noyau via des "appels systèmes". Linux et
FreeBSD n'utilisent pas la même langue pour ces appels, mais comme
les deux systèmes suivent le modèle Unix, on retrouve quand même
sensiblement les mêmes appels entre les deux. La couche d'émulation
fait juste la traduction d'un langage dans l'autre, avec les quelques
ajustements nécessaires. Au final, ça veut dire qu'un binaire prévu pour
Linux peut être lancé sous FreeBSD ou NetBSD.

Ce système d'émulation comporte quelques spécificités (notamment sur
l'emplacement des bibliothèques dynamiques, et autres choses du genre),
aussi il est mieux d'utiliser des binaires natifs. Quasiment toutes les
applications Linux existent aussi en FreeBSD et NetBSD (de l'intérêt de
l'"open source"...) ; dans la pratique, l'émulation Linux ne sert que
pour lancer des programmes dont le code source n'est pas disponible, et
qui n'existent qu'en version Linux. Par exemple Acrobat Reader.

Pour ce qui est du support ext2 : en fait bof. Ce support marchouille
mais n'est pas extrêmement fiable, et peut planter le filesystem
occasionnellement. La réciproque est vraie aussi (le support UFS/FFS de
Linux peut planter le filesystem). Personnellement, je déconseille ce
genre de partage.

Dans tout cela, rien ne départage FreeBSD et NetBSD. Pour choisir il faut
chercher ailleurs.

2) Les ports ?
Si j'ai bien compris, c'est ainsi qu'on appelle les sources des
applications en y ajoutant une gestion des dépendances et une
automatisation de l'installation et des upgrades. J'ai bon ?

Un port, c'est un système de compilation qui :
-- récupère (habituellement par réseau) le code source de l'application
-- applique les patchs locaux qui permettent à l'application de mieux
tourner sous BSD (c'est dingue comme beaucoup de programmeurs supposent
toujours qu'il n'y a que Linux qui existe)
-- compile le programme
-- installe le programme et/ou produit le package binaire correspondant

Ça permet d'installer des applications sans attendre que quelqu'un
produise le package binaire ; ça permet aussi d'interférer un peu avec
le programme, si on veut une configuration spéciale ou appliquer une
modification maison.

(D'ailleurs en RTFMant, j'ai appris que les packages binaires étaient
plus petits que les sources, c'est marrant j'ai toujours été persuadé
du contraire. Quelqu'un explique ?)

Le code binaire est plus compact que le code source. C'est comme ça.
Par exemple, une fonction peut s'appeler "perform_all_pending_jobs" (24
charactères) mais dans le code binaire, c'est une adresse (4 octets).
Globalement, la programmation consiste à exprimer ce qu'on veut à
l'ordinateur, et comme l'ordinateur est assez simplet, il faut lui
exprimer de verbeuse, avec moult détails.

De plus, le code source comporte des commentaires qui ne se retrouvent
pas dans le package binaire (puisqu'ils sont destinés à ceux qui veulent
modifier le code source, et sans utilité pour les autres).

3) Bootloader ?
La section 2.5.3 du handbook n'est pas très claire. Si j'installe le
boot manager de FreeBSD, est-ce qu'il me proposera de gérer mon win et
mon tux ?

Sur un PC, le disque dur commence par un MBR : c'est le premier secteur
du disque. Le reste du disque est découpé en "partitions" (appelée
"slices" en dialecte BSD). Chaque OS occupe une ou plusieurs slices.
FreeBSD en prend une, et y applique son propre système de découpage en
sous-slices ; ce système d'appelle "disklabel". Les sous-slices sont
appelées "partitions" en dialecte BSD (ce qui est source de confusion).

Quand la machine boote, elle charge le MBR, et l'exécute (le MBR
contient la "table de partitions/slices" et le code du bootloader).
Le bootloader be base de Ms-Dos/Windows regarde les slices, choisit
la première qui a le flag "active" (c'est marqué dans la table de
partitions), charge le premier secteur de la slice choisie, et
l'exécute. À charge pour ce premier secteur de faire le boulot. FreeBSD
est bootable de cette façon : le premier secteur de sa slice sait
s'occuper du reste.

Le bootloader FreeBSD agit un peu comme le bootloader de base de Ms-Dos,
sauf qu'il affiche un choix multiple pour toutes les slices détectées,
et permet de choisir l'OS qu'on veut lancer. On peut configurer un choix
par défaut avec un timeout.

Pour un Linux, ce qui s'occupe de le booter, c'est lilo. On peut
installer lilo sur le premier secteur d'une de ses slices et obtenir
ainsi un montage similaire à FreeBSD ou Ms-Dos. Mais l'usage courant est
d'installer lilo sur le MBR du disque (à la place du MBR standard) et de
le configurer pour lancer tous les OS qu'on veut.

Faut-il au contraire choisir "Leave the MBR untouched" ? Et dans ce cas,
est-il possible de configurer mon lilo pour booter FriBi ?

En résumé de ce que j'ai raconté ci-dessus : s'il y a un Linux sur la
machine, et qu'on veut le faire cohabiter avec Linux, le plus simple est
de choisir "Leave the MBR untouched" puis de configurer le lilo pour
pouvoir booter le BSD. Vu de lilo, un BSD se boote comme un Windows
(lilo charge le premier secteur de la slice, et lui laisse terminer le
boulot).

Tout cela est valable aussi bien pour FreeBSD que NetBSD.

4) Taille des slices ?
J'ai pas très bien compris la distinction entre une partition et un
slice...

"slice" = ce qui est appelé "partition" dans le monde Linux
"partition" = morceau de slice.

À noter : Linux numérote ses partitions automatiquement au boot, et
comme il sait lire les "disklabels" de BSD, il rajoute les partitions
BSD (les morceaux de slice) au bout de sa liste.

Pour la 'a', c'est OK: 100 MB.
Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?

Ce n'est pas impératif du tout. Ça dépend de l'utilisation de la machine.
Si c'est pour faire du web, la machine ne swappera quasiment jamais.
Si c'est pour faire du traitement d'images de qualité professionnelle
(donc de _grosses_ images), ça ne fait pas de mal d'avoir du swap sous
la main.

Il est par ailleurs possible de partager le swap avec un filesystem
temporaire, typiquement /tmp (cf "man mfs"). Ça permet d'avoir un
/tmp de belle taille, rapide, séparé de la partition racine, et
automatiquement vidé à chaque boot. Par ailleurs, mozilla, quand il
télécharge un gros fichier, stocke d'abord ce fichier dans /tmp puis le
copie vers sa destination finale. Aussi, si on veut pouvoir télécharger
avec mozilla une image de cdrom (600 Mo), il faut un /tmp d'au moins
cette taille.

Dans la pratique, il est rare d'utiliser simultanément beaucoup de swap
et beaucoup de place dans /tmp. Donc mon conseil est de mettre beaucoup
de swap (genre 1 Go), et de mettre /tmp en mfs. Voici ce que j'ai dans
mon /etc/fstab à ce sujet :

/dev/ad0s1b none swap sw 0 0
/dev/ad0s1b /tmp mfs rw 0 0

Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?

Oui et non. En gros, BSD peut utiliser une partition ou une slice pour
faire son swap, et il en sera très content, mais ça va fâcher Linux :
alors que BSD considère le swap comme une zone vierge, Linux insiste
pour que le début de sa zone de swap contienne quelques structures de
données spécifiques. En swappant, BSD détruira cette structure, et, au
boot suivant, le Linux râlera.

On peut ajuster le Linux pour reconstruire sa structure en cours de boot
(avec un "mkswap" bien placé) mais c'est très casse-gueule (on a vite
fait de blaster une autre partition comme ça) aussi je ne recommande pas.

Pour la 'e', OK.
Pour /usr, quelle taille prévoir ? Sous Linux, il fait 2 GB, mais je
pense y aller calmement au départ et j'imagine qu'il y a un outil pour
redimensionner les partitions si nécessaire.

Il y a un "growfs" mais c'est de la chirurgie lourde, aussi il est
mieux d'en faire le moins possible. Le système "vinum" permet de rendre
l'opération plus gérable, mais "vinum" rajoute sa propre couche de
complexité.

Après on peut s'arranger. Tout dépend des applications qu'on installe.
J'ai déjà fait tourner du FreeBSD sur 200 Mo en tout ; sur ma machine
de bureau, où je veux plein de place et plein d'applications, j'ai
un /usr de 8 Go (plein à moitié pour le moment).

On peut aussi avoir envie de mettre un /var séparé, surtout si on
installe une base de donnée (genre mysql), car le contenu de la base
sera alors stocké dans /var.

5) AfterStep ?
Est-ce qu'il a été porté sous FriBi ?

Oui. Il y a un port (/usr/ports/x11-wm/afterstep) et donc le package
binaire correspondant sur tout bon miroir FreeBSD.

J'ai les sources Linux, je peux le recompiler sans modif ?

Ça dépend. Si Afterstep n'a pas été programmé avec les pieds, aucune
modification n'est nécessaire. Il reste que certaines modifications
peuvent être souhaitables (pour une meilleure intégration avec l'OS et
le reste des composants installés -- je pense aux polices de caractères,
par exemple) et le mieux est de passer par un package binaire ou par
le port. Le port s'occupe en plus des dépendances (si une application
nécessite l'installation d'un autre port -- une bibliothèque par exemple
-- le port fera la compilation / installation de cette bibliothèque
automatiquement).

Si oui est-ce généralisable à toutes les applis dont j'ai les sources ?

En gros oui. Mais au moins 99% de ces applications ont des ports. Il
existe environ 10000 ports sur un FreeBSD actuel.


--Thomas Pornin

PS : outre NetBSD et FreeBSD, il existe OpenBSD. En première
approximation, c'est comme NetBSD. De toutes façons, tout ce que je
raconte ici est valable uniformément pour les trois *BSD.

Amis du 'Berkeley Screen of Death' bonjour.

:-) Pas trop, le dernier que j'ai eu, j'ai pas apprécié...

J'ai vu sur le ng (VD il y a 4 jours, à propos d'un G4) que NetBSD
aurait «l'émulation linux». Qu'est ce que ça signifie ?
Qu'on peut utiliser des applis dans le usr du pingouin qu'on monterait
dans le root de NetBSD ?

Effectivement, et ca marche très bien. FreeBSD gère aussi l'émulation
Linux et on peut y lancer Netscape, StarOffice, Bash, Java, Maple,
Oracle... Bref tous les trucs pour lesquels ont a pas les source
surtout, ou qu'on ne peut pas compiler sous FreeBSD.

running Linux software on FreeBSD.» et je sais qu'on peut compiler en
dur dans le noyau de FriBi, le support de l'ext2 pour monter mon home.
Alors Free ou Net ?

Ah toi de voir. Pour ma part FreeBSD mais je ne suis pas objectif, je
ne connais pas du tout NetBSD.

Si j'ai bien compris, c'est ainsi qu'on appelle les sources des
applications en y ajoutant une gestion des dépendances et une
automatisation de l'installation et des upgrades. J'ai bon ?

Oui. C'est super pratique a utiliser.

(D'ailleurs en RTFMant, j'ai appris que les packages binaires étaient
plus petits que les sources, c'est marrant j'ai toujours été persuadé
du contraire. Quelqu'un explique ?)

Le code compilé ne prend pas tous ces caractères qui servent a rien, et
donc s'il est dynamique, il est plus léger ?

Exemple:
[nlsn@shiva TP13]% du -shc *.java;du -shc *.class
10.0K Chaine.java
10.0K Naturel.java
20K total (Sources)
2.0K Chaine$Chainon.class
4.0K Chaine.class
4.0K Naturel.class
10.0K total (Programme)

La section 2.5.3 du handbook n'est pas très claire. Si j'installe le
boot manager de FreeBSD, est-ce qu'il me proposera de gérer mon win et
mon tux ?

Oui. Le boot manager de FreeBSD permet de booter 1 des 4 partitions
primaires ou le disque dur suivant (avec les touches F1 a F5). Il a
l'avantage de continuer a marcher meme si tu détruis tes partitions
FreeBSD.

Pour ton windows, qui doit etre sur une primaire, c'est ok. Et pour ton
Linux, il faut que Lilo soit installé quelque part, sur une partition
primaire.

Faut-il au contraire choisir "Leave the MBR untouched" ? Et dans ce cas,
est-il possible de configurer mon lilo pour booter FriBi ?

Oui, tu fais comme tu fais pour Windows, il me semble.

4) Taille des slices ?
J'ai pas très bien compris la distinction entre une partition et un
slice...

Hum. En fait, tu as une slice, c'est une partition au sens MSDOS, c'est
ce qu'utilise Linux. Et les partitions, c'est au sens Unix, il y a un
disklabel (table des partitions (8 ou 16)). Les partitions, elles sont
dans une slice MSDOS.

ad0s1b
^
disklabel b (pas reconnu par linux (ou alors tu le verras en hda9
ou un truc du genre))
^^
slide 1 (hda1)
^^^
disque 0 (hda)

Pour la 'a', c'est OK: 100 MB.

Ca correspond a /

Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?

Ca n'est pas impératif. Je trouve que FreeBSD utilise plus facilement
le swap pour garder un gros cache disque, mais ca reste petit. Si tu
veux garder de l'espace disque, que tu ne sature jamais ta mémoire, tu
n'es pas obligé.

Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?

Il y a un Howto qui traine quelque part qui en parle, c'est possible,
il suffit de refaire un mkswap avant de monter le swap a chaque boot de
Linux.

Par ailleurs, sous FreeBSD, on peut utiliser le swap pour y monter
/tmp, ca permet de gagner de la place (parce qu'avec un / de 100 Mo, tu
ne peux pas y mettre /tmp). (man mdconfig)

Pour /usr, quelle taille prévoir ? Sous Linux, il fait 2 GB, mais je
pense y aller calmement au départ et j'imagine qu'il y a un outil pour
redimensionner les partitions si nécessaire.

Je ne sais pas, en installant tout plein de trucs, toutes les sources,
et les ports, j'arrive a une grosse utilisation, j'ai ca:

Sur mon PC, sachant que c'est mon systeme principal, je n'ai pas linux:
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 145M 89M 45M 67% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad0s1e 50G 44G 2.0G 96% /home
/dev/ad0s1d 11G 5.2G 5.3G 49% /usr
/dev/ad0s1f 1.2G 406M 769M 35% /var
/dev/md0 504M 20K 463M 0% /tmp
procfs 4.0K 4.0K 0B 100% /proc

Sur un serveur, qui a tous les ports, toutes les sources, mais peut
etre pas tout KDE et tout GNOME, meme s'il y en a des morceaux.
Filesystem Size Used Avail Capacity Mounted on
/dev/amrd0s2a 145M 90M 43M 68% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/amrd0s2g 32G 12G 18G 40% /a1
/dev/amrd0s2h 5.8G 4.5G 867M 84% /a2
/dev/amrd0s2d 11G 3.0G 7.5G 28% /usr
/dev/amrd0s2e 4.7G 381M 4.0G 9% /var
/dev/amrd0s2f 9.5G 4.9G 4.6G 52% /var/news
/dev/md0 1008M 6.3M 921M 1% /tmp

5) AfterStep ?
Est-ce qu'il a été porté sous FriBi ?

Oui, tu as le port. Normalement, toute bonne appli Linux peut meme se
compiler sans passer par les ports.

J'ai les sources Linux, je peux le recompiler sans modif ?

Normalement... Mais il y a pas mal d'appli qui ont des petits patchs
inclus dans les ports.

Si oui est-ce généralisable à toutes les applis dont j'ai les sources ?

Globalement, oui. Mais si tu fais ca tu perd la gestion des dépendances
(via les ports).


--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )