NetBSD , etat des lieux.

Eric Masson devait dire quelque chose comme ceci :

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.

Mouaif, tu le lances avec le flag -P et zou, si tu fais une toile, tu as
la possibilité de récupérer ce que tu as écrasé.

Et l'obligation de revérifier à la main pour voir si tu t'es planté ou
non. Parce que si te le savais au moment où tu as merdé, tu n'aurais
pas merdé.
En fait, la plus part du temps, il suffirait d'un rappel en début
d'écran ( original | nouveau ), pour aider à différencier d'entrée ce
qui est à droite de ce qui est à gauche. Mais ça obligerait de modifier
le script puisqu'il passe par /more/ si je ne m'abuse.

Maintenant, personnellement je n'ai pas mieux à proposer, donc...

Ben vala, c'est effectivement le point intéressant, dire que mergemaster
c'est nul sans proposer autre chose, que ce soit un outil ou une autre
manière de procéder, ça me semble un poil léger, mais bon...

C'est pour ça que j'explique pourquoi je le trouve imbouffable, le
retour de l'utilisateur en quelque sorte.

Manuel Bouyer n'était pas loin de dire :

[...] mais
il faut aussi acheter le materiel en fonction de ses besoins, et non pas
acheter le materiel et voir ensuite ce qu'on peut en faire.

Oui et non. Pourquoi acheter du matériel alors qu'il existe déjà ? Que
ce soit un particulier ou une petite entreprise, au lieu de changer
l'ensemble du parc matériel, le passage des serveurs sous *BSD permet
de gagner en puissance tout en conservant du matériel ancien, voir en
recyclant une partie des machines qui servaient initialement aux
employés. Ca ne sera pas valable pour toutes les utilisations, mais une
petite entreprise n'a pas besoin d'une puissance infinie pour gérer son
parc client, par exemple.


[Snip le modèle de développement de NetBSD]

Mais non, pas du tout justement. [...]

C'est pour cela que je pose la question. Je regarde le projet de
l'extérieur, n'ayant pas les compétences pour le faire de l'intérieur,
donc je me renseigne. Et ta réponse m'a appris des choses, merci.

Manuel Bouyer devait dire quelque chose comme ceci :

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.

Tres mauvais exemple le SMP (pour toi, et tres bon pour moi). [...]

C'était à prévoir, mais bon, c'était avant tout un exemple pour
expliquer la façon dont je percevais les choses.

Tiens, j'en profite de ton message pour remercier toutes les personnes
qui ont répondus, principalement celles à qui je ne répondrais pas
parce que, ben je n'ai rien à répondre.
J'ai appris pas mal de choses, principalement des éléments qui sont
invisibles aux utilisateurs qui ne sont pas au coeur du projet, et
c'est avant tout ce que je souhaitais.

Miod Vallat n'était pas loin de dire :

ne les paratage pas. Du coup, les tentatives de fork que furent
EkkoBSD, MirBSD et dans une (nette) moindre mesure MicroBSD ont
échoués. Si le premier existe peut-être encore (quelqu'un pourrait le
dire ?), MirBSD n'en fini pas de se chercher, et MicroBSD ressemblait
plus à une vengeance contre Théo qu'autre chose.

Sur ce point, il faut relativiser, ce sont de mauvais exemples :

Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes yeux,
ce sont justement de bons exemples. Que ce soit parce que la créativité
individuelle se retrouver bridée, ou parce qu'au contraire il fait bon
travailler dans un projet dont l'on connait précisément l'orientation
du moment, un modèle dictatorial n'incite pas à développer ses propres
idées dans son coin.

- MirBSD est le plus abouti de ces forks, [...]

Bof. J'ai dû mal à considérer ce projet comme abouti, alors qu'il
n'arrête pas de changer d'orientation. D'un autre côté, l'absence de
développeur pour le kernel explique aussi beaucoup de chose, notament
ces fréquents changements. Ils sont obligés de s'appuyer sur quelque
chose d'existant et développé par d'autres, ça ne facilite pas le
travail.

