NetBSD , etat des lieux.

Stephane Catteau <steph.nospam@sc4x.net> wrote:

Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ? Michel Talon exagérait en parlant de machine que l'on ne
trouvait plus que dans les musées, mais crois-tu vraiment que les
développeurs qui s'occupent du support pour Vax ne sont que des
fanatiques de Vax et ne seraient pas prêt à bosser aussi sur, disons
les Sun, qu'ils ont aussi à disposition ?

Ben si, ca arrive.

Dans le projet NetBSD, j'ai fait un certain nombre de choses dont
l'intérêt était plus que limité (genre la compatibilité binaire avec
IRIX sur station SGI). Je les ai fait surtout parceque ca m'ammusait.

C'est clair qu'il y aurait eu tout un tas de choses auquels j'aurai pu
collaborer et qui auraient été plus utiles pour le projet, mais vu que
je ne suis pas payé pour, si ca ne m'ammuse pas, pourquoi le faire? Je
ne suis pas masochiste, hein...

Soit dit en passant, mettre au point la compatibilité binaire IRIX a
permis d'aller piocher des bonnes idées dans IRIX qui ont ensuite été
adapté à NetBSD, comme quoi rien n'est vraiment sterile.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org

Stephane Catteau <steph.nospam@sc4x.net> wrote:

Il y a encore quatre ans, lorsque j'ai opté pour FreeBSD sur mon
réseau à moi que j'ai, j'ai longtemps hésité à prendre NetBSD. A
l'époque, c'était lui qui revenait le plus souvent, non pour ces
qualités intrinsèque, mais parce qu'il tournerait quelque soit le
matériel choisi. Apparament, ce n'est plus le cas, et c'est dommage.

Ca n'a jamais été le cas. NetBSD a depuis le premier jour été conçu pour
fonctionner sur plusieurs architectures différentes. Il s'agit d'ecrire
des sous-systèmes le plus machine-indépendants possibles, pour que la
maintenance des nombreuses architectures soient la plus légère possible.

NetBSD supporte ainsi de nombreuses architectures, avec les mêmes
sources, et avec des fonctionnalités la plupart du temps au même niveau
sur les différentes plateformes.

Toutefois, il reste le support du matériel, qui n'est pas forcément plus
brillant que sur d'autres OS. NetBSD n'a pas inventé de methode miracle
qui lui permettrait de supporter toutes les cartes réseaux immaginables.
Pour qu'on ait un driver, il faut qu'un developpeur ait eu le materiel
entre les mains, les competences dans la tête, et les heures libres dans
son emploi du temps.

Par contre, une fois qu'un driver a été écrit pour une architecture, il
est utilisable pour les autres.

Lorsqu'un système doit tourner sur un maximum de plateforme, comme tu
le dis toi-même on se trouve confronté à un problème d'adéquation entre
les développeurs à même de faire ceci/cela et la disponibilité, pour
eux, du matériel pour lequel il faut le faire. Du coup, une part des
développeurs doit, *tel que je le perçois de l'extérieur*, devenir des
touches à tout, et s'occuper aussi bien d'adapter le kernel pour la
machine qu'ils ont sous la main, qu'adapter les drivers pour les
différents périphériques compatibles avec la-dite machine.

Ben non, justement: avec des drivers machines indépendants, on ne perds
pas de temps en maintenance sur les architecures exotiques. Voir la
réponse de Manuel Bouyer sur le sujet.

Et ca va même plus loin: comme il n'y a pas besoin de re-ecrire des
drivers, ca va vite pour faire leportage sur un nouvel OS. NetBSD/amd64
a ainsi été pondu en 15 jours par un seul developpeur.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org

Le Sun, 10 Sep 2006 13:37:26 +0200, Patrick Lamaizière a écrit :

Ben ici ça marche (iwi ou ndis) ©

Ben là, manifestement, ça marche pas (tm) ;-)
Note bien que je n'exclue pas le bug interface chaise-clavier ;-)

