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) --
Il y a eu une tentative pour avoir les mêmes pilotes sur différents unix, UDI. Beaucoup de publicité au début, rien de concret ensuite, et plus un bruit depuis 2001. Un bon point à ceux qui s'en souviennent, les autres peuvent s'instruire sur http://www.projectudi.org/
Intéressant, dommage que ça n'est pas abouti ...
Pour répondre à ta question plus précisément : oui, une telle interface est réalisable, mais elle sera mort-née : l'effort d'adaptation d'un système existant à la nouvelle interface est supérieur à la bonne volonté des développeurs (en d'autres mots : INERTIE VAINCRA !)...
Effectivement ...
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples (c'était un projet développé au LAMI si je me souvient bien, un truc du nom de DEVIL, mais depuis les chercheurs concernés se sont intéressé à autre choses)
La conception d'un tel langage n'est pas si compliqué, et globalement la réécriture derrière non plus (enfin l'adaptation aux différentes exigences des systèmes ... ) le tout couplé avec un peu de crosscompil, on pourrait avoir un sdk pour drivers multi-plateformes ...
Oui, je sais, j'ai qu'à m'en occuper si c'est si simple ... (si j'avais le temps, refrain connu ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <42a0078e$0$3437$626a14ce@news.free.fr>, Miod Vallat wrote:
Il y a eu une tentative pour avoir les mêmes pilotes sur différents
unix, UDI. Beaucoup de publicité au début, rien de concret ensuite, et
plus un bruit depuis 2001. Un bon point à ceux qui s'en souviennent, les
autres peuvent s'instruire sur http://www.projectudi.org/
Intéressant, dommage que ça n'est pas abouti ...
Pour répondre à ta question plus précisément : oui, une telle interface
est réalisable, mais elle sera mort-née : l'effort d'adaptation d'un
système existant à la nouvelle interface est supérieur à la bonne
volonté des développeurs (en d'autres mots : INERTIE VAINCRA !)...
Effectivement ...
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec
un compilo adpaté pour chaque système. Il existe un DSL pour des
drivers simples (c'était un projet développé au LAMI si je me souvient
bien, un truc du nom de DEVIL, mais depuis les chercheurs concernés se
sont intéressé à autre choses)
La conception d'un tel langage n'est pas si compliqué, et globalement
la réécriture derrière non plus (enfin l'adaptation aux différentes
exigences des systèmes ... ) le tout couplé avec un peu de
crosscompil, on pourrait avoir un sdk pour drivers multi-plateformes
...
Oui, je sais, j'ai qu'à m'en occuper si c'est si simple ... (si
j'avais le temps, refrain connu ... )
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Il y a eu une tentative pour avoir les mêmes pilotes sur différents unix, UDI. Beaucoup de publicité au début, rien de concret ensuite, et plus un bruit depuis 2001. Un bon point à ceux qui s'en souviennent, les autres peuvent s'instruire sur http://www.projectudi.org/
Intéressant, dommage que ça n'est pas abouti ...
Pour répondre à ta question plus précisément : oui, une telle interface est réalisable, mais elle sera mort-née : l'effort d'adaptation d'un système existant à la nouvelle interface est supérieur à la bonne volonté des développeurs (en d'autres mots : INERTIE VAINCRA !)...
Effectivement ...
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples (c'était un projet développé au LAMI si je me souvient bien, un truc du nom de DEVIL, mais depuis les chercheurs concernés se sont intéressé à autre choses)
La conception d'un tel langage n'est pas si compliqué, et globalement la réécriture derrière non plus (enfin l'adaptation aux différentes exigences des systèmes ... ) le tout couplé avec un peu de crosscompil, on pourrait avoir un sdk pour drivers multi-plateformes ...
Oui, je sais, j'ai qu'à m'en occuper si c'est si simple ... (si j'avais le temps, refrain connu ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Stephane Dupille
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples
Vaut autant faire des drivers en Java... ;-)
-- Subject: hors-sujet Etudiant1 de Formatique> c'est quoi ce message!!c'est Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!! -+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec
un compilo adpaté pour chaque système. Il existe un DSL pour des
drivers simples
Vaut autant faire des drivers en Java... ;-)
--
Subject: hors-sujet
Etudiant1 de Formatique> c'est quoi ce message!!c'est
Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!!
-+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples
Vaut autant faire des drivers en Java... ;-)
-- Subject: hors-sujet Etudiant1 de Formatique> c'est quoi ce message!!c'est Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!! -+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-
Marwan Burelle
In article , Stephane Dupille wrote:
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples Vaut autant faire des drivers en Java... ;-)
Sérieusement, pourquoi ?
Un DSL bien fait peut très juste se réécrire vers du C, en plus ça permet d'encapsuler pas mal de manips compliquées et répétitives dans des expressions du langage (c'est ce que faisait DEVIL) et de la même manière on doit pouvoir encapsuler les interactions avec le système.
L'avantage d'un langage spécifique (plutôt qu'une bidouille avec un jeu de macro ... ) c'est que l'on peut en plus raisoner sur le langage après (vu que le langage est plus limité que le C, on peut faire des analyses statiques qui ont des chances de réussir ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <m27jhbhm8k.fsf@gimli.dustnet.teaser.fr>, Stephane Dupille wrote:
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec
un compilo adpaté pour chaque système. Il existe un DSL pour des
drivers simples
Vaut autant faire des drivers en Java... ;-)
Sérieusement, pourquoi ?
Un DSL bien fait peut très juste se réécrire vers du C, en plus ça
permet d'encapsuler pas mal de manips compliquées et répétitives dans
des expressions du langage (c'est ce que faisait DEVIL) et de la même
manière on doit pouvoir encapsuler les interactions avec le système.
L'avantage d'un langage spécifique (plutôt qu'une bidouille avec un
jeu de macro ... ) c'est que l'on peut en plus raisoner sur le langage
après (vu que le langage est plus limité que le C, on peut faire des
analyses statiques qui ont des chances de réussir ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de
programmes ;)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples Vaut autant faire des drivers en Java... ;-)
Sérieusement, pourquoi ?
Un DSL bien fait peut très juste se réécrire vers du C, en plus ça permet d'encapsuler pas mal de manips compliquées et répétitives dans des expressions du langage (c'est ce que faisait DEVIL) et de la même manière on doit pouvoir encapsuler les interactions avec le système.
L'avantage d'un langage spécifique (plutôt qu'une bidouille avec un jeu de macro ... ) c'est que l'on peut en plus raisoner sur le langage après (vu que le langage est plus limité que le C, on peut faire des analyses statiques qui ont des chances de réussir ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Marwan Burelle
In article , Benoit Izac wrote:
Quel est l'intérêt de faire un fetchindex si tu le reconstruis ensuite ?
Euh, pour faire des make search sans avoir à attendre la fin portsdb -Uu ... (en plus pkgdb -F fait un fetchindex, je viens de tester, si l'index n'est pas à jour ... )
Toujours est-il que tu as bien un problème car mes résultats sont identiques à : <http://www.freebsd.org/cgi/ports.cgi?queryÍparanoia&stype=requires&release=5-STABLE%2Fi386>
Oui, effectivement, il y a quelque chose que je ne comprend pas ...
Je viens de virer /usr/ports refaire un cvsup (enfin hier) un portsdb -Uu et j'ai toujours les mêmes résultats ...
En explorant un peu, il y a des dépendances "conditionelles" dans certains de ces ports, je n'ai pas vérifier tout, mais il me semble que certains ports en question teste la présence d'appli pour activer certaines options, induisants de nouvelles dépendances ... au final, donc au final il suffit que l'une de ces options active une dépendance vers un outil dépendant de cdparanoia pour obtenir ce résultat ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <86d5r5eypc@message.id>, Benoit Izac wrote:
Quel est l'intérêt de faire un fetchindex si tu le reconstruis ensuite ?
Euh, pour faire des make search sans avoir à attendre la fin portsdb
-Uu ... (en plus pkgdb -F fait un fetchindex, je viens de tester, si
l'index n'est pas à jour ... )
Toujours est-il que tu as bien un problème car mes résultats sont
identiques à :
<http://www.freebsd.org/cgi/ports.cgi?queryÍparanoia&stype=requires&release=5-STABLE%2Fi386>
Oui, effectivement, il y a quelque chose que je ne comprend pas ...
Je viens de virer /usr/ports refaire un cvsup (enfin hier) un portsdb
-Uu et j'ai toujours les mêmes résultats ...
En explorant un peu, il y a des dépendances "conditionelles" dans
certains de ces ports, je n'ai pas vérifier tout, mais il me semble
que certains ports en question teste la présence d'appli pour activer
certaines options, induisants de nouvelles dépendances ... au final,
donc au final il suffit que l'une de ces options active une dépendance
vers un outil dépendant de cdparanoia pour obtenir ce résultat ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Quel est l'intérêt de faire un fetchindex si tu le reconstruis ensuite ?
Euh, pour faire des make search sans avoir à attendre la fin portsdb -Uu ... (en plus pkgdb -F fait un fetchindex, je viens de tester, si l'index n'est pas à jour ... )
Toujours est-il que tu as bien un problème car mes résultats sont identiques à : <http://www.freebsd.org/cgi/ports.cgi?queryÍparanoia&stype=requires&release=5-STABLE%2Fi386>
Oui, effectivement, il y a quelque chose que je ne comprend pas ...
Je viens de virer /usr/ports refaire un cvsup (enfin hier) un portsdb -Uu et j'ai toujours les mêmes résultats ...
En explorant un peu, il y a des dépendances "conditionelles" dans certains de ces ports, je n'ai pas vérifier tout, mais il me semble que certains ports en question teste la présence d'appli pour activer certaines options, induisants de nouvelles dépendances ... au final, donc au final il suffit que l'une de ces options active une dépendance vers un outil dépendant de cdparanoia pour obtenir ce résultat ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Stephane Dupille
Vaut autant faire des drivers en Java... ;-) Sérieusement, pourquoi ?
C'était pas sérieux. Je disais que quitte à sortir un langage spécifique pour faire un machin portable, vaut autant utiliser Java, dont le seul intérêt est sa portabilité (supposée).
Mais il fallait prendre cette remarque comme une boutade et pas au sérieux. Je mettrais un smiley plus gros la prochaine fois.
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;)
C'est bien ça qui (me) fait peur.
-- Bonsoir laurco, ici , te souviens tu de moi ? Tu étais venu me voir un jour à Paris Montparnasse.Qu'est ce que tu deviens?Si tu veux téléphone moi au :0607xxxxxx.A Bientôt. Guy -+- GF in <http://www.le-gnu.net> : Mon Parnasse chez les neuneux -+-
Vaut autant faire des drivers en Java... ;-)
Sérieusement, pourquoi ?
C'était pas sérieux. Je disais que quitte à sortir un langage
spécifique pour faire un machin portable, vaut autant utiliser Java,
dont le seul intérêt est sa portabilité (supposée).
Mais il fallait prendre cette remarque comme une boutade et pas au
sérieux. Je mettrais un smiley plus gros la prochaine fois.
Enfin, bon, c'est un délire de chercheur en langages et analyses de
programmes ;)
C'est bien ça qui (me) fait peur.
--
Bonsoir laurco, ici guyfxxxxx@wanadoo.fr, te souviens tu de moi ? Tu
étais venu me voir un jour à Paris Montparnasse.Qu'est ce que tu
deviens?Si tu veux téléphone moi au :0607xxxxxx.A Bientôt. Guy
-+- GF in <http://www.le-gnu.net> : Mon Parnasse chez les neuneux -+-
Vaut autant faire des drivers en Java... ;-) Sérieusement, pourquoi ?
C'était pas sérieux. Je disais que quitte à sortir un langage spécifique pour faire un machin portable, vaut autant utiliser Java, dont le seul intérêt est sa portabilité (supposée).
Mais il fallait prendre cette remarque comme une boutade et pas au sérieux. Je mettrais un smiley plus gros la prochaine fois.
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;)
C'est bien ça qui (me) fait peur.
-- Bonsoir laurco, ici , te souviens tu de moi ? Tu étais venu me voir un jour à Paris Montparnasse.Qu'est ce que tu deviens?Si tu veux téléphone moi au :0607xxxxxx.A Bientôt. Guy -+- GF in <http://www.le-gnu.net> : Mon Parnasse chez les neuneux -+-
Marwan Burelle
In article , Stephane Dupille wrote:
C'était pas sérieux. Je disais que quitte à sortir un langage spécifique pour faire un machin portable, vaut autant utiliser Java, dont le seul intérêt est sa portabilité (supposée).
Mais il fallait prendre cette remarque comme une boutade et pas au sérieux. Je mettrais un smiley plus gros la prochaine fois.
Je l'avais vu, mais bon, j'avais quand même envie de réagir ... faut dire que mettre java dans un post, c'est me tendre une grosse perche à troll, c'est plus fort que moi ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;) C'est bien ça qui (me) fait peur.
Je vois pas pourquoi ? ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <m2y89rg42c.fsf@gimli.dustnet.teaser.fr>, Stephane Dupille wrote:
C'était pas sérieux. Je disais que quitte à sortir un langage
spécifique pour faire un machin portable, vaut autant utiliser Java,
dont le seul intérêt est sa portabilité (supposée).
Mais il fallait prendre cette remarque comme une boutade et pas au
sérieux. Je mettrais un smiley plus gros la prochaine fois.
Je l'avais vu, mais bon, j'avais quand même envie de réagir ... faut
dire que mettre java dans un post, c'est me tendre une grosse perche
à troll, c'est plus fort que moi ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de
programmes ;)
C'est bien ça qui (me) fait peur.
Je vois pas pourquoi ? ;)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
C'était pas sérieux. Je disais que quitte à sortir un langage spécifique pour faire un machin portable, vaut autant utiliser Java, dont le seul intérêt est sa portabilité (supposée).
Mais il fallait prendre cette remarque comme une boutade et pas au sérieux. Je mettrais un smiley plus gros la prochaine fois.
Je l'avais vu, mais bon, j'avais quand même envie de réagir ... faut dire que mettre java dans un post, c'est me tendre une grosse perche à troll, c'est plus fort que moi ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;) C'est bien ça qui (me) fait peur.
Je vois pas pourquoi ? ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Stephane Dupille
Mais il fallait prendre cette remarque comme une boutade et pas au sérieux. Je mettrais un smiley plus gros la prochaine fois. Je l'avais vu, mais bon, j'avais quand même envie de réagir ... faut
dire que mettre java dans un post, c'est me tendre une grosse perche à troll, c'est plus fort que moi ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;) C'est bien ça qui (me) fait peur.
Je vois pas pourquoi ? ;)
Non, rien.
-- Suffit d'être suffisamment nombreux et tu feras moins le malin. Voter con est une chose, s'en vanter en est une autre... Vous êtes grotesques et dangereux. -+- Rocou In GNU - Le quantitatif supléra-t-il le qualitatif ? -+-
Mais il fallait prendre cette remarque comme une boutade et pas au
sérieux. Je mettrais un smiley plus gros la prochaine fois.
Je l'avais vu, mais bon, j'avais quand même envie de réagir ... faut
dire que mettre java dans un post, c'est me tendre une grosse perche
à troll, c'est plus fort que moi ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de
programmes ;)
C'est bien ça qui (me) fait peur.
Je vois pas pourquoi ? ;)
Non, rien.
--
Suffit d'être suffisamment nombreux et tu feras moins le malin.
Voter con est une chose, s'en vanter en est une autre...
Vous êtes grotesques et dangereux.
-+- Rocou In GNU - Le quantitatif supléra-t-il le qualitatif ? -+-
Mais il fallait prendre cette remarque comme une boutade et pas au sérieux. Je mettrais un smiley plus gros la prochaine fois. Je l'avais vu, mais bon, j'avais quand même envie de réagir ... faut
dire que mettre java dans un post, c'est me tendre une grosse perche à troll, c'est plus fort que moi ;)
Enfin, bon, c'est un délire de chercheur en langages et analyses de programmes ;) C'est bien ça qui (me) fait peur.
Je vois pas pourquoi ? ;)
Non, rien.
-- Suffit d'être suffisamment nombreux et tu feras moins le malin. Voter con est une chose, s'en vanter en est une autre... Vous êtes grotesques et dangereux. -+- Rocou In GNU - Le quantitatif supléra-t-il le qualitatif ? -+-
Benoit Izac
Bonjour,
le 03/06/2005 à 11:22, Marwan Burelle a écrit dans le message :
Je viens de virer /usr/ports refaire un cvsup (enfin hier) un portsdb -Uu et j'ai toujours les mêmes résultats ...
En explorant un peu, il y a des dépendances "conditionelles" dans certains de ces ports, je n'ai pas vérifier tout, mais il me semble que certains ports en question teste la présence d'appli pour activer certaines options, induisants de nouvelles dépendances ... au final, donc au final il suffit que l'une de ces options active une dépendance vers un outil dépendant de cdparanoia pour obtenir ce résultat ...
À mon avis tu as quelque chose dans pkgtools.conf qui te donne ce comportement. Tu peux essayer un portsdb -qUu avant un make search.
-- Benoit Izac
Bonjour,
le 03/06/2005 à 11:22, Marwan Burelle a écrit
dans le message <slrnda08b4.avf.burelle@pc5-179.lri.fr> :
Je viens de virer /usr/ports refaire un cvsup (enfin hier) un portsdb
-Uu et j'ai toujours les mêmes résultats ...
En explorant un peu, il y a des dépendances "conditionelles" dans
certains de ces ports, je n'ai pas vérifier tout, mais il me semble
que certains ports en question teste la présence d'appli pour activer
certaines options, induisants de nouvelles dépendances ... au final,
donc au final il suffit que l'une de ces options active une dépendance
vers un outil dépendant de cdparanoia pour obtenir ce résultat ...
À mon avis tu as quelque chose dans pkgtools.conf qui te donne ce
comportement. Tu peux essayer un portsdb -qUu avant un make search.
le 03/06/2005 à 11:22, Marwan Burelle a écrit dans le message :
Je viens de virer /usr/ports refaire un cvsup (enfin hier) un portsdb -Uu et j'ai toujours les mêmes résultats ...
En explorant un peu, il y a des dépendances "conditionelles" dans certains de ces ports, je n'ai pas vérifier tout, mais il me semble que certains ports en question teste la présence d'appli pour activer certaines options, induisants de nouvelles dépendances ... au final, donc au final il suffit que l'une de ces options active une dépendance vers un outil dépendant de cdparanoia pour obtenir ce résultat ...
À mon avis tu as quelque chose dans pkgtools.conf qui te donne ce comportement. Tu peux essayer un portsdb -qUu avant un make search.
-- Benoit Izac
Miod Vallat
Intéressant, dommage que ça n'est pas abouti ...
Dommage ? Non, pas vraiment.
Si chacun joue le jeu, tu as une phase longue de cohabitation de l'interface native (existante) du système, plus l'interface UDI. Tant que tous les pilotes ne sont pas convertis en UDI, tu as donc du code supplémentaire, ayant des bugs différents. Plus les bugs lors de la conversion natif->UDI.
De plus, suppose qu'une nouvelle génération de matériel, avec quelques particularités qui obligent à rendre caduque une interface UDI (par exemple, parce qu'une opération considérée comme atomique ne l'est plus, et nécessite un traitement supplémentaire entre les deux moitiés réellement atomiques). Il n'est pas possible de faire la modification rapidement, puisqu'il faut que le comité/consortium/parti/etc se mette d'accord sur la nouvelle interface et publie une nouvelle version de la spécification (et je passe sous silence les joies de la compatiblité descendante).
Autre possibilité, une amélioration du système (par exemple zero-copy TCP ou XiP) peut être rendue inopérante parce que l'interface UDI ne sera pas assez générique (ou le sera trop, selon le point de vue) et provoquera forcément des copies de données pour rien, ou des essorages de structures [*] sur plusieurs niveaux d'abstraction. Et hop, adieu les rêves de performance.
UDI, c'est beau sur le papier, c'est une bonne idée pour les PHB et autres décideurs pressés, mais c'est un niveau d'abstraction trop haut, trop ambitieux, pour qu'il soit intéressant dans les faits.
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples (c'était un projet développé au LAMI si je me souvient bien, un truc du nom de DEVIL, mais depuis les chercheurs concernés se sont intéressé à autre choses)
Pour les mêmes raisons qui conduisent à éviter UDI : modéliser le comportement d'un matériel est insuffisant, un bon driver est écrit en fonction du matériel ET du système sur lequel il va fonctionner.
Intéressant, dommage que ça n'est pas abouti ...
Dommage ? Non, pas vraiment.
Si chacun joue le jeu, tu as une phase longue de cohabitation de
l'interface native (existante) du système, plus l'interface UDI. Tant
que tous les pilotes ne sont pas convertis en UDI, tu as donc du code
supplémentaire, ayant des bugs différents. Plus les bugs lors de la
conversion natif->UDI.
De plus, suppose qu'une nouvelle génération de matériel, avec quelques
particularités qui obligent à rendre caduque une interface UDI (par
exemple, parce qu'une opération considérée comme atomique ne l'est plus,
et nécessite un traitement supplémentaire entre les deux moitiés
réellement atomiques). Il n'est pas possible de faire la modification
rapidement, puisqu'il faut que le comité/consortium/parti/etc se mette
d'accord sur la nouvelle interface et publie une nouvelle version de la
spécification (et je passe sous silence les joies de la compatiblité
descendante).
Autre possibilité, une amélioration du système (par exemple zero-copy
TCP ou XiP) peut être rendue inopérante parce que l'interface UDI ne
sera pas assez générique (ou le sera trop, selon le point de vue) et
provoquera forcément des copies de données pour rien, ou des essorages
de structures [*] sur plusieurs niveaux d'abstraction. Et hop, adieu les
rêves de performance.
UDI, c'est beau sur le papier, c'est une bonne idée pour les PHB et
autres décideurs pressés, mais c'est un niveau d'abstraction trop haut,
trop ambitieux, pour qu'il soit intéressant dans les faits.
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec
un compilo adpaté pour chaque système. Il existe un DSL pour des
drivers simples (c'était un projet développé au LAMI si je me souvient
bien, un truc du nom de DEVIL, mais depuis les chercheurs concernés se
sont intéressé à autre choses)
Pour les mêmes raisons qui conduisent à éviter UDI : modéliser le
comportement d'un matériel est insuffisant, un bon driver est écrit en
fonction du matériel ET du système sur lequel il va fonctionner.
Si chacun joue le jeu, tu as une phase longue de cohabitation de l'interface native (existante) du système, plus l'interface UDI. Tant que tous les pilotes ne sont pas convertis en UDI, tu as donc du code supplémentaire, ayant des bugs différents. Plus les bugs lors de la conversion natif->UDI.
De plus, suppose qu'une nouvelle génération de matériel, avec quelques particularités qui obligent à rendre caduque une interface UDI (par exemple, parce qu'une opération considérée comme atomique ne l'est plus, et nécessite un traitement supplémentaire entre les deux moitiés réellement atomiques). Il n'est pas possible de faire la modification rapidement, puisqu'il faut que le comité/consortium/parti/etc se mette d'accord sur la nouvelle interface et publie une nouvelle version de la spécification (et je passe sous silence les joies de la compatiblité descendante).
Autre possibilité, une amélioration du système (par exemple zero-copy TCP ou XiP) peut être rendue inopérante parce que l'interface UDI ne sera pas assez générique (ou le sera trop, selon le point de vue) et provoquera forcément des copies de données pour rien, ou des essorages de structures [*] sur plusieurs niveaux d'abstraction. Et hop, adieu les rêves de performance.
UDI, c'est beau sur le papier, c'est une bonne idée pour les PHB et autres décideurs pressés, mais c'est un niveau d'abstraction trop haut, trop ambitieux, pour qu'il soit intéressant dans les faits.
Sinon, pourquoi pas passer par un DSL (Domain Specific Language) avec un compilo adpaté pour chaque système. Il existe un DSL pour des drivers simples (c'était un projet développé au LAMI si je me souvient bien, un truc du nom de DEVIL, mais depuis les chercheurs concernés se sont intéressé à autre choses)
Pour les mêmes raisons qui conduisent à éviter UDI : modéliser le comportement d'un matériel est insuffisant, un bon driver est écrit en fonction du matériel ET du système sur lequel il va fonctionner.
Cyrille Szymanski
On 2005-06-03, Miod Vallat wrote:
Intéressant, dommage que ça n'est pas abouti ...
Dommage ? Non, pas vraiment.
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour créer une interface de ce type ?
Tant que tous les pilotes ne sont pas convertis en UDI, tu as donc du code supplémentaire, ayant des bugs différents.
Si l'idée c'est qu'à terme UDI remplace l'interface actuelle je ne vois pas le problème. On peut aussi bien créer un fork voire une branche 100% UDI et incorporer les drivers au fur et à mesure de leur développement.
De plus, suppose qu'une nouvelle génération de matériel, avec quelques particularités qui obligent à rendre caduque une interface UDI
Je ne dois pas très bien avoir compris ce qu'était UDI alors. Pour moi l'avantage c'était d'offrir une même interface au matériel. Par exemple tu as du code pour manipuler le bus PCI sur beaucoup d'architectures/os différents et toutes offrent les mêmes services. Pourquoi ne pas les unifier ? Aujourd'hui ces unifications ne dépassent pas le cadre de l'OS et c'est dommage.
Autre possibilité, une amélioration du système (par exemple zero-copy TCP ou XiP) peut être rendue inopérante parce que l'interface UDI ne sera pas assez générique
Oui.
Pour les mêmes raisons qui conduisent à éviter UDI : modéliser le comportement d'un matériel est insuffisant, un bon driver est écrit en fonction du matériel ET du système sur lequel il va fonctionner.
Tu penses que c'est vraiment mieux quand le même driver est réécrit pour chaque architecture/os avec tous les bugs qui peuvent apparaître lors du portage ? Sans parler du fait que un design qui était bon sur une plateforme peut se révéler un cauchemar sur une autre ?
Un UDI-like ne résoudra pas ce genre de problème c'est clair ; mais à mon avis ça ne rendra pas les choses pire que ce qu'elles sont aujourd'hui.
-- Cyrille Szymanski
On 2005-06-03, Miod Vallat <miod@online.fr> wrote:
Intéressant, dommage que ça n'est pas abouti ...
Dommage ? Non, pas vraiment.
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour
créer une interface de ce type ?
Tant que tous les pilotes ne sont pas convertis en UDI, tu as donc du code
supplémentaire, ayant des bugs différents.
Si l'idée c'est qu'à terme UDI remplace l'interface actuelle je ne vois pas le
problème. On peut aussi bien créer un fork voire une branche 100% UDI et
incorporer les drivers au fur et à mesure de leur développement.
De plus, suppose qu'une nouvelle génération de matériel, avec quelques
particularités qui obligent à rendre caduque une interface UDI
Je ne dois pas très bien avoir compris ce qu'était UDI alors. Pour moi
l'avantage c'était d'offrir une même interface au matériel. Par exemple tu as
du code pour manipuler le bus PCI sur beaucoup d'architectures/os différents et
toutes offrent les mêmes services. Pourquoi ne pas les unifier ? Aujourd'hui
ces unifications ne dépassent pas le cadre de l'OS et c'est dommage.
Autre possibilité, une amélioration du système (par exemple zero-copy
TCP ou XiP) peut être rendue inopérante parce que l'interface UDI ne
sera pas assez générique
Oui.
Pour les mêmes raisons qui conduisent à éviter UDI : modéliser le
comportement d'un matériel est insuffisant, un bon driver est écrit en
fonction du matériel ET du système sur lequel il va fonctionner.
Tu penses que c'est vraiment mieux quand le même driver est réécrit pour chaque
architecture/os avec tous les bugs qui peuvent apparaître lors du portage ?
Sans parler du fait que un design qui était bon sur une plateforme peut se
révéler un cauchemar sur une autre ?
Un UDI-like ne résoudra pas ce genre de problème c'est clair ; mais à mon avis
ça ne rendra pas les choses pire que ce qu'elles sont aujourd'hui.
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour créer une interface de ce type ?
Tant que tous les pilotes ne sont pas convertis en UDI, tu as donc du code supplémentaire, ayant des bugs différents.
Si l'idée c'est qu'à terme UDI remplace l'interface actuelle je ne vois pas le problème. On peut aussi bien créer un fork voire une branche 100% UDI et incorporer les drivers au fur et à mesure de leur développement.
De plus, suppose qu'une nouvelle génération de matériel, avec quelques particularités qui obligent à rendre caduque une interface UDI
Je ne dois pas très bien avoir compris ce qu'était UDI alors. Pour moi l'avantage c'était d'offrir une même interface au matériel. Par exemple tu as du code pour manipuler le bus PCI sur beaucoup d'architectures/os différents et toutes offrent les mêmes services. Pourquoi ne pas les unifier ? Aujourd'hui ces unifications ne dépassent pas le cadre de l'OS et c'est dommage.
Autre possibilité, une amélioration du système (par exemple zero-copy TCP ou XiP) peut être rendue inopérante parce que l'interface UDI ne sera pas assez générique
Oui.
Pour les mêmes raisons qui conduisent à éviter UDI : modéliser le comportement d'un matériel est insuffisant, un bon driver est écrit en fonction du matériel ET du système sur lequel il va fonctionner.
Tu penses que c'est vraiment mieux quand le même driver est réécrit pour chaque architecture/os avec tous les bugs qui peuvent apparaître lors du portage ? Sans parler du fait que un design qui était bon sur une plateforme peut se révéler un cauchemar sur une autre ?
Un UDI-like ne résoudra pas ce genre de problème c'est clair ; mais à mon avis ça ne rendra pas les choses pire que ce qu'elles sont aujourd'hui.
