karteum59 a écrit 863 commentaires

Heu... Ce n'est pas que je cherche particulièrement à défendre MsOffice (je serais plutôt adepte du LaTeX...), m'enfin le souci que tu décris est désactivable depuis toujours : il suffit de décocher les ''styles automatiques''. A l'époque où j'étais contraint de l'utiliser, c'est un des premiers trucs que je désactivais à l'installation du bidule (avec 2-3 autres automatismes du même acabit, ainsi que cette horreur de trombone !).

Hum...
C'est pas RMS qui cautionnait la création de gNewSense (basée sur une Ubuntu ''nettoyée'') au prétexte que Debian n'était ''pas assez libre'' ? (existence de dépôts non-free, blobs/firmwares...)

Je suis assez d'accord, le Ion a l'air très sympa bien qu l'ATOM330 soit un peu limité (j'ai une Intel D945GCLF2 et c'est pas très jouissif question vitesse même si ça me suffit la plupart du temps, mais le chip graphique GMA950 est probablement le plus limitant et le Ion n'a pas cette limitation)

Note que je ne vois pas trop non plus l'intérêt du lecteur bluray (quelqu'un arrive à voir une différence de qualité significative entre un film sur DVD et un bluray sur un écran 21.5'' ?), or je suppose que ce lecteur compte pour une part importante du prix de l'ensemble non ?

N.B.: ton énorme écran full-HD est probablement à lui tout seul une usine à gaz pompeuse de courant ! :)

Pardus a également mis au point une alternative sympathique (remplacement d'init, remplacement des scripts shell par des modules Python...). La doc a disparu du site web principal depuis son remaniement, mais elle est toujours présente ici :
http://svn.uludag.org.tr/viewcvs/trunk/promotion/development(...)

Pardus (http://www.pardus-fr.org) commence à bien se répandre aussi

C'est clair, il faudrait fusiller (voire écarteler) tous les extrémistes ! :)

(--> [] )

Tu as aussi waf (http://code.google.com/p/waf/ ), qui est un peu dans le même esprit que scons (mais apparemment plus simple, léger et rapide).

git clone --depth 1 devrait te plaire... :)

Moi je trouve qu'on devrait promouvoir davantage le langage Ook (http://fr.wikipedia.org/wiki/Ook!#Ook.21 )
Comme ça le processus de sélection naturelle augmenterait naturellement le nombre de programmeurs vraiment barbus-poilus ! :)

Oops, mauvaise manip ("refresh" mal placé) qui m'a fait poster deux fois... Désolé :)

Mouais, enfin, le monsieur vient de dire que chacun peut choisir les 4 associations qu'il soutient ! Personne ne t'oblige à soutenir les faucheurs ou Sortir du Nucléaire... Donc je ne vois pas ce que tu reproches à Hooseek !

Mouais, enfin, le monsieur vient de dire que chacun peut choisir les 4 associations qu'il soutient ! Personne ne t'oblige à soutenir les faucheurs ou Sortir du Nucléaire... Donc je ne vois pas ce que tu reproches à Hooseek !

Mon .screenrc est bling-bling depuis longtemps :)
(N.B. et je suis d'accord, ^A est vrament très ch... J'ai mis ^O à la place !)
Par contre, si qqun connaît le truc pour parcourir l'historique de ma console (scrolling) via +flèches/PgUp/PgDown plutôt que ^O, ça m'intéresserait !!!

escape ^Oo
hardstatus alwayslastline
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}][%{Y}%l%{g}]%{=b C}[ %m/%d %c ]%{W}'

Ah ?
Il me semblait justement que TI avait fait un effort là-dessus (au vu de l'activité autour de cette carte dans OpenEmbedded, on ne peut pas dire que Linux soit à la rue sur cette archi ! Et OpenEmbedded est connu pour son intransigeance sur l'aspect 100% libre de tout ce qui y est intégré !).
Il me semble précisément que Angström est parfaitement utilisable (je crois d'ailleurs que Koen Kooi, un des gros contributeurs, est employé par TI), et intègre tout le nécessaire question drivers, quels sont ceux qui sont non-libres ou manquants selon toi ?
N.B.: Ogre3D sur BeagleBoard/PowerVR : http://www.youtube.com/watch?v=LDtUE5PIhV0 :)
Android sur BeagleBoard : http://www.youtube.com/watch?v=CR5rGia8GcY

J'ai une D945GCLF2 avec un ATOM 330. J'en suis globalement satisfait mais
* oublie le 1080p (à moins qu'il y ait une astuce pour mieux utiliser le multi-core avec le H.264/lavc)
* pour la 3D, c'est du GMA950. Avec Elisa/XBMC ça rame un peu chez moi (de plus, il y a des soucis avec Xorg 1.5 => obligation de repasser en XAA ! Et ce n'est pas sans bug...)
* ce n'est pas fanless (mais il doit être possible de mettre un ventilo moins bruyant voire un gros radiateur)

Cela dit, le rapport puissance*/(prix*consommation*encombrement) n'est pas mal du tout...

Si tu prends une EPIA ou une carte à base d'ATOM 230 (les eee rentrent dans cette catégorie, tout comme la D945GCLF), OK tu seras fanless, mais la puissance sera encore moindre... (cela dit vu que j'ai des doutes sur l'utilisation efficace de mes deux cores par lavc, il n'est pas exclu que le résultat soit en fait identique sur un ATOM 230 monocore... :)

