C'est vrai qu'on entend beaucoup plus parler de gens sous Mint ou sous PCLinuxOS (j'avais jamais entendu parlé de cette distro...) que de gens sous Arch !
Et surtout où est le rapport avec udev ? J'utilise (et c'est surement le cas de plein de monde) udev et je monte mes partitions soit classiquement avec /dev/sdXY, soit par label avec /dev/disk/by-label/SWAP par exemple (lisible, pratique, etc. tant qu'il n'y a pas de conflits).
Un peu comme en C et tout un tas d'autres langages.
Tu penses que c'est un bon point pour OCaml d'être comparé au C ? :-)
Tu aurais du garder ton programme :)
C'était dans des contextes différents en fait. Et c'est pas que la sortie d'ocamldep n'est pas bien triée, c'est plutôt qu'il ne fait pas ce dont j'avais besoin ici.
En gros, le cas d'utilisation, c'est que j'ai une liste de .ml dans un ordre quelconque, et je dois les compiler en .o pour les linker avec du C++ derrière. ocamldep est incapable de me sortir les trucs dans le bon format (il ne sait générer que des foo.cmo: foo.cmi et foo.cmx: foo.cmo, ou alors la forme « brute » qui est « a: b c ». Dans tous les cas, avoir besoin d'ocamldep pour linker son binaire c'est honteux : pourquoi est-ce que le linker d'OCaml ne sait pas faire ce travail tout seul ?
C'est ça, si tu veux profiter des multiples processeurs il faut forker ton processus.
Et induire une plus grosse utilisation de mémoire et des IPC. Cool.
De ces inconvénients je retiens surtout la petite dimension de la communauté d'utilisateur, qui implique un nombre assez restreint de contributions de bibliothèques.
Il y a aussi un autre problème que je vais illustrer par deux exemples. Je cherche une lib OCaml qui binde OpenGL. J'ai le choix entre LablGL, glcaml, glmlite et un autre dont j'ai plus le nom en tête. Pareil pour SDL : sdlcaml et ocamlsdl. Sans compter que la plupart des ces libs sont buggées et non maintenues (il y a des bouts de l'interface SDLmixer d'OCamlSDL qui segfaultaient systématiquement à cause d'une typo dans le code C il y a environ un an, c'est peut-être encore le cas, j'en sais rien).
Quand je parlais de release mineure je voulais parler de 3.11.1, qui n'a pas été release sous Windows non plus.
En vrai le support d'OCaml sous Windows a commencé à mourir avec l'introduction de Dynlink en mode natif, qui a obligé à tout compiler avec flexdll sous Windows pour avoir un comportement du dynamic linker identique à celui traditionnel sous UNIX. C'était genre vers 3.09 ou 3.10 il me semble. Avant tout passait assez correctement avec mingw et msys, maintenant il faut hacker... Tout ça pour une feature dont personne ne se sert au final.
C'est bête, OCaml ça a été ma première introduction à la programmation fonctionnelle, mais ça a vraiment vieilli vite dans ma tête depuis que je me suis mis un peu à Haskell. Je sais pas ce que je ferais sans typeclasses de nos jours :)
En même temps c'était voué à l'échec depuis un moment. J'ai l'impression qu'il y a de moins en moins de gens de l'INRIA qui bossent sur OCaml, et historiquement le projet a toujours été très fermé à toutes les contributions externes. C'était clair qu'à un moment ça allait casser.
Sans client Jabber ? Tu ne peux pas, c'est une évidence… Pas de bras, pas de chocolat.
Je n'ai pas dit être fermé à l'installation d'un client.
Avec Jabber en passant par une client natif, genre Empathy, c'est une adresse Jabber à rentrer, typiquement guest@guest.example.com
D'accord, ça répond en fait à ma question sur « comment » (le coup de guest@ etc.). Il faut chercher un serveur qui supporte ça, ou tous les serveurs le supportent ?
Merci pour les autres informations, notamment les clients webs :)
La lib standard est totalement vide : pas de gestion de l'unicode, pas de strings non mutables, pas de petits outils par défaut comme @@ et @$ que tout le monde redéfinit dans son prelude.ml, une interface système qui est en gros un copier-coller de celle du C (donc très bas niveau par rapport à ce qu'il y a dans les stdlibs de Python/Perl). Je sais bien que Batteries, Core ou Extlib (oh tiens, 3 réimplémentations de la lib standard d'OCaml, ça c'est homogène !) règlent ces problèmes, mais ça n'est pas une excuse ;
Pas de gestionaire de packages par défaut. Même findlib n'est pas inclut dans la distribution OCaml de base, il faut l'installer à part. Je ne parle même pas de GODI qui est à peu près le seul truc utilisable mais lui non plus pas standard. C'est con, ça + lib standard moisie ;
Rien de plus chiant que de compiler de l'OCaml. Les modules doivent être linkés dans leur ordre de dépendance, ce qui fait que le travail de résolution des dépendances entre les modules doit être fait par le build system. ocamldep simplifie bien la tâche, sauf quand tu as quelque chose d'un peu plus compliqué qu'un projet d'exemple bidon. Au final j'ai eu plusieurs fois à écrire un programme qui fait un tri topologique sur l'output d'ocamldep pour remettre les modules dans le bon ordre pour les filer à ocamlopt ;
Tu pourrais répondre à ma critique d'au dessus « ocamlbuild ». Où est la doc ? Elle n'existe simplement pas, sauf si tu considères trois exemples de code sur un wiki comme une doc. Combine l'absence de documentation à l'utilisation d'extensions syntaxiques qui ont été crées uniquement pour ce projet, et tu as comme résultat un truc illisible et incompréhensible pendant 2 ou 3h ;
« Bon, apparemment personne s'est plaint qu'on a pas release la dernière version mineure d'OCaml sous Windows, du coup on va pas non plus release la version 3.12.0 sous Windows ». En gros, si tu veux avoir un truc portable, tu es coincé sous 3.11. Et si tu veux avoir un truc portable avec des Big_int, tu es donc coincé dans la mocheté à moins d'utiliser des extensions Camlp4 ;
En parlant de camlp4, c'est devenu quoi camlp5 ? Pourquoi la nouvelle version de camlp4 s'appelle camlp4, et l'ancienne version camlp5 ? C'est pas totalement illogique, par hasard ?
Pas de support des threads natifs si j'ai bien compris : tu es coincé avec un programe monothreaded car le GC n'est pas concurrent. C'est triste, de nos jours où presque toutes les machines récentes ont 4 à 8 coeurs ;
De nos jours Haskell est bien plus soutenu par tout le monde qu'OCaml, a une communauté importante, plusieurs entreprises derrière qui soutiennent (en tout cas, plus qu'OCaml qui a Jane Street, l'INRIA, et... j'en vois pas d'autres), un bon support des plateformes majeures (Win/Linux/Mac), des mises à jour assez grandes régulièrement (cf. le nouveau backend LLVM), etc.
Et même si tu veux rester proche de l'OCaml, F# marche bien sous Mono. Mais j'irais pas jusqu'à dire que c'est une bonne idée :)
Pas forcément, il est courant de proposer des comptes anonymes restreints pour les besoins d'un salon.
Je ne le savais pas. Imaginons moi, M. λ, veut me connecter sur un salon de discussion Jabber sans avoir de compte ni de client Jabber, je fais comment concrétement ? Avec IRC la barrière à l'entrée est minimale : en passant par un client desktop (genre X-Chat) c'est une adresse de serveur à rentrer + un join, et en passant par un client web genre Mibbit c'est juste cliquer sur un lien hypertexte. Je ne pense vraiment pas que ça soit si simple avec Jabber (malheureusement).
+i je ne sais pas ce que c'est, mais +m si je me souviens bien c'est un salon sous modération, ce qui se fait très bien avec Jabber.
+i c'est channel sur invitation uniquement, avec possibilité pour les gens sur liste d'accès de se faire inviter par ChanServ. Il y a pas mal d'autres modes utiles pour la modération : +R qui oblige les gens à être enregistrés pour rejoindre le channel, +M qui les oblige à être enregistrés pour parler, +l qui met une limite sur le nombre d'utilisateurs, et j'en passe.
Moins d'utilisateurs ? Avec le nombre d'utilisateurs de Google, je ne sais pas ce qu'il te faut…
J'utilise peut-être Google Chat mais ça n'est pas pour autant que je me « sens » utilisateur de Jabber. Je ne maitrise aucune des notions liées à ce protocole de communication (comme tu peux surement le constater), et je l'utilise uniquement pour des discussions simples. Si tu veux jouer à ça, avec le nombre d'utilisateurs de Skyrock, Ustream et Justin.tv ça fait pas mal d'utilisateurs d'IRC aussi.
Un protocole tout en XML bien illisible comparé au plain text d'IRC.
Quand tu écris un bot, pouvoir lire facilement ce que t'envoie le serveur c'est pratique :) Mais bon, je suis développeur, mon avis est forcément biaisé là dessus et c'est uniquement du troll poilu.
Sinon, je n'ai pas trouvé de client web Jabber intégrable dans un site web, tu peux me donner un lien ? Ça m'intéresse.
La nécessité de se créer un compte quelque part pour se connecter et discuter ;
Une gestion moins fine des permissions sur les salons que ce qu'IRC permet (via ChanServ et les différents modes comme +m ou +i) ;
Beaucoup moins d'utilisateurs donc une bien plus grosse barrière à l'entrée (pour une petite communauté, c'est important) ;
Un protocole tout en XML bien illisible comparé au plain text d'IRC.
Sinon, IRC a aussi tout un écosystème qui n'est pas aussi développé pour Jabber. Par exemple, pour une communauté orientée autour d'un site web, proposer un client IRC web n'est pas forcément une mauvaise idée pour attirer de nouvelles personnes (et des services comme Mibbit le proposent). Des "gadgets" comme les bots de CIA.cv sont d'après moi aussi quelque chose d'utiles pour un petit projet libre. Ou bien un bot qui gère une FAQ comme utilisé sur ##C++ @ freenode.
Dans les features de Jabber que tu cites, pas mal sont aussi gérées par des outils autour d'IRC. Ça n'est pas aussi intégré mais au final ça marche très bien. Par exemple, les messages privés peuvent être envoyés via MemoServ, ou comme tu le citais NickServ pour la gestion des comptes.
Effectivement, mais ça n'est pas ce qui est utilisé comme root filesystem (dans aucun cas, cf. les limitations évoquées dans l'article que tu cites). On peut toujours supposer que l'auteur du journal a fait ses tests sur une partition montée en cofs, mais ça me semble peu probable.
Quand j'utilisais coLinux (l'an dernier), il y avait une image disque .vdi avec de l'ext4 dessus, et effectivement Samba pour accèder au disque Windows. La FAQ de coLinux semble confirmer ce point. Renseigne toi 30 secondes avant de raconter n'importe quoi :-)
Mais de toute façon ça n'a que peu de rapport avec les problèmes de vitesse qu'a Cygwin avec les scripts bash : c'est à mon avis plutôt à cause du fait que le fork est une opération assez coûteuse sous Windows (si on veut garder la sémantique UNIX de l'opération).
Le titre de l'article a beau être un peu exagéré, j'ai du mal avec le reste de tes « critiques » :
Le code source des paquets est fourni, et ils sont hostés sur le serveur de l'auteur de l'article, on peut donc supposer que c'est lui qui les a compilé ;
La procédure d'installation se résume à deux installation de paquets, une copie de fichier, une commande lancée en root, une édition de fichier et un reboot. C'est loin d'être une procédure longue ;
Ça ne marche pas à moitié, ça marche pour ce que c'est sensé faire. Si ça ne te convient pas, personne ne te force à l'utiliser.
Optimus ne fonctionne pas totalement, dans le sens où il n'y a pas encore de bascule automatique entre la carte Intel à basse consommation et la carte Nvidia à forte consommation.
Faire fonctionner uniquement la carte Nvidia est un grand pas en avant (ça permet d'avoir enfin des performances 3D correctes sur les laptops munis de cette technologie), mais c'est encore un gros retard sur ce qui est fait sous Windows, notamment car la batterie s'épuise beaucoup plus vite maintenant que la carte Nvidia est tout le temps allumée.
L'auteur de l'article propose pour cela une solution qui ne fonctionne pas encore actuellement : faire tourner deux serveurs X, un qui utilise la carte Intel et un pour les applications 3D qui ont besoin de performance, qui utilise la carte Nvidia et qui n'est pas toujours lancé. C'est encore loin d'une bascule transparente, mais ça serait déjà très bien pour la plupart des utilisateurs. Et si j'ai bien compris, à moins de totalement changer l'architecture de X, proposer une bascule automatique entre les deux cartes est actuellement impossible. Wait and see!
J'avais trouvé SNUSP assez marrant quand je codais des interpréteurs pour ce genre de bêtises il y a un moment.
C'est un peu comme du Brainfuck, mais bidimensionnel : on a / et \ qui permettent de faire des « virages » dans le flux d'exécution, et une boucle se représente vraiment comme... une boucle en deux dimensions (un rectangle avec des / et des \ pour les coins quoi).
Il y a quelques extensions du langage qui permettent d'avoir des procédures, des threads ou de la mémoire bidimensionnelle. Bref, beaucoup de fun si tu veux coder un interpréteur :)
Ça n'est que partiellement vrai. À ce que j'ai compris, il manquait une faille permettant d'obtenir le plain text du metldr pour que fail0verflow récupère la clé privée. Il se trouve que geohot avait depuis quelque temps un exploit permettant cela et l'a donc utilisé. Ça n'empêche qu'il n'a pas « juste » utilisé ce qui a été released par fail0verflow, il y avait un peu plus derrière.
Et puis le « jeune prétentieux » a aussi fait pas mal de boulot sur l'iPhone avant. C'est pas juste un script kiddy, contrairement à ce que tu sembles dire.
Renvoyer les données sur la même connexion != renvoyer les données sur la même interface.
Si l'IP 1.2.3.4 contacte 5.6.7.8 via eth1, mais que 5.6.7.8 a une route qui dit « 1.2.3.4 va sur eth0 », les données de 1.2.3.4 vers 5.6.7.8 sont reçues sur eth1 mais la réponse de 5.6.7.8 à 1.2.3.4 passera par eth0.
[^] # Re: Plus simple.
Posté par Pierre Bourdon . En réponse au journal Falling in love with Gnome. Évalué à 4.
Peut-être que des gens utilisent Linux et Gnome pour d'autres raison que la liberté des logiciels ?
# chromium
Posté par Pierre Bourdon . En réponse au journal Consommation mémoire navigateurs web. Évalué à 10.
Sauf que tu oublies que chromium lance plusieurs process, donc la consommation mémoire que tu vois là ne veux juste rien dire.
[^] # Re: neko
Posté par Pierre Bourdon . En réponse au journal Nom de geek pour une chatte ?. Évalué à 3.
Raté !
[^] # Re: utilisation des cgroups ?
Posté par Pierre Bourdon . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 5.
Les cgroups sont arborescents donc ça ne pose pas de problème : on peut créer des "sous"-cgroups dans un cgroup.
[^] # Re: et si debian disait juste non
Posté par Pierre Bourdon . En réponse au journal GNOME seulement compatible avec Linux ?. Évalué à 2.
C'est vrai qu'on entend beaucoup plus parler de gens sous Mint ou sous PCLinuxOS (j'avais jamais entendu parlé de cette distro...) que de gens sous Arch !
[^] # Re: tant mieux
Posté par Pierre Bourdon . En réponse au journal GNOME seulement compatible avec Linux ?. Évalué à 10.
Et surtout où est le rapport avec udev ? J'utilise (et c'est surement le cas de plein de monde) udev et je monte mes partitions soit classiquement avec /dev/sdXY, soit par label avec /dev/disk/by-label/SWAP par exemple (lisible, pratique, etc. tant qu'il n'y a pas de conflits).
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . En réponse au journal Sortie de Perl 5.14.0. Évalué à 4.
Tu penses que c'est un bon point pour OCaml d'être comparé au C ? :-)
C'était dans des contextes différents en fait. Et c'est pas que la sortie d'ocamldep n'est pas bien triée, c'est plutôt qu'il ne fait pas ce dont j'avais besoin ici.
En gros, le cas d'utilisation, c'est que j'ai une liste de .ml dans un ordre quelconque, et je dois les compiler en .o pour les linker avec du C++ derrière. ocamldep est incapable de me sortir les trucs dans le bon format (il ne sait générer que des foo.cmo: foo.cmi et foo.cmx: foo.cmo, ou alors la forme « brute » qui est « a: b c ». Dans tous les cas, avoir besoin d'ocamldep pour linker son binaire c'est honteux : pourquoi est-ce que le linker d'OCaml ne sait pas faire ce travail tout seul ?
Et induire une plus grosse utilisation de mémoire et des IPC. Cool.
Il y a aussi un autre problème que je vais illustrer par deux exemples. Je cherche une lib OCaml qui binde OpenGL. J'ai le choix entre LablGL, glcaml, glmlite et un autre dont j'ai plus le nom en tête. Pareil pour SDL : sdlcaml et ocamlsdl. Sans compter que la plupart des ces libs sont buggées et non maintenues (il y a des bouts de l'interface SDLmixer d'OCamlSDL qui segfaultaient systématiquement à cause d'une typo dans le code C il y a environ un an, c'est peut-être encore le cas, j'en sais rien).
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . En réponse au journal Sortie de Perl 5.14.0. Évalué à 2.
Quand je parlais de release mineure je voulais parler de 3.11.1, qui n'a pas été release sous Windows non plus.
En vrai le support d'OCaml sous Windows a commencé à mourir avec l'introduction de Dynlink en mode natif, qui a obligé à tout compiler avec flexdll sous Windows pour avoir un comportement du dynamic linker identique à celui traditionnel sous UNIX. C'était genre vers 3.09 ou 3.10 il me semble. Avant tout passait assez correctement avec mingw et msys, maintenant il faut hacker... Tout ça pour une feature dont personne ne se sert au final.
C'est bête, OCaml ça a été ma première introduction à la programmation fonctionnelle, mais ça a vraiment vieilli vite dans ma tête depuis que je me suis mis un peu à Haskell. Je sais pas ce que je ferais sans typeclasses de nos jours :)
En même temps c'était voué à l'échec depuis un moment. J'ai l'impression qu'il y a de moins en moins de gens de l'INRIA qui bossent sur OCaml, et historiquement le projet a toujours été très fermé à toutes les contributions externes. C'était clair qu'à un moment ça allait casser.
[^] # Re: Jabber ?
Posté par Pierre Bourdon . En réponse au message [Debian]Ircd-hybrid - empêcher la création de channels. Évalué à 1.
Je n'ai pas dit être fermé à l'installation d'un client.
D'accord, ça répond en fait à ma question sur « comment » (le coup de guest@ etc.). Il faut chercher un serveur qui supporte ça, ou tous les serveurs le supportent ?
Merci pour les autres informations, notamment les clients webs :)
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . En réponse au journal Sortie de Perl 5.14.0. Évalué à 10.
[^] # Re: Jabber ?
Posté par Pierre Bourdon . En réponse au message [Debian]Ircd-hybrid - empêcher la création de channels. Évalué à 2.
Je ne le savais pas. Imaginons moi, M. λ, veut me connecter sur un salon de discussion Jabber sans avoir de compte ni de client Jabber, je fais comment concrétement ? Avec IRC la barrière à l'entrée est minimale : en passant par un client desktop (genre X-Chat) c'est une adresse de serveur à rentrer + un join, et en passant par un client web genre Mibbit c'est juste cliquer sur un lien hypertexte. Je ne pense vraiment pas que ça soit si simple avec Jabber (malheureusement).
+i c'est channel sur invitation uniquement, avec possibilité pour les gens sur liste d'accès de se faire inviter par ChanServ. Il y a pas mal d'autres modes utiles pour la modération : +R qui oblige les gens à être enregistrés pour rejoindre le channel, +M qui les oblige à être enregistrés pour parler, +l qui met une limite sur le nombre d'utilisateurs, et j'en passe.
J'utilise peut-être Google Chat mais ça n'est pas pour autant que je me « sens » utilisateur de Jabber. Je ne maitrise aucune des notions liées à ce protocole de communication (comme tu peux surement le constater), et je l'utilise uniquement pour des discussions simples. Si tu veux jouer à ça, avec le nombre d'utilisateurs de Skyrock, Ustream et Justin.tv ça fait pas mal d'utilisateurs d'IRC aussi.
Quand tu écris un bot, pouvoir lire facilement ce que t'envoie le serveur c'est pratique :) Mais bon, je suis développeur, mon avis est forcément biaisé là dessus et c'est uniquement du troll poilu.
Sinon, je n'ai pas trouvé de client web Jabber intégrable dans un site web, tu peux me donner un lien ? Ça m'intéresse.
[^] # Re: Perl 6 ?
Posté par Pierre Bourdon . En réponse au journal Sortie de Perl 5.14.0. Évalué à 1.
Si tu penses qu'OCaml est mieux que la concurrence, c'est plutôt en années de retard qu'il faudrait compter :)
/me est déjà dehors.
[^] # Re: Jabber ?
Posté par Pierre Bourdon . En réponse au message [Debian]Ircd-hybrid - empêcher la création de channels. Évalué à 2.
Sinon, IRC a aussi tout un écosystème qui n'est pas aussi développé pour Jabber. Par exemple, pour une communauté orientée autour d'un site web, proposer un client IRC web n'est pas forcément une mauvaise idée pour attirer de nouvelles personnes (et des services comme Mibbit le proposent). Des "gadgets" comme les bots de CIA.cv sont d'après moi aussi quelque chose d'utiles pour un petit projet libre. Ou bien un bot qui gère une FAQ comme utilisé sur ##C++ @ freenode.
Dans les features de Jabber que tu cites, pas mal sont aussi gérées par des outils autour d'IRC. Ça n'est pas aussi intégré mais au final ça marche très bien. Par exemple, les messages privés peuvent être envoyés via MemoServ, ou comme tu le citais NickServ pour la gestion des comptes.
[^] # Re: Applications graphiques
Posté par Pierre Bourdon . En réponse au journal andLinux ou comment faire tourner linux dans windows sans virtualbox. Évalué à 2.
C'est Xming qui est utilisé.
[^] # Re: Tres drole
Posté par Pierre Bourdon . En réponse au journal andLinux ou comment faire tourner linux dans windows sans virtualbox. Évalué à 6.
Effectivement, mais ça n'est pas ce qui est utilisé comme root filesystem (dans aucun cas, cf. les limitations évoquées dans l'article que tu cites). On peut toujours supposer que l'auteur du journal a fait ses tests sur une partition montée en cofs, mais ça me semble peu probable.
[^] # Re: Tres drole
Posté par Pierre Bourdon . En réponse au journal andLinux ou comment faire tourner linux dans windows sans virtualbox. Évalué à 8.
Quand j'utilisais coLinux (l'an dernier), il y avait une image disque .vdi avec de l'ext4 dessus, et effectivement Samba pour accèder au disque Windows. La FAQ de coLinux semble confirmer ce point. Renseigne toi 30 secondes avant de raconter n'importe quoi :-)
Mais de toute façon ça n'a que peu de rapport avec les problèmes de vitesse qu'a Cygwin avec les scripts bash : c'est à mon avis plutôt à cause du fait que le fork est une opération assez coûteuse sous Windows (si on veut garder la sémantique UNIX de l'opération).
[^] # Re: Ah j'ai oublié ...
Posté par Pierre Bourdon . En réponse au journal 5 projets GSOC pour The Gimp. Évalué à 10.
Il y a 4 projets de GSoC concernant Inkscape :
Le 3ème devrait notamment t'intéresser :)
# Lien du journal
Posté par Pierre Bourdon . En réponse au journal Do no evil qu'ils disaient.... Évalué à 5.
Je ne peux pas accéder à ton lien, il me redirige vers une page de login.
Autre source : http://www.engadget.com/2011/05/10/internal-emails-reveal-googles-desperation-over-skyhooks-andro/
[^] # Re: Plus précisément
Posté par Pierre Bourdon . En réponse au journal Nvidia Optimus fonctionnel sur Linux!. Évalué à 10.
Le titre de l'article a beau être un peu exagéré, j'ai du mal avec le reste de tes « critiques » :
# Plus précisément
Posté par Pierre Bourdon . En réponse au journal Nvidia Optimus fonctionnel sur Linux!. Évalué à 10.
Optimus ne fonctionne pas totalement, dans le sens où il n'y a pas encore de bascule automatique entre la carte Intel à basse consommation et la carte Nvidia à forte consommation.
Faire fonctionner uniquement la carte Nvidia est un grand pas en avant (ça permet d'avoir enfin des performances 3D correctes sur les laptops munis de cette technologie), mais c'est encore un gros retard sur ce qui est fait sous Windows, notamment car la batterie s'épuise beaucoup plus vite maintenant que la carte Nvidia est tout le temps allumée.
L'auteur de l'article propose pour cela une solution qui ne fonctionne pas encore actuellement : faire tourner deux serveurs X, un qui utilise la carte Intel et un pour les applications 3D qui ont besoin de performance, qui utilise la carte Nvidia et qui n'est pas toujours lancé. C'est encore loin d'une bascule transparente, mais ça serait déjà très bien pour la plupart des utilisateurs. Et si j'ai bien compris, à moins de totalement changer l'architecture de X, proposer une bascule automatique entre les deux cartes est actuellement impossible. Wait and see!
[^] # Re: Limitations arbitraires
Posté par Pierre Bourdon . En réponse au journal Un nouveau EeePC sous Linux?. Évalué à 3.
Oui, car un disque dur c'est tellement rapide qu'avoir un gros cache en RAM c'est superflu !
Et sinon, tu m'offres un SSD ? :-)
# SNUSP
Posté par Pierre Bourdon . En réponse au message petite bêtise juste pour amuser les plus fêlés d'entre nous.... Évalué à 4.
J'avais trouvé SNUSP assez marrant quand je codais des interpréteurs pour ce genre de bêtises il y a un moment.
C'est un peu comme du Brainfuck, mais bidimensionnel : on a / et \ qui permettent de faire des « virages » dans le flux d'exécution, et une boucle se représente vraiment comme... une boucle en deux dimensions (un rectangle avec des / et des \ pour les coins quoi).
Il y a quelques extensions du langage qui permettent d'avoir des procédures, des threads ou de la mémoire bidimensionnelle. Bref, beaucoup de fun si tu veux coder un interpréteur :)
[^] # Re: IOS ?
Posté par Pierre Bourdon . En réponse au journal iOS5 (ou 4 et demi ?). Évalué à 2.
Tu devrais mettre à jour, je tourne sous IOS 27.31 depuis presque un an.
[^] # Re: Correction
Posté par Pierre Bourdon . En réponse au journal Sony, GeoHot et Anonymous. Évalué à 10.
Ça n'est que partiellement vrai. À ce que j'ai compris, il manquait une faille permettant d'obtenir le plain text du metldr pour que fail0verflow récupère la clé privée. Il se trouve que geohot avait depuis quelque temps un exploit permettant cela et l'a donc utilisé. Ça n'empêche qu'il n'a pas « juste » utilisé ce qui a été released par fail0verflow, il y avait un peu plus derrière.
Et puis le « jeune prétentieux » a aussi fait pas mal de boulot sur l'iPhone avant. C'est pas juste un script kiddy, contrairement à ce que tu sembles dire.
[^] # Re: Utiliser xinetd ?
Posté par Pierre Bourdon . En réponse au message Forcer un programme à utiliser une interface réseau. Évalué à 2.
Si l'IP 1.2.3.4 contacte 5.6.7.8 via eth1, mais que 5.6.7.8 a une route qui dit « 1.2.3.4 va sur eth0 », les données de 1.2.3.4 vers 5.6.7.8 sont reçues sur eth1 mais la réponse de 5.6.7.8 à 1.2.3.4 passera par eth0.