Globalement ce que je veux dire c'est que ça n'a aucun sens de dire "machin à X lignes spécifiques, ce qui est mieux que bidule qui en a Y, etc"
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 et d'introduire de nouvelles fonctionnalités ou en modifier d'anciennes sans avoir à modifier énormément de code.
Par rapport à la remarque initiale de patrick_g, ça montre qu'il n'est peut-être pas si ridicule qu'on voit des ports vers de nouvelles architecture alors même qu'un problème important subsiste. Si le "coût" (dans tous les sens du terme) du port n'est pas élevé, ça peut bien expliquer cette situation.
Maintenant, vu que des chiffres précis te sont présentés, plutôt que de te contenter de dire "Non, de toute façon ça sert à rien", donne-nous de l'argument technique ou du chiffre plutôt qu'une simple opinion "éclairée".
Pour revenir à la question de patrick_g (dont la formulation est quand même un peu trollesque), je trouve également ça assez surprenant. Le port amd64 date d'au moins 2003, a été réalisé par un développeur de Wasabi (_la_ boîte derrière NetBSD) en partenariat avec AMD. D'autre part, la limite de 2Go par processus me semble être dépassée depuis plusieurs années sur d'autres architectures (i386, macppc) d'après une petite recherche. Peut-être que le profil habituel d'utilisation de NetBSD fait qu'AMD64 n'est pas populaire chez ses utilisateurs. 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).
Après vu qu'il ne semble s'agir que d'une seule architecture, c'est peut-être simplement un choix de priorité. Pas si ridicule. Ou alors dans le même genre, 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 ? ;)
[^] # Re: 2 Go
Posté par vjm . En réponse au journal Un article intéressant sur NetBSD. Évalué à 2.
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 et d'introduire de nouvelles fonctionnalités ou en modifier d'anciennes sans avoir à modifier énormément de code.
Par rapport à la remarque initiale de patrick_g, ça montre qu'il n'est peut-être pas si ridicule qu'on voit des ports vers de nouvelles architecture alors même qu'un problème important subsiste. Si le "coût" (dans tous les sens du terme) du port n'est pas élevé, ça peut bien expliquer cette situation.
Maintenant, vu que des chiffres précis te sont présentés, plutôt que de te contenter de dire "Non, de toute façon ça sert à rien", donne-nous de l'argument technique ou du chiffre plutôt qu'une simple opinion "éclairée".
Pour revenir à la question de patrick_g (dont la formulation est quand même un peu trollesque), je trouve également ça assez surprenant. Le port amd64 date d'au moins 2003, a été réalisé par un développeur de Wasabi (_la_ boîte derrière NetBSD) en partenariat avec AMD. D'autre part, la limite de 2Go par processus me semble être dépassée depuis plusieurs années sur d'autres architectures (i386, macppc) d'après une petite recherche. Peut-être que le profil habituel d'utilisation de NetBSD fait qu'AMD64 n'est pas populaire chez ses utilisateurs. 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).
Après vu qu'il ne semble s'agir que d'une seule architecture, c'est peut-être simplement un choix de priorité. Pas si ridicule. Ou alors dans le même genre, 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 ? ;)