Si la carte figure comme carte wifi reconnue dans dmesg,
Si on a chargé le module wlan_wep (c'est bien nécessaire, n'est-ce
pas?),
Si on a tapé un truc du genre:
# ifconfig iwi0 inet 192.168.0.20 netmask 0xffffff00 ssid
my_net wepkey 0x01020304050607080910111213 weptxkey 1 wepmode on

Et que ça ne passe jamais en status "associated" mais que ça reste en
"no carrier", kékonfé?

PS: tu vas me dire que j'exagère, mais j'ai acheté la carte intel 2200bg
il y a peu, donc je ne l'ai pas testée sous FreeBSD (seulement sous
NetBSD 3.0), par contre j'avais testé sans succès ndis sous FreeBSD 6.0
et 6.1.

Bonjour,

le 10/09/2006 à 15:39, Michel Talon a écrit dans le message
<ee14ie$14oi$1@asmodee.lpthe.jussieu.fr> :

Il me semble que des outils de la convivialité de mergemaster
auraient pourtant du dissuader l'auteur de sévir à nouveau.

Quel est le problème avec mergemaster ?

Preuve n°2 de ce que je disais. Ne pas reconnaître mergemaster pour ce
qu'il est, c'est l'esprit de chapelle, c'est le même genre que les
amoureux de dselect sous Debian, on se croît "élite" parcequ'on
arrive, aprés maintes essais et erreurs à manipuler un outil
totalement merdique.

Dis plutôt qu'il ne te convient pas plutôt que de cracher dessus (les
goûts et les couleurs ...).

Comment ça se fait d'ailleurs que je n'ai pas besoin d'utiliser un
outil analogue à mergemaster pour upgrader une machine sous Debian?

Parce que Debian fait ces propres fichiers de configuration par défaut
mais ils ne conviennent pas forcément à tous les utilisateurs. J'ai
utilisé Debian pendant au moins deux années et je ne suis pas prêt à le
réinstaller pour au moins deux raisons :

- le découpage d'un paquet en plein de petits paquets. Lorsque je
veux installer un logiciel xxx, je ne veux pas installer
xxx-client, xxx-serveur et xxx-doc. Si je n'ai pas besoin de la
doc, je ne la lit pas mais au moins elle est disponible le jour où
je le souhaite (avoir les sources est aussi un plus). Si je ne
veux pas du serveur, je ne le lance pas et il ne me prendra que
quelque Ko en plus sur le disque. J'ai commencé à lire ton
document sur les ports et bien que je trouve ton travail
remarquable, le passage comparant le nombre de paquets disponibles
sur Debian et FreeBSD n'a aucun sens ; d'une part en raison du
découpage des paquets sous Debian, d'autre part les différentes
versions disponibles sous FreeBSD (par exemple openldap-2.[234]).

- lorsque j'installe un service, je veux le configurer _avant_ qu'il
ne soit lancé. Et sous Debian, tu fais apt-get install xxx et hop
comme par magie et souvent sans question préalable le service est
lancé et en écoute sur un port. C'est peut-être ce que cherche la
majorité des gens mais pas moi.

Réponse: tout ça devrait être entièrement automatique.

Impossible : comment le système peut-il deviner dans un fichier texte
quelles lignes _tu_ veux garder (car _tu_ les as modifiée) ? Sans ton
intervention, je doute qu'il n'y arrive.

D'ailleurs il y a des susystèmes qui améliorent l'automatisme comme
etcmerge. Mais le seul but valable est que ce soit entièrement
automatique.

Je ne connais pas etcmerge.

--
Benoit Izac

Bonjour,

le 10/09/2006 à 14:12, Stephane Catteau a écrit dans le message
<mn.53547d69307cddfc.30736@sc4x.org> :

[...] Pourquoi les utilisateurs lambda francophones, moi y compris,
ont-ils autant de mal à faire d'un *BSD leur système principal, voir
leur seul système ?

