> Si ça a un sens. D'un point de vue purement quantitatif ça nous dit quelle est la quantité de code spécifique à maintenir pour chaque architecture. Moins il y en a, plus il est facile de porter vers de nouvelles architectures
Tout ça c'est joli, mais NetBSD ne supporte pas des applis de plus 2 Go. C'est ça pour toi la portabilité ?
> Moins il y en a, plus il est facile de porter vers de nouvelles architectures
Pas forcément. Il y a ce qui est spécifique et ce qui est lié à l'optimisation. Ce qui est spécifique, doit vraiment être spécifique. D'où par exemple Linux qui fusionne i386 avec x86_64 car ses architectures ont beaucoup de points communs. Mais dans ce cas, on dit quoi pour les "chiffres précis" ? Qu'il y a 0 lignes de spécifique pour x86_86 ? Où que c'est la somme des lignes pour l'architecture "virtuelle" qui supporte i386 et x86_64 ? Où seulement la moitier ?
Pour la libc il n'y a rien de spécifique entre i386 et x86_64. Il n'y a rien de spécifique car la glibc est conçu pour (et utilise les entêtes "spécifiques" de Linux). Par contre il peut y avoir plein d'optimisations. Et il y en a beaucoup. Ce n'est pas de la portabilité dans ce dernier cas, c'est de l'optimisation. Ces lignes d'optimisations, tu les mets où ? Toujours en spécifique ?
> Maintenant, vu que des chiffres précis te sont présentés
Bof. Pourquoi NetBSD ne supporte pas les applis avec plus de 2 Go si c'est si simple ? Si les "chiffres précis" laissent entendre que c'est si simple ?
Et pour que NetBSD supporte les applis de plus de 2 Go, quel va être la taille du/des patch(s) ? Sûr que ça ne sera pas léger (sinon ça serait déjà fait). Mais ces "chiffres précis" ne vont pas changer...
Alors ils représentent quoi ces "chiffres précis" ?
> plutôt que de te contenter de dire "Non, de toute façon ça sert à rien"
Je n'ai pas dit ça.
J'ai seulement dit que le critière du nombre de ligne n'indique en rien une supériorité ou une infériorité. Dans un certain contexte, par exemple la portabilité, ça peut être significatif/important. Pour d'autres contextes c'est une toute autre histoire. Linux ne veux pas être le champion de la portabilité et qu'il y ait plus de lignes de code spécifiques pour une architecture n'indique absolument pas qu'il est moins bien foutu que NetBSD.
> donne-nous de l'argument technique ou du chiffre plutôt qu'une simple opinion "éclairée".
Les chiffres, je ne les ai pas.
Mais je ne me fais pas un avis seulement sur des chiffres.
> plutôt qu'une simple opinion "éclairée".
Ce n'est pas "éclairé" dans le sens "spécialiste", c'est seulement du bon sens.
> Si c'était si "grave", je pense qu'il y aurait eu une pression plus forte de la communauté (et donc on aurait plus de résultat après une petite recherche).
Très juste. Il n'y a pas de raison technique sur ce manque.
> est-ce que Linux ne devrait pas plutôt s'empresser d'intégrer grsec au lieu de développer 36 schedulers et 26 API de virtualisation ? ;)
Pour du troll, c'est du troll. Linux a mieux que grsec, c'est SeLinux. Il n'y a pas 26 API de virtualisation, mais qu'une : KVM. Il y a deux modes de virtualisation : paravirtualisation et full-virtualisation. KVM/pv_ops ne fait pas de paravirtualisation enoore. Mais ça ne va pas tarder : http://berrange.com/personal/diary/2008/02/progress-in-fedor(...)
Il y a lguest qui est dédié "laboratoire".
Il y a une parties de Xen qui a été intégrée à Linux mais seulement pour des raisons de compatibilité. Pour que Linux support en invité des OS Xen. Ce code ne fera pas doublon, il va être utilisé par KVM/pv_ops.
Et pour ce qui est du côté "clean", Linux a refusé Xen car trop intrusif. Et NetBSD ?
[^] # Re: 2 Go
Posté par IsNotGood . En réponse au journal Un article intéressant sur NetBSD. Évalué à 0.
Tout ça c'est joli, mais NetBSD ne supporte pas des applis de plus 2 Go. C'est ça pour toi la portabilité ?
> Moins il y en a, plus il est facile de porter vers de nouvelles architectures
Pas forcément. Il y a ce qui est spécifique et ce qui est lié à l'optimisation. Ce qui est spécifique, doit vraiment être spécifique. D'où par exemple Linux qui fusionne i386 avec x86_64 car ses architectures ont beaucoup de points communs. Mais dans ce cas, on dit quoi pour les "chiffres précis" ? Qu'il y a 0 lignes de spécifique pour x86_86 ? Où que c'est la somme des lignes pour l'architecture "virtuelle" qui supporte i386 et x86_64 ? Où seulement la moitier ?
Pour la libc il n'y a rien de spécifique entre i386 et x86_64. Il n'y a rien de spécifique car la glibc est conçu pour (et utilise les entêtes "spécifiques" de Linux). Par contre il peut y avoir plein d'optimisations. Et il y en a beaucoup. Ce n'est pas de la portabilité dans ce dernier cas, c'est de l'optimisation. Ces lignes d'optimisations, tu les mets où ? Toujours en spécifique ?
> Maintenant, vu que des chiffres précis te sont présentés
Bof. Pourquoi NetBSD ne supporte pas les applis avec plus de 2 Go si c'est si simple ? Si les "chiffres précis" laissent entendre que c'est si simple ?
Et pour que NetBSD supporte les applis de plus de 2 Go, quel va être la taille du/des patch(s) ? Sûr que ça ne sera pas léger (sinon ça serait déjà fait). Mais ces "chiffres précis" ne vont pas changer...
Alors ils représentent quoi ces "chiffres précis" ?
> plutôt que de te contenter de dire "Non, de toute façon ça sert à rien"
Je n'ai pas dit ça.
J'ai seulement dit que le critière du nombre de ligne n'indique en rien une supériorité ou une infériorité. Dans un certain contexte, par exemple la portabilité, ça peut être significatif/important. Pour d'autres contextes c'est une toute autre histoire. Linux ne veux pas être le champion de la portabilité et qu'il y ait plus de lignes de code spécifiques pour une architecture n'indique absolument pas qu'il est moins bien foutu que NetBSD.
> donne-nous de l'argument technique ou du chiffre plutôt qu'une simple opinion "éclairée".
Les chiffres, je ne les ai pas.
Mais je ne me fais pas un avis seulement sur des chiffres.
> plutôt qu'une simple opinion "éclairée".
Ce n'est pas "éclairé" dans le sens "spécialiste", c'est seulement du bon sens.
> Si c'était si "grave", je pense qu'il y aurait eu une pression plus forte de la communauté (et donc on aurait plus de résultat après une petite recherche).
Très juste. Il n'y a pas de raison technique sur ce manque.
> est-ce que Linux ne devrait pas plutôt s'empresser d'intégrer grsec au lieu de développer 36 schedulers et 26 API de virtualisation ? ;)
Pour du troll, c'est du troll. Linux a mieux que grsec, c'est SeLinux. Il n'y a pas 26 API de virtualisation, mais qu'une : KVM. Il y a deux modes de virtualisation : paravirtualisation et full-virtualisation. KVM/pv_ops ne fait pas de paravirtualisation enoore. Mais ça ne va pas tarder :
http://berrange.com/personal/diary/2008/02/progress-in-fedor(...)
Il y a lguest qui est dédié "laboratoire".
Il y a une parties de Xen qui a été intégrée à Linux mais seulement pour des raisons de compatibilité. Pour que Linux support en invité des OS Xen. Ce code ne fera pas doublon, il va être utilisé par KVM/pv_ops.
Et pour ce qui est du côté "clean", Linux a refusé Xen car trop intrusif. Et NetBSD ?