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) --
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.
En fait, le problème est plus du côté des constructeurs finalement, et ça se voit bien sur PC. Chaque nouveau modele vient avec sa propre façon de faire, sans forcément de bonne raison.
Prennons l'exemple des cartes réseau ethernet, elles font toutes la même chose et fournissent toutes le même service, pourtant chaque carte a sa propre façon de parler avec le système avec une forte tendance à s'éloigner le plus possible de ce que font les autres. C'est lamentable, si on regarde bien, je suis sûr que l'écriture de drivers représentent la majeure partie des modifications, mise à jour et aute sorte de commit dans les sources des OS libres.
Et la simplicité, ou la généricité d'un matériel n'y change rien.
Pourtant, dans certains domains (par exemple les périph de stockages en USB ou les cartes son Firewire) il existe une forme de standard et/ou un protocol unique de communication, plus ou moins ouvert mais unique.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <slrnda0jns.1uh.cns@szymanski4.rez-gif.supelec.fr>,
Cyrille Szymanski wrote:
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.
En fait, le problème est plus du côté des constructeurs finalement, et
ça se voit bien sur PC. Chaque nouveau modele vient avec sa propre
façon de faire, sans forcément de bonne raison.
Prennons l'exemple des cartes réseau ethernet, elles font toutes la
même chose et fournissent toutes le même service, pourtant chaque
carte a sa propre façon de parler avec le système avec une forte
tendance à s'éloigner le plus possible de ce que font les
autres. C'est lamentable, si on regarde bien, je suis sûr que
l'écriture de drivers représentent la majeure partie des
modifications, mise à jour et aute sorte de commit dans les sources
des OS libres.
Et la simplicité, ou la généricité d'un matériel n'y change rien.
Pourtant, dans certains domains (par exemple les périph de stockages
en USB ou les cartes son Firewire) il existe une forme de standard
et/ou un protocol unique de communication, plus ou moins ouvert mais
unique.
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
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.
En fait, le problème est plus du côté des constructeurs finalement, et ça se voit bien sur PC. Chaque nouveau modele vient avec sa propre façon de faire, sans forcément de bonne raison.
Prennons l'exemple des cartes réseau ethernet, elles font toutes la même chose et fournissent toutes le même service, pourtant chaque carte a sa propre façon de parler avec le système avec une forte tendance à s'éloigner le plus possible de ce que font les autres. C'est lamentable, si on regarde bien, je suis sûr que l'écriture de drivers représentent la majeure partie des modifications, mise à jour et aute sorte de commit dans les sources des OS libres.
Et la simplicité, ou la généricité d'un matériel n'y change rien.
Pourtant, dans certains domains (par exemple les périph de stockages en USB ou les cartes son Firewire) il existe une forme de standard et/ou un protocol unique de communication, plus ou moins ouvert mais unique.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Cyrille Szymanski
On 2005-06-03, Marwan Burelle 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 (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)
Ça a l'air très intéressant comme approche mais pour le coup ça me paraît vraiment ambitieux. De toute façon, il faut standardiser une interface pour les différents composants matériels. Ensuite on peut s'attaquer au code MI.
-- Cyrille Szymanski
On 2005-06-03, Marwan Burelle <burelle@lri.fr> 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 (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)
Ça a l'air très intéressant comme approche mais pour le coup ça me paraît
vraiment ambitieux. De toute façon, il faut standardiser une interface pour
les différents composants matériels. Ensuite on peut s'attaquer au code MI.
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)
Ça a l'air très intéressant comme approche mais pour le coup ça me paraît vraiment ambitieux. De toute façon, il faut standardiser une interface pour les différents composants matériels. Ensuite on peut s'attaquer au code MI.
-- Cyrille Szymanski
Miod Vallat
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour créer une interface de ce type ?
Toute initiative.
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.
Parce que dans ce cas, tu ne peux pas utiliser une éventuelle amélioration du bus tant que la norme UDI n'est pas mise à jour. Et que ça peut prendre du temps.
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 ?
Non, mais moi je me fiche totalement des bugs que peuvent avoir les drivers des autres systèmes.
Sans parler du fait que un design qui était bon sur une plateforme peut se révéler un cauchemar sur une autre ?
Justement, je doute que des interfaces genre UDI soient suffisamment souples pour ce genre de situation (rien que la gestion de cohérence de cache entre différentes architectures est un sac de noeuds).
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour
créer une interface de ce type ?
Toute initiative.
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.
Parce que dans ce cas, tu ne peux pas utiliser une éventuelle
amélioration du bus tant que la norme UDI n'est pas mise à jour. Et que
ça peut prendre du temps.
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 ?
Non, mais moi je me fiche totalement des bugs que peuvent avoir les
drivers des autres systèmes.
Sans parler du fait que un design qui était bon sur une plateforme peut se
révéler un cauchemar sur une autre ?
Justement, je doute que des interfaces genre UDI soient suffisamment
souples pour ce genre de situation (rien que la gestion de cohérence de
cache entre différentes architectures est un sac de noeuds).
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour créer une interface de ce type ?
Toute initiative.
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.
Parce que dans ce cas, tu ne peux pas utiliser une éventuelle amélioration du bus tant que la norme UDI n'est pas mise à jour. Et que ça peut prendre du temps.
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 ?
Non, mais moi je me fiche totalement des bugs que peuvent avoir les drivers des autres systèmes.
Sans parler du fait que un design qui était bon sur une plateforme peut se révéler un cauchemar sur une autre ?
Justement, je doute que des interfaces genre UDI soient suffisamment souples pour ce genre de situation (rien que la gestion de cohérence de cache entre différentes architectures est un sac de noeuds).
laurent.pertois
Eric Masson wrote:
<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>
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Eric Masson <emss@free.fr> wrote:
<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>
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
<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>
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Arnaud Launay
Le Fri, 27 May 2005 20:26:34 +0000 (UTC), Michel Talon écrivit:
Autrement dit quand tu as 500 ports installés, tu les recompile tous à chaque fois que tu fais un cvsup. Merci, je n'ai pas installé une Gentoo c'est pas pour faire la même chose sous FreeBSD.
Le Fri, 27 May 2005 20:26:34 +0000 (UTC), Michel Talon écrivit:
Autrement dit quand tu as 500 ports installés, tu les recompile
tous à chaque fois que tu fais un cvsup. Merci, je n'ai pas
installé une Gentoo c'est pas pour faire la même chose sous
FreeBSD.
Le Fri, 27 May 2005 20:26:34 +0000 (UTC), Michel Talon écrivit:
Autrement dit quand tu as 500 ports installés, tu les recompile tous à chaque fois que tu fais un cvsup. Merci, je n'ai pas installé une Gentoo c'est pas pour faire la même chose sous FreeBSD.
Le Fri, 27 May 2005 20:26:34 +0000 (UTC), Michel Talon écrivit:
Autrement dit quand tu as 500 ports installés, tu les recompile tous à chaque fois que tu fais un cvsup. Merci, je n'ai pas installé une Gentoo c'est pas pour faire la même chose sous FreeBSD.
Heu, la Gentoo ne fait pas ce genre de choses...
Tout balacer dans l'userland, c'est bien mieux. C'est vachement plus marrant quand tu bouzille un portage comme perl, au pif....
-- Laurent
Arnaud Launay <asl@launay.org> writes:
Le Fri, 27 May 2005 20:26:34 +0000 (UTC), Michel Talon écrivit:
Autrement dit quand tu as 500 ports installés, tu les recompile
tous à chaque fois que tu fais un cvsup. Merci, je n'ai pas
installé une Gentoo c'est pas pour faire la même chose sous
FreeBSD.
Heu, la Gentoo ne fait pas ce genre de choses...
Tout balacer dans l'userland, c'est bien mieux. C'est vachement plus
marrant quand tu bouzille un portage comme perl, au pif....
Le Fri, 27 May 2005 20:26:34 +0000 (UTC), Michel Talon écrivit:
Autrement dit quand tu as 500 ports installés, tu les recompile tous à chaque fois que tu fais un cvsup. Merci, je n'ai pas installé une Gentoo c'est pas pour faire la même chose sous FreeBSD.
Heu, la Gentoo ne fait pas ce genre de choses...
Tout balacer dans l'userland, c'est bien mieux. C'est vachement plus marrant quand tu bouzille un portage comme perl, au pif....
-- Laurent
Cyrille Szymanski
Miod Vallat wrote in news:42a06a68$0$4842$:
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour créer une interface de ce type ?
Toute initiative.
Parce que dans ce cas, tu ne peux pas utiliser une éventuelle amélioration du bus tant que la norme UDI n'est pas mise à jour. Et que ça peut prendre du temps.
C'est le prix à payer. La politique de NetBSD "it doesn't work unless it's right" va dans ce sens et ça n'a rien d'étonnant.
Apple est un peu en train de prouver qu'avec une API bien foutue on peut passer d'un monde à l'autre assez facilement. Dans leurs keynotes ils ont annoncé qu'il faisaient tourner presque toutes leurs applis sur i386 depuis 10.0
Pour moi c'est un des modèles de développement le plus pérenne. Jusqu'au jour où c'est trop bloated et qu'on repart à zéro c'est vrai, mais c'est toujours mieux que de ne jamais être arrivé à ce point.
moi je me fiche totalement des bugs que peuvent avoir les drivers des autres systèmes.
C'est pas vraiment un argument (et en plus c'est égoiste comme vision) vu que très souvent les drivers sont portés un peu dans tous les sens. Donc son bug c'est ton bug.
Et UDI ou pas, rien n'empêche un OS d'avoir son propre driver (UDI ou non d'ailleurs).
Sans parler du fait que un design qui était bon sur une plateforme peut se révéler un cauchemar sur une autre ?
Justement, je doute que des interfaces genre UDI soient suffisamment souples pour ce genre de situation (rien que la gestion de cohérence de cache entre différentes architectures est un sac de noeuds).
Peut-être que justement l'erreur c'est de vouloir faire une norme multi-architecture. En fait si on peut partager le même driver sur tous les i386 c'est déjà pas si mal. Et si avec quelques légères modifications on obtient une version sparc, ppc ou autre moi je trouve ça génial.
-- Cyrille Szymanski
Miod Vallat <miod@online.fr> wrote in
news:42a06a68$0$4842$636a15ce@news.free.fr:
Tu critiques spécifiquement UDI ou plus généralement toute initiative
pour créer une interface de ce type ?
Toute initiative.
Parce que dans ce cas, tu ne peux pas utiliser une éventuelle
amélioration du bus tant que la norme UDI n'est pas mise à jour. Et
que ça peut prendre du temps.
C'est le prix à payer. La politique de NetBSD "it doesn't work
unless it's right" va dans ce sens et ça n'a rien d'étonnant.
Apple est un peu en train de prouver qu'avec une API bien foutue
on peut passer d'un monde à l'autre assez facilement. Dans leurs
keynotes ils ont annoncé qu'il faisaient tourner presque toutes leurs
applis sur i386 depuis 10.0
Pour moi c'est un des modèles de développement le plus pérenne.
Jusqu'au jour où c'est trop bloated et qu'on repart à zéro c'est
vrai, mais c'est toujours mieux que de ne jamais être arrivé à
ce point.
moi je me fiche totalement des bugs que peuvent avoir les
drivers des autres systèmes.
C'est pas vraiment un argument (et en plus c'est égoiste comme
vision) vu que très souvent les drivers sont portés un peu dans
tous les sens. Donc son bug c'est ton bug.
Et UDI ou pas, rien n'empêche un OS d'avoir son propre driver
(UDI ou non d'ailleurs).
Sans parler du fait que un design qui était bon sur une plateforme
peut se révéler un cauchemar sur une autre ?
Justement, je doute que des interfaces genre UDI soient suffisamment
souples pour ce genre de situation (rien que la gestion de cohérence
de cache entre différentes architectures est un sac de noeuds).
Peut-être que justement l'erreur c'est de vouloir faire une norme
multi-architecture. En fait si on peut partager le même driver sur
tous les i386 c'est déjà pas si mal. Et si avec quelques légères
modifications on obtient une version sparc, ppc ou autre moi je
trouve ça génial.
Tu critiques spécifiquement UDI ou plus généralement toute initiative pour créer une interface de ce type ?
Toute initiative.
Parce que dans ce cas, tu ne peux pas utiliser une éventuelle amélioration du bus tant que la norme UDI n'est pas mise à jour. Et que ça peut prendre du temps.
C'est le prix à payer. La politique de NetBSD "it doesn't work unless it's right" va dans ce sens et ça n'a rien d'étonnant.
Apple est un peu en train de prouver qu'avec une API bien foutue on peut passer d'un monde à l'autre assez facilement. Dans leurs keynotes ils ont annoncé qu'il faisaient tourner presque toutes leurs applis sur i386 depuis 10.0
Pour moi c'est un des modèles de développement le plus pérenne. Jusqu'au jour où c'est trop bloated et qu'on repart à zéro c'est vrai, mais c'est toujours mieux que de ne jamais être arrivé à ce point.
moi je me fiche totalement des bugs que peuvent avoir les drivers des autres systèmes.
C'est pas vraiment un argument (et en plus c'est égoiste comme vision) vu que très souvent les drivers sont portés un peu dans tous les sens. Donc son bug c'est ton bug.
Et UDI ou pas, rien n'empêche un OS d'avoir son propre driver (UDI ou non d'ailleurs).
Sans parler du fait que un design qui était bon sur une plateforme peut se révéler un cauchemar sur une autre ?
Justement, je doute que des interfaces genre UDI soient suffisamment souples pour ce genre de situation (rien que la gestion de cohérence de cache entre différentes architectures est un sac de noeuds).
Peut-être que justement l'erreur c'est de vouloir faire une norme multi-architecture. En fait si on peut partager le même driver sur tous les i386 c'est déjà pas si mal. Et si avec quelques légères modifications on obtient une version sparc, ppc ou autre moi je trouve ça génial.
-- Cyrille Szymanski
Cyrille Szymanski
Marwan Burelle wrote in news::
En fait, le problème est plus du côté des constructeurs finalement, et ça se voit bien sur PC. Chaque nouveau modele vient avec sa propre façon de faire, sans forcément de bonne raison.
Et la simplicité, ou la généricité d'un matériel n'y change rien.
Pourtant, dans certains domains (par exemple les périph de stockages en USB ou les cartes son Firewire) il existe une forme de standard et/ou un protocol unique de communication, plus ou moins ouvert mais unique.
Oui, ce qui est dommage c'est que les gens ne développent pas de standard et qu'ils font tout dans leur coin. Et quand un standard pointe le bout de son nez, il fait l'objet d'une guerre de parts de marché (USB/FireWire par exemple).
Pour le reste, il faut avoir beaucoup d'énergie pour les faire évoluer rapidement.
Ou alors tu as des organismes comme le W3C qui fonctionnent bien, mais personne ne les écoute malheureusement.
Dès qu'il faut faire travailler plusieurs organisations en commun tout s'écroule.
-- Cyrille Szymanski
Marwan Burelle <burelle@lri.fr> wrote in
news:slrnda0ka8.avf.burelle@pc5-179.lri.fr:
En fait, le problème est plus du côté des constructeurs finalement, et
ça se voit bien sur PC. Chaque nouveau modele vient avec sa propre
façon de faire, sans forcément de bonne raison.
Et la simplicité, ou la généricité d'un matériel n'y change rien.
Pourtant, dans certains domains (par exemple les périph de stockages
en USB ou les cartes son Firewire) il existe une forme de standard
et/ou un protocol unique de communication, plus ou moins ouvert mais
unique.
Oui, ce qui est dommage c'est que les gens ne développent pas de
standard et qu'ils font tout dans leur coin. Et quand un standard
pointe le bout de son nez, il fait l'objet d'une guerre de parts de
marché (USB/FireWire par exemple).
Pour le reste, il faut avoir beaucoup d'énergie pour les faire évoluer
rapidement.
Ou alors tu as des organismes comme le W3C qui fonctionnent bien, mais
personne ne les écoute malheureusement.
Dès qu'il faut faire travailler plusieurs organisations en commun
tout s'écroule.
En fait, le problème est plus du côté des constructeurs finalement, et ça se voit bien sur PC. Chaque nouveau modele vient avec sa propre façon de faire, sans forcément de bonne raison.
Et la simplicité, ou la généricité d'un matériel n'y change rien.
Pourtant, dans certains domains (par exemple les périph de stockages en USB ou les cartes son Firewire) il existe une forme de standard et/ou un protocol unique de communication, plus ou moins ouvert mais unique.
Oui, ce qui est dommage c'est que les gens ne développent pas de standard et qu'ils font tout dans leur coin. Et quand un standard pointe le bout de son nez, il fait l'objet d'une guerre de parts de marché (USB/FireWire par exemple).
Pour le reste, il faut avoir beaucoup d'énergie pour les faire évoluer rapidement.
Ou alors tu as des organismes comme le W3C qui fonctionnent bien, mais personne ne les écoute malheureusement.
Dès qu'il faut faire travailler plusieurs organisations en commun tout s'écroule.
-- Cyrille Szymanski
Marwan Burelle
In article , Cyrille Szymanski wrote:
Ou alors tu as des organismes comme le W3C qui fonctionnent bien, mais personne ne les écoute malheureusement.
Je ne peux pas te laisser dire que le W3C fonctionne bien, ils ont la spécialité de sortie des standards compliqués pas toujours très simple à mettre en oeuvre et pas toujours en adéquation avec la réalité. Prennons l'exemple d'XQuery (langage de requète pour XML), ce langage est contradiction avec la plus part des caractéristiques d'un langage de requètes (terminaison, complexité en temps polynomial, déclarativité ... ) et en plus le pseudo-système de types qu'ils lui ont collés est foireux, alors qu'il existe de nombreux projets de recherche avec des systèmes de types orientés XML qui marchent (et qui existaient avant XQuery pour certains ... )
Donc forcément, dans ce genre de contexte tu n'as pas forcément envie de suivre leur recommandantions ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <Xns966EA0A9C855Acns2cnsinvalid@212.27.42.65>,
Cyrille Szymanski wrote:
Ou alors tu as des organismes comme le W3C qui fonctionnent bien, mais
personne ne les écoute malheureusement.
Je ne peux pas te laisser dire que le W3C fonctionne bien, ils ont la
spécialité de sortie des standards compliqués pas toujours très simple
à mettre en oeuvre et pas toujours en adéquation avec la
réalité. Prennons l'exemple d'XQuery (langage de requète pour XML), ce
langage est contradiction avec la plus part des caractéristiques d'un
langage de requètes (terminaison, complexité en temps polynomial,
déclarativité ... ) et en plus le pseudo-système de types qu'ils lui
ont collés est foireux, alors qu'il existe de nombreux projets de
recherche avec des systèmes de types orientés XML qui marchent (et qui
existaient avant XQuery pour certains ... )
Donc forcément, dans ce genre de contexte tu n'as pas forcément envie
de suivre leur recommandantions ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Ou alors tu as des organismes comme le W3C qui fonctionnent bien, mais personne ne les écoute malheureusement.
Je ne peux pas te laisser dire que le W3C fonctionne bien, ils ont la spécialité de sortie des standards compliqués pas toujours très simple à mettre en oeuvre et pas toujours en adéquation avec la réalité. Prennons l'exemple d'XQuery (langage de requète pour XML), ce langage est contradiction avec la plus part des caractéristiques d'un langage de requètes (terminaison, complexité en temps polynomial, déclarativité ... ) et en plus le pseudo-système de types qu'ils lui ont collés est foireux, alors qu'il existe de nombreux projets de recherche avec des systèmes de types orientés XML qui marchent (et qui existaient avant XQuery pour certains ... )
Donc forcément, dans ce genre de contexte tu n'as pas forcément envie de suivre leur recommandantions ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Miod Vallat
C'est le prix à payer. La politique de NetBSD "it doesn't work unless it's right" va dans ce sens et ça n'a rien d'étonnant.
Mais ils n'ont pas les mains liées par les autres participants à UDI. Ils peuvent changer leurs interfaces en interne au fur et à mesure des besoins de support matériel.
Et UDI ou pas, rien n'empêche un OS d'avoir son propre driver (UDI ou non d'ailleurs).
Sauf que si tu conserves deux interfaces, une UDI et une native, tu as deux fois plus de sources de bug et une masse de code potentiellement inutile ; ainsi qu'aucune motivation pour migrer vers UDI.
C'est le prix à payer. La politique de NetBSD "it doesn't work
unless it's right" va dans ce sens et ça n'a rien d'étonnant.
Mais ils n'ont pas les mains liées par les autres participants à UDI.
Ils peuvent changer leurs interfaces en interne au fur et à mesure des
besoins de support matériel.
Et UDI ou pas, rien n'empêche un OS d'avoir son propre driver
(UDI ou non d'ailleurs).
Sauf que si tu conserves deux interfaces, une UDI et une native, tu as
deux fois plus de sources de bug et une masse de code potentiellement
inutile ; ainsi qu'aucune motivation pour migrer vers UDI.
C'est le prix à payer. La politique de NetBSD "it doesn't work unless it's right" va dans ce sens et ça n'a rien d'étonnant.
Mais ils n'ont pas les mains liées par les autres participants à UDI. Ils peuvent changer leurs interfaces en interne au fur et à mesure des besoins de support matériel.
Et UDI ou pas, rien n'empêche un OS d'avoir son propre driver (UDI ou non d'ailleurs).
Sauf que si tu conserves deux interfaces, une UDI et une native, tu as deux fois plus de sources de bug et une masse de code potentiellement inutile ; ainsi qu'aucune motivation pour migrer vers UDI.
