reno a écrit 3881 commentaires

Désolé mais ta remarque est stupide: ce n'est pas aux outils de définir l'utilisation qu'on veut en faire!!
Surtout pas avec des limitations antiques: qui calcule encore sur 16bit??

Ca c'est la philosophie Microsoft de l'informatique: le logiciel sait mieux que toi ce que tu veux faire, ce qui est la plupart du temps contre-productif.

Oui, enfin avec des raisonements comme ça, on se retrouve avec le probleme de l'amiante..

Je ne dis pas qu'il faut rester a l'age de pierre, mais toute nouveauté possede un risque, donc faire des études pour vérifier que ces nouveau produits n'ont pas d'effets indésirable me parait une bonne idée.

Le probleme est bien sûr qu'il est impossible de prouver qu'un produit n'a aucun effet indésirable, donc la difficulté est de savoir s'arréter.

Bof un ch'tit troll de temps en temps, c'est marrant ok mais sur une news qui n'a pas d'intérêt..
La sur DragonFly c'est dommage, ne serait-ce qu'a cause de Hammer qui a l'air d'être un FS prometteur:
CRCs partout, snapshot, fsck rapide (si j'ai bien compris), réplication multi-maître..

J'aurais bien aimer une discussion sur le fond.

>Le but de DragonFlyBSD ayant toujours été d'obtenir un système à image unique pour les clusters (un seul OS réparti sur x machines) au lieu d'un cluster traditionnel (x OS pour x machines)

Cette phrase est assez révisionniste, l'annonce initiale (1) parle du SMP, packaging et système de distribution, le mot SSI n'y est même pas présent.

Mais il est vrai que l'accent de DragonFlyBSD a évolué vers les systèmes SSI en "délaissant" le SMP (j'ignore quand car il n'y a pas eu d'annonce: quand les utilisateurs ont été surpris du peu d'évolution du SMP, M. Dillon a expliqué son changement de priorité): les derniers benchmarks que j'ai vu (a prendre avec des pincettes car ils n'incluaient pas cette dernière version de DragonFly) montraient que FreeBSD et Linux étaient loin devant DragonFlyBSD de ce point de vue.

Pour clarifier mon point de vue: je ne critiques absolument pas les orientations de DragonFly: c'est le bébé de M. Dillon, il fait ce qu'il veut!! Mais dire qu'il a toujours été orienté SSI..

1: http://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html

Par pure curiosité, tu avais essayé un kernel Linux 'normal' ou avec deja les options | patch prévu pour les systèmes a faible mémoire?
Cf http://lwn.net/Articles/191955/

Non, une 'adresse' est a prendre au sens large: au niveau TCP et UDP, c'est l'adresse IP + le port.

Netfilter ne permet même pas de changer l'adresse IP sans changer le port (ce qui est très bete car c'est utile parfois!).

Ce qui me parait tres bete..

Si j'ai bien compris Cairo est utilisé par le client donc s'il peut utiliser l'accél matérielle et que le compositeur qui lui est coté X serveur utilise l'accel materielle aussi alors ça veut dire que plusieurs processus utilisent tous les deux l'accel materielle, c'est possible?

>>Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !<<

Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.

>>mais cela n'aurait aucun intéret de tt façon<<
Bin la bande passante utilisée pour envoyer des vecteur ou des commandes OpenGL est tres inferieure a celle utilisée pour envoyer des images donc dans certaines conditions (assez limitée d'accord), cela pourrait être interressant.

>>Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?).<<

Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?

>>Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X.<<
Oui j'avais oublié ça, mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???

>>Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire.<<
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.

>>Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).<<

C'est effectivement le gros probleme..

Pas un non sens complet, juste un non sens pour ton utilisation, mais tu prends décidement ton cas pour une généralité.
(sarcasme) Ils n'ont pas fait le Neo FreeRunner spécifiquement pour toi, quel dommage! (/sarcasme)

Dans un debat sur OSNews sur le même sujet, un lecteur m'a dit que shm était incompatible avec l'accélération matérielle, ce qui est un probleme..

J'avoue avoir un peu de mal a comprendre comment ça marcherait un bureau avec une acceleration materielle si le client fait le rendu de l'image..

J'ai lu que de plus en plus une grosse partie du rendu est faite par le client X (le programme), mais il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local) et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final mais
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
2) j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).

Ce n'est pas clair tout ça pour moi..
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image (ce que fait Cairo il me semble non?), le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?

>>Ce produit est quand même un non sens, comment peut on s'équiper de nos jour d'un téléphone qui n'a même pas le EDGE ???<<

Tu es fana d'EDGE, ok mais ça ne veut pas dire que tout le monde est dans ce cas: j'ai acheté un Smartphone Asus pour ses fonction telephones et GPS: je ne me sers même pas du GPRS alors tu pense qu'EDGE ou la 3G comme j'en m'en moque..
Il n'a pas le WiFi non plus qui par contre doit être sympa pour éviter les fils lors des synchronisation.

Donc, évite de prendre ton cas pour une généralité..
Tu as des sondages qui montre que beaucoup de gens attendrent impatiemment Edge ou la 3G?
Car je ne suis pas le seul: il y a beaucoup de technophile autour de moi, et personne ne s'y interesse (mais ok ça reste un petit échantillon): l'interface des iPhone, la navigation par GPS? Oui, ça m'/nous interresse, mais Edge ou la 3G? Non.

Tu n'as pas du y reflechir beaucoup..

Un utilisateur qui veut du Windows ne sera pas satisfait car Windows en boite coute plus cher que Windows OEM donc il ira voir ailleurs.

