au moment de l'exec par le fils, il "exec" le shell lui même (argv[0]) au lieu du programme entré.
exit(0) après le wait ne devrait pas être là.
les modifications sur stdin/stdout doivent se faire dans le fils (avant l'exec). Là tu le fais dans le père/shell et, en plus, après le fork, ce qui n'a aucune incidence sur le fils, ce n'est certainement pas ce que tu veux..
surcharger l'argv du main pour construire ton argv pour l'execv est, en plus d'être carrément dégueulasse et illisible, dangereux car rien ne t'indique qu'il est bien dimensionné. Construis en un autre à l'aide de malloc! (btw fgets ne devrait pas non plus être utilisé, je l'avais déja dit à ton collègue ou à toi.
conseil: continue de découper ton code en fonctions, par exemple en faire une pour le fork+exec+modification stdou/stdin serait déja pas mal, voire une autre pour construire l'argv ou encore pour "parser" la ligne d'entrée
conseil: utilise "strace -o /tmp/trace -f -t ./shell" afin de savoir quels syscalls sont effectués par ton programme. L'argument "-f" est important, il demande de tracer aussi les fils. Avec le code posté, tu obtiens qq chose du genre (j'ai retirés les lignes non pertinentes).
La première ligne indique le pid. On voit bien que le wait fonctionne bien, mais que le fils (pid 3063) fait une lecture sur stdin (fd=0) et ne quitte qu'au moment on on entre CTRL+D (read=0 => EOF). Note que le fork est en fait le "clone", c'est la primitive noyau ("syscall") que la fonction fork de la libc utilise. Tu peux aussi utiliser ltrace (avec un L pour librairies), qui normalement te donne les noms de fonctions appellées, mais en règle générale, c'est beaucoup plus lent et verbeux, et il faut avoir les infos de débuggages.
et donc que le noyau bloque les nouvelles écritures en attendant que le pipe soit lu de l'autre côté.
If a process attempts to read from an empty pipe, then read(2) will
block until data is available. If a process attempts to write to a
full pipe (see below), then write(2) blocks until sufficient data has
been read from the pipe to allow the write to complete.
-- pipe(7)
En rejoignant Francesco et lolop, et en tentant de synthétiser voire de complèter :
Thread:
- communication simplifiée: i.e. un seul espace de mémoire partagé, attention aux problème de synchronisation à ces données (mutex) et de live/dead-lock.
- pas d'isolation en cas de plantages.
- nécessite d'utiliser des bibliothèque thread-safe, sauf si leur utilisation est confinée dans un seul thread (et encore… cf. genre perror).
- de manière générale, toute resource/fonctionnalité qui est associée à un processus est partagée entre ses threads : file descriptor, mémoire et autres mappings, privilèges et permissions, signaux, etc. Parfois il y a moyen d'utiliser une API par thread (cf. comme ton affinity), parfois non. Dans tous les cas, il faudra bien faire attention aux petites notes dans les pages man car souvent il y a certaines substilités ou interactions (par exemple, dans quelles conditions et quel thread reçoit le signal lorsqu'un fork d'un autre thread se termine (SIGCHLD) ? question non-triviale… :p).
- tant tous les cas, ce n'est pas plus lourd qu'utiliser des processus, ce serait même un peu plus lèger: si ce n'est au niveau de la mémoire kernel au moins au niveau du travail nécesaire à la création d'un nouveau thread. Dans ton cas (création à l'origine, nombre très réduit), c'est insignifiant. Amha on t'as dit ça dans le contexte d'un serveur web ou applicatif qui démarre un thread pour chaque nouvelle requête par opposition à un style de programmation évenementiel (qui n'a pas besoin de créer des nouvelles resources "lourdes"—thread, processus—pour s'accomoder d'une charge grandissante). Après tu as des archi hybrides async + thread-poll qui théoriquement peuvent-être très efficaces… Mais bon la on entre dans le domaine de l'overkill.
- possibilité d''utilisation d'un alogrithme paralellisable, à grand frais de complexité d'implémentation.
Processus:
- "force" un style de communication par message, ce qui en soit peut être un avantage et peut simplifier le raisonnement afin d'éviter les live-lock.
- permet aussi de partager une zone mémoire, certes avec un peu plus de travail: via mmap/shm. Pour faire de l'ipc (p.e. pour synchroniser l'accès), tu as aussi shm, les sémaphore et les ipc type sysV, et probablement d'autres trucs linux only
- plus robuste en cas de plantage mais nécessite alors un système de baby-sitting et de rendez-vous (qui peuvent être très simple à mettre en oeuvre, néanmoins cela reste à faire).
Une autre possibilité c'est l'utilisation de la programmation asynchrone avec boucle d'évènement et la partie "calcul" qui travaille de manière itérative sur des petis morceaux… Certes, ton programme n'exploite a lui seul plus les deux coeurs, mais le coeur inutilisé peut travailler pour le kernel, le pilote ou le processus de capture. Bref il faut savoir où est la charge avant de chercher à vouloir l'optimiser. Que te donne un "top" pendant la capture ? Normalement, la capture en tant que soit (read()) ne devrait pas prendre du temps cpu "user" à ton programme.
grosso-modo: while(ev=lastevent()) {
switch(ev) { case read_done: lire données suivante; case write_done: écrire données suivante; case default: itération calcul;} si calcul fini alors attendre le prochain évèvement, sinon vérifier sans attendre.
Bref selon moi la programmation évènementielle est la plus simple et la plus fiable, sans overhead du à la synchronisation; suit ensuite en terme de fiabilité la division en processus et je ne conseillerais les threads qu'en derniers recours. Par contre, ceux-ci sont indispensables si ton algorithme de calcul est "paralellisable", ce qui, sans vouloir te dénigrer, n'est à priori pas le cas car cela demande un niveau de compétance qui ferait que tu ne te poserais sûrement pas ici en premier lieu ;-)
Tu ne vas quand meme pas émuler 50 machines arm ? Pourquoi ne pas utiliser une solution plus légère à base de uml, lxc, vnet, openvswitch, marionette (iirc c'est assez lightweight et utilise uml) ou une combinaison custom de ceux-ci sur base de tun/tap. Donc en natif sur de l'amd64, ensuite j'imagine que l'intérêt de ta recherche c'est de faire le test en vrai sur du matos (i.e. une simulation réseau ne reste qu'une simulation…). Je réserverai l'émulation qemu* pour faire la cross-compilation (et encore si t'as déja le matos, cela n'est peut-être pas nécessaire de s'embêter avec cela) ou bien si tu dois faire du dev kernel.
Ta recherches se situe au niveau protocole de réseau radio (genre mesh, batman ?) et implique du developement noyau ou bien c'est juste applicatif ? Pour du dével noyau, UML pourrait être indiqué. Si c'est de l'applicatif, peut-être qu'un autre système offrira plus de facilité : de ce que j'ai entendu parler: vkernel sur dragonflybsd, rump sur netbsd, les jails de freebsd sont normalement assez puissantes, routing domaine + vnet + alt + pf d'openbsd, maintenant faut voir un peu quelles features tu as besoin (simulations de panne, délais aléatoire, etc).
Il me semble que la couche réseau du noyau continue de recevoir des fonctionnalités permettant l'introduction de delais et autres simulation de fautes… Bref: utilise un kernel récent et regarde du côté du linux/Documentation/networking et des outils iproute2 et tc.. Ça peut-être utile, du moins pour du développement user-space.
PS: Par contre si tu veux convertir des partitions primaires en étendues cela risque d'être un peu plus sportif, mais, vu les autres commentaires, apparemment cela ne serait pas nécessaire. Arrange toi juste pour que ta partition ntfs soit primaire avec l'id 1, windows ignorera le reste…
PS2: L'inverse (conversion étendue->primaire) est théoriquement plus facile. Fin bref si tu te demandes ce qu'il est possible de faire avec ta clef sans devoir reformater et/ou déplacer des données (+fix métadonnées des partitions), poste toujours la sortie du fdisk.
Ce qu'Olivier implique c'est que tu peux juste recréer la table de partition en changeant les ID, en gardant les mêmes offsets (tip: notes les offset avant et compare ensuite les sorties de fdisk, il ne faudrait surtout pas que t'es partitions ne "tombent" plus aux bons endroits)… sfdisk peut être plus simple à utiliser pour ce genre de manip mais cela reste aussi tout à fait possible avec fdisk,cfdisk et autres. Tu coup tu ne dois rien formater et tu ne perds rien. Au pire, tu fais un backup du mbr avant au cas où : dd if=/dev/clef of=backup.mbr count=1 (inverser if et of pour restaurer). Après, genre ton sda1/boot deviendra sda3/boot. Si le /etc/fstab du rpi utilise des uuids ou des labels de partitions, tu n'auras même pas besoin de le modifier, à vérifier donc. Il pourrait aussi y avoir quelque chose à changer du côté du bootloader rpi, typiquement un fichier de configuration qui se trouve dans la partition boot et qui spéficie l'argument root= passé au noyau (je ne connais pas le processus de boot d'un rpi donc ceci ne sont que des supputations…). Normalement ça n'est pas plus compliqué que cela :)
Le 'log-output: #' est bizzard qd même, je me serais attendu à voir ton premier echo… Comme dit nono, tu fais un chroot /target, puis tu lances ton script à la main, tu verras bien ce qu'il se passe ;-)
«Research data suggest that periodontal health could be achieved by main dietary strategies which include substitution of saturated fats with monounsaturated fatty acids (MUFA) and polyunsaturated fatty acids (PUFA), particularly n-3 PUFA». (2015).
Les acides gras saturés proviennent majoritairement d'origine animale à quelques exceptions près. C'est vrai j'aurais du écrire soit graisse d'origine animale ou acide gras saturé. Les acide gras saturés d'origine végétale ou animale sont aussi peu recommandables mais un conseil simple/effectif c'est de limiter la consommation de viande grasse et de ne pas utiliser le lait de coco comme substituant ayant une meilleur valeur nutritionnelle par rapport à la crème car ça n'est pas le cas.
En mettant de côté ma précédente formulation un peu maladroite, cette réponse te convient-elle mieux ?
a vraissemblance d'une backdoor dans red-hat […] détruirait toute leur crédibilité et leur commerce de manière tragique…
Comme pour n'importe quel éditeur de logiciels, libres ou pas.
Argument facile mais attendu. Aller, prenons un exemple, genre Macromedia/Adobe ? Au nombre de failles, on pourrait quasiment parler de backdoor. Bizarrement je n'ai jamais entendu parler d'une institution qui faisait tourner son "core-business" sur de l'action script. On est d'accord que la nature d'une relation client-entreprise est singulière à ce client et à cette entreprise et que ce n'est donc pas une constance au sein d'un même secteur d'activité ?
PS (pour le karma): Dans cette relation, il y d'autres composantes que cette confiance économique et rationnelle qui rentre en compte: par exemple il y a souvent une dimension psychologique mais aussi un aspect "prise d'otage" (aussi très présent en informatique) tel que la contrainte Oracle pour ne prendre qu'un exemple peu sujet à polémique, mais bon suivez mon regards… Bref la nature des relations que Red-Hat entretient avec ses clients me semble plus exposée aux conséquences d'un tel agissement, que d'autres de ses concurrents si on cherche vraiment à comparer. Mais bon ça n'est pas un gage de garantie absolue, ça déplace juste le curseurs du bon côté…
tu n'as rien à faire toi-même des commentaires que tu écris, tu ne te les appliques pas à toi-même.
Pardon ? Dans un autre commentaire du me demande par "curiosité" la liste de mes choix, alors écoutes: je n'ai pas smartphone parce que je n'en ai pas l'utilité et que je trouves ça stupide voir néfaste: processus de fabrication inhumain, pollution, prône une forme de dé-socialisation, peu respectueux de mes droits et libertés, contraintes budgétaires, matériel décevant, pas possible de l'utiliser pleinement (car fermé et proprio), etc. C'est vrai que le principe de sécurité n'est pas sur cette liste mais c'est parce que je considère que la sécurité ne peut être que le produit d'un processus ouvert par opposition à proprio/fermé*. J'ai le même gsm depuis +6ans, le modèle basique qui a remplacé le précédent que j'ai malencontreusement égaré ou détruit. Je sais c'est pas libre, et qu'au niveau de la technique/sécurité c'est le pire de tous, mais on ne va pas me piquer mon numéro de CB avec. Est-ce pour ça que je n'applique pas mes propres principes ? Oui probablement, selon ta logique binaire.
Après je pourrais te répondre n'importe quoi tu vas quand même me ressortir ton argument : "ah ben tu vois, vu que tu ne fonde pas tes puces toi même, ben tout tes principes tu peux te les garder", ou me taxer de deux poids deux mesures, ou encore me la faire celle de "ah tu mets des mots dans ma bouche, je n'ai jamais dit ça" (ah non ça tu ne me l'as pas encore faite, je faisais attention… on va voir si ça passe toujours ici… :p)
Désolé: primo, ça n'est pas ce que j'appelle être pragmatique. Deusio: je crois que ce journal tient toute la substance factuelle dont on a besoin. La prochaine fois, je laisserai simplement un flyer pour la prochaine réunion des UAS (utilisateurs anonymes de smartphone).
*: point sur lequel je suis visiblement en désaccord avec tout le monde ici, c'est marrant à une autre époque le débat priorio/libre vs sécurité s'articulait de manière différente ici. Y a plus que pBpG qui a une discution sensée maintenant qu'il ne doit plus s'occuper des aspects idéologiques ;-)
J'en fais pas un haine du proprio, j'écris si mal que ça ? Je dis juste que pour miniser les risques il y a une solution plus intelligente qu'utiliser un smartphone proprio et d'installer n'importe quoi dessus (et puis venir chercher des infos sur, tiens, un forum web).
Pour moi il s'agit d'une analyse rationnelle. Biensûr comme la pluspart des gens je fais des compromis, parfois parce que pas-le-choix, parfois par facilité/confort. Et ? Dois-je vraiment étaler la liste de mes choix avant de pouvoir écrire que faire une confiance aveugle à des processus industriels sur lequel on a aucune vibilité, aucun contrôle, qui sont réputés pour ne pas être fiables, qui ont des objectifs en conflit avec ma propre indépendance, semble naïf ?
J'aimes beaucoup ton pragmatisme, sauf que, pratiqué religieusement de la sorte, il n'en porte plus que le nom.
D'un côté on me reproche d'être noir/blanc alors que la sécurité est une science de l'évaluation des risques d'une perte comparé au coût de sa protection et non une science de la certitude, et maintenant tu me reproches d'être inconstant et de ne pas rechercher une sécurité absolue en applicant les mêmes mesures drastiques à deux menaces qui, excuse moi je crois que l'on peut au moins être d'accord là dessus, ne sont pas équivalentes. Bref à force de tirer, le troll va finir par s'user.
Là où je me plante, c'est effectivement d'avoir pensé qu'il était évident pour tout le monde qu'utiliser un smartphone comportait des risques relativement importants. Plus important qu'utiliser un os libre sur du matos pas libre. Voilà risque = chance, rapport cas (dé)favorables/# de cas, on peut se baser sur des chiffres objectifs pour l'évaluer avec plus ou moins de réussite. C'est certain que'à ne pas avoir de smartphone, je m'expose néanmoins au risque d'être la victime d'un spyware+exploit et/ou backdoor matériel sous mon matos/os actuel. Il est juste relativement très, très, faible. Loin derrière le risque de me faire aggresser devant chez moi parce que quelqu'un s'est suffisemment endetté pour achetter un téléphonne du bonheur. Et figures toi que je dors encore très bien. C'est dommage de voir que même sans la composante politique, i.e. le fait que google/grosse corporation n'en a foncierement rien à caller de ma "sécurité", mon discour soit si difficile à accepter sur le plan rationnel et technique.
au fait, ton OS libre, tu l'as compilé toi-même? Regardé toutes les lignes de code? Si tu n'as pas fais ça, pourquoi avoir plus confiance en lui qu'en Android?
J'ai encore l'ambition de terminer cette tâche. Le simple fait que d'autres et moi-même pouvons le faire augmente mon degré de confiance. C'est bien de ça dont on parlait ?
Qu'y-a-t-il dans /var/log/syslog ? je ne pense pas que d-i utilise systemd, du coup je serais assez méfiant vis-à-vis de la commande hostnamectl… Amha tu aurais plus de chance en réécrivant le fichier /etc/hostname directement et en lançant la commande 'hostname monhostname'; YMMV comme on dit.
struct{fonction1=ext2_function1,...}ext2_mount_ops;// l'insance d'un objet contient un pointeur vers xxx_ops.struct{mount_ops=ext2_mount_ops,....}vnode;vnode->mount_ops->function1(...);//appel
on aurait
// un tableau statiquestructmount_ops*[MAXFS];// dont chaque élément pointe vers une structure xxx_opsmount_ops[EXT2]=&ext2_mount_ops;// l'instance d'un objet "polymorphe" contient un index et non plus un pointeurstruct{mount_ops_idx=EXT2,...}vnode// et l'appel se fait comme celamount_ops[vnode->mount_ops_idx]->function1(...)
Donc en gros rajouter une opération arithmétique sur un pointeur (l'addresse de mount_ops est connu au moment du link) pour calculer l'addresse de la function1(), Pour le même nombre de déférencement de pointeurs. (vnode->idx, mount_opt+IDX->ext2_mount_ops+OFFSET versus vnode->mount_ops->0+OFFSET). Ça serait peut-être même mieux au niveau de l'utilisation du cache cpu et pourrait consommer moins de mémoire car IDX n'a pas besoin d'avoir la représentation d'un pointeur, un octet devrait être suffisant. Que de spéculations :p
Pour le 4, je suppose que cela rendrait plus hardu la conception modulaire du noyau. C.-à-d. qu'on doit soit réserver le petit tableau au moment du link de vmlinux (donc limiter arbitrairement le nombre, p.e., de module de filesystem que tu peux charger et perdre un peu de mémoire), soit payer un coût pour une indirection supplémentaire, soit faire du runtime linking plus sophistiqué.
Enfin bon, c'est juste une supposition lancée en l'air, je n'en sais vraiment pas plus; sauf que ça me semblerait être une mesure effective à un côut quasi-nul de perf :p
En fait en appellant systématiquement keyctl(JOIN…) avec le même identifiant, le bug du noyau linux va incrémenter le compteur comme si un nouveau processus utilisait le même keyring. Il n'y a pas de création d'un objet supplémentaire. Et ce jusqu'à l'overflow qui va permettre à l'user de mettre la main sur la mémoire qui contient cet objet.
Je suppose que l'on pourrait théoriquement arriver au même résultat sans le bug mais en lançant 232 processus différents; sauf que là effectivement on va avoir un autre problème d'exhaustion de resources avant.
Non il n'y a qu'un objet keyring par processus. Le refcount est là pour pemettre le partage entre plusieurs processus. Il n'y a pas de "leak" de mémoire à proprement parler.
Au sujet des micro-noyaux, il y a tout la famille de L4 qui a montré que l'overhead réel sur un i386 avec mmu n'était en fait que de l'ordre < 5% (milieu-fin des années 90). Comme système complet, il y a minix et hurd mais ils utilisent un modèle d'ipc moins performant. Ensuite cela est vrai que beaucoup sont utilisés en configuration hybride: L4Linux, puce radio qui tourne sous SeL4, hyperviseurs nova, etc. Mais bon je ne suis pas un expert non plus.
C'est juste qu'ils réussissent à utiliser la mmu pour faire de l'ipc sans avoir une dichotomie kernel/noyau aussi bourinne qu'avec un noyau monolithique, sans pour autant se payer un flush tlb à chaque changement de contexte. Après, un système planté sera toujours moins performant qu'un système qui tourne 1-2% moins vite en conditions normales.
Un seul exemple de système démontré sécurisé que tu utilises dans la vie de tous les jours ? Aucun.
C'est bien pourquoi je ne me permets pas de venir pleurnicher.
Après, les audits de code et la preuve formelle, cela se fait. Mais il faudrait déjà avoir le code en question et un moyen de l'utiliser…
Donc en bref, oui désolé j'ai plus confiance en du code ouvert qu'en du code fermé (qui plus est, contrôlé par une entreprise américaine qui n'a que pour seul objectif que de se faire du pognon sur mon dos), et oui cette confiance n'est pas absolue.
Mais bon je tourne en rond ici, je vais donc arrêter d'argumenter; c'est pas bon pour mon karma en plus.
[…] ici le scénario c’est « je télécharge une appli sur l’AppStore, je ne veux pas me retrouver avec mes données chiffrées et un Russe qui me vend la clé pour 100€ ».
Je complète:
- une applidont je n'ai aucun moyen d'attester qu'elle n'est pas malveillante
- AppStoredont les règles de fonctionnement sont opaques, arbitraires et qui n'assurerait qu'une sécurité au finale toute relative (de l'ordre du placebo)
- mes donnéesde valeurs qui se trouvent enregistrées dans le même téléphonnent que j'utilise pour installer la première application "horloge" qui passe.
Enfin bref c'est bien beau de venir me faire la leçon sur ce qu'est ou pas la sécurité, mais j'ai surtout l'impression qu'on ne veut pas voir la poutre que l'on a dans l'oeil. C'est pas comme si c'était la première faille de ce genre en plus… Mais non on persiste à ne pas vouloir regarder que le problème se situe au moment on l'on a décidé de faire tourner n'importe quoi dans son téléphonne et d'y enregistrer toutes sorte de données en croyant que l'on pouvoit garder un quelconque contrôle sur qui ferait quoi avec nos données.
Venir pleurer que son téléphonne est troué alors qu'il est de notoriété publique que le dit téléphonne est déja sorti obsolète, ne sera jamais ou rarement offert la possibité d'être mis à jour et ce pendant une durée bien trop réduite, ne fonctionne qu'avec des logiciels fermés, et au bon vouloir d'un éditeur et du constructeur, etc. et ben moi je trouve cela complètement naïf, voir ridicule.
Visiblement cela ne caresse pas la majorité dans le sens du poil. :-D (rire démoniaque)
PS: je fréquence ce site justement parce que j'ai fais certains choix en informatique. Merci de ne pas tirer de conclusions sur ce que je fais ou devrais faire.
[^] # Re: Quelques problèmes
Posté par benja . En réponse au message introduire redirection dans un minishell. Évalué à 2. Dernière modification le 06 mars 2016 à 23:04.
Au temps pour moi: évidemment (argument sizeof…) fgets ne souffre pas de ce problème, contrairement à gets.
# Quelques problèmes
Posté par benja . En réponse au message introduire redirection dans un minishell. Évalué à 2.
au moment de l'exec par le fils, il "exec" le shell lui même (argv[0]) au lieu du programme entré.
exit(0) après le wait ne devrait pas être là.
les modifications sur stdin/stdout doivent se faire dans le fils (avant l'exec). Là tu le fais dans le père/shell et, en plus, après le fork, ce qui n'a aucune incidence sur le fils, ce n'est certainement pas ce que tu veux..
surcharger l'argv du main pour construire ton argv pour l'execv est, en plus d'être carrément dégueulasse et illisible, dangereux car rien ne t'indique qu'il est bien dimensionné. Construis en un autre à l'aide de malloc! (btw fgets ne devrait pas non plus être utilisé, je l'avais déja dit à ton collègue ou à toi.
conseil: continue de découper ton code en fonctions, par exemple en faire une pour le fork+exec+modification stdou/stdin serait déja pas mal, voire une autre pour construire l'argv ou encore pour "parser" la ligne d'entrée
conseil: utilise "strace -o /tmp/trace -f -t ./shell" afin de savoir quels syscalls sont effectués par ton programme. L'argument "-f" est important, il demande de tracer aussi les fils. Avec le code posté, tu obtiens qq chose du genre (j'ai retirés les lignes non pertinentes).
La première ligne indique le pid. On voit bien que le wait fonctionne bien, mais que le fils (pid 3063) fait une lecture sur stdin (fd=0) et ne quitte qu'au moment on on entre CTRL+D (read=0 => EOF). Note que le fork est en fait le "clone", c'est la primitive noyau ("syscall") que la fonction fork de la libc utilise. Tu peux aussi utiliser ltrace (avec un L pour librairies), qui normalement te donne les noms de fonctions appellées, mais en règle générale, c'est beaucoup plus lent et verbeux, et il faut avoir les infos de débuggages.
# Je suppose que le tampon du pipe est rempli
Posté par benja . En réponse au message [résolu] execlp apt-cache ne fini jamais. Évalué à 3. Dernière modification le 29 février 2016 à 21:24.
et donc que le noyau bloque les nouvelles écritures en attendant que le pipe soit lu de l'autre côté.
[^] # Re: Améliorations
Posté par benja . En réponse au journal bookmark - manifeste cyber. Évalué à 1.
Autant l'avoir, quant à s'insérer au milieu d'une conjugaison, entouré de virgules… ;-P
[^] # Re: Besoin de tuning manuel ?
Posté par benja . En réponse au message système multi thread vs multi process dans un système multi core. Évalué à 2.
En rejoignant Francesco et lolop, et en tentant de synthétiser voire de complèter :
Thread:
- communication simplifiée: i.e. un seul espace de mémoire partagé, attention aux problème de synchronisation à ces données (mutex) et de live/dead-lock.
- pas d'isolation en cas de plantages.
- nécessite d'utiliser des bibliothèque thread-safe, sauf si leur utilisation est confinée dans un seul thread (et encore… cf. genre perror).
- de manière générale, toute resource/fonctionnalité qui est associée à un processus est partagée entre ses threads : file descriptor, mémoire et autres mappings, privilèges et permissions, signaux, etc. Parfois il y a moyen d'utiliser une API par thread (cf. comme ton affinity), parfois non. Dans tous les cas, il faudra bien faire attention aux petites notes dans les pages man car souvent il y a certaines substilités ou interactions (par exemple, dans quelles conditions et quel thread reçoit le signal lorsqu'un fork d'un autre thread se termine (SIGCHLD) ? question non-triviale… :p).
- tant tous les cas, ce n'est pas plus lourd qu'utiliser des processus, ce serait même un peu plus lèger: si ce n'est au niveau de la mémoire kernel au moins au niveau du travail nécesaire à la création d'un nouveau thread. Dans ton cas (création à l'origine, nombre très réduit), c'est insignifiant. Amha on t'as dit ça dans le contexte d'un serveur web ou applicatif qui démarre un thread pour chaque nouvelle requête par opposition à un style de programmation évenementiel (qui n'a pas besoin de créer des nouvelles resources "lourdes"—thread, processus—pour s'accomoder d'une charge grandissante). Après tu as des archi hybrides async + thread-poll qui théoriquement peuvent-être très efficaces… Mais bon la on entre dans le domaine de l'overkill.
- possibilité d''utilisation d'un alogrithme paralellisable, à grand frais de complexité d'implémentation.
Processus:
- "force" un style de communication par message, ce qui en soit peut être un avantage et peut simplifier le raisonnement afin d'éviter les live-lock.
- permet aussi de partager une zone mémoire, certes avec un peu plus de travail: via mmap/shm. Pour faire de l'ipc (p.e. pour synchroniser l'accès), tu as aussi shm, les sémaphore et les ipc type sysV, et probablement d'autres trucs linux only
- plus robuste en cas de plantage mais nécessite alors un système de baby-sitting et de rendez-vous (qui peuvent être très simple à mettre en oeuvre, néanmoins cela reste à faire).
Une autre possibilité c'est l'utilisation de la programmation asynchrone avec boucle d'évènement et la partie "calcul" qui travaille de manière itérative sur des petis morceaux… Certes, ton programme n'exploite a lui seul plus les deux coeurs, mais le coeur inutilisé peut travailler pour le kernel, le pilote ou le processus de capture. Bref il faut savoir où est la charge avant de chercher à vouloir l'optimiser. Que te donne un "top" pendant la capture ? Normalement, la capture en tant que soit (
read()) ne devrait pas prendre du temps cpu "user" à ton programme.grosso-modo:
while(ev=lastevent()) {switch(ev) { case read_done: lire données suivante; case write_done: écrire données suivante; case default: itération calcul;} si calcul fini alors attendre le prochain évèvement, sinon vérifier sans attendre.
Bref selon moi la programmation évènementielle est la plus simple et la plus fiable, sans overhead du à la synchronisation; suit ensuite en terme de fiabilité la division en processus et je ne conseillerais les threads qu'en derniers recours. Par contre, ceux-ci sont indispensables si ton algorithme de calcul est "paralellisable", ce qui, sans vouloir te dénigrer, n'est à priori pas le cas car cela demande un niveau de compétance qui ferait que tu ne te poserais sûrement pas ici en premier lieu ;-)
[^] # Re: Améliorations
Posté par benja . En réponse au journal bookmark - manifeste cyber. Évalué à 2.
Je ne veux pas, quant à moi, parler en notre nom. Textes intéressants, ceci dit…
# Pas de réponse mais
Posté par benja . En réponse au message Simulateur de réseau : virtualisation, 802.11, scriptable . Évalué à 1. Dernière modification le 23 février 2016 à 17:58.
quelques questions :
Tu ne vas quand meme pas émuler 50 machines arm ? Pourquoi ne pas utiliser une solution plus légère à base de uml, lxc, vnet, openvswitch, marionette (iirc c'est assez lightweight et utilise uml) ou une combinaison custom de ceux-ci sur base de tun/tap. Donc en natif sur de l'amd64, ensuite j'imagine que l'intérêt de ta recherche c'est de faire le test en vrai sur du matos (i.e. une simulation réseau ne reste qu'une simulation…). Je réserverai l'émulation qemu* pour faire la cross-compilation (et encore si t'as déja le matos, cela n'est peut-être pas nécessaire de s'embêter avec cela) ou bien si tu dois faire du dev kernel.
Ta recherches se situe au niveau protocole de réseau radio (genre mesh, batman ?) et implique du developement noyau ou bien c'est juste applicatif ? Pour du dével noyau, UML pourrait être indiqué. Si c'est de l'applicatif, peut-être qu'un autre système offrira plus de facilité : de ce que j'ai entendu parler: vkernel sur dragonflybsd, rump sur netbsd, les jails de freebsd sont normalement assez puissantes, routing domaine + vnet + alt + pf d'openbsd, maintenant faut voir un peu quelles features tu as besoin (simulations de panne, délais aléatoire, etc).
Il me semble que la couche réseau du noyau continue de recevoir des fonctionnalités permettant l'introduction de delais et autres simulation de fautes… Bref: utilise un kernel récent et regarde du côté du linux/Documentation/networking et des outils iproute2 et tc.. Ça peut-être utile, du moins pour du développement user-space.
*: "QEMU/debootstrap approach" sur https://wiki.debian.org/EmDebian/CrossDebootstrap décrit une méthode assez simple pour faire l'émulation avec qemu si tu y tiens vraiment :-)
[^] # Re: Windows et ordre des partitions
Posté par benja . En réponse au message clé usb avec plusieurs partitions (pour windows). Évalué à 2.
PS: Par contre si tu veux convertir des partitions primaires en étendues cela risque d'être un peu plus sportif, mais, vu les autres commentaires, apparemment cela ne serait pas nécessaire. Arrange toi juste pour que ta partition ntfs soit primaire avec l'id 1, windows ignorera le reste…
PS2: L'inverse (conversion étendue->primaire) est théoriquement plus facile. Fin bref si tu te demandes ce qu'il est possible de faire avec ta clef sans devoir reformater et/ou déplacer des données (+fix métadonnées des partitions), poste toujours la sortie du fdisk.
[^] # Re: Windows et ordre des partitions
Posté par benja . En réponse au message clé usb avec plusieurs partitions (pour windows). Évalué à 2. Dernière modification le 23 février 2016 à 17:06.
Ce qu'Olivier implique c'est que tu peux juste recréer la table de partition en changeant les ID, en gardant les mêmes offsets (tip: notes les offset avant et compare ensuite les sorties de fdisk, il ne faudrait surtout pas que t'es partitions ne "tombent" plus aux bons endroits)… sfdisk peut être plus simple à utiliser pour ce genre de manip mais cela reste aussi tout à fait possible avec fdisk,cfdisk et autres. Tu coup tu ne dois rien formater et tu ne perds rien. Au pire, tu fais un backup du mbr avant au cas où : dd if=/dev/clef of=backup.mbr count=1 (inverser if et of pour restaurer). Après, genre ton sda1/boot deviendra sda3/boot. Si le /etc/fstab du rpi utilise des uuids ou des labels de partitions, tu n'auras même pas besoin de le modifier, à vérifier donc. Il pourrait aussi y avoir quelque chose à changer du côté du bootloader rpi, typiquement un fichier de configuration qui se trouve dans la partition boot et qui spéficie l'argument root= passé au noyau (je ne connais pas le processus de boot d'un rpi donc ceci ne sont que des supputations…). Normalement ça n'est pas plus compliqué que cela :)
[^] # Re: Console 4
Posté par benja . En réponse au message Jessie install preseed : Fin de l'installation bloquée à 18 % depuis hier. Évalué à 1.
Le 'log-output: #' est bizzard qd même, je me serais attendu à voir ton premier echo… Comme dit nono, tu fais un chroot /target, puis tu lances ton script à la main, tu verras bien ce qu'il se passe ;-)
[^] # Re: Ça a l'air trop bon
Posté par benja . En réponse au journal Galette pomme/noisette. Évalué à 1. Dernière modification le 22 janvier 2016 à 01:43.
http://www.ncbi.nlm.nih.gov/pubmed/26783708
«Research data suggest that periodontal health could be achieved by main dietary strategies which include substitution of saturated fats with monounsaturated fatty acids (MUFA) and polyunsaturated fatty acids (PUFA), particularly n-3 PUFA». (2015).
Les acides gras saturés proviennent majoritairement d'origine animale à quelques exceptions près. C'est vrai j'aurais du écrire soit graisse d'origine animale ou acide gras saturé. Les acide gras saturés d'origine végétale ou animale sont aussi peu recommandables mais un conseil simple/effectif c'est de limiter la consommation de viande grasse et de ne pas utiliser le lait de coco comme substituant ayant une meilleur valeur nutritionnelle par rapport à la crème car ça n'est pas le cas.
En mettant de côté ma précédente formulation un peu maladroite, cette réponse te convient-elle mieux ?
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 1. Dernière modification le 21 janvier 2016 à 23:20.
Argument facile mais attendu. Aller, prenons un exemple, genre Macromedia/Adobe ? Au nombre de failles, on pourrait quasiment parler de backdoor. Bizarrement je n'ai jamais entendu parler d'une institution qui faisait tourner son "core-business" sur de l'action script. On est d'accord que la nature d'une relation client-entreprise est singulière à ce client et à cette entreprise et que ce n'est donc pas une constance au sein d'un même secteur d'activité ?
PS (pour le karma): Dans cette relation, il y d'autres composantes que cette confiance économique et rationnelle qui rentre en compte: par exemple il y a souvent une dimension psychologique mais aussi un aspect "prise d'otage" (aussi très présent en informatique) tel que la contrainte Oracle pour ne prendre qu'un exemple peu sujet à polémique, mais bon suivez mon regards… Bref la nature des relations que Red-Hat entretient avec ses clients me semble plus exposée aux conséquences d'un tel agissement, que d'autres de ses concurrents si on cherche vraiment à comparer. Mais bon ça n'est pas un gage de garantie absolue, ça déplace juste le curseurs du bon côté…
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 4. Dernière modification le 21 janvier 2016 à 22:36.
Pardon ? Dans un autre commentaire du me demande par "curiosité" la liste de mes choix, alors écoutes: je n'ai pas smartphone parce que je n'en ai pas l'utilité et que je trouves ça stupide voir néfaste: processus de fabrication inhumain, pollution, prône une forme de dé-socialisation, peu respectueux de mes droits et libertés, contraintes budgétaires, matériel décevant, pas possible de l'utiliser pleinement (car fermé et proprio), etc. C'est vrai que le principe de sécurité n'est pas sur cette liste mais c'est parce que je considère que la sécurité ne peut être que le produit d'un processus ouvert par opposition à proprio/fermé*. J'ai le même gsm depuis +6ans, le modèle basique qui a remplacé le précédent que j'ai malencontreusement égaré ou détruit. Je sais c'est pas libre, et qu'au niveau de la technique/sécurité c'est le pire de tous, mais on ne va pas me piquer mon numéro de CB avec. Est-ce pour ça que je n'applique pas mes propres principes ? Oui probablement, selon ta logique binaire.
Après je pourrais te répondre n'importe quoi tu vas quand même me ressortir ton argument : "ah ben tu vois, vu que tu ne fonde pas tes puces toi même, ben tout tes principes tu peux te les garder", ou me taxer de deux poids deux mesures, ou encore me la faire celle de "ah tu mets des mots dans ma bouche, je n'ai jamais dit ça" (ah non ça tu ne me l'as pas encore faite, je faisais attention… on va voir si ça passe toujours ici… :p)
Désolé: primo, ça n'est pas ce que j'appelle être pragmatique. Deusio: je crois que ce journal tient toute la substance factuelle dont on a besoin. La prochaine fois, je laisserai simplement un flyer pour la prochaine réunion des UAS (utilisateurs anonymes de smartphone).
*: point sur lequel je suis visiblement en désaccord avec tout le monde ici, c'est marrant à une autre époque le débat priorio/libre vs sécurité s'articulait de manière différente ici. Y a plus que pBpG qui a une discution sensée maintenant qu'il ne doit plus s'occuper des aspects idéologiques ;-)
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 4.
J'en fais pas un haine du proprio, j'écris si mal que ça ? Je dis juste que pour miniser les risques il y a une solution plus intelligente qu'utiliser un smartphone proprio et d'installer n'importe quoi dessus (et puis venir chercher des infos sur, tiens, un forum web).
Pour moi il s'agit d'une analyse rationnelle. Biensûr comme la pluspart des gens je fais des compromis, parfois parce que pas-le-choix, parfois par facilité/confort. Et ? Dois-je vraiment étaler la liste de mes choix avant de pouvoir écrire que faire une confiance aveugle à des processus industriels sur lequel on a aucune vibilité, aucun contrôle, qui sont réputés pour ne pas être fiables, qui ont des objectifs en conflit avec ma propre indépendance, semble naïf ?
J'aimes beaucoup ton pragmatisme, sauf que, pratiqué religieusement de la sorte, il n'en porte plus que le nom.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 4. Dernière modification le 21 janvier 2016 à 21:23.
D'un côté on me reproche d'être noir/blanc alors que la sécurité est une science de l'évaluation des risques d'une perte comparé au coût de sa protection et non une science de la certitude, et maintenant tu me reproches d'être inconstant et de ne pas rechercher une sécurité absolue en applicant les mêmes mesures drastiques à deux menaces qui, excuse moi je crois que l'on peut au moins être d'accord là dessus, ne sont pas équivalentes. Bref à force de tirer, le troll va finir par s'user.
Là où je me plante, c'est effectivement d'avoir pensé qu'il était évident pour tout le monde qu'utiliser un smartphone comportait des risques relativement importants. Plus important qu'utiliser un os libre sur du matos pas libre. Voilà risque = chance, rapport cas (dé)favorables/# de cas, on peut se baser sur des chiffres objectifs pour l'évaluer avec plus ou moins de réussite. C'est certain que'à ne pas avoir de smartphone, je m'expose néanmoins au risque d'être la victime d'un spyware+exploit et/ou backdoor matériel sous mon matos/os actuel. Il est juste relativement très, très, faible. Loin derrière le risque de me faire aggresser devant chez moi parce que quelqu'un s'est suffisemment endetté pour achetter un téléphonne du bonheur. Et figures toi que je dors encore très bien. C'est dommage de voir que même sans la composante politique, i.e. le fait que google/grosse corporation n'en a foncierement rien à caller de ma "sécurité", mon discour soit si difficile à accepter sur le plan rationnel et technique.
J'ai encore l'ambition de terminer cette tâche. Le simple fait que d'autres et moi-même pouvons le faire augmente mon degré de confiance. C'est bien de ça dont on parlait ?
[^] # Re: Console 4
Posté par benja . En réponse au message Jessie install preseed : Fin de l'installation bloquée à 18 % depuis hier. Évalué à 1.
Qu'y-a-t-il dans /var/log/syslog ? je ne pense pas que d-i utilise systemd, du coup je serais assez méfiant vis-à-vis de la commande hostnamectl… Amha tu aurais plus de chance en réécrivant le fichier /etc/hostname directement et en lançant la commande 'hostname monhostname'; YMMV comme on dit.
[^] # Re: Journal bookmark inutile.
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 1.
L'idée c'est au lieu d'avoir par exemple:
on aurait
Donc en gros rajouter une opération arithmétique sur un pointeur (l'addresse de mount_ops est connu au moment du link) pour calculer l'addresse de la function1(), Pour le même nombre de déférencement de pointeurs. (vnode->idx, mount_opt+IDX->ext2_mount_ops+OFFSET versus vnode->mount_ops->0+OFFSET). Ça serait peut-être même mieux au niveau de l'utilisation du cache cpu et pourrait consommer moins de mémoire car IDX n'a pas besoin d'avoir la représentation d'un pointeur, un octet devrait être suffisant. Que de spéculations :p
[^] # Re: Journal bookmark inutile.
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 0. Dernière modification le 21 janvier 2016 à 17:56.
Pour le 4, je suppose que cela rendrait plus hardu la conception modulaire du noyau. C.-à-d. qu'on doit soit réserver le petit tableau au moment du link de vmlinux (donc limiter arbitrairement le nombre, p.e., de module de filesystem que tu peux charger et perdre un peu de mémoire), soit payer un coût pour une indirection supplémentaire, soit faire du runtime linking plus sophistiqué.
Enfin bon, c'est juste une supposition lancée en l'air, je n'en sais vraiment pas plus; sauf que ça me semblerait être une mesure effective à un côut quasi-nul de perf :p
[^] # Re: Journal bookmark inutile.
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 1.
En fait en appellant systématiquement keyctl(JOIN…) avec le même identifiant, le bug du noyau linux va incrémenter le compteur comme si un nouveau processus utilisait le même keyring. Il n'y a pas de création d'un objet supplémentaire. Et ce jusqu'à l'overflow qui va permettre à l'user de mettre la main sur la mémoire qui contient cet objet.
Je suppose que l'on pourrait théoriquement arriver au même résultat sans le bug mais en lançant 232 processus différents; sauf que là effectivement on va avoir un autre problème d'exhaustion de resources avant.
[^] # Re: Journal bookmark inutile.
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à 2. Dernière modification le 21 janvier 2016 à 17:26.
Non il n'y a qu'un objet keyring par processus. Le refcount est là pour pemettre le partage entre plusieurs processus. Il n'y a pas de "leak" de mémoire à proprement parler.
Au sujet des micro-noyaux, il y a tout la famille de L4 qui a montré que l'overhead réel sur un i386 avec mmu n'était en fait que de l'ordre < 5% (milieu-fin des années 90). Comme système complet, il y a minix et hurd mais ils utilisent un modèle d'ipc moins performant. Ensuite cela est vrai que beaucoup sont utilisés en configuration hybride: L4Linux, puce radio qui tourne sous SeL4, hyperviseurs nova, etc. Mais bon je ne suis pas un expert non plus.
C'est juste qu'ils réussissent à utiliser la mmu pour faire de l'ipc sans avoir une dichotomie kernel/noyau aussi bourinne qu'avec un noyau monolithique, sans pour autant se payer un flush tlb à chaque changement de contexte. Après, un système planté sera toujours moins performant qu'un système qui tourne 1-2% moins vite en conditions normales.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à -4.
Yes, Mea culpa d'avoir hijacké le thread d'antistress. J'ai lu "firefoxOS", j'ai cru qu'on était vendredi ;-)
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à -3. Dernière modification le 21 janvier 2016 à 17:07.
C'est bien pourquoi je ne me permets pas de venir pleurnicher.
Après, les audits de code et la preuve formelle, cela se fait. Mais il faudrait déjà avoir le code en question et un moyen de l'utiliser…
Donc en bref, oui désolé j'ai plus confiance en du code ouvert qu'en du code fermé (qui plus est, contrôlé par une entreprise américaine qui n'a que pour seul objectif que de se faire du pognon sur mon dos), et oui cette confiance n'est pas absolue.
Mais bon je tourne en rond ici, je vais donc arrêter d'argumenter; c'est pas bon pour mon karma en plus.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à -7.
Je complète:
- une appli dont je n'ai aucun moyen d'attester qu'elle n'est pas malveillante
- AppStore dont les règles de fonctionnement sont opaques, arbitraires et qui n'assurerait qu'une sécurité au finale toute relative (de l'ordre du placebo)
- mes données de valeurs qui se trouvent enregistrées dans le même téléphonnent que j'utilise pour installer la première application "horloge" qui passe.
Enfin bref c'est bien beau de venir me faire la leçon sur ce qu'est ou pas la sécurité, mais j'ai surtout l'impression qu'on ne veut pas voir la poutre que l'on a dans l'oeil. C'est pas comme si c'était la première faille de ce genre en plus… Mais non on persiste à ne pas vouloir regarder que le problème se situe au moment on l'on a décidé de faire tourner n'importe quoi dans son téléphonne et d'y enregistrer toutes sorte de données en croyant que l'on pouvoit garder un quelconque contrôle sur qui ferait quoi avec nos données.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à -4.
Heu… gni ? "Il dit qu'il voit pas le rapport."
[^] # Re: Android certes, mais Firefox OS
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016 . Évalué à -3.
Appelles cela comme tu veux, j'assume pleinement.
Venir pleurer que son téléphonne est troué alors qu'il est de notoriété publique que le dit téléphonne est déja sorti obsolète, ne sera jamais ou rarement offert la possibité d'être mis à jour et ce pendant une durée bien trop réduite, ne fonctionne qu'avec des logiciels fermés, et au bon vouloir d'un éditeur et du constructeur, etc. et ben moi je trouve cela complètement naïf, voir ridicule.
Visiblement cela ne caresse pas la majorité dans le sens du poil. :-D (rire démoniaque)
PS: je fréquence ce site justement parce que j'ai fais certains choix en informatique. Merci de ne pas tirer de conclusions sur ce que je fais ou devrais faire.