M a écrit 2988 commentaires

Mouais le bench est pas super : il n'indique pas comment les binaires ont été compilé.

On peut apprendre [1] que certains bench se font on -O0 ou que certain exploite openmp (non supporter par clang)...

[1] http://thread.gmane.org/gmane.comp.compilers.clang.devel/14059/focus=14084

mouais ca a l'air guere mieux que le powervr : http://comments.gmane.org/gmane.linux.debian.devel.embedded/5866

En fait il y a plus de detail sur http://www.hercules.com/fr/ecafe/bdd/p/156/#product_tech_carac

C'est un processeur FreescaleTM i.MX515@ 800 MHz. Le reference manual (de 22MB) est dispo sur le site freescale.

Pour le gpu c'est un AMD :

The GPU3D (3D graphics processing unit) is based on the AMD Z430 (also known as ATI Yamato DX).

Si la machine n'est pas trop locker et le hardware est bon, ca pourrait être un truc sympa.

Depuis le fork de Xfree je trouve que le serveur X se linuxifie de plus en plus, avec des incompatibilité à chaque nouvelle version.

J'ai l'impression que la couche graphique est de moins en moins stable par rapport a ce qui se faisait il y a quelques années :

• kms : il faut forcement le driver et kernel qui va bien

• kms : on a perdu l'accélération overlay xv et on doit passer par des solutions pas toujours aussi performante (cpu, synchro, ...)

• la conf auto, c'est bien, sauf qd ca marche pas. Avant certes il fallait avoir une conf un peu complexe, mais qui avait l'avantage de fonctionner tout le temps.

• on veut ajouter plein d'extension, mais les drivers ne suivent pas. On parle du support des nouvelles cartes, par contre on oublie souvent que les drivers pour les vielles générations ne sont pas mis a jour.

-- On a beau cracher sur nvidia, mais il supporte encore des cartes graphiques qui sont sorties il y a plus de 10 ans !!! (idem pour les bsd)

-- Intel fait des drivers libres, mais leur driver n'est pas tres stable (bug graphiques, ...)

-- AMD malgré les specs sont à la traine

• on perd de plus en plus l'aspect reseau du serveur X

-- les display manageur (gdm, kdm), ne permette plus de faire du XDMCP. C'est pourtant pratique dans certaines situation (ex formation ou l'on ne veut pas installer le soft sur N pc).

• WebGL, compiz & co c'est bien beau, mais si c'est pour faire comme Windows Vista (il faut avoir du matos dernier cri), non merci

PS : désolé pour le formatage, mais la nouvelle syntaxe linuxfr n'est pas la meilleur syntaxe wiki...

Regarde comment fonctionne le package ndk. En gros, tu peux mettre des binaires dans l'apk (lib/armeabi/).

Tu peux aussi embarquer des données dans l'apk et l'installer à la main :
http://gimite.net/en/index.php?Run%20native%20executable%20in%20Android%20App

1) dans quel cas la non utilisation de l'overcommit et split-stack serait utile ?

Un des usages de ne pas utiliser l'overcommit, c'est de ne pas avoir de OOM killer (non l'OOM killer ne se déclenche pas a la création des threads, mais on a une belle erreur du pthread_create suite au mmap de la stack qui échoue) mais un comportement ou l'on peut catcher les erreurs.
Dans ce cas l'utilisation des split-stack est débile : on introduit un comportement non prédictible (si la taille de la stack doit etre augmenté et qu'il n'y a plus de memoire, que fait on ?).

De plus la non utilisation de l'overcommit est pas évidente. Tu connais des exemples de système qui l'utilise ?

2)
dans le cas classique on a la stack plus une page de garde pour catcher les débordement de pile. Avec ce système il faudra rajouter du code qui gère tout les cas de débordement de pile (allocation statique par le compilo, tableau sur la pile de taille variable, alloca, ...).

3)
J'ai pas tout suivi. Si tu alloue des pages, mais que tu n'utilises pas encore, ca influence les algo de swapping de linux ?
Pourquoi ne pas améliorer ces algos dans ce cas. Les stacks ne sont pas le seul cas de ce cas d'usage.

