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) --
Malheureusement nVidia = beaucoup de soucis en général, vu qu'ils refusent de fournir la moindre doc. Je ne sais pas ce que ça donne pour cette carte-là en particulier, j'avoue que j'utilise très rarement FreeBSD (le BSD que j'utilise) dans un environnement graphique "natif".
A l'inverse, quel constructeur est réputé pour se montrer coopératif avec le monde opensource, tout en fabriquant des cartes performantes ? (rho, une ligne trop longue ... la fatigue surement ;)
Il n'y en a pas à ma connaissance (ou plus, ATI a eu une période où ils fournissaient les specs de leurs cartes ... ) De toute façon, les specs des constructeurs ne sont pas vraiment suffisantes pour avoir une accelération efficace (encore l'exemple ATI ... ) l'implantation de la libGL joue beaucoup sur les performances et tant que certains algos seront fermés, avoir une accel efficace en libre restera un rêve.
À moins que les cartes facent suffisament de progrès pour que l'on se passe totalement de la partie soft (une implem OpenGL dans la carte directement, ça serait vraiment pas mal ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <slrnd9eauh.fn3.nicolas.ecarnot@verdon.acc.fr>,
Nicolas Ecarnot wrote:
Le 26-05-2005, Jacques Caron <jc@imfeurope.com> écrivait :
Malheureusement nVidia = beaucoup de soucis en général, vu qu'ils refusent
de fournir la moindre doc. Je ne sais pas ce que ça donne pour cette
carte-là en particulier, j'avoue que j'utilise très rarement FreeBSD (le
BSD que j'utilise) dans un environnement graphique "natif".
A l'inverse, quel constructeur est réputé pour se montrer coopératif
avec le monde opensource, tout en fabriquant des cartes performantes
?
(rho, une ligne trop longue ... la fatigue surement ;)
Il n'y en a pas à ma connaissance (ou plus, ATI a eu une période où
ils fournissaient les specs de leurs cartes ... ) De toute façon, les
specs des constructeurs ne sont pas vraiment suffisantes pour avoir
une accelération efficace (encore l'exemple ATI ... ) l'implantation
de la libGL joue beaucoup sur les performances et tant que certains
algos seront fermés, avoir une accel efficace en libre restera un
rêve.
À moins que les cartes facent suffisament de progrès pour que l'on se
passe totalement de la partie soft (une implem OpenGL dans la carte
directement, ça serait vraiment pas mal ;)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Malheureusement nVidia = beaucoup de soucis en général, vu qu'ils refusent de fournir la moindre doc. Je ne sais pas ce que ça donne pour cette carte-là en particulier, j'avoue que j'utilise très rarement FreeBSD (le BSD que j'utilise) dans un environnement graphique "natif".
A l'inverse, quel constructeur est réputé pour se montrer coopératif avec le monde opensource, tout en fabriquant des cartes performantes ? (rho, une ligne trop longue ... la fatigue surement ;)
Il n'y en a pas à ma connaissance (ou plus, ATI a eu une période où ils fournissaient les specs de leurs cartes ... ) De toute façon, les specs des constructeurs ne sont pas vraiment suffisantes pour avoir une accelération efficace (encore l'exemple ATI ... ) l'implantation de la libGL joue beaucoup sur les performances et tant que certains algos seront fermés, avoir une accel efficace en libre restera un rêve.
À moins que les cartes facent suffisament de progrès pour que l'on se passe totalement de la partie soft (une implem OpenGL dans la carte directement, ça serait vraiment pas mal ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
F. Senault
"F. Senault" writes:
'Lut,
[PCBSD]
Le seul bémol de la version que j'ai testée(à part qu'il faut aimer KDE), c'est la mauvaise gestion des claviers pas qwerty...
Et l'installeur en GPL, c'est pas mal dans le genre, non ?
Personnellement ? Je vais peut-être choquer, hein, mais j'en ai rien à faire. Si leur machin marche et qu'ils veulent l'enfermer dans la GPL, ça m'est totalement équilatéral.
D'un autre côté, si ça fait connaître plus largement le système sur lequel c'est basé (qui, lui, reste développé et licencié selon ses propres règles), ils ont tout mon soutien.
Éric Masson
Fred -- Ahh Avaler le grand déversoir des images cyniques A boire à plein tube Cathodique Attendez-moi J'avais envie de venir moi aussi Mais voyez-vous ça va trop vite N'allez pas si vite (Noir Désir, Fin de Siècle)
"F. Senault" <fred@lacave.net> writes:
'Lut,
[PCBSD]
Le seul bémol de la version que j'ai testée(à part qu'il faut aimer
KDE), c'est la mauvaise gestion des claviers pas qwerty...
Et l'installeur en GPL, c'est pas mal dans le genre, non ?
Personnellement ? Je vais peut-être choquer, hein, mais j'en ai rien à
faire. Si leur machin marche et qu'ils veulent l'enfermer dans la GPL,
ça m'est totalement équilatéral.
D'un autre côté, si ça fait connaître plus largement le système sur
lequel c'est basé (qui, lui, reste développé et licencié selon ses
propres règles), ils ont tout mon soutien.
Éric Masson
Fred
--
Ahh Avaler le grand déversoir des images cyniques A boire à plein tube
Cathodique Attendez-moi J'avais envie de venir moi aussi Mais voyez-vous
ça va trop vite N'allez pas si vite (Noir Désir, Fin de Siècle)
Le seul bémol de la version que j'ai testée(à part qu'il faut aimer KDE), c'est la mauvaise gestion des claviers pas qwerty...
Et l'installeur en GPL, c'est pas mal dans le genre, non ?
Personnellement ? Je vais peut-être choquer, hein, mais j'en ai rien à faire. Si leur machin marche et qu'ils veulent l'enfermer dans la GPL, ça m'est totalement équilatéral.
D'un autre côté, si ça fait connaître plus largement le système sur lequel c'est basé (qui, lui, reste développé et licencié selon ses propres règles), ils ont tout mon soutien.
Éric Masson
Fred -- Ahh Avaler le grand déversoir des images cyniques A boire à plein tube Cathodique Attendez-moi J'avais envie de venir moi aussi Mais voyez-vous ça va trop vite N'allez pas si vite (Noir Désir, Fin de Siècle)
Marwan Burelle
In article <fikfspwq3ljb$, F. Senault wrote:
Et l'installeur en GPL, c'est pas mal dans le genre, non ? Personnellement ? Je vais peut-être choquer, hein, mais j'en ai rien à
faire. Si leur machin marche et qu'ils veulent l'enfermer dans la GPL, ça m'est totalement équilatéral.
Je vais pas relancer un troll, mais il y a la clause 2.b de la GPL qui peut poser problème (même si le texte qui suit rend cette clause ambigue ... )
D'un autre côté, si ça fait connaître plus largement le système sur lequel c'est basé (qui, lui, reste développé et licencié selon ses propres règles), ils ont tout mon soutien.
Oui, également, mais c'est quand même dommage ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <fikfspwq3ljb$.dlg@ballantines.lacave.local>, F. Senault wrote:
Et l'installeur en GPL, c'est pas mal dans le genre, non ?
Personnellement ? Je vais peut-être choquer, hein, mais j'en ai rien à
faire. Si leur machin marche et qu'ils veulent l'enfermer dans la GPL,
ça m'est totalement équilatéral.
Je vais pas relancer un troll, mais il y a la clause 2.b de la GPL qui
peut poser problème (même si le texte qui suit rend cette clause
ambigue ... )
D'un autre côté, si ça fait connaître plus largement le système sur
lequel c'est basé (qui, lui, reste développé et licencié selon ses
propres règles), ils ont tout mon soutien.
Oui, également, mais c'est quand même dommage ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Et l'installeur en GPL, c'est pas mal dans le genre, non ? Personnellement ? Je vais peut-être choquer, hein, mais j'en ai rien à
faire. Si leur machin marche et qu'ils veulent l'enfermer dans la GPL, ça m'est totalement équilatéral.
Je vais pas relancer un troll, mais il y a la clause 2.b de la GPL qui peut poser problème (même si le texte qui suit rend cette clause ambigue ... )
D'un autre côté, si ça fait connaître plus largement le système sur lequel c'est basé (qui, lui, reste développé et licencié selon ses propres règles), ils ont tout mon soutien.
Oui, également, mais c'est quand même dommage ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Miod Vallat
Je vais pas relancer un troll, mais il y a la clause 2.b de la GPL qui peut poser problème (même si le texte qui suit rend cette clause ambigue ... )
Je ne vois pas ce qui peut poser problème. La valeur ajoutée de PC/BSD est un installeur sous GPL, le reste du système FreeBSD est laissé intact.
D'un autre côté, si ça fait connaître plus largement le système sur lequel c'est basé (qui, lui, reste développé et licencié selon ses propres règles), ils ont tout mon soutien.
Oui, également, mais c'est quand même dommage ...
Si ça te dérange tant que ça, tu peux essayer de convaincre les gens de PC/BSD de changer de licence, ou monter un projet concurrent...
Je vais pas relancer un troll, mais il y a la clause 2.b de la GPL qui
peut poser problème (même si le texte qui suit rend cette clause
ambigue ... )
Je ne vois pas ce qui peut poser problème. La valeur ajoutée de PC/BSD
est un installeur sous GPL, le reste du système FreeBSD est laissé
intact.
D'un autre côté, si ça fait connaître plus largement le système sur
lequel c'est basé (qui, lui, reste développé et licencié selon ses
propres règles), ils ont tout mon soutien.
Oui, également, mais c'est quand même dommage ...
Si ça te dérange tant que ça, tu peux essayer de convaincre les gens de
PC/BSD de changer de licence, ou monter un projet concurrent...
Je vais pas relancer un troll, mais il y a la clause 2.b de la GPL qui peut poser problème (même si le texte qui suit rend cette clause ambigue ... )
Je ne vois pas ce qui peut poser problème. La valeur ajoutée de PC/BSD est un installeur sous GPL, le reste du système FreeBSD est laissé intact.
D'un autre côté, si ça fait connaître plus largement le système sur lequel c'est basé (qui, lui, reste développé et licencié selon ses propres règles), ils ont tout mon soutien.
Oui, également, mais c'est quand même dommage ...
Si ça te dérange tant que ça, tu peux essayer de convaincre les gens de PC/BSD de changer de licence, ou monter un projet concurrent...
talon
Marc Espie wrote:
In article , Jacques Caron wrote:
- Compile t-on son noyau sous BSD ?
Bien sûr.
Non, pas forcement.
Typiquement, sous OpenBSD, le noyau GENERIC fonctionne tres bien sur >95% des cas. boot -c + config permet de tordre le cou de 90% des cas restants, et il reste sans doute quelques cas tres, tres tordus ou il faut compiler un noyau. Mais ca n'a vraiment rien d'indispensable.
Je ne sais pas si net ou free ont pique config -e un jour, mais c'est vraiment le bonheur pour mettre des vieux trucs en production rapidement sans avoir a se manger une compile de noyau en rab.
Il y a toujours eu une config visuelle (config -v) dans les vieux FreeBSD qui permettait de désactiver les drivers inutiles ou nuisibles ou à activer des drivers initialement inactivés ou les configurer. Ce truc est tombé en désuétude et je ne crois plus qu'il y soit encore, car d'une part il y a les modules précompilés qui couvrent quasi tous les besoins, et d'autre part on peut passer des sysctls au noyau au boot via le loader. Donc en fait toute cette configuration dont tu parles se fait maintenant via /boot/loader (et son fichier de conf). Sincèrement je trouve ça beaucoup plus calir et simple que le système antérieur.
--
Michel TALON
Marc Espie <espie@tetto.home> wrote:
In article <opsrej7qeazscttn@news.free.fr>,
Jacques Caron <jc@imfeurope.com> wrote:
- Compile t-on son noyau sous BSD ?
Bien sûr.
Non, pas forcement.
Typiquement, sous OpenBSD, le noyau GENERIC fonctionne tres bien sur >95%
des cas. boot -c + config permet de tordre le cou de 90% des cas restants,
et il reste sans doute quelques cas tres, tres tordus ou il faut compiler
un noyau. Mais ca n'a vraiment rien d'indispensable.
Je ne sais pas si net ou free ont pique config -e un jour, mais c'est
vraiment le bonheur pour mettre des vieux trucs en production rapidement
sans avoir a se manger une compile de noyau en rab.
Il y a toujours eu une config visuelle (config -v) dans les vieux FreeBSD
qui permettait de désactiver les drivers inutiles ou nuisibles ou à
activer des drivers initialement inactivés ou les configurer. Ce truc
est tombé en désuétude et je ne crois plus qu'il y soit encore, car d'une
part il y a les modules précompilés qui couvrent quasi tous les besoins,
et d'autre part on peut passer des sysctls au noyau au boot via le loader.
Donc en fait toute cette configuration dont tu parles se fait maintenant via
/boot/loader (et son fichier de conf). Sincèrement je trouve ça beaucoup plus
calir et simple que le système antérieur.
Typiquement, sous OpenBSD, le noyau GENERIC fonctionne tres bien sur >95% des cas. boot -c + config permet de tordre le cou de 90% des cas restants, et il reste sans doute quelques cas tres, tres tordus ou il faut compiler un noyau. Mais ca n'a vraiment rien d'indispensable.
Je ne sais pas si net ou free ont pique config -e un jour, mais c'est vraiment le bonheur pour mettre des vieux trucs en production rapidement sans avoir a se manger une compile de noyau en rab.
Il y a toujours eu une config visuelle (config -v) dans les vieux FreeBSD qui permettait de désactiver les drivers inutiles ou nuisibles ou à activer des drivers initialement inactivés ou les configurer. Ce truc est tombé en désuétude et je ne crois plus qu'il y soit encore, car d'une part il y a les modules précompilés qui couvrent quasi tous les besoins, et d'autre part on peut passer des sysctls au noyau au boot via le loader. Donc en fait toute cette configuration dont tu parles se fait maintenant via /boot/loader (et son fichier de conf). Sincèrement je trouve ça beaucoup plus calir et simple que le système antérieur.
--
Michel TALON
Cyrille Szymanski
On 2005-05-27, Marwan Burelle wrote:
À moins que les cartes facent suffisament de progrès pour que l'on se passe totalement de la partie soft (une implem OpenGL dans la carte directement, ça serait vraiment pas mal ;)
Ah oui ça serait une super idée ça. C'est le coût du développement qui les retient de faire ça ?
Il y avait aussi une histoire de composants matériels avec des drivers Java mais ça tient plutôt de la science fiction. Par contre l'approche ndisulator est intéressante je trouve. Personne ne sait s'il existe des projets d'interfaces bien standardisées ? Microsoft a une couche "Hardware Abstraction Layer" mais je ne sais pas exactement quels services elle offre.
-- Cyrille Szymanski
On 2005-05-27, Marwan Burelle <burelle@lri.fr> wrote:
À moins que les cartes facent suffisament de progrès pour que l'on se
passe totalement de la partie soft (une implem OpenGL dans la carte
directement, ça serait vraiment pas mal ;)
Ah oui ça serait une super idée ça. C'est le coût du développement qui les
retient de faire ça ?
Il y avait aussi une histoire de composants matériels avec des drivers Java
mais ça tient plutôt de la science fiction. Par contre l'approche ndisulator
est intéressante je trouve. Personne ne sait s'il existe des projets
d'interfaces bien standardisées ? Microsoft a une couche "Hardware Abstraction
Layer" mais je ne sais pas exactement quels services elle offre.
À moins que les cartes facent suffisament de progrès pour que l'on se passe totalement de la partie soft (une implem OpenGL dans la carte directement, ça serait vraiment pas mal ;)
Ah oui ça serait une super idée ça. C'est le coût du développement qui les retient de faire ça ?
Il y avait aussi une histoire de composants matériels avec des drivers Java mais ça tient plutôt de la science fiction. Par contre l'approche ndisulator est intéressante je trouve. Personne ne sait s'il existe des projets d'interfaces bien standardisées ? Microsoft a une couche "Hardware Abstraction Layer" mais je ne sais pas exactement quels services elle offre.
-- Cyrille Szymanski
talon
Eric Masson wrote:
Patrick Lamaizière writes:
« PC-BSD is free and open-source software licenced under the terms of the GNU GPL »
Argghhhhhh...
<gpliste> C'est pour pas se faire voler leur code. C'est déjà arrivé, par exemple Kro$oft a volé le code Kerberos du MIT pour l'intégrer dans Windaube2K Server. Depuis, tu ne trouves plus les sources de MIT krb5... </gpliste>
Éric Masson
En attendant PC-BSD monte à la vitesse V sur Distrowatch. Il va finir par devenir le Ubuntu des *BSD :-( Son principe le plus important est que chaque gros logiciel vient avec toutes ses libs dans leur propre directory, comme ce qu'on trouve sous Program Files dans Windows, ce qui rend installation et désinstallation trivial. Je crois que c'est la première distribution à avoir le courage de faire ça, c'est à dire de jeter aux orties toutes les conneries sur la réutilisation des librairies dynamiques, qui mettent un bordel sans nom dans les systèmes unixoides, et rien que pour ça il faut les féliciter.
Personnellement ayant installé une machine fraîchement sous FreeBSD-5.3 je suis déjà emmerdé jusqu'au cou avec les ports depuis que j'ai eu le malheur de faire un cvsup au moment de la 5.4. Basiquement plus rien ne compile sans vouloir te refaire la quasi totalité de tes ports, et bien entendu il y en a la moitié qui sont marqués BROKEN pour des motifs futiles. FreeBSD est en train de devenir encore plus merdique que Debian, si c'est possible, je voue aux gémonies les responsables actuels de l'arbre des ports.
--
Michel TALON
Eric Masson <emss@free.fr> wrote:
Patrick Lamaizière <adresse@est.invalid> writes:
« PC-BSD is free and open-source software licenced under the terms of the
GNU GPL »
Argghhhhhh...
<gpliste>
C'est pour pas se faire voler leur code. C'est déjà arrivé, par exemple
Kro$oft a volé le code Kerberos du MIT pour l'intégrer dans Windaube2K
Server. Depuis, tu ne trouves plus les sources de MIT krb5...
</gpliste>
Éric Masson
En attendant PC-BSD monte à la vitesse V sur Distrowatch. Il va finir par
devenir le Ubuntu des *BSD :-(
Son principe le plus important est que chaque gros logiciel vient avec toutes
ses libs dans leur propre directory, comme ce qu'on trouve sous
Program Files dans Windows, ce qui rend installation et désinstallation
trivial. Je crois que c'est la première distribution à avoir le courage de
faire ça, c'est à dire de jeter aux orties toutes les conneries sur la
réutilisation des librairies dynamiques, qui mettent un bordel sans nom dans
les systèmes unixoides, et rien que pour ça il faut les féliciter.
Personnellement ayant installé une machine fraîchement sous FreeBSD-5.3 je suis
déjà emmerdé jusqu'au cou avec les ports depuis que j'ai eu le malheur de
faire un cvsup au moment de la 5.4. Basiquement plus rien ne compile sans
vouloir te refaire la quasi totalité de tes ports, et bien entendu il y en a
la moitié qui sont marqués BROKEN pour des motifs futiles. FreeBSD est en
train de devenir encore plus merdique que Debian, si c'est possible, je voue
aux gémonies les responsables actuels de l'arbre des ports.
« PC-BSD is free and open-source software licenced under the terms of the GNU GPL »
Argghhhhhh...
<gpliste> C'est pour pas se faire voler leur code. C'est déjà arrivé, par exemple Kro$oft a volé le code Kerberos du MIT pour l'intégrer dans Windaube2K Server. Depuis, tu ne trouves plus les sources de MIT krb5... </gpliste>
Éric Masson
En attendant PC-BSD monte à la vitesse V sur Distrowatch. Il va finir par devenir le Ubuntu des *BSD :-( Son principe le plus important est que chaque gros logiciel vient avec toutes ses libs dans leur propre directory, comme ce qu'on trouve sous Program Files dans Windows, ce qui rend installation et désinstallation trivial. Je crois que c'est la première distribution à avoir le courage de faire ça, c'est à dire de jeter aux orties toutes les conneries sur la réutilisation des librairies dynamiques, qui mettent un bordel sans nom dans les systèmes unixoides, et rien que pour ça il faut les féliciter.
Personnellement ayant installé une machine fraîchement sous FreeBSD-5.3 je suis déjà emmerdé jusqu'au cou avec les ports depuis que j'ai eu le malheur de faire un cvsup au moment de la 5.4. Basiquement plus rien ne compile sans vouloir te refaire la quasi totalité de tes ports, et bien entendu il y en a la moitié qui sont marqués BROKEN pour des motifs futiles. FreeBSD est en train de devenir encore plus merdique que Debian, si c'est possible, je voue aux gémonies les responsables actuels de l'arbre des ports.
--
Michel TALON
myrddin
Marwan Burelle wrote:
Heu... À ma connaissance, le port du driver 'nvidia' pour FreeBSD a une option pour activer ou non la couche de support Linux et il est maitenant threadsafe (avec la nouvelle bibliothèque multi-threads du noayu). Ou alors j'ai tout mélangé.
Hum, je ne suis pas sûr, ça à peut être changé côté thread (c'était prévu ... ) mais il me semble que c'est toujours une lib linux ... mais je peux me tromper (surtout que là je supconne fortement X.org d'avoir écrasé ma libGL.so ... )
Hello
Ben moi je suis absolument super sur, les drivers proprio nvidia sont, pour la version freebsd, native freebsd et non rien à voir avec celle de linux.
Il y a une 'couche' de comptabilité optionnel (cela rajoute des libs, 3 il me semble j'ai pas ma freebsdbox sous la main pour vérifier)
Elle est seulement utile pour utiliser des binaires prévus pour linux et qui utilise la 3d, par exemple des jeux...
les binaires natifs freebsd utilisant la 3d fonctionne parfaitement sans la couche de comptabilité linux
Bn : pour désactiver la couche de comptabilité nux c'est facile :
c'est ici que cela ce passe :)
/VIDIA-FreeBSD-x86-1.0-7174/src/nv-freebsd.h
/* * This option decides if the driver will be built with support for Linux * compatibility. This makes nvidia.ko dependant on linux.ko; if you have * no need for Linux 3D applications, you can safely unset this flag. */
Et voila plus besoins de comptabilité nux :) (et plus besoin du module linux non plus...
Voila ;)
a+
Marwan Burelle wrote:
Heu... À ma connaissance, le port du driver 'nvidia' pour FreeBSD a une
option pour activer ou non la couche de support Linux et il est maitenant
threadsafe (avec la nouvelle bibliothèque multi-threads du noayu). Ou
alors j'ai tout mélangé.
Hum, je ne suis pas sûr, ça à peut être changé côté thread (c'était
prévu ... ) mais il me semble que c'est toujours une lib linux
... mais je peux me tromper (surtout que là je supconne fortement
X.org d'avoir écrasé ma libGL.so ... )
Hello
Ben moi je suis absolument super sur, les drivers proprio nvidia sont,
pour la version freebsd, native freebsd et non rien à voir avec celle
de linux.
Il y a une 'couche' de comptabilité optionnel (cela rajoute des libs, 3
il me semble j'ai pas ma freebsdbox sous la main pour vérifier)
Elle est seulement utile pour utiliser des binaires prévus pour linux
et qui utilise la 3d, par exemple des jeux...
les binaires natifs freebsd utilisant la 3d fonctionne parfaitement sans
la couche de comptabilité linux
Bn : pour désactiver la couche de comptabilité nux c'est facile :
c'est ici que cela ce passe :)
/VIDIA-FreeBSD-x86-1.0-7174/src/nv-freebsd.h
/*
* This option decides if the driver will be built with support for Linux
* compatibility. This makes nvidia.ko dependant on linux.ko; if you have
* no need for Linux 3D applications, you can safely unset this flag.
*/
Heu... À ma connaissance, le port du driver 'nvidia' pour FreeBSD a une option pour activer ou non la couche de support Linux et il est maitenant threadsafe (avec la nouvelle bibliothèque multi-threads du noayu). Ou alors j'ai tout mélangé.
Hum, je ne suis pas sûr, ça à peut être changé côté thread (c'était prévu ... ) mais il me semble que c'est toujours une lib linux ... mais je peux me tromper (surtout que là je supconne fortement X.org d'avoir écrasé ma libGL.so ... )
Hello
Ben moi je suis absolument super sur, les drivers proprio nvidia sont, pour la version freebsd, native freebsd et non rien à voir avec celle de linux.
Il y a une 'couche' de comptabilité optionnel (cela rajoute des libs, 3 il me semble j'ai pas ma freebsdbox sous la main pour vérifier)
Elle est seulement utile pour utiliser des binaires prévus pour linux et qui utilise la 3d, par exemple des jeux...
les binaires natifs freebsd utilisant la 3d fonctionne parfaitement sans la couche de comptabilité linux
Bn : pour désactiver la couche de comptabilité nux c'est facile :
c'est ici que cela ce passe :)
/VIDIA-FreeBSD-x86-1.0-7174/src/nv-freebsd.h
/* * This option decides if the driver will be built with support for Linux * compatibility. This makes nvidia.ko dependant on linux.ko; if you have * no need for Linux 3D applications, you can safely unset this flag. */
Et voila plus besoins de comptabilité nux :) (et plus besoin du module linux non plus...
Voila ;)
a+
Eric Masson
(Michel Talon) writes:
Son principe le plus important est que chaque gros logiciel vient avec toutes ses libs dans leur propre directory, comme ce qu'on trouve sous Program Files dans Windows, ce qui rend installation et désinstallation trivial.
Euh, tu devrais te relire ;) Le dll hell et les instabilités suite à une désinstallation sous Windows, c'est loin d'être une légende...
Je crois que c'est la première distribution à avoir le courage de faire ça, c'est à dire de jeter aux orties toutes les conneries sur la réutilisation des librairies dynamiques, qui mettent un bordel sans nom dans les systèmes unixoides, et rien que pour ça il faut les féliciter.
Mouaif, j'attends de voir ce que va pondre Matt Dillon à ce sujet avec les varsymlinks.
Basiquement plus rien ne compile sans vouloir te refaire la quasi totalité de tes ports, et bien entendu il y en a la moitié qui sont marqués BROKEN pour des motifs futiles.
-- je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr que ma femme le fera .-) -+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
talon@lpthe.jussieu.fr (Michel Talon) writes:
Son principe le plus important est que chaque gros logiciel vient avec
toutes ses libs dans leur propre directory, comme ce qu'on trouve sous
Program Files dans Windows, ce qui rend installation et
désinstallation trivial.
Euh, tu devrais te relire ;)
Le dll hell et les instabilités suite à une désinstallation sous
Windows, c'est loin d'être une légende...
Je crois que c'est la première distribution à avoir le courage de
faire ça, c'est à dire de jeter aux orties toutes les conneries sur la
réutilisation des librairies dynamiques, qui mettent un bordel sans nom dans
les systèmes unixoides, et rien que pour ça il faut les féliciter.
Mouaif, j'attends de voir ce que va pondre Matt Dillon à ce sujet avec
les varsymlinks.
Basiquement plus rien ne compile sans vouloir te refaire la quasi
totalité de tes ports, et bien entendu il y en a la moitié qui sont
marqués BROKEN pour des motifs futiles.
--
je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec
le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr
que ma femme le fera .-)
-+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
Son principe le plus important est que chaque gros logiciel vient avec toutes ses libs dans leur propre directory, comme ce qu'on trouve sous Program Files dans Windows, ce qui rend installation et désinstallation trivial.
Euh, tu devrais te relire ;) Le dll hell et les instabilités suite à une désinstallation sous Windows, c'est loin d'être une légende...
Je crois que c'est la première distribution à avoir le courage de faire ça, c'est à dire de jeter aux orties toutes les conneries sur la réutilisation des librairies dynamiques, qui mettent un bordel sans nom dans les systèmes unixoides, et rien que pour ça il faut les féliciter.
Mouaif, j'attends de voir ce que va pondre Matt Dillon à ce sujet avec les varsymlinks.
Basiquement plus rien ne compile sans vouloir te refaire la quasi totalité de tes ports, et bien entendu il y en a la moitié qui sont marqués BROKEN pour des motifs futiles.
-- je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr que ma femme le fera .-) -+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
Eric Masson
Cyrille Szymanski writes:
Microsoft a une couche "Hardware Abstraction Layer" mais je ne sais pas exactement quels services elle offre.
Tiens, une réponse que j'ai faite il y a quelque temps à un mec qui tirait à boulet rouge sur windows sans vraiment savoir de quoi il parlait : http://groups-beta.google.com/group/fr.comp.sys.atari/msg/c0c86f7ed6729d13?hl=en&fwc=1
Dans la structure d'un dérivé d'NT, Ndis est une interface de l'exécutif dédiée aux drivers réseau.
Pour voir s'il existe d'autres interfaces de ce type, il faudrait se taper les docs des différents ddk ou encore le msdn.
Éric Masson
--
Sinon, à propos d'afterstep et de window maker : quand je déplace une fenêtre, en plus de la neige sur le moniteur, j'ai du crachin dans les haut parleurs... -+- hcl in Guide du linuxien pervers - "Y'a plus de saison j'vous dis :("
Cyrille Szymanski <cns@cns2.invalid> writes:
Microsoft a une couche "Hardware Abstraction Layer" mais je ne sais
pas exactement quels services elle offre.
Tiens, une réponse que j'ai faite il y a quelque temps à un mec qui
tirait à boulet rouge sur windows sans vraiment savoir de quoi il
parlait :
http://groups-beta.google.com/group/fr.comp.sys.atari/msg/c0c86f7ed6729d13?hl=en&fwc=1
Dans la structure d'un dérivé d'NT, Ndis est une interface de
l'exécutif dédiée aux drivers réseau.
Pour voir s'il existe d'autres interfaces de ce type, il faudrait se
taper les docs des différents ddk ou encore le msdn.
Éric Masson
--
Sinon, à propos d'afterstep et de window maker : quand je déplace une
fenêtre, en plus de la neige sur le moniteur, j'ai du crachin dans les
haut parleurs...
-+- hcl in Guide du linuxien pervers - "Y'a plus de saison j'vous dis :("
Microsoft a une couche "Hardware Abstraction Layer" mais je ne sais pas exactement quels services elle offre.
Tiens, une réponse que j'ai faite il y a quelque temps à un mec qui tirait à boulet rouge sur windows sans vraiment savoir de quoi il parlait : http://groups-beta.google.com/group/fr.comp.sys.atari/msg/c0c86f7ed6729d13?hl=en&fwc=1
Dans la structure d'un dérivé d'NT, Ndis est une interface de l'exécutif dédiée aux drivers réseau.
Pour voir s'il existe d'autres interfaces de ce type, il faudrait se taper les docs des différents ddk ou encore le msdn.
Éric Masson
--
Sinon, à propos d'afterstep et de window maker : quand je déplace une fenêtre, en plus de la neige sur le moniteur, j'ai du crachin dans les haut parleurs... -+- hcl in Guide du linuxien pervers - "Y'a plus de saison j'vous dis :("
