reno a écrit 3886 commentaires

Autant pour moi!

Ceci dit il n'en reste pas moins que le Zaurus est trop cher pour l'Inde.

Le Simputer coute 250$, le Zaurus coute 500$.

En plus, un portable a quand meme des possibilités différentes qu'un PDA même si c'est un Zaurus..

Bof, tout le monde n'est pas "a cheval" sur l'utilisation des mots d'Anglais en Francais.

En tout cas, ca ne m'a jamais gene dans ce magazine.

TU trouves ca genant, mais n'en fait pas une generalite..

Pour compiler l'OS je n'avais pas de doute sur ce sujet.

Mais c'est plutot pour leurs applications que je me posais la question:
quand on depense des millions pour le materiel ce serait bete de perdre un gros % d'efficacite a cause du compilateur.

Bien sur le compilateur ne fait pas tout: les librairies de calcul optimisee a la main diminue un peu la dependance par rapport au compilateur..

Je me demande quelle compilateur ils utiliseront pour faire tourner leur bebete?
Quelqu'un sait? Je ne l'ai pas vu dans les depeches.

AMHA ce sera celui d'Intel..
Je pense qu'il s'ecoulera pas mal d'eau sous les ponts avant que gcc soit capable de generer du code "performant" pour IA-64.
Deja que pour les 80x86 en performance il se fait battre a plate couture par le compilateur d'Intel alors generer du code pour VLIW..

Ca ne serait pas ce que tu veux?

Tu pourrais eviter d'ecrire Micro$oft au lieu de Microsoft, ce genre de vocabulaire de warlodz m'a toujours fait pietre impression.. Pour ce qui est du sujet: "Linux manque d'applications" Faux est un peu fort: cela depend du sujet: si tu veux faire du montage video sous Linux, tu est plutot limite je crois, pareil pour les applications qui gerent les couleurs en quadrichromie (pour les impressions professionelles). Pour moi la bonne reponse est: cela depend des domaines mais des centaines d'applications tournent sur Linux, etc. Aussi "10 ans plus tard, linux est maintenu pas des millions de personnes à travers le monde" Je mettrai plutot "10 ans plus tard, Linux est utilise par" "maintenu par des millions de personnes" est plutot exagere..

C'est quoi la difference exactement?

Parce que le fait que certains developpeurs preferent les licenses de type BSD au license de type GPL, ce n'est pas franchement nouveau!

Moui mais une petite recherche sur le web donne:
[] Squeak is an open, highly-portable Smalltalk-80 implementation [].

Alors?

Ruby est plus puissant, plus souple, mais moins lisible..

Python est plus lisible, personellement j'aime beaucoup la tabulation "significative": j'ai eu trop souvent a lire des fichiers mal indentes..
Mais trop verbeux: les self partout BEURK!
Guido aurait pu faire une exception et utiliser un $ ou un @ pour distinguer les variables des attributs et les methodes des fonctions..

Sinon en fait je trouve que les deux langages sont assez semblables..

Bin pas tout a fait pour l'embarque, mais embarque == souvent real-time.
Pour le real time soft, le patch kernel preemption a ete integre en 2.5.

Ca devrait diminuer les temps des reponses maximum.

Pour le desktop, c'est aussi interressant plus ALSA.

Mm, si ce n'est pas tres coherent, c'est que je n'ai pas encore pris mon cafe.

Moi personellement entre Ruby et Python, j'hesite encore..

Ne serait-ce que parce qu'il y a beaucoup de code/developpeur qui connaisse Python que Ruby.
Je sais: si c'etait le seul argument alors il faudrait rester en shell/Tcl/Perl qui ont plus d'utilisateur, mais ces languages la je ne les apprecie pas DU TOUT..

Le but de l'article etait de voir si les perf de xfs justifie sa reputation...
et il a des plantage systeme avec xfs!

==> je vais rester en ReiserFS !!

Bin fallait pas s'attendre a des modifications importantes: au depart il etait prevu juste un portage de Qt2 vers Qt3.
Bon ils ont fait quand meme quelque ammeliorations, mais le changement de version majeur ne correspond pas forcement a une mise a jour importante mais a une rupture de la compatibilite binaire..

Puis pour ce qui est du cote "plus beau", a part une vrai,vrai gestion de la transparence (quand ce sera supporte par X), je ne vois pas trop ce qui changera dans le future..

Euh pas tout a fait: si j'ai bien compris le patch lock-break est la combinaison des 2 patchs kernel preemptif + low latency..

Moi je me suis incrit au club, mais je suis plutot déçus: je croyais que cela permettrait d'accéder a des serveur ftp rapide pour télécharger les dernieres distributions, mise-a-jour, etc.