Emmanuel Dreyfus n'était pas loin de dire :

Hélàs je penche pour cette solution. Il y aurait un gros travail de
packaging et de pre-configuration des applis de bureautique pour qu'un
BSD soit lambda-friendly.
Bof. J'ai passé une semaine pour configurer X.org, mais c'est

uniquement parce que je suis tétu. Lorsqu'il utilisait la configuration
par défaut (i.e. sans fichier de conf extérieur) il fonctionnait à
merveille, même si les performances étaient un peu dégradée. C'est très
user-friendly façon Microsoft ça.

Y'a pas que le serveur X à configurer pour atteindre une config
bureautique accessible à l'utilisateur lambda.

Sur FreeBSD, je serais tenté de dire que si, vu que c'est la seule
chose qui m'a demandé plus de dix minutes d'implication personnelle. Le
reste, en gros il suffit de cliquer et ça marche. Même au niveau de
l'installation de l'OS en lui-même, il n'y a pas à proprement parler de
problèmes.

Michel Talon n'était pas loin de dire :

[Mergemaster]

Réponse: tout ça devrait être entièrement automatique. 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.

Le pire, c'est que c'est partiellement faisable. Pour rc.conf par
exemple, qui est le fichier qui diffèrera à coup sûr, les lignes
correspondant à une même configuration sont clairement identifiables.
/sendmail_enable="NONE"/ et /sendmail_enable="YES"/, c'est la même
chose, pas besoin de demander à l'utilisateur s'il veut garder sa
configuration. S'il l'a changé c'est qu'il veut que ce soit comme cela.
Reste le cas des options de configuration qui ont été ajoutée entre
temps, et qui ne correspondent pas forcément à ce que l'utilisateur
voudrait pour sa machine. Mais là non plus il n'y a pas vraiment de
question à se poser, on ajoute la ligne, avec un commentaire style "#
ADDED BY MERGEMASTER [date]" avant la ligne, on liste les fichiers
modifiés à la fin du programme, et l'utilisateur fait le ménage
lui-même.

Michel Talon devait dire quelque chose comme ceci :

Et c'est là où je ne suis pas d'accord avec Michel
Talon.
Faire une version en français d'un document n'est pas une perte de
temps, mais plutôt un moyen de montrer que ce n'est pas aussi compliqué
qu'il ne peut y paraître au premier abord. Et tant pis si dans un
premier temps il n'y a que trois lecteurs.

Ca se voit que tu n'as pas l'expérience de ces choses.

Et pourtant, si, <http://bsd.sc4x.net>. La seule doc en ligne
mériterait largement d'être mise à jour et complétée, mais elle reçoit
quand même deux à trois visiteurs par mois. Pour un site dont je ne
fais pas la pub et que google doit ressortir en dix millième position,
ce n'est pas si mal je trouve.

De ma doc en anglais j'ai eu exactement 3 échos. [...]

Je n'ai eu que deux échos pour mon site, mais ça c'est une question
d'habitude. J'ai un autre site, confidentiel aussi, qui reçoit une
dizaine de visiteurs par jour depuis quatre ans. Son livre d'or est
desespérément vide.
Dans l'ensemble les gens n'aiment pas donner leur avis, il faut s'y
faire et ne tenir compte que des logs du serveur pour savoir si c'est
lu ou non.

Le snobisme à outrance ronge ce milieu jusqu'à la moelle.
Les mecs te disent, critiquer ne sert à rien il faut proposer du code ou de
la documentation. Certes j'achète l'argument. Mais je te parie tout ce que tu
veux que si tu proposes que ce soit l'un ou l'autre, on t'enverra sur les
roses immédiatement.

