Ca c'est unique parce que tu n'as pas confiance dans la compilation realisee par les distribs.
Si le bug est dans le source, il est aussi dans le binaire.
Et perso, je n'ai pas le temps, ni les competence de faire un audite des sources, ni d'etre abonne aux mailing-list de tout les projects pour connaitre et evaluer des derniers bugs trouve, ni ...
Je prefere faire confiance a un distributeur qui est certainement meilleur que moi dans ce domaine...
S'il code pas comme de porc (ce qui ne doit pas etre le cas) un butineur n'a rien a voir avec le 'noyau' d'un systeme.
Tu croix qui ont des sources IE different pour win NT, win 2000, win XP.
Tu croix que lorsqu'il livre un correctif pour IE il livre egalemenent le 'noyau' (ou equivalent).
Tu croix que lorsqu'il corrige un bug (sisi ca arrive...) dans leur pile TCP/IP il sont oblige de refournir IE.
etc...
etc...
Bref, si IE est imbrique dans leur systeme au point qu'il soit inseparable, c'est qu'il l'ont fait expres et pas pour optimisation ou confort d'utilisation...
Je copie ici le passage qui me semble le plus "savoureu" :
... par opposé aux
serveurs où Linux gagne sérieusement du terrain
contre Microsoft. Je vais peut-être me faire écharper
mais j'attends encore le procès en abus de position
dominante que les parties prenantes du monde Linux
ont le devoir d'entreprendre en partageant le risque
et le butin avec des avocats prêts à financer
l'opération. Microsoft a usé de tactiques illicites, et
simples à démonter, voire mes chroniques sur les
licences OEM de Windows et du lanceur d'OS.
Microsoft a réussi à empêcher les OEM d'offrir des
systèmes bi-OS permettant à Linux et ses
applications de se faire une place au soleil tout en
rassurant les utilisateurs ...
Dans une de ces chroniques, Gassee se demandait quant les representants du free software (Redhat, Suse, Mandrake, etc... FSF?) feraient un proces un microsoft.
Mais pour lui, proces il y aura (GNU/Linux contre Microsoft).
J'arrive pas à comprendre les gus qui utilisent de tel truc. J'ai posé la question mais je suis sure que 70 % des gens ne savent pas ce que celà veut dire.
Enfin, faut bien frimer...
Une abréviation anglaise sur un forum français ...
PS : Merci pour l'info. Je sais que AFAIK n'apporte rien et peut être ignoré. Comme mon post :-) ...
Un bout de /etc/modules.conf pour faire tourné un Vibra 16 avec alsa V0.5
alias char-major-116 snd
alias snd-card-0 snd-card-ens1371
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
options snd snd_device_gid=0 snd_device_uid=0 snd_device_mode=0666 snd_cards_limit=1 snd_major=116
options snd-card-ens1371 snd_index=0 snd_id=CARD_0
Alsa c'est 99 % de module. Le gain en taille memoire est ridicule en virant le support de son de Linux.
Du momemt que les modules ne sont pas charges. un 'alias sound off' dans /etc/modules.conf permet de se garantir du zele de kmod.
Je comprend pas bien ou le noyau 2.4 est plus lent. Tu as des benchs ?
Mon experience perso et subjective :
2.0 un peu plus rapide que 1.2.
2.2 nettement plus rapide (gestion memoire surtout) que le 2.0.
2.4 pas vraiment plus rapide que le 2.2.
Par contre :
2.0 consonne autant de memoire que 1.2.
2.2 consonne plus de memoire que 2.2 (voir beaucoup plus mais la gestion memoire est bien meilleur).
2.4 consonne un peu plus de memoire que 2.2.
Bref, plus on monte en version, plus il faut de memoire.
Mais que de progres ! durant le 2.2, la barierre de 2G par fichier est saute.
Le 2.4 permet sans douleur d'augmenter le nombre de process maxi.
Le 2.4 augment la reponse des serveurs type apache. Si tu a 100 process apache a l'ecoute et qu'une connection se fait sur le port 80, tu n'as pas 100 process qui sont reveille.
Le 2.4 integre une version raid plus rapide que le 2.2.
Le 2.4 (ou pour le 2.6 car il y a un petit probleme de compatibilite avec certaines applis) ameliore la vitesse des fork().
Le 2.4 donne acces a la journalisation avec des systemes de fichier adapte a certaine appli (news).
Le 2.4 a nettement ameliorer l'utilisation des disques IDE.
Le 2.4 augment la taille memoire disponible.
etc...
Bref, il est plus adapte a des serveur de prod (meme s'il est peut-etre plus lent).
Alors bien sur le 2.4 doit etre plus lent dans certains domaines. Mais c'est le prix du progres...
Tu remarqueras que je ne parle jamais de desktop :-) ...
Je crois que le gros chantier pour la 2.6 est le changement de l'organisation des peripheriques.
Le but est de pourvoir endormir sa machine (comme sous windows).
Sauvegarde du contexte sur disque dur et lors de la reinitialisation, reconfiguration des peripheriques (dans le bonne ordre :-) ).
> Je pense vraiment qu'ils n'ont pas d'interet a virer OSS du noyau.
OSS va etre virer pour la 2.5.5 (peut-etre un poil plus).
Alsa a des modules de compatibilite OSS. J'utilise Alsa avec les applis OSS sans probleme...
Par exemple ma distrib RH utile OSS. J'ai virer OSS (OSS et ALSA ne peuvent cohabiter) et installe Alsa.
=> pas de probleme...
De plus les branches de developpement (2.5) ne sont pas la pour faire dans la dentelle...
Bizarre, j'ai la meme carte que j'utilise avec alsa (chip ens1371 je crois).
> carte son de pauvre lamer (qui fait pas de full duplex)
la Vibra16 fait tres bien du full duplex avec Alsa.
Bizarre, Bizarre...
> Alsa, c'est tres tres chiant, et ca n'apporte aucun interet véritable.
Si tu n'as pas teste, tu ne peux pas juger objectivement...
Ce soir, pour te donner un coup de main je poste mon /etc/modules.conf (suis au boulot actuellement). J'utilise actuellement Alsa V0.5 (la branche stable).
Je ne pense pas aux problemes de stabilite :
1- la fiabilite eleve c'est pour les serveurs et les serveurs n'utilisent pas de carte son.
2- Alsa ne m'a jamais pose de probleme.
Je probleme est au niveau application. Beaucoup d'applications sont codes pour OSS voir les deux a la foi (OSS/ALSA).
Il est claire qu'au niveau appli il y aura du taff pour tout basculer sous ALSA (donc des problemes de fiabilite temporaire).
Neanmoins, s'est positif pour la fiabilite a long terme. Il n'y a que ALSA a fiabiliser...
Enfin, Alsa est bien meilleur qu'OSS (qui est moins free software qu'alsa) full-duplex/modulaire/support de plusieurs carte/modules de compatibilite avec l'API OSS.
l'integration d'ALSA a Linux est du bonsens et etait programme et attendu depuis longtemps.
Désolé mais je connais déjà un peu gtk+ et gtkmm (et glade est assez sexy). De plus pour ce type d'appli le C++ n'est pas (du moins par rapport à mon habitude du C) un gros avantage.
> Il semble juste que tu ais un tout petit peu "enjolivé" l'histoire d'Unix :-).
Faut dire que j'ai un peu tendance à diaboliser Windows. Il faut que je m'équilibre.
> Argh. L'insulte suprême.
Je suis trop fort...
> Bon, puisque tu m'as expédié ton "CV" avec ton passé d'Unixien, voici les miennes :
çà me revient vaguement. On a eu, il y a xx mois, un thread sur gtkmm/QT à la coloration un peu moins "sauvage".
> l'azerty pour coder c'est vraiment trop pénible :-).
Ben moi je suis trop habituer a l'azerty et passer à un qwerty est une véritable souffrance durant la première semaine.
> Oh là là, je suis vexé.
Puisque tu es un contributeur au free software, tu as tout mon respect (enfin une partie).
Surtout que n'en suis pas un (un peu evangéliste par moment. Limite tendance casse couille d'après mes collèges). Si j'ai de temps ce sera dotgnu (une partie seulement :-) ) ou un front-end pour rsync.
> malgré une conception pourrie (bus, mémoire, proc, IDE,...)
Au boulot (une mission de deux mois), j'ai un UltraSparc 5 (pas le dernier mais dans les 25 000 F je croix). j'admin a ouvert la boite pour changer le lecteur de CDROM. Et il y avait dedans :
- disque IDE
- chipset graphic ATI rage 128 (chez j'ai la meme chose et c'est 10 fois plus rapide ?!).
- bus PCI (du moins pour les cartes d'extension)
- ram type PC d'il y a 2 ans (EDO).
La comparaison avec Windows etait uniquement pour indiquer que je me méfis des bruits portés par les journaux ou les constructeurs. Par exemple SUN peut te dire que Linux n'a pas une aussi bonne gestion SMP que les grosses bécanes SUN a grand coup de graphique mais il n'y a pratiquement jamais de benckmark indépendant pour confirmer.
En avril-juin 2001 je bossais chez hp (grenoble). J'utilisait leurs stations de travail et j'ai été supris de la lenteur de leur système (chez moi j'ai un pII 233 qui est un peu moins rapide, subjectivement, que leur haut gamme de station de travail).
J'en ai fait par et on m'a dit que c'est normal car HP-UX c'est fait pour les serveurs et pas pour surfer sur le web.
J'étais chez hp pour faire un intranet assez lourd (beaucoup de traitement php). C'était lent et pour prouver que ce n'était pas lié à mes choix logiciels, j'ai fait des benck du site web que je developpait. les becanes pour tester étaient une vieille station de travail (la mienne), un serveur de 3 ans, une station de travail haut de gamme récente (autour de 50 000 F, moins de 10 000 ) et un PC sous Linux évidament.
Le PC était un celeron à 500 Mhz et 32 Mo.
Le plus rapide était le celeron qui était 50% plus rapide que la station haut de gamme. Je fesait peut-être des traitements qui utilisait les points faibles des PA-risc (les expressions régulière sont horriblement lentes avec un PA-risc ?!?).
Mes "collèques" était très très surpris car il était constament dans les bruits qui disait qu'un station de travail c'est beaucoup mieux qu'un PC, que les technologies des PC sont totalement dépacées et patati et patata...
J'ai perfois l'impression qu'il y a un peu de çà avec le support de thread ou SMP de Linux. Malheureusement, je n'ai rien de consistant pour confirmer ...
Enfin, l'expérience dans les gros serveurs de SUN, etc... ne peut pas être ignorée et elle est actuellement supérieur à Linux.
> ... sauf pour ce qui est de l'implémentation des threads, et du support SMP, domaines où Linux ne fait pas le poids actuellement.
Certains journaux "professionnel" dise que Linux est beaucoup plus mauvais que Windows pour les threads et que c'est un gros problème pour la montée en charge.
C'est n'importe quoi.
Les autres Unix ont PEUT-ETRE un avantage mais çà doit pas allez bien loin... Sauf pour des confs enorme (type plus de 16 CPUs). Mais dans ces cas il n'y a jamais de benckmark de publié.
J'ai lu un bench qui comparait Linux sous Sparc (bi-cpu) et Solaris sous Sparc. Linux etait moins performant de 3 à 5 %. Bref, rien. Et je pense que c'est (dans ce cas) plus un problème de compilateur que de noyau.
[^] # Re: Tex/Latex & outil de formatage
Posté par matiasf . En réponse à la dépêche Open Office: pourquoi les utilisateurs Linux en ont-ils besoin?. Évalué à 6.
[^] # Bof...
Posté par matiasf . En réponse à la dépêche Tinfoil Hat Linux: la distribution pour paranoïaques. Évalué à 0.
Si le bug est dans le source, il est aussi dans le binaire.
Et perso, je n'ai pas le temps, ni les competence de faire un audite des sources, ni d'etre abonne aux mailing-list de tout les projects pour connaitre et evaluer des derniers bugs trouve, ni ...
Je prefere faire confiance a un distributeur qui est certainement meilleur que moi dans ce domaine...
[^] # Aucun interet en soi...
Posté par matiasf . En réponse à la dépêche Microsoft devra dévoiler le code source de Windows. Évalué à 10.
S'il code pas comme de porc (ce qui ne doit pas etre le cas) un butineur n'a rien a voir avec le 'noyau' d'un systeme.
Tu croix qui ont des sources IE different pour win NT, win 2000, win XP.
Tu croix que lorsqu'il livre un correctif pour IE il livre egalemenent le 'noyau' (ou equivalent).
Tu croix que lorsqu'il corrige un bug (sisi ca arrive...) dans leur pile TCP/IP il sont oblige de refournir IE.
etc...
etc...
Bref, si IE est imbrique dans leur systeme au point qu'il soit inseparable, c'est qu'il l'ont fait expres et pas pour optimisation ou confort d'utilisation...
[^] # RE: Gassée
Posté par matiasf . En réponse à la dépêche Be porte plainte contre Microsoft. Évalué à 5.
http://www.liberation.fr/chroniques/gassee/ga20010831.html(...)
Je copie ici le passage qui me semble le plus "savoureu" :
... par opposé aux
serveurs où Linux gagne sérieusement du terrain
contre Microsoft. Je vais peut-être me faire écharper
mais j'attends encore le procès en abus de position
dominante que les parties prenantes du monde Linux
ont le devoir d'entreprendre en partageant le risque
et le butin avec des avocats prêts à financer
l'opération. Microsoft a usé de tactiques illicites, et
simples à démonter, voire mes chroniques sur les
licences OEM de Windows et du lanceur d'OS.
Microsoft a réussi à empêcher les OEM d'offrir des
systèmes bi-OS permettant à Linux et ses
applications de se faire une place au soleil tout en
rassurant les utilisateurs ...
©Libération
[^] # RE: Gassée
Posté par matiasf . En réponse à la dépêche Be porte plainte contre Microsoft. Évalué à 1.
Mais pour lui, proces il y aura (GNU/Linux contre Microsoft).
[^] # Re: Incomplet
Posté par matiasf . En réponse à la dépêche "langages de scripts sous linux" de C. Blaess. Évalué à -4.
Mais non !
PHP c'est compile comme Perl et ca arrive pas a la cheville de sed...
[^] # Génial
Posté par matiasf . En réponse à la dépêche Linus passe un peu la main. Évalué à 7.
Enfin, faut bien frimer...
Une abréviation anglaise sur un forum français ...
PS : Merci pour l'info. Je sais que AFAIK n'apporte rien et peut être ignoré. Comme mon post :-) ...
[^] # Re: Hmm..
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 1.
alias char-major-116 snd
alias snd-card-0 snd-card-ens1371
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
options snd snd_device_gid=0 snd_device_uid=0 snd_device_mode=0666 snd_cards_limit=1 snd_major=116
options snd-card-ens1371 snd_index=0 snd_id=CARD_0
Bonne chance.
[^] # Re: Petite machine petite machine, faut relativiser :-)
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 3.
Du momemt que les modules ne sont pas charges. un 'alias sound off' dans /etc/modules.conf permet de se garantir du zele de kmod.
[^] # Re: hum
Posté par matiasf . En réponse à la dépêche Linus passe un peu la main. Évalué à 1.
ca va pousser le developpement d'une solution free...
Question con :
que veut dire AFAIK que j'ai vu 10 millions de foi...
[^] # bug tracking system de chez Debian
Posté par matiasf . En réponse à la dépêche Linus passe un peu la main. Évalué à 1.
[^] # Re: Explication ...
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 0.
> Donnez-moi un Cakewalk, un soundforge et des plugins de traitement du signal, le tout sous linux...
Jetes un coup d'oeil sur http://gstreamer.net(...) . Il y a peut-etre ton bonheur...
[^] # Re: C'est une avancée certaine !
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 10.
Mon experience perso et subjective :
2.0 un peu plus rapide que 1.2.
2.2 nettement plus rapide (gestion memoire surtout) que le 2.0.
2.4 pas vraiment plus rapide que le 2.2.
Par contre :
2.0 consonne autant de memoire que 1.2.
2.2 consonne plus de memoire que 2.2 (voir beaucoup plus mais la gestion memoire est bien meilleur).
2.4 consonne un peu plus de memoire que 2.2.
Bref, plus on monte en version, plus il faut de memoire.
Mais que de progres ! durant le 2.2, la barierre de 2G par fichier est saute.
Le 2.4 permet sans douleur d'augmenter le nombre de process maxi.
Le 2.4 augment la reponse des serveurs type apache. Si tu a 100 process apache a l'ecoute et qu'une connection se fait sur le port 80, tu n'as pas 100 process qui sont reveille.
Le 2.4 integre une version raid plus rapide que le 2.2.
Le 2.4 (ou pour le 2.6 car il y a un petit probleme de compatibilite avec certaines applis) ameliore la vitesse des fork().
Le 2.4 donne acces a la journalisation avec des systemes de fichier adapte a certaine appli (news).
Le 2.4 a nettement ameliorer l'utilisation des disques IDE.
Le 2.4 augment la taille memoire disponible.
etc...
Bref, il est plus adapte a des serveur de prod (meme s'il est peut-etre plus lent).
Alors bien sur le 2.4 doit etre plus lent dans certains domaines. Mais c'est le prix du progres...
Tu remarqueras que je ne parle jamais de desktop :-) ...
[^] # Explication ...
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à -4.
OSS est utilise par Linux et d'autre unix proprietaire.
OSS est moins libre qu'Alsa (Alsa est GPL)
A moyen terme, t'auras pas le chois => Alsa uniquement.
[^] # RE: Le 2.6.x va être Super
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 10.
Le but est de pourvoir endormir sa machine (comme sous windows).
Sauvegarde du contexte sur disque dur et lors de la reinitialisation, reconfiguration des peripheriques (dans le bonne ordre :-) ).
[^] # RE: Hmm...
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 0.
OSS va etre virer pour la 2.5.5 (peut-etre un poil plus).
Alsa a des modules de compatibilite OSS. J'utilise Alsa avec les applis OSS sans probleme...
Par exemple ma distrib RH utile OSS. J'ai virer OSS (OSS et ALSA ne peuvent cohabiter) et installe Alsa.
=> pas de probleme...
De plus les branches de developpement (2.5) ne sont pas la pour faire dans la dentelle...
[^] # Troll
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à -3.
[^] # Re: Hmm..
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 10.
Bizarre, j'ai la meme carte que j'utilise avec alsa (chip ens1371 je crois).
> carte son de pauvre lamer (qui fait pas de full duplex)
la Vibra16 fait tres bien du full duplex avec Alsa.
Bizarre, Bizarre...
> Alsa, c'est tres tres chiant, et ca n'apporte aucun interet véritable.
Si tu n'as pas teste, tu ne peux pas juger objectivement...
Ce soir, pour te donner un coup de main je poste mon /etc/modules.conf (suis au boulot actuellement). J'utilise actuellement Alsa V0.5 (la branche stable).
[^] # Re: Le 2.6.x va être une pur tuerie !!!
Posté par matiasf . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 10.
Je ne pense pas aux problemes de stabilite :
1- la fiabilite eleve c'est pour les serveurs et les serveurs n'utilisent pas de carte son.
2- Alsa ne m'a jamais pose de probleme.
Je probleme est au niveau application. Beaucoup d'applications sont codes pour OSS voir les deux a la foi (OSS/ALSA).
Il est claire qu'au niveau appli il y aura du taff pour tout basculer sous ALSA (donc des problemes de fiabilite temporaire).
Neanmoins, s'est positif pour la fiabilite a long terme. Il n'y a que ALSA a fiabiliser...
Enfin, Alsa est bien meilleur qu'OSS (qui est moins free software qu'alsa) full-duplex/modulaire/support de plusieurs carte/modules de compatibilite avec l'API OSS.
l'integration d'ALSA a Linux est du bonsens et etait programme et attendu depuis longtemps.
[^] # RE: Attention au changement de règles
Posté par matiasf . En réponse à la dépêche Firewall toujours en fonction sur un Linux arrêté!. Évalué à 10.
Pas tres interessant. Mais rigolo a connaitre.
[^] # Re: thread dotgnu
Posté par matiasf . En réponse à la dépêche Miguel de Icaza s'explique sur .NET. Évalué à 1.
Désolé mais je connais déjà un peu gtk+ et gtkmm (et glade est assez sexy). De plus pour ce type d'appli le C++ n'est pas (du moins par rapport à mon habitude du C) un gros avantage.
[^] # Re: thread dotgnu
Posté par matiasf . En réponse à la dépêche Miguel de Icaza s'explique sur .NET. Évalué à 0.
Faut dire que j'ai un peu tendance à diaboliser Windows. Il faut que je m'équilibre.
> Argh. L'insulte suprême.
Je suis trop fort...
> Bon, puisque tu m'as expédié ton "CV" avec ton passé d'Unixien, voici les miennes :
çà me revient vaguement. On a eu, il y a xx mois, un thread sur gtkmm/QT à la coloration un peu moins "sauvage".
> l'azerty pour coder c'est vraiment trop pénible :-).
Ben moi je suis trop habituer a l'azerty et passer à un qwerty est une véritable souffrance durant la première semaine.
> Oh là là, je suis vexé.
Puisque tu es un contributeur au free software, tu as tout mon respect (enfin une partie).
Surtout que n'en suis pas un (un peu evangéliste par moment. Limite tendance casse couille d'après mes collèges). Si j'ai de temps ce sera dotgnu (une partie seulement :-) ) ou un front-end pour rsync.
[^] # Re: Serveurs bas de gamme !!!
Posté par matiasf . En réponse à la dépêche Sun joue la carte linux. Évalué à 9.
Au boulot (une mission de deux mois), j'ai un UltraSparc 5 (pas le dernier mais dans les 25 000 F je croix). j'admin a ouvert la boite pour changer le lecteur de CDROM. Et il y avait dedans :
- disque IDE
- chipset graphic ATI rage 128 (chez j'ai la meme chose et c'est 10 fois plus rapide ?!).
- bus PCI (du moins pour les cartes d'extension)
- ram type PC d'il y a 2 ans (EDO).
Bref, un PC avec un cpu lent...
[^] # Re: Serveurs bas de gamme !!!
Posté par matiasf . En réponse à la dépêche Sun joue la carte linux. Évalué à 10.
La comparaison avec Windows etait uniquement pour indiquer que je me méfis des bruits portés par les journaux ou les constructeurs. Par exemple SUN peut te dire que Linux n'a pas une aussi bonne gestion SMP que les grosses bécanes SUN a grand coup de graphique mais il n'y a pratiquement jamais de benckmark indépendant pour confirmer.
En avril-juin 2001 je bossais chez hp (grenoble). J'utilisait leurs stations de travail et j'ai été supris de la lenteur de leur système (chez moi j'ai un pII 233 qui est un peu moins rapide, subjectivement, que leur haut gamme de station de travail).
J'en ai fait par et on m'a dit que c'est normal car HP-UX c'est fait pour les serveurs et pas pour surfer sur le web.
J'étais chez hp pour faire un intranet assez lourd (beaucoup de traitement php). C'était lent et pour prouver que ce n'était pas lié à mes choix logiciels, j'ai fait des benck du site web que je developpait. les becanes pour tester étaient une vieille station de travail (la mienne), un serveur de 3 ans, une station de travail haut de gamme récente (autour de 50 000 F, moins de 10 000 ) et un PC sous Linux évidament.
Le PC était un celeron à 500 Mhz et 32 Mo.
Le plus rapide était le celeron qui était 50% plus rapide que la station haut de gamme. Je fesait peut-être des traitements qui utilisait les points faibles des PA-risc (les expressions régulière sont horriblement lentes avec un PA-risc ?!?).
Mes "collèques" était très très surpris car il était constament dans les bruits qui disait qu'un station de travail c'est beaucoup mieux qu'un PC, que les technologies des PC sont totalement dépacées et patati et patata...
J'ai perfois l'impression qu'il y a un peu de çà avec le support de thread ou SMP de Linux. Malheureusement, je n'ai rien de consistant pour confirmer ...
Enfin, l'expérience dans les gros serveurs de SUN, etc... ne peut pas être ignorée et elle est actuellement supérieur à Linux.
[^] # Re: Serveurs bas de gamme !!!
Posté par matiasf . En réponse à la dépêche Sun joue la carte linux. Évalué à 7.
Certains journaux "professionnel" dise que Linux est beaucoup plus mauvais que Windows pour les threads et que c'est un gros problème pour la montée en charge.
C'est n'importe quoi.
Les autres Unix ont PEUT-ETRE un avantage mais çà doit pas allez bien loin... Sauf pour des confs enorme (type plus de 16 CPUs). Mais dans ces cas il n'y a jamais de benckmark de publié.
J'ai lu un bench qui comparait Linux sous Sparc (bi-cpu) et Solaris sous Sparc. Linux etait moins performant de 3 à 5 %. Bref, rien. Et je pense que c'est (dans ce cas) plus un problème de compilateur que de noyau.