je ne connais malheureusement pas le terme exact.
C'est la complexité du changement de contexte entre deux processus/threads (il n'y a pas de distinction sous Linux).
Plus précisement, je pense qu'il s'agit de la complexité de l'algorithme qui élit le processus auquel serait attribué la prochaine tranche de temps CPU exprimée en fonction du nombre de processus qui la réclament (donc qui sont dans l'état "Running").
dans le noyau 2.6 ,permettrait de gérer des nombres astronomiques de threads les doigts dans le nez
Bah, justement à l'heure actuelle la RedHat est configurée par défaut avec un maximum de 256 threads/processus.
Bien sûr, il est facile de recompiler soi-même sa Posix Thread librairie avec une limite plus élévée, mais si RedHat à fixé cette valeur par défaut, c'est pour faire prendre conscience au dévéloppeur que pour Linux, 256 threads c'est déjà beaucoup et qu'au delà le système risque de "souffrir".
Par comparaison, quand je lance quelques applis sur mon Duron 900 avec XP (Warcraft 3, Winamp, Opera, et Outlook) le gestionnaire des tâches me donne déja presque 250 threads, au boulot sur ma station de développeur ou j'utilise beaucoup d'applis gourmandes, j'ai déja dépassé les 500.
Imagine, que tu ai acheté un serveur en Rack, et que pour accélérer ton appli serveur, tu souhaites lancer 1000 threads en parallèle. Pour NT c'est une charge de travail raisonnable (surtout pour un serveur), pour Linux c'est délirant, ton système va être poussé dans ses derniers retranchements.
Donc soit tu bride ton appli, soit tu change d'OS (c'est pour éviter celà que REDHAT dépense de l'argent la-dessus).
Le coup du nombre de threads astronomique, c'est justement pour essayer de casser cette image "Linux = limité en nombre de threads".
Je pense qu'en parlant innovation, on devrait parler des implémentations plus rapides qu'ailleurs des protocoles. IPv6 par exemple, a eu sa première implémentation dans Linux. Ça a été le premier OS a l'implémenter (tiens, j'ai pas d'autres exemples :) ).
Certes, parler d'innovation là dedans, c'est encore limite étant donné que les devs n'ont rien inventé. Comme pour LVM, ou LVS par exemple.
Je pense que parler d'innovation est relativement un leurre, plutôt parler de la qualité de ce qu'on trouve dans le noyau Linux par rapport à ce qu'on peut trouver à prix d'or sur le marché: LVM, Netfilter en sont de très bon exemple.
Y'a du gros fud, bien sûr, mais il n'a pas tout à fait tort, il ne dit pas que des choses ridicules.
Du point de vue de Microsoft, ils intègrent tout, et quand on lit ça:
"Supposons que vous souhaitiez ajouter la reconnaissance de l'écriture manuscrite à l'ensemble du système d'exploitation. "
Et oui, comment on ferait sous Linux? Je ne dis pas que je suis d'accord avec eux, mais on va bien finir par arriver à un truc où tout sera portable (le tablet PC, ça a vraiment pas l'air mal).
Je vois bien une bibliothèque pour Gnome et une pour KDE qui fera ça, avec incompatibilité entre elles. L'avantage de Windows, c'es de fournir à toutes les applications des services (composants COM, reconnaissance de l'écriture par exemple).
enierement d'accord avec toi, ce client la est fabuleux :)
mais j'attend encore thunderbird, car je suis aussi sous windows et peut etre y aura-t-il possibilité de partager les mails entre les deux, en ayant qu'une version de chaque mail pour les deux client ;)
Moi je pense que c'est une bonne idée.
Sincerement, considérant les enjeux du débat qui va avoir lieu, et les implications des décisions qui pourraient y etre prises, et peut etre tout simplement pour leur dire qu'il ne sont certainement pas ceux qui font progresser cette science qu'est l'informatique, mais simplement des voleurs de pommes, des profiteurs, des prétentieux et des décus de la vie.
Je rajouterais que l'informatique n'en est qu'a ses balbutiements, qu'elle n'a besoin ni d'être encartelée, ni vampirisée.
Si l'on considére les faits marquants de deux facettes de cette activitée, son business, ou plutot le profit technologique facile, nous a fait une jolie bulle spéculative, discréditant tout de meme pas mal ceux qui doivent sacrifier enormément d'eux même, pour prouver que le libre est au moins autant une réalitée viable, et combien plus belle, que celle qu'ils veulent nous imposer.
Non a la nouvelle aristocratie megacorporatiste !
Non mais !
j'ai rien contre les corses.
Mais je n'y eux rien au fait que la peau de leurs mandarines colle.
La couche 3 du modèle OSI doit être détachable facilement de la couche 2.
Dans les mandarines corses, ce n'est pas le cas.
Elles ne sont donc pas conformes au modèle OSI, ce qui tu l'admets est un frein certain à leur consommation courante, hein ?
j'aurais aimé trouvé le fameux "Inside the Windows NT File System", car je me refuse d'acheter chez Microsoft Press
Tu craint l'ex-communication par RMS ?
Effectivement, j'aurais aimé avoir plus d'explications sur ce fait.
D'après les docs de MS, NTFS est journalisé depuis Windows 2000.
Windows 2000 est relativement ancien et probablement antérieur à la journalisation dans Linux, car sauf erreur de ma part ni EXT3FS, ni XFS, ni JFS n'était stables à l'époque de sa sortie.
Pour ce qui est de ReiserFS, d'après les doc, il semble qu'il ne soit pas journalisé mais utilise un système du type BSD-SoftUpdate.
A moins que l'auteur posséde des éléments concrets pour appuyer son propos (et de prouver que les docs officielles de MS mentent), c'est juste un troll de laisser entendre que "NT est en retard sur Linux vis à vis de la journalisation" comme le fait la news alors qu'en fait c'est l'inverse qui est (ou a été pendant longtemps, en gros jusqu'au noyau 2.4) la vérité.
Que NTFS ait beaucoup d'inconvénients, je suis d'accord.
Lesquels ?
- assuré un libre accès a tout contenu (avoir la description du format du contenu). Il est annormale pour être dans la loi d'être obligé d'acheter un programme pour lire un DVD que l'on vient d'acheter (au US uniquement actuellement).
Oui
- interdire ce qui nuit à la communication (ex DMCA).
Oui
- interdire les licences abusives qui favorisent les monopôles. style mon produit ne peut marché que sous mon OS.
En fait sur un PC qui a largement moins de 4 Go de mémoire (toute machine actuelle) et qui pourrait donc se contenter d'un adressage 32 bits, le 64 bits représentent une perte de performance de quelques pourcents (et non un gain comme certains semblent le penser) car les pointeurs sont plus long donc le cache est moins bien utilisé.
Mais il est sûr que sur le long terme, avec le baisse de prix des barettes de RAM, le 64-bits c'est l'avenir.
En fait sur un PC qui a largement moins de 4 Go de mémoire (toute machine actuelle) et qui pourrait donc se contenter d'un adressage 32 bits, le 64 bits représentent une perte de performance de quelques pourcents (et non un gain comme certains semblent le penser) car les pointeurs sont plus long donc le cache est moins bien utilisé.
Mais il est sûr que sur le long terme, avec le baisse de prix des barettes de RAM, le 64-bits c'est l'avenir.
Je sais que tout le monde a l'air de trouver ces articles nuls parce qu'ils sont posté en rafales et qu'en plus ils sont techniques donc ils faut un peu réfléchir pour les commenter.
Néanmoins on y trouve des informations intéressantes :
"Last month's column looked at bare context switch times by using the best primitives on both Windows and Linux. According to those results, context switch time under Windows takes only half as long as under Linux. I concluded that the algorithm for choosing a thread to run is well optimized in Windows."
En gros, linux gère plus mal les threads que Windows NT, d'une part Linux a du mal a supporter plus de 100-150 threads sur un serveur alors que sur ma machine NT de développeur j'atteint couramment 500 threads. D'autres part (et c'est la raison pour laquelle on est limité en nombre de threads) il y a un mauvais support des threads au niveau noyau, qui donne des perfs plus mauvaise que sous NT, et surtout ses perfs se dégradent beaucoup quand le nombre de threads est élévé (ce qui n'est pas le cas sous NT)
C'est la raison pour laquelle RedHat bosse actuellement sur une nouvelle Posix Thread Librairy, quand cette librairie sera stable et que le noyau 2.6 sera sortie (car la librairie a des dépendance au niveau noyau), le support des threads sous Linux pourra rivaliser (voir dépasser) celui de NT.
Je crois que pour RedHat, le mauvais support des threads est un des principaux freins à l'adoption de Linux au niveau serveur, d'ou le fait qu'il investisse beaucoup pour l'améliorer (c'est comme le manque de système de fichiers journalisés autrefois).
1) Cela dit, pour revenir à la question de départ, étant donné la manière dont est fait MacOSX, on peut considérer sans grand tord qu'il s'agit d'un UNIX. Il ne faut pas oublier que schématiquement, il s'agit d'un serveur BSD4.4 au dessus d'un µnoyau Mach... et jusqu'à preuve du contraire, BSD, c'est plutôt Unix...
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . En réponse à la dépêche Plein d'articles sur DeveloperWorks. Évalué à 1.
C'est la complexité du changement de contexte entre deux processus/threads (il n'y a pas de distinction sous Linux).
Plus précisement, je pense qu'il s'agit de la complexité de l'algorithme qui élit le processus auquel serait attribué la prochaine tranche de temps CPU exprimée en fonction du nombre de processus qui la réclament (donc qui sont dans l'état "Running").
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . En réponse à la dépêche Plein d'articles sur DeveloperWorks. Évalué à 1.
Bah, justement à l'heure actuelle la RedHat est configurée par défaut avec un maximum de 256 threads/processus.
Bien sûr, il est facile de recompiler soi-même sa Posix Thread librairie avec une limite plus élévée, mais si RedHat à fixé cette valeur par défaut, c'est pour faire prendre conscience au dévéloppeur que pour Linux, 256 threads c'est déjà beaucoup et qu'au delà le système risque de "souffrir".
Par comparaison, quand je lance quelques applis sur mon Duron 900 avec XP (Warcraft 3, Winamp, Opera, et Outlook) le gestionnaire des tâches me donne déja presque 250 threads, au boulot sur ma station de développeur ou j'utilise beaucoup d'applis gourmandes, j'ai déja dépassé les 500.
Imagine, que tu ai acheté un serveur en Rack, et que pour accélérer ton appli serveur, tu souhaites lancer 1000 threads en parallèle. Pour NT c'est une charge de travail raisonnable (surtout pour un serveur), pour Linux c'est délirant, ton système va être poussé dans ses derniers retranchements.
Donc soit tu bride ton appli, soit tu change d'OS (c'est pour éviter celà que REDHAT dépense de l'argent la-dessus).
Le coup du nombre de threads astronomique, c'est justement pour essayer de casser cette image "Linux = limité en nombre de threads".
[^] # Re: il y a qu'en même du gros fud...
Posté par Anonyme . En réponse à la dépêche "Linux est un concurrent sérieux". Évalué à 1.
Certes, parler d'innovation là dedans, c'est encore limite étant donné que les devs n'ont rien inventé. Comme pour LVM, ou LVS par exemple.
Je pense que parler d'innovation est relativement un leurre, plutôt parler de la qualité de ce qu'on trouve dans le noyau Linux par rapport à ce qu'on peut trouver à prix d'or sur le marché: LVM, Netfilter en sont de très bon exemple.
[^] # Re: il y a qu'en même du gros fud...
Posté par Anonyme . En réponse à la dépêche "Linux est un concurrent sérieux". Évalué à 1.
Du point de vue de Microsoft, ils intègrent tout, et quand on lit ça:
"Supposons que vous souhaitiez ajouter la reconnaissance de l'écriture manuscrite à l'ensemble du système d'exploitation. "
Et oui, comment on ferait sous Linux? Je ne dis pas que je suis d'accord avec eux, mais on va bien finir par arriver à un truc où tout sera portable (le tablet PC, ça a vraiment pas l'air mal).
Je vois bien une bibliothèque pour Gnome et une pour KDE qui fera ça, avec incompatibilité entre elles. L'avantage de Windows, c'es de fournir à toutes les applications des services (composants COM, reconnaissance de l'écriture par exemple).
# Re: Synergy
Posté par Anonyme . En réponse à la dépêche Synergy. Évalué à 1.
je viens juste de l'installer, et c'est terrible.
j'essayerai demain avec 4 PCs ... :)
par contre, je viens justement de m'acheter un clavier pour une de mes machines ... dommage, plus besoin now :)
[^] # Re: Et sous vim ...
Posté par Anonyme . En réponse au message [Éditeur/Emacs] Lister un répertoire. Évalué à 1.
[^] # Re: Travailler c'est trop dur
Posté par Anonyme . En réponse au journal Travailler c'est trop dur. Évalué à 1.
Euh, elle était facile, oui. D'autant plus que tu m'as bien aidé.
[^] # Re: Quel est l'interet ?
Posté par Anonyme . En réponse à la dépêche Ipod et Linux.... Évalué à 1.
très bien, c'est un peu beaucoup trop fort... il est super lent et a un support matériel très limité.
[^] # Re: Nouveau site LinuxFr
Posté par Anonyme . En réponse à la dépêche Nouveau site LinuxFr. Évalué à 1.
# Re: Pouêêt
Posté par Anonyme . En réponse au journal Pouêêt. Évalué à 1.
[^] # Re: Vous voulez du rapide et du léger ...
Posté par Anonyme . En réponse à la dépêche Un autre "Thunderbird" ?. Évalué à 1.
mais j'attend encore thunderbird, car je suis aussi sous windows et peut etre y aura-t-il possibilité de partager les mails entre les deux, en ayant qu'une version de chaque mail pour les deux client ;)
(je n'ai pas essayé avec mozilla ;)
[^] # Re: Nouvelle offensive sur les brevets logiciels
Posté par Anonyme . En réponse à la dépêche Nouvelle offensive sur les brevets logiciels. Évalué à 1.
Sincerement, considérant les enjeux du débat qui va avoir lieu, et les implications des décisions qui pourraient y etre prises, et peut etre tout simplement pour leur dire qu'il ne sont certainement pas ceux qui font progresser cette science qu'est l'informatique, mais simplement des voleurs de pommes, des profiteurs, des prétentieux et des décus de la vie.
Je rajouterais que l'informatique n'en est qu'a ses balbutiements, qu'elle n'a besoin ni d'être encartelée, ni vampirisée.
Si l'on considére les faits marquants de deux facettes de cette activitée, son business, ou plutot le profit technologique facile, nous a fait une jolie bulle spéculative, discréditant tout de meme pas mal ceux qui doivent sacrifier enormément d'eux même, pour prouver que le libre est au moins autant une réalitée viable, et combien plus belle, que celle qu'ils veulent nous imposer.
Non a la nouvelle aristocratie megacorporatiste !
Non mais !
[^] # Re: Les pizzas c'est Mal®
Posté par Anonyme . En réponse au journal Il est l'heure de manger. Évalué à 1.
Hum...
[^] # Re: Les pizzas c'est Mal®
Posté par Anonyme . En réponse au journal Il est l'heure de manger. Évalué à 1.
Mais je n'y eux rien au fait que la peau de leurs mandarines colle.
La couche 3 du modèle OSI doit être détachable facilement de la couche 2.
Dans les mandarines corses, ce n'est pas le cas.
Elles ne sont donc pas conformes au modèle OSI, ce qui tu l'admets est un frein certain à leur consommation courante, hein ?
[^] # Re: Les pizzas c'est Mal®
Posté par Anonyme . En réponse au journal Il est l'heure de manger. Évalué à 1.
Elles ont la peau qui colle c'est l'horreur.
Et l'horreur à table c'est l'horreur.
[^] # Re: Download ?
Posté par Anonyme . En réponse à la dépêche Un autre "Thunderbird" ?. Évalué à 1.
tant pis, on attendra :))
*pressé*
[^] # Re: Quelques remarques en vrac
Posté par Anonyme . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
Tu craint l'ex-communication par RMS ?
[^] # Re: Quelques remarques en vrac
Posté par Anonyme . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
D'après les docs de MS, NTFS est journalisé depuis Windows 2000.
Windows 2000 est relativement ancien et probablement antérieur à la journalisation dans Linux, car sauf erreur de ma part ni EXT3FS, ni XFS, ni JFS n'était stables à l'époque de sa sortie.
Pour ce qui est de ReiserFS, d'après les doc, il semble qu'il ne soit pas journalisé mais utilise un système du type BSD-SoftUpdate.
A moins que l'auteur posséde des éléments concrets pour appuyer son propos (et de prouver que les docs officielles de MS mentent), c'est juste un troll de laisser entendre que "NT est en retard sur Linux vis à vis de la journalisation" comme le fait la news alors qu'en fait c'est l'inverse qui est (ou a été pendant longtemps, en gros jusqu'au noyau 2.4) la vérité.
Que NTFS ait beaucoup d'inconvénients, je suis d'accord.
Lesquels ?
[^] # Re: Nouvelle offensive sur les brevets logiciels
Posté par Anonyme . En réponse à la dépêche Nouvelle offensive sur les brevets logiciels. Évalué à 1.
Oui
- interdire ce qui nuit à la communication (ex DMCA).
Oui
- interdire les licences abusives qui favorisent les monopôles. style mon produit ne peut marché que sous mon OS.
Oui
# Re: Il est l'heure de manger
Posté par Anonyme . En réponse au journal Il est l'heure de manger. Évalué à 1.
(welcome back Nets)
[^] # Re: Le POWER4 est-il prêt pour le desktop ?
Posté par Anonyme . En réponse à la dépêche Le POWER4 est-il prêt pour le desktop ?. Évalué à 1.
Mais il est sûr que sur le long terme, avec le baisse de prix des barettes de RAM, le 64-bits c'est l'avenir.
[^] # Re: Le POWER4 est-il prêt pour le desktop ?
Posté par Anonyme . En réponse à la dépêche Le POWER4 est-il prêt pour le desktop ?. Évalué à 1.
Mais il est sûr que sur le long terme, avec le baisse de prix des barettes de RAM, le 64-bits c'est l'avenir.
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . En réponse à la dépêche Plein d'articles sur DeveloperWorks. Évalué à 1.
Néanmoins on y trouve des informations intéressantes :
"Last month's column looked at bare context switch times by using the best primitives on both Windows and Linux. According to those results, context switch time under Windows takes only half as long as under Linux. I concluded that the algorithm for choosing a thread to run is well optimized in Windows."
En gros, linux gère plus mal les threads que Windows NT, d'une part Linux a du mal a supporter plus de 100-150 threads sur un serveur alors que sur ma machine NT de développeur j'atteint couramment 500 threads. D'autres part (et c'est la raison pour laquelle on est limité en nombre de threads) il y a un mauvais support des threads au niveau noyau, qui donne des perfs plus mauvaise que sous NT, et surtout ses perfs se dégradent beaucoup quand le nombre de threads est élévé (ce qui n'est pas le cas sous NT)
C'est la raison pour laquelle RedHat bosse actuellement sur une nouvelle Posix Thread Librairy, quand cette librairie sera stable et que le noyau 2.6 sera sortie (car la librairie a des dépendance au niveau noyau), le support des threads sous Linux pourra rivaliser (voir dépasser) celui de NT.
Je crois que pour RedHat, le mauvais support des threads est un des principaux freins à l'adoption de Linux au niveau serveur, d'ou le fait qu'il investisse beaucoup pour l'améliorer (c'est comme le manque de système de fichiers journalisés autrefois).
[^] # Re: Quelques remarques en vrac
Posté par Anonyme . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
[^] # Re: Sortie d'OpenWall Linux 1.0
Posté par Anonyme . En réponse à la dépêche Sortie d'OpenWall Linux 1.0. Évalué à 1.
Disclaimer: Non, ce message n'a pas pour but de répondre à un troll