M a écrit 3005 commentaires

Le noyau doit s'occuper de gerer le HW et les ressources du systeme et rien d'autre. Les autres fonctionnalites doivent se trouver en user-land, soit sous forme de librairie ou de service tournant en tache de fond (avec acces par local RPC ou autre)
Ca me fait doucement rigoler cet argument quand on voit ce que d'autre sous systeme du noyau font :

certaines cartes réseaux supporte le checksum crc des packets, c'est pas pourtant que celle qui ne le supporte doit doivent faire le calcul en user-land.
Idem avec les carte wifi full-mac vs soft-mac.
On peut même retrouver dans le noyau des démultiplexeur mpeg pour la gestion du dvb

Le role du noyau et des drivers c'est vraiment d'abstraire le matériel : le soft ne doit pas avoir connaissance des particularités de la carte et d'y accéder toujours par la même interface.

ALSA est a coté de la philosophie unix :
- l'API publique n'est pas sur l'interface noyau, mais sur libasound avec une API montreuse (plus de 1000 fonction) et un interpréteur lips...
- les applications ne peuvent pas accéder avec libasound directement aux cartes cheap (manque le mixage, resampling)
- pulseaudio fait bien plus qu'un mixeur soft et a des dépendances de folie ...

je vous conseille la lecture de https://sites.google.com/site/glasnostsurfukushima/bulletins qui donne des infos assez "objective" sur l'incident de fukushima.

S'il y avait que ça.

T'as pas le droit de publier l'énoncé.

Et la notation est assez subjective :
- performance du programme (temps exécution, occupation RAM)
- qualité du code (un code conforme à la norme misra, ou alors au coding rules linux ?)

En plus si t'es gagnant tu donnes ton droit a l'image a cette boite pendant 2 ans pour qu'ils puissent de faire de la pub/promo.

bref ca sent une opération de com/recrutement d'une boite et ca donne pas envie...

arf c'est du c++ tout moche.

Sinon le commentaire dans le code a l'air de dire que c'est que pour les vielles version de Word : jusqu'a 95.

il me semble que fs et gs sont quand même utilisés en particulier pour le stack protector.

fs et gs sont utilisé comme des registres (read_mostly) supplémentaire qui pointe sur des données. Ils servent pour implémenter les TLS (user/kernel) et le stack protector.

Au passage, la segmentation disparaît dans EMT64.
Sauf pour fs et gs : http://en.wikipedia.org/wiki/Memory_management_unit#x86-64

C'est dommage qu'ils n'aient pas fournie une meilleur alternative...

Pour la dernière question, non, le kernel a besoin d'avoir accès aux pages des applications !

oui mais dans le cas de linux, l'accès ce fait par un autre mapping (direct mapping).

De plus on parle de page exécutable, je vois pas ce que le kernel ferais dedans.

Lennart a eu beau jeu de souligner que systemd utilisait à fond des dizaines de fonctions spécifiques de Linux et qu'il ne s'agissait nullement d'ajouter quelques bifurcations dans le code:

Tant mieux, le jour ou debian passera a systemd, je crois que j'envisagerait de passer a une autre distrib (j'ai attendu 2 ans avant de me résigner a installer udev...; le montage par UID est une atrocité).

D'après les photos, c'est bien le hub USB qui alimente la 'bête' mais pas à travers le port USB.

D'apres ce que je vois, les cables soudés au pcb sont des cables de debug (uart, jtag).

Par contre le cable usb qui arrive a la bestiole est un peu special. Si on regarde bien la photo c'est le racord (rouge) de 2 cables usb. L'un amène le courant (host) du hub, l'autre device permet de piloter le clavier, souris, carte ethernet, ...

Pourtant il font tourner mediawiki :
https://www.redhat.com/openshift/sites/default/files/documents/RHOS_Express_Getting_Started_w_MediaWiki.pdf

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, ...) ?