NetBSD , etat des lieux.

Benoit Izac devait dire quelque chose comme ceci :

[...] 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 possible, mais vu mon faible niveau en anglais, je connais
surtout l'état des lieux chez les francophones.

-- 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. Windows est plus
simple en apparence, mais en apparence seulement. La plus part des
utilisateurs se contentent de la configuration d'usine parce qu'il est
difficile, et parfois même dangeureux, de se plonger dans les
entrailles du système pour le faire.
Personnellement, j'ai commencé par FreeBSD et ce n'est qu'après que
j'ai fait un peu mumuse avec du Linux. En quoi, deux mois je controlais
suffisement le système pour lui confier la sécurité du réseau (de deux
postes de travail à l'époque), et un mois plus tard je maitrisais
suffisement le système pour plonger dans les pages man et tenter des
bidouillages d'équilibristes. Pourtant, je ne suis ni informaticien ni
même scientifique, mon domaine c'est plutôt le littéraire.
Du coup, plus que la simplicité apparente de Windows qui favoriserait
ce dernier, c'est amha la difficulté suposée des *BSD qui les
défavoriserait. 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. Ce n'est pas en maintenant
une aura d'élitisme autour du système, ne serait-ce qu'en obligeant les
utilisateurs à comprendre l'anglais jusque dans les moindres doc que
l'on peut trouver sur le net, que l'on arrivera à attirer des
utilisateurs. Dès lors que trois personnes peuvent dire, ici il y a une
doc en français concernant les ports, et bien pourquoi ne pas tenter
l'aventure ? Qu'importe si mon anglais est limité, l'aide sera en
français, je pourrais donc rien qu'à la lire savoir si c'est à ma
portée ou non, sans en plus être rebuté par la lenteur, et les erreurs
éventuelles, dû à sa traduction par mes soins.

-- 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. Plus le
temps passe, plus l'ordinateur s'introduit massivement dans les
familles. Le petit rentrant en, disons seconde, il lui faut un
ordinateur. Pourquoi ne pas lui piquer de temps en temps pour jouer, et
utiliser l'antiquité du salon comme poste principal sous *BSD ? Le
dernier Windows ne tournera pas dessus, mais n'importe quel *BSD tourne
sur n'importe quel PC d'il y a une dizaine d'années.

-- une partie de ton matériel informatique ne fonctionne pas sous
BSD (scanner, imprimante, modem...) ;

Bof. Peut-être me trompé-je, mais j'ai l'impression que ce n'est plus
aussi vrai maintenant que cela pouvait l'être dans le temps. De plus,
certains fabricants, NVidia par exemple, se mettent à développer des
drivers pour *BSD. Plus la communauté pourra se targuer d'utilisateurs
"personnels", plus les fabricants seront prêt à prendre sur eux pour
développer les drivers.

-- 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.
Cela dit, le problème est valable aussi dans l'autre sens, rare sont
les utilisateurs de Windows qui peuvent s'en sortir avec les formats
ouverts.

-- ton poste est utilisé par d'autres personnes et il ne te
viendrait pas à l'idée de leur imposer BSD (dont ils ignorent
l'existence) ;

Le mien non, j'ai réglé le problème en achettant un ordinateur pour
les autres ;-) De toute façon, cela explique pourquoi il y a deux OS
sur la machine, mais pas pourquoi l'on a nous même par trop tendance à
utiliser le "mauvais".

-- BSD n'est pas fait pour l'utilisateur lambda.

Là non plus je suis loin d'être d'accord. Pourquoi ne serait-il pas
fait pour l'utilisateur lambda ? Même mon fils (onze ans et sur windows
depuis qu'il a quatre ans) ne s'en sort pas trop mal lorsqu'il utilise
le mien. Aucun *BSD ne correspond à la vision Windows d'un OS
personnel, mais ce n'est pas pour autant qu'ils ne sont pas fait pour
un utilisateur lambda.

Pourtant j'ai plus de machines sous FreeBSD à la maison que de
machines faisant tourner un autre système, mais mon poste principal
est mixte.

Libre à toi de rester du côté obscur de la Force. ;-)

Je crois en fait que c'est la flemme de changer mes habitudes. Tous
les logiciels que j'utilise ont un équivalent sous FreeBSD, mais les
habitudes c'est dur à perdre.

Emmanuel Dreyfus n'était pas loin de dire :

-- BSD n'est pas fait pour l'utilisateur lambda.

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.
J'ai un peu l'impression que vous êtes trop informaticiens et
sur-estimés ce qu'un utilisateur lambda attend d'un logiciel. Pour lui,
tant qu'il s'installe et fonctionne, le reste importe peu. De toute
façon l'utilisateur lambda ne sait pas qu'il n'utilise que 10% au plus
des capacités du logiciel.

Thierry Thomas n'était pas loin de dire :

-- BSD n'est pas fait pour l'utilisateur lambda.
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.

C'est le but de DesktopBSD et de PC-BSD, et on dit qu'ils n'en sont pas
loin. Après, il reste à le faire savoir... Quand un utilisateur lamda
décide d'utiliser un OS « alternatif », il y a de fortes chances qu'il
pense à la distribution Linux à la mode du jour.

