benoar a écrit 4238 commentaires

Exorbitant ... Ce n'est pas un magazine à grand tirage non plus. C'est le prix de 3 bières, enfin, je sais pas trop à quoi comparer, mais quand même, vu la qualité des articles (OK, c'est variable) je pense que ça les vaut (si tu voir un magazine encore plus "marginal", va regarder du coté de MISC ... et de son prix).

http://en.wikipedia.org/wiki/Secure_Digital_card#SDXC

Pas tout à fait, elle existait déjà dans la v2. Ce qui est nouveau dans la v3, c'est l'interdiction des accord du type celui de Novell/MS, qui ne sont pas directement des accords sur l'utilisation de brevets (ce qu'interdit déjà la v2), mais des accords de "promesse de non attaque" (cf l'OSP). Oui, c'est de l'enculage de mouche, mais d'un coté c'est MS qui l'a provoqué ...

Tu le rajoutes dans /etc/modules.

le processeur c'est 50%
Aujourd'hui, avec les dual-core, ça veut souvent dire que 1 core est à 100% (et puisque firefox est mono-processus, ça veut bien dire que flash consomme tout ce qu'il peut comme ressources).

Holala ... "au niveau de l'électronique" ... tu sais de quoi tu parles exactement ?
Le BIOS est executé par le processeur, comme tout programme/OS. Il communique avec des composants en envoyant des commandes (inb/outb), en écrivant dans des endroits de la mémoire mappés sur un périph (MMIO), bref, que des choses que sait faire n'importe quel OS.

Après, tu n'as pas tort sur le "à part si l'OS a les même connaissances que le BIOS" : c'est souvent le manque de doc qui empêche d'avoir un linuxbios fonctionnel par exemple. Genre tu ne pourras pas contrôler la tension / le coeff multiplicateur / etc. de ton processeur _parce que tu n'as pas les docs_. Mais si elles existent, l'OS pourrait tout à fait le faire ! Le BIOS ne peut _pas_ les cacher, sauf pour des mécanismes très particuliers comme le passage en mode protégé des x86 qui ont été conçu des l'origine pour ne pas être réversible. Mais, ça ne concerne pas l'accès à un périphérique.

Donc, pour revenir à nos moutons, quand cela concerne un périphérique dont l'OS a un driver, le BIOS ne peut rien faire !

Ou simplement :
(1).__add__(2)

Oui, bien sûr, mais c'était précisément le mode single dont je parlais.

Vu la question, j'ai supposé qu'on avait pas déjà les droits root, sinon c'est trop facile, effectivement ...

Sur ma Debian, il me demande le mdp même en single ...

Ça va pas t'aider beaucoup, mais j'ai déjà vu un problème dans le même genre qui arrivait avec OOo. Uniquement OOo. Sur un partage samba, qui marche très bien avec le reste. Avec client/serveur Ubuntu 8.10/8.04. Le bug report est ici :
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bu(...)
Personne ne sait d'où ça vient ...

Alors voilà, la méthode quand on est étudiant, en général, c'est de lire ses cours. C'est bien d'utiliser Google de temps en temps, mais je suppose que si la question t'a été posée, c'est que tu a dû étudier un peu le mécanisme de démarrage d'un système linux en cours, non ?

Sinon, pour répondre sans répondre, oui c'est possible, mais je pense que tu pars sur une mauvaise piste ... enfin, "se logguer automatiquement" me semble une mauvaise piste. Cherche autre chose ! (OK, la question t'orientais peut-être vers la mauvaise piste)

Bah, un peu comme un driver, quoi. À part que c'est plus modulaire, je ne vois pas de différence si énorme qui justifie une quelconque fermeture. Enfin bon, je peux toujours réver ...

Bizarre, moi un simple */*.c va chercher pareil en zsh. Qu'apporte le fait de mettre **/*.c ?

C'est bizarre, il faudrait que je vérifie chez moi.

Le problème vient vraiment de la définition de "désactiver" : la plupart du temps, c'est juste de ne pas initialiser le périphérique.

