shal a écrit 136 commentaires

Si tu avais l'option debug tu dois pouvoir utiliser une appli sur ton Linux qui va t'afficher l'ecran de ton smartphone .

je ne sais plus le nom de l'appli mais chercher tu va trouvé. Peut-etre scrcpy

C'est ma config: un PC entièrement fanless (sans ventilateur).

Une carte mère avec carte vidéo incorporé, un CPU core i3 version T (faible dissipation) un gros radiateur pour le refroidir. Une alim entièrement fanless.
Pas de boitier, la carte mère est posé sur un truc anti-static c'est tout, l'alim a coté , le disque dur pas trop loin. Le tout dans un meuble en bois très ouvert.
Le but pour moi était un PC complètement silencieux.
Reste le disque dur qui fait encore un peu de bruit, mais 2To en SSD c'est trop cher….

Bof, quand tu as essayé les 3: openswan , racoon et isakmpd. Il y en a un qui resort vainqueur….racoon

OpenSwan ? Ca existe encore ?

Si tu est sur un kernel 2.6 utilise racoon, 100 fois mieux que openswan.

Si tu est sur un kernel 2.4, bon courage.

Pour information, j'ai mis une grosse heure à lire l'intégralité.

1) c'est certes long à lire mais le ratio temps_passé/chose_apprises est très bon . Donc tant que ce ratio reste bon, qu'importe la longueur.

2) l'interview est intéressant mais pas directement lié au 2.6.33 donc aurait du être mis a part.

Contrairement à d'autres, j'aime particulièrement le passage sur les RC. On apprends plus sur comment fonctionne les développeurs entre eux et l'écosystème associé. Le reste est consacré a comment marche le noyau.

3) non

Merci pour ton travail.

En effet, erreur de copier coller.
Le vrai device c'est /dev/oco_out mais pour donner un nom plus explicite je l'ai appelé /dev/my_test dans mes explications.

Le truc c'est que je copie le buffer d'un framebuffer dans un autre module puis une application vas lire a travers /dev/my_test (ou /dev/oco_out) l'image présente dans le framebuffer.

J'ai rajouter un système de synchronisation me permettant de savoir quand une image est disponible.

Le /dev/my_test est ouvert par un module que j'ai écrit , c'est un très bête module de type filesystem :

static struct file_operations hello_ops= {
.read = helloRead,
.write = helloWrite,
.open = helloOpen,
.release = helloRelease
};

Avec :

static int helloOpen(struct inode *inode, struct file *file) {
printk(KERN_DEBUG "hello2 open()\n");
return 0;
}
Il y a aussi dans le init (avec major à 0)
ret = register_chrdev(major,HELLO_DEV_NAME,&hello_ops);
printk(KERN_ALERT "MAJOR HELLO2= %d\n",ret);

Je retrouve dans le dmesg le majeur puis je crée mon /dev/my_test : mknod /dev/my_test c 254 0

Si j'essaye de lire /dev/my_test avec cat pas de problème.
Si avec mon programme j'essaye de lire /dev/zero par exemple il fonctionne. mais pas /dev/my_test
J'ai regardé avec valgrind , pas de problème sur mon programme.

Voici un programme de test minimal qui plante :

int main(int argc, char * argv[])
{
int fbdesc;

fbdesc = open("/dev/oco-out", O_RDONLY|O_LARGEFILE );
if(fbdesc == -1)
{
perror("open fb");
exit(-1);
}

close(fbdesc);
exit(0);
}

compilé avec -g -D_GNU_SOURCE -Wall

j'ai finalement réussi a faire un squelette de ma solution, enfin je pense.

un module test1 reçoit de la donné depuis le userland , le copie dans un buffer d'un module test2 qui peut être lu par le userland. l'application bloque tant qu'il n'y pas de donné.

J'ai fait deux modules de type filesystem. Les deux ont chacun un buffer alloué par vmalloc (de même taille).
le module test2 dispose d'une méthode test2_memcpy() qui est déclaré dans un fichier .h

