Bonjour,
Je sais que c'est mal vu ici de poster un lien comme sujet
de journal, mais celui-ci est beau. :)
En fait, en lieu et place d'article, il s'agit d'une ( grosse ) série
d'interview de développeurs et gens gérant NetBSD.
Ce qui est intéressant avec ses interviews, c'est de plonger
un peu dans les arcanes de la création d'un système d'exploitation.
Sans rentrer trop dans la technique, on peut y lire les choix
politique ou fonctionnelle qui se pose pour des gens qui veulent
maintenir et faire évoluer de façon cohérente un OS.
Au final, pour les plus linuxiens d'entre vous, que ceci parle de
NetBSD n'a pas vraiment d'importance, c'est passionnant ! :)
http://arstechnica.com/articles/culture/netbsd4-interview.ar(...)
Journal Un article intéressant sur NetBSD
2
fév.
2008
# Non pas du tout...
Posté par Spack . Évalué à 10.
Ce n'est pas le fait de poster un lien qui est mal vu mais plutôt le fait de juste le poster c'est à dire sans aucune explication...
Dans ton cas rien à dire... On sait de quoi traite ton lien ;-)
# 2 Go
Posté par patrick_g (site web personnel) . Évalué à 8.
we are planning to fund other projects, for example:
* Solve beyond 2GB memory on amd64 problems
Celui-ci m'a fait sursauter. Sur un CPU x86-64 NetBSD ne sait pas gérer plus de 2 Go ? Vraiment ?
Ce ne serait pas un problème plus urgent à résoudre que de porter NetBSD sur des grilles-pains ?
Sinon interview très intéressante.
[^] # Re: 2 Go
Posté par kowalsky . Évalué à 3.
-Un lancer de troll
-Une stupidité...
Je m'explique au cas improbable ou ce n'est pas un lancer de troll...
C'est libre, les gens qui portent NetBSD sur un grille-pain le font parce
qu'ils sont content de le faire.
Ensuite, j'ai un NetBSD 4 avec 8Go de RAM
Pour info, voici le nombre de libre specifique à x86-64, c'est à
dire qui ne sont pas l'arbre de source general, pour simplifier.
--------------Assembly Line------C Line---------
libc : ------------------310----------2772----------
C startup : ----------0--------------104------------
libm : -----------------52------------0---------------
kernel :---------------3314---------17392--------
dynamic linker : ---59-------------172-----------
[^] # Re: 2 Go
Posté par IsNotGood . Évalué à 1.
Comme Linux, comme tout ce qui est libre.
> Ensuite, j'ai un NetBSD 4 avec 8Go de RAM
Le problème de 2 Go doit être par processus.
> Pour info, voici le nombre de libre specifique à x86-64, c'est à dire qui ne sont pas l'arbre de source general, pour simplifier.
Et ?
Je ne dois pas comprendre. J'ai une F8 sous x86_64, c'est les même source que pour i386, ppc et ppc64. Évidemment, il doit y avoir des "ifdef ...". Pour ce qui est "spécifique" x86_64, c'est dans linux/arch/x86_64 (ou un truc dans ce goût). Branche qui a été fusionnée avec i386 dans Linux 2.6.24.
Bref, pour comptabiliser, c'est quasi impossible. Alors c'est peut-être "pire" que NetBSD, mais il y a plus de 4 Go de mémoire par processus (c'est l'intérêt principal de x86_64). Et toutes les applis ont des pointeurs en 64 bits (contre 32 bits pour i386). Notons bien que sous Fedora (mais ça doit être la même chose pour Debian, etc), une appli qui existe en i386, existe en x86_64.
> libc : ------------------310----------2772----------
> C startup : ----------0--------------104------------
> libm : -----------------52------------0---------------
> dynamic linker : ---59-------------172-----------
Sachant que la libc, libm, crt.o, et ld.so en i386 tourne sous x86_64 pour Linux, l'écard peut être de 0 ici.
[^] # Re: 2 Go
Posté par zul (site web personnel) . Évalué à 4.
Pour le remarque sur la glibc, j'ai rien compris. Il y'a bien du code spécifique à l'architecture x86_64 dans la glibc (enfin la dernière fois que j'ai regardé le très estimable code de la glibc). Donc ce n'est pas probablement pas 0. Je n'ai pas du tout compris la remarque sur i386 (la possibilité de tourner en mode x86 est possible, mais quel intérêt d'avoir une 'glibc 32 bits' sur un noyau 64 bits.
Si vous voulez vraiment une feature dans NetBSD, vous pouvez faire un don à NetBSD dans ce but, et un devéloppeur sera en retour payé pour effectuer cette tâche (ou alors encore mieux, juste écrire le patch :D).
[^] # Re: 2 Go
Posté par IsNotGood . Évalué à 1.
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".
Vire toutes les lignes spécifiques x86_86 de la libc, ben tu peux l'utiliser sur x86_64. Es-ce mieux ? J'en doute.
> quel intérêt d'avoir une 'glibc 32 bits' sur un noyau 64 bits.
Je n'utilise pas. Mais par exemple tu peux utiliser le plugin flash (uniquement en i386). Dans la pratique Fedora permet d'installer du i386 et x86_64 en parallèle (même fs (pas de chroot), noyau x86_64). Donc tu installe Firefox i386 (et donc glibc.i386, libX11.i386, etc). Tu as un Firefox i386 et donc peut installer le plugin flash. Tu peux avoir Firefox i386 et x86_64 en parallèle. Pour lancer Firefox.i386, faut utiliser setarch :
Petit exemple :
[admin@one ~]$ uname -m
x86_64
[admin@one ~]$ setarch i386 bash
[admin@one ~]$ uname -m
i686
[admin@one ~]$ exit
/usr/bin/firefox est un scripts qui a entre autre :
MOZ_ARCH=$(uname -m)
case $MOZ_ARCH in
x86_64 | ia64 | s390 )
MOZ_LIB_DIR="/usr/lib64"
SECONDARY_LIB_DIR="/usr/lib"
;;
* )
MOZ_LIB_DIR="/usr/lib"
SECONDARY_LIB_DIR="/usr/lib64"
;;
esac
Depuis peu Firefox sous x86_64 permet d'utiliser des plugins i386 (il faut toujours les dépendances du plugin en i386). Ça se fait avec nspluginwrapper (je n'ai jamais utilisé).
[^] # Re: 2 Go
Posté par vjm . É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 ? ;)
[^] # Re: 2 Go
Posté par IsNotGood . É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 ?
[^] # Re: 2 Go
Posté par kowalsky . Évalué à 6.
tout les sens, créer en portage très facilement.
Après, des problèmes spécifique subsiste, dans le fond.
Mais Linux à plein de chose en retard vis a vis de windows, dois
je arrêter d'utiliser Linux ?
C'est dommage qu'un article si loooong et si beaaaau qui au fond
parle de chose qui ne sont pas spécifique à NetBSD, ramène juste :
NetBSD, ça pue.
Il y a des points négatifs, partout. Mais l'important, c'est les points
forts surtout.
[^] # Re: 2 Go
Posté par IsNotGood . Évalué à 0.
Mais qui a dit ça ?
> NetBSD, ça pue.
Qui a dit ça ?
Linux et NetBSD n'ont pas les même objectifs, n'ont pas la même concèption technique ni concèpte de mener un projet et n'ont pas les mêmes moyens. Une confrontable style "nombre de ligne bidule" n'a aucun sans et n'est pas un raison de l'absence d'un support pour des applis de plus de 2 Go. Le manque de moyen ou motivations sont de bonnes raisons. Et j'ai dit que je ne voyait pas de raison technique pour que NetBSD n'est pas un adressage 64 bits pour les applis. Es-ce grave qu'il manque ça à NetBSD ? Dans la grande majorité des cas, non.
Libre à toi de conclure que "NetBSD, ça pue".
Prend X11 qui est très portable. Il y a pourtant des tonnes de ligne de code spécifique pour le driver bidule et le driver machin. Tu peux diminuer le nombre de ces lignes. Tu vire XV (ça ne t'empêche pas de regarder des vidéos), tu vires le mode overlay pour les cartes TV ou décodeur mpeg, tu vires le mode Xshm, tu vires tout ce qui est accélération, etc. Pour les drivers qui ont un équivalent framebuffer, tu les vires pour utiliser l'API portable framebuffer, etc. Tu vires tout ce qui est DRI/DRM et fait tout en soft, etc.
Au final t'as beaucoup moins de lignes de code spécifiques et ça marche toujours (mais moins vite, il manquera peut-être AIGLX).
Es-ce que la seconde version avec moins de ligne de code spécique est meilleure ? Es-ce que le fait que la seconde version a moins de ligne de code spécifique est une preuve d'une meilleure concèption où de déveleloppeurs plus doués ?
Es-ce que la première version est moins portable ? Ben non, car elle a surtout des optimisations. Si l'optimisation n'est pas portée, et bien on utilise la version "générique".
Donc compter le nombre de ligne de code spécifique sans donner plus d'information est quasi sans intérêt.
[^] # Re: 2 Go
Posté par zul (site web personnel) . Évalué à 5.
Sinon je ne répondrai pas sur le reste. Tu es trop trollifère tout seul.
Linux n'est pas portable, mais il est beaucoup porté. Je te laisse essayé de comprendre la différence.
[^] # Re: 2 Go
Posté par IsNotGood . Évalué à 4.
Pour un truc pas portable, c'est un exploit...
> Je te laisse essayé de comprendre la différence.
Dire qu'un truc qui est porté sur plein d'architectures n'est pas portable, est pour le moins incohérence pour ne pas dire que c'est la preuve d'un esprit bien débile.
Puis ça me fatigue. Faut toujours que les *BSD se compare à Linux. Quand Linux fait un truc, Linux ne dit pas "c'est mieux que *BSD". On dit seulement "c'est mieux que le Linux d'il y a 6 mois, etc".
Mais avec les *BSD, c'est toujours une comparaison avec Linux et pour dire que Linux est de la merde ou fait par des gogos, ou crade, etc.
Très bien *BSD est génial. Mais Linux l'est au moins tout autant. Ça vous fait mal au cul de reconnaitre ça ?
[^] # BSD se compare à Linux
Posté par ZeroHeure . Évalué à 9.
Ah que c'est bon de prendre IsNotGood en flagrant délit un lundi matin !!
C'est le bonheur de la semaine assuré !
Or, de qui est le premier message comparant BSD à Linux ? De qui ? de qui ? Allez mon canard(*) cherche pas, tu t'es coincé dans tes arguties.
NB: ce Puis ça me fatigue est trop beau.
(*) Le canard cancane.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: 2 Go
Posté par tuXico . Évalué à 6.
C'est marrant mais si on suit le thread de la conversation, il me semble fort qu'on obtient une conversation du type
"j'ai un lien génial pour mieux comprendre les OS"
"Ton OS est pourri, j'ai tout lu pour sortir des éléments de critique et pour le dire de manière agressive"
(et troisième post, le Tien) "Comme Linux, comme tout ce qui est libre." ce qui semble être la première comparaison (dans la présente discussion)
C'est ma lecture du thread, sûrement je me trompe... Je laisse les gens relire la discussion dans sa suite logique.
Enfin dans
"Très bien *BSD est génial. Mais Linux l'est au moins tout autant. Ça vous fait mal au cul de reconnaitre ça ?"
on remarque qu'il n'y a aucune comparaison et plein de retenue.
"au moins autant" donc en aucun cas moins ?
Je me fous de savoir si c'est vrai ou pas (le concours de la plus grosse, bof... ce genre de truc doit pouvoir se relativiser, je parie que, dépendant du domaine, on peut faire des conclusions contraires), c'est juste le côté "crier gratuitement au loup" qui me fait réagir...
[^] # Re: 2 Go
Posté par kowalsky . Évalué à 3.
parler d'une pauvre ligne en fin de fin d'article qui fait reference à un probleme...
ça ne donne pas envis de partager tout ça quand même.
Dommage, parce que j'ai plein de joli lien comme celui ci :)
[^] # Re: 2 Go
Posté par patrick_g (site web personnel) . Évalué à 2.
Donc vas-y tu peux poster tes jolis liens ;-)
[^] # Re: 2 Go
Posté par vjm . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.