Erreur... :-(

Bah,si ca a pu les aider un peu..

Enfin j'espere que le projet de possibilité d'achat groupé de Sharp Zaurus va aboutir car 500$ c'est un peu cher..

Mouis, mais le probleme c'est que même des démons dont les performances ne sont pas critiques sont écrit en C/C++ d'ou un nombre important de problemes de sécurités..

Pour résoudre ce probléme a mon avis il faudrait 2 choses:
- changer le modele de sécurité (pas seulement root et le reste): les modeles de sécurité "a jeton" cf Eros par exemple (non ce n'est pas cochon) permettent de diminiuer les risques..
- utiliser d'autre language que le C: Ada, Modula, Eiffel serait pas mal: compilé (donc relativement performant), avec un GC (évite les problèmes liés à la mauvaise gestion de la mémoire cf zlib par exemple).

D'apres ce que j'ai lu un programme avec GC utilise environ 2* la mémoire d'un programme ou la mémoire est gérée manuellement, ce qui est moins un problème maintenant que le prix de la mémoire a baissé.

Avec purify quand on appelle une fonction en lui passant une structure avec certains champs non-initialisés, purify signalera "lecture de champ non-initialisés" même quand on n'utilise pas ces champs dans la fonction..

On peut filtrer bien sur ce type d'erreur, mais c'est dommage: s'il y a vraiment une lecture de variable non-initialisée on risque de ne pas la voir..

D'après ce que j'ai lu valgrind n'a pas ce probleme (il en a d'autres: multi-threading)..

> Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient
> plus vers le Hurd et son µnoyau (en plus, je suis
>persuadé que cette histoire de µnoyau va faire peur)

Je ne vois pas pourquoi tu penses que le micronoyau leur ferait peur!
Les éditeurs logiciels se fichent éperdument de savoir si le système d'exploitation utilise un micro-noyeau, un exo-kernel ou un pico-kernel ce qui les interesse c'est de pouvoir vendre leurs produits en quantité suffisante pour faire du bénéfice, un point c'est tout!

Ce qui AMHA n'est pas pres d'arriver pour GNU déja que pour Linux c'est pas (encore) le cas (ça dépend des domaines, bien sur).

> faut arreter de s'obseder avec l'installeur graphique, c pas seulement ca qui constitue l'essentiel sur distro pour neuneu

C'est quand meme une grande partie!
Enfin c'est plutot la partie reconnaissance de materielle aleatoire en fonction de la distro qui est genant, pas tellement le mode graphique, je suis d'accord.

Eric Raymond a aussi dit que selon lui des que les PC seraient en dessous de xx $, ce serait la fin de Microsoft car leur OS serait trop cher.

Ce qui est stupide, car il suffira alors a Microsoft de reduire le cout de son OS!

Non il dit un peu trop de betises en ce moment..

Une petite question, puisque GPLinux est encore une fois une Debian+nouvel instaleur graphique.
et que je crois qu'il y a aussi un autre projet pour créer un nouvel instaleur graphique..

La question: pourquoi les Debianistes (ça se dit ça?) n'ont pas chercher à réuitiliser l'instaleur de Mandrake?
Il est 100% GPL et plutot "bien noté".

Ca m'étonnerait que les liens entre l'instaleur et les RPM soient si forts que ça..

J'ai toujours trouvé dommage que chaque distribution ait son propre instaleur, ca amène des tas d'histoires comme la distribution TotoTM a reconnu mon équipement A mais pas B, la distribution TataTM a reconnu B mais pas A --> BEURK!

ClawHammer c'est la variante moins cher, celle que onsieur tout-le-monde pourra peut-être se payer un jour quand les prix d'introduction auront baissés.
SledgeHammer c'est l'équivalent du Xeon, ça restera cher et prévu pour les serveurs.

Les deux faisant partie de la famille des "Hammer".

Soit dit en passant un gros regrets pour les ClawHammer, ils n'utiliseront que de la DDR simple channel (comme celle utilisée à l'heure actuelle) donc avec en gros la même bande passante que maintenant, mais avec une meilleure latence car une partie du northbridge est intégré au CPU.
Le sledgeHammer utilisera de la DDR double-channel: bande-passante*2.

> Les origines du succes du x86 relevent AMHA plus de la chance que du calcul

C'est clair que si IBM avait choisi Motorola a la place d'Intel, on aurait tous des dérives du 8000 (dommage d'ailleurs, car ils étaient plus facile à programmer en assembleur).

Mais il faut quand même reconnaitre que Intel a bien réussi a exploiter leur avantage, ce qui n'est pas toujours si évident..

Quand a "loin d'être meilleur", ça dépend quels sont les critère de comparaison: les PC sont imbattables au niveau performance en calcul entier/prix dans leurs domaines.

Et quand a refaire le même coup: n'oublie pas qu'ils peuvent sponsoriser le développement de l'Itanium avec les bénéfices fait sur les Pentiums.
Je crois que Intel a déjà dépensé plus d'un milliard de $ pour le développement des Itanium..

Alors comme une bonne partie des conccurents ont déclarés forfaits..

As-tu comparé avec les mêmes fontes?