Lorsque l'on te répond, oui, je connais ça. J'ai déjà fait quelques
commentaires, sans obtenir de réponse de l'a part de l'auteur. Je suis
d'ailleurs du même acabit moi-même. Mais mes commentaires ont été pris
en compte.
Cependant, que ce soit en tant que lecteur ou qu'auteur,
personnellement cela ne me dérange pas. Lorsque j'ai écrit cette doc,
et lorsque j'écris celles qui ne sont pas en ligne car rarement
terminée, je ne le fais pas pour moi ou pour avoir des retours, mais
pour aider les personnes qui passeraient par là.
Dès lors, même si j'apprécierais que l'on me signale qu'ici ou là j'ai
dit une connerie, car cela peut m'arriver, ou alors que l'on me dise
qu'il y a une façon plus simple de faire ceci ou cela, je me moque de
l'absence de retour. Tant que cela à pu aider quelqu'un, tant pis s'il
est égoïste et ne veut pas me le dire, ça a été utile, c'est tout ce
qui compte.

[...] Bref le mec reste comme un con avec ses 10 lignes de C,
la solution qu'on lui propose c'est d'utiliser gawk. Alors pourquoi
avoir un awk inférieur dans le système, et plus généralement pourquoi ne
pas utiliser Linux?

Je répondrais au niveau de l'utilisateur lambda, en redéfinissant donc
ton exemple sur la seule partie que je cite :
Pourquoi ? Parce qu'il faut bien commencer quelque part. Ce n'est pas
ce qu'il y a de mieux, ce n'est pas la meilleur façon de le faire avec
du *BSD, mais c'est une façon de le faire. Qui plus est, l'impact en
terme d'image est plus intéressant dans ce cas. Un "quoi ? Tu faisais
comme ça ? Mais, sais-tu que l'on peut faire ceci-cela", démontrera
mieux la puissance/simplificité/autre du système, que si l'on apprenait
tout de suite à l'utilisateur la "façon *BSD".
Je vois ça par exemple avec les personnes qui ont migrés de Linux à
FreeBSD, et qui utilisait hostname(1) avant de découvrir ébahi que l'on
pouvait fixer ça au niveau de /etc/rc.conf.

Emmanuel Dreyfus devait dire quelque chose comme ceci :

Un projet comme NetBSD n'a pas à proprement parler de direction
technique qui établit ce qui doit évoluer et comment. C'est bien plus
les contributions des individus qui pilotent le projet, ce qui laisse
pas mal de la place au p'tit nouveau qui veut s'exprimer.
Mais cela fait aussi que, soit le projet (i.e. tous projets gérés de

cette façon) part dans tous les sens, soit il tend à stagner. De plus,
qu'est-ce qui fait que NetBSD diffère à ce point d'autres projets
disposant eux d'une direction technique, quelque soit sa forme ? Je ne
vois pas pourquoi, si ce n'est pour des raisons historiques et/ou
peut-être d'égo, NetBSD ne pourrait pas se tourner vers cette forme.

Faudrait déjà que les developpeurs soient d'accord sur ce diagnostic.

Sont-ils d'accord sur quelque chose ? Je plaisante, évidement, mais
plus je lis cette discussion, plus j'ai l'impression que les
développeurs ne sont jamais d'accord entre eux ;-)


[Snip]

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.

Dans ce cas, n'est-ce pas, entre autre, aux développeurs de changer
cela ? Ta propre vision est biaisée, personnellement je définis plutôt
NetBSD comme un OS tous matos, ce qui est un plus lorsque le parc
machine est hétérogène. Une foule de machine, mais un seul OS à
maitriser pour toutes les unifier.
Du coup, une entreprise qui se monterait n'a qu'à embaucher un admin
système qui maitrise NetBSD, et faire ensuite les rebus informatique
pour s'équiper. Du Sun, De l'Amiga, quelques Alpha, et la salle
informatique est montée à moindre frais avec du matériel qui reste
performant et un OS qui saura en tirer le meilleur.
En tant qu'utilisateur, même si j'ai tendance à considèrer ce large
support d'architecture comme un frein pour le développement du
projet[1], je le vois aussi comme l'atout majeur du projet par rapport
à ses concurrents.


[1]
Enfin, moins depuis que cette discussion à commencé.