dans test1.c
static struct file_operations test1_ops= {
....
.write = test1_write,
...
};


static ssize_t test1_write(struct file *file, const char *buf, size_t
count, loff_t *ppos) {
.....
copy_from_user((int *)buffer1 + (int)*ppos, buf, ecrits);
...
if( test2_memcpy()(buffer1,buffer1_size) != 0)
{
printk(KERN_DEBUG "test2_memcpy failed\n");
}
......
}

Dans test2.c:
static DECLARE_WAIT_QUEUE_HEAD(wq);
static int flag = 0;
static struct file_operations test2_ops= {
....
.read = test2_read,
...
};
static ssize_t test2_read(struct file *file, char *buf, size_t count,
loff_t *ppos) {
...
wait_event_interruptible(wq, flag != 0);
flag = 0;
copy_to_user(buf, (int *)buffer2 + (int)*ppos, lus);
.....
};

int test2_memcpy(char *buf, size_t count)
{
buffer2 != memcpy(buffer2, buf, count);
flag = 1;
wake_up_interruptible(&wq);
return 0;
}
EXPORT_SYMBOL( test2_memcpy);


Et ca marche ;-)

Merci, je vais regarder plus profondément ces docs.

En effet, je viens de freezer ma machine en tentant une synchro a coup de mutex_lock ;-)


Le LDD3 j'avais vu mais c'est lourd de tout prendre d'un coup...
Quoique je viens de voir que dans le chapitre 6 (Advanced char driver) il y a un paragraphe sur blocking I/O qui semble correspondre à mon besoin.

Merci

Non, aucune.
On peut faire des lunettes pour que les normaux voit comme les daltoniens mais pas l'inverse.
Ce serait comme faire un casque qui permet d'entendre les utlra-son.

Pour voir ce que vous un daltonien:
http://www.daltoniens.fr/

J'avais jamais pu jouer a frozen-bubble.
Je viens de réussir mon premier niveau ;-)

Sur le pas de panique, je suis d'accord avec toi.

Sur le fait qu'il faille la base des hash de toutes les configurations d'ordinateur et de tous les programmes, c'est n'est pas exact.
Si tu prends la technologie TXT de Intel, cela permet de créer une racine de confiance sans avoir de mesurer ni le BIOS ni les firmware. Cela ne dépends que du chipset de la carte mère.
Et grâce à la virtualisation, tu peut créer un domaine root minimaliste qui sera "de confiance" (comprendre contrôler par les ayant-droits), et un domaine contrôler par l'utilisateur.

Je viens de lire les slides de Frederic qui a poster plus haut et qui développe ce que je viens de dire a propos de cela: http://2009.rmll.info/Trusted-computing-et-Logiciel.html
(Fred ne m'en voudra pas de citer ses slides ;-) )

Donc oui, on peut effectivement créer une solution basé sur les DRM.

Je vous rassure :
Il y a un man-in-the-middle possible, même avec les TPM 1.2
Peu de TPM respecte en réalité la norme du TCG et ne fournisse pas de certificat du TPM permettant de faire de la Remote Attestation, quasi indispensable pour créer une solution DRM basé TPM

Oui, j'avais pas citer la cold boot attack ;-)

Pour contrer la cold boot attack, il faut regarder la technologie danbury de Intel. Elle date de 207 mais ne sortira que l'année prochaine.
Là la clé de chiffrement ne quitte pas le chipset (qui est protégé des manipulation hardware).
La cold boot attack permet néanmoins de récupérer des informations qui sont en RAM...

Pour aller encore plus loin, il y a la xbox 360 .....

Un exemple d'application de TPM qui pourrait intéresser même les plus libriste d'entre vous, c'est Bitlocker.
Bitlocker existe que sous Windows mais l'équivalent Linux serait possible (mais n'existe pas clé en main).
Pour ceux qui ne connaisse pas , cela permet de protéger vos informations dans le cas où votre portable est voler.
Et il n'est pas possible de faire cela proprement sans utiliser un composant hardware.
Je dit proprement car on peut essayer de cacher par obfuscation les mécanisme de protection dans le code (comme un DRM). Si vous ne mettez pas d'obfuscation, un hacker pourrait modifier le bootloader pour récupérer votre password.