Il y a aussi le risque d'avoir des clients mécontents quand les utilisateurs s'apercevront qu'il ne peuvent pas installer le logiciel rigolo qu'on leur a envoyé: un nombre non négligeable de gens ne comprennent pas vraiment la notion d'OS..

>Le seul device mainstream multitouch que je connaisse, c'est le iphone.

Les touchpad de certains ordinateurs portables (Macbook Air) sont multitouch: l'idée étant de scroller avec 2 doigts par exemple, j'ignore par contre si les utilisateurs se servent vraiment de cette fonctionnalité.

>Le pare-feu intégré de windows ? un simple gadget pour faire joli. Dés qu'on veut personnaliser le filtrage, on déchante !

Ah? Chez moi, il marche sans problème (et personnalisé, après j'imagine que ça dépend de la conf) et me convient donc ne soit pas si affirmatif..

Un avantage du parefeu Windows, c'est que les docs des FAI, applications nécessitant l'ouverture de port montrent le chemin a faire en utilisant comme exemple le parefeu Windows en général donc c'est pratique pour les néophytes.

Pas tous non! Gratuit ne veut pas dire librement redistribuable..

C'est souvent le cas d'accord, mais pas toujours.

Je suis d'accord avec toi pour ne pas considerer les logiciels propriétaires comme immoraux.

Cependant utiliser des logiciels propriétaire n'est pas un acte isolé et neutre, loin de la, cf l'analyse de Brendan Scott (lien dessous) qui montre très bien que les logiciels propriétaires forment a terme un 'monopole naturel' et bien sûr l'heureux bénéficiaire de ce monopole en profite abusivement la plupart du temps (exemple type: Microsoft, IBM avant).

Maintenant exprimer tout ça en un seul mot est impossible..

http://brendanscott.wordpress.com/2008/06/20/the-invisible-c(...)

>>Je t'assure que la fusion du PC et du téléphone est une évidence même pour des non informaticiens<<

Bah, la fusion d'équipement c'est quelque-chose qui a lieu assez rarement en pratique: la fusion TV/Ordinateurs par exemple, très souvent évoquée est un échec..

La seule fusion réussie que je connais est celle du PDA et du téléphone, pour faire les 'smartphones'.

Un téléphone pour être utilisable en tant que PC a besoin d'une base d'accueil (écran, clavier), et si on ajoutais un disque dur dans cette base pour sauvegarder les données (en cas de perte du téléphone), et si on rajoutais un CPU parce que le téléphone rame un peu et un GPU dans la base d'accueil pour pouvoir jouer?
Tiens maintenant la "base d'accueil" a tout le matériel d'un PC!

C'est le cas bien sûr, j'appelle ça une attaque 'a la Sun' (utiliser une license GPL incompatible pour éviter que le code 'libéré' serve a alimenter Linux) qui a pour but de fragmenter la communauté 'libre'.

Dans le cas de Symbian vs Android, les licenses incompatibles empechent que du code Symbian aille dans Android, mais il reste la possibilité de d'ajouter une API commune qui ferait que des developpeurs d'application puissent cibler a la fois Symbian et Android.

Mais cela a peu de chance de se produire: la 'mise en commun' de ressources n'est pas vraiment le point fort du libre (cf rpm vs pkg, les gestionnaire de sons, etc).

Une fusion du telephone et du PC?
Tres peu probable (mais pas impossible) mais même dans cas, il est possible que ce soit le x86 qui tue ARM dans ces secteurs plutôt que le contraire..

Pas l'Atom qui est trop gourmand en énergie, mais son successeur Intel devrait augmenter la lutte contre ARM, apres je ne fais pas de pronostic.

Ca n'a rien a voir avec le noyau..
Les 'goto locaux' pour remplacer les exceptions dans une fonction C sont un style tout a fais acceptable a mon avis..

Mais ils ne sont utilisés que dans des cas bien spécifiques, et beaucoup moins que les appels de fonctions..

Uhm, il y a quand même une grande différence entre maintenant et il y a 10 ans c'est que la course a la fréquence est morte a cause de la puissance consommée.

Pour ce qui est de la gravure, ce qui me fait le plus peur ce n'est pas la technique mais l'état d'AMD: ça fait des années qu'ils sont en déficit et leur offre actuelle est en deçà de celle d'Intel, donc Intel risque de relâcher la pression..

Peut-être que les autres sont capables d'utiliser les numéros de versions correctement..

Genre si la feuille de calcul est version N alors autoriser fonction buggée sinon erreur "cette fonction est dépréciée a cause du bug machin" utiliser la fonction Untel a la place ou utiliser le mode de compatibilité Toto.

Avec ajout de nouvelles fonctionnalités *uniquement* hors du mode de compatibilité, le code de compatibilité étant du code "mort" il ne coute pas grand chose a maintenir et le nouveau code ne contenant plus les anciennes erreurs: un utilisateur nouveau ne se fera pas avoir par les bugs historiques du logiciel.

Ca ne me parait pas bien compliqué quand même, surtoût quand on a des milliards de bénéfice comme Microsoft..

Le threading et FF, c'est une longue histoire de désamour, ce n'est pas prêt d'être corrigé ton bug..

1) Je suis bien conscient que mes besoins ne sont pas les même pour tous, mais dire qu'on ne peut pas utiliser Word/Excel sur Wine de manière professionnelle, comme tu l'as fait est une généralisation hâtive.

2) Les correctifs Microsoft, c'est souvent assez rigolo: quand est-ce que Microsoft corrige Excel pour la fonction de calcul des années bissextile?

Ah non, il ne le feront pas pour rester compatible, la compatibilité ascendante avec des bugs, bof..