Je ne suis pas persuadé que ce soit différent entre les francophones et
le reste du monde mais voici quelques idées :

[...]

-- c'est plus simple sous Windows et dans une certaine mesure sous
certaines distibutions Linux et tu n'as pas le temps ou l'envie
d'apprendre à faire l'équivalent sous BSD ;

Ca commence mal, je ne suis pas d'accord avec toi.

Note que je ne faisais que suggérer des idées, ça ne reflète pas mon
opinion car ma machine personnelle est uniquement sous FreeBSD depuis
maintenant deux ans.

[...]

-- tu disposes d'un logiciel indispensable (typiquement un jeux) qui
n'a pas d'équivalent sous BSD ;

Ce n'est pas faux, mais au niveau de l'utilisation personnelle, il n'y
a guère que les jeux qui n'aient pas d'équivalent sous *BSD.

C'était plus un clin d'½il pour mettre en relation indispensable et jeux
que j'ai choisi cet exemple. Il y a quand même des logiciels
professionnels qui n'ont pas d'équivalent (dessin industriel par
exemple).

[...]

-- les fichiers que tes amis/collègues t'envoient par mail ne sont
pas lisibles sous BSD car en format propriétaire et seul Windows
dispose des logiciels pour les lire (gratuitement en plus) ;

Gratuitement c'est vite dit. La moitié des documents Word ne passent
pas dans wordpad, il n'y a pas de lecteur pour Excel, et ainsi de
suite. A la limite, OpenOffice s'en sort mieux qu'un Windows sortie
d'usine.

Je pensais plutôt à des formats comme quicktime (dernière version),
flash ou shockwave.

[...]

--
Benoit Izac

Bonjour,

le 10/09/2006 à 14:31, Stephane Catteau a écrit dans le message
<mn.53677d69a4ea1ccf.30736@sc4x.org> :

Quel est le problème avec mergemaster ?

C'est imbouffable. Une fois sur deux je me demande si je suis entrain
de garder mes modifications ou de tout foutre en l'air. Et une fois sur
trois je suis vraiment entrain de tout foutre en l'air.

Je le trouve vraiment pratique :

Incidemment, l'option -U est apparue dans les dernières versions, qui
devrait rendre le processus encore beaucoup plus simple. Elle permet
d'auto-upgrader des fichiers qui n'ont pas été modifiés par
l'utilisateur, c'est-à-dire 99% du temps, tous les répertoires default,
tous les scripts rc, les répertoires mtree, etc.

J'ai pas encore eu l'occasion de l'utiliser, par contre... :)

Fred
--
25 grams of wafers and 20 ml of wine undergo transubstantiation and
become the flesh and blood of our Lord. How many Joules of heat are
released by the transformation?
(Theological Physics exam, 1997, stolen from Tanuki the Raccoon-dog)

F. Senault n'était pas loin de dire :

[...] Comment veux-tu arrêter de soutenir le projet ? Ordonner au mec
de se mettre à bosser sur PC parce que c'est plus porteur ? Tu crois
vraiment que tu vas *récupérer* quelqu'un dans l'open source, ou juste
le voir se barrer ailleurs avec son fork ?

Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ? Michel Talon exagérait en parlant de machine que l'on ne
trouvait plus que dans les musées, mais crois-tu vraiment que les
développeurs qui s'occupent du support pour Vax ne sont que des
fanatiques de Vax et ne seraient pas prêt à bosser aussi sur, disons
les Sun, qu'ils ont aussi à disposition ?

S'ils étaient prêts à bosser sur une autre plateforme, ils le feraient,
c'est le principe du bénévolat. S'ils ne le font pas, c'est bien qu'ils
en ont moins envie, non ?

