Il y a pire !
Les daicideurs pressés devraient immédiatement supprimer cette horeur communiste de leur parc informatique, car aptitude contient, j'ai du mal à le dire tellement le choc et l'émotion me nouent le clavier, aptitude contient, disais-je, un démineur !
Toute une symbolique hippie, une dénonciation du développement militaire de nos beaux pays, et cela passe devant nous sans que personne ne s'en offusque ou ne s'en rende compte !
Ruby On Rails n'est pas un CMS. Il faudrait plutôt parler de Typo pour comparer quelque chose en Ruby avec Plone.
Ruby on rails est à typo ce que Zope est à Plone... Plone et Typo sont des utilisateurs des frameworks sous-jacents...
En plus, j'ai un doute sur les performances, j'imagine que certains clients un peu poussifs pourraient mettre beaucoup de temps à parser le fichier, plus qu'à faire une requête DNS en tous cas.
Je confirme que la lecture de ce fichier, à partir d'un nombre conséquent d'entrées (plus d'un million), devient proprement calamiteuse. C'est ce qui m'a fait abandonner ce système.
De plus, rediriger vers 127.0.0.1 fait que si vous utilisez pour du développement un serveur Web, vous aurez droit à un certain nombre de "blagues" sous forme de requêtes inutiles qui apparaîtront...
Perso, je redirige certains vrais gêneurs vers ::dead, sinon le reste est filtré par noscript + adblock... J'ai notamment la ligne suivante :
Mais un fichier hosts de plusieurs centaines milliers de lignes, faut pas déconner, c'est mauvais pour certaines applis (à l'époque, je ne sais plus quel client jabber c'était qui ne supportait vraiment pas ça)
Pour l'ACPI, c'est pas que du Intel... Y'a ce point également à ne pas oublier : http://antitrust.slated.org/www.iowaconsumercase.org/011607/(...)
"It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work", Bill Gates
Traduction approximative :
"Cela serait dommage que nous et nos partenaires fassions le travail et qu'au final Linux fonctionne bien sans devoir faire ce travail."
Microsoft, avec Vista, a entièrement refait son architecture graphique.
MacOS X ne peut pas supporter la technologie Optimus pour l'instant, idem pour Windows XP (mais bon vu son âge...)
Tu n'as pas répondu à la question : en quoi est-ce hostile à Linux?
Dans l'exemple de ton commentaire, je vois du matos qui évolue, du code qui est fait pour Windows pour s'adapter, et ce code pas fait pour Linux. Ce n'est pas de l'hostilité, juste personne pour payer un dév pour faire pour Linux.
Je résume le code de la DSDT vu que c'est pas clair apparemment :
if (OS == windows) {
trucQuiMarche();
} else if (OS == linux) {
trucQuiPlanteLamentablement();
}
La correction, c'est d'enlever le test et de ne faire que trucQuiMarche, qu'il s'agisse de windows ou linux.
Quand le compilateur AML de Microsoft introduit du bytecode invalide (qui plantait à une époque l'interpréteur de Linux), c'est pas hostile, c'est "l'évolution" ?
C'est "l'évolution" qui dit qu'il faut que ce qui est simple ne doit plus l'être et que seul ce qui est compliqué mérite d'exister ?
Dans mes exemples, j'ai mis l'ACPI. Si ça c'est pas de l'hostile à Linux franchement, que te faut-il de plus ? Un système où le BIOS filtre sur l'OS, un système où un bytecode les trois quarts du temps non conforme est indispensable au fonctionnement de la machine...
Quand linux ne boote plus parce qu'on a augmenté la quantité de RAM et que la DSDT fait mal le mapping mémoire pour Linux, franchement, t'as de quoi chialer (et c'est du vécu)
Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
"Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel.
Hum, raté...
Tout d'abord, en effet, le pilote nvidia ne trouve pas de sortie, et donc il refuse de lancer un serveur X.
Sinon, pour la partie OpenGL, c'est assez complexe. OpenGL seul ne peut pas marcher, quel que soit l'OS. Il faut systématiquement un complément qui fournisse le contexte sur lequel le rendu se fera. Dans le cas de Windows, il s'agit de WGL. Dans le cas du serveur X, il s'agit de GLX.
Pour faire fonctionner Optimus en cassant le moins de choses possible sur l'architecture de X, il faudrait détourner la libGL et être capable de créer un contexte dans le pilote nVidia qui serve à faire le rendu dans un buffer qui soit dans le framebuffer de l'IGP Intel. Ce qui bloque sérieusement actuellement, c'est la création de ce contexte il me semble.
Au passage la platforme ion2 de nvidia en est réduite à un gpu sur bus pci-e alors que le ion était un vrai chipset (contrôleur usb, ddr)
En effet, le contrôleur mémoire est intégré au CPU. Et comme intel force sûrement encore la vente du chipset avec le CPU, ben nVidia a décidé de se simplifier la vie et de ne faire plus qu'un GPU à l'aide d'Optimus. Je ne vois pas comment leur reprocher ça...
Intel a pété sa gueule à ION en incluant dans l'Atom un IGP (et en refusant je ne sais quelle licence à nVidia).
nVidia a donc préparé ION2, avec la technologie Optimus, pour contrer ce coup bas d'Intel.
J'ai trouvé tous tes liens, j'avais fait mes recherches hein...
Sinon, l'autonomie est ridicule quand t'as la carte nvidia allumée en permanence, typiquement quand t'es sous linux et que t'as pas utilisé acpi_call ou une autre méthode pour éteindre la carte graphique.
Non, justement, il est catégoriquement impossible de faire marcher la carte nvidia, il n'est pas possible d'allumer la carte nvidia et d'éteindre la carte intel, ni avec switcheroo, ni avec aucune bidouille connue, ni avec les appels liés à Optimus dans la DSDT. Il n'y a pas de réglage dans le bios, pas de réglage dans windows... Rien, nada.
Le GPU Intel, avec les pilotes libres, marche pour la 2D uniquement, pour la 3D, ça rame sérieusement.
Je n'ai peut être pas été clair dans l'explication : nVidia Optimus, ce n'est pas du tout la même chose que les systèmes hybrides à base de deux cartes. Certains fabricants vont laisser un mécanisme "simulant" le système hybride, qui permet donc de faire marcher le tout sous Linux. Mais ce n'est pas le cas de l'Asus N61Jv...
Sur le très long terme tu veux dire ? To make this as good as Windows we need to seriously re-architect the X server + drivers.
Et perso je ne considère pas qu'utiliser les pilotes libres intel, sur un GPU aussi minable que celui là, ça soit une bonne chose. C'est tellement lent que des trucs basiques vont ramer : même un jeu 3D minimal comme ksudoku (en mode roxdoku) rame... Si ça donne une bonne image du libre, je pige plus...
Il s'agit de diodes éclairant le PC, sur le côté, autour du clavier... Toshiba appelle ça "illumination". Elles peuvent être éteintes, sous Windows, à l'aide d'un bouton sur le clavier. Sous Linux, elles restaient allumées en permanence, c'était pénible.
Effectivement, pour si peu de mails, c'est problématique.
Il faudrait que des efforts soient faits pour pouvoir rebasculer sur SQLite au lieu de MySQL, mais les performances de SQLite pour Akonadi sont... pas terribles on va dire... Une autre solution serait d'utiliser mysql embedded peut être ?
Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?
Sauf que, depuis le début, l'idée c'est "une appli compatible Android == une appli compatible Linux", ce qui est faux, à moins de réduire Linux stricto senso à un noyau (et encore, le noyau des Android, avec sa couche de patchs, a des différences déjà), ce qui est assez débile à mon sens. Dans ce cas, tu peux dire qu'une appli UNIX est facilement portable sous Windows (ben oui, y'a une couche POSIX dans le noyau Windows NT5)... Tu peux aussi dire qu'une appli MacOS X est portable sous Darwin, c'est tout aussi vrai et faux.
Sauf que là, il ne s'agit pas de libraires à installer mais de librairies à écrire.
C'est comme dire que pour porter une appli sur Linux il suffit de la porter sur Windows et après d'utiliser wine... On est au même degré de similitude...
Pour ma part, Nokia navi et un coup du client googleMaps fait très bien l'affaire pour mes déplacements pédestres/cyclistes.
Oui, mais quand on voit des décalages variant de 5 à 20 mètres (voire parfois plus), ça montre que la puce n'est pas utilisable pour, par exemple, contribuer à OpenStreetMap.
Quant à la partie développement, il y a des démos interessantes sur le net, mais je suis toutefois intéressé par ton retour.
Facile : 15 minutes de développements, 15 heures pour tenter, sans réussir, de faire un environnement de cross compilation sous Linux...
Bien qu'on soit d'accord qu'Android n'est pas une distribution Linux classique, Android utilise quand même le noyau Linux.
Et alors ?
Si y'a *rien* en commun niveau espace utilisateur, ça changera quedal.
Si ton appli utilise directement les API Android pour l'affichage, le système de fichiers tordu d'Android, etc... Ben y'a aucune chance pour que ça marche sous un linux normal.
# Pire
Posté par Pinaraf . En réponse au journal Aptitude (Debian) : la grande désillusion. Évalué à 3.
Les daicideurs pressés devraient immédiatement supprimer cette horeur communiste de leur parc informatique, car aptitude contient, j'ai du mal à le dire tellement le choc et l'émotion me nouent le clavier, aptitude contient, disais-je, un démineur !
Toute une symbolique hippie, une dénonciation du développement militaire de nos beaux pays, et cela passe devant nous sans que personne ne s'en offusque ou ne s'en rende compte !
[^] # Re: Dans la jungle des CMS, difficile de s’y retrouver...
Posté par Pinaraf . En réponse à la dépêche Sortie de Plone 4. Évalué à 4.
Ruby on rails est à typo ce que Zope est à Plone... Plone et Typo sont des utilisateurs des frameworks sous-jacents...
[^] # Re: Site du même type
Posté par Pinaraf . En réponse à la dépêche Évolutions de la rentrée sur LinuxFr.org. Évalué à 4.
[^] # Re: Fausse bonne idée
Posté par Pinaraf . En réponse à la dépêche De l'efficacité du fichier hosts.. Évalué à 9.
Je confirme que la lecture de ce fichier, à partir d'un nombre conséquent d'entrées (plus d'un million), devient proprement calamiteuse. C'est ce qui m'a fait abandonner ce système.
De plus, rediriger vers 127.0.0.1 fait que si vous utilisez pour du développement un serveur Web, vous aurez droit à un certain nombre de "blagues" sous forme de requêtes inutiles qui apparaîtront...
Perso, je redirige certains vrais gêneurs vers ::dead, sinon le reste est filtré par noscript + adblock... J'ai notamment la ligne suivante :
::dead facebook.com fbcdn.net www.facebook.com graph.facebook.com
Mais un fichier hosts de plusieurs centaines milliers de lignes, faut pas déconner, c'est mauvais pour certaines applis (à l'époque, je ne sais plus quel client jabber c'était qui ne supportait vraiment pas ça)
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 2.
Sinon l'i7 le plus cher est à 1000€ : http://www.materiel.net/ctl/Socket_1366/55896-Core_i7_980X_E(...)
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 8.
"It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work", Bill Gates
Traduction approximative :
"Cela serait dommage que nous et nos partenaires fassions le travail et qu'au final Linux fonctionne bien sans devoir faire ce travail."
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 4.
MacOS X ne peut pas supporter la technologie Optimus pour l'instant, idem pour Windows XP (mais bon vu son âge...)
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 5.
Dans l'exemple de ton commentaire, je vois du matos qui évolue, du code qui est fait pour Windows pour s'adapter, et ce code pas fait pour Linux. Ce n'est pas de l'hostilité, juste personne pour payer un dév pour faire pour Linux.
Je résume le code de la DSDT vu que c'est pas clair apparemment :
if (OS == windows) {
trucQuiMarche();
} else if (OS == linux) {
trucQuiPlanteLamentablement();
}
La correction, c'est d'enlever le test et de ne faire que trucQuiMarche, qu'il s'agisse de windows ou linux.
Quand le compilateur AML de Microsoft introduit du bytecode invalide (qui plantait à une époque l'interpréteur de Linux), c'est pas hostile, c'est "l'évolution" ?
C'est "l'évolution" qui dit qu'il faut que ce qui est simple ne doit plus l'être et que seul ce qui est compliqué mérite d'exister ?
[^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 2.
Quand linux ne boote plus parce qu'on a augmenté la quantité de RAM et que la DSDT fait mal le mapping mémoire pour Linux, franchement, t'as de quoi chialer (et c'est du vécu)
[^] # Re: ARM.... Android .... Copains.
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 6.
"Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel.
Hum, raté...
Tout d'abord, en effet, le pilote nvidia ne trouve pas de sortie, et donc il refuse de lancer un serveur X.
Sinon, pour la partie OpenGL, c'est assez complexe. OpenGL seul ne peut pas marcher, quel que soit l'OS. Il faut systématiquement un complément qui fournisse le contexte sur lequel le rendu se fera. Dans le cas de Windows, il s'agit de WGL. Dans le cas du serveur X, il s'agit de GLX.
Pour faire fonctionner Optimus en cassant le moins de choses possible sur l'architecture de X, il faudrait détourner la libGL et être capable de créer un contexte dans le pilote nVidia qui serve à faire le rendu dans un buffer qui soit dans le framebuffer de l'IGP Intel. Ce qui bloque sérieusement actuellement, c'est la création de ce contexte il me semble.
[^] # Re: ...
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 3.
En effet, le contrôleur mémoire est intégré au CPU. Et comme intel force sûrement encore la vente du chipset avec le CPU, ben nVidia a décidé de se simplifier la vie et de ne faire plus qu'un GPU à l'aide d'Optimus. Je ne vois pas comment leur reprocher ça...
[^] # Re: Ce n'est pas X.Org le problème?
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 2.
[^] # Re: Ce n'est pas X.Org le problème?
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 3.
nVidia a donc préparé ION2, avec la technologie Optimus, pour contrer ce coup bas d'Intel.
[^] # Re: c'est bien non ?
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 4.
Sinon, l'autonomie est ridicule quand t'as la carte nvidia allumée en permanence, typiquement quand t'es sous linux et que t'as pas utilisé acpi_call ou une autre méthode pour éteindre la carte graphique.
Une mailing list sur launchpad est prévue explicitement pour ces problèmes : hybrid-graphics-linux@lists.launchpad.net.
Et pour info, l'avis de Dave Airlie sur Optimus : http://www.mail-archive.com/hybrid-graphics-linux@lists.laun(...)
[^] # Re: c'est bien non ?
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 6.
Le GPU Intel, avec les pilotes libres, marche pour la 2D uniquement, pour la 3D, ça rame sérieusement.
Je n'ai peut être pas été clair dans l'explication : nVidia Optimus, ce n'est pas du tout la même chose que les systèmes hybrides à base de deux cartes. Certains fabricants vont laisser un mécanisme "simulant" le système hybride, qui permet donc de faire marcher le tout sous Linux. Mais ce n'est pas le cas de l'Asus N61Jv...
[^] # Re: c'est bien non ?
Posté par Pinaraf . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 10.
To make this as good as Windows we need to seriously re-architect the X server + drivers.
Et perso je ne considère pas qu'utiliser les pilotes libres intel, sur un GPU aussi minable que celui là, ça soit une bonne chose. C'est tellement lent que des trucs basiques vont ramer : même un jeu 3D minimal comme ksudoku (en mode roxdoku) rame... Si ça donne une bonne image du libre, je pige plus...
[^] # Re: doc' à foison
Posté par Pinaraf . En réponse au journal De l'écriture d'un pilote Linux pour un gadget - suite. Évalué à 6.
[^] # Re: Quelles diodes?
Posté par Pinaraf . En réponse au journal De l'écriture d'un pilote Linux pour un gadget - suite. Évalué à 7.
[^] # Re: Réaction chimique
Posté par Pinaraf . En réponse au journal De l'écriture d'un pilote Linux pour un gadget - suite. Évalué à 8.
Mon pote a, je pense, pas eu les bons réflexes, résultat il y a eu un court-circuit au niveau de la carte mère... et PAF quoi...
[^] # Re: kdepim non inclu
Posté par Pinaraf . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 1.
Il faudrait que des efforts soient faits pour pouvoir rebasculer sur SQLite au lieu de MySQL, mais les performances de SQLite pour Akonadi sont... pas terribles on va dire... Une autre solution serait d'utiliser mysql embedded peut être ?
Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?
[^] # Re: kdepim non inclu
Posté par Pinaraf . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 2.
[^] # Re: Android != Linux
Posté par Pinaraf . En réponse au journal Android en tête au second trimestre 2010 sur le segment des OS pour téléphones portables (USA). Évalué à 3.
[^] # Re: Android != Linux
Posté par Pinaraf . En réponse au journal Android en tête au second trimestre 2010 sur le segment des OS pour téléphones portables (USA). Évalué à 3.
C'est comme dire que pour porter une appli sur Linux il suffit de la porter sur Windows et après d'utiliser wine... On est au même degré de similitude...
[^] # Re: Du rêve à la réalité...
Posté par Pinaraf . En réponse au journal Mon bon vieux Nokia E71.. Évalué à 3.
Oui, mais quand on voit des décalages variant de 5 à 20 mètres (voire parfois plus), ça montre que la puce n'est pas utilisable pour, par exemple, contribuer à OpenStreetMap.
Quant à la partie développement, il y a des démos interessantes sur le net, mais je suis toutefois intéressé par ton retour.
Facile : 15 minutes de développements, 15 heures pour tenter, sans réussir, de faire un environnement de cross compilation sous Linux...
[^] # Re: Android != Linux
Posté par Pinaraf . En réponse au journal Android en tête au second trimestre 2010 sur le segment des OS pour téléphones portables (USA). Évalué à 5.
Et alors ?
Si y'a *rien* en commun niveau espace utilisateur, ça changera quedal.
Si ton appli utilise directement les API Android pour l'affichage, le système de fichiers tordu d'Android, etc... Ben y'a aucune chance pour que ça marche sous un linux normal.