Maintenant, si tu veux t'amuser un peu, tu peux aussi tenter la beagleboard ! (moins puissante qu'un ATOM en calcul pur mais possédant un DSP et du câblage/microcode dédié pour du décodage H.264, et certainement beaucoup plus compacte et économe en énergie ! :)
-> http://beagleboard.org/

Tu as déjà utilisé arora ? (http://code.google.com/p/arora/ )
C'est un navigateur léger basé sur QT4/Webkit (en fait c'est une évolution du code de démo Webkit dans QT4). Très rapide et réactif (et il paraît que c'est encore mieux avec QT4.5), la seule chose qui me manque est adblock (mais privoxy aide bien...), et occasionnellement flash (mais ça fait aussi du bien de s'en passer, pour une navigation plus légère et plus libre :)

Hmmm.
Faire une puce pour l'embarqué ça ne s'improvise pas, et contrairement à une machine de bureau tu n'as même pas la flexibilité de choisir tes composants de manière discrète.
Dans l'embarqué, les solutions sont de toute façons de plus en plus intégrées (type OMAP/PowerVR), une puce graphique à part n'est pas appropriée !

Je suis plutôt d'accord avec le commentaire précédent : je vois de moins en moins l'intérêt de OGD compte tenu du fait que
- ATI sera bientôt suffisamment libre, Intel l'est déjà (libre à toi de choisir une carte-mère / un laptop qui possède un chip graphique Intel. ça a été mon cas)
- NVidia aura bientôt Nouveau qui sera libre et utilisable
- D'une manière générale, dans le monde du HW il faut avoir une masse / un volume critique pour arriver à qqch. Il ne suffit pas de faire un produit, il faut s'inscrire dans la dynamique d'un marché en perpetuelle évolution. Et l'équipe de OGD n'a (à mon avis) pas les moyens d'entrer ET rester dans la course ! (j'espère me tromper, mais hélas je suis pessimiste)

Donc oui, pour moi, concentrons les efforts sur des drivers libres (comme Nouveau) !

P.S.: cependant, OGD peut aussi à ma connaissance être vue comme une carte FPGA générique, donc servir à faire du calcul autre (ou à faire mumuse avec du VHDL, à l'instar de Armadeus)

Bon, je me réponds à moi-même : j'aurais dû regarder la FAQ avant de trollposter trop vite !
En fait, ils ont bien l'intention de backporter ces modifs dans CPython 3.0, mais à moyen/long terme, et leur approche est conditionnée par des besoins en interne (large base de code Python 2.x utilisée sur leurs machines)

Le fait de se baser sur une version 2.x s'explique par son utilisation dans de nombreux projets existants
Je pense que les ingés de Google savent ce qu'ils font et je me garderai donc bien de les critiquer, mais néanmoins je m'interroge sur ce choix : en effet, réaliser ce JIT basé sur LLVM va prendre un temps non négligeable, et le code Python 2.x existant se satisfait souvent bien de CPython (qui va continuer à exister). Quitte à faire des changements aussi importants que ceux décrits, j'aurais personnellement trouvé été plus enclin à me baser sur Python 3 vu que sa pénétration est quand même destiné à s'accroître avec le temps (ou sinon c'est un peu un désavoeu pour Python 3 en soi !).
M'enfin...

Hmmm, je ne sais pas.
Car dans ce cas il faut pouvoir /prouver/ que tu as été victime d'une infraction et que le responsable est donc qqun d'autre (trop facile, sinon...), et ça n'est pas à la portée du premier venu ! (on en revient au besoin d'avoir des logs)

Si qqun vole les plans du Rafale en hackant un ordi de l'armée depuis un accès sur ma borne wifi, je ne crois pas qu'ils vont me laisser m'en tirer avec un "c'est pas moi, c'est ma borne wifi"...

Hum...

Sauf erreur de ma part, si quelqu'un passe par ton AP Wifi et pirate (allez, au hasard, lance un scan de port sur un site de l'armée), tu es responsable !
De même, le recel de contrefaçon est déjà passible de 3 ans d'emprisonnement et 300000 euros d'amende, et l'unique critère de reconnaissance est déjà l'adresse IP du point d'accès... Si qqun fait du P2P sur ta ligne Wifi tu peux déjà te prendre un procès !
Bref, quand tu partages un accès au net (quel qu'il soit, volontairement ou non), tu es déjà sensé logger/contrôler ce qui passe puisque d'une certaine manière tu deviens "ISP".

Ce que l'HADOPI change (entre autres), c'est la systématisation/automatisation des contrôles (un peu comme les radars automatiques), le fait que toutes les instances judiciaires soient court-circuitées et le travail de flicage délégué à des instance privées (dont la probité reste plus qu'incertaine/aléatoire).

ça ne change rien au fait qu'il faille surveiller / sécuriser son accès (surtout quand on est cybercafé/ISP !), par contre, aujourd'hui on peut (encore) essayer de montrer sa bonne foi au tribunal et arguer du fait qu'un accès ne peut être sécurisé à 100%... (pour des raisons techniques, et aussi compte tenu du facteur humain dans le cas d'AP privés : tout le monde n'est pas expert en sécurité informatique !)

Concernant le problème des performances et de l'espace d'adressage : pourquoi n'est-il pas possible de factoriser un certain nombre de choses interdépendantes sous formes de libs partagées (en userland donc, mais partageant un espace d'adressage commun au sein du même processus serveur ou de l'application hôte) ?

J'imagine qu'un certain nombre de choses complexes pourraient peut-être aussi être sorties du noyau : par exemple : est-il nécessaire que les filesystems soient en kernel-space ? (le rôle du noyau ne pourrait-il pas se borner à abstraire le device physique sous-jacent et le présenter dans /dev, en gérant les accès concurrents, les interruptions, les droits d'accès, etc. Charge à un processus serveur (ou une lib) en userland de jouer le rôle du FS).
Idem, la stack IP ne pourrait-elle pas être en userland, le kernel se bornant à abstraire l'interface réseau physique ? Etc...

Autre chose : plutôt que d'avoir une approche où un processus serveur fait le boulot (cas des micro-noyaux), est-ce qu'il y a moyen de faire que le code d'une lib (et juste ce code là, pas le reste du code de l'appli qui est linkée dessus) ait des droits spécifiques (pour accéder directement au matériel, ou plus simplement à un service/fichier spécial donné) ?
(Par exemple, il me semble que le ring est défini au niveau de chaque page de code, un jmp dans une page de code ring0 permettrait donc de fonctionner dans ce mode ?). Si c'était possible, une appli lambda aurait juste besoin d'être linkée à la "libfs" (qui accéderait directement à /dev/sda*), et on éviterait les IPC (cas des micro-noyaux) et/ou bon nombre de "int 0x80" (noyau Linux actuel) pour les appels au fs...

P.S.: c'est une question ouverte, pas un troll ! (j'espère d'ailleurs que je suis assez clair dans ma question... :)

P.S.2: ah si, le petit troll de rigueur qui vient avec : si le noyau Linux était sous licence LGPL (ou BSD), on pourrait explorer ce type de voie en partant de ce dernier. Mais il est sous licence GPL => impossible de copier-coller du code du noyau Linux (des algos qu'on trouverait intéressants, par exemple) pour les mettre dans des libs userland, ou sinon seules les applis GPL pourront s'y linker... Dommage que la GPL restreigne l'usage du code sur un tel critère technique...

Heu...
En l'occurence, sur la D945GCLF2 ma carte graphique est "00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller"

Donc c'est du GMA950... pas terrible question accélération (problème annexe : ça pose des soucis depuis Lenny / xorg 1.5 : obligation de forcer XAA pour avoir des performances correctes (utilisables) car EXA était catastrophique, mais en XAA pas moyen d'avoir à la fois un compositing manager OpenGL (compiz) + xv ! Vais finir par revenir à Etch où tout marchait bien (ou jouer les têtes brûlées et compiler xorg 1.6...))

Note que "rapide" dépend de ton besoin et que tu vas zapprt des solutions au ratio performance/coût intéressant si tu mets la barre trop bas sur le coût.

Les FPGA en général peuvent en effet t'apporter une puissance de calcul plus qu'intéressante si tu as des besoins spécifiques (et les compétences et le temps pour tirer parti du FPGA, évidemment !). Jette par exemple un coup d'oeil sur http://www.armadeus.com
Même remarque pour OpenCL/Cuda/gpgpu/CellBE : les cartes graphiques (ou le Cell) ont une puissance de calcul assez fabuleuse... pour certains types de calculs !
Pour un exemple très concret, regarde ça (juste pour le fun hein ;)
http://www.802.11mercenary.net/ps3-wepcrack/
(après, on peut toujours gloser sur le fait que Sony laisse tourner Linux dans une sandbox, empêchant l'utilisation du GPU pour les calculs, mais bon... :)

Pour ma part, je me suis acheté une carte-mère mini-itx D945GCLF2 à base d'ATOM 330 (maintenant ça doit tourner dans les 80 €). Le système est dual-core + HT (donc il est vu comme un quad-core). dmesg me renvoie "Total of 4 processors activated (12769.65 BogoMIPS)", pour autant que ça veuille dire quelque chose... Par contre, voulant m'en servir comme media-center, je suis couramment limité par la puissance de calcul d'un seul core, car individuellement c'est pas des foudres de guerre : par exemple, le décodeur H.264 de libavcodec ne semble pas tirer parti des deux (ou pseudo-4) cores, et je n'arrive pas à lire des vidéos dans des résolutions supérieures à 720p (et même 720p c'est limite...)

Bonjour,

Petite remarque : pour moi (version pdf du document), les "oe" (avec le "o" dans le "e") sont rendus incorrectement, avec un "&#339" directement dans le texte. J'ai aussi un &#8230 à un endroit...

Mais sinon, bravo et merci pour cette doc ! :)