Pourquoi ferait-il autre chose ? Regarde cette discussion, tout le
monde dit que Linux est plus simple qu'un BSD. Pourquoi l'utilisateur
ne croirait-il pas les spécialistes que vous êtes ?
Pourtant vous avez tord sur ce point. FreeBSD, puisque c'est celui que
je connais le mieux, est simple. Il n'a pas la même logique que
Windows, mais ce n'est pas pour autant qu'il doive être considéré comme
compliqué ou hermétique.

Emmanuel Dreyfus devait dire quelque chose comme ceci :

Faire une distribution orientée bureau ne se limite pas à fournir
OpenOffice. Il faut packager tout un tas de logiciels (window manager,
panaux de configuration, etc...), avec des fichiers de config qui vont
bien, histoire que quand on aille choisir OpenOffice dans un menu du
windowmanager, ca ne réponde pas qu'il n'est pas là où on le cherche.

Les applications elles-mêmes posent peu problème, c'est surtout le
bureau qu'il faut configurer.

Euh ? Je n'ai eu aucun de ces problèmes avec le FreeBSD de mon poste
de travail (les autres n'ont même pas X donc...). Et pourtant je ne me
suis pas cassé la tête, dans l'ensemble j'ai installé le package,
parfois compilé le port pour flatter mon égo, et puis c'est tout.

Francois Zellinger devait dire quelque chose comme ceci :

Et alors. D'abord, je pense qu'on n'a pas besoin d'être « grand », et plus
qu'un sytème d'exploitation devient « lambda-friendly » ou « destop », moins
il c'est un vrai unix (cf les distris commerciales Linux).

Comme on peux s'attendre à ce que tout le monde saches lire et écrire, une
qu'une meilleure documentation, à l'exemple de celle de FreeBSD serait la
seule chose vraimemt nécessaire.

Avec éventuellement des docs qui entrent plus dans les détails de tels
ou tels point précis, quitte à macher un peu le travail pour le
lecteur. Une fois qu'il a réussi à installer le système sans tout faire
sauter, l'utilisateur lambda se dit qu'après tout il n'est pas aussi
bête que cela et qu'avec un petit coup de main il devrait arriver à
faire le reste.

Benoit Izac devait dire quelque chose comme ceci :

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 ?

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.
Maintenant, personnellement je n'ai pas mieux à proposer, donc...

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


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

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

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

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

--
«je vous savoire comment faire lancer un programme ,qui a comme resultat
devenire root , une fois il est executer.»
LD in Guide du linuxien pervers - "Petit lamer deviendra grand... peut-être"

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

[...]
avoir un parc matériel de, disons 2004 au pif parce qu'il faut bien une
date, pour arriver à faire tourner NetBSD, plus le temps passe, moins
le projet aura d'utilisateurs.

Ca marche aussi sur du materiel de 2006; j'en ai installe un paquet
ces dernier temps. Y compris des truc plus pointus comme des Dell
poweredge ou une machine avec des 3ware 9550SX. C'est vrai que ca ne
tourne pas sur *tout* les materiels (mais c'est le cas pour tout les OS,
j'en ai eu recemment la preuve avec les athlon64 sous linux et windows), 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.

[...]
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.
Personnellement, ça finirait par me gaver, parce que pendant que je
fais ces petites adaptations, je ne crée pas à proprement parler de
code, me contentant de faire des retouches sur celui qui a été écrit
par d'autres.
De plus, cela augmente considérablement le nombre de développeurs
nécessaire au projet, ce qui complique d'autant plus les décisions
collégiales, ce qui nuit donc à la fois au dynamisme et à l'ambiance du
projet. Tu l'as dit toi-même, avoir des idées c'est bien, mais il faut
aussi trouver les développeurs.
Combien de développeurs récupèrerait le projet si, au hasard, il
arrêtait de soutenir les versions amiga, atari et vax ? Et je dis bien
au hasard, parce qu'il y a probablement des versions beaucoup moins
utiles et utilisées que ces trois là. Cinquante cinq plateformes
soutenues, c'est cinquante cinq fois plus de monde nécessaires,
cinquante cinq fois plus de version d'un même code qui doit être
parfait avant de pouvoir passer à la suite, bref beaucoup trop
d'entraves.

Mais non, pas du tout justement. Avec les couches d'abstraction, pour un
peripherique donne c'est le meme driver qui marche sur les differentes
plateformes. Tout ce qu'il y a de specifique c'est le code pour le processeur
et ce qui l'entoure (MMU, bus d'interface etc). Tout ce qu'il y a a changer
pour une nouvelle plateforme c'est ce code, et il n'y a aucune raison d'aller
toucher a du code existant (sauf si celui ci etait mal ecrit au depart).

Attention, je ne dis pas que NetBSD doit se restreindre à quelques
architecture seulement. Le fait qu'il puisse tourner "partout" est une
bonne chose, mais si le "partout" était un peu plus restreind, le
projet ne pourrait qu'y gagner.

C'est un debat, et je n'y crois pas. Il y a pas mal de gens qui
developpent pour NetBSD pour des architectures anciennes ou exotiques;
mais ils contribuent aussi du code machine-idenpendant qui est utilise par
tout le monde.


--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--

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.
De même, qu'est-ce qu'ils en ont à faire, eux, du SMP ou de ceci/cela

Tss! Il y a des vax multiprocesseurs, voyons !