Pour plus d'information, sur comment faire du chiffrement de disque avec ecryptfs en utilisant le TPM : http://publib.boulder.ibm.com/infocenter/systems/topic/liaai(...)

Pour les nombreux qui n'aurait pas compris la blagues de Archibald.
Richard Feynman a publier une autobiographie que s'intitule: Vous voulez rire, monsieur Feynman !

Auto-biographie que je conseil, Richard Feynman étant un "personnage"

MAO pour Musique Assisté par Ordinateur
Je le précise comme la dépêche ne le précise pas....

La lampe qui sert pour la photo.
Je m'en sert plus souvent que de l'appareil photo ;-)

Le Trusted Computing a beaucoup évolué depuis TCPA/Palladium.

Notamment sur comment le rendre acceptable par les utilisateur soucieux de leur liberté.

Mon stage se situe justement dans ces derniéres avancés.

Oui, j'ai oublié ces données pourtant basique ;-) :

- durée : 6 mois , a partir de mars ou avril
- stage énuméré. je ne sais plus exactement combien (autour des 800/900).

Quand à l'ouverture sur un CDI, honnêtement assez peu de chance. Mais les étudiants devraient se méfier de cette carotte. Très très peu de boite peuvent annoncer qu'elles embaucheront 6 mois après. Ni les grosses boites (en réorganisation permanente), ni les ssii (dépendant des contrats), ni les petites.

N'hésiter pas à envoyer des questions par mail ou ici.

Oui, l'annonce a été envoyé chez eux mais pas de candidat de chez eux. peut-être qu'elle n'a pas été diffusé correctement.
Pourtant c'est un stage très intéressant....

Zut, il manque un truc a cette solution.

En effet a la lecture on aura pas besoin de detarer l'archive pour avoir accès aux fichiers.
par contre à la création il y aura une duplication de mes fichiers.
Et comme cela se compte en giga, je vais avoir des pertes de performances.

Je vais voir du coté de unionfs ou ceux utiliser par les liveCD

Merci pour cette idée.
Elle me convient parfaitement. Je suis un peu bête de pas y avoir penser plus tôt. Mais j'étais tellement parti sur mon idée que c'était faisable avec tar.


Désolé si ma demande était pas très claire.

Non pas tout a fait, en fait pour pouvoir communiquer avec d'autre être intelligent il faut que nous et eux soyons suffisamment évolué.

Si la période entre le moment où on est suffisamment évolué pour envoyer des signaux n'est que de 50ans la probabilité de recevoir pendant cette période le signal émit par d'autre planète est faible (décalage horaire compris).

Mode paranoiaque: c'est quasiment une preuve que ça vas péter ;-)

Maintenant , on sais pourquoi on est seul dans l'univers et que l'on as pas encore communiquer avec des êtres plus évoluer.

En effet, a un stade de développement, toutes espèces ce met a produire un l'accélérateur de particule qui détruit leur planètes.

Maintenant c'est notre tour...


;-)

Un live-USB enfantin à installer sans rien sacrifier de sa clé, qu'on peut adapter à sa guise comme une distribution classique, et qui se paie le luxe d'être plus rapide que celles-ci lorsque chargée en RAM, ça donne envie de n'utiliser ses disques durs que comme stockage passif de ses fichiers !

C'est pile-poil ce que je veux faire pour faire un PC qui sert de source HiFi. le bruit est a proscrire et donc les disques dur.
j'avais commençais a faire joujou avec des clé USB Ubuntu, c'est pas mal mais ce qui m'arrêter c'était que pour rajouter une application ou faire des mise a jour il faut recommencer tout l'image.
j'espère que avec la slax ce sera (facilement) possible.

J'ai essayé, très simple a créer la clé usb bottable.
très prometteur tout cela....