De plus tu réduis le problème aux cas particuliers des architectures
soutenues, oubliant l'ensemble du projet. Si les développeurs Vax fork
et créent un BSD purement Vax synchronisé sur NetBSD, pourquoi pas.
Dans le même temps, NetBSD n'aura plus à attendre qu'ils aient adapté
les modifications avant de pouvoir passer à la suite.

Je ne pense pas que ça fonctionne comme ça. Je n'ai _vraiment_ pas
l'impression qu'on attend qu'un développeur ait fini quelque chose pour
continuer le développement sur le reste du projet.

Oh, et aussi, il semblerait qu'une des grandes forces du projet vienne
du travail sur les couches d'abstraction, qui permettent tout de même de
développer à peu près (exactement ?) de la même manière sur toutes les
plateformes. Cela signifie en théorie que l'ajout de chaque plateforme
est de moins en moins difficile et devrait permet d'ajouter beaucoup
plus facilement d'autres archis *modernes*. (IIRC, NetBSD a été le
premier OS open source à supporter l'AMD64, non ?)

De même, qu'est-ce qu'ils en ont à faire, eux, du SMP ou de ceci/cela
? Comment une équipe peut-elle avancer dans une direction si la moitié
de ses membres n'en ont rien à faire de cette direction et se tourne
donc les pouces (façon de parler) ? Amha ça n'aide pas vraiment à avoir
une bonne ambiance.

Je crois que tu ne réalises pas du tout comment fonctionne le
développement sur un projet de cette taille. La répartition des tâches
est à la fois beaucoup plus granulaire que ça, et chaque dev' a
certainement pas mal de casquettes / projets sur lesquels travailler
simultanément, il me semble.

Note: j'ai pris Vax en exemple, mais d'autres sont peut-être plus
significatifs.

Fred
--
Some days violence is just a nice quick solution to a problem that would
need thought, planning and actual work to do justice to.
(Wayne Pascoe in the SDM)

/.../

Franchement, qui va choisir un OS parcequ'il tourne bien sur du vieux
matos? Tant que les domaines d'applications des BSD seront vus comme
"FreeBSD pour les PC, OpenBSD pour la sécurité et NetBSD pour le vieux
matos", NetBSD aura du mal à être dynamique.

Il faut créer les niches. Franchement, j'ai basculé deux bécanes chez
moi de Free vers Net pour réussir à faire tourner racoon convenablement.
Et, à l'heure actuelle, je suis très satisfait de NetBSD i386/amd64 dans
sa position de firewall / routeur internet / concentrateur VPN, il n'y a
pas de raisons que j'installe autre chose si je dois remettre une
machine équivalente quelque part.

Fred
--
Our chief weapons are 'who', 'ps -aux', 'kill -9', and a fanatical
devotion to 'fastboot'.
(Sun User Group)

F. Senault <fred@lacave.net> wrote:

Incidemment, l'option -U est apparue dans les dernières versions, qui
devrait rendre le processus encore beaucoup plus simple. Elle permet
d'auto-upgrader des fichiers qui n'ont pas été modifiés par
l'utilisateur, c'est-à-dire 99% du temps, tous les répertoires default,
tous les scripts rc, les répertoires mtree, etc.

Et il a fallu combien d'*années* et de discussions à perte de vue pour
introduire cette option si pratique et complètement évidente?

--

Michel TALON

"F. Senault" <fred@lacave.net> writes:

'Lut,

Il faut créer les niches. Franchement, j'ai basculé deux bécanes chez
moi de Free vers Net pour réussir à faire tourner racoon
convenablement.

Pareil ici, d'ailleurs je vais bientôt devoir regarder du coté de la
répartition de charge entre deux accès internet avec une passerelle sous
Net.

--

Je ne veux pas lancer un débat (sinon je mettrait ça sur fcold) mais
j'aimerais plutôt savoir ce que les autres en pensent, comment ils ont
configuré ça, s'ils aiment...
-+- GA in Guide de linuxien pervers - "Le premier qui débat aura un gage"