En plus l'utilisation en contexte embarqué des split-stack est peu recommandable pour les tâches RT. Dans le cas classique on peut pre-faulter la stack, ici on aura des mmap automatique en cours de vie du programme.

La bibliothèque Bionic écrite par Google est une alternative légère, sous licence BSD, de la glibc.

C'est plus exactement un portage de la libc de openbsd sous linux. Google n'ont pas tout récrit. Au passage ça vaut mieux, vu le nombre de bugs subtiles qui ont été trouvé dans leur implémentation des threads ...

Sur les architectures x86 et x86-64, une nouvelle option « -fsplit-stack » [...] Cela permet d’économiser beaucoup de mémoire sur les programmes multithread.

Linux étant lasy (COW), la stack est réellement alloué qu'a l'utilisation et chaque thread peut alloué 8MB sans consommer de la RAM physique.
Du coup le seul avantage que je vois c'est pour les système qui ont un espace d’adressage limité (32 bits). Et quand je lit ce que cette option coûte (chaque fonction doit vérifier s'il faut allouer une nouvelle pile), je vois pas l’intérêt du truc.

Serait il possible d'avoir des exemples concrets des avantages de toutes ces nouvelles options ?

PS : Une nouvelle version de llvm devrait sortir dans quelques jours

Il y a un truc qui m'intrigue. Il me semble avoir vu quelque part que les nouvelles centrale avait/aurait un refroidissement passif. C'est à dire quel était capable de s'auto refroidir

En effet je trouve que le système des "vielles" centrales de type fukushima est bancale :

• lors d'un tremblement de terre/accident on coupe la centrale
• le décroissement de l'énergie du combustible est exponentielle http://en.wikipedia.org/wiki/Decay_heat
• du coup même après l'arrêt on continue a produire de l'énergie, qu'il faut évacuer. Et pour évacuer cette énergie il faut une source d'énergie extérieure (electricité, fuel, ...). Pourquoi ne pas utiliser une partie de l'énergie résiduelle pour refroidir le fuel ?

Des personnes aurait plus d'info sur le refroidissement passif (études, utilisation, ...) ?

Le nouveau noyau propose également un travail d'amélioration de l'option CONFIG_DEBUG_RODATA effectué par Ingo Molnar.

Ce n'est pas Ingo qui a fait le boulot.

Cette option permet de marquer en Read Only certaines pages mémoires du noyau et, avec le noyau 2.6.38, nous bénéficions maintenant d'une protection contre l'exécution sur les données. Le bit NX (No eXecute) est mis pour les sections BSS (Block Started by Symbol)

En théorie il est mis pour tout ce qui n'est pas du code : bss, mais aussi les data, les section init (code et data)...
Mais sur le 2.6.38 ce n'est fait qu'en mode 32 bits. Un bug en mode 64 bits bloquait le suspend to RAM.
Un patch a été soumis, mais bon c'est pas un truc qui a l'air de passionner les devs Linux...

et un second patch protège le chargement des modules noyau en mettant le bit RO/NX sur les données et le bit RO+X sur le code.

En fait c'est RO sur le code + données constante et X sur le code :
RO+X sur le code ;
RO+NX sur le données constantes ;
RW+NX sur les datas ;

Tu crois qu'une telle opération est aussi facile a monter que dans un film ?

En plus seul les acteurs locaux peuvent intervenir, sinon ca revient a déclarer la guerre.

Les pro kadhafi regagne de plus en plus de terrain : http://www.lemonde.fr/afrique/article/2011/03/13/libye-les-pro-kadhafi-regagnent-du-terrain_1492505_3212.html A ce rythme la zone d'exclusion risque de devenir inutile.

En plus avec la catastrophe au japon, les medias en parle beaucoup moins. Ca risque de tombé dans "l'oubli" comme pour la cote d'ivoire.

Apparament cette centrale m'a pas de circuit secondaire, mais qu'un primaire.

Sinon c'est marrant à la TV :

• sur france 3, sur le plateau un scientifique qui explique ce qui s'est probablement passé avec des shémas (plutot de type tchernobil, mais en moins grave (le reacteur est a l'arret)), puis interview de l'ASN (Autorité de Sûreté Nucléaire) qui avoue qu'il n'ont pas d'info de premiere main
• sur france 2, interview de quelqu'un de la Areva/Cogema qui dit que c'est plutot du type Three Mile Island.