Le BIOS est un mini-OS en lui-même, mais n'importe quel OS un peu évolué ne passe pas par lui pour accéder aux périphériques. Le BIOS est une antiquité qui n'a plus de sens aujourd'hui, les OS se débrouillent très bien tout seul (ok, j'exagère, il le faut juste le temps de booter le kernel). Il ne peut _pas_ empêcher l'OS de voir un péripérique si celui-ci le veut vraiment.

Je teste et je te redis ce que j'ai trouvé.

Je trouve ça tout à fait raisonnable pour ce que c'est ... ce n'est pas du matos "grand public" non plus, hein.

C'est dommage, car pour moi c'est la base de l'interopérabilité de filer les specs de son matos. Ainsi, les libristes pourraient au moins essayer d'implémenter un synthétiseur libre. Même s'il est moins performant, ce n'est pas le plus important pour moi.

Bah moi je suis en linux PPC, donc c'est mort ...

Et merde : je voulais dire nom de $%&#@ ...

mais la question paraissait les gênés.
géner, non de $%&#@ ...

Le plus "drôle" dans cette histoire, c'est que les IP d'OpenCore sont distribués sous licence libre, mais nécessitent un synthétiseur proprio pour être "implémentés" dans le FPGA ...

Non. C'est pas encore sorti (remarque, je ne connais pas Astrée) à part quelques publis.

Oui Java serait mieux, mais à la base la cible c'était l'embarqué, et comme ça fait un bout de temps que le chercheur est dessus (moi je ne suis pas chercheur en fait, hein) il n'a pas changé d'objectif en route : c'est toujours le C embarqué critique, et c'est toujours comme ça que ça marche d'ailleurs dans ce domaine.

Par contre, il y a une thésarde qui bosse pas loin de moi sur Java et la modélisation par contrainte du bytecode, pour la génération de test. Elle arrive même à gérer l'allocation dynamique, elle. Je pense que si elle développe son truc, ça peut effectivement devenir énorme.

Par contre, un petit bémol à tout ça : normalement, le programme va générer des entrées pour atteindre certains objectifs, mais normalement les sorties doivent être données par un oracle. Il peut les calculer, mais à ce moment c'est faire le boulot du programme à se place, et ce n'est pas le but. Bref, on peut prendre une bonne part du boulot des mecs qui font de la valid', mais il y aura toujours de la place pour ceux qui jouent les oracles.

Voilà, petite question qui peut sembler redondante avec le contenu de l'article, mais encore une fois dans le monde de l'embarqué, je trouve quelques points troubles : peut-on développer du début à la fin pour cette plateforme avec un système utilisant 100% de logiciel libre ?

Je pose cette question car dans la présentation de POD par exemple, on parle de "free" sans autre précision, et plus tard de "open specification" mais pas d'implémentation. Je voudrais savoir s'il existe un moyen d'arriver au résultat (un système qui marche) uniquement avec des outils libres. Car à chaque news qui passe ici, on se rend compte qu'en fait, par exemple, tout est libre à part le synthétiseur HDL... Ou alors on parle de TI et de leur super plateforme libre, mais dès qu'on touche au DSP c'est "ha non, là faut raquer et tout garder secret".

Je ne suis pas "contre" ces méthodes, je ne veux pas le cul de la crémière en sus, je voudrais juste que ce soit écrit clairement si c'est le cas. Peut-être que c'est vraiment 100% libre ici, mais je ne l'ai pas trouvé très clair de mon point de vue.

Bah, le problème c'est que "couper" un périphérique ne veut rien dire. N'importe quel OS avec accès au bus PCI peut le "réactiver". Je n'ai pas essayé, mais je parie que couper le wifi/réseau/son dans le bios ne change absolument rien pour linux.

Et si tu voulais "désactiver le contrôleur disque", bonne chance pour charger un quelconque kernel ...

La différence avec Windows, c'est que pour la détection du matériel, celui-ci se base sur un interface avec le BIOS, pas comme linux.