>GPL c'est libre, ce qui est un cran au-dessus au niveau liberté que OpenSource
Tu chipotes..
[coupé]
>eux par contre aurait le droit d'en faire ce qu'ils veulent, même publier le code source il me semble
Tout a fait, ce qui explique donc pour le GPL n'est pas en général pas payant (ou tres peu) puisqu'il suffit d'un client qui rediffuse l'appli pour que tout le monde puisse la récupérer (légalement) sans payer, donc le GPL payant en théorie ça existe, en pratique pas souvent..
Donc sur le fond tu as raison, c'est quand même assez limite comme argumentation..
Sinon tu parlais de compilation: AVX a des instructions a 3 registres (voire 4 pour la multiplication-addition) contrairement au SSE qui modifiait une des sources, ce qui devrait simplifier pas mal le travail du compilateur|programmeur au niveau de la gestion des registres.
>Je suppose que déjà le système de parallélisation automatique du x86 doit prendre une certaine place sur la puce...
Bof, pas tant que ça maintenant (en pourcentage), c'est pour ça que les x86 ont finis par rattrapper les RISCs..
Je pense que les scientifiques vont être très, très satisfait d'avoir l'AVX, les calculs scientifiques se faisant sur 64bit de précision en général.
>Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable
Pour les VLIW, il reste le probleme du compilateur, a part pour du code tres regulier un VLIW n'est pas exploité au mieux donc ce n'est pas du tout évident que le VLIW soit la bonne voie: le POWER est tout à fait compétitif par rapport a l'Itanium.
Bof, tu sous entends qu'on ne peut pas comparer BeOS et un desktop sous Linux parce qu'ils seraient trop différent?
Je ne suis pas d'accord: Interface graphique évoluée (mis a part les effets 3D récent), protection mémoire, scheduler prémptif, etc BeOS était tres similaire a un desktop Unix (sauf qu'il avait une réactivité bien supérieure)..
Par contre, il y a plusieurs énormes différence entre Windows3.1 et des systèmes d'exploitations moderne (BeOS, Linux et autres):
-scheduler préemptif vs coopératif.
-protection mémoire.
-...
>Il ne faut pas oublier que le kernel Linux utilise du shell pour démarrer dans la plupart des distributions :)
Ce qui donne en final que BeOS sur un Celeron333 mettait moins de 20s pour demarrer (hors BIOS, depuis GRUB jusqu'a l'IHM utilisable), mais une distribution Linux peut mettre facilement plus de 3 fois le temps sur du matériel bien plus puissant.
Ca n'a pas de rapport avec la choucroute juste pour montrer que si un point n'a "pas d'importance" comme le temps de démarrage, au final ça peut devenir du n'importe quoi.
[[DragonflyBSD a une approche différente (sujet du fork originel). Leur proposition est relativement bien documenté sur leur site web.]]
Pour info, le but de DragonflyBSD a changé, au départ c'était effectivement d'utiliser une autre approche pour le SMP, maintenant le centre d'interet sont les clusters..
Donc coté monté en charge en SMP, FreeBSD est beaucoup plus performant que DragonflyBSD..
un point que je trouve perfectible aussi, c'est que dans la liste tu marque 'complexifier l'implémentation des sémaphores' ce qui aurait tendance a faire croire que ce serait nouveau, alors que ce n'est pas le cas.. Je mettrais plutôt 'revenir a l'ancienne implémentation (complexe mais performantes) des sémaphores'.
>D'un point de vue théorique avec un petit modèle, son argumentation est idiote.
Ahem, les modèles étant souvent simpliste, ça me parait très exagéré de qualifier une argumentation "d'idiote" sur cette base.
>La consomation est P=k*fV². Si tu ne baisses que la fréquence, tu augmentes le temps de calculs, l'énergie nécessaire pour le calcul est inchangé.
La preuve dans le cas présent: les CPUs attendent souvent la mémoire, les IOs, et se tourner les pouces plus lentement (a frequence plus basse), ça consomme moins d'énergie que le faire plus rapidement..
>Si il y a eu des bourdes dans Ubuntu 8.04, Firefox 3 n'en fait pas partie.
Pas d'accord..
>Ce qui aurait crétin, aurait été de faire la maj dans le cycle de support.
La nous sommes d'accord, donc pour moi la seule solution 'correcte' aurait été de rester en FF2 pendant tous le cycle de support: c'est ce genre de chose que fait RHE..
Ou alors il faut renommer LTS, car prétendre avoir un support a long terme en utilisant des beta-versions pour diminuer les futurs couts de support, c'est trompeur je trouve.
Bin pour Fedora ça a un sens, après tout c'est une distrib pour que RedHat integre des nouvelles technos (c'est la même logique qui fait installer KDE4), si tu veux du stable utilise une autre distrib..
Mais pour Ubuntu l'integrer dans une version soi-disant 'support a long terme', je suis d'accord c'est du n'importe quoi.
Avec une bourde pareille, Ubuntu LTS n'est pas près de concurrencer RHE!
Bof honetement quand tu regardes les autres laptops, au niveau robustesse, consommation d'energie, ecran lisible au soleil, ils ne font pas trop le poids par rapport a l'OLPC (ok cote puissance CPU c'est le contraire, mais qui s'en soucie?)..
La seule chose que je trouve bizarre dans le projet OLPC c'est que l'approche 'constructioniste', c'est bien beau mais ce n'est pas suffisant et je n'ai pas tellement entendu parler de ce qui se passait pour pouvoir avoir des manuels installable sur les laptops..
J'imagine que ca se fait pays par pays les manuels étant différents, mais on n'en entend pas parler, c'est pourtant un enjeu important je pense..
Il y a plusieurs incohérences dans ses propos:
- il critique les 'fondamentalistes open-source' en disant que c'est à cause d'eux qu'ils n'ont pas pu intégré Flash alors qu'il me semble que la licence d'Adobe empêche de redistribuer Flash.
- d'un coté il critique Sugar en disant qu'il a manqué d'un architecte et de l'autre il dit qu'ils peuvent porter Sugar sur Windows.
Ce n'est pas vraiment incohérent, juste curieux..
- au départ il insistait que le projet OLPC était un projet éducatif le laptop étant juste un support et maintenant le but c'est de mettre un laptop entre les mains de chaque enfants..
Soit ce sont ceux qui rapportent ces propos qui les déforment (ou bien j'ai mal compris), soit j'ai du mal à le suivre..
Ton programme essaie peut-être de faire une résolution de nom (nslookup) ou similaire et attend pendant un certain temps la réponse avant de continuer?
Peut-être qu'en regardant les appels systeme par strace ou en étudiant comment tourne ton programme avec gdb, il y a gprof aussi qui peut-être utile..
> une campagne marketing bien menée (qui commencerait par retirer le "small" du nom, pour ajouter "super" ou "fast"
'small talk' en Anglais --> 'papoter' donc je ne sais pas si le nom est un problème (au moins pour les Anglophones).
Pour le reste, oui la syntaxe est bizarre quand on est habitué a d'autre syntaxe après je crois qu'Objective-C est un Smalltalk a la syntaxe C-like mais ce n'est pas pour autant qu'il a du succès..
Non, je n'ai pas la solution (et d'ailleurs je prefere Ruby a Smalltalk: syntaxe plus agréable).
C'est la differentre entre la compatibilité "théorique" et la compatibilité "bug-compatible"..
C'est clair que la compatibilité 'théorique" fait plus mal aux utilisateurs sur le court-terme, mais on peut esperer que sur le long terme elle soit bénéfique: autrement si on supporte tous les bugs on se retrouve avec des usines à gaz, fragiles.
Je ne gueule pas, je fais juste remarquer que ce qui a changé c'est le systeme audio dans l'OS Linux pas Skype, donc pour moi en étant de bonne foi, on ne peux pas dire que c'est 100% la faute de Skype..
Bon ceci dit, PA a l'air bien partie pour être utiliser dans la majorité des distributions (Fedora, Suse, Mandriva, Ubuntu, impressionant!), donc peut-être que ça va enfin se stabiliser sur cette partie la (enfin jusqu'a ce qu'il faille tout casser pour bien suporter la MAO ou autre :-) ).
[^] # Re: GPL != OpenSource != gratuit
Posté par reno . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 3.
Tu chipotes..
[coupé]
>eux par contre aurait le droit d'en faire ce qu'ils veulent, même publier le code source il me semble
Tout a fait, ce qui explique donc pour le GPL n'est pas en général pas payant (ou tres peu) puisqu'il suffit d'un client qui rediffuse l'appli pour que tout le monde puisse la récupérer (légalement) sans payer, donc le GPL payant en théorie ça existe, en pratique pas souvent..
Donc sur le fond tu as raison, c'est quand même assez limite comme argumentation..
[^] # Re: AVX = SSE++
Posté par reno . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 2.
256bit = 4*64bit: ça va faire plaisir aux scientifiques qui utilisent des flottants sur 64b et non pas 32b comme pour les jeux.
[^] # AVX = SSE++
Posté par reno . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 2.
Sinon tu parlais de compilation: AVX a des instructions a 3 registres (voire 4 pour la multiplication-addition) contrairement au SSE qui modifiait une des sources, ce qui devrait simplifier pas mal le travail du compilateur|programmeur au niveau de la gestion des registres.
[^] # Re: Interface logicielle
Posté par reno . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 2.
http://aseigo.blogspot.com/2008/05/i915-and-gem.html
[^] # Re: Interface logicielle
Posté par reno . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 2.
http://www.phoronix.com/scan.php?page=news_item&px=NjQ3N(...)
[^] # Re: Le CPU, limité dans son évolution
Posté par reno . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 2.
Bof, pas tant que ça maintenant (en pourcentage), c'est pour ça que les x86 ont finis par rattrapper les RISCs..
Je pense que les scientifiques vont être très, très satisfait d'avoir l'AVX, les calculs scientifiques se faisant sur 64bit de précision en général.
>Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable
Pour les VLIW, il reste le probleme du compilateur, a part pour du code tres regulier un VLIW n'est pas exploité au mieux donc ce n'est pas du tout évident que le VLIW soit la bonne voie: le POWER est tout à fait compétitif par rapport a l'Itanium.
[^] # Re: Et les micro noyaux type HURD ?
Posté par reno . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 6.
Je ne suis pas d'accord: Interface graphique évoluée (mis a part les effets 3D récent), protection mémoire, scheduler prémptif, etc BeOS était tres similaire a un desktop Unix (sauf qu'il avait une réactivité bien supérieure)..
Par contre, il y a plusieurs énormes différence entre Windows3.1 et des systèmes d'exploitations moderne (BeOS, Linux et autres):
-scheduler préemptif vs coopératif.
-protection mémoire.
-...
[^] # Re: Et les micro noyaux type HURD ?
Posté par reno . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 2.
Pas uniquement: KDE tout seul peut mettre plus de temps a demarrer que BeOS n'en mettait pour booter au total (kernel boot+IHM).
>je pense que BeOS n'avait pas beaucoup de service activé par défaut.
Ce qui est une bonne conception, ne serait-ce que du point de vue sécurité..
>Coté driver, il devait être limité
Le matériel compatible était limité oui, mais en quoi cela explique un boot plus lent ou plus rapide?
>mais si j'ai bien compris son architecture micro noyau lui permettait de réutiliser les drivers linux. Donc, la phase d'init est la même.
Non, je ne pense pas que BeOS réutilisait les drivers Linux, ne serait-ce que d'un point de vue licence cela ne passerait pas..
[^] # Re: Et les micro noyaux type HURD ?
Posté par reno . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 5.
Ce qui donne en final que BeOS sur un Celeron333 mettait moins de 20s pour demarrer (hors BIOS, depuis GRUB jusqu'a l'IHM utilisable), mais une distribution Linux peut mettre facilement plus de 3 fois le temps sur du matériel bien plus puissant.
Ca n'a pas de rapport avec la choucroute juste pour montrer que si un point n'a "pas d'importance" comme le temps de démarrage, au final ça peut devenir du n'importe quoi.
[^] # Re: et les autres OS ?
Posté par reno . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 3.
Pour info, le but de DragonflyBSD a changé, au départ c'était effectivement d'utiliser une autre approche pour le SMP, maintenant le centre d'interet sont les clusters..
Donc coté monté en charge en SMP, FreeBSD est beaucoup plus performant que DragonflyBSD..
[^] # Re: Sémaphore et mutex
Posté par reno . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 5.
Bof, il dit juste qu'il y a un mouvement pour remplacer les sémaphore par des mutex.
Le reste, c'est toi qui extrapoles je pense..
# Un petit correctif
Posté par reno . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 7.
Non c'est la troisième dans ta liste.
un point que je trouve perfectible aussi, c'est que dans la liste tu marque 'complexifier l'implémentation des sémaphores' ce qui aurait tendance a faire croire que ce serait nouveau, alors que ce n'est pas le cas.. Je mettrais plutôt 'revenir a l'ancienne implémentation (complexe mais performantes) des sémaphores'.
En tout cas, merci pour le poste!
[^] # Re: pas convaincu.
Posté par reno . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 3.
Ahem, les modèles étant souvent simpliste, ça me parait très exagéré de qualifier une argumentation "d'idiote" sur cette base.
>La consomation est P=k*fV². Si tu ne baisses que la fréquence, tu augmentes le temps de calculs, l'énergie nécessaire pour le calcul est inchangé.
La preuve dans le cas présent: les CPUs attendent souvent la mémoire, les IOs, et se tourner les pouces plus lentement (a frequence plus basse), ça consomme moins d'énergie que le faire plus rapidement..
[^] # Re: pas convaincu.
Posté par reno . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 3.
# Un *excellent* article
Posté par reno . En réponse à la dépêche Le projet One Laptop Per Child à la croisée des chemins. Évalué à 4.
http://radian.org/notebook/sic-transit-gloria-laptopi
Il mérite probablement un sujet indépendant tellement il est bon..
[^] # Re: firefow 3.0 beta 5
Posté par reno . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 4.
Pas d'accord..
>Ce qui aurait crétin, aurait été de faire la maj dans le cycle de support.
La nous sommes d'accord, donc pour moi la seule solution 'correcte' aurait été de rester en FF2 pendant tous le cycle de support: c'est ce genre de chose que fait RHE..
Ou alors il faut renommer LTS, car prétendre avoir un support a long terme en utilisant des beta-versions pour diminuer les futurs couts de support, c'est trompeur je trouve.
[^] # Re: firefow 3.0 beta 5
Posté par reno . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
Mais pour Ubuntu l'integrer dans une version soi-disant 'support a long terme', je suis d'accord c'est du n'importe quoi.
Avec une bourde pareille, Ubuntu LTS n'est pas près de concurrencer RHE!
[^] # Re: pour le libre
Posté par reno . En réponse à la dépêche 188 jeux libres dans le commerce !. Évalué à 5.
Dans ces packs la qualité de chaque jeux est n'est pas si elevée que ça..
[^] # Re: Negroponte mouai
Posté par reno . En réponse à la dépêche Le projet One Laptop Per Child à la croisée des chemins. Évalué à 5.
La seule chose que je trouve bizarre dans le projet OLPC c'est que l'approche 'constructioniste', c'est bien beau mais ce n'est pas suffisant et je n'ai pas tellement entendu parler de ce qui se passait pour pouvoir avoir des manuels installable sur les laptops..
J'imagine que ca se fait pays par pays les manuels étant différents, mais on n'en entend pas parler, c'est pourtant un enjeu important je pense..
# Negroponte mouai
Posté par reno . En réponse à la dépêche Le projet One Laptop Per Child à la croisée des chemins. Évalué à 8.
- il critique les 'fondamentalistes open-source' en disant que c'est à cause d'eux qu'ils n'ont pas pu intégré Flash alors qu'il me semble que la licence d'Adobe empêche de redistribuer Flash.
- d'un coté il critique Sugar en disant qu'il a manqué d'un architecte et de l'autre il dit qu'ils peuvent porter Sugar sur Windows.
Ce n'est pas vraiment incohérent, juste curieux..
- au départ il insistait que le projet OLPC était un projet éducatif le laptop étant juste un support et maintenant le but c'est de mettre un laptop entre les mains de chaque enfants..
Soit ce sont ceux qui rapportent ces propos qui les déforment (ou bien j'ai mal compris), soit j'ai du mal à le suivre..
# Probleme réseau?
Posté par reno . En réponse au message Processus lent avec processeur en idle. Évalué à 3.
Peut-être qu'en regardant les appels systeme par strace ou en étudiant comment tourne ton programme avec gdb, il y a gprof aussi qui peut-être utile..
[^] # Re: So what ?
Posté par reno . En réponse à la dépêche O'Reilly France : fermeture définitive. Évalué à 3.
PS: c'est modéré à 10 une remarque pareil???
PPS: dès qu'on fait remarque qu'une modération est 'surprenante' le message est en général modéré très négativement, donc adieu monde cruel!
[^] # Re: En espérant que cela boost l'utilisation de smalltalk
Posté par reno . En réponse à la dépêche Squeak par l'exemple. Évalué à 3.
'small talk' en Anglais --> 'papoter' donc je ne sais pas si le nom est un problème (au moins pour les Anglophones).
Pour le reste, oui la syntaxe est bizarre quand on est habitué a d'autre syntaxe après je crois qu'Objective-C est un Smalltalk a la syntaxe C-like mais ce n'est pas pour autant qu'il a du succès..
Non, je n'ai pas la solution (et d'ailleurs je prefere Ruby a Smalltalk: syntaxe plus agréable).
[^] # Re: À quand les premières versions opérationnelles ?
Posté par reno . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 5.
C'est clair que la compatibilité 'théorique" fait plus mal aux utilisateurs sur le court-terme, mais on peut esperer que sur le long terme elle soit bénéfique: autrement si on supporte tous les bugs on se retrouve avec des usines à gaz, fragiles.
[^] # Re: À quand les premières versions opérationnelles ?
Posté par reno . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 2.
Bon ceci dit, PA a l'air bien partie pour être utiliser dans la majorité des distributions (Fedora, Suse, Mandriva, Ubuntu, impressionant!), donc peut-être que ça va enfin se stabiliser sur cette partie la (enfin jusqu'a ce qu'il faille tout casser pour bien suporter la MAO ou autre :-) ).