M a écrit 2996 commentaires

Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug.
Dans ce cas on fait un truc minimaliste et simple, pas un truc qui essaye de tout faire, qui a des interaction avec l'extérieur via IPC [1].

[1] Surtout dbus, je n'arrive pas a comprendre comment un truc qui ce voulait simple est arrivé à une telle API. "D-Bus is a message bus, used for sending messages between applications.
Conceptually, it fits somewhere in between raw sockets and CORBA in
terms of complexity.". C'est bien plus proche du corba que des sockets...

oui le markdown ça pue, ca demande un formatage ligne par ligne...

http://opencores.org/openrisc,linux : "Status

Kernel version is tracking mainline. It is capable of booting and running BusyBox userspace. The C library providing user space support is uClibc."

Ca inspire confiance ...

Les licences GPL et LGPL me semble peu adaptées pour le hardware : déjà comment on définit la notion de travail dérivé ?

Si je mets une brique GPL sur mon asic qu'est ce que je dois redistribuer ? Idem pour la LGPL.

Ensuite comment appliquer la GPLv3 sur un asic. Le fournisseur du chip doit me donner accès a sa fonderie pour que je puisse faire tourner mes modifs ;)

Ensuite vu les coûts pour fondre un processeur avec des technos moderne (de l'ordre du millions d'euros), si on a le choix entre une brique opensource sans garantie, et une brique qui coûte quelques K€ avec du support, un historique (on sait que cette brique tourne déjà chez les concurrents, il y a déjà des drivers). Le choix est vite fait.

Surtout que lorsque l'on regarde les projets "OpenCores Certified" http://opencores.org/projects?occp=on et ben il reste pas grand chose d'intéressant : I2C (c'est pas la mort à faire), sdcard (douteux vu qu'il ne supporte pas le mode 1 bit, qui est le mode de démarrage des sd. Support de sdio ?), contrôleur lcd de base (c'est pareil, c'est pas très complexe a faire).

Au final tous les trucs qui seraient intéressants à avoir : usb2 (ehci host + otg), gpu, NAND, ddr/ddr2, video encoder/decoder, lcd avancée (vide scaler, color space conversion, plane blending, ...) ne sont pas dispos.

<i>Je pense que ce processeur est encore trop proche des procs
actuels qui gaspillent les transistor comme si cela n avait pas un cout.
commencons par revenir a un proc 16 bits car cela suffit amplement.
32 bits ne servent a RIEN . </i>
Tu vis dans quel monde. Les smartphone ressemble de plus en plus a des pc avec 512 Mo de RAM et des Ghz sous le capot. Les proc passe au 64 bits (Mips le fait deja, arm sont en train de le faire).

Et puis qui dit 16 bits qui 64Ko de mémoire adressable. Je te met au défit de faire tourner un Linux sur cette archi ...

En cherchant bien on peut l'obtenir sans se loguer. Mais le site est assez mal foutu...

<i>Le consommateur veut du pas cher. Vous pouvez vous mettre à plusieurs ici pour crier le contraire, vous ne représentez pas un volume critique: aucun intérêt économique à satisfaire vos besoins</i>
Et ben s'il achète un produit de qualité d'occasion, il payera surement moins cher (sur la durée) qu'un produit a bas coup.

La filière de la récup est très peu développé en france. Quand je vois ce qui est mis chaque mois dans les rues (encombrant destiné a la décharge), je me dis qu'on pourrait faire pas mal d'heureux pour certaines population pauvre.
Y a qu'a voir le reportage de talasa hier. Une assoc se fait chier a retaper des epaves pour les offrir aux pecheurs d'Haïti, alors que des "neufs" sont démantelé.

<i>Pour répondre aux questions sur "on ne peut plus réparer" ou "plus soi-même", encore une fois, prendre en compte tout le problème: </i>
Le coté non réparable vient surtout a mon avis de la miniaturisation, de l'électronique et de l'informatique que les produits embarque de plus en plus.

Avant les moteurs de voitures c'etait pas sorcier, ca reposait sur de la mécanique.
Maintenant il y a des injection electronique & co...

Idem pour les produits électronique. Avant c'était a base de grosse résistance, condo, transistor et autres composants discret. Aujourd'hui on fait une petite puce qui fait tout ca.

Enfin obsolescence vient aussi d'un phénomène de masse. Y a qu'a voir internet. Les sites internet sont de plus en plus lourd. En ben les gens suivent comme des moutons.

Ca va être pareil avec la TV. Le standard SECAM/PAL était compatible avec la version noir et blanc. C'est a dire qu'une télé a pu avoir une très longue durée de vie.
Aujourd'hui ils envisagent dans quelques années d'arrêter les flux SD et de tout passer en h264/HD. Qui va protester ? Personne, les gens sont déjà formaté a ce qu'une TV ne dure plus 20 ans...

Mais si on peut faire lire des fichier mp3 par le navigateur : http://www.world-voices.com/resources/addaud.html

Comment ca c'est pas html5 ?

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