Et ben je trouve qu'interviewer une entreprise privée (france 2) et bien moins crédible que le traitement de france3. On se croirait sur TF1.

Oui mais vu que tu as fermer l'entrée comment je suis censé lire ta réponse ?

Il y avait déja une demande dans le bug lié au avatar, et celui ci as été fermé et impossible de le retrouver.
C'est vraiment tout pourris comme suivi si on peut pas retrouver les anciens bugs ni faire de recherche !!!!

Sinon le fait l'insérer des images c'est bien pour la sécurité, ca permet de faire charger au gens des liens. Genre jouer avec le like de facebook (http://linuxfr.org/nodes/84840/comments/1213031), récupérer les ip des gens qui lisse ton commentaire, ...

Au passage d'autres exploits sont dispo sur http://c-skills.blogspot.com/ (avec code et explication).

On voit que niveau sécurité android c'est pas top.

Premièrement il y a très peu de mise à jour, et comme aucun logiciel n'est parfait, il y a des bugs. Et certains contiennes des failles de sécurité plus ou moins grave. Les malware exploitent des failles dans les soft bas niveau android (process init et adb) qui permette un acces root en local ( http://intrepidusgroup.com/insight/2010/09/android-root-source-code-looking-at-the-c-skills/ ). Le navigateur a aussi des problèmes sur certaines version.

Et que fait google rien : il patch le code source (et encore c'est pas sur pour les vielles versions), mais ensuite c'est au constructeur de téléphone/opérateur de proposer l'update !!!

Bref c'est catastrophique, de plus en plus de téléphone android vont vivre avec des exploits publiques sans aucune chance d'être patché (a moins de le reflasher).

Deuxièmement avec le NDK les applis ont un accès bas niveau libc, appel système et peuvent implémenter facilement ces exploits sans aucune permission spécifique.

C'est la porte ouverte au malware sur ces engins. Surtout qu'ils sont connectés en permanence.

PS : Le système des permissions android est merdique. La liste des perms demandé par chaque appli à l'install est peu visible sur la nouvelle version du market. Et plein d'application abuse des permissions sans moyen de les installer en leur accordant qu'une partie des perms.

PS2 : Apple est mieux à ce niveau : chaque release est pour tout le monde (facile c'est eux le constructeur) et les applis sont limités au niveau de l'API utilisable.

Sauf que un des exploits est inspirer d'un exploit udev : http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1185

Arf je me demandais si on pouvais faire la même chose avec les votes sur linuxfr. Mais c'est du post + token...

a mettre en relation avec

http://linuxfr.org/suivi/support-des-vieux-navigateurs

je me demande si ce commentaire aura l'effet escompté

C'est clair qu'il faut savoir profiter des ssii :

• tu veux t'entraîner à passer des entretient d'embauche, les ssii seront un bon terrain de jeux sans gros risque.
• ton expérience (cv/stage de fin d'année) est moisie, tu as moyen de la booster chez une SSII.
• tu es jeune diplômé ou tu déménages et tu n'as pas de boulot. Et ben les SSII peuvent te permettre de gagner ta croute en attendant mieux.
• tu veux rentrer dans une grosse boite, la SSII peut etre un point d'entrée.

Le CCAN peut être une bonne idée.

Par contre ca commence mal avec le build assert.

C'est un truc assez trivial a faire, mais 4 pauvres ligne de code dans un .h sont mis sous LGPL.

Si on veut un truc viable, a mon avis il faut une licence plus permissive (BSD like).

Même en étant connecté on peux vouloir plusieurs css suivant le navigateur.

On peut peut-être définir le style aux deux niveaux, compte et cookie. Si le cookie est présent on l'utilise, sinon on utilise celui du compte.

SeaMonkey 1.1.19 entre autre

Il faudrait dans ce cas peut etre mieux organiser les css : a moins de toutes les essayer je n'ai aucune idée de celle pour appareil mobile, ou pour impression.

Ensuite il faudrait supporter les css par session (mais c'est déja un autre bug).