Ils ont les codec et la lecture de DVD installé de base, ce qui n'est pas si fréquent (ce qui est un peu frustrant pour les codec d'ailleurs car il s'agit d'un probleme principalement américain qui "déteint" ailleurs).
Je t'ai plusser avant de changer d'avis:
1) ça n'a couté que quelques octets et c'était interressant de savoir qu'il y a un magazine sur Linux en langue arabe (même si je ne parles pas Arabe).
2)les réactions montrent que les gens ne sont pas hostiles a parler des magazines en langues étrangères et il y en a de très bon: a une époque Dr Dobbs était inégalé et si je ne parle pas Allemand les quelques articles que j'ai pu voir en Anglais de c't m'ont paru très bon.
Puisqu'on parles des magasines étrangers, il y a quelques années, j'avais été surpris de voir qu'a Palo Alto (en plein coeur de la Silicon Valley) il n'y avait pas tant que ça de magasines qui parle de Linux..
Note que pour le 'highlight', ce n'est pas tres etonnant que l'anti-aliasing foire, c'est probablement une operation de changement de couleurs trop rapide.
Pour ce qui est du rendu, ce n'est pas forcement de la faute de Qt, ça depend probablement aussi de la façon dont on le configure.
0)Non, mais les analogies comme souvent ne servent pas a grand chose.
1)Je n'ai jamais dit que le tableur était l'outil idéal pour des fichiers avec 100 000 lignes, mais je pense quand même qu'il devrait le supporter: ce n'est pas a l'outil de définir le mode d'emploi, point.
2)Le tableur n'est pas le plus performant pour les gros fichier, mais c'est du temps d'*ordinateur* dont on parle, apprendre a utiliser un autre outil c'est un investissement en temps *personnel*: c'est a chacun de voir ou il veut mettre la barrière.
3)Je suis tout a fait d'accord que le tableur remplace trop souvent une base de donnée, mais le choix ne devrait pas être imposé a cause d'une restriction artificielle.
4)Tiens, puisque tu parles d'emacs: sait-tu qu'une des grandes avancées des outils GNU des le depart était d'utiliser ... des entiers 32 bits!
Et a l'époque c'était loin d'être évident (mémoire pas si grande que ça) mais RMS a pris le parti d'utiliser des entiers 32bit, ce qui était une *bonne* idée.
Alors une appli qui utilise des entiers 16bits en 2008 (hors cas tres particulier), je rigole.
5)La notion d'une tache, un outil sous Unix, ça fait longtemps, (depuis les IHM en fait) qu'elle est appliquée de manière très, très "fluctuante".
De GNU tar qui fait la compression; a Perl qui remplace sed+awk, a Mozilla qui fait mail+navigateur, a Konqueror qui fait tout, Thunderbird qui fait email et newsgroup, etc
une tache = un outil faut le dire vite!!
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..
>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..
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/
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 ?!).<<
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.
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.
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..
>>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.
[^] # Re: Mouai
Posté par reno . En réponse à la dépêche Test de Pardus 2008. Évalué à 2.
[^] # Re: magazine Linux arabe
Posté par reno . En réponse à la dépêche Revue de presse - août 2008. Évalué à 1.
1) ça n'a couté que quelques octets et c'était interressant de savoir qu'il y a un magazine sur Linux en langue arabe (même si je ne parles pas Arabe).
2)les réactions montrent que les gens ne sont pas hostiles a parler des magazines en langues étrangères et il y en a de très bon: a une époque Dr Dobbs était inégalé et si je ne parle pas Allemand les quelques articles que j'ai pu voir en Anglais de c't m'ont paru très bon.
Puisqu'on parles des magasines étrangers, il y a quelques années, j'avais été surpris de voir qu'a Palo Alto (en plein coeur de la Silicon Valley) il n'y avait pas tant que ça de magasines qui parle de Linux..
[^] # Re: Moche
Posté par reno . En réponse à la dépêche KDE 4.1 : Don't Look Back. Évalué à 3.
Pour ce qui est du rendu, ce n'est pas forcement de la faute de Qt, ça depend probablement aussi de la façon dont on le configure.
[^] # Re: N'est stupide que la stupidité :)
Posté par reno . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 2.
[^] # Re: N'est stupide que la stupidité :)
Posté par reno . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 5.
1)Je n'ai jamais dit que le tableur était l'outil idéal pour des fichiers avec 100 000 lignes, mais je pense quand même qu'il devrait le supporter: ce n'est pas a l'outil de définir le mode d'emploi, point.
2)Le tableur n'est pas le plus performant pour les gros fichier, mais c'est du temps d'*ordinateur* dont on parle, apprendre a utiliser un autre outil c'est un investissement en temps *personnel*: c'est a chacun de voir ou il veut mettre la barrière.
3)Je suis tout a fait d'accord que le tableur remplace trop souvent une base de donnée, mais le choix ne devrait pas être imposé a cause d'une restriction artificielle.
4)Tiens, puisque tu parles d'emacs: sait-tu qu'une des grandes avancées des outils GNU des le depart était d'utiliser ... des entiers 32 bits!
Et a l'époque c'était loin d'être évident (mémoire pas si grande que ça) mais RMS a pris le parti d'utiliser des entiers 32bit, ce qui était une *bonne* idée.
Alors une appli qui utilise des entiers 16bits en 2008 (hors cas tres particulier), je rigole.
5)La notion d'une tache, un outil sous Unix, ça fait longtemps, (depuis les IHM en fait) qu'elle est appliquée de manière très, très "fluctuante".
De GNU tar qui fait la compression; a Perl qui remplace sed+awk, a Mozilla qui fait mail+navigateur, a Konqueror qui fait tout, Thunderbird qui fait email et newsgroup, etc
une tache = un outil faut le dire vite!!
[^] # Re: Capacité du parser CSV
Posté par reno . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 8.
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.
[^] # Re: jusqu'à la prochaine fois
Posté par reno . En réponse à la dépêche Atheros libère un pilote pour ses composants 802.11n. Évalué à 10.
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.
[^] # Re: Ah, les beaux trolls !
Posté par reno . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 6.
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.
# Revisionnisme?
Posté par reno . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 7.
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
[^] # Re: Mémoire
Posté par reno . En réponse à la dépêche LinuxConsole 1.0.2008 CD. Évalué à 4.
Cf http://lwn.net/Articles/191955/
[^] # Re: Mini correction
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 2.6.26. Évalué à 3.
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!).
[^] # Re: Bon trève de conneries !
Posté par reno . En réponse à la dépêche Mouvement des semences libres. Évalué à 9.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par reno . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 2.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par reno . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 3.
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..
[^] # Re: Pas d'Edge ou de 3G ????
Posté par reno . En réponse à la dépêche Le téléphone nouveau est arrivé : Neo FreeRunner. Évalué à 1.
(sarcasme) Ils n'ont pas fait le Neo FreeRunner spécifiquement pour toi, quel dommage! (/sarcasme)
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par reno . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 2.
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?
[^] # Re: Pas d'Edge ou de 3G ????
Posté par reno . En réponse à la dépêche Le téléphone nouveau est arrivé : Neo FreeRunner. Évalué à 3.
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.
[^] # Re: Pourquoi pas linux pour tous?
Posté par reno . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 5.
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..
[^] # Re: X et pointeurs multiples
Posté par reno . En réponse à la dépêche Sortie de la developers' release d'Ubuntu MID Edition. Évalué à 2.
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é.
[^] # Re: En attendant la news...
Posté par reno . En réponse au journal Darty condamné pour vente subordonée. Évalué à 2.
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.
[^] # Re: "logiciel privateur"
Posté par reno . En réponse à la dépêche Ce que pensent Stallman, Torvalds, Brown et Zemlin de Microsoft. Évalué à 4.
C'est souvent le cas d'accord, mais pas toujours.
[^] # Re: "logiciel privateur"
Posté par reno . En réponse à la dépêche Ce que pensent Stallman, Torvalds, Brown et Zemlin de Microsoft. Évalué à 2.
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(...)
[^] # Re: La mort du PC?
Posté par reno . En réponse à la dépêche Nokia s'offre Symbian pour le rendre libre. Évalué à 3.
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!
[^] # Re: Attention
Posté par reno . En réponse à la dépêche Nokia s'offre Symbian pour le rendre libre. Évalué à 3.
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).
[^] # Re: La mort du PC?
Posté par reno . En réponse à la dépêche Nokia s'offre Symbian pour le rendre libre. Évalué à 2.
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.