D'ailleurs comment pourrait il en être autrement, dans un projet de
bénévoles?
Linux, OpenBSD, etc. ne sont pas des projets de bénévoles ?

Linux n'est absolument pas un projet de bénévoles. Nombre de
contributions sont directement financées par des entreprises à vocation
commerciales.

Je ne trouve pas que l'un empèche l'autre. Ces entreprises n'ont
aucune obligation, c'est d'elles-mêmes qu'elles décident d'agir ainsi,
parce qu'un Linux correspondant à leur besoin est un plus pour elles.
Bon, la GPL les obligent dans la plus part des cas à retourner le code
source, et donc à contribuer, mais à mon sens ce n'est pas la seule
explication.
Prend FreeBSD, par exemple. Si Yahoo avait fait un retour total de ses
modifications, le projet aurait-il cessé d'être bénévole pour autant ?
S'ils pouvaient avancer la même pénétration et la même notoriété que
Linux, au niveau du grand public, les projets *BSD bénéficieraient du
même support de la part d'entreprises, pour autant ce ne sont pas elles
qui commandent, et ce n'est pas parce qu'elles ammènent du code, qu'il
doit être accepté.
Et ne parlons pas des entreprises conciliantes qui acceptent que leurs
employés passent une partie de leur temps à développer pour ceci ou
cela, tant qu'ils font correctement leur travail par ailleurs. Les
développeurs cessent-ils d'être bénévole parce qu'une partie de leur
travail est finalement rémunéré par une entreprise ?

Quand à OpenBSD, je ne suis pas certain qu'on puisse dire qu'il ait
moins de lacunes à combler que NetBSD. Ce ne sont pas les mêmes, mais
c'est un autre OS qui souffre d'un faible nombre de contributeurs (pour
des raisons différentes, cela dit)

C'est cependant un projet bénévole qui avec une direction technique
qui impose une évolution. Et un projet qui évolue, même s'il pourrait
le faire mieux et plus vite.


[Snip]

Une direction technique n'est pas à proprement parler là pour imposer
quoi que ce soit, mais pour préparer le terrain. Il est plus facile de
discuter à dix de la faisabilité d'une proposition et de la façon dont
elle doit être mise en oeuvre, que d'avoir la même discussion avec
quelques centaines de personnes peuvent donner leur avis. La dizaine de
personne à la tête du projet fini par se connaitre, par comprendre ce
qui se trouve entre les lignes, ce qui facilite les discussions et
permet d'arriver rapidement à une conclusion.

On a le groupe core pour résoudre les discussions où aucun consensus
n'emmerge. C'est un petit groupe, qui se connait, etc...

C'est donc, amha, prendre le problème à l'envers.

Emmanuel Dreyfus n'était pas loin de dire :

[...] mais vu que
je ne suis pas payé pour, si ca ne m'ammuse pas, pourquoi le faire? Je
ne suis pas masochiste, hein...

Parce que tu aimes le projet et que tu es prêt à faire, *parfois*, un
petit sacrifice pour que le projet avance dans la bonne direction ?

Benoit Izac n'était pas loin de dire :

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

Note que je ne faisais que suggérer des idées,

Moi aussi, moi aussi, même si mon poste de travail est multi-OS.

-- 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).

Oui, mais le grand public à rarement besoin de faire du dessin
industriel à la maison. Par contre jouer, étrangement il aime bien ;-)

[...]

-- 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.

Pour les uns et les autres, il faut télécharger le programme qui va
bien. Et là c'est parfois la croix et la banière. Pour installer la
dernière version de flash sous Windows, il a fallut que j'aille piocher
du côté du FTP, impossible de trouver sur le site un lien vers
l'installeur supportant les autres navigateurs de IE. Et dans
l'ensemble c'est valable pour les autres formats. Tant que tu restes en
100% microsoft, c'est facile, mais si tu en sors c'est un calvère.
A l'inverse, pour Linux et les *BSD, lorsque tu as le binaire, il
fonctionnera pour ce que tu as, quoi que ce soit. Mais il faut d'